![]() | s390, zseries: DHCP Support |
---|---|
On IBM's S/390 and zSeries platforms, DHCP only works on interfaces using the OSA and OSA Express network cards. These cards are the only ones with a MAC, which in turn is required for DHCP's autoconfiguration features. |
The purpose of the Dynamic Host Configuration Protocol is to assign network settings centrally from a server rather than configuring them locally on each and every workstation. A client configured to use DHCP does not have control over its own static address. It is enabled to configure itself completely and automatically according to directions from the server.
One way to use DHCP is to identify each client using the hardware address of its network card (which is fixed in most cases) then supply that client with identical settings each time it connects to the server. DHCP can also be configured so the server assigns addresses to each interested host dynamically from an address pool set up for that purpose. In the latter case, the DHCP server will try to assign the same address to the client each time it receives a request from it (even over longer periods). This, of course, will not work if there are more client hosts in the network than network addresses available.
With these possibilities, DHCP can make life easier for system administrators in two ways. Any changes (even bigger ones) related to addresses and the network configuration in general can be implemented centrally by editing the server's configuration file. This is much more convenient than reconfiguring lots of client machines. Also it is much easier to integrate machines, particularly new machines, into the network, as they can be given an IP address from the pool. Retrieving the appropriate network settings from a DHCP server can be especially useful in the case of laptops regularly used in different networks.
A DHCP server not only supplies the IP address and the netmask, but also the host name, domain name, gateway, and name server addresses to be used by the client. In addition to that, DHCP allows for a number of other parameters to be configured in a centralized way, for example, a time server from which clients may poll the current time or even a print server.
The following section gives an overview of DHCP without describing the service in every detail. In particular, we want to show how to use the DHCP server dhcpd in your own network to easily manage its entire setup from one central point.
Both a DHCP server and DHCP clients are available for SUSE LINUX. The DHCP server available is dhcpd (published by the Internet Software Consortium). On the client side, choose between two different DHCP client programs: dhclient (also from ISC) and the DHCP client daemon in the dhcpcd package.
SUSE LINUX installs dhcpcd by default. The program is very easy to handle and will be launched automatically on each system boot to watch for a DHCP server. It does not need a configuration file to do its job and should work out of the box in most standard setups. For more complex situations, use the ISC dhclient, which is controlled by means of the configuration file /etc/dhclient.conf.
The core of any DHCP system is the dynamic host configuration protocol daemon. This server leases addresses and watches how they are used, according to the settings as defined in the configuration file /etc/dhcpd.conf. By changing the parameters and values in this file, a system administrator can influence the program's behavior in numerous ways. Look at a basic sample /etc/dhcpd.conf file:
Example 19.30. The Configuration File /etc/dhcpd.conf
default-lease-time 600; # 10 minutes max-lease-time 7200; # 2 hours option domain-name "kosmos.all"; option domain-name-servers 192.168.1.1, 192.168.1.2; option broadcast-address 192.168.1.255; option routers 192.168.1.254; option subnet-mask 255.255.255.0; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.20; range 192.168.1.100 192.168.1.200; }
This simple configuration file should be sufficient to get the DHCP server to assign IP addresses in the network. Make sure a semicolon is inserted at the end of each line, because otherwise dhcpd will not be started.
The above sample file can be divided into three sections. The first one defines how many seconds an IP address is leased to a requesting host by default (default-lease-time) before it should apply for renewal. The section also includes a statement of the maximum period for which a machine may keep an IP address assigned by the DHCP server without applying for renewal (max-lease-time).
In the second part, some basic network parameters are defined on a global level:
The line option domain-name defines the default domain of your network.
With the entry option domain-name-servers, specify up to three values for the DNS servers used to resolve IP addresses into host names (and vice versa). Ideally, configure a name server on your machine or somewhere else in your network before setting up DHCP. That name server should also define a host name for each dynamic address and vice versa. To learn how to configure your own name server, read Section 19.6. “DNS — Domain Name System”.
The line option broadcast-address defines the broadcast address to be used by the requesting host.
With option routers, tell the server where to send data packets that cannot be delivered to a host on the local network (according to the source and target host address and the subnet mask provided). In most cases, especially in smaller networks, this router is identical to the Internet gateway.
With option subnet-mask, specify the netmask assigned to clients.
The last section of the file is there to define a network, including a subnet mask. To finish, specify the address range that the DHCP daemon should use to assign IP addresses to interested clients. In our example, clients may be given any address between 192.168.1.10 and 192.168.1.20 as well as 192.168.1.100 and 192.168.1.200.
After editing these few lines, you should be able to activate the DHCP daemon with the command rcdhcpd start. It will be ready for use immediately. You can also use the command rcdhcpd check-syntax to perform a brief syntax check. If you encounter any unexpected problems with your configuration — the server aborts with an error or does not return “done” on start — you should be able to find out what has gone wrong by looking for information either in the main system log /var/log/messages or on console 10 (Ctrl + Alt + F10).
On a default SUSE LINUX system, the DHCP daemon is started in a chroot environment for security reasons. The configuration files must be copied to the chroot environment so the daemon can find them. Normally, there is no need to worry about this because the command rcdhcpd start automatically copies the files.
As mentioned above, DHCP can also be used to assign a predefined, static address to a specific host for each request. As might be expected, addresses assigned explicitly always take priority over addresses from the pool of dynamic addresses. Furthermore, a static address never expires in the way a dynamic address would, for example, if there were not enough addresses available so the server needed to redistribute them among hosts.
To identify a host configured with a static address, dhcpd uses the hardware address, which is a globally unique, fixed numerical code consisting of six octet pairs for the identification of all network devices (for example 00:00:45:12:EE:F4). If the respective lines, like the ones in File 19.31. “Additions to the Configuration File”, are added to the configuration file of File 19.30. “The Configuration File /etc/dhcpd.conf”, the DHCP daemon will assign the same set of data to the corresponding host under all circumstances.
Example 19.31. Additions to the Configuration File
host earth { hardware ethernet 00:00:45:12:EE:F4; fixed-address 192.168.1.21; }
The structure of this entry is almost self-explanatory: The name of the respective host (host <host name>) is entered in the first line and the MAC address in the second line. On Linux hosts, this address can be determined with the command ifstatus followed by the network device (for example eth0). If necessary, activate the network card first: ifup eth0. The output should contain something like
link/ether 00:00:45:12:EE:F4
In the above example, a host with a network card having the MAC address 00:00:45:12:EE:F4 is assigned the IP address 192.168.1.21 and the host name earth automatically. The type of hardware to enter is ethernet in nearly all cases, although token-ring, which is often found on IBM systems, is also supported.
To improve security, the SUSE version of the ISC's DHCP server comes with the non-root/chroot patch by Ari Edelkind applied. This enables dhcpd to:
run with the permissions of nobody
run in a chroot environment (/var/lib/dhcp)
To make this possible, the configuration file /etc/dhcpd.conf needs to be located in /var/lib/dhcp/etc. The corresponding init script automatically copies the file to this directory upon starting.
The server's behavior with regard to this feature can be controlled through the configuration file /etc/sysconfig/dhcpd. To continue running dhcpd without the chroot environment, set the variable DHCPD_RUN_CHROOTED in /etc/sysconfig/dhcpd to “no”.
To enable dhcpd to resolve host names even from within the chroot environment, some other configuration files need to be copied as well, namely:
/etc/localtime
/etc/host.conf
/etc/hosts
/etc/resolv.conf
These files are copied to /var/lib/dhcp/etc/ when starting the init script. These copies must be taken into account for any changes that they require, if they are dynamically modified by scripts like /etc/ppp/ip-up. However, there should be no need to worry about this if the configuration file only specifies IP addresses (instead of host names).
If your configuration includes additional files that should be copied into the chroot environment, specify these under the variable DHCPD_CONF_INCLUDE_FILES in the file etc/sysconfig/dhcpd. To make sure the DHCP logging facility keeps working even after a restart of the syslog daemon, it is necessary to add the option "-a /var/lib/dhcp/dev/log" under SYSLOGD_PARAMS in the file /etc/sysconfig/syslog.
![]() | LDAP Support |
---|---|
In this version of the SUSE LINUX Server, the DHCP server as configured with YaST can be set up to store the server configuration locally (on the host which runs the DHCP server), or alternatively to have its configuration data managed by an LDAP server. |
The DHCP module of YaST allows you to set up your own DHCP server for the local network. The module can work in two different modes:
When starting the module for the first time, you will be prompted to make just a few basic decisions concerning the server administration. After completing this initial setup, the server is ready to go, with a configuration that should be suitable for most basic scenarios.
This expert mode lets you configure more advanced settings, such as those related to dynamic DNS, TSIG management, and others.
![]() | Navigating the Module, Obtaining Help |
---|---|
All dialogs of the DHCP module have a similar layout. The left part of the dialog window displays a tree view which lets you go to the individual sections of the configuration, while the corresponding configuration dialog is displayed to the right. To get help on the current dialog, click on the lifebelt icon at the left bottom of the window. To close the help window and go back to the tree, click on the icon depicting a tree structure. |
After launching the module for the first time, YaST starts a four-part configuration assistant. You can set up a basic DHCP server for your network by completing this assistant.
In the first step, YaST looks for the network interfaces available on your system, and then displays them in a list. From the list, select the interface on which the DHCP server shall listen. (see Figure 19.49. “DHCP Server: Selecting the Network Interface”).
A checkbox lets you define whether your DHCP settings should be automatically stored by an LDAP server. In the entry fields, you need to provide the network specifics for all of the clients to be managed by the DHCP server. These are the domain name, the address of a time server, the addresses of the primary and the secondary name server, the addresses of a print and a WINS server (in case you have a mixed network with both Windows and Linux clients), the gateway address, as well as the lease time (see Figure 19.50. “DHCP Server: Global Settings”).
In this step, you can configure how dynamic IP addresses should by assigned to clients. To do so, you need to specify an IP range from which the server can assign addresses to DHCP clients. All these addresses must be covered by the same netmask. You also need to specify the lease time during which a client may keep its IP address without having to request an extension of the lease. Optionally, you may specify the maximum lease time, that is to say the period during which the server reserves an IP address for a particular client (see Figure 19.51. “DHCP Server: Dynamic DHCP”).
After the third part of the configuration assistant, a last dialog will be shown where you can define how the DHCP server should be started. Selecting 19.52. “DHCP Server: Host Management”).
causes the DHCP to be started automatically as part of the boot procedure. If you select , the server needs to be started manually. To finish the server configuration, select . Alternatively, you can select in the tree to the left, to go beyond the basic setup and add a special configuration for individual hosts (see FigureInstead of using dynamic DHCP in the way described above, you can also configure the server to assign addresses in quasi-static fashion. To do so, use the entry fields provided in the lower part, to specify a list of the hosts to be managed in this way. Specifically, you need to provide the 19.52. “DHCP Server: Host Management”).
and the to be given to such a host, the and the (Token Ring or Ethernet). You can modify the list of hosts, which is shown in the upper part, with the buttons , , and (see FigureAfter having completed all the steps of the configuration assistant (with or without additional host management), select
to apply the configuration and to start the server.In addition to the configuration methods as discussed above, there is also an expert configuration mode which allows you to tweak the DHCP server setup in every detail. The expert configuration is started by selecting
in the tree view in the left part of the dialog.In this first dialog, you need to make the existing configuration editable by selecting 19.53. “DHCP Server: Chroot Jail and Declarations”). After selecting , you need to define the type of the declaration to be added. The button allows you to view the log file of the server, to configure TSIG key management, and to adjust the configuration of the firewall according to the setup of the DHCP server.
. An important feature of the behavior of the DHCP server is its ability to run in a chroot environment, or chroot jail, in order to secure the server host. If the DHCP server should ever be compromised by an outside attack, the attacker will still be behind bars in the chroot jail, which will prevent him from touching the rest of the system. The lower part of the dialog displays a tree view with the declarations that have already been defined. You can modify these with , , and . Selecting takes you to additional expert dialogs. (see FigureThis dialog allows you specify a new subnet with its IP address and netmask. In the middle part of the dialog you can modify the DHCP server start options for the selected subnet, by using the buttons
, , and . If you want to set up dynamic DNS for the subnet, select the button.If you chose to configure dynamic DNS in the previous dialog (see Section 19.6.8. “Dynamic Update of Zone Data”), you can now configure the key management for a secure zone transfer (see Figure 19.56. “DHCP Server: TSIG Configuration”. Selecting takes you to another dialog to configure the interface for dynamic DNS (see Figure 19.57. “DHCP Server: Interface Configuration for Dynamic DNS”).
You can now activate dynamic DNS for the subnet by selecting 19.55. “DHCP Server: Configuring Subnets”). Selecting again takes you back to the original expert configuration dialog.
. After doing so, use the dropdown menu to choose the TSIG keys for forward and reverse zones, making sure that the keys are the same for the DNS and the DHCP server. With the checkbox labeled , you can enable the automatic update and adjustment of the global DHCP server settings according to the dynamic DNS environment. Lastly, you can define which forward and reverse zones should be updated per dynamic DNS, specifying the name of the primary name server for each of the two zones. If the name server runs on the same host as the DHCP server, you can leave these fields blank. Selecting takes you back to the subnet configuration dialog (see FigureTo define the interfaces where the DHCP server should listen, and to adjust the firewall configuration, select SuSEfirewall2 to the new conditions (see Figure 19.58. “DHCP Server: Network Interface and Firewall”), after which you can go back to the original dialog by selecting .
-> from the expert configuration dialog. From the list of interfaces displayed, select one or more which should be attended by the the DHCP server. If clients in all of the subnets shall be able to communicate with the server, and if the server host also runs a firewall, the latter needs to be adjusted accordingly. To do so, select the checkbox labeled . YaST will now adjust the rules ofAfter having completed all of the configuration steps, close the dialog with
. The server is now started with its new configuration.For more information, the page of the Internet Software Consortium on the subject (http://www.isc.org/products/DHCP/) is a good source to read about the details of DHCP, including about version 3 of the protocol, currently in beta testing. Apart from that, you can always rely on the man pages for further help. Try man dhcpd, man dhcpd.conf, man dhcpd.leases, and man dhcp-options. Also, several books about DHCP have been published over the years that take an in-depth look at the topic.
With dhcpd, it is even possible to offer a file to a requesting host, as defined with the parameter filename, and for this file to contain a bootable Linux kernel. This allows you to build client hosts that do not need a hard disk — they are enabled to load both their operating system and their network data over the network (diskless clients), which could be an interesting option for both cost and security reasons.