The ability to automate a Linux installation, and to ensure that all installations are consistent across a large number of workstations or servers, provides administrators with a great tool for dealing with an operating system that traditionally has had a reputation for being difficult to install. By providing all of the consistency and ease-of-use that comes with automation, Kickstart installations could put an end to Linux’s bad-installation reputation.
Using the Kickstart procedures, a single file is used to supply answers to the questions normally asked during the RedHat installation procedure. This translates into unattended installations and uniformity throughout your company’s machines.
In this article, I’ll cover the procedures required to perform a Kickstart installation using RedHat 7.2.
What you need
Using a Kickstart installation requires some basic groundwork. To perform a network installation, you’ll need a BOOTP/DHCP server running on your network. This server must have the networking configuration information for the machine on which RedHat is being installed.
To perform a disk-based installation on a local machine, you’ll need to have a boot disk with the Kickstart configuration, ks.cfg, located in the top-level directory of the bootdisk.
You’ll also need a CD-ROM of the version of RedHat you want to install. Finally, to create the Kickstart configuration using Kickstart Configurator, you will need a machine running both RedHat and the X Window System.
The ks.cfg file
There are three ways to create the ks.cfg file:
- 1. The RedHat documentation CD-ROM contains a sample version of the ks.cfg file. This file may be edited to suit your configuration and then saved to your boot disk.
- 2. You can also create the ks.cfg file from scratch using any text editor. This method, which is the one I use in this article, requires only a text editor and knowledge of how to customize a Linux installation.
- 3. Use the Kickstart Configurator. The configurator utility may be used on systems where X is running.
The Kickstart configuration file MUST be named ks.cfg, and it is always stored in the top-level directory of the boot disk. The entire Kickstart process depends on the information contained in the ks.cfg file. When the RedHat installation program reads the ks.cfg file, information is read in a prerequisites-defined order, and a specific syntax is followed. The following rules apply to the ks.cfg file:
- 1. The command section: The command section specifies the options used for the installation, including authentication method, bootloader options, partitioning options, firewall options, and the installation method.
- 2. The %packages section: This section lists the Linux components to be installed, such the Apache Web server, printer support, mail and news servers, X Windows, etc.
- 3. The %pre and %post sections: These sections list actions to be performed before and after the installation process begins. These sections are not required for a Kickstart installation but are very useful nonetheless.
- · If any item required by the installation is omitted from the ks.cfg file, the installation will prompt the administrator for information on the missing item. When the reply is entered, the installation will continue.
- · Any items not required by the installation process can be left out of the ks.cfg file.
- · Lines beginning with a pound sign (#) are treated as comments.
Options used in the ks.cfg file
The options listed in the ks.cfg file describe the installation from beginning to end. I will discuss these options only in terms of whether they are required. For example, I may mention that Kerberos 5 authentication is one of your options, but this article will not provide an explanation of how Kerberos actually works.
The authentication section
The auth section establishes the authentication method for the installation. It MUST be present in the ks.cfg file. This section performs some of the same functions as the /usr/sbin/ksconfig command.
The auth section always begins with one of the following keywords:
Table A shows a list of the commands available for the auth section.
|--enablemd5||Encrypts passwords using the MD5 hashing algorithm|
|--enableshadow or --useshadow||Enables the use of shadowed passwords|
|--enableldap||Enable LDAP support (If this option is used, the following two options must also be included.)|
|--enableldapauth||Specify LDAP as the authentication method (If either --enableldap or --enableldapauth are used, the following two options must also be included.)|
|--ldapserver||Specifies the name of the LDAP server|
|--ldapbasedn||Specifies the distinguished name in the LDAP directory that is used to store user information|
|--enablesmbauth||Enables user authentication of users through an SMB server|
|--smbservers||Lists the server or servers used for SMB authentication|
|--smbworkgroup||Specifies the SMB workgroup|
The bootloader section
The bootloader section is always required for Kickstart installations. This section specifies three critical components of the installation:
- 1. Whether the bootloader should be installed
- 2. Whether the bootloader used will be LILO or GRUB
- 3. Which configuration options (if any) for the bootloader will be used
The clearpart section
The clearpart section specifies which partitions, if any, are removed prior to Linux being installed. This section is optional, although most administrators will perform some actions related to disk partitioning during the installation. This section uses the following syntax:
Table B shows the clearpart options.
|--linux||Deletes all Linux partitions|
|--all||Deletes all partitions|
|--drives||Specifies where partitions will be removed|
|--initlabel||Specifies the default disk label for the type of architecture Linux is being installed|
This firewall configuration section uses this syntax.
Ports may be specified using either the port: protocol format or by using the numerical value for the port, along with the protocol allowed. (Click here to see an example of the syntax for this configuration.)
Specifying the installation method
There are four installation methods available for Kickstart installations. The simplest method is to install RedHat from the local CD-ROM. For this type of installation, the following command is used:
Another method for installing RedHat locally is to install from an installation tree located on a local hard drive. For this method, the following command isused:
The partition and the directory where the installation are located are then specified using the following two entries:
An example for specifying the harddrive is:
The first command tells the installation that the CD-ROM installation is being used. The second command performs the same action as selecting CD-ROM from the menu during a RedHat installation.
The next three methods are used when the RedHat installation tree is located on a remote server. For any remote methods, the following syntax is used:
To install RedHat from an NFS, use the following command:
Then, specify the IP address or hostname of the NFS server and the path to the directory containing the installation tree. For example:
nfs --server nfsserver.techrepublic.com --dir sdb2/redhat
--server 192.168.1.30 --dir sdb2/redhat
To install from a URL, use the following keyword:
The url is followed by a second entry that specifies the path to the installation tree and whether the installation is being done through HTTP or FTP. Additionally, when the FTP method is specified, the user name and password must be supplied with the URL. Either of the following examples will work. (Note: These are fictitious addresses.)
For HTTP installations, use:
For FTP installations, use:
Specifying the keyboard type (required)
To specify a US type keyboard, use the entry:
Specifying the language (required)
The keyword used to specify which language support is installed is lang. To specify language support for English, use the following entry:
Mouse support (required)
The options used for mouse support are shown in Table C.
|--device <dev>||Specifies the device the mouse is using|
|--emulthree||Emulates a three-button mouse|
This section is where all the networking information for your system is entered. If your installation is done through the local CD-ROM or hard drive, network configuration is optional. For all other installation methods (NFS, HTTP, or FTP), network configuration must be used. This section configures networking information used during a network-based installation and also provides networking information for the installed system. The options for networking configuration are shown in Table D.
|--bootproto||Specifies the boot protocol (The default is DHCP. Other options are bootp and static.)|
|--device <device>||Specifies the Ethernet card being installed (If the --device option is used, the ks.cfg file must be a local file. An Ethernet card on a remote system cannot be installed through the ks.cfg file.)|
|--ip||Specifies the IP address for the system being installed|
|--gateway||Specifies the default gateway|
|--netmask||Specifies the default netmask|
|--hostname||Specifies the hostname for the system|
There are several important points to remember when configuring networking options. First, using the BOOTP and DHCP options means that either a BOOTP server or a DHCP server must be running on your network to provide IP information for network configuration.
To use DHCP during the installation, use the following entry in ks.cfg:
network --bootproto dhcp
To use BOOTP, use this entry:
network --bootproto bootp
Second, if static IP information is used, there are two items you must be aware of:
- · All networking information must be on one line, so only one DNS server may be specified.
- · A typical entry for static IP information would look like this.
Finally, use of the static option requires all networking information to be entered into the ks.cfg file. This information is used both during and after the installation.
Configuring disk partitions
The partitioning section is required for all Kickstart installations and is ignored during upgrades. This section always begins with either part or partition. Table E shows the available partitioning options.
|/<mount-point>||Specifies where a partition will be mounted|
|--size <size-in megabytes>||Specifies the minimum size of the partition (Use an integer only to specify partition size; do not add MB to the number.)|
|--grow||Specifies that the partition will grow to fill the space available or grow to the specified maximum size|
|--maxsize <size>||Specifies the maximum size of the partition|
|--onpart||Specifies that the partition will be placed in a device that already exists (For example, partition /usr --onpart /dev/hda6 would place the /usr partition on /dev/hda6, provided /dev/hda6 has already been created.)|
|--noformat||Prevents the installation program from formatting the partition (This option is used with the --onpart command.)|
|--ondisk or --ondrive||Specifies the disk where the partition is created|
|--ondisk /dev/sdb||Creates the partition on the second SCSI disk|
|--asprimary||Specifies that the partition is automatically allocated as a primary partition (If the partition can be allocated as primary, the partitioning operation fails.)|
|--bytes-per-inode <number>||Specifies the number of bytes per inode|
|--fstype||Specifies the filesystem type for the partition (Available options are ext2, ext3, and VFAT.)|
|--start||Specifies the starting cylinder for the partition (This option requires that the disk be specified with the --ondisk or --ondrive option. The end cylinder for the partition must be specified with the --end option, or the partition size must be specified using the --size option.)|
|--end||Specifies the end cylinder for the partition|
|--badblocks||Checks the partition for bad blocks while formatting|
There are two points to remember about partitioning:
- · All partitions will be formatted during the installation process, unless the --noformat AND the --onpart options are used.
- · If the clearpart option is used, the --onpart options cannot be used on a logical partition.
The RAID configuration section uses the following syntax:
raid <mount-point> --level <raid-level> --device <device-name> <partitions>
The options available for configuring RAID are shown in Table F.
|--level||Specifies the RAID level to use (Levels 0, 1, and 5 are allowed.)|
|--device||Specifies the name of the RAID device|
|--spares <number>||Specifies the number of spares available|
|--fstype||Specifies the filesystem used|
|--noformat||Does not format the array|
The following rules apply when configuring RAID:
- · If the mount point is /, The RAID level must be level 1, unless there is a /boot partition on the system.
- · If a /boot partition exists, the /boot partition must be level 1 and the / partition may be level 0, 1, or 5.
Set the root password
The root password is always required. The format for this command is:
Setting the timezone
The timezone is always required. The format for the timezone command is:
To use Greenwich Mean Time, use this format:
time --utc <timezone>
To configure X Windows, use the xconfig keyword. The options available with the xconfig keyword are shown in Table G.
|--noprobe||Does not probe for a monitor|
|--card <card-name>||Uses a card name from the list in Xconfigurator (If you skip this option, Anaconda will probe for the card.)|
|--videoram||Specifies the amount of memory on the card|
|--monitor||Specifies the monitor type (If no monitor type is specified, Anaconda will probe for the monitor.)|
|--hsync||Specifies thehorizontal sync rate for the monitor|
|--vsync||Specifies thevertical sync rate for the monitor|
|--defaultdesktop||Uses --defaultdesktop=GNOME OR defaultdesktop=KDE|
|--startxonoboot||Uses a graphical login for the system|
|--resolution <res>||Specifies thedefault resolution for X Windows|
|--depth||Specifies thedefault color depth|
When RedHat is installed, the installation program uses the comps file located in the /RedHat/base directory. The comps file lists every package available during a RedHat installation. When packages are selected for installation, the package must exist in the comps file, and the package name must match. Packages may be installed by component, which is actually a group of related packages, or by individual package name. To use the comps file format, you should know that:
- 1. Lines that begin with a number, followed by the component name, define components.
- 2. If a line begins with the number 1, the component is installed by default.
- 3. Each package in that particular component is then listed on a separate line.
- 4. Packages that are not part of a component are listed on individual lines without a leading number.
To install components without specifying individual packages, begin the packages section with the following line:
You will then specify the component on a separate line beginning with the at symbol (@). Here is a sample %packages section, where the system has support for a network Managed Workstation, Gnome, and several additional tools:
@Network Managed Workstation
Pre- and post-install configuration
The Kickstart installation method provides the capabilities to execute commands prior to and after the installation.
The %pre section lists commands to execute as soon as the installation program has read the ks.cfg file but prior to performing the actual installation.
The two commands below will create a message-of-the-day file with the date the Kickstart was performed and then add a secondary nameserver IP address to/etc/resolv.conf:
#add a comment to /etc/motd
echo "RedHat 7.2 Kickstart Install `/bin/date`" >/etc/motd
#add a secondary nameserver
echo "nameserver 10.24.253.191" >> /etc/resolv.conf
The %post section lists commands to run after the installation has completed. At this point, Linux has been installed, so you will have access to all Linux commands. In the example below, users jack and susan are added, the ping command is tested, and the dig command is run to perform a DNS check:
/usr/sbin/useradd jack -p ansqs1234
/usr/sbin/useradd susan -p sqL8749
This section may also be used to automatically add a firewall script, configure a router/gateway, or run any other function required of the system.
The %pre and %post sections are always placed at the end of the ks.cfg file. When using the Kickstart Configurator method, the %pre and %post identifiers are not visible. Kickstart Configurator will add them automatically.
Running Kickstart Configurator
The Kickstart Configurator provides a GUI interface for the process of creating and saving the ks.cfg file. If the icon for Kickstart Configurator isn't available under the KDE or Gnome menus, run the following command:
When presented with the user-friendly interface, make the selections you want for your system and save the ks.cfg file. The resulting text file is easily edited to give you exactly the configuration you want.When your configurations have been selected, click on Save File. You will then see the entire contents of your ks.cfg file in the next window.
Once the ks.cfg file has been saved, it may be opened and edited in any text editor, or you can run Kickstart Configurator again and create a new version. This method of creating the ks.cfg file is very useful, especially when you are not sure about which driver to use for a specific device or if you would like to let the RedHat installation program perform configuration tasks without having to provide any information.
Starting the installation
Once the kickstart file is saved, copy it to your boot disk. To begin the kickstart installation, boot any machine from the floppy disk, and at the prompt, enter the command:
Specify the installation method (CD-ROM, NFS, etc.), and the Kickstart installation will begin.
Kickstart installations are a practical and uncomplicated way to automate RedHat installations or to ensure that a group of workstations or servers are all using the same configuration. In this article, I covered the process for performing a Kickstart installation of RedHat Linux, the commands used to configure the system for Linux, how to select and install RPM packages, and how to run specific commands prior to and after the installation. The Kickstart method provides the flexibility and consistency that administrators need to make their jobs easier. Try this installation method; it could become your preferred method for upgrading and installing RedHat.