Diskless booting

Diskless booting can be a handy and wonderful thing. Getting it to work involves tinkering with a variety of things that are not often tinkered with, and this is a short guide as to what these might be on a linux server.

etherboot

Etherboot lets you use a network card to do the diskless boot. With older cards you will be most happy if you have a ROM burner and some blank roms laying around. If you have a newer card, you may be able to flash etherboot into the card (a bit risky and I never have), or to set things up so that the on-card network booting code (probably PXE) can pull in etherboot and go from there. This "bounce boot" scheme is very nice and works great for the Intel ether pro 100 and I am sure other cards.

In either case, you can download etherboot and build rom images from the source, but you will probably find it more convienent to pick up images from rom-o-matic.net

DHCP

You will need to setup a /etc/dhcpd.conf file. Since I have done this once, I almost always have one laying around to copy into place as use asa starting point. Then you need to start the dhcp server (and make sure it always gets started when the system reboots) via: 
service dhcpd restart
chkconfig dhcpd on
If you hack on the config file, you must restart the server before your changes will have any effect. Very likely you will also need to open up port 67 on your firewall for this to work.

TFTP

The directory /tftpboot hold things that tftpd can dole out, and usually tftpd is restricted to only serve files from this directory for security reasons. You will have to turn on the tftp server (it should never be on by default), but editing the file /etc/xinetd.d/tftp and changing the disable line from no to yes, then: 
service xinetd restart

RSH

One particular diskless client (vxWorks) uses the remote shell protocol to transfer file. This operates on port 514 (another hole to punch in the firewall). It is good to write an iptables rule that only opens this port up to the local net, or better yet only to specific machines that need it. The rsh service must be activated in the same was as TFTP is, by editing /etc/xinetd.d/rsh and changing the disable line from no to yes, then: 
service xinetd restart
Security (such as it is with this protocol) is also controlled by the .rhosts file in the home directory of the user being used for file transfer, and is quite fussy about permissions and ownership of this file.

iptables (the firewall)

I used to run the monmotha firewall script, but more recently I decided to just monkey with the iptables scripts that come as part of fedora. It turns out the key file to dork with here is /etc/sysconfig/iptables. After fiddling with this to open up UDP port 67 (for DHCP/BOOTP) and UDP port 68 (for TFTP), you must as usual do: 
service iptables restart

When things go wrong

Even after doing the usual jive described above, things still were not working when I set up a new machine with Fedora Core 5. One thing that seems to be relevant is that the DHCPD server moved from ISC 3.0.2 to ISC 3.0.3 and the etherboot FAQ suggests that the following line is now needed with the 3.0.3 server: 
next-server 192.168.0.1;
This tells etherboot what the IP number of the TFTP server is. In general this is the same IP as the DHCP server (and this used to be the default).

The ethereal (aka wireshark) packet sniffer is sometimes a handy tool in these grim situations.

It is instructive to run the dhcp server in a console window when sorting out problems. To do this: 

service dhcpd stop
/usr/sbin/dhcpd -f -d
After doing this, I discover that some other machine on our subnet is sending DHCPINFORM messages telling my server that he is authoritative on my subnet and I am not. Apparently an authoritative server may send DHCPNAK messages to veto address assignments from non authoritative servers. Things work without my claiming to be authoritative (which could be done with a single line in the dhcpd.conf file), but it works just to ignore all the chatter from this self-important windows box.
Feedback? Questions? Drop me a line!

Uncle Tom's Computer Info / tom@mmto.org