|
Chapter 9 Configuring Network Servers |
|
|
|
Chapter 9 Configuring Network Servers |
|
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.
| 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:
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.
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.
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.
This parameter defines the IP address of an lpr server that is available to every system on the network.
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:
The hostname associated with this client entry is acorn .
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.
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.
The default gateway for this subnet is 172.16.3.25.
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.
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.
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:
number
The
number
of addresses that can be dynamically assigned, written in hex.
mode
The
mode
in which dynamic addresses are written into the updated
bootptab
file. If the mode is 0, addresses are written as IP addresses. If the mode is 1, addresses must be written as hostnames. If a hostname can't be found for a dynamically assigned address, the address assignment is not made when the mode is set to 1. If the mode is 2, the dynamic address is written to the
bootptab
file as a hostname if there is a valid hostname for the address. If there is not, the IP address is used. Mode 2 is the default and usually should not be changed.
string
The
string
contains any additional configuration settings that should be provided to the DHCP clients in the form of
bootptab
parameters.
time
The amount of
time
that the client can keep the address. The client must renew its request for the address before the amount of time specified with the
dl
parameter has elapsed. If the client does not renew
its lease on the address, the server is free to assign the address to another client. If the
dl
parameter is not used, the address is permanently assigned.
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:
.dynamic-1:ip=172.16.12.64:T254=0x80:T250="gw=172.16.12.1:ds=172.16.12.3"
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:
172.16.12.64:ha=0080c7aaa804:gw=172.16.12.1:ds=172.16.12.3
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.
|
|
|
|
| 9.3 Network Information Service |
|
9.5 DHCP |