Hands-Off Fedora Installs with Kickstartby Q Ethan McCallum
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.
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
$ 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
tzdata RPMs installed already. They are
not required, but include files that simplify hand-editing ks.cfg.
The first entries are the installation type and source.
install url --url http://kickstart-server/FC1-install
The type may be
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
cdrom for swapping CDs or DVDs,
mounting the install media from an NFS share, and the self-explanatory
Languages and Input
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
mouse don't matter for
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 en_US en_UK). Specifying just the default
--default en_US) installs support for all languages.
For a workstation build you'll likely want to configure your video card and
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.
skipx directive to skip this step (say, for headless
servers). You can manually configure X later.
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
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
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
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 --iscrypted $1$NaCl$X5jRlREy9DqNTCXjHp075/
--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
$ openssl passwd -1 -salt "NaCl" "don't use this"
--iscrypted flag the specified password will be
used as-is, such as:
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
authconfig --enableshadow --enablemd5
There are other authentication options, such as NIS, LDAP, or Kerberos 5.
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.
firewall --disabled to manually configure the firewall
later or to skip it altogether.
Pages: 1, 2