Home > Articles > Operating Systems, Server > Linux/UNIX/Open Source

  • Print
  • + Share This
This chapter is from the book


Most people who use the Internet regularly probably use DHCP on a daily basis—even if they don't know it.

In a classic office network that does not use DHCP, each PC needs to be configured with a static IP address and all of the appropriate network settings: name servers, default routes, and so on. Once configured, the device reads its own local network settings when it boots and never forgets it. A DHCP-connected device, on the other hand, asks a central DHCP server for all that information each time it boots and leases an IP address from the server. From the perspective of the user, the PC automatically configures itself. That's what happens at home when you dial in to your ISP and are assigned an address.

Setting Up DHCP

For starters, you need to install the DHCP package on your system. Be aware that many distributions break up the DHCP package into a dhcp-server and a dhcp-client, though the names can vary. Debian's DHCP server package is called just dhcp, for example.

The server gets its information from the /etc/dhcpd.conf configuration file. Take a look at this very basic configuration file that I created on my test server, being sure to note the semicolons at the end of each entry:

# My DHCP configuration file

ddns-update-style            none;

default-lease-time           21600;
max-lease-time               21600;

option subnet-mask ;
option broadcast-address;
option routers     ;
option domain-name-servers,;
option domain-name           "mydomain.dom";
option root-path             "";
filename                     "/lts/vmlinuz-2.4.24-ltsp-1";

subnet netmask {
    range dynamic-bootp;

When I start a thin client or even a regular PC with this configuration file in place, the unit is assigned an IP address between and—that's the meaning behind the range dynamic-bootp parameter near the bottom. Take a look at the rest of these settings in turn, starting from the top:

  • ddns-update-style: DHCP version 3, which many of you will be using, requires this entry, regardless of whether you are using dynamic DNS updates on your system. This is a setting in transition with interim being the only functional setting. For now, you can set it to none as in my configuration example.

  • default-lease-time: Each host (MAC address) that obtains an address from the server leases that address for a specific time, measured in seconds. If the machine reboots inside of that time, it can be assured of getting the same IP address.

  • max-lease-time: When connecting, the client can actually request a specific lease time, also measured in seconds. You might choose to make both default and maximum lease times to be the same or you might allow a client to request a longer lease. This is your choice.

  • option subnet-mask: This is the subnet mask assigned to clients.

  • option broadcast-address: Next, we have the broadcast address. Unless you are subnetting, this is pretty basic.

  • option routers: This is essentially your default route to the Internet.

  • option domain-name-servers: You are free to list one to three name servers on this line. Separate each one with a comma.

  • option domain-name: Another self-explanatory parameter, this is the domain name for your network.

  • option root-path: As the name implies, this is the path to the server where the thin client will find the new root directory and all of the associated files to run. It may seem obvious, but take note of the fact that the LTSP server does not have to be the same machine as the default route or the name server.

  • filename: This is the filename of the kernel that the thin-client workstation will download once it connects. The kernel is downloaded via TFTP, which I'll cover shortly.

All that brings us back around to the paragraph that started it all.

subnet netmask {
    range dynamic-bootp;
    range dynamic-bootp;

Here, we are essentially defining a dynamic network and specifying the addresses available for DHCP clients just logging on. Before moving on, I should tell you that the range I've defined above is a little different than the one I showed you just a couple of paragraphs back. In this example, there are actually two ranges of IP addresses up for grabs, and you could include more, depending on how you, as the systems administrator, decided to partition out IPs.

One of the reasons I've separated this out is that everything above the subnet paragraph is considered global. There can be many different subnet paragraphs (as in a Class A or B private network). That said, some of the globals start with the word “option”. All of these options you see can be applied to the subnet you defined (a different default DNS address perhaps). Unless you include a different parameter, the global parameters apply.

The Webmin Approach

Configuring DHCP from the command line is actually fairly easy. Should you prefer a more graphical approach, Webmin provides a module with everything you need to configure and maintain your DHCP server. You can find DHCP configuration under Servers in Webmin, or you can just jump to it by entering the URL in your browser's location bar:


Assigning Fixed DHCP Addresses

As a longtime systems administrator, I always have had a love/hate relationship with DHCP. These feelings come from trying to work on a site where every PC in the entire organization is assigned an IP dynamically. When troubleshooting problems on the network, I also had the additional burden of trying to figure out which workstation belonged to a particular IP address.

Luckily, DHCP does allow for host-specific IP addresses. To me, if a workstation is always sitting in a fixed location—on someone's desk, for example—then a fixed IP is more than desirable. Configuring fixed DHCP addresses does require an additional step, but it's not that complicated. Have a look at the following additional paragraph in my DHCP configuration file:

host thinclient1 {
    hardware ethernet       00:50:41:01:82:35;
    fixed-address ;
    filename                "/lts/vmlinuz-2.4.24-ltsp-1";

Because this requires more work than assigning a range of addresses, why would you want to do this? Well, for one, this is more secure, because any host authenticating through your DHCP server is going to assign addresses only to those cards it knows about. For another, you know which workstation has which address, so support is easier, because you always know which unit you are talking about.

The host parameter represents the host name (thinclient1, in this case) for this client and should have an equivalent either configured on your name server or in your /etc/hosts file. Next, the hardware ethernet address is the unique hardware address (or MAC address) that I've mentioned in the past. You can get this information in a variety of ways. Dedicated thin-client units probably have it stamped on their backs. Ethernet cards have small labels identifying their MAC addresses. You can also see the MAC address by using the ifconfig command. The hardware ethernet address is the HWaddr information that you see on the second line below.

$ /sbin/ifconfig eth0
eth0      Link encap:Ethernet HWaddr 00:04:5A:5A:A8:2B
          inet addr: Bcast:

Let's get back to the dhcpd.conf file segment we were looking at and continue with the fixed-address parameter. This is, quite simply, the IP address that you want to assign to that client. Finally, the last line (the filename parameter) is the TFTP download path to the kernel that the thin client loads when it boots from the network. And that, my friends, is the perfect segue to a discussion of TFTP.

  • + Share This
  • 🔖 Save To Your Account