Complete Kickstart: How to Save Time Installing Linux

Author’s note: This article first appeared in the June 2008 issue of Linux Magazine but is no longer maintained there. I republish it here with no changes because it shows a method that performs both series of tasks that I’d been doing separately, installation and post-installation. It also has historical value that I want to retain. Although some details of this article may be out of date, Kickstart and other modern tools can perform this type of all-in-one installation. You can use this article as a means to learn the possibilities.

---

By David Both and BRuce Garland

We work in a lab environment at Cisco Systems in RTP, North Carolina, and are responsible for the care and feeding of many Intel, Sun, and Cisco boxes that make up the lab environment. Because it’s a lab, developers and testers require frequent re-installations of these systems to return them to a known state. We also need to install operating systems on new boxes fairly often.

All of these installations can be time-consuming, so we were tasked with creating a locally available kickstart server for Red Hat Enterprise Linux 5.1.

As we started to delve into the requirements for creating a kickstart server we discovered that, although much of the information required to do so is available from various places on the Internet, some necessary information is very difficult to find. This article will concentrate on the specific configuration details required for an unattended network Kickstart of Red Hat Enterprise Linux 5.1. It is intended to cover all aspects of setting up a Kickstart server, including some information that is not readily available.

The basic function of a kickstart server is to allow an administrator to perform a network installation of Linux. It provides a single location to store files for installation and allows for ease of updating those files instead of dealing with multiple copies of DVDs. It also allows for very fast and hands-free installation as well as the ability to provide a menu-driven interface for selection of the desired kickstart configuration from among two or more choices.

The Requirements

Our requirements were that kickstart, once launched and after making a menu selection to choose a particular kickstart configuration, needed to be completely unattended. We also needed to install some local tools and make configuration changes to the installed boxes before they would be ready for use. The Anaconda installer menu must provide us with options to install multiple versions of this kickstart or to boot from hard drive. If no menu selection is made after a short timeout, the Anaconda installer is configured to boot from the hard drive.

Here’s what you need in order to perform a kickstart:

1. 1. A Web server and/or FTP Server for delivery of the RPMs that are to be installed.
2. 1. A DHCP server for IP address assignments and to launch PXE Boot.
3. 1. A TFTP server for download of PXE Boot components to the machines being kickstarted.
4. 1. An PXE Boot capable network card.
5. 1. The BIOSes on the computers to be kickstarted must be configured to allow a network boot.

Each of the required servers can be located on a different system, or they can be combined onto a single computer.

In addition, Cisco Core routers require special configuration to transport UDP PXE Boot packets across subnet boundaries. Our environment requires the use of a serial console during Kickstart for menu selection. This gives us the ability to select from two or more different kickstart installations.

Initial Decisions and Sizing

We chose to use HTTP for file delivery, but due to the possibility that some need might arise in the future for an FTP kickstart, we decided to configure our kickstart server directory structure so that both FTP and HTTP can be used. We also chose to house the HTTP, TFTP, and DHCP servers on a single computer.

For our environment, we had no reason not to have all of the servers on one box, and the number of simultaneous kickstarts we expect to experience is well within the capability of the hardware and network infrastructure we have available. When sizing a prospective kickstart server the limiting factors are most likely to be the hard drive data transfer rates and the network. Experience has shown up to 20 or so systems can be kickstarted simultaneously in about an hour with a very modest Pentium 4, a single IDE hard drive, and a 100Mb connection.

Using a 3.0GHz Intel Core-Duo with 4GB of RAM and dual 120GB hard drives in RAID 1 configuration on a Gigabit Ethernet connection should allow us to support multiple simultaneous kickstarts in numbers far larger than we currently expect. The only reason we used this particular hardware is that it is what we had available.

Kickstart Sequence of Events

