University Computing Systems

Systems Administration - Linux Kickstart Installation Guide

The purpose of this document is to outline the UCS kickstart and linux setup
procedures.  Since kickstart is always being improved upon, this document will 
continue to evolve so as to reflect the changes made to the linux kickstart 
configuration.

This document is made up of the following sections:

Introduction to kickstart
Kickstarting a linux machine using the UCS kickstart
Files used by the UCS kickstart process
Kernel Upgrades


Introduction to kickstart
Just like Sun’s jumpstart which is used to automate the installations of
Solaris machines, RedHat’s kickstart can be used for unintended
installations of Linux machines.  

The kickstart process is made possible by Anaconda, The RedHat System Installer 
which allows installs to be either interactive or scripted (kickstart).

All of the packages to be installed including layout of the system disk,
and swap size, are configured inside of the kickstart configuration file,
which by default is named ks.cfg, however, it is possible to change the name of
this file.  For details, see Files used by the UCS kickstart process.

For a complete description of the kickstart process, see The official Red Hat 
kickstart documentation 


Kickstarting a linux machine using the UCS kickstart
This section describes the process of kickstarting a UCS linux machine.

The first step is to obtain the MAC address of the machine’s
primary Network Interface Card.   The easiest way of obtaining the MAC address 
is to use the standard UCS kickstart boot CD to boot into a holographic shell.

First, insert the UCS kickstart CD into the CD-drive.  At the prompt, type :

		desktop rescue

The installer will begin to initialize the system and begin to load any
needed device drivers, and a DHCP request will be sent for an IP address.  
Once an address is obtained, Anaconda will start rescue mode and a dialog 
box will be presented indicating that rescue mode is about to attempt to 
mount the current linux installation.  On this screen, select Alt+F2 which 
will invoke a shell prompt.  

At the shell prompt type the following command :

		ifconfig eth0 

The above command will display information for the primary network interface,
eth0 including the MAC address.  The MAC address is indicated as HWaddr.

An alternative method is to boot the machine with a knoppix Live CD 
and issue an ’ifconfig eth0’ from a shell prompt.  

Once the MAC address has been obtained, it needs to be added to the
maciptable.  The maciptable is used by the kickstart post install scripts to
configure the machine’s hostname and network information.  The maciptable
is also used to determine the kickstart group the machine belongs to.  
For more information on this file, see Files used by the UCS kickstart process 


The maciptable is :

	/afs/cad/linux/admin/install/maciptable


The maciptable has the following format :

	MAC Address		IP Address 	Gateway		Group

In addition to the MAC address, and IP, gateway and group information is also needed. 
It is important that the group be set to a valid kickstart group otherwise the
kickstart process will not complete successfully.  Valid kickstart groups are
located in /afs/cad/linux/admin and begin with a "KS", e.g., KS.dms_faculty 

Currently, no script exists to create new kickstart groups.  If a new group is
desired, copy an existing group directory and modify it accordingly.

After an entry has been added to the maciptable for the machine that is to be
installed, a boot CD is required to initiate the kickstart process.  

A boot CD can be made from the UCS kickstart boot images which are located in AFS.  

The location for these images is :

	/afs/cad/linux/admin/install/BOOT/iso_boot_images

The above directory contains images for both RHEL 3.0 and RHEL 4.0.  There are 
also images for both x86 and x64 platforms for both RHEL versions.

Choose the image that matches the platform and version of RHEL that is being
installed.  

NOTE:  It is possible to install RHEL x86 on an x64 platform, but the OS will
not be able to take advantage of the 64-bit capabilities of the machine’s
architecture.  It is suggested to always install the 64-bit version of RHEL on
machines that support it.

After the proper boot image has been identified, the image should be
burned to a CD.  This document assumes the reader is already familiar with the
process used to create CDs from ISO images and so the steps for creating a boot
CD will not be covered in this document.

After the boot CD has been created, the kickstart process can begin.  The
system should be connected to a DHCP port as the kickstart process uses DHCP 
for installation.  

The system can now be booted using the newly created boot CD.  The boot process
will load isolinux and display the UCS modified welcome screen.  Pressing enter 
will install a desktop system, typing "server" (without quotes) will install a 
server based system.

The distinction between a DESKTOP and SERVER relate to the number and type
of packages which get installed.  A server configuration does not install
a windowing system.  Also, additional services are disabled for servers.   It
is important to note that DESKTOP and SERVER do not refer to the various RedHat
Enterprise distributions, but are based on the number of packages added to the
system and on customizations which are done.   

For complete details on the different customizations done for DESKTOPS vs
SERVERS, please see the group.customize.sh script.

It is possible to create different profiles.  Instead of using the generic UCS
desktop or server profile, a custom profile containing a custom list of packages, disk
partition layout, etc, may be used by issuing the following command at the 
installation prompt :

	desktop text ks=nfs:viridian:/jumpstart/linux/kickstart/profiles/PROFILENAME.cfg

where PROFILENAME = the name of the profile you wish to use.

Note: If the installer identifies more than one network card in the system, 
you will need to tell linux what card to use for installation.  Always select the
primary Network Interface Card (eth0) for the install process.

If everything went OK, a message should soon appear that anaconda is starting.
The machine should begin to identify hardware components such as video, hard disk and
media controllers, and prepares the disks for installation.  The disk partitions
will be created and package installation will being.  Once the installation 
is underway remember to remove the boot CD from the system’s CDROM drive; failure 
to remove the boot CD will result in the system cycling the install process. 

The installation time for new x64 machines is about an hour, which includes the
time to update the machine with the latest patches.  Older systems, can take up
to two hours to complete the install process.

After the installation has finished, the system should be connected to a
network port where it can obtain a static network address and rebooted.  If the
installation process was successful, the system should come up with the address
specified in the maciptable.  At this point it is a good idea to CHANGE the
root password.



Files used by the UCS kickstart process

This section attempts to describe the UCS kickstart mechanism and each of the files
it depends on.  This section provides only a brief summary of what each
script’s purpose is, for an overall understanding of what each script does,  
please look at each individual script.

 Kickstart Configuration File (ks.cfg) 

	The ks.cfg file is the kickstart configuration file that is used by the
	kickstart installation process.  This file can be named anything, but 
	the standard naming convention in use for the UCS profiles used by
	the desktop and server configuration is as follows :

			rh<ver><type><plat>.cfg

			 ver = version of RHEL, such as 3,4 or 5
			type = either desktop, server or hpc (for warewulf clusters)
			plat = the platform is either x86 or 64

 	The first section of the kickstart configuration file describes the locale 
	settings such as language, keyboard and timezone.   
 
 	There are also %pre and %post sections contained within the configuration
 	file.  The %pre section is used in all UCS kickstart configuration files to
 	specify partition information for the system disk.  The %post section is
	used to identify the system as either a DESKTOP or SERVER and then calls the
	ks-post_install script which is located on viridian in :

		/jumpstart/linux/kickstart/scripts

	The UCS profile files are located on viridian in :

		/jumpstart/linux/kickstart/profiles

 	Please refer to the official Red Hat kickstart documentation for complete details 
	and a more complete explanation on the ks.cfg (kickstart configuration file).

 ks-post_install
 
	The system clock is synced with the hardware clock and then ks-post_install 
	calls the AFS installation script :

		viridian:/jumpstart/linux/kickstart/scripts/install.afs.client.linux.ksh

	The ks-post-install script is located on viridian in :

		/jumpstart/linux/kickstart/scripts

 linux-post-install

	This script makes customizations that are common to both DESKTOP and SERVER
	profiles.  UCS staff and crontabs are also added via the linux-post-install
	script.  System software such as SSH and sendmail are installed and
	configured.  

	The following scripts are then called :
	
		- group.customize.sh 
		- call.bootstrap.sh
		- linux-post-install-stage2

	The group.customize.sh script makes customizations that are specific to
	both DESKTOP and SERVER installations.  This script is described in more 
	detail in the next section.

	The call.bootstrap.sh script is used to register the machine on the RHN 
	and patch the system via up2date.  It is located in :

		/afs/cad/linux/admin/install/scripts/KS

	More details on up2date are located in the section on Patching with up2date

	The linux-post-install script is located on viridian in :

		/jumpstart/linux/kickstart/scripts

 group.customize.sh

	As stated in the previous section, this script is used to make specific
	customizations based on whether the machine is a DESKTOP or SERVER.  For
	DESKTOP installations, the script makes modifications to the KDE desktop
	environment and creates the various terminal profiles for gnome-terminal.
	For SERVER installations, the script turns off unneeded services and enables
	console access on ttyS0 which is needed for concentrator access to the
	machine.

	Finally, /afs/cad/linux/scripts/KS/linux-post-install-stage2 is copied
	to /etc/rc.d/rc.local and the machine is rebooted.

  The group.customize.sh script is located in afs :

		/afs/cad/linux/admin/install/scripts/KS/group.customize.sh

 linux-post-install-stage2

	For DESKTOP systems, this script calls :
	
		/afs/cad/linux/admin/install/scripts/KS/install.display.sh

	which attempts to identify the display card and install the proprietary
	display driver.  The install.display.sh script currently knows about Nvidia
	and a few ATI cards.

	The script then calls :

	/afs/cad/linux/admin/install/scripts/set.hostname.sh
	which sets the static hostname and IP address for the machine according to 
	the one listed in the maciptable.

	Finally, finishup.sh is called.

 finishup.sh

	This script removes temporary mount points and initiates a final reboot.

	The finishup.sh script is located in afs :

		/afs/cad/linux/admin/install/scripts/KS/finishup.sh


Kernel Upgrades

Before an updated linux kernel can be installed on any UCS linux system, a new
AFS kernel module needs to be built against the updated kernel.  Please see 
This Document for detailed instructions on how to build AFS kernel modules.

Once the corresponding AFS kernel modules have been built, the updated kernel
rpms should be placed in the following AFS directory :

	/afs/cad/linux/admin/install/<KERNEL>/<PLATFORM>/<RHEL_VERSION>/<KERNEL_VERSION>

A symlink named CURRENT should be put in place which points to the
KERNEL_VERSION which is to be used as the most current version.

e.g., 

	ln -s 2.6.9-42.0.10.EL CURRENT
	ls -l CURRENT
	lrwxr-xr-x    1 andym    30             16 2007-05-10 16:51 CURRENT -> 2.6.9-42.0.10.EL/

The update.kernel.sh script can then be used to perform the actual kernel
update.  The script will install the updated kernel along with updated kernel
modules as well as a new kernel module for the Nvidia display driver.

The update.kernel.sh script is called from call.bootstrap.sh which itself is
called from the linux-post-install script.  When calling the update.kernel.sh
directly, i.e., on a machine which has already been installed, it is import to
call the script with the -d switch, which will rebuild the kernel modules for 
the display driver.  If -d is not specified, the windowing system will not be
able to be started since the display driver will not be able to load.


Patching with up2date

During the kickstart process each system is registered on the RHN via the
call.bootstrap.sh script.  All UCS linux systems have the following line in
root’s crontab :

05 2 * * *         /afs/cad/linux/admin/bin/up2date.sh -u

This script runs the up2date process and logs a report for each host.