Note: this series of articles applies to CentOS 5; 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, 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 disc (a CD if you’re doing a compact installation like a server install, or a DVD if you’re including more of the applications).
Prepare a build system
If you think you’re going to have to build any packages yourself, you’ll need a build system running the same version of CentOS. This machine will need development libraries and compilers. I like to set up such a machine by selecting “everything” during package selection.
Even if you’re not going to be building any packages yourself, you’ll need a CentOS 5 machine on which to prepare the kickstart repository (note that this can be a virtual machine if that’s more convenient).
On the build system, create a build directory: ~/kickstart_build. Create subdirectories like this:
|
1 2 3 4 |
~/kickstart_build +-- isolinux +-- images +-- ks |
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.
Copy repodata/comps.xml to ~/kickstart_build.
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:
|
1 2 3 4 |
# The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work |
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), 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, but since we’re going to need to quickly access various RPMs, it’s more efficient to put them all into a temporary directory. For example, you could put them in ~kickstart_build/all_rpms.
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.