A network-based kickstart can be initiated by an PXE Boot capable network card. The PXE Boot first requests an IP address from a DHCP server. It also obtains the location of a PXE Boot file from the DHCP server. PXELINUX is a bootloader for Linux using the PXE network booting protocol. The PXE Boot file is loaded from the TFTP server along with the contents of a file which defines the location and name of the installation kernel and initrd.img file as well as some parameters for the boot kernel and a menu for the Anaconda installer. This configuration file for Anaconda also contains the location of the kickstart configuration file to be used during the installation.

The PXE Boot file then loads the boot kernel and initrd image still using TFTP. After booting, Anaconda is started and Anaconda loads the menu and displays a window with a timer with several menu options. The Menu and time-out can be skipped if you do not need to make any choices here.

After choosing the desired kickstart installation, Anaconda locates the kickstart configuration file from the HTTP server and reads it. The kickstart configuration file has a default name of ks.cfg, but can be named anything. We use several for our different configurations, so provide unique names for each. If all of the data required to perform a complete installation is included in the kickstart configuration file, the installation completes without further intervention from the administrator. The RPM files used during the installation are downloaded from the HTTP server as they are needed.

The kickstart configuration file can also contain bash script commands that can be run both before and after the rest of the installation. We make extensive use of the post-installation bash scripts to perform installations of locally required RPM packages and tarballs as well as to make configuration changes before the first reboot.

Hardware configuration

In order to boot from the network it is necessary not only to have a network card that is capable of a network boot, but also to configure the BIOS to boot appropriately. You have a couple of options. The first is to always attempt to boot from the network as the first choice, then CD/DVD, and then from the hard drive. The second is to boot from the CD/DVD first, then the hard drive, and finally from the network. Choose the option that best fits your needs.

When booting from the hard drive prior to booting from the network, an additional step requiring some manual intervention would be required to force a boot from the network. It is necessary to overwrite the boot record to prevent booting from the hard drive. This can be done with a small script or from the command line using the dd command but it is another point of intervention.

We chose to configure BIOS to boot first from the network. We then set a short timeout for Anaconda so that the default is to boot to the hard drive if no other action is taken.

DHCP Configuration

The /etc/dhcpd.conf file must be configured correctly to provide an IP address for each client host as well as information necessary to initiate a PXE Boot sequence for each kickstart client host. DHCP determines the host name using the MAC address of the NIC making the request. Although the IP address can be specified in the dhcpd.conf file, we use DNS to maintain the addresses and DHCP does the lookup and then passes the address to the host.

DHCP can also serve a range of addresses rather than a specific address for each host, but that is outside the scope of this article.

#######################################################################
allow booting;allow bootp;dns-update-style ad-hoc;
option domain-name "cisco.com";
option domain-name-servers 109.99.6.247;
max-lease-time 604800;
default-lease-time 604800;
deny unknown-clients;

# The next-server line is required even though we point to ourselves.
# Resolves some issues relating to pxeboot across subnets.
next-server 109.99.101.74;

# 109.99.222 Subnets:
subnet 109.99.222.0   netmask 255.255.255.0
  { authoritative ; option routers 109.99.222.1 ; }

# Red Hat Enterprise Linux 5.1 Kickstart boxes
group {
filename "RHEL/pxelinux.0";
host ems-lnc100.cisco.com
  { hardware ethernet 00:15:17:1D:42:88 ; fixed-address ems-lnc100.cisco.com ;}
host ems-lnx118.cisco.com
  { hardware ethernet 00:04:23:B7:9A:15 ; fixed-address ems-lnx118.cisco.com ;}
host ems-lnx145.cisco.com
  { hardware ethernet 00:04:23:B5:6B:A9 ; fixed-address ems-lnx145.cisco.com ;}
}
#######################################################################

Listing 1: The very basic dhcpd.conf required to support kickstarts.

The filename RHEL/pxelinux.0; statement in the group stanza directs the PXE Boot to load the pxelinux.0 boot file from the specified directory, RHEL. The full path for this directory in our setup is /opt/tftpboot/RHEL where /opt/tftpboot is a symbolic link to /tftpboot. The TFTP root, /tftpboot, is defined in /etc/xinetd.d/tftp.

