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
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
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 installed (under
%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 dependencies.