Certification Objective 5.05-Using Kickstart to Automate Installation

Kickstart is Red Hat's solution for an automated installation of Red Hat. All the questions asked during setup can be automatically supplied with one text file. You can easily set up nearly identical systems very quickly. Kickstart files are useful for quick deployment and distribution of Linux systems.

Inside the Exam

Kickstart and the Red Hat Exams

For the Troubleshooting and System Maintenance portion of the exam, it's possible that the exam proctor might configure your computer using a customized kickstart configuration file. (It's possible that she might use another method such as a VMware snapshot.) The file might be local or it might be stored on the server. Understanding kickstart is a very useful skill that can help you install Linux on a number of different computers simultaneously. You can start the process and walk away. The options are rich and varied. The Red Hat Exam Prep guide suggests that you know how to configure "hands-free installation using Kickstart."

Whether or not you see kickstart labs on your exam, understanding how it works is an important administrative skill that I think Red Hat should include on its exams. You can check the bug status for yourself at https://bugzilla.redhat.com.

Kickstart Concepts

There are two methods for creating the required kickstart configuration file:

• Start with the anaconda-ks.cfg file from the root user's home directory, /root.

• Use the graphical Kickstart Configurator, accessible via the system-config-kickstart command.

The first option lets you use the kickstart template file created for your computer by Anaconda, the Red Hat Enterprise Linux installation program. The second option, the Kickstart Configurator, is discussed in detail later in this chapter.

If you're installing RHEL on a number of computers, the anaconda-ks.cfg file is handy. You can install RHEL the way you want on one computer. You can then use the anaconda-ks.cfg file from that computer as a template to install RHEL on the other identical computers on your network. If the computers aren't identical, you can customize each anaconda-ks.cfg file as required for elements such as a different hard disk size, host name, and so on.

Setting Up a Kickstart USB

Once the kickstart file is configured, the easiest way to use it is through the RHEL installation USB drive. Similar steps can be used if your system has a floppy drive. To do so, follow these basic steps:

1. Configure and edit the anaconda-ks.cfg file as desired. I'll describe this process in more detail shortly.

2. Insert and mount the image file for an installation boot CD or USB drive. These options are described in more detail in Chapter 2. If the drive doesn't mount automatically, you can then mount the drive with a command such as mount /dev/cdrom /mnt.

3. If you mounted a CD, insert a USB drive. Find the associated device with the fdisk -l command. Make a note of the device, such as /dev/sdb. You'll need it shortly.

4. If it doesn't mount automatically (as it should if you're in the GNOME desktop), mount it with a command such as mount /dev/sdb /net.

5. Copy the kickstart file to the top level directory of the USB drive. Make sure the file name on the USB drive is ks.cfg.

6. You should now be ready to try out the installation boot USB on a different computer. You'll get to try this again shortly in an exercise.

7. When you try the boot USB, you can start the kickstart installation from the aforementioned USB drive, possibly with the following command (some trial and error may be required):

    boot: linux ks=hd:sdb1:/ks.cfg 

   Alternatively, if the kickstart file is on the boot CD, try

    boot: linux ks=cdrom:/ks.cfg 

   Or if it's on the first floppy drive, try

    boot: linux ks=hd:fd0:/ks.cfg 

   As long as you have a DHCP server on your network, you may be able to use the same USB key or even a 1.44MB floppy drive. Just boot each new Linux computer, type in the associated command such as linux ks=floppy at the boot prompt, give the computer a moment to read the ks.cfg file, and insert the same device in the next new Linux computer.

Configuring a Kickstart Server

Alternatively, you can configure a kickstart configuration file on the DHCP/BOOTP server for your network. If you want to put the file on a DHCP/BOOTP server, open the /etc/dhcpd.conf configuration file on that server. Specify the kickstart file. For example, if you've stored the appropriate kickstart file in the /usr/install directory on the DHCP server, add the filename "/usr/install/" command to dhcpd.conf. That prompts Anaconda to look on the server in the /usr/install directory for a client_ip-kickstart file, where the assigned IP address is substituted for client_ip.

For example, if the DHCP server assigns IP address 192.168.0.55, the installation looks for the kickstart file named 192.168.0.55-kickstart. If necessary, you can associate a specific IP address with a certain network card in the DHCP configuration file, as described in Chapter 13.