In each host stanza we specify the MAC address of the NIC in the respective hosts and the hostname. DHCP queries DNS for the IP address and passes it back to the host along with the router and DNS server information.

We discovered during configuration of our server for the kickstart role that the next-server line is required in dhcpd.conf to resolve some PXE Boot issues even though the next-server is really the same server in our case. You should use this statement no matter which box hosts the PXE Boot server, even if it is the same as the DHCP server. It took us a couple days to figure this out and it is one of the things we could not find documented anywhere.

The allow booting and allow bootp statements are both required for kickstarts to function.

All of the options pertaining to PXE Boot can be placed in the group or individual host stanzas as well as in the global section of the DHCP configuration. This allows you as much granularity as you need to have multiple servers and kickstart configurations as well as to ensure that only specific hosts or groups of hosts can be kickstarted.

The PXE Boot files

Three PXE Boot files are required to perform a network boot. The first is pxelinux.0, the network boot loader. The second is the network boot kernel, vmlinuz, and the third is the initial RAM disk image, initrd.img.

We placed pxelinux.0 in /opt/tftpboot/RHEL/ as this is the location we specified in dhcpd.conf. We also have discovered that this is the only place from which it works.

The kernel and RAM disk image files are placed in a distribution or release unique location such as /opt/tftpboot/RHEL/RHEL-server. We also have an RHEL workstation based release we use and place its files in /opt/tftpboot/RHEL/RHEL-workstation. This allows us to keep them separate and helps us to know which is which. We have seen configurations in which files for different distributions and releases are all located in a single directory and named differently. Our method works better for us because we like the additional organization it imposes.

For the most part one set of PXE Boot files is pretty much like another. Most Red Hat Enterprise based distributions currently provide a set of these files. Most of these files should work with most distributions. However we did find that the Red Hat Enterprise Linux 5.1 files are specific to that distribution and that PXE Boot files from other distributions such as CentOS do not work with RHEL 5.1.

TFTP Configuration

The TFTP configuration file, /etc/xinetd.d/tftp, should look like the sample configuration below. We changed disable = yes to disable = no and server_args = -s -c -v -v -v /tftpboot to server_args = -s -c -v -v -v /opt/tftpboot.

#######################################################################
# default: off
service tftp
{
	disable	= no
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s -c -v -v -v /opt/tftpboot
	per_source		= 11
	cps			= 100 2
	flags			= IPv4
}
#######################################################################

Listing 2. The TFTP configuration file required only minor changes.

Creating the PXE Boot configuration file

Each host that is to be kickstarted requires a unique configuration file which is located in the /opt/tftpboot/RHEL/pxelinux.cfg directory. This file is used to specify the locations of specific files such as the kernel and the initrd image file. These files are named with the hexadecimal representation of the IP address of the computer to be kickstarted.

You’ll find an online IP to Hex converter at http://tinyurl.com/4lzthf and another tool, written in Perl, is available at http://tinyurl.com/4pz6g3. Usage is very straightforward for each of these tools.

For example, the IP address 192.168.0.55 converts to C0A80037 in hex, so in this case the name of the configuration file for the host with ip address 192.168.0.55 is C0A80037.

Loading the PXE Boot configuration file

The PXE Boot configuration files contain information that allows PXEBoot to locate the kernel and initrd image files for the kickstart process. They also specify the serial console parameters and provide a menu for selection of the desired kickstart. The kernel and initrd images are not the files that will be installed on the kickstarted machine, but are used only as the running operating system during the kickstart itself.

The PXE Boot process tries to load the correct file for the computer by using an interesting algorithm. First it tries to load a file with a name based on the MAC address of the system, then with names based on the hexadecimal IP address, removing one hex digit for each failure. The sequence would look like this:

