Building a custom CentOS 7 kickstart disc, part 1

Note: this series of articles applies to CentOS 7; for CentOS 6, see this series.

CentOS (and of course, it’s upstream distro, Red Hat Enterprise Linux) has an
extremely powerful, but somewhat poorly documented, tool for rapidly deploying machines
and managing their configuration: kickstart. Kickstart lets you build a custom
installation that can run hands-free. So not only is the installation quick and easy
for you, you can be confident that your machines are configured exactly the way you
want them to be.

Imagine that you have 25 web servers (or a mix of web servers, database servers,
mail servers, etc.). It would be highly desirable to install identical software
packages on all of those machines. In that way, you know that any application you build
will run the same way on all machines.

If you use the standard install DVD, achieving such uniformity can be challenging.
During the installation, it’s always possible that you might accidentally select a
different mix of packages for one machine, especially if you are not using one of the
standard installation types. Further, it’s quite likely that for your production
environment you might need some additional packages that are not part of the standard
CentOS distribution. For example, in our environment, we add apps like
aide, httperf,
zabbix, iftop, memcached,
and swatch. If you have to add these packages
manually after installation, you’ll spend a lot of time, and you might overlook a
machine or a package, leading to inconsistent behavior down the road.

In addition to your software packages, you will likely need to make various system
and software configurations. For example, you may need to configure httpd or mysql, or
maybe you need to add a group to /etc/group or
a user to /etc/passwd. It is critical that
these configurations be done consistently on all machines.

The solution is to predefine your package selections with kickstart and let the
automated installer guarantee the installation of the same applications on all
machines. Further, the postinstaller capabilities of kickstart will allow you to
install non-distro applications and perform any system configuration that you can do
from a shell script.

If you want to make your life really easy, you can set up your kickstart to
run from a single DVD.

Prepare a build system

You will need a CentOS 7 machine on which to assemble the packages and build the
custom ISO file. This can be a physical or a virtual machine; my build machine runs
under VMWare Fusion on a Mac. Download the DVD ISO for the install media. Be sure
to validate your checksums before you get started. If you are going to build on a
physical machine, burn the ISO to DVD. If you’re using a virtual build machine, you
can just mount the ISO directly.

Install CentOS 7 on your build machine; choose “Desktop” for the installation type
(unless you plan to build custom packages from source; if you need to do that, you’ll
need to install the development tools as well).

On the build system, create a build directory:
~/kickstart_build. Create subdirectories like this:

Copy all the files from the isolinux
directory on CentOS DVD into your ~/kickstart_build/isolinux directory.

Copy
.discinfo from the CentOS DVD into your
~/kickstart_build/isolinux directory

Recursively copy the contents of the images directory
on the CentOS DVD into your ~/kickstart_build/isolinux/images directory.

Copy the contents of the LiveOS directory
on the CentOS DVD into your ~/kickstart_build/isolinux/LiveOS directory.

Get the comps.xml file from repodata. This file is named
with a unique hex string for each release. In CentOS 7.0.1406, for example, it is called
4b9ac2454536a901fecbc1a5ad080b0efd74680c6e1f4b28fb2c7ff419872418-c7-x86_64-comps.xml.gz.
Copy it to ~/kickstart_build/comps.xml.gz and
gunzip it so that you have ~/kickstart_build/comps.xml.

Your kickstart config file will go into ~/kickstart_build/isolinux/ks. I like to have a separate
directory for this, because I build a series of different config files for different
machines or classes of machines.

Start from a sample configuration file

It is always best to start with a sample configuration file. CentOS makes it easy
for you to get your hands on one. Just perform a standard installation on a machine.
After the install, look in look in /root/anaconda-ks.cfg to get a sample kickstart
configuration file.

Copy this file into ~/kickstart_build/isolinux/ks/ks.cfg.

If you want your kickstart to run completely unattended, you will need to make
sure that the installer clears any existing partitions on the system before
installing. Change this line:

to

Of course, if you’re not installing to sda, you may need to
modify this line.

Do not use the --all option if you plan on running your
kickstart to install to a multiboot system; you will blow away all your operating
systems.
Then again, I don’t know that kickstart makes much sense in such
a scenario. You’re much safer installing manually.

Note: it seems that in CentOS 7, anaconda writes a line into this file that
is not valid according to the kickstart installer. This line:

should be:

Note
that the drive configuration here reflects the configuration of your build machine. If
that is different from your target machine (for example, your build machine might use
IDE drives, and your target might use SCSI, or you may want to use software RAID on the
target machine), you’ll have to edit some of these lines. When you’re getting started,
it’s easiest if you use a build machine configured identically to your target
machine.

