Jan 19 2008

Multi-OS Installation: Configuring the PXE Loader Environment

This article is one in a series detailing the implementation of a Multi-OS boot environment. While the article should stand on its own, it may be generally helpful to read the other articles in the series for the highest level of understanding.

The configuration of the PXE environment requires several components:

  • dhcpd server
  • tftpd server
  • PXE bootloader

Each of these items has customized configuration files which will be described below.

At the lowest level there is a dhcpd server listening for initial boot requests. ISC’s dhcpd server, specifically version 3.0.6 which was the current version at the time. On the production RHEL machine, version 3.0.5 from the RPM was used.

The full intricacies of configuring the dhcpd file can be found in the manpage, however at a minimum one needs to specify the following pxelinux entries and create a single subnet stanza for basic functionality.

# pxelinux settings
option space pxelinux;
option pxelinux.magic code 208 = string;
option pxelinux.configfile code 209 = text;
option pxelinux.pathprefix code 210 = text;
option pxelinux.reboottime code 211 = unsigned integer 32;

#and

# Servers subnet
subnet 172.16.32.0 netmask 255.255.254.0 {
authoritative;
option routers 172.16.32.1;
option subnet-mask 255.255.254.0;
option broadcast-address 172.16.33.255;
option domain-name “dhcp.karlmajer.com karlmajer.com”;
range dynamic-bootp 172.16.33.201 172.16.33.251;

ddns-domainname “dhcp.karlmajer.com”;
ddns-rev-domainname “dhcp.33.30.172.in-addr.arpa.”;

next-server 172.16.32.16;

filename “boot/pxelinux.0″;
site-option-space “pxelinux”;
option pxelinux.magic f1:00:74:7e;
option pxelinux.configfile “pxelinux.cfg”;
option pxelinux.pathprefix “/tftpboot/pxelinux/files/”;
option pxelinux.reboottime 30;
}

Several assumptions are made by that configuration snippet that will need updating:

  1. *There is no other dhcpd server on the network*
  2. The tftpd server is at 172.16.32.16
  3. The default router is at 172.16.32.1
  4. You’ve placed your pxelinux and configuration files in $TFTPROOT/boot directory
  5. Your network spans 2 class Cs, i.e. the 255.255.254 (/23) netmask and 33.255 broadcast.

After making these changes in the dhcpd.conf file, start up the daemon using the method of your choice, i.e., service dhcpd start, svcadm enable dhcpd, or even simply ‘dhcpd’ from the command line.

At this point there should be a functioning dhcpd server on the network. The next thing to configure is the tftpd server. Tftp-hpa version 0.42 was chosen as the tftp server of choice as it supported the remapping of file paths in requests, and offered tcp wrappers as an added bonus. Edit the tftpd.map file, often sought by tftpd at /etc/tftpd.map, and add the following lines to it:

rgi ^pxelinux.0 /boot/pxelinux.0
rgi ^pxelinux.cfg/ /boot/
rgi ^boot/pxelinux.cfg/ /boot/
rgi ^boot// /

This sets up the location of the boot files relative to the tftpd root which is specified on startup. In the environment that was built, all provisioning related items were placed in /export/install and the tftpd daemon was chrooted to this path. Therefore the pxelinux related files were in /export/install/boot, the menu files were in /export/install/hostmenu.

Now the tftpd server can be run from either inetd or as a standalone. Given the low usage of the install system, it was decided that tftpd would run from xinetd on RHEL ignoring the startup/shutdown costs of the daemon which may be noticeable were the install frequency several installs per hour rather than week.

Configuration of the inetd process will differ depending on the flavor of unix employed. On RHEL one need simply add a service definition to the xinetd.d directory and the xinetd daemon will pick it up on the next invocation. A sample RHEL stanza looks as follows:

# default: off
# description: The tftp server serves files using the trivial file transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware printers, \
# and to start the installation process for some operating systems. service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -m /etc/tftpd.map -v -v -v -s /export/install -t 10
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}

Note the explicit paths to the tftpd.map as well as the chroot to /export/install.

At this point we have a daemon to respond to our PXE requests, and we have a daemon to serve the content using the tftp protocol for the PXE requests. Now we need to supply the file to be served.

PXELinux from http://syslinux.zytor.com/pxe.php was used as the bootloader. The files were unbundled and placed into /export/install/boot. A menu file was created for pxelinux, the contents of which look like:

#Note, this menu starts the local disk, a memtest utility, and a Windows 2000 RIS #Installation.
default local
prompt 1
timeout 0
display /boot/install.msg
F1 /boot/install.msg

label local
localboot 0

label w50aa
kernel /images/W50AA/boot/w50aa.0