/opt/tftpboot/RHEL/pxelinux.cfg/01-22-33-44-aa-cc-ee
/opt/tftpboot/RHEL/pxelinux.cfg/C0A80037
/opt/tftpboot/RHEL/pxelinux.cfg/C0A8003
/opt/tftpboot/RHEL/pxelinux.cfg/C0A800
/opt/tftpboot/RHEL/pxelinux.cfg/C0A80
/opt/tftpboot/RHEL/pxelinux.cfg/C0A8
/opt/tftpboot/RHEL/pxelinux.cfg/C0A
/opt/tftpboot/RHEL/pxelinux.cfg/C0
/opt/tftpboot/RHEL/pxelinux.cfg/C
/opt/tftpboot/RHEL/pxelinux.cfg/default

The contents of our files is identical for each of the installations this process is designed for, so only a single master file is located at /opt/tftpboot/RHEL/pxelinux.cfg. Then we use a soft link with the hexadecimal IP address as its name to point to a master file. We can do this because all of our Intel boxes have the same kickstart choices available. You could also use individual files if that suits your needs better.

The contents of our master file are shown below:

#######################################################################

# RHEL5 Kickstart configuration file.
#
# NOTE: The workstation and server versions of the RHEL 5.1 images require
# different initrd.img files.

default 1
prompt 1
timeout 200
display msgs/Main.msg
F1 msgs/Main.msg
F2 msgs/general.msg
F3 msgs/expert.msg
F4 msgs/param.msg
F5 msgs/rescue.msg

#F1 Main.msg

# Hard drive
label 1
    localboot 1

# RHEL5.1-MAX
label 2
    kernel RHEL-workstation/vmlinuz
    append ksdevice=eth0 initrd=RHEL-workstation/initrd.img \
    console=ttyS0,9600n8 ramdisk_size=6804 \
    ks=http://emstools2b.cisco.com/pub/kickstart/rhel-AP-Max-ks.cfg

# RHEL5.1-MIN
label 3
    kernel RHEL-server/vmlinuz
    append ksdevice=eth0 \
    initrd=RHEL-server/initrd.img console=ttyS0,9600n8 \
    ramdisk_size=6804
    ks=http://emstools2b.cisco.com/pub/kickstart/rhel-AP-Min-ks.cfg
#######################################################################

Listing 3. PXE Boot configuration files

In Listing 3 the PXE Boot configuration files contain data to create a menu for Anaconda and information that allows the PXE Boot process to locate the files needed to boot. The append lines have been split for formatting purposes, but should be on a single line when used.

Note that there are multiple stanzas in the file. One for each possible kickstart installation that is defined. Each stanza specifies different files for the vmlinuz, initrd.img and the location and name of the kickstart file to be used. Console parameters are also specified in the PXE Boot configuration file because we use the console to make the menu choice for the desired kickstart and to monitor the installation.

We also added the statement ksdevice=eth0 to the append line. This prevents manual intervention to choose the install NIC when more than one NIC is present. This information was also very hard to find.

This file also contains the definitions of the various menu options we want the Anaconda installer to provide, as well as the Function Key definitions for various help options. The menu options are created by Anaconda using the labels in each stanza. So the menu choices we have are 1, 2 and 3. Note that option 1 is local boot from the hard drive and that the “default 1” line specifies that the system will boot to the hard drive after the timeout. The “timeout 200” line specifies the length of the timeout in tenths of a second. This is a strange unit, but the value of 200 results in a timeout of twenty seconds.

The data to generate and display the menu itself is located in the file /tftpboot/RHEL/msgs/Main.msg. Separating the files that specify the options from the file that displays the available options allows us to define hidden options should we need to do that.

#######################################################################

       09Welcome to 0cThe Cisco Linux09 Installer!07
0a
                            |       |
                        . | | | . | | | .
                            '       '
                            C I S C O
07

Enter number of the Linux distribution you wish to install:

1. Cisco CEL 4
2. Red Hat Enterprise Linux MIN (Test)
3. Red Hat Enterprise Linux MAX (DEV test)

