Droms R. The DHCP handbook
Подождите немного. Документ загружается.
The server normally stores its lease database in a specific directory that varies from
system to system. You can use the
-lf switch to specify a different filename and
location for the lease database. All temporary filenames are also based on the speci-
fied name and directory.
When the server runs in the background as a daemon, it creates a file into which it
saves its process ID. This file is normally stored in the
/var/run or /etc directory,
again depending on the operating system. You can use the
-pf switch to specify a
different filename and directory.
The DHCP server does not continue to operate if it finds errors in the configuration
file because any errors could result in it badly misconfiguring clients on the network.
Therefore, after making changes to the configuration file, it’s a very good idea to
make sure that it’s correct before installing it. You can do this with the
-t switch.
The server tests the specified configuration file and prints error messages if it finds
errors. The exit status is zero if no errors exist, and nonzero if errors exist. Thus, shell
scripts and human users can use the
-t switch.
The DHCP server might operate incorrectly if you make changes to the lease data-
base while it is stopped and those changes are not correct. After making changes to
the configuration file, you should check that it is correct before installing it. You can
do this with the
-T switch; the server tests the specified configuration file and lease
file and prints error messages if it finds errors. The exit status is zero if no errors exist
and nonzero if errors exist.
The server normally prints a startup message with the version number, the copyright
information, and some information on how to contact the ISC. After you have seen
this information once, you probably don’t need to see it again (besides, it can make
the system startup messages look messy). To prevent this message from printing, you
use the
-q switch.
If you are having a problem with DHCP and want to be able to provide a tracefile so
that the problem can be reproduced in a controlled way, you can do this by starting
the DHCP server with the
-tf switch, which takes a filename as an argument. The
file must not exist when you start the server. The server logs to the tracefile as long
as it is running, and if the error you are trying to find occurs while the server is
logging to the tracefile, you have captured the error. In current versions of the ISC
DHCP server, tracefile logging does not work properly with failover, although a trace
file from a failover server can be useful for debugging problems not related to
failover. To play back a tracefile, use the
-play switch, followed by the name of the
file. When you are playing back a tracefile, you must specify the name of a lease file
to write to, and this lease file should not be your usual lease file because the lease file
will contain the results of the server trace playback, not your current lease database.
CHAPTER 14 The ISC DHCP Server246
018 3273 CH14 10/3/02 5:02 PM Page 246
Specifying Interfaces
On some operating systems, you can specify on which network interface or inter-
faces the DHCP server should respond to requests. This works correctly only on oper-
ating systems on which the DHCP distribution works with computers that have
more than one network interface. If the operating system doesn’t support a mecha-
nism by which the server can tell on which interface a packet arrived or determine
on which interface one will be sent, it is not possible to specify on which network
interfaces it should listen for requests.
The usual reason for specifying interfaces on the command line is that you are
installing a DHCP server on a machine that is directly connected to networks in two
different administrative domains. For example, in a home office configuration where
you have a DSL connection to the Internet, you might set up a Linux or NetBSD
system as a router between your ISP’s network and your home office network. Both
of these networks appear to be broadcast networks, but the DSL network is in your
ISP’s administrative domain, and your ISP will probably become very upset if you
begin providing DHCP service on its network. By specifying on the command line
that the interface attached to your home office network, you can prevent the DHCP
server from operating on the other network.
Another reason to specify interface names on the command line is that the DHCP
server might sometimes incorrectly identify a network interface as a broadcast inter-
face when it is not one. It might then attempt to use this interface, and it might be
unable to operate as a result. If this happens, you can explicitly list all your
computers’ broadcast interfaces on the command line, and the server should ignore
the misidentified interface.
Server Operation
After you have installed the server, you will need to do a variety of things. The first
task is to make sure the server is started automatically whenever the server computer
is started so that DHCP service isn’t stopped by system restarts. You might subse-
quently need to restart the server to install a new configuration, or you might need
to modify the lease database.
Starting the Server Automatically
After you configure the DHCP server to your satisfaction, you must arrange for it to
start automatically. On Unix and Unix-like operating systems, servers are normally
started by the
init daemon. The init daemon starts in one of three ways, depend-
ing on the operating system: from an
/etc/inittab file, from an /etc/rc shell
script, or from a separate script in the
/etc/rc.d directory.
Server Operation 247
018 3273 CH14 10/3/02 5:02 PM Page 247
You might be able to determine which of these three methods is used on your oper-
ating system by reading the man page for the
init program. If that doesn’t help,
look for an
/etc/inittab file; if one exists, that may be how servers are started.
There should be a man page for the
/etc/inittab file. If you invoke the server from
inittab, make sure to give it the -f switch because versions of init that use inittab
automatically start a new instance of a daemon when the old one exits. Without the
-f flag, the DHCP server always appears to have exited from the perspective of the
process that started it.
If no
/etc/inittab exists, look for an /etc/rc file. If such a file exists, it is probably
a shell script that invokes various daemons on startup. Most operating systems that
provide
/etc/rc scripts expect you to make local modifications in a local file, called
/etc/rc.local. Your entry in /etc/rc.local should look something like the one in
Example 14.15.
Example 14.15
if [ -f /etc/dhcpd.conf ]; then
echo -n ‘ dhcpd’; dhcpd >/dev/console 2>&1
fi
Shell Scripts
If no
/etc/rc exists, or if /etc/rc.d exists in addition to /etc/rc, you should add a
shell script to the
/etc/rc.d directory. These scripts operate differently on different
operating systems, so you should try to find documentation on how they work on
your operating system, or look at an existing script to see how it works. Example
14.16 provides a very simple example of a startup script.
Example 14.16
#!/bin/sh
if [ x$1 = xstart ]; then
dhcpd >/dev/console 2>&1
fi
if [ x$1 = xstop ]; then
kill `cat /var/run/dhcpd.pid`
fi
exit $?
CHAPTER 14 The ISC DHCP Server248
018 3273 CH14 10/3/02 5:02 PM Page 248
Startup Files
After you add a shell script to
/etc/rc.d, you must configure it to run. Systems that
use
/etc/rc.d generally order their startup with a set of /etc/rcn.d directories, in
which
n is a number representing a runlevel. Runlevel numbers aren’t standardized.
If you don’t know your runlevel and your documentation doesn’t say, you must look
through these directories to find the one where network daemons are started. When
you find that directory, you must create a symbolic link from the startup file you just
created into this directory.
The system startup script sorts the names of the files in this directory and executes
them in the sort order. Therefore, the filename you choose must appear later in the
sorted list of files than any scripts that must be executed before the server can start
(for example, the script that configures the network). Filenames in these directories
usually start with a letter, followed by a two-digit number. You should use the same
letter, a number that’s higher than the number of any network startup scripts your
script depends on (for example, the one that starts the name server), and then the
name of the real script file. So, for example, if you name your script
dhcpstart, and
your
rcn.d directory for network startup is rc3.d, you might type ln -s
/etc/rc.d/dhcpstart /etc/rc3.d/S57dhcpstart.
Updating the Server Configuration
When the server is running, you can freely update the configuration file without
disturbing it. After you update the file, you need to stop the server by using the Unix
kill command. If you are running the server out of /etc/inittab, it should restart
automatically. If you are not running the server out of
/etc/inittab, you must
restart it yourself by invoking it with the same arguments specified in the system
startup script.
You do not risk data loss when sending a
SIGTERM signal to the server; the server
never sends updates to the client for information that isn’t confirmed as written to
disk by the operating system.
Modifying the Lease Database
If, for some reason, you must make changes to the lease database, you must stop the
server before any such changes are made; otherwise, data loss is not only possible
but also likely. After you make the changes, you can restart the server, and it imme-
diately picks up any changes that you made to the file.
RPM Packages for DHCP
If you are using a distribution of Linux that is based on the Red Hat Package
Manager (RPM), you might want to install the RPM packages contributed by Charles
R. Anderson, which are available via a link from the ISC Web site. The RPM packages
Server Operation 249
018 3273 CH14 10/3/02 5:02 PM Page 249
were built on Red Hat Linux, and hence they integrate best with that distribution.
There are binaries built specifically for several recent Red Hat Linux distributions on
several architectures, as well as a source RPM (SRPM) so that you can build your own
binary packages for your particular system. The packages are distributed in subdirec-
tories that reflect the distribution name and version on which they were built.
Five binary RPM packages are provided, and you can install just the parts you need:
dhcp, dhcp-client, dhcp-server, dhcp-relay, and dhcp-devel. All packages require
the base
dhcp package. The others contain the DHCP client, DHCP server, DHCP
relay agent, and software development components, respectively. The package files
are named after the version of the ISC source from which they were built, plus an
RPM package release version and the architecture for which they were built. For
example, RPM package release 1cra of version 3.0 of the DHCP server built for the
i386 architecture is named
dhcp-server-3.0-1cra.i386.rpm. The SRPM for this
release is named
dhcp-3.0-1cra.src.rpm.
After you have chosen and downloaded the components you need for your particu-
lar distribution and architecture, you need to install them, by using the
rpm
command as follows:
rpm -i dhcp*-3.0-1cra.i386.rpm
If you are upgrading from a previous RPM package release, you should use the RPM
upgrade switch instead of the install switch:
rpm -U dhcp*-3.0-1cra.i386.rpm
If instead you choose to rebuild the binary packages from the SRPM, the basic
command is as follows:
rpm --rebuild dhcp-3.0-1cra.src.rpm
You have to set up your RPM build environment properly to build the packages; you
can do so as a normal user or as the superuser. In the latter case, the binary packages
are written to the
/usr/src/redhat/RPMS/architecture directory and should be
installed as explained previously in this section. You can use a couple options to
control how the packages are built:
Option Description
build_debug Builds the software with debugging information included
build_scd Creates an /etc/dhcpd directory for the configuration file
The options are specified as arguments to the RPM --define switch, with 1 as the
value. You can specify multiple
--define switches to combine the options. For
CHAPTER 14 The ISC DHCP Server250
018 3273 CH14 10/3/02 5:02 PM Page 250
example, to build the packages with debugging information and an /etc/dhcpd
directory, you would use this:
rpm --rebuild --define ‘build_scd 1’ --define ‘build_debug 1’ \
dhcp-3.0-1cra.src.rpm
After you have installed the RPM packages, you must configure them.
Documentation and sample configuration files are included in each package’s subdi-
rectory, under the system documentation directory (for example,
/usr/share/doc/dhcp-server-3.0 or /usr/doc/dhcp-server-3.0, depending on the
distribution).
init scripts are installed in /etc/rc.d/init.d, and they cause the
server, client, and/or relay components to start automatically upon bootup.
You can configure the
init scripts to pass different options to the actual programs by
editing
/etc/sysconfig/dhcpd for the server and /etc/sysconfig/dhcrelay for the
relay agent. The options for
dhcpd are shown in Example 14.17, and the options for
dhcrelay are shown in Example 14.18.
Example 14.17
# Where to read the configuration file from.
CONFIGFILE=”/etc/dhcpd.conf”
# Where to store the lease state information.
LEASEFILE=”/var/lib/dhcp/dhcpd.leases”
# Define INTERFACES to limit which network interfaces dhcpd listens on.
# The default null value causes dhcpd to listen on all interfaces.
#INTERFACES=”eth0”
INTERFACES=””
# Define OPTIONS with any other options to pass to the dhcpd server.
# See dhcpd(8) for available options and syntax.
OPTIONS=”-q”
Example 14.18
# Define SERVERS with a list of one or more DHCP servers where
# DHCP packets are to be relayed to and from. This is mandatory.
#SERVERS=”10.11.12.13 10.9.8.7”
SERVERS=””
# Define OPTIONS with any other options to pass to the dhcrelay server.
# See dhcrelay(8) for available options and syntax.
#OPTIONS=”-q -i eth0 -i eth1”
OPTIONS=”-q”
Server Operation 251
018 3273 CH14 10/3/02 5:02 PM Page 251
All the options except for the dhcrelay SERVERS option are optional. Examples 14.17
and 14.17a show the values that the init scripts use by default.
Before starting the DHCP server, you must first manually create the lease file as docu-
mented earlier:
touch /var/lib/dhcp/dhcpd.leases
Finally, you can start and stop the server manually with these commands:
/sbin/service dhcpd start
/sbin/service dhcpd stop
You can restart the server as follows:
/sbin/service dhcpd restart
The init script for dhcpd automatically tests the configuration file and the lease data-
base before it restarts the server, by invoking dhcpd with the
-t and -T switches.
This prevents a currently working server from being restarted if there is an error in
the new configuration file.
Summary
The ISC DHCP server is an open-source software product from the ISC. You can
download the source code for the server from the ISC Web site. You can also get
binaries for Red Hat Linux by using a link through the ISC Web site, and many oper-
ating systems include versions of the ISC DHCP server.
Before you can use the DHCP server, you must create a lease database and a configu-
ration file. The configuration file should define IP addresses to assign to clients, set
server operating parameters and provide options that are correct for the clients on all
network segments on which IP addresses may be assigned.
The server runs continuously as a background daemon. When the configuration file
is updated, the server must be restarted for the changes to take effect. If the lease
database is to be modified other than by the DHCP server, the DHCP server must be
stopped prior to modification and restarted afterward. If the server is being used in
production, it should be started automatically when the system on which it is
configured to run is powered on.
CHAPTER 14 The ISC DHCP Server252
018 3273 CH14 10/3/02 5:02 PM Page 252
IN THIS CHAPTER
• Configuring a DHCP Server to
Be Authoritative
• Configuring an Individual
Subnet
• Supporting Multiple Network
Segments
• Configuring Multiple IP
Subnets on Each Network
Segment
15
Configuring a DHCP
Server
This chapter demonstrates how to configure a DHCP
server to provide basic DHCP service, using the ISC DHCP
server as an example. Configuring a DHCP server involves
the following processes:
• Describing the network topology
• Setting up pools of addresses from which the server
can dynamically assign addresses to new clients
• Setting up basic services, some of which may vary
according to the topology
Chapter 16, “Client Identification and Fixed-Address
Allocation,” covers static address assignment and client
identification.
To work through this chapter, you need an understanding
of the basic server configuration file format the ISC DHCP
server uses, as described in Chapter 3, “Configuring the
DHCP Server.” You also need an understanding of IP
subnetting, as described in Chapter 4, “Configuring TCP/IP
Stacks,” and an understanding of DHCP message passing,
as described in Chapter 7, “Transmitting DHCP Messages.”
Configuring a DHCP Server to Be
Authoritative
The first thing you need to do with the ISC DHCP server
is to tell it whether it is authoritative. A DHCP server is
authoritative if it is administered by the person or persons
who run the networks it serves. A DHCP server is not
authoritative if it is administered by someone else.
019 3273 CH15 10/3/02 4:59 PM Page 253
CHAPTER 15 Configuring a DHCP Server254
Most DHCP servers are authoritative. The reason that you have to configure the ISC
DHCP server to be authoritative is that this makes it unlikely that someone would
accidentally configure the ISC DHCP server to be authoritative. A poorly configured
DHCP server that is configured as authoritative can wreak havoc on the network to
which it is attached.
It is important that you configure every official DHCP server as authoritative. If the
DHCP server is not authoritative, it will not tell clients when they have changed
networks, so clients that change networks will not get new IP addresses. To configure
the ISC DHCP server to be authoritative, you need to write an authoritative
statement, as shown in Example 15.1.
Example 15.1
authoritative;
Configuring an Individual Subnet
Even if a network is small, it always includes at least one subnet. This section uses an
example based on Ted Lemon’s home network. Ted’s network consists of a single
Ethernet segment behind a router that connects it to the Internet. There is one
subnet on the Ethernet segment, and it has a network number of 10.0.0.0 and a
subnet mask of 255.255.255.0. To define this subnet for the server, Ted writes a
subnet declaration, as shown in Example 15.2.
Example 15.2
subnet 10.0.0.0 netmask 255.255.255.0 {
}
This declaration simply informs the server that the 10.0.0.0 subnet exists; it does not
configure the server to answer requests for addresses on the 10.0.0.0 subnet. With
this information, the server has enough knowledge about the network that it can tell
when an address that a client requests is invalid. For example, if a DHCP client
broadcasts a
DHCPREQUEST message on Ted’s home network, asking for an IP address
of 10.20.0.15, which is a different subnet, the DHCP server responds with a
DHCPNAK
message, informing the client that the requested address is not valid.
019 3273 CH15 10/3/02 4:59 PM Page 254
SUBNET DECLARATIONS
Some DHCP servers do not require written subnet declarations in all cases. These servers
derive network topology information by looking at the IP addresses and subnet masks of the
interfaces connected to the DHCP server machine and then requiring the network administra-
tor to specify more information for networks to which they are not directly connected.
This might seem like a convenience at first. However, consider what is really happening: It is
not that the network administrator has not configured the DHCP server with topology infor-
mation, but rather that he or she has done so implicitly, rather than explicitly. As the network
grows—and the DHCP server configuration file grows with it—the subnet configuration infor-
mation the network administrator included implicitly when creating the configuration file
might change. If the administrator tries to move the DHCP server with such a configuration
file to a different subnet, the implicit part of the configuration changes, and the configuration
file no longer works..
For this reason, the ISC DHCP server requires that all subnets supported in the configuration
file be explicitly declared. The file is, thus, completely portable, and all assumptions about the
network topology are visible to other network administrators who might need to adjust the
configuration. Even if the DHCP server you are using does not require that all assumptions
about network topology be made explicit, you should make the topology explicit if at all
possible.
Address Allocation
To allow the server to assign addresses to clients, the network administrator must
define which addresses in the subnet are available for dynamic allocation. The
subnet in this example contains the addresses 10.0.0.0 through 10.0.0.255—a total
of 256 addresses. Of these, 10.0.0.0 and 10.0.0.255 are reserved as broadcast
addresses, so 254 IP addresses are available to be allocated.
The first step in setting up a subnet for dynamic allocation is to determine which of
these addresses the DHCP server should make available. It is also important to decide
whether to reserve some addresses for computers whose addresses must not change.
These computers either should not be configured using DHCP or should be config-
ured using static IP address assignments, which are described in Chapter 16. You
may also want to reserve some addresses for later use.
Reserved Addresses
On the subnet in this example, two fixed addresses are not allocated by DHCP: the
router’s address, 10.0.0.1, and the DHCP server’s address, 10.0.0.2. The DHCP server
does not necessarily need to know about these addresses, but it is important to
remember to exclude these addresses from the list of addresses that may be allocated
by the server.
Configuring a DHCP Server to Be Authoritative 255
019 3273 CH15 10/3/02 4:59 PM Page 255