Enhancing Kickstart

Brian Boyd

As a systems administrator, imagine being assigned to install 30 Red Hat Linux servers, and at the same time, creating a method for standardized installs. Some servers will be the same, but not all. NTP may need to be configured on all systems, but some may also need software RAID mirroring. All unnecessary services must be disabled, but these will vary by server.

Recently in a similar scenario, I looked to Red Hat's Kickstart for a solution. Kickstart provides a method for performing an automated installation and configuration. Any option in the manual installation process can be defined in a ks.cfg file, such as disk partitions, network settings, and package selection. Additionally, Kickstart allows scripts to be executed before and after the installation.

Perfect, right? Not quite. There were two problems with this solution. First, 30 Kickstart configuration files would be generated, each more than 100 lines long, and the content of which was generally redundant. Creating and maintaining such files would be inefficient. Second, the post-install process is Kickstart's greatest strength, and I wanted to use it to configure those dozens of tedious tasks that must be performed on a freshly installed system. However, there was no easy way of accomplishing this aside from copying the necessary scripts to each ks.cfg file. I was looking for a method of simply choosing which post-install scripts to execute, with minimal redundancy or effort.

My solution was to write a set of scripts that enhance Kickstart's functionality. In this environment, HTTP was to be the method of installation because of its simplicity. Additionally, the use of a Web server would allow server-side scripts to automatically generate host-specific ks.cfg files. PHP was the language of choice.

The default directory structure for these scripts is as follows:

os/ -- The directory in which all OS configuration files reside.

group/ -- The directory in which all group configuration files reside.

host/ -- The directory in which all host configuration files reside.

main/ -- This directory contains several files, as follows:

kick.inc -- Defines all public functions and is referenced by all configuration files and scripts.

kick.ini -- Defines how Kickstart is configured, such as the directory structure and URL path. It is read by kick.inc, thus making it available to all configuration files and scripts.

global.ini -- Defines global variables that are non-OS, group, or host specific. These settings are also available to all configuration files and scripts.

post/ -- The directory in which all post-install scripts reside.

pkgs/os/ -- The directory containing the contents of the Red Hat installation CDs. Each version of Red Hat exists in a different directory. For example, a Red Hat AS 3 directory would be pkgs/os/rhas3/ with the following contents: base RPMS TRANS.TBL.

pkgs/extra/ -- The directory containing RPMs not provided by Red Hat, with a directory for each operating system, such as pkgs/extra/rhas3/.

All configuration files are written in an INI file format. The three main types of configuration files are OS, group, and host. An OS file defines the default settings for that operating system; each operating system has an OS file. A group file defines settings for a group or cluster. And a host file defines settings specific to each host. Host settings override group settings, and group settings override OS settings. This tiered approach allows for maximal flexibility and minimal redundancy.

The ks.cfg file, which is called by the system that is being Kickstarted, expects to be passed the host name. This script is responsible for generating the appropriate Kickstart commands specific to that host.

Now that I've described the big picture, let me illustrate by example. There are two Web servers and one database server to be installed with Red Hat AS 3. The Web servers will be configured identically. Mirrored disks will be used, and because they reside on the DMZ, extra security precautions will be taken. Tripwire will be installed, the gcc compiler will not be installed, and certain binaries will be set chmod 0700. The database server will use LVM for the database partition. All servers need SSH and NTP configured.

The Configuration Files

The configuration files must first be created. Listing 1 shows the operating system file, os/rhas3.ini, which defines the default policies used for this operating system at this site. As you can see, many of the options found in the [kickstart_command] section closely resemble Kickstart comands.

In the [services] section, the ntpd service is enabled, while cups, mdmonitor, and mdmpd are disabled from starting up. The following scripts should be executed after the installation: network, services, pkg-rpms, ssh, and ntp. The [kickstart_package_add] and [kickstart_package_remove] sections define which packages to add or remove from the installation. This makes it easy to remove packages installed as part of the base OS that are not needed, thus saving precious backup resources. And finally, the commands to be executed during the post-install process are defined in the [kickstart_post] section. These commands download the script getpostinstall, which will then download and execute the post-install scripts defined for the given host.

Next, the group files must be created. Listings 2 and 3 show the group/web.ini and group/database.ini files. The web.ini file states that the Tripwire RPM package, which is not part of the OS distribution, is to be installed. Both the mdmonitor and mdmpd services should be enabled at startup, in addition to those services defined in the OS file. Both the Tripwire and lockdown scripts should be executed after the installation to configure Tripwire and to lockdown certain binaries.

Listings 4, 5, and 6 show the host configuration files. Host-specific settings are defined, such as host name and IP address. Note that multiple interfaces may be configured.

To view the configuration file that Kickstart will see, point a Web browser to:

http://<kickstart_server>/kickstart/ks.cfg?host=<host_name>

http://kick.mydomain.com/kickstart/ks.cfg?host=web1

Post-Install Scripts

The post-install scripts must also be created if they do not already exist. Listing 7 shows an example of the post/services script, which enables or disables services from starting automatically at boot. Note that it makes use of the global function get_host_var() to obtain the list of services to enable or disable for the given host. A possible post/ssh script is shown in Listing 8, showing how easy it is to modify files with the ed command.

Additional sections and options can easily be added in any of the configuration files and retrieved by functions, such as get_kick_var() and get_host_var(), which are defined in main/kick.inc, allowing for maximum flexibility in the post-install scripts.

It would also be possible to automate the complete configuration process of a Web server, for example. A post-install script could be written to check out the appropriate httpd.conf file and applications files from CVS. The CVS server name and CVS tags to check out could be defined in a configuration file.

Installation

Now that everything has been configured, it's time to perform an install. Starting with the system web1, insert the OS boot CD in web1 and boot from it. At the boot prompt, type:

linux ks=http://10.0.5.3/kickstart/ks.cfg?host=web1

Once the OS installation is complete, the post-installation process begins. This process, which is driven by the getpostinstall script defined in the [kickstart_post] section of the rhas3.ini file, is responsible for downloading the post-install scripts configured for the server web1 and then executing them. All output from the post-install scripts is written to the /root/postinstall.log file for later review.

After the system reboots and the root user logs in for the first time, the following message is displayed:

*******************************************
Congratulations, the Kickstart installation has completed successfully!

Review /root/postinstall.log for any errors

Tasks to perform manually:
 - Change root password
*******************************************

Note that, because this is a Web-based installation, information requiring secrecy such as passwords and private keys should be applied manually. Also, these scripts currently only work for new installs, not upgrades, but they could be modified to support those as well.

Conclusion

By minimizing redundant configuration settings required for Kickstart, these scripts allow new systems to be installed more quickly and those configuration files to be more easily maintained. Additionally, the post-install process has been greatly enhanced, encouraging the administrator to further automate the configuration process specific to the environment's needs. And, in the midst of this, a well-defined and consistent installation and configuration process is easily achieved.

Brian Boyd has a B.S. in Computer Science from Biola University, and has been working as a systems administrator for more than 4 years. When not at the computer, he enjoys spending time with his wife and two dogs. Brian can be reached at: bboyd@hotpop.com.