05[F1-Main] [F2-General] [F3-Expert] [F4-Kernel] [F5-Rescue]07

#######################################################################

Listing 4: The file /tftpboot/RHEL/msgs/Main.msg

You’ll see that Listing 4 contains the menu for the Anaconda installer. We have added our own options to the menu.

Cisco Core router configuration

The DHCP and TFTP protocols both use UDP rather then TCP packets. Most UDP packets are not forwarded across subnet boundaries and we have many different subnets in our network. Many Cisco routers with current versions of IOS have the ability to configure helper addresses for UDP packets. This enables the router to forward UDP packets to the DHCP and TFTP servers or to specific subnet(s).

Based on our experience, you should only configure this on the core router closest to your server.

#######################################################################
ip forward-protocol udp
!
interface ethernet 1
 ip helper-address 10.44.23.7
interface ethernet 2
 ip helper-address 192.168.1.19
#######################################################################

Listing 5. Sample Configuration

You’ll find a sample configuration from the Cisco IOS IP Configuration Guide, Release 12.2, in Listing 5 that provides an example of the commands required to set up a helper address.

If a protocol is not specified on your router, the helper address will forward all UDP packets to your kickstart server. If this is not what you want, be sure to specify only those protocols that need to be forwarded. This is another piece of information that was very hard to locate. Refer to the Cisco IOS IP Configuration Guide, Release 12.2, for details of this and related commands.

This will not be an issue if your DHCP and TFTP servers are located in the same subnet as all of the hosts you wish to kickstart.

Web Server (Apache) configuration

We chose Apache for our web server because it is supplied by all Red Hat distributions and because we use it on other internal servers so are familiar with its operation. Once you have Apache installed and running, nothing else needs to be done to the configuration to make it work for kickstarts. All you have to do is place the files in a location that is served by Apache.

Because we wanted our server to be as flexible as possible, we decided to plan for the eventuality that we would eventually support both FTP and HTTP kickstarts even though we are only using HTTP at this time. Therefore we chose a directory structure starting at /var/ftp/pub and created a symbolic link to this location from /var/www/html.

ln -s /var/ftp/pub /var/www/html/pub

Making the RPMs Available

While we wanted to make the ISO images of RHEL 5.1 available for download so that users can burn their own installation DVDs, it is also necessary to make the RPMs located in the ISO images available for the kickstarts. In order to accomplish this without having to store the files on the hard drive twice, we chose to keep only the ISO images on the hard drive and mount them using the loopback device to make the individual files in the ISO available to the kickstart.

To accomplish this, the following directories were created.

   /var/ftp/pub/rhel/5.1/isos/i386/
   /var/ftp/pub/rhel/5.1/os

The iso images for RHEL 5.1 client and server were copied to the /var/ftp/pub/rhel/5.1/isos/i386 directory. The following entries were added to /etc/fstab to mount the ISOs automatically at boot time.

#######################################################################
/var/ftp/pub/rhel/5.1/isos/i386/rhel-5.1-client-i386-dvd.iso \
        /var/ftp/pub/rhel/5.1/os/i386/workstation iso9660 \
        loop=/dev/loop1,ro  0 0

/var/ftp/pub/rhel/5.1/isos/i386/rhel-5.1-server-i386-dvd.iso \
        /var/ftp/pub/rhel/5.1/os/i386/server \
        iso9660 loop=/dev/loop2,ro  0 0
#######################################################################

Listing 6: /etc/fstab

The entries in Listing 6 for /etc/fstab mount the ISO images so that the files in the images can be available for the kickstarts.

Note that we chose to use the loop1 and loop2 devices instead of the loop0 device so that the loop0 device would be available to anyone wanting to use a loopback.

The Kickstart Configuration File

The kickstart configuration file, by default named ks.cfg, is used by Anaconda to define the parameters of the installation. This file provides the answers to all of the questions and entries to all of the fields required by the installation process. Only by having answers to each and every question can the kickstart be fully automated. If any of the required fields does not have an entry the installation halts and waits for input.