If the kickstart file is stored on a different server, add the next-server servername option to the dhcpd.conf configuration file. In this case, the servername is the name of the computer with the kickstart file.

On the Job 

Red Hat is working on making it easier to create a kickstart-based installation server. For more information, see the Cobbler project at http://cobbler.et.redhat.com/.

Starting the Installation with a Kickstart File

No matter where you choose to put the kickstart file, you can boot with a USB key or a specialized installation CD. You can put the kickstart file on the boot media. Just copy the configuration file as ks.cfg from wherever you've saved your kickstart configuration file.

If you're booting from a CD, and the kickstart file is also on that CD, enter the following command at the boot: prompt. This assumes the ks.cfg file is in the top level directory of the CD.

 boot: linux ks=cdrom:/ks.cfg 

If you're booting from the Red Hat installation CD, you can still refer to a kickstart configuration file on a USB key or hard disk, respectively, possibly with one of the following commands:

 boot: linux ks=hd:sdb:/ks.cfg boot: linux ks=hd:hda2:/home/mj/ks.cfg 

This assumes the kickstart configuration file is called ks.cfg and is located on the USB key detected as /dev/sdb, or the second partition of the first IDE drive in the /home/mj directory.

You don't need to get a kickstart file from a DHCP server. To boot from a specific NFS or HTTP server on the network, say with an IP address of 192.168.17.18, from the /kicks/ks.cfg file, type one of the following commands:

 boot: linux ks=nfs:192.168.17.18:/kicks/ks.cfg boot: linux ks=http:192.168.17.18:/kicks/ks.cfg 

However, even if you've specified a static IP address in ks.cfg, this installation looks for IP address information from a DHCP server. If the information is not found, Anaconda continues with a standard installation, not using the kickstart file.

Sample Kickstart File

I've based this section on the anaconda-ks.cfg file created when I installed my RHEL Server. I've added a number of comments. While you're welcome to use it as a sample file, be sure to customize it for your hardware and network. This section just scratches the surface on what you can do with a kickstart file; your version of this file may vary.

While most of the options are self-explanatory, I've interspersed my explanation of each command within the file. This file illustrates just a small portion of available commands. For more information on each command (and options) in this file, read the latest RHEL System Administration Guide, which is available online at www.redhat.com/docs/manuals/enterprise.

Follow these ground rules and guidelines when setting up a kickstart file:

• Do not change the order of the options.

• You do not need to use all the options.

• If you leave out a required option, the user will be prompted for the answer.

On the Job 

If you leave out an option, you will be prompted to complete it. This is an easy way to see if your kickstart file is properly configured. But as some kickstart options change the partitions on your hard drive, even testing this file can delete all of the data on your computer. So it's safest to have a test computer (with no important data) such as a Xen or VMware machine available to test your kickstart configuration file.

Here is the code from my kickstart file. The first line is a comment that tells me that this file was created during the installation process:

 # Kickstart file automatically generated by anaconda. 

The first command is simple; it starts the installation process. It defaults to the first available local media; in this case, the first RHEL installation DVD/CD or USB key.

 install 

However, if you want to specify an installation, you could add the source of your choice on the next line. It could be cdrom, or if you're installing from an NFS server, you can specify it as follows. If you have the name of the server (and a reliable DNS), you can substitute it for the IP address.

 nfs --server=192.168.0.4 --dir=/inst 

You can also configure a connection to an FTP or HTTP server by substituting one of the commands shown here. The directories I specify are based on the FTP and HTTP installation servers created in Chapter 2:

 url --url http://192.168.0.4/inst 

or

 url --url ftp://192.168.0.4/pub/inst 

If the installation files (or even the ISOs) are on a local hard drive, you can specify that as well. For example, when I downloaded the RHEL CDs to my home directory on the /dev/sda10 drive and installed on a separate partition, it added the following directive to my anaconda-ks.cfg file:

 harddrive --partition=/dev/sda10 --dir=/home/michael/ 

The lang command specifies the language to use during the installation process. It matters if the installation stops due to a missing command in this file. The keyboard command is self-explanatory, as it specifies the keyboard to configure on this computer.

 lang en_US.UTF-8 keyboard us 

The network command is a lot more straightforward if you have a DHCP server for your network; it would read network --device eth0 --bootproto dhcp. This particular line configures static IP address information, with the specified network mask (--netmask), gateway address (--gateway), DNS servers (--nameserver), and computer name (--hostname).

 network --device eth0 --bootproto static --ip 192.168.0.44 --netmask 255.255.255.0 --gateway 192.168.0.1 --nameserver 192.168.0.1 --hostname enterprise5 

