The University of Michigan
DEPARTMENT OF PHYSICS
U-M ATLAS Grid Project
2477 Randall Laboratory
Ann Arbor, MI 48109-1120
(734) 647-5463

Kickstart Installation for
the UM ATLAS Grid Cluster

Kickstart is an installation program from Red Hat which makes it possible to customize installation of the Red Hat Linux operating system. One can use kickstart to easily create an automated non-interactive installation. Instead of answering all the installation questions manually, including all the details of package selection, you can put your answers and list of packages into a file which will automatically be read by the installation program at startup.

These notes describe how we have used Kickstart to install and configure CERN Red Hat Linux 7.2.1 on the UM ATLAS Grid cluster, which currently consists of the machines atgrid and linat01 through linat06. This system should scale fairly easily to a much larger cluster, though right now it is based on putting a floppy in the machine while it is connected to a network, and it may be possible to bypass even that requirement.

Main steps:

  1. Kickstart boot disk
  2. Kickstart configuration files
  3. Post-installation processing
  4. Updated RPM packages
  5. host configuration files
  6. pre-reboot tasks
  7. post-reboot tasks

Manual intervention is only required after all RPM packages have been installed and the system has rebooted. The only manual intervention required is to give the system it's name and IP address and to create an emergency boot disk.

Documentation about Kickstart is available from Red Hat at:

http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/ch-kickstart2.html
More general documentation about customizing a Kickstart installation (an customizing the initial RAM disk) can be found in my web page Kickstart Installation of Red Hat Linux.

Kickstart Boot Disk

The kickstart boot disk contains a kernel, an inital RAM disk, and configuration files that control what packages are installed and other aspects of the installation. The installation disk we have used is a slightly modified version of the standard Red Hat or CERN boot disk for installing over the network.

To make a copy of this bootdisk:

  1. Download the disk image as a binary file from this link (you'll probably need to right-click on the link to download):
    Kickstart Boot Disk Image for CERN Red Hat Linux 7.2.1
    (as of 1 July 2002)

  2. Copy it to a floppy, as with:
    dd if=cern721.img of=/dev/fd0 bs=1k

  3. You can mount the floppy disk (it's in FAT format) and edit the file ks.cfg (or other files) to your liking. This is described further below.

  4. Boot from the floppy while the machine is connected to the network with the "simplest" network interface card in order to perform the installation.

Kickstart Configuration Files

The files on the boot disk are: 

% ls -lt /mnt/floppy
-rwxr-xr-x    1 myers    myers         936 Jul  9 17:28 boot.msg
-rwxr-xr-x    1 myers    myers        1023 Jul  3 19:20 syslinux.cfg
-rwxr-xr-x    1 myers    myers        7744 Jul  3 19:15 ks.cfg
-rwxr-xr-x    1 myers    myers        6943 Jul  3 19:15 upgrade.cfg
-rwxr-xr-x    1 myers    myers        1415 Jun 19 21:44 ks.sh
-rwxr-xr-x    1 myers    myers        7407 Jun  7 18:43 laptop.cfg
-rwxr-xr-x    1 myers    myers         278 Apr 16 19:20 cern.msg
-rwxr-xr-x    1 myers    myers         656 Apr 16 19:20 expert.msg
-rwxr-xr-x    1 myers    myers        1198 Apr 16 19:20 general.msg
-rwxr-xr-x    1 myers    myers      705343 Apr 16 19:20 initrd.img
-r-xr-xr-x    1 myers    myers        6192 Apr 16 19:20 ldlinux.sys
-rwxr-xr-x    1 myers    myers         860 Apr 16 19:20 param.msg
-rwxr-xr-x    1 myers    myers         504 Apr 16 19:20 rescue.msg
-rwxr-xr-x    1 myers    myers      673204 Apr 16 19:20 vmlinuz

The initial message/menu displayed when the floppy is booted is contained in the file boot.msg. Color changes are marked by an "escape" sequence beginning with Control-O followed by a 2-digit hex number.

The options one can select from the inital menu are controled by the file syslinux.cfg. The version on this disk lets you select one of three separate kickstart configuration files: 1) ks.cfg to install from scratch over the network (this is the default), or 2) upgrade.cfg to upgrade an existing installation over the network, or 3) laptop.cfg to install onto a laptop from a CD (not the network).

The most important file is ks.cfg. It is divided into three parts. The first part simply contains answers to the questions normally asked during an interactive installation. The comments in the file should be enough to understand what is going on, but you can use the "Kickstart options" section of the on-line Kickstart manual to modify it to suit your needs.

One useful directive in the configuration file is interactive. When this is used, the installation will still ask you questions as it goes along, but it will use the values from the configuration file as the defaults. This has been commmented out in the configuration file, but uncommenting it is very useful for debugging.