Creating the Starting ks.cfg File

We initially created the kickstart file using the kickstart GUI configurator. Using this configurator allowed selection of the major software groups to be installed. There are other ways to obtain a kickstart configuration file to use as a starting point. Each time Red Hat Linux is installed, a kickstart configuration is stored at /root/anaconda-ks.cfg. This file can be used to exactly recreate the installation as it was performed. You could generate a kickstart file by performing a manual installation with the exact configuration you want and then use the anaconda-ks.cfg file generated as the starting point.

We renamed our kickstart files from anaconda-ks.cfg to something more meaningful, rhel-AP-Max-ks.cfg, and rhel-AP-Min-ks.cfg. This enables us to know from the names which type of installation the file is for, and also to keep multiple files in the same directory.

The kickstart configuration files have several sections. Each section has statements pertaining to a specific portion of the installation. Some sections are optional.

We did not use the %pre section which allows running scripts before the installation begins, so we will start with the command section. Most of this should be relatively self-explanatory, but if you need more information on any portion, the Red Hat Enterprise Linux Installation Guide (see Resources) contains an excellent description of each section of a kickstart file and describes each of the possible statements and commands that can be used. For the sake of brevity we will only discuss certain key portions of our kickstart file.

#######################################################################
# This is an installation not an upgrade
install
# The location of the RPM files
url --url http://emstools2b.cisco.com/pub/rhel/server
key 9a09007d99b6cd00
lang en_US
# Use text mode install
text
keyboard us
xconfig --defaultdesktop kde --resolution 640x480 --depth 8
network --device eth0 --bootproto dhcp --onboot=on
rootpw --iscrypted $1$tihTg7ne$hohhkj87hGGddg9B4WkXV1
authconfig --useshadow --enablemd5
selinux --disabled
timezone America/New_York
firewall --disabled
firstboot --disable
# Reboot after installation
reboot
bootloader --location=mbr --append="console=ttyS0,9600n8"
clearpart --all --initlabel

# define partitions
part /boot --fstype ext3 --size=512
part /opt --fstype ext3 --size=10000 --grow
part /usr --fstype ext3 --size=10000
part /tmp --fstype ext3 --size=7500
part /var --fstype ext3 --size=7500
part /home --fstype ext3 --size=2500
part swap --size=2048
part / --fstype ext3 --size=2048
part /usr/local --fstype ext3 --size=2000

#######################################################################

Listing 7: The command section of our kickstart file.

We added a key line to this section. This is what Red Hat calls the Installation number and is required to enable all Linux functionality. Just what would not be enabled is not specified. If the key line is not included in the kickstart files, the installation stops and waits for input which is not what we want.

We specified a text mode install because, as mentioned before, we need to use the console for installation and a graphical installation would not work for us.

We specified our console parameters in the “bootloader” line to ensure that they matched those of our console servers.

Due to issues we had with creating LVMs using kickstart, we only created EXT3 partitions, not Logical Volumes. We intend to revisit this and determine whether Logical Volumes can be used. It may be that, because our procedures are to simply re-kickstart systems that have any significant issues, such an effort would be more trouble than it is worth.

The %packages section of our kickstart file defines which groups are installed. These are the names preceeded by an “@” sign. Individual RPM packages can also be specified just by placing the appropriate package name on a line by itself in this section.

You can specify RPM packages that are not to be installed even if they are part of a group that you otherwise need to install. These RPMs are specified on a line by themselves but are preceeded by a “-” sign.

