Hands-Off Fedora Installs with Kickstart

Editor's note: Ethan has collected this series and other information into Managing RPM-Based Systems with Kickstart and Yum. This series continues in Advanced Linux Installations and Upgrades with Kickstart and Pre-patched Kickstart Installs.

If you've installed Red Hat's Fedora OS, you've likely noticed the Anaconda installer's polished and friendly user interface. It's certainly helpful, but I still don't want to click through it every time I (re)build a machine. Kickstart's automated installs give my mousing finger a rest.

Kickstart isn't only for large server farms. Someone building a couple of oft-recycled machines, such as in a lab environment, can benefit from fast, consistent, unattended OS installs. Additionally, people who are just experimenting with Linux can rely on Kickstart as a way to start fresh when their tinkering goes awry.

In this article, I'll explain how to set up a basic Kickstart environment and perform an install. I tested this process extensively on Fedora Core 1 and briefly on FC2. It may work for Red Hat 9, as well.

Before You Start

A Kickstart install involves three participants: a target machine uses a config file to set system parameters and determine what RPMs to pull from the installation media. (The config file may have any name; this article will refer to it as ks.cfg.)

There are several ways to connect those pieces: the target machine can fetch the RPMs from a local disk, NFS server, FTP server, and so on. The config file can come from the aforementioned places or from the boot media, and it may exist in a different place than the installation media.

Related Reading Learning Red Hat Enterprise Linux & Fedora By Bill McCarty

Such flexibility makes it difficult to explain a "typical" Kickstart process in detail. This article demonstrates just one method, using a web server to host the install media and config file. This is likely the easiest and least intrusive method to experiment with Kickstart. It should also scale as your Kickstart experiment matures into a formal infrastructure.

To that end, the setup described in this article requires:

• The Fedora install files, which you'll copy to the web server's file system.
• A target machine on which you will install Fedora. Using virtual hardware, such as VMware or Bochs, will simplify your experiment.
• Bootable media that matches the version of Fedora you plan to install. Choose from install CD 1, diskettes (images/bootdisk.img and images/drvnet.img from the install media), or a bootable CD made from images/boot.iso.
• A source machine to host the install files and Kickstart config, and run the web server.

Some of these require additional explanation and I'll describe them in turn.

The Source Machine: Setting up the Install Tree

The target machine will fetch its install files and ks.cfg from a web server running on the source machine. The source machine needn't run Linux, but it must have roughly 2.2G disk space available. The web server must listen on port 80 due to a limitation in Kickstart's HTTP code.

Create a directory FC1-install under the document root and populate it with the Fedora directory from the install media. Use your preferred download tool (say, wget) to grab the tree from a Fedora mirror site or copy the contents from the install CDs or ISOs. Be sure to maintain the directory structure in this latter case. There are myriad ways to do this, such as:

$ cd /mnt/cdrom
$ cp -a Fedora /...docroot.../FC1-install

Finally, create a subdirectory kickstart under the doc root to host the Kickstart config files.

Creating the Kickstart Config File, ks.cfg

ks.cfg makes unattended installs possible. It holds canned responses to the questions posed during an interactive install. The examples assume you've saved this file under the web server's document root as kickstart/ks.cfg.

There are several ways to create ks.cfg. (I did warn you that Kickstart was flexible.) If you're plotting a clone farm, build one machine to your specs and use /root/anaconda-ks.cfg on that host as a starting point for the others.

Barring that, use the redhat-config-kickstart GUI (from the redhat-config-kickstart package). This tool doesn't support LVM for disk layout, but is a valuable learning tool nonetheless. You can hand-edit the generated ks.cfg to use LVM (described below).

You can also create or edit ks.cfg using any text editor, provided you know the directives. Here's a walk through the directives in the sample ks.cfg.

You probably already have the redhat-config-language, hwdata, and tzdata RPMs installed already. They are not required, but include files that simplify hand-editing ks.cfg.

Installation Type

The first entries are the installation type and source.

install
url --url http://kickstart-server/FC1-install

The type may be install or upgrade. The url directive specifies an HTTP installation and indicates the URL of the install media. (The directory Fedora, from the install media, must be a subdirectory of the URI part of the URL.) Other installation sources include cdrom for swapping CDs or DVDs, nfs for mounting the install media from an NFS share, and the self-explanatory ftp.

Languages and Input

