Configuring Linux is nowhere near as complex as the Windows environment. The low level Linux boot process is the same as Windows and Solaris, mainly a PXE request is dropped onto the wire. The dhcpd server accepts the request and issues a reply packet containing the IP address for the PXE client, the IP address of the next server to speak to, and the filename that the PXE client needs to request. The filename passed to the client used is the pxelinux bootloader which has been described in detail elsewhere.

The operating system makes use of the PXE Loader configuration. Please go read that post if you have yet to do so as general configuration details are described in that article.

The pxelinux menu entry needs to be updated to point to the linux kernel and an appropriate initrd stanza needs to be added to the menu entry as well. Substitute your own directory name for all instances of RHEL_4_U5_x86_32. That said, a sample entry in my environment looks like this:

label rhel4_32
kernel /images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz
append initrd=/images/RHEL_4_U5_x86_32/install/images/pxeboot/initrd.img nofb text noipv6 method=http://install/images/RHEL_4_U5_x86_32/install ksdevice=eth0

Remember that the tftpd server is chrooted to /export/install, so on the filesystem, the kernel resides in the base directory /export/install/images/RHEL_4_U5_x86_32/. The nomenclature used at the customer site allows multiple variants of RHEL 4 32 and 64 bit to live in the tree concurrently. Menu entries need only be added for each desired variant to install other versions.

Once the PXE menu entries have been added, the image can be prepared. This is nowhere near as complex as windows and requires only a few steps:

mkdir /export/install/images/RHEL_4_U5_x86_32 # or the path for the real vers.
mkdir -p /mnt/{1,2,3,4…N} # one per ISO
mount -o loop /path/to/iso/RHEL4-U5-i386-AS-disc1.iso /mnt/1
…
mount -o loop /path/to/iso/RHEL4-U5-i386-AS-discN.iso /mnt/N
# note, if you run out of loopback devices, add “options loop max_loop=256”
# to /etc/modprobe.conf and reboot.
tar -C /mnt/1 cpvf – | tar -C /export/install/images/RHEL_4_U5_x86_32/ -xpf -
…
tar -C /mnt/N cpvf – | tar -C /export/install/images/RHEL_4_U5_x86_32/ -xpf -

When finished, in /export/install/images/RHEL_4_U5_x86_32/ directory you should have the following directories: RedHat, SRPMS, install, images, isolinux, and a large number of README html files.

Confirm that the install/images/pxeboot directory contains a file called vmlinuz and the path matches what was indicated in the pxelinux menu entry and that the initrd.img is present in the same directory and that the paths to the images match:

ls -al /export/install/images/RHEL_4_U5_x86_32/install/images/pxeboot
grep RHEL_4_U5_86_32 /export/install/default

And that concludes all of the image prep necessary. The next item to configure is the apache server to ensure it can serve the http content as requested by the method= line of the menu entry. To do so we need to edit the configuration of apache and add a section allowing the webserver to find our content at /images/. Edit the httpd.conf and add the following in an appropriate location, or use this snippet to create a new file uniquely named along the lines of install.conf in the httpd/conf.d directory, if present.

Alias /images/ /export/install/images/
< directory >
Options Indexes FollowSymLinks
AllowOverride Limit
Order allow,deny
Allow from all
< /directory >

Apache needs to then be restarted or HUP’ed for the configuration changes to take effect.

All that is left now is to test the individual components:

First we need to make sure dhcpd is running:

ps -ef | grep dhcpd

Next we ensure apache is running;

ps -ef | grep httpd

Now we make sure that the repository is in proper order:

ls -al /export/install/boot/pxelinux # check for pxelinux
ls -al /export/install/boot/default # check for the default menu file for your entry
ls -ald /export/install/images/RHEL_4_U5_x86_32/ # make sure the RedHat dir is there
ls -ald /export/install/images/RHEL_4_U5_x86_32/install/images/pxeboot # should return 4 files: initrd.img, README, TRANS.TBL, vmlinuz

Now we make sure that tftp is working as expected (remember that tftp was chrooted to /export/install so everything will be relative to that path):

tftp localhost
cd images/RHEL_4_U5_x86_32/install/images/pxeboot
get vmlinuz

Next we ensure the apache is serving content properly.

wget http://localhost/images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz

if for some reason you dont have wget on your server you can do it manually using telnet:

telnet localhost 80
HEAD /images/RHEL_4_U5_x86_32/install/images/pxeboot/vmlinuz HTTP/1.0

This essentially concludes the work required to netboot a RHEL installer to the point where the user can make their desired selections to complete the installation.

After finishing the configuration, all that is left is to reboot the machine and netboot using the F12 key, and then select the newly added menu entry from the pxelinux menu when prompted. When the installer loads and begins the interactive installation you will need to walk through the installer options and answer any question.

If you have any problems or questions, drop me a line and I’ll see what I can do to help. If there is interest in the topic, moving from an interactive installation to the configuring of kickstart may be discussed in a later article should there be interest in the topic.

>>> Karl

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

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

After performing some tuning based on the walkthrough found here: http://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html, I was able to get the Win -> Mac communications up to 260 Mbit/sec. Just for comparison, unoptimized Mac<->Linux rates were 260Mbit/sec using OS X 10.4 and FC 6. I suspect that the limitations of my switch will cap my throughput at that rate.

Naturally, after having done all of the edits instructed in the tutorial, I discovered that dslreports.com offers a utility called DrTCP that drastically simplifies making windows TCP tuning changes.  At a minimum, you will need to restart the network interface that you’ve tuned, if you don’t simply reboot the machine altogether.

For aid in testing during the tuning I used the following utilities:

• Windows – http://www.pcausa.com/Utilities/pcattcp.htm
  •  A copy of the windows binaries are at http://www.genvmunix.com/ttcpzip.exe
• Mac & Linux – http://www.genvmunix.com/ttcp.c
  • The source compiled without any changes with a few warnings doing just a cc -o ttcp ttcp.c on both unix variants.
  • If I can find a netperf client as well I will rerun my testing using that utility.

When time permits, my final round of testing will involve directly connecting the machines together and see what kind of rates I can get by eliminating the switch altogether. For now I have settled with the 260 MBits/sec.

>>>Karl