label memtest
kernel /boot/memtest
append -

For safety the default configuration chosen is to always favor the internal drives and only attempt to boot from the w50aa stanza on request. Now copy the menu containing the described data into the /export/install/boot/ (adjusted appropriately for your filesystem layout) and either name the file default, or name the file something else and symlink it to default.

At this point you should have the basic workings of a PXE loader environment. To test it first make sure that dhcpd is running:

ps -ef | grep dhcpd

Next use tftp to connect to localhost and request the file pxelinux:

tftp localhost
get pxelinux

Finally, reboot a host with a PXEboot capable network adapter and hit F12 to netboot.

Please let me know if you have any questions or comments.

>>> Karl

2 responses so far

Jan 15 2008

The General Infrastructure

The production system and the prototype were built on differing operating systems. Solaris 10 was initially used to allow for native Solaris Jumpstart procedures for Jumpstarting Solaris 9 on both Intel and Sparc. While migrating the completed prototype to RHEL 5.0 64, the Sparc Solaris issues, Sparc lacking  pxe boot loader capabilities to boot the operating system, were addressed by adding the appropriate stanzas to the dhcpd configuration files.

Unless otherwise specified, the Solaris installation was built from the source tarball, whereas the Linux installation came from an official RedHat RPM. This typically accounts for any version differences found between the two operating systems.

The network services required to fully netboot and install a machine are as follows:

  • At the lowest level there is a dhcp server listening for initial boot requests. ISC’s dhcpd server, specifically version 3.0.6 which was the current version at the time. On the RHEL machine, version 3.0.5, was used.
  • A tftp server is required to make the necessary files available. The files in question could be either pxe bootloaders for Linux and Solaris 10, the actual boot files in the case of Solaris 9, and the WINNT bootloader in the case of Windows. Tftp-hpa version 0.42 was chosen as the tftp server of choice as it supported the remapping of file paths in requests, and offered tcp wrappers as an added bonus.
  • An HTTP server is made available on the network to support Solaris jumpstart and Linux kickstart. The server offers media for both of the installation processes. The Apache that shipped with Solaris 10, Apache/2.0.58, and the Apache that shipped with RHEL 5, Apache/2.2.3, worked without a problem.
  • An NFS server is made available on the network to support Solaris installations including jumpstart. The server offers the entire media tree to any client that may desire it. Linux NFS servers may have problems with Solaris clients on anything other than NFSv2. The converse is not true.
  • To support windows, a CIFS needed to be offered. Samba was picked as it is the primary software of choice. Version 3.023c-2 was used on RHEL, 3.025c on Solaris.
  • RIS Services are required to properly net install a Windows machine. The software used was a python implementation of the binl server and is covered in greater detail in the Windows section.
  • Additionally, OS ISOs for every operating system to be installed must be obtained for both the Windows and Unix environments. This must be done in accordance to appropriate licensing for each respective OS.

The delivered product was capable of installing: Linux RHEL 3,4,5 32 and 64 bit variants, Solaris 9, 10, both intel and sparc at multiple releases, Windows 200[03], XP, both 32 and 64 bit including the unpatched and last two service pack levels. All in all a total of 27 windows offerings, 6 Solaris offerings, and 6 Linux offerings were available to any server or desktop that supported pxe booting.

More to come…

>>> Karl

No responses yet

Jan 15 2008

Building a Multi-OS Installation Host

Recently a client expressed interest in having me build an installation environment wholly contained on a single, preferably unix, server. The client had a requirement of being able to Kickstart any RedHat/Fedora Linux distribution they chose, Jumpstart Solaris 9 & 10 for Sparc and Intel, and net install a wide range of windows installations. The unix installation environments were straightforward, both taking advantage of the pxe bootloader environment. Linux uses pxelinux, and Solaris uses a Sun modified version of pxegrub. Windows was an entirely different issue.

After a bit of research I decided to use a combination of the theory behind the Ultimate Deployment Appliance (UDA) VM, available from http://www.vmware.com/appliances/directory/232 , VMWare’s appliances directory, as well as the information found on the RIS for Linux site located at http://oss.netfarm.it/guides/pxe.php around which the UDA is built.UDA v1.4 was already capable of booting a considerable variety of 32 bit windows images, however it lacked the ability to easily add 64 bit images. Additionally, there was no need for the pretty HTML GUI that the package offered and so they were omitted in favor of a pxelinux and pxegrub menu system.

This series of articles will describe how the system was built as well as provide examples on how to build your own. It will be written in several parts, at least one for each of Solaris, Linux, and Windows, and the Windows article may be further subdivided into several more.

More will follow as time permits.

>>> Karl

No responses yet