#######################################################################
%packages
@engineering-and-scientific
@mysql
@development-libs
@editors
@system-tools
@gnome-software-development
@text-internet
@gnome-desktop
@core
@base
@ftp-server
@network-server
@legacy-software-development
@java-development
@printing
@kde-desktop
@mail-server
@server-cfg
@sql-server
@admin-tools
@development-tools
@graphical-internet
festival
audit
kexec-tools
bridge-utils
device-mapper-multipath
dnsmasq
imake
-sysreport
mc
festival
audit
libgnome-java
libgtk-java
libgconf-java
kexec-tools
xorg-x11-server-Xnest
xorg-x11-server-Xvfb
-compiz-kde
-knetworkmanager
-amarok
#######################################################################

Listing 8: The %packages section of the kickstart file defines the groups and packages to install.

Using Post-installation scripts

We invested a great deal of effort developing the post-install scripts defined in the %post section of the kickstart configuration file. These scripts allow us to perform installation and configuration of RPMs and tarballs that are not part of the Red Hat installation.

The important thing to remember about the post-installation scripts is that they are executed using the bash command interpreter in a chroot’ed environment that behaves as it will when rebooted after the installation. This allows virtually any action that you could possibly work into a script to be performed during the final stages of installation.

#######################################################################
%post
# Install the yum repository configuration files
cd /tmp
wget http://emstools2b.cisco.com/pub/local/lab-repos.tar
cd /
tar -xvf /tmp/lab-repos.tar

# Set an ID to be used for other scripts
touch /LINUX_RHEL_MINIMAL_INSTALL

# Install Kshell as a preference of some developers.
yum -y install ksh

# Configure some local NFS mount points
service portmap start
mount  emsnfs:/export/linux/post   /mnt
cat /mnt/auto_localnfs >> /etc/auto.misc
cat /mnt/auto_misc >> /etc/auto.misc

# Get the command to create the motd and create it for the first time.
cp /mnt/createMOTDLinux /etc/init.d/create_motd
mv /etc/motd /etc/motd.orig
/etc/init.d/create_motd > /etc/motd

umount /mnt

# Create symlinks for mount points
# the links to /localnfs are to work around the issue with Linux
# mount points not being browsable as they are in Unix
mkdir /localnfs
ln -s /misc/apps       /localnfs/apps
ln -s /misc/rtp-chaos  /localnfs/rtp-chaos
ln -s /misc/black-hole /localnfs/black-hole
ln -s /misc/tools      /localnfs/tools
ln -s /misc/tftpboot   /localnfs/tftpboot
mkdir /opt/scratch
ln -s /opt/scratch /scratch

# Create ssh authorized keys
# Make the directory
mkdir /root/.ssh

# Create the keys file
cat  << xxEOFxx >> /root/.ssh/authorized_keys
sh-dss AAAAB3NzaC1kc3MAAACBAKyW6vv6uHKGKL54765VBHKJHhbfvfhJ/rkspGK2pmAM7awj7EwB
/wUBZUucmQSYnyaOlbvS6NkdE+sUC/asU/mEZjzoQgP+kdahxfJvWATaJweVFjRdHrIZxPB4nlO+MEBb
cPmUP7cLLQ1KGbfUakr35qzb9RjpBPDcBSDW2GZRAAAAFQCD/qw8FCSfEyWAmtkXDioJBWUCOwAAAIAm
4czfxx+Srm7FxGDTsiL52ojKzZCzddTi6YclknBXYpa3jhjhDfgkbGfHc746cVXm3hJ9ZgA3RQpMypKn
WS6EHimjkjEeqfw/viqPR1NCvj1xVs9XDjRtCelwsxUNj31Y2RHCsusa6DDwG765bnlk/BO4lUGRQpNy
QAAjKyDhPwAAAIAPJQcSf0tc4OrqNxy/gjkhkhgghfTRerthkljhGuyKarrmWan9ZkkFJQYnp09GNasZ
zI7Zwau3oqfutPTWJFehBskFKvRpSjYd59vKjWpDyCE5xHYxZfDORTj4pzjRSyiXDP/viA5DBCUWieM4
zGWa1RKVdskjPFS56y5GAkEwcA== root@emsjumpsssh-dss AAAAB3NzaC1kc3MAAACBAOqZBr62GU
La+NwGUatvO7OVXqGDn4qXvR2GAUputz9uyYmcWTvoHG0D3eAQ2flqhpyhJQo63GyntUtmGkXIHFuM3z
4qDt19qcpFRj10ZzRbZGhf+QbJwkxA9fpOy/BmoYykW5l36Db/Dvlzk4zNgJAmGXb2rNv8RSqYC6kCZf
aNAAAAFQDTb8EsksyknY++4zXC3TPNrH/+MwAAAIEAz3OCUfZXo+e/lJ/KSFj1un378KGGo9qfGSpVMV
Tva/z58KAZ174tJpgnfA8+fQOwq/ip8s9UyHA2qR+BICjjZo1KatevFN7l4rpNSqdLivEasrGBu6fRTP
/kQ6vt+OLIAQyr8t9RqpZKUVdd9odFA9NLiuOhG//eh2cDSXmjFnkAAACAbgzdEMcCMeMT/XPJrkZ/md
TX/EJ6VNQEuTP3fhrjKKjccYobXPOQhvliIhPGFbtrRZlYRPPFAkAAse0qRPOsy8XHKD18WnQr5JNJx+
C5PYMkb8APY55Ydwwrt4EFeqnFpF3RXFhPY1eiZNAI33GopEGVTiLTO4ZW9mYC8EI7e28= root@emstools
xxEOFxx