Please note that all options for the network command must be on one line. Line wrapping, if the options exceed the space in your editor, is acceptable.

The xconfig command specifies the graphical configuration for this system. The switches are nearly self-explanatory. The --driver switch specifies the graphics card driver. The --resolution switch sets the default resolution for the monitor, with a given color --depth in bits. If you see --startxonboot, the system starts the GUI by default when you boot Linux.

 xconfig --driver "i810" --resolution 800x600 --depth 24 

You need to specify the root user password during the installation process. This line specifies the password in encrypted format. You don't have to encrypt the root password in this line. If needed, you can copy this password from /etc/shadow.

 rootpw --iscrypted $1$5UrLfXTk$CsCW0nQytrUuvycuLT317/ 

As for security, the firewall is either --enabled or --disabled. If a port is to be open, it's also specified on this line; for example, --port=22:tcp specifies an open SSH port.

 firewall --enabled 

Open by default, the authconfig command sets up the Shadow Password Suite (--enableshadow) and MD5 encryption (--enablemd5).

 authconfig --enableshadow --enablemd5 

The selinux command can be set to --enforcing, --permissive, or --disabled.

 selinux --enforcing 

The timezone command is associated with a long list of timezones. If you've installed the SquirrelMail RPM, you can find a full list in /usr/share/squirrelmail/ locale/timezones.cfg. If you want to set the hardware clock to the equivalent of Greenwich Mean Time, add the --utc switch.

 timezone America/Los_Angeles 

The default bootloader is GRUB. Naturally, it should normally be installed on the Master Boot Record (MBR) of a hard drive. You can include a --driveorder switch to specify the drive with the bootloader and an --append switch to specify commands for the kernel.

 bootloader --location=mbr --driveorder=sda --append="rhgb quiet" # 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 #clearpart --linux --drives=sda #part /boot --fstype ext3 --size=100 --ondisk=sda #part raid.53 --size=1000 #part raid.51 --size=1000 #part raid.49 --size=1000 #part raid.45 --size=1000 #part raid.43 --size=1000 #part raid.41 --size=1000 #part raid.39 --size=1000 #part raid.37 --size=1000 #part raid.35 --size=1000 #part pv.25 --size=0 --grow --ondisk=sda #raid /tmp --fstype ext3 --level=RAID6 --device=md0    raid.45 raid.43 raid.41 raid.37 raid.35 #volgroup VolGroup00 --noformat --pesize=32768 pv.25 #logvol swap --fstype swap --name=LogVol01    --vgname=VolGroup00 --size=960 --grow --maxsize=1920 #logvol /home --fstype ext3 --name=LogVol02    --vgname=VolGroup00 --size=4992 #logvol / --fstype ext3 --name=LogVol00    --vgname=VolGroup00 --size=9984 #logvol /var --fstype ext3 --name=LogVol03    --vgname=VolGroup00 --size=4992 

The following is a list of package groups that are installed through this kickstart configuration file. These names correspond to the names that you can find in the comps-rhel5-server-core.xml file described in Chapter 2.

By default, the commands that partition your hard drives are commented out of the anaconda-ks.cfg file. These options are a bit more complex, so I discuss them in more detail in the next section. If the commands work for you, don't forget to delete the comment character (#) to activate these commands. (Note that the directives that start with raid and logvol are line-wrapped.)

 %packages @ dialup @ system-tools 

After the package groups are installed, you can specify post-installation commands (%post) in the kickstart installation file:

 %post 

Kickstart Partitioning

The partitioning options in the kickstart file are a bit complex. They can give you full control of the partitioning options, too. You can clear all partitions with clearpart --all, or just clear any Linux-type partitions with clearpart --linux, or just add partitions to existing free hard drive space. You can create partitions on more than one drive, but you need to identify each device specifically.

To add Linux partitions, use the part command with the following syntax:

 part mount_dir --size=size [--grow] [--maxsize=size] 

The size is in megabytes. You can use the --grow option to allow the partition to expand and fill all remaining disk space (or share it with any other partitions marked grow on the same disk). This will not expand on the fly, but instead, when all fixed-size partitions are added, these "growable" partitions will use the remaining free space.