Our version of the configuration file uses a temporary static IP address for the installation. This is set by 

### Network Configuration using linux-install IP
network --nodns --hostname install-gig --bootproto static --ip 141.211.43.124 --netmask 255.255.255.224  --gateway 141.211.43.97
It's almost trivial to change to using a temporary DHCP address, by changing this line to read 

### Network Configuration using DHCP
network --nodns --hostname linux-install --bootproto dhcp

Our configuration file include information for creating a set of Linux partitions: 

clearpart  --linux
part /boot --size   128  --fstype=ext2
part swap  --size  1024  --fstype=ext2
part /tmp  --size   512  --fstype=ext2
part /var  --size   512  --fstype=ext2
part /     --size   512  --fstype=ext2
part /usr  --size  2048  --fstype=ext2
part /home --size  1024  --fstype=ext2
We are using the ext2 filesystem because we do not yet have any experience with the newer ext3 filesytem. That should change in the near future. The sizes of these partitions are sufficient for CERN Red Hat 7.2.1 but may need to be made larger for a newer release (Red Hat installations are getting bloated).

If you select "upgrade" rather than the default of "install" then the configuration file upgrade.cfg. is used instead. The first section of this file is simlar to the corresponding section of ks.cfg except that it does not contain partitioning information.

We have had troubles with AFS after an upgrade unless you first remove any previous non-RPM version of AFS first.

Package Selection

The second part of the Kickstart configuraiton file lists the packages to be installed. This section begins with the line

%packages

You can list packages individually by name (without version numbers). You can also list collections of packages, with the name of the collection preceeded by an "@" sign. For example, to include all the packages that make up the collection called "CERN OpenAFS client" you would add the line

@ CERN OpenAFS client

You can also require that a particular package not be installed by preceeding the name with a minus sign. For example, to be sure that the telnet-server package is not installed (a good idea for security these days - use ssh instead) you would simply add the line:

-telnet-server

Post Installation Processing

The last part of the Kickstart configuration file is for post-procssing after all RPM packages have been installed. The package list ends and the post-processing section begins with the line:

%post

We have used this section to perform automatic site-specific customization of the installation. How this is done is the topic of the next several sections.

The instructions in the post-processing section are Bourne shell script commands which are run in a chroot environment. Our version of the configuration file does the following:

  1. Connects via ftp back to the server from where the installation was originally performed and copies three sets of files:
    • Newer RPM packages than those in the original installation
    • A tar file containing all customized configuration files (such as /etc/hosts and /etc/resolv.conf.
    • A script called ks.sh which will be run later.

  2. Installs the newer RPM packages.

  3. Unpacks the tar file from the / directory, thus puttting every cusotmized configuration file in it's proper place.

  4. Looks for the file /root/ks.sh This allows for further customization, which is described further below.

A log of all post-processing is kept in the file /root/ks.log

Updated RPM packages

As currently configured, the post-processing script gets the updated RPM packages via anonymous ftp from the host 141.211.101.27 (linat1.physics.lsa.umich.edu) from the directory /pub/linux/RH7.2/updates. Any RPM package found in this directory is installed, whether or not an older package was initially installed.

These packages are also installed as part of an upgrade.

Host Configuration Files

As currently configured, the post-processing script gets the configuration file tarball via anonymous ftp from the host 141.211.101.27 (linat1.physics.lsa.umich.edu) from the directory /pub/linux/um-atlas-grid. The name of the file is linatX-install.tar (it is not compressed).

For an upgrade rather than installation a separate file is used. The name of this file is linatX-upgrade.tar.

Pre-reboot tasks

The file ks.sh in the /root directory is a part of the configuration file tarball. It contains instructions that are to be performed before the post-installation reboot.

The current version does the following:

  1. Adds an NFS mount of /usr/local to /etc/fstab
  2. Creates several mount point directories
  3. Turns particular services on or off
  4. Changes the LILO boot message

After this script is finished the system will reboot.

Post-reboot tasks

All manual intervention has been saved until after the reboot. A short script which is run after the reboot is actually the rc.local script in /etc/rc.d, which is always run at the end of a boot. It is put in place as a part of the configuration file tarball described above (though it is probably better to have it copied over via ftp). It does the following:
  1. Turns certain services on or off (this is redundant with what's done in ks.sh).
  2. Sets the hostname and IP address (and restart the network with this new information).
  3. Creates an emergency boot disk for the machine (this requires that someone put in a blank floppy disk).
  4. Runs tripwire to record the filesystem status for later comparison for intrusion detection or system administration.
  5. Replaces itself with a more generic rc.local file which will be run in future reboots.

Eric Myers <myers@umich.edu> 23 July 2002
http://www.umich.edu/~myers/linux/kickstart/linatX.html