Copy the RPMs

You will need access to all the RPMs that you might possibly include in your kickstart
(along with all their dependencies). These will be located on your install media in the
Packages directory.

You will probably find it more convenient to copy them all to your local disk;
I use this directory:
~/kickstart_build/all_rpms. This will allow
you to combine RPMs from different install media or multiple repos if necessary.

Determine which packages to include

Look in the file ~kickstart_build/comps.xml
(which you copied from repodata/comps.xml on
disc 1 of the CentOS distribution). This defines the packages and their groups.

Your baseline kickstart configuration file will list the packages that are to be
installed (under %packages). Groups are noted
with a leading @. You can edit this list, but
leave @core in the file,
since that group has system-critical packages in it.

Add groups and packages to this list.
If you want to really trim down your package list to make a tight distribution, you
can use individual packages rather than groups, which may include more than you need.
You can include a group and then explicitly exclude a specific package by
listing the package with a - prepended to the name.

Next comes the most challenging part — compiling the RPMs and resolving
dependencies.

Part 1 •
Part 2
Part 3
Part 4

Join the Conversation

9 Comments

  1. Hello,
    This is a great tutorial, thanks for putting this together.

    I have a workspace where I build the iso from a simple ks.cfg, where the only think I change from the default is set the network address on the interfaces and also add some static route in the %post section of the ks.cfg.

    I now have a requirement to add some custom rpms that I need in the machines. I noticed all these days when I am building the iso, I do NOT have a comps.xml. I do see the ‘@core’ in the %packages section of ks.cfg, however I do not see the comps.xml anywhere in the hierarchy. So I copied over the standard one that comes with the CentOS 6.5 (the OS I need), and I edited to add some rpms and remove ‘less’ (primarily to test to see if the comps.xml got picked up). Once I install the iso, I do NOT see the rpms I added and I still see ‘less’ when I had removed it from the comps.xml.

    I am terribly confused on where the ks.cfg is picking up the packages from because to being with I did not have a comps.xml. Is there a easier way to trace where it comes from?

    Thanks for your help!

    Cheers,
    B

  2. Followed your steps and got the kickstart install working. So many other resources online but none of them lay it down in such a precise manner. Although your RPM dependency checks did not work for me the way I thought it would, I was able to ensure the dependencies were satisfied in a different manner.

    Thank you very much for putting this together!

  3. Which release are you using?
    I’m using 1611 and having errors with the gather_packages.pl script.

    Error:
    ————
    Can’t locate XML/Simple.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ~/kickstart_build/utils/gather_packages.pl line 3.
    BEGIN failed–compilation aborted at ~/kickstart_build/utils/gather_packages.pl line 3
    ————

    1. In part 2 of these articles, there is an RPM command that installs the perl modules you need.

  4. Hi

    Thanks for this helpful article. I’m following your instructions to create a kick start image in Cantos 7.1.
    Copy .discinfo from the CentOS DVD into your ~/kickstart_build/isolinux directory
    I cant any file like that in my source USB. Any idea about that?

    Thanks in advance .
    -mo

  5. After burning a DVD from the resultant ISO, the install failed with what appears to be a very early service that does a checksum on the installer. Obviously it’s going to fail as “my” ISO is now custom and doesn’t match the “factory” ISO. Has anyone else experienced this?

    I read back through the blog to see if I missed a step and it doesn’t appear that I did. I either missed something or these instructions work for a distribution earlier than 7.2.1511 where “something” changed.

    Any words of wisdom would be greatly appreciated.

  6. Previously in Red Hat Enterprise Linux 5 & 6, there was an image install.img which one was able to decompress as follows.

    [[email protected] ~]# unsquashfs install.img

    Then it would be edited by changing/appending some custom information in the file /squashfs-root/usr/bin/anaconda
    Where is the file which replaced install.img ?
    How do one expand it?
    Which file do one need to update instead of /squashfs-root/usr/bin/anaconda?
    How do one rebuild the new .img file?

  7. hello,i have a problem
    Previously in Red Hat Enterprise Linux 5 & 6, there was an image install.img which one was able to decompress as follows.

    [[email protected] ~]# unsquashfs install.img

    Then it would be edited by changing/appending some custom information in the file /squashfs-root/usr/bin/anaconda
    Where is the file which replaced install.img ?
    How do one expand it?
    Which file do one need to update instead of /squashfs-root/usr/bin/anaconda?
    How do one rebuild the new .img file?

Leave a comment

Your email address will not be published. Required fields are marked *