9.4 A BOOTP Server

A UNIX system becomes a BOOTP server when it runs the BOOTP daemon ( bootpd ). Some systems, such as Linux, include the daemon with the operating system. Other systems, like Solaris, do not. Even systems that provide bootpd as part of the system software do not run the daemon by default.

There are two ways to run the BOOTP daemon: it can be started at boot time from a startup script or it can be started by the Internet daemon , inetd . If the server has a large number of clients that are frequently rebooted, run bootpd from a startup file. Starting bootpd in this manner reduces the amount of "startup" overhead because the daemon is only started once. Possible lines for starting bootpd from the rc.inet2 file on a Slackware Linux system are:

if [ -f /usr/sbin/bootpd -a -f /etc/bootptab ]; then
      echo -n " bootpd"
      /usr/sbin/bootpd -s
fi

The code checks to make sure that the daemon and its configuration file are available. bootpd is then started with the -s switch. This switch tells bootpd to continue running and listening to the bootps port, and not to time out even if there is no activity on that port. The disadvantage of starting bootpd in this manner is that it continues to use system resources even when it is not needed. The preferred way to start bootpd is from inetd . To start it from inetd on a Slackware 96 Linux system, uncomment the bootps entry in the inetd.conf file and correct the path and daemon name. [10] The completed inetd.conf entry is:

[10] The Slackware 96 inetd.conf file attempts to start in.bootpd instead of bootpd , which is the actual name of the daemon on that system. I'm sure this will be corrected in later releases of Slackware.

bootps    dgram     udp  wait root /usr/sbin/bootpd    bootpd

This entry tells inetd to listen to UDP port 67 identified as bootps in the /etc/services file and, if it hears data on that port, to run /usr/sbin/bootpd as user root . Once the line is added to the inetd.conf file, send a SIGHUP to inetd to force it to read the new configuration, as in this example:

# 
ps -acx | grep inetd

  93 ?  S    0:00 inetd
# 
kill -HUP 93

If your systems does not include BOOTP software, don't panic: bootpd is available from the Internet. The same software found in the Linux system can be downloaded in the bootp-DD2.4.3.tar file. Download and untar the source code. su to root and compile the server software with make . The Makefile has entry points for several different UNIX architectures. (For our sample Solaris system, we use the sunos5gcc entry point.) If the software compiles without errors do a make install to install the executable daemon in the /usr/sbin directory. Do a make install.man to install the manpages in /usr/local/man .

You should define all network services, including BOOTP, in the /etc/services file. Add the following lines to your /etc/service file when bootpd is installed:

bootps            67/udp                          # bootp server
bootpc            68/udp                          # bootp client

Finally, make sure that you include bootpd in the /etc/inetd.conf file as shown earlier in this section. Once it is included and inetd is reloaded with a SIGHUP signal, you are ready to run.

Installing the daemon is only the beginning. The real challenge of managing a BOOTP server is providing the configuration information that clients need. The package found on Linux systems and in the bootp-DD2.4.3.tar file is the BOOTP daemon from Carnegie Mellon University (CMU). It has its own unique configuration commands. Other BOOTP server implementations use other configuration commands. However, the type of information provided by BOOTP is the same regardless of the implementation.

The CMU server reads its configuration from the /etc/bootptab file. The syntax used in this file is very similar to the syntax of the /etc/termcap and the /etc/printcap files. Each bootpd configuration parameter is two characters long and is separated from the other parameters by a colon. The general format of a bootptab entry is:

hostname:pa=value:pa=value:pa=value...

Where hostname is the hostname of the client, pa is the two character parameter name, and value is the value assigned to that parameter for this client.

Newline characters separate each client's entry. If an entry spans multiple lines, the newline character at the end of each line must be escaped with a backslash (\). Comments in the bootptab file begin with a sharp sign (#). Table 9.3 contains a list of the bootptab configuration parameters.

Table 9.3: bootptab Configuration Parameters