lang and mouse indicate the language and mouse type, respectively, to use during the installation.

lang en_US.UTF-8
mouse generic3ps/2

The sample ks.cfg uses U.S. English with the Unicode (UTF-8) character set, and a generic PS2 mouse with three buttons.

Refer to /usr/share/redhat-config-language/locale-list for the list of valid languages.

The values of lang and mouse don't matter for unattended installations.

langsupport and keyboard set the runtime (installed) language support and keyboard type, respectively.

langsupport --default en_US.UTF-8 en_US.UTF-8
keyboard us

Specify a single language (en_US) or multiple languages with a default (--default en_US en_UK). Specifying just the default (--default en_US) installs support for all languages.

Video

For a workstation build you'll likely want to configure your video card and monitor, using xconfig.

xconfig --card "VMWare" --videoram 16384 --hsync 31.5-37.9
        --vsync 50-70 --resolution 800x600 --depth 16

(We've split the above line for readability; it should be a single line in ks.cfg..)

xconfig takes the card's name (listed in /usr/share/hwdata/Cards) and video RAM in kilobytes. The remaining parameters specify the monitor's horizontal and vertical sync rates, resolution, and color depth in bits.

Use the skipx directive to skip this step (say, for headless servers). You can manually configure X later.

Networking

The network directive sets the target host's runtime network configuration. This may be different than the build-time IP. For example, you may use separate networks to build (DHCP-enabled) and deploy machines (static IPs).

network --device eth0 --bootproto static --ip 10.10.10.237
        --netmask 255.255.255.0 --gateway 10.10.10.254
        --nameserver 10.10.10.11,10.0.0.23,10.1.0.34
        --hostname fc1-test

This line configures the interface eth0 with a static IP address of 10.10.10.237. Notice that the nameserver selection accepts a comma-separated list of IP addresses.

Configure other interfaces by specifying different devices with --device. You needn't supply any network information when --bootproto is dhcp or bootp.

The network configuration will differ for each host in a clone farm, so you can't use the same file for the entire group. I'll present ideas on how to handle this situation in a future article.

Authentication and Security

Set the root password with the rootpw directive.

rootpw --iscrypted $1$NaCl$X5jRlREy9DqNTCXjHp075/

The --iscrypted flag indicates an MD5-hashed password. You can find a password's encrypted form any number of ways, such as copying an existing entry from /etc/shadow or using OpenSSL's passwd module:

$ openssl passwd -1 -salt "NaCl" "don't use this"

Without the --iscrypted flag the specified password will be used as-is, such as:

rootpw plain_text

On the subject of passwords, authconfig determines how to authenticate users. The following line sets the target host to use MD5-hashed passwords from the local /etc/passwd and /etc/shadow files:

authconfig --enableshadow --enablemd5

There are other authentication options, such as NIS, LDAP, or Kerberos 5.

The firewall directive sets up a rudimentary ruleset, useful for a machine that will talk to the outside world:

firewall --enabled --trust=eth0 --http --ssh

Here, traffic from interface eth0 will be implicitly trusted. The firewall will permit incoming SSH (port 22/tcp) and HTTP (80/tcp) traffic on all interfaces.

Specify firewall --disabled to manually configure the firewall later or to skip it altogether.

Time Zone

Set the machine's time zone with the timezone directive:

timezone America/Chicago

Valid time zones are in the TZ column of the file /usr/share/zoneinfo/zone.tab.

Boot Loader

The bootloader directive sets the location of the GRUB boot loader. The sample ks.cfg places it in the master boot record (MBR):

bootloader --location=mbr

If you don't want a boot loader, specify --location=none. Remove an old boot loader from the MBR with the separate zerombr directive.

Disks

Disk setup is the most complex part of a ks.cfg because there are so many machine- and environment-dependent choices. Note that the sample ks.cfg clears existing partitions on the target machine, so be sure to backup any valuable data.

clearpart removes disk partitions.

clearpart --all --drives=sda --initlabel 

clearpart can remove just Linux partitions (--linux) or all existing partitions (--all). It removes partitions from all drives unless you've added the --drives flag. The --initlabel flag works for previously unused disks or disks with foreign partition schemes: it clears out the old partitions and sets up a scheme that Linux can understand.

Omit clearpart to preserve existing partition boundaries.

part sets up partitions. The sample ks.cfg uses a simple two-partition layout and has a separate swap partition:

part /boot --fstype ext3 --size=100 --ondisk=sda --asprimary
part / --fstype ext3 --size=1024 --grow --ondisk=sda --asprimary
part swap --size=128 --grow --size=256 --ondisk=sda --asprimary

The first parameter specifies the mount point, here /boot, /, and swap. (Linux doesn't really mount swap space, but that's a minor technicality.) Set the file-system type with the --fstype flag. The sample uses ext3. Other options include ext2 and vfat (aka Windows). Swap doesn't use a file-system type.

Specify a partition's size in megabytes using the --size flag. Specify the partition's physical disk with the optional --ondisk flag. Mark your primary partitions with --asprimary.

part's --onpart and --noformat flags preserve existing partitions between Kickstart installs. For example, the following would mount the preexisting hda7 as /home:

part /home --fstype ext3 --size 1024 --onpart hda7 --noformat 

Note that this won't shuffle data to another part of the disk if other partition sizes change; it simply tells Kickstart to leave hda7's partition boundaries intact and to skip creating a new file system there using mkfs.

The following is a simple one-disk LVM setup:

part /boot --fstype ext3 --size=75 --asprimary
part pv.00 --size=1 --grow --asprimary

volgroup vgroot pv.00
logvol / --name=root.fs --vgname=vgroot --size=1024
logvol swap --name=swap.vol --vgname=vgroot --size=256

The second part directive sets up a partition as an LVM physical volume (PV). The --grow flag grows this partition to the maximum allowable size, so that you needn't know the disk's size ahead of time. part still requires a size, though, so it uses a bogus PV partition size of 1MB.

logvol is LVM's part equivalent: it accepts the logical volume's mount point and size, in addition to the volume group to which it belongs. logvol's --name flag names the volume.

Note that the generated /root/anaconda-ks.cfg on the target host has a commented-out disk layout.

Rebooting

The reboot directive forces the target host to reboot when the installation completes. Don't forget to remove the installation media, lest the machine reboot right back into the installer.

Package Selection

The %packages directive specifies which RPMs to install on the target host. You may select packages individually or en masse as groups. To specify a group, prefix the name with the @ symbol and a space. Precede a name with a minus symbol (-) to exclude that package from the group.

%packages
@ dialup
kernel
grub
e2fsprogs

The Fedora/base/comps.xml file, from the install media, defines package groups. I'll describe this file in greater detail in a future article.

Kickstart installs packages in addition to those you select in order to resolve dependencies. Use %packages's --ignoredeps flag to ignore package dependencies.

Package selection is another area in which it is easiest to perform a manual installation once, then mine the resultant /root/anaconda-ks.cfg file for information.

Build the Target Machine: Run the Kickstart

The hard work is done. Now boot the target machine from the Fedora media. At the boot: prompt, enter:

linux ks=http://build-server/kickstart/ks.cfg

You will receive an error if the boot media does not match the version of Fedora you're trying to install.

Unless you have DHCP available on the target machine's network, the installation will pause for you to enter its IP configuration. This is fine for small deployments and experiments, but a full, hands-off Kickstart infrastructure calls for DHCP or bootp.

The installation will also pause for input if any required directives are missing from ks.cfg.

Troubleshooting a Failed Install

The installer's error reporting can be cryptic. Messages refer to lines in Anaconda's underlying Python scripts, not your ks.cfg.

Include the interactive directive to step through the installation using values from ks.cfg as the defaults. You cannot test the root password this way, though; you must enter that manually.

Going Beyond

My Kickstart R&D has certainly paid off: I no longer have to click through the full Fedora installer and I can grab a tea while Kickstart does the hard work. Hopefully, this article will help jump-start your own Kickstart projects.

There is a lot more to Kickstart than what I have described here. It supports several customization points, including home-grown RPMs and pre-/post-install scripts. I'll cover these and more in a future article.

Resources

• Sample ks.cfg
• If you've installed redhat-config-kickstart RPM, the Kickstart documentation is available on your machine in HTML form. They are also available online in Chapter 7 of the Red Hat 9 Customization Guide.
• The Fedora Mirrors page has a list of mirror sites from which to download the install tree.

Ethan would like to thank Scott Wheeler for reviewing this article.

Q Ethan McCallum grew from curious child to curious adult, turning his passion for technology into a career.

Return to LinuxDevCenter.com.

Copyright © 2009 O'Reilly Media, Inc.