Best practices: PXE-Installserver

There are many ways to set up a PXE-Installserver, but if you give it a bit of thought you can come up with some quite nifty ideas. So without further ado here is a description of my setup.

My directory layout does not use the usual /srv/tftpboot directory. I wouldn’t have used that name anyway since TFTP is just a small part of the puzzle necessary because most PXE Option ROMs can’t natively boot from HTTP, FTP or NFS (yes, gPXE/iPXE does, but how many NICs come with gPXE/iPXE out-of-the-box? Not to mention LOMs where it’s part of the mainboard’s BIOS). If I were to use it, it would thus be called /srv/pxeboot, but I had a better idea.

In /srv/support I have a large collection of all files related to IT support, that is, setup files for drivers and applications, ISO images etc. Basically, if something is installable it goes here. This especially includes ISO images of various versions of Linux distributions.

Now take the case of Linux distributions. Conventionally you would mount the first ISO, copy its contents somewhere, say /srv/support/os122/CD1, copy the contents of the second ISO to CD2 etc. You would then also copy the Linux kernel and the initrd from the first CD somewhere below /srv/pxeboot/os122 and refer to them in your PXELinux configuration. The drawback: you need twice the space (once for the ISO, which you want to keep around for burning it to a DVD and another time for the extracted contents) and the kernel/initrd exist even three times (the third time below /srv/pxeboot).

I chose to go a different route. In my setup, I have the PXE Bootstrap pxelinux.0 and its config files located at /srv/support/pxelinux and all Linux distribution ISOs located at /srv/support/Linux/isos. Since /srv/support is a Samba share, I can easily access the ISOs and burn them from Windows. Below /srv/support/Linux/mnt I want directories named after the ISOs that each contains the contents of the respective ISOs.

I used to do loopback mount each and every ISO, requiring me to increase the number of available loop devices with the kernel command line option max_loop. Besides this extra option, this also blew up /etc/fstab and boot time since each ISO had to be mounted at startup just in case someone wants to access it someday.

Now I use autofs. A background process, the automounter watches defined directories and mounts stuff on-demand, just when it’s necessary, unmounting after a configurable period of time. In the config file /etc/auto.master I put:

/srv/support/Linux/mnt /srv/support/Linux/auto.linuxisos -v --timeout=300

This tells automount to create mountpoints beneath /srv/support/Linux/mnt using the rules defined in the separate config file /srv/support/Linux/auto.linuxisos. automount shall also be verbose about its operations in its syslog messages and unmount filesystems after a timeout of 300 seconds.

The config file /srv/support/Linux/auto.linuxisos contains lines like this:

openSUSE-12.1-x86_64 -fstype=iso9660,ro,loop :/srv/support/Linux/isos/openSUSE-12.1-DVD-x86_64.iso

The first column is the directory name to be created dynamically and used as mountpoint for the file in the third column. The second column contains the mount options, in this case indicating it’s an ISO 9660 Filesystem (you might encounter UDF ISOs, I didn’t so far) and it’s a read-only, loopback mount.

I do not maintain this file myself. Instead this is done by the script update_autofs_map.sh, which I wrote and which is run through the following /etc/crontab entry:

# Update /srv/support/Linux/auto.linuxisos regularly
0 0 * * *       root    ls /srv/support/Linux/isos/*DVD*.iso | /usr/local/sbin/update_autofs_map.sh >/srv/support/Linux/auto.linuxisos

Note that there is a drawback to this method (using autofs): you can’t combine autofs with NFS exports. Since the NFS server exports references to file handles on the local filesystem, which is the filesystem “below” /srv/support/Linux/mnt, and it has no idea of crossing filesystem boundaries when autofs has mounted ISOs in the subdirectories there. This means that you have to serve ISO contents via HTTP or (T)FTP.

1 comment

  1. In the auto.master(5) man page, a map-type of “program” is documented which could be used to generate the autofs map file dynamically rather than via cron. For an example of this, the auto.net map (I think this is included with autofs packages), which dynamically populates /net when you cd into it.

Leave a comment