Parameter	Description	Example
bf	Bootfile	:bf=null
bs	Bootfile size	:bs=22050
cs	Cookie servers list	:cs=172.16.3.7
df	Dump file	:df=/var/tmp/bootp_db.dump
dn	Domain name	:dn=nuts.com
ds	Domain name servers list	:ds=172.16.35.5
ef	Vendor extension file	:ef=/usr/local/xyz.extensions
gw	Gateways list	:gw=128.2.13.1
ha	Hardware address	:ha=7FF8100000AF
hd	Bootfile directory	:hd=/usr/boot
hn	Send hostname boolean	:hn
ht	Hardware type	:ht=ethernet
im	Impress servers list	:im=172.16.8.12
ip	Host IP address	:ip=172.16.11.1
lg	Log servers list	:lg=172.16.12.1
lp	LPR servers list	:lp=172.16.6.6
ns	IEN-116 name servers list	:ns=172.16.12.6
nt	Network Time Protocol server list	:nt=172.16.50.30
ra	Reply address list	:ra=172.16.12.255
rl	Resource location servers	:rl=172.16.99.35
sa	TFTP server	:sa=172.16.12.1
sm	Subnet mask	:sm=255.255.255.0
sw	Swap server	:sw=172.16.12.56
T n	Vendor extension n	:T132="12345927AD3B"
tc	Template continuation	:tc=default1
td	Secure TFTP directory	:td=/tftpboot
to	Time offset	:to=18000
ts	Time servers list	:ts=172.16.12.1
vm	Vendor magic cookie selector	:vm=auto
yd	NIS domain name	:yd=nuts
ys	NIS server	:ys=172.16.12.1

Every parameter in Table 9.3 that has the word "list" in its description accepts a list of whitespace-separated values. For example, the name server list is defined using the ds parameter in this format: :ds=172.16.12.1 172.16.7.3: . One parameter in the table, hn , is a Boolean. If it is specified, the server sends the hostname from the bootptab entry to the client. As a Boolean hn does not take any values, but all the other parameters do.

