Hack36.Install Linux Simply by Booting


Hack 36. Install Linux Simply by Booting

Let server daemons that are already running in your environment and a simple PXE configuration make installs as easy as powering on the target hosts.

Many distributions have some form of automated installation. SUSE has AutoYaST, Debian has Fully Automated Install (FAI), Red Hat has kickstart, and the list goes on. These tools typically work by parsing a configuration file or template, using keywords to tell the installation program how the machine will be configured. Most also allow for customized scripts to be run to account for anything the automated installation template hasn't accounted for.

The end result is a huge time savings. Though an initial time investment is required to set up and debug a template and any other necessary tools, once this is done, you can use a single template file to install all machines of the same class, or quickly edit a working template file to allow for the automated installation of a "special case" target host. For example, a template for a web server can quickly be edited to take out references to Apache and replace them with, say, Sendmail.

The only downside to automated installations is that, without any supporting infrastructure in place to further automate things, you have to boot to a CD or some other media and issue a command or two to get the installation process rolling. It would really be wonderful if installing Linux were as simple as walking through the machine room (or lab, or anyplace else where there are a lot of target hosts that need installing), powering on all the new machines, and walking away. Let's have a look at how this (and more!) can be accomplished.

In my examples, I'll be using the Red Hat/Fedora kickstart mechanism for my automated installations, but other tools can accomplish similar if not identical results.

4.9.1. Preparatory Steps

The list of components you'll need to configure may sound slightly intimidating, but it's much easier than it looks, and once you get it to work once, automating the setup process and replicating the ease of installation is a breeze. Before you do anything, though, make sure that the hosts you want to install have network cards that support a Preboot eXecution Environment (PXE). This is a standard booting mechanism supported by firmware burned into the network card in your server. Most server-grade network cards, and even recent desktop network cards, support PXE. The way to check is generally to enter the BIOS settings and see if there's an option to enable PXE, or to carefully watch the boot messages to see if there are settings there for PXE booting. On a lot of systems, simply hitting a function key during bootup will cause the machine to boot using PXE.

4.9.1.1. Configuring DHCP.

When you know for sure that your machines support PXE, you can move on to configuring your DHCP/BOOTP server. This service will respond to the PXE broadcast coming from the target node by delivering an IP address, along with the name of a boot file and the address of a host from which the boot file can be retrieved. Here's a typical entry for a target host:

 host pxetest { hardware ethernet 0:b:db:95:84:d8; fixed-address 192.168.198.112; next-server 192.168.101.10; filename "/tftpboot/linux-install/pxelinux.0"; option ntp-servers 192.168.198.10, 192.168.198.23; } 

All the lines above are perfectly predictable in many environments. Only the lines in bold type are specific to what we're trying to accomplish. Once this information is delivered to the client, it knows what filename to ask for and which server to ask for that file.

At this point, you should be able to boot the client, tell it to PXE boot, and see it get an IP address and report to you what that address is. In the event that you have a PXE implementation that tells you nothing, you can check the DHCP server logs for confirmation. A successful DHCP request and response will look something like this in the logs:

 Aug 9 06:05:55 livid dhcpd: [ID 702911 daemon.info] DHCPDISCOVER from 00: 40:96:35:22:ff (jonesy-thinkpad) via 172.16.1.1 Aug 9 06:05:55 livid dhcpd: [ID 702911 daemon.info] DHCPOFFER on 192.168. 198.101 to 00:40:96:35:22:ff (jonesy-thinkpad) via 192.168.198.100 

4.9.1.2. Configuring a TFTP server.

Once the machine is able to get an IP address, the next thing it will try to do is get its grubby RJ45 connectors on a boot file. This will be housed on a TFTP server. On many distributions, a TFTP server is either included or readily available. Depending on your distribution, it may or may not run out of inetd or xinetd. If it is run from xinetd, you should be able to enable the service by editing /etc/xinetd.d/in.tftpd and changing the disable option's value to no. Once that's done, restarting xinetd will enable the service. If your system runs a TFTP server via inetd, make sure that an entry for the TFTP daemon is present and not commented out in your /etc/inted.conf file. If your system runs a TFTP server as a permanent daemon, you'll just have to make sure that the TFTP daemon is automatically started when you boot your system.

Next, we need to create a directory structure for our boot files, kernels, and configuration files. Here's a simple, no-frills directory hierarchy that contains the bare essentials, which I'll go over in a moment:

 /tftpboot/ linux-install/ pxelinux.0 vmlinuz initrd.img pxelinux.cfg/ default 

First, run this command to quickly set up the directory hierarchy described above:

 $ mkdir -p /tftpboot/linux-install/pxelinux.cfg 

The -p option to mkdir creates the necessary parent directories in a path, if they don't already exist. With the directories in place, it's time to get the files! The first one is the one our client is going to request: pxelinux.0. This file is a simple bootloader meant to enable the system to do nothing more than grab a configuration file, from which it learns which kernel and initial ramdisk image to grab in order to continue on its way. The file itself can be obtained from the syslinux package, which is readily available for almost any distribution on the planet. Grab it (or grab the source distribution), install or untar the package, and copy the pxelinux.0 file over to /tftpboot/linux-install/pxelinux.0.