# Copy the logbanner and change sshd_config
cat  << xxEOFxx >> /etc/LogBanner
                               WARNING!!!
                   READ THIS BEFORE ATTEMPTING TO LOGON                      

     This System is for the use of authorized users only.  Individuals
     using this computer without authority, or in excess of their
     authority, are subject to having all of their activities on this
     system monitored and recorded by system personnel.  In the course
     of monitoring individuals improperly using this system, or in the
     course of system maintenance, the activities of authorized users
     may also be monitored.  Anyone using this system expressly
     consents to such monitoring and is advised that if such
     monitoring reveals possible criminal activity, system personnel
     may provide the evidence of such monitoring to law enforcement
     officials.                                                              

     Cisco Acceptable Use Policy:
     http://wwwin.cisco.com/infosec/policies/acceptable_use.shtml
xxEOFxx

echo "Banner /etc/LogBanner" >> /etc/ssh/sshd_config

#######################################################################

Listing 9: Post-installation Script Example

You’ll see that Listing 9 contains a partial listing of our post-installation script which installs both RPMs and tarballs designed for our unique lab environment as well as performing other necessary tasks.

As you can see, our post-installation is quite extensive. In addition to performing installations of several software packages we require, it also sets up a login banner, creates the /root/.ssh directory and copies some public keys there. We have only shown one of these keys to save space.

Notice that we can also start services as in the line service portmap start and access files on NFS mounts during this last portion of the kickstart. Post-installation provides a very flexible environment for performing a great many automated tasks.

Perform the kickstart

Performing the kickstart is very easy because we have done all of the hard work in setting up the network kickstart. We have four basic steps to perform.

1. Add the computer to DNS.
2. Add the appropriate information to the dchpd.conf file.
3. Boot the computer.
4. Select the desired kickstart from the menu.

The automated kickstart does the rest. The first two steps only need to be performed the first time a computer is kickstarted; after that the DNS and DHCP information will already be there.

Troubleshooting a failing Kickstart

The most common problems with network kickstarts the way we have set it up are network failures, MAC addresses that are incorrectly entered in the dhcpd.conf file, using the MAC address for the wrong NIC. These problems will present themselves on the console with messages from PXE Boot on the NIC unable to obtain an IP address.

An incorrectly named hexadecimal IP address file for a system or a problem with the TFTP server will allow the NIC to obtain the network data, but fails to load the PXE Boot configuration file for the system. Be sure your TFTP server is configured correctly using the tftp file in the /etc/xinetd.d directory.