Author: Brian Jones
administrators around the globe continue to stick with Red Hat Linux as
their production distribution of choice. If you got 10
administrators in a room and asked them, they’d probably all give different (and
probably long-winded) answers, but they’d all mention the power and control
afforded by the Red Hat’s Kickstart.
While Kickstart is extremely useful, it does have one nagging issue
we’d like to overcome: You have to trudge up to the machine room to boot
to a CD and type linux ks at the boot prompt in order to
use it. I’ve said it before and I’ll say it again; the role of an admin
is to script himself out of a job. If it can be further automated, it
probably will be eventually, even if what’s being automated is, well, an
automation solution to begin with!
We can eliminate ourselves from the Kickstart process by making our
Kickstart target machines boot over the network. They’ll grab a bootable
kernel from a configured TFTP server, and that kernel will be configured
to Kickstart itself. It will get a Kickstart configuration
file and access the installation media over the network, using either
FTP, HTTP, or, in this case, NFS.
The targets have to have a BIOS that supports using a network device
as a boot device, just as it does the CD-ROM, diskette, and hard drives.
I have yet to see a server that doesn’t support this, and even most
desktop machines can do it these days. In addition, the network device
in the machine has to support PXE. You as an
administrator will undoubtedly have to figure out exactly what
definition of “supports PXE” your NIC vendor uses. Some devices just
make a BOOTP request and they do as the BOOTP server says. Other devices
seem to completely ignore the DHCP directives altogether and insist on
making a call to an actual running PXE daemon running on the DHCP
server. I’ll show you what has worked for me, and let you share your
tips in the comments section at the end of this article.
To be clear, we’ll be setting up the following components:
- DHCP server — to tell the target where to get its boot kernel.
- TFTP server — to serve up the boot kernel with the proper parameters.
- NFS server — to serve up the installation media.
Step 1: Configuring DHCP
You’ll need the dhcpd package installed for this. There are
conflicting documents online saying the Red Hat-supplied dhcpd isn’t up to the
task; ignore them. It works just fine. I’ve tested this in multiple environments,
with multiple hardware platforms, and it works.
Once it’s installed, make sure you run chkconfig dhcpd on so that the DHCP daemon starts automatically at boot time. You also need to set up a DHCP configuration file
called /etc/dhcpd.conf. Here’s a simple example:
ddns-update-style none;
ignore client-updates;
allow bootp;
allow booting;
subnet 192.168.2.0 netmask 255.255.255.0 {
default-lease-time 21600;
max-lease-time 43200;
option subnet-mask 255.255.255.0;
}
host morticia {
hardware ethernet 00:90:27:9a:3d:fd;
fixed-address 192.168.2.2;
next-server 192.168.2.1;
filename "pxelinux.0";
}
This is just barely enough to get you to the point where you can see
if things are working. The first stanza serves a dual purpose which can
be overlooked: it tells the DHCP server which NIC to listen on on a
dual-homed box. It’s also required, which is the second purpose. In
addition, though, it allows you to group options common to all machines
in the subnet. So, for example, all machines in the defined subnet will
have a subnet mask of 255.255.255.0, so we don’t have to put that in
every host definition. I’ve also defined our target machine here,
“morticia.” In addition to identifying it to the DHCP server using the
hardware address of the client, we’ve also told it to go to a
“next-server,” and we’ve told it the filename to use to boot itself.
Step 2: Configure TFTP
This is another area where I’ve seen docs stating that the Red Hat-supplied
version doesn’t work. I haven’t run into an instance of this yet; if you have, please
comment and help us all out. I use the Red Hat-supplied
tftp-server package, which launches from the xinetd super-server once you
enable it. Enabling the server basically means editing /etc/xinetd.d/tftp
and changing the “disable” line from “yes” to “no.” Restart xinetd, and it’ll
handle TFTP requests. Note that you won’t see in.tftpd running in
a process listing; it’s started up by the xinetd server as needed, and
promptly shut down when it’s done.
Once the server is set up, you’ll need to populate the /tftpboot directory with the following:
- Something bootable. In this setup, we’ll take the first CD from a recent
Red Hat version.cdto images/pxeboot/ and copy the vmlinuz and
initrd.img files over to the /tftpboot directory. - pxelinux.0, from the
pxepackage, which comes with recent
Red Hat versions (though it’s not installed by default). Copy it to
/tftpboot. - A configuration file for the boot kernel. This looks a good bit like a LILO
or GRUB config file. We’ll make a directory called
/tftpboot/pxelinux.cfg, and the config file will be called
“default.” For our test, we’ll make one that looks like this:
default linux
serial 0,38400n8
label linux
  kernel vmlinuz
append ksdevice=eth0 console=tty0 console=ttyS0,38400
load_ramdisk=1 initrd=initrd.img network
ks=nfs:192.168.2.1:/Kickstart/fc2-ks.cfg
One thing to note about this file is that the append line above has to be all
one line — no backslashes, no line breaks. I added them here only for
readability. The append line contains the meat of what’s going to happen. The
ksdevice token allows you to specify which interface to use on
multi-homed targets. Then, the ks token tells the target where to
grab the Kickstart configuration file from. The Kickstart file, in turn, will
tell the target where to get the installation media from, and it’s off to the
races! Well, almost…
Step 3: Configure an NFS server
NFS servers are simple to setup. This is generally not the area of
NFS that causes admins headaches. No, it’s the maintenance under production
loads, security issues, performance nightmares, and application integration problems
that lead us to come up with the many colorful alternate meanings for the
abbreviation. However, for the purposes of this experiment, NFS is quick to set up
and relatively trouble-free.
Let’s not forget our purpose: we have a DHCP server telling the target machine
to head over to the TFTP server to get its boot file and parameters. Those
parameters will tell the target system to grab a Kickstart file, which will
tell it to NFS-mount a partition to get its install media, which I set up by
copying the ISO images to an exported directory.
First, create a directory
called /cd-images/Red Hat. In that directory, copy the ISO images
for all of the binary CDs of the version you’re installing. In more recent
versions of Red Hat, Kickstart can actually loopback mount the ISO images over
an NFS mount, which saves you from having to copy the entire contents of the
CDs to the directory. Once that’s done, add this line to the
/etc/exports file: /cd-images 192.168.2.0/24(ro),
and start or restart the NFS server.
Give it a go!
Now, when we turn on the target machine, the BIOS will turn control over to the
network device, which will look to get an IP address from our DHCP server.
Along with the reply, it’ll also be told to go get the bootstrap kernel,
pxelinux.0, from our TFTP server. The pxelinux.cfg file we created will tell
the bootstrap image which kernel to boot, and which parameters to use,
including where to go find its Kickstart file. The NFS server will serve up the
Kickstart file, which will tell our target machine to get its installation
media from the NFS server as well. Boot it up, poke, prod, and play!
