Assuming you already have a DHCP server set up for your subnet, you will need to include something like the following in the configuration file, and restart the daemon:
allow booting;
allow bootp;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 155.888.813.103;
filename "linux-install/pxelinux.0";
}
The actual syntax will depend on your DHCP server software. next-server needs to be set to the address of the machine which you will be setting up as a PXE boot server (which could be the same as the DHCP server).
Set up an NFS server and export two directorys - one will hold the Kickstart configuration, and in the other put a copy of the RHE3L distribution. Something like:
/install/kickstart/
distros/WS/images/pxeboot/initrd.img
TRANS.TBL
vmlinuz
RedHat/TRANS.TBL
base/comps.rpm
comps.xml
hdlist
hdlist2
hdstg2.img
netstg2.img
product.img
stage2.img
TRANS.TBL
RPMS/*.rpm
Export the directorys to those subnets/machines that you want to be able to do installations on, and make sure that any firewall is configured to allow access.
First, ensure that your server has the syslinux, redhat-config-netboot, and tftp-server RHE3L RPMs installed (n.b. the last two RPMs are only included in the AS version of RHE3L). Configure xinetd, and any firewall, to allow access to files under /tftpboot via TFTP.
Next, you need to make a kernel available for PXE network booting, for example:
pxeos -a -i "RedHat Enterprise 3 WS" \
-p NFS \
-D 0 \
-s 155.888.813.103 \
-L /install/distros/WS \
RHE3WS
See man pxeos for more details. If your server doesn't have a graphical environment installed (why would it ?) you will get an error about not being able to run a GUI. Simply edit /usr/share/redhat-config-netboot/netboot_util.py and comment out the line import gtk.
When successful, the above command will create a directory called linux-install under /tftpboot, containing a RHE3WS directory which has the files initrd.img, ks.cfg and vmlinuz in it.
For some reason specification of a Kickstart config file when PXE booting has been disabled in the pxeboot command. You can either edit /usr/sbin/pxeboot to re-enable it, or follow the steps below. To configure the server to allow a client to PXE boot from it, do something like:
pxeboot -a -O RHE3WS \
-r 256000 \
-K nfs:155.888.813.103:/install/kickstart/ks.cfg \
client.mydomain.ac.uk
See man pxeboot for more details. Again, if you get errors about a GUI/gtk, edit /usr/sbin/pxeboot and comment out the line self.setSerial(gtk.FALSE).
The above command will have created a file in /tftpboot/linux-install/pxelinux.cfg/ whose name is the IP address of the client in hex, the contents of which should be something like:
default RHE3WS
label RHE3WS
kernel RHE3WS/vmlinuz
append initrd=RHE3WS/initrd.img \
console=tty0 \
ks=nfs:155.888.813.103:/install/kickstart/ks.cfg \
ramdisk_size=268235456
(lines wrapped for clarity). If you didn't edit /usr/sbin/pxeboot to re-enable processing of the -K argument, then the ks=... field will be missing from the boot parameters - just add it back in by hand.
The above expects there to be a Kickstart configuration file in /install/kickstart/ks.cfg on the NFS server. See this example for the fresh installation of new machines. N.B. the example uses a post-install script which is broken out of the configuration file, to allow it's use by multiple Kickstart setups whilst minimising the maintenance overhead - see Kickstart post-install script below.
Go into the BIOS and:
The machine will now initiate the PXE boot/install sequence. Once the installation starts, insert a blank floppy into the floppy drive. You can now safely leave the machine to it's own devices. Make sure that it at least gets past the stage where it identifies the mouse type - if the machine reboots at this point it is probably because the disk isn't large enough to handle the minimum layout specified in the Kickstart configuration file. Adjust the partition size settings and try again.
When the machine reboots at the end of the installation process it won't try to start over again, it'll hang trying to boot off of the empty floppy disk that you remembered to insert after the install started. Once the installation is complete, go back into the BIOS and disable PXE booting. For safety (if you don't have BIOS passwords enabled) you might also want to stop the PXE/TFTP server honouring boot requests by doing, for example:
pxeboot -d client.mydomain.ac.uk
Often you wind up needing many Kickstart configuration files, e.g. for different hardware configurations, but you still want all the machines to be configured the same, and you don't want to have to remember to change the all the config files every time you alter the post-install process. A simple solution is to have a generic post-install script in each Kickstart configuration file, that NFS mounts the "master script" and runs it (see the end of the example Kickstart config file. To further simplify the script management I have this script set a few useful values as environment variables, then it behaves like the Sys V Unix "init" boot sequence, running all the scripts in a given directory in listing order (unless they start with the letter NO). Each of these scripts configures one particular aspect of the system.
The expected layout under /install/kickstart is:
/install/kickstart/files/
scripts/
post-install
post-install is the "master script", scripts/ is the directory containing the specific post-install configuration scripts, and files/ is a directory containing files that are too large to be embedded in the scripts (e.g. sendmail.cf).
As the "master script" runs it stores the output from each of the other scripts in /root/post-install.log, which you should check for errors after the installation has completed, and the machine has rebooted.
These are the scripts that I am currently using (all IP addresses, and server names are fictional):
Although it seems like a lot of work to get all of this set up, once you are finished you will be able to perform consistent unattended installs of as many machines as your NFS server can cope with simultaneously. If they are old machines where you're already confident that the disks are OK, and you've turned off the bad block checking in the Kickstart configuration file, you should find that the whole process takes 15 to 20 minutes (if you're not doing too many machines at once).
Or at least it would do if the post-install didn't finish off by applying the several hundred patches that have been released to your local RedHat update satellite since the original RHE3L distribution shipped. This can take a couple of hours - and you'll be panicing that the install has hung while trying to determine the monitor type (the last thing that's displayed on the screen).
To get around this you can merge all of the latest updates into the distribution that you are doing the installation from. This script shows one way of doing it. The basic steps are:
There are three points to note: