Building a custom CentOS 6 kickstart disc, part 1

Note: this series of articles applies to CentOS 6; for CentOS 5, 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, analog, httperf, ganglia, iptraf, memcached, nagios, 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 6 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 two DVD ISOs for the install media.  Be sure to validate your MD5 checksums before you get started.  If you are going to build on a physical machine, burn the ISOs to DVDs.  If you’re using a virtual build machine, you can just mount the ISOs directly.

Install CentOS 6 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 disc 1 into your ~/kickstart_build/isolinux directory. Also copy .discinfo from CentOS disc 1 into your ~/kickstart_build/isolinux directory

Copy all the files from the images directory on CentOS disc 1 into your ~/kickstart_build/isolinux/images directory.

Get the comps.xml file from repodata.  In RHEL/CentOS 6, this file is no longer called just “comps.xml”; instead, it has some horrendous hex string for a name.  In CentOS 6.2, it is named bedb7dc8fdf920deffbdc5a70ea0d6d77255656556184f5e996e8a88a63d145c-c6-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. Edit the file and find the partitioning information that is commented out; it will have the following note above it:

Uncomment all the lines regarding the disk partitioning. If you don’t do this, your kickstart will have no partition on which to install the selected packages.

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 don’t have to do this, but it makes your life easier to have all the RPMs in a single directory. Note that for our custom disc, we’ll copy just the RPMs we need to install, but since we’re going to need to quickly access various RPMs, it’s more efficient to put all of them into a temporary directory. Copy all the files from the Packages folder on DVD 1 to ~kickstart_build/all_rpms.  Repeat for DVD 2.

If you have CentOS CDs, copy all the RPMs onto your build machine in a temporary directory. You won’t need most of them, but when you’re tracking down dependencies, it beats switching discs in and out. If you have a DVD, you don’t need to worry about this.

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 @. Leave @core and @base in the file, since those have system-critical packages in them.

If you want to really trim down your package list to make a tight distribution, you can remove other groups or replace the groups with the names of just packages that you want from those groups, using comps.xml as a reference for which packages are in each group. You can explicitly exclude a package by listing it 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