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
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
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:
| +-- images
| +-- ks
| +-- LiveOS
| +-- Packages
Copy all the files from the
directory on CentOS DVD into your
.discinfo from the CentOS DVD into your
Recursively copy the contents of the
on the CentOS DVD into your
Copy the contents of the
on the CentOS DVD into your
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
Copy it to
gunzip it so that you have
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
Copy this file into
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:
clearpart --none --initlabel
clearpart --drives=sda --all --initlabel
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:
network --device=lo --hostname=localhost.localdomain
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
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
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
(which you copied from
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
%packages). Groups are noted
with a leading
@. You can edit this list, but
@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