Use these parameters to configure TCP/IP for each client on your network. The following sample bootptab file defines the domain name, name servers, the default routers, the Ethernet addresses, the hostnames, the IP addresses, the print servers, and the subnet masks for three different systems. (Don't worry about the details yet; each command will be explained later.)

#  /etc/bootptab file for nuts.com
acorn:\
     :hd=/usr/boot:bf=null:\
     :ds=172.16.12.1 172.16.3.5:\
     :sm=255.255.255.0:\
     :lp=172.16.12.1:\
     :gw=172.16.3.25:\
     :ht=1:ha=0080c7aaa804:\
     :dn=nuts.com:hn:ip=172.16.3.4:
peanut:\
     :hd=/usr/boot:bf=null:\
     :ds=172.16.12.1 172.16.3.5:\
     :sm=255.255.255.0:\
     :lp=172.16.12.1:\
     :gw=172.16.12.1:\
     :ht=1:ha=0800200159C3:\
     :dn=nuts.com:hn:ip=172.16.12.2:
hickory:\
     :hd=/usr/boot:bf=null:\
     :ds=172.16.12.1 172.16.3.5:\
     :sm=255.255.255.0:\
     :lp=172.16.12.1:\
     :gw=172.16.3.25:\
     :ht=1:ha=0000c0a15e10:\
     :dn=nuts.com:hn:ip=172.16.3.16

Notice that much of the information is repetitive. All of the clients use the same domain name, name servers, subnet masks, and print servers. Systems on the same subnets also use the same default routers. It is possible to define repetitive information in templates that are then referenced in individual client configurations. The following example uses a global template that defines the domain name, name servers, subnet mask, and print servers. The template is then referenced in each of the subsequent configurations by using the tc parameter.

#  /etc/bootptab file for nuts.com
defaults:\
     :hd=/usr/boot:\
     :dn=nuts.com:ds=172.16.12.1 172.16.3.5:\
     :sm=255.255.255.0:\
     :lp=172.16.12.1:\
     :hn:
acorn:\
     :tc=defaults:\
     :bf=null:\
     :gw=172.16.3.25:\
     :ht=1:ha=0080c7aaa804:\
     :ip=172.16.3.4:
peanut:\
     :tc=defaults:\
     :bf=null:\
     :gw=172.16.12.1:\
     :ht=1:ha=0800200159C3:\
     :ip=172.16.12.2:
hickory:\
     :tc=defaults:\
     :bf=null:\
     :gw=172.16.3.25:\
     :ht=1:ha=0000c0a15e10:\
     :ip=172.16.3.16:

The first entry, defaults , is the template. The remaining entries are client entries. The template defines information used by all of the hosts and the specific client entries define information unique to those hosts. Looking at the template and at one of the host entries shows a full configuration. First, let's examine the meaning of each parameter in the defaults template:

defaults:\

The name by which this template is referenced is defaults . A template can be assigned any name as long as it doesn't conflict with any hostname in the bootptab file.

:hd=/usr/boot:\

The first line of the defaults template defines the boot directory ( hd ). BOOTP clients can be diskless systems that boot from the server. The value provided by hd is used by a diskless system to retrieve the boot image. This directory is not used by our clients, but could be needed if a terminal server, router, or other diskless device was added to the network.

:dn=nuts.com:ds=172.16.12.1 172.16.3.5:\

This line defines the domain name and the addresses of the domain name servers. The dn parameter defines the domain name as nuts.com . The ds parameter defines the IP addresses of the name servers used on this network.

:sm=255.255.255.0:\

The sm parameter defines this network's subnet mask.

:lp=172.16.12.1:\

This parameter defines the IP address of an lpr server that is available to every system on the network.

:hn:

The hn parameter tells the server to send the hostname to the client. When this parameter is incorporated in the peanut entry as part of this template, the server sends the name peanut to the client. When it is incorporated in the entry for acorn , the name acorn is sent. Because this is the last line in the defaults template, it does not end with a backslash.

Now let's look at the parameters in a client entry:

acorn:\

The hostname associated with this client entry is acorn .

:tc=defaults:\

This tc parameter tells bootpd to incorporate all of the information defined in the defaults template into this client entry. To use multiple templates in a client entry, include multiple tc parameters. Exclude an individual parameter from a template by specifying the parameter preceded by an at-sign (@). For example, to exclude the lpr server parameter provided by the defaults template from inclusion in the acorn configuration, we could have added :@lp: to the acorn entry.

:bf=null:\

The bf parameter defines the name of the boot file for diskless systems. In the sample, the parameter intentionally points to a file that does not exist because the client has a disk and we want it to boot from its local disk. When a client has its own disk, a value is not required in this field. However, in this case, the value is commonly set to "null" to ensure that if the client accidently has a boot file value in its BOOTREQUEST packet, the value will be overwritten by the server.

:gw=172.16.3.25:\

The default gateway for this subnet is 172.16.3.25.

:ht=1:ha=0080c7aaa804:\

The ht parameter identifies the type of hardware used for the client's network interface. The hardware type is identified by a number or by a keyword. There are several possible values but only two are meaningful: ht will be either 1 for Ethernet or 6 for Token Ring. See the bootptab manpage if you're interested in the other, rarely used, values.

The ha parameter defines the physical hardware address associated with the client's network interface. The example shows an Ethernet address. The type of address provided must be consistent with the hardware type defined by the ht parameter. These two parameters always appear together in a bootptab file.

:ip=172.16.3.4:\

The IP address for this client is 172.16.3.4.

With only three clients in the example, the benefit of using templates may not be immediately clear. The benefits of saving time, reducing typing, and avoiding errors are clearer when a large number of systems are involved.

It is possible to configure a BOOTP server to handle a very large number of clients. However, if a large number of clients rely on a single boot server and all of the clients attempt to boot at one time, the server can be overwhelmed. This might happen in the case of a power outage. There are two mitigating fators: Because most clients cache the configuration provided by the server in a local disk file, they are not completely dependent on the server; and the BOOTP protocol includes back-off algorithms that avoid contention problems. Still, it is possible for an overloaded server to cause a significant delay when booting its clients. One way to avoid problems is to have several boot servers. One server for each subnet is a good design because it eliminates the need to pass BOOTP information through a router, which requires a special configuration.