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.
is then started with the
switch. This switch tells
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
this manner is that it continues to use system resources even when it
is not needed. The preferred way to start
. To start it from
on a Slackware 96 Linux
system, uncomment the
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
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:
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.
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:
Now let's look at the parameters in a client entry:
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.
Normally a BOOTREQUEST packet is not forwarded between networks because it is transmitted from the client using the limited broadcast address - 255.255.255.255. According to the RFCs, the limited broadcast address should not be forwarded, though it is possible to configure some routers to do so. The CMU BOOTP software provides a BOOTP gateway program that eliminates the need to create a special router configuration and allows you to put the configuration server on a different subnet from the BOOTP clients. The BOOTP gateway is bootpgw .
If your system includes BOOTP software, you may already have bootpgw . Linux includes bootpgw . If your system doesn't have it, it will when you download and install the bootp-2.4.3.tar file.
bootpgw is run as an alternative to bootpd . Both of these programs listen to the same port. The inetd.conf entry for bootpgw is:
bootps dgram udp wait root /usr/sbin/bootpgw bootpgw 172.16.12.1
inetd listens to the bootps port and starts the bootpgw program when data is received on that port. (Adding the bootps port to /etc/services is covered above in the bootpd installation.) When bootpgw starts, it reads the hostname or address of the BOOTP server from the command line. In the example, the remote BOOTP server is 172.16.12.1. If the data received on the bootps port is a BOOTREQUEST packet, bootpgw retransmits the BOOTREQUEST as a unicast packet addressed directly to the remote configuration server.
At least one system on each subnet must run either bootpd or bootpgw to either reply to BOOTREQUEST packets or to forward them to a system that will. It is not possible to run both bootpd and bootpgw on one system and there is no reason to try. If the subnet has a local BOOTP server up and running, there is no need to forward BOOTREQUEST packets to another network. Use bootpgw on very small subnets that do not justify a local configuration server. On all other subnets, use a local BOOTP server.
As described in Chapter 3 , Dynamic Host Configuration Protocol (DHCP) is based on the Bootstrap Protocol (BOOTP). As you might expect, the DHCP enhancements are included in the bootp-2.4.3.tar file. Set the -DDYNAMIC option in the Makefile to compile the DHCP extensions into bootpd . The DHCP extensions add the following /etc/bootptab configuration parameters:
To use these parameters in the bootptab file, create a special entry in the file that begins with the string .dynamic- n . n in this string is a number from 1 to 32767. An example should make this clear. Assume that we want to automatically assign the addresses from 172.16.12.64 to 172.16.12.192, and that we want to manually assign the other addresses. We might enter the following in the bootptab file:
This defines a dynamic address group starting at 172.16.12.64. The group contains 128 (80 hex) available addresses. Tell clients assigned an address from this group to use 172.16.12.3 as a name server and to use 172.16.12.1 as a gateway.
When bootpd receives an address request from a client it creates an entry for the client using the information defined above, and physically appends that new entry to the end of the bootptab file. The first client request adds the following entry to the end of the bootptab file:
To assign the client a hostname instead of just an IP address, add hostnames to the domain server database for all of the addresses in the address group.
These extensions help bootpd provide services to DHCP clients. There are also software packages available that have been designed from the beginning to be DHCP servers.