Once that file is delivered to the client, the next thing the client does is look for a configuration file. It should be noted here that the syslinux-supplied pxelinux.0 always looks for its config file under pxelinux.cfg by default. Since our DHCP server only specifies a boot file, and you could have a different configuration file for every host you PXE boot, it looks for the config file using the following formula:

  1. It looks for a file named using its own MAC address, in all-uppercase hex, prefixed by the hex representation of its ARP type, with all fields separated by dashes. So, using our example target host with the MAC address 00:40:96:35:22:ff, the file would be named 01-00-40-96-35-22-FF. The 01 in the first field is the hex representation of the Ethernet ARP type (ARP type 1).

  2. Next, it looks for a file named using the all-uppercase hex representation of the client IP address. The syslinux project provides a binary called gethostip for figuring out what this is, which is much nicer than doing it in your head. Feeding my IP address to this command returns COA8C665.

  3. If neither of these files exists, the client iterates through searching for files named by lopping one character off the end of the hex representation of its IP address (COA8C66, COA8C6, COA8C, COA8…you get the idea).

  4. If there's still nothing, the client finally looks for a file named default. If that's not there, it fails to proceed.

In our simple test setup, we've just put a file named default in place, but in larger setups, you can set up a configuration file for each class of host you need to install. So, for example, if you have 40 web servers to install and 10 database servers to install, you don't need to create 50 configuration filesjust create one called web-servers and one called db-servers, and make symlinks that are unique to the target hosts, either by using gethostip or by appending the ARP type to the MAC address, as described above.

Whichever way you go, the configuration file needs to tell the client what kernel to boot from, along with any options to pass to the kernel as it boots. If this sounds familiar to you, it should, because it looks a lot like a LILO or GRUB configuration. Here's our default config file:

 default linux label linux kernel vmlinuz append ksdevice=eth0 load_ramdisk=1 prompt_ramdisk=0 network ks=nfs:myserver:/kickstart/Profiles/pxetest 

I've added a bunch of options to our kernel. The ksdevice and ks= options are specific to Red Hat's kickstart installation mechanism; they tell the client which device to use for a network install (in the event that there is more than one present) and how and where to get the kickstart template, respectively. From reading the ks= option, we can see that the installation will be done using NFS from the host myserver. The kickstart template is /kickstart/Profiles/pxetest.

The client gets nowhere, however, until it gets a kernel and ramdisk image. We've told it to use vmlinuz for the kernel and the default initial ramdisk image, which is always initrd.img. Both of these files are located in the same directory as pxelinux.0. The files are obtained from the distribution media that we're attempting to install. In this case, since it's Red Hat, we go to the isolinux directory on the boot CD and copy the kernel and ramdisk images from there over to /tftpboot/linux-install.

4.9.2. Getting It Working

Your host is PXE-enabled; your DHCP server is configured to deliver the necessary information to the target host; and the TFTP server is set up to provide the host with a boot file, a configuration file, a kernel, and a ramdisk image. All that's left to do now is boot! Here's the play-by-play of what takes place, for clarity's sake:

  1. You boot and press a function key to tell the machine to boot using PXE.

  2. The client broadcasts for, and hopefully gets, an IP address, along with the name and location of a boot file.

  3. The client contacts the TFTP server, asks for the boot file, and hopefully gets one.

  4. The boot file launches and then contacts the TFTP server again for a configuration file, using the formula we discussed previously. In our case it will get the one named default, which tells it how to boot.

  5. The client grabs the kernel and ramdisk image specified in default and begins the kickstart using the NFS server specified on the kernel append line.

4.9.3. Quick Troubleshooting

Here are some of the problems you may run into and how to tackle them:

  • If you get TFTP ACCESS VIOLATION errors, these can be caused by almost anything. However, the obvious things to check are that the TFTP server can actually access the file (using a TFTP client) and that the DHCP configuration for the target host lists only a filename parameter specifying pxelinux.0, and doesn't list the BOOTP bootfile-name parameter.

  • If you fail to get a boot file and you get a "TFTP open timeout" or some other similar timeout, check to make sure the TFTP server is allowing connections from the client host.

  • If you fail to get an IP address at all, grep for the client's MAC address in the DHCP logs for clues. If you don't find it, your client's broadcast packets aren't making it to the DHCP server, in which case you should look for a firewall/ACL rule as a possible cause of the issue.

  • If you can't seem to get the kickstart configuration file, make sure you have permissions to mount the NFS source, make sure you're asking for the right file, and check for typos!

  • If everything fails and you can test with another identical box or another vmlinuz, do it, because you might be running into a flaky driver or a flaky card. For example, the first vmlinuz I used in testing had a flaky b44 network driver, and I couldn't get the kickstart file. The only change I made was to replace vmlinuz, and all was well.



Linux Server Hacks (Vol. 2)
BSD Sockets Programming from a Multi-Language Perspective (Programming Series)
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 162
Authors: M. Tim Jones

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net