If you specify multiple partitions with the --grow option, their space will be divided evenly. You can also specify a --maxsize, which will allow the partition to grow only to the size specified in megabytes.

The following commands from my kickstart configuration file (with comment characters remove) perform the following tasks.

The clearpart command removes all of the partitions on the first SATA or SCSI hard drive:

 clearpart --all --drives=sda 

This first part command configures the /boot directory to the ext3 filesystem with 100MB of space on the first SATA/SCSI hard drive:

 part /boot --fstype ext3 --size=100 --ondisk=sda 

The next several part commands specify RAID devices. The raid.53 is an arbitrary number. The --size designation is straightforward, in MB.

 #part raid.53 --size=1000 

After the RAID partitions, an LVM partition is specified as growable (--grow) on the first IDE drive:

 #part pv.25 --size=0 --grow --ondisk=hda 

Now I configure a RAID device for the /tmp directory, configured to RAID 6 (--level=RAID6), set to --device name md0, using RAID partitions raid.45, raid.43, raid.41, raid.37, and raid.35.

 #raid /tmp --fstype ext3 --level=RAID6      --device=md0 raid.45 raid.43 raid.41 raid.37 raid.35 

Next, I configure a volume group, followed by configuring logical volumes for a swap, /home, root (/), and /var partitions of the noted sizes:

 #volgroup VolGroup00 --noformat --pesize=32768 pv.25 #logvol swap --fstype swap --name=LogVol01      --vgname=VolGroup00 --size=960 --grow --maxsize=1920 #logvol /home --fstype ext3 --name=LogVol02      --vgname=VolGroup00 --size=4992 #logvol / --fstype ext3 --name=LogVol00      --vgname=VolGroup00 --size=9984 #logvol /var --fstype ext3 --name=LogVol03      --vgname=VolGroup00 --size=4992 

Alternatively, I could specify a part command for the root directory (/), formatted to the ext3 filesystem, on partition /dev/sda5. If more room is available, this partition expands to fill the available space.

 part / --fstype ext3 --onpart=sda5 

Exercise 5-2: Creating a Sample Kickstart File

In this exercise, you will use the anaconda-ks.cfg file to duplicate the installation from one computer to another with identical hardware. This exercise installs all the exact same packages with the same partition configuration on the second computer. Assume that both computers use DHCP to set up their IP addresses. To the existing partitions, add one /home partition of 2000MB and a 512MB swap partition. In other words, on the second computer, you'll need at least 2.5GB more free space than on the first computer.

You want to install all the same packages as your current installation, so you do not need to make any package changes to the default anaconda kickstart file in the /root directory. This assumes you can boot from a CD and have a USB drive. If you do not have multiple computers for this exercise, alternatives include VMware and Xen. If you don't have a USB drive, you can substitute a floppy drive.

1. Review the /root/anaconda-ks.cfg file. Copy it to ks.cfg.

2. Insert the USB key. Run the fdisk -l command to find the USB device, such as /dev/hdb. If it isn't automatically mounted, use the device file to mount it.

3. Copy the ks.cfg file to the mounted USB key.

4. Prepare the second computer so that it has at least 2.5GB more unused and unpartitioned space than the first computer. Reboot the second computer with the Linux boot file with the kickstart file in the USB key and the first binary CD (or boot CD) in the CD-ROM drive.

5. At the Red Hat Installation menu boot prompt, enter the following startup command. If the device file associated with the USB key is different, or if you're using a floppy drive, substitute accordingly.

    boot: linux ks=hd:hdb:/ks.cfg 

You should now see the system installation creating the same basic setup as the first system. The difference should correspond to the different partitions. Depending on how you installed Linux on the original computer, you may need a network connection to the same installation source or the other installation CDs.

Optional Exercise 5-3: Modifying the Packages to be Installed

Edit the ks.cfg file on the USB key and add one more package group. For a list of package group names, consult the comps-rhel5-server-core.xml file in the first installation CD's /Server/repodata subdirectory. (If you're working with the RHEL 5 desktop, substitute Client for Server.) Alternatively, set up an interactive installation so that you can test and observe the result on another computer.

On the Job 

In the KDE desktop, the default command line terminal is konsole, which has modest differences from gnome-terminal.

The Kickstart Configurator

Now that you understand the basics of what goes into a kickstart file, it's time to solidify your understanding through the graphical Kickstart Configurator. When you experiment with this GUI tool, you can learn more about what happens in the kickstart configuration file.

Inside the Exam

For Administrators from Other Unix-style Distributions

Linux is not the only operating system developed in the style of Unix. There are a number of other important Unix-style operating systems in the computing world, including, but not limited to, Solaris, HP-UX, AIX, IRIX, or even SCO UNIX. A substantial number of candidates for the Red Hat exams learn their skills on these operating systems.

The Red Hat exams test your skills on Red Hat Enterprise Linux. While many Unix skills are transferable to the exam, many features are unique to RHEL. While you can configure anything in Linux from the command line interface, Red Hat has created a number of administrative tools that you can use only in the GUI.

Based on the nature of the published Red Hat Exam Prep guide, you'll almost certainly be installing a GUI during the installation portion of the exam. When you install the GUI, you'll also have access to the tools developed by Red Hat. You can also access the command line interface in the GUI with a right-click, which opens a pop-up menu. In GNOME, you can click Open Terminal; in KDE, you can click Konsole. Alternatively, you can choose KDE Main Menu | System | Terminal or GNOME Applications | Accessories | Terminal to open the same command line interface.

You can then start the Red Hat tool of your choice from the command line; most of these utilities start with system-config-*. To see a full list, type system- at the command line and press the TAB key twice. Alternatively, from the GNOME desktop, you can start a number of these tools from the GNOME System menu (or KDE Main Menu), under the Administration submenu.

On the other hand, the GUI may not be available during the Troubleshooting and System Maintenance portion of either exam. So while the GUI tools can be helpful, you still need to know what to do from the command line interface.

If you're confident in your skills editing the Linux text configuration files, don't bother with the GUI tools. It's faster to edit Linux text configuration files directly in any Unix-style operating system. However, if you get nervous on exams or are uncertain of your skills and a GUI tool is available, learn to use the appropriate GUI tools. This can be a lifesaver during the exam.

As of this writing, I recommend that you do not use the Kickstart Configurator, at least until Package Selection is no longer disabled, as shown in Figure 5-3. I believe it's one of the problems left over in the transition from up2date to yum.

Figure 5-3: The Kickstart Configurator doesn't quite work.

