Portable
JumpStart Environment II: Adding Kickstart
Michael R. Sbailo Jr.
In the first part of my "Portable JumpStart Environment" article
(http://www.samag.com/documents/s=9598/sam0504e/), I explained
how to take a Linux-based laptop and configure it to jumpstart Solaris
machines. This second part will explain how to take the same laptop
and give it the functionality to build Red Hat machines. By doing
this, it not only simplifies the amount of machines and administration
needed to support a heterogeneous build environment, but again does
so from a single portable source.
Overview
In addition to the basic requirements of DHCP, TFTP, and NFS,
you will need to add another component called PXE (Pre-boot Execution
Environment). Much like Sun systems use the OpenBoot firmware to
allow booting from their network devices, PXE works with your x86
system to provide that same functionality. This means that before
you begin, be sure your client is PXE aware. If you have older hardware,
you may want to look into Etherboot as an alternative. To enable
PXE on your client, simply enter your systems BIOS and turn it on.
With PXE enabled and listed as your primary boot device, your
system is ready to boot from the network. Once the request is received
by DHCP from your client, the server assigns an IP address and tells
PXE where to find its pxelinux.0 file. This binary is then transferred
through TFTP with instructions on the location of the netboot image.
This file contains the data stating which kernel and initial ramdisk
to load. It also gives the necessary information to NFS to mount
the install directory. After all of the above is accounted for,
your system will begin installing in the same manner as if you installed
it from CD-ROM. Figure 1 shows a basic idea of the process flow.
Now that you have a basic idea of the differences and similarities
of performing a network install with both Solaris and Red Hat, let's
put it all together.
Copying Software
Begin by copying the Red Hat software to your laptop. You may
want to consider structuring the file system under the same parent
directory used for Solaris. This will shorten your exports file
and keep you from having to add new entries. Once you have the CD-ROM
mounted, you can use dd to create the ISO image. You will
need to do this for each CD-ROM:
#dd if=/dev/cdrom of=/home/BUILD/RedHat/rhe3/rhe3-disc1.iso bs=32k
The ISO images alone are sufficient to complete the install; you do
not need to unpack the software. However, this makes upgrading the
software more difficult. To see the contents of the ISO, you can mount
it up with a loop-back device. You will need to do this anyway to
extract the correct initial ramdisk and kernel. Here is an example:
#mount -o loop /home/BUILD/RedHat/rhe3/rhe3upd6-i386-disc1.iso /mnt
Obtaining the Initial Ramdisk and Kernel
After you have mounted up the first ISO image with the above command,
you can copy the initial ramdisk and kernel to your /tftpboot directory.
The initial ramdisk is called initrd.img and the kernel is vmlinuz.
It's a good idea for you to rename both files with specific names
related to the version of Red Hat you're installing. This will also
allow you to store multiple copies of the kernel and initial ramdisk
for different versions of the OS:
#cd /mnt/images/pxeboot
#cp initrd.img /tftpboot/rhe3-initrd.img
#cp vmlinuz /tftpboot/rhe3-vmlinuz
The initrd.img file can be customized with specific modules to fit
your needs. Here is how to take a look inside:
#cp /tftpboot/rhe3-initrd.img /tmp
#cd /tmp
#gunzip -dc rhe3-initrd.img > initrd.ext2
#mount -o loop /tmp/initrd.ext2 /mnt2
PXE Configuration
After copying the correct initrd.img and vmlinuz files, you can
address the server-side requirements for PXE. As I said previously,
PXE is what makes network-booting a PC possible. The first file
you will need is called pxelinux.0. There are a couple of ways to
obtain this file. If you already have some Red Hat systems in your
environment, you can copy it from one of them. Here is how to find
it after you are logged into a running system:
#locate pxelinux.0
#cp /usr/lib/syslinux/pxelinux.0 /tftpboot
If you don't have an existing system, you can download the file from
http://syslinux.zytor.com. This site will also help to answer
any questions related to PXELINUX.
Creating a Netboot Image
The next file addressed in this process is the netboot image.
A netboot image is basically a bootloader that determines whether
your client will boot from the network or its hard drive. This file
defines things such as kernel, initial ramdisk, network device,
and method used for booting, as well as where to look for the kickstart
configuration file. An important note about the append line
within this file is that it needs to be entirely on one line. Line
breaks and continuation slashes will cause problems resulting in
failure of the boot process. You will need to create the directory
/tftpboot/pxelinux.cfg and then create the file. I'm using vi:
#mkdir /tftpboot/pxelinux.cfg
#vi default.netboot-rhe3
default linux
serial 0,38400n8
label linux
kernel vmlinuz
append ksdevice=eth0 ip=dhcp console=tty0 load_initial
ramdisk=1 initrd=initrd.img network
ks=nfs:192.168.0.1:/home/BUILD/RedHat/rhe3/ks.cfg
Another important piece to this file is how it is called via TFTP.
There are three methods to load this file. The first is a symbolic
link of your client's MAC address:
01-00-0F-1F-AB-39-19 -> default.netboot-rhe3
The next method is similar to how we set up a Sun to load its mini-kernel,
and that's with a Hex representation of your client's IP address:
0A0A0A0A -> default.netboot-rhe3
If you're going to use one netboot file for everything, just make
a symbolic link called "default":
default -> default.netboot-rhe3
Kickstart Configuration
The ks.cfg file is really the guts of your Red Hat configuration.
This is where you lay out your partition table, define which services
will be turned on or off, configure network settings, and ultimately
tell the system which software packages to load. You can also instruct
the system to perform any post-install scripts you may have. There
are many directives that can be used to customize your Red Hat install.
When defining disks, it's important to specify SCSI vs. IDE (sda,
hda). Here is a simple configuration to get you started:
# simple ks.cfg
install
nfs --server=192.168.0.1 -dir=/home/BUILD/RedHat/rhe3
lang en_US.UTF-8
langsupport --default en_US.UTF-8 en_US.UTF-8
keyboard us
mouse none
skipx
network --device eth0 --bootproto static --ip=192.168.0.11
--netmask=255.255.255.0 --gateway=192.168.0.1
--nameserver=192.168.0.1 --hostname=node1
rootpw --iscrypted $3$y606grSH$SUzlwxKc73Lhgn82yu1bnF1
firewall --disabled
authconfig --enableshadow --enablemd5
timezone America/New_York
bootloader --location=mbr
# 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 --all --initlabel
part /boot --fstype ext3 --size=100 --ondisk=sda
part / --fstype ext3 --size=1024 --grow --ondisk=sda
part swap --size=1000 --grow --maxsize=2000 --ondisk=sda
%packages
@ everything
grub
kernel-smp
kernel
%post
wget http://foo.server/post-install.sh
sh post-install.sh Services
Now that I've covered the specific pieces needed to complete a
Red Hat install over the network, I will explain the additional
configurations that need to be made to your existing services. As
you could probably tell from the information on PXE, the service
most changed in all of this is the TFTP server. There are several
new files you will need to add to its directory structure as well
as a new sub-directory. The files that should exist at the top level
of the /tftpboot directory are pxelinux.0, rhe3-initrd.img, and
rhe3-vmlinuz. Here is an example of what it might look like:
drwxr-xr-x 2 root root 152 Aug 31 2004 pxelinux.cfg
lrwxrwxrwx 1 root root 15 Aug 31 2004 initrd.img -> rhe3-initrd.img
lrwxrwxrwx 1 root root 12 Aug 31 2004 vmlinuz -> rhe3-vmlinuz
The /tftpboot/pxelinux.cfg directory is where you will put the netboot
image you have created. It is also where you will need to decide how
you will call that file:
lrwxrwxrwx 1 root root 20 Aug 31 2004 default -> default.netboot-rhe3
DHCP is the next service where you will need to make changes. In its
simplest form, you are basically defining the TFTP server and the
bootloader program. Below is a stripped-down version of the dhcpd.conf
file I used for testing:
ddns-update-style none; ddns-updates off;
## PXE Stuff
deny unknown-clients;
not authoritative;
option domain-name "example.com";
option domain-name-servers 192.168.0.9, 192.168.0.10;
option subnet-mask 255.255.255.0;
allow bootp;
allow booting;
option ip-forwarding false; # No IP forwarding
option mask-supplier false; # Don't respond to ICMP Mask req
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
}
group {
next-server 192.168.0.1; # name of your TFTP server
filename "pxelinux.0"; # name of the bootloader program
host node1 {
hardware ethernet 00:11:43:d9:46:29;
fixed-address 192.168.0.11;
}
}
Finally, depending on how you structured your file systems, the only
other service you may need to adjust is your NFS server. If you have
several versions of the OS you want to install, I recommend exporting
your data at a higher level so you don't need to keep adding to your
exports file. Here is the exports file I used:
/home/BUILD/RedHat *(ro,async,anonuid=0,anongid=0)
In addition to Solaris, you now have a system that is capable of installing
the Red Hat operating system over the network.
Conclusion
This robust configuration allows you to consolidate several aspects
of a heterogeneous environment and gives you the benefit of a single
point of administration.
I thank my co-worker Andreas Meyer for his contributions to this
article.
References
How to Install Red Hat Linux via PXE and Kickstart: http://www.stanford.edu/~alfw/PXE-Kickstart/
The SYSLINUX Project: http://syslinux.zytor.com
Michael Sbailo is part of a Systems Integration team for a
telecommunications company. His responsibilities include design
and maintenance of the systems build infrastructure as well as daily
operations tasks. He can be reached at: mike.sbailo@gmail.com. |