To start the Kickstart Configurator, go into the Linux GUI. Open a command line interface shell. Start the Kickstart Configurator with the system-config-kickstart command. (If the command is not found, you'll need to install the RPM of the same name.) Alternatively, in the GNOME desktop, choose Applications | System Tools | Kickstart. The following sections should look familiar, as they are closely related to the RHEL installation menus.

The first screen in Figure 5-4 illustrates a number of basic installation steps. If you've installed RHEL or Red Hat Linux, all of these steps should look familiar.

Figure 5-4: The Kickstart Configurator

As you can see, a number of other options appear in the left-hand pane, each associated with different kickstart commands. To learn more about kickstart, experiment with some of these settings. Use the File | Save command to save these settings with the file name of your choice, which you can then review in a text editor. Alternatively, you can choose File | Preview to see the effect of different settings on the kickstart file.

The following sections provide a brief overview of each option shown in the left-hand pane. I'm guessing it's unlikely that you'll have to know kickstart in this level of detail on the Red Hat exams, at least until bug 217165 is addressed. However, an understanding of the Kickstart Configurator can help you understand the installation process, which is important on the installation part of each exam.

On the Job 

If you need to customize package groups, don't use a GUI Kickstart Configurator version before RHEL 5.1 (update 1) is released. As of this writing, bug 217165 (https://bugzilla.redhat.com) won't be addressed until that release. If you use a Kickstart Configurator version before that, it will overwrite the kickstart file that you've previously created.

Basic Configuration

In the Basic Configuration screen, you can assign settings for the following components:

• Default Language The default language for the installation and operating system.

• Keyboard Also normally associated with language.

• Time Zone Supports computers in which the hardware clock is set to the atomic realization of UTC, which corresponds closely to Greenwich Mean Time.

• Root Password Can be encrypted in the kickstart file.

• Target Architecture Can help you customize a kickstart file for different systems.

• Reboot System After Installation Adds the reboot command to the end of the kickstart file.

• Perform System Installation In Text Mode Supports automated installation in text mode.

• Perform Installation In Interactive Mode Allows you to test the steps associated with a kickstart installation.

Installation Method

The Installation Method options are straightforward. You're either installing Linux for the first time or upgrading a previous installation. The installation method, and your entries, are based on the location of the installation files. For example, if you select an NFS installation method, the Kickstart Configurator prompts you for the name or IP address of the NFS server and the shared directory with the RHEL installation files.

You can set up your kickstart file to install RHEL from a CD/DVD, a local hard drive partition, or one of the standard network servers: NFS, HTTP, or FTP.

Boot Loader Options

The next section lists boot loader options. The default boot loader is GRUB, which supports passwords for an additional level of security during the boot process.

Linux boot loaders are normally installed on the MBR. If you're dual-booting Linux and Microsoft Windows with GRUB, you can set up the Windows boot loader (or an alternate boot loader such as Partition Magic or System Commander) to point to GRUB on the first sector of the Linux partition with the /boot directory. Kernel parameters allow you to pass commands to the kernel through the GRUB configuration file as described earlier in this chapter.

Partition Information

The Partition Information options determine how this installation configures the hard disks on the affected computers. While it supports the configuration of standard and RAID partitions, it does not yet support the configuration of LVM groups. The Clear Master Boot Record option allows you to wipe the MBR from an older hard disk that might have a problem there; it sets up the zerombr yes command in the kickstart file.

On the Job 

Don't use the zerombr yes option if you want to keep an alternate bootloader on the MBR such as Partition Magic or the NT Boot Loader.

You can remove partitions depending on whether they've been created to a Linux filesystem. If you're using a new hard drive, you'll want to Initialize the Disk Label as well. Click the Add command; it opens the Partition Options dialog box. As you can see in Figure 5-5, this corresponds to the Anaconda Add Partition dialog box shown back in Chapter 2.

Figure 5-5: Using the Kickstart Configurator to set up partitions

Network Configuration

The Network Configuration section enables you to set up IP addressing on the network cards on a target computer. You can customize static IP addressing for a specific computer, or you can configure the use of a DHCP server. You can also make kickstart look for a BOOTP server, which is a specially configured DHCP server on a remote network.

Authentication

The Authentication section lets you set up two forms of security for user passwords: Shadow Passwords, which encrypts user passwords in the /etc/shadow file, and MD5 encryption. This section also allows you to set up authentication information for various protocols:

• NIS Network Information Service for one login database on a network with Unix and Linux computers on a network.

• LDAP The Lightweight Directory Assistance Protocol is used for certain types of databases such as directories.

• Kerberos 5 The MIT system for strong cryptography to authenticate users on a network.

• Hesiod Associated with Kerberos 5.

• SMB Samba (CIFS) allows configuration of your Linux computer on a Microsoft Windows-based network.

• Name Switch Cache Associated with NIS for looking up passwords and groups.

Firewall Configuration

The Firewall Configuration section allows you to configure a default firewall for the subject computer. Generally, you'll want a firewall only for those computers that are connected to outside networks such as the Internet.

In this section, you can also configure basic SELinux settings. The Active and Disabled options are straightforward; the Warn option corresponds to a Permissive implementation of SELinux. For more information, see Chapter 15.

Display Configuration

The Display Configuration section allows you to configure the Linux GUI. While there is a lot of debate on the superiority of GUI- or text-based administrative tools, text-based tools are more stable. For this reason (and more), many Linux administrators don't even install a GUI. However, if you're installing Linux on a series of computers, it's likely that most of the users won't be administrators.

In this section are three tabs. Under the General tab, you can set a default color depth and resolution, indicate a default desktop (GNOME or KDE), configure the X Window to start by default, and disable or enable the Setup Agent (the First Boot process). Under the Video Card and Monitor tabs, you can set Linux to probe your hardware or specify the hardware from a list. If you want to do something fancy such as specifying multiple resolutions, you'll need to modify the ks.cfg file directly.

Package Selection

The Package Selection section allows you to choose the package groups that are installed through this kickstart file. You should recognize it as the custom installation screens shown during the installation process.

On the Job 

Package Selection doesn't work in the GUI Kickstart Configurator for RHEL 5 and isn't scheduled to be fixed until the first update, scheduled three months after the first release of RHEL 5.

Installation Scripts

You can add preinstallation and post-installation scripts to the kickstart file. Post-installation scripts are more common, and they can help you configure other parts of a Linux operating system in a common way. For example, if you wanted to install a directory with employee benefits information, you could add a post-installation script that adds the appropriate cp commands to copy files from a network server.