Warning about dhcpd-3.0.3

The most recent release of ISC's dhcp server (version 3.0.3) has a change in behaviour in how it handles the IP address of the TFTP server. In previous versions, the IP address of the TFTP server was defaulted to be the same as the IP address of the DHCP server (Unless otherwise specified by the next-server option). The new behaviour is to set the IP address of the TFTP server to all zeros. This causes a problem for Etherboot and some PXE bootroms.

Fortunately, there's an easy fix. If you are using ISC dhcpd v3.0.3, and you've noticed that your clients no longer can grab the kernel via TFTP, then you need to take a look at This document

DHCP Configuration

DHCP is the first protocol a terminal uses during the boot process. Thus, it is likely a good idea to configure this protocol first. The terminals will actually send a DHCP request to the server at 2 points during the boot process. Once to gather information about the kernel to download and the initrd. The next request will happen after the kernel starts executing, and is used to request an IP address, and gather information about the root filesystem that will be mounted over NFS.

There are several brands of DHCP servers. For LTSP, the standard is the ISC brand. However, there's also dnsmasq.

ISC DHCP Configuration

Here is a sample dhcpd.conf file:

dhcpd.conf example

   Warning: This site does not allow %INCLUDE% of URLs 

Download the above example by clicking here

The above example illustrates several important points. If you'd like to see an explanation of this example, line-by-line, then take a look at this line-by-line example.

Note: You may have to change option root-path to read "/opt/ltsp/debian_etch_i386" instead of "ipaddress://opt/ltsp/debian_etch_i386" to avoid nfsmount errors on the client.

Advanced dhcpd.conf configuration

If you have multiple terminal types, then you may find the Advanced DHCP Config to be of use. This will tell you how to use PXE and Etherboot in the same network.

If you plan to use ISA network boards in your terminals, please have a look at NetworkCards to find out which additional DHCP configuration needs to be done (option-128 and option-129).

Verify DHCP server is running

To verify the DHCP server is running on your LTSP server, use the following command:

   # netstat -apn | grep ":67 "

You should see a line like this returned:

   udp      0    0 0.0.0.0:67            0.0.0.0:*                    5958/dhcpd

If the DHCP server is not running, start it with the following command:

   # /etc/init.d/dhcp start

Then, double check to see if the server is running again, using the above netstat command.

Once the DHCP erver is running, you are ready to move on to configuring your TFTP server.

-- SteveSwitzer - 07 Dec 2004

Running DHCP on same server is NOT mandatory

Although it is advisable to have DHCP on same server on which LTSP runs but in case u want to have a different server which runs LTSP and u wish that client should acquie IP adresses from a pre existing DHCP server, in that case you should configure ur DHCP server and add one more line in the /etc/dhcpd.conf file

 next server 172.16.x.x(or your LTSP server IP Address) 

please note that you should add this line in the place where you are adding PXE Clients. In case your number of clients is small then you can specify all clients manually alongwith the MAC address , however if the number is large then you can do away with specifying the range of IP's. Now the clients will get the IP from the already running DHCP server and the tftp boot image would be fetched from the LTSP server. Without actually disturbing your DHCP.

-- DhirajGaur - 07 Jan 2005

Multiple DHCP servers on the same network segment

It is possible to have a DHCP server together with a second DHCP server for LTSP on the same network segment. I use this to boot PC's as 'standalone' workstations or LSTP terminals depending on whether they boot from their hard disk or with etherboot/PXE. The second DHCP server is not always running. This is some text in addition to http://www.ltsp.org/contrib/parallel_dhcp.txt by Bhaskar S. Manda.

I have used the following two methods successfully:

Use different port numbers for the DHCP servers

This will completely seperate the network traffic for the two DHCP servers, they will not see eachothers traffic. I have an ADSL modem with a DHCP server that I can not configure. Therefore, the DHCP server for LTSP uses a non standard portnumber: 1067.

Set up the client

For the first DHCP request by the client, you have to instruct the Etherboot (or whatever you are using) to make the request on port 1067. Go to http://www.rom-o-matic.net to make an etherboot image. Before you say 'GetROM', do 'Configure' and check the option 'alternate DHCP port 1067'. If you compile etherboot yourself you can choose any port you like.In 5.0.11 edit etherboot.h replace 67 and 68 with your own parameters.

Set up the server

Change the server startup script in /etc/init.d/dhcpd (or equivalent) to make the server respond to requests on port 1067. At the top of the file, add a line like

    DHCPORT="1067"

and edit the line that calls the server to something like

    dhcpd -p $DHCPORT ... (other options)

For the second DHCP request, edit the host entries in /etc/dhcpd.conf (or equivalent) to something like this:

    host ws001 {
               hardware ethernet  00:11:22:33:44:55;
               fixed-address  1.2.3.4;
               filename   ...;
   !!--->      option option-129 "DPORT=1067";
          # or option option-129 "NIC=3c509 IRQ=3 DPORT=1067"; # if you have a 3COM ISA network card
               }

or compile a new kernel that uses port number 1067. Don't forget to restart the DHCP server daemon.

Restrict one DHCP server to serve only known MAC addresses

If you want to boot from the network card you can not always set the card to use a different port number as suggested above. In that case you can also use the standard port 67 on the second (LTSP) DHCP server. However, you must make sure of the following:

1. On the second DHCP server (for LTSP), do not include a 'range' option that overlaps with that from the first DHCP server (you should not do that anyway). Only serve known MAC addresses.
2. On the second DHCP server, give out the same information for DNS, Gateway, Netmask etc as the first DHCP server for the case where a computer with known MAC address requests information (However, the IP adress given by the first or second DHCP server will be different).

Both servers will answer the DHCP request from one machine, giving some superfluous network traffic. The client will keep issuing DHCP requests until one of the DHCP servers gives a satisfactory answer (remember, the LTSP terminal will want a boot filename which it won't get from the first DHCP server).

It may also be possible to use the configuration options described in the topic 'advanced dhcpd.conf configuration' above by SteveSwitzer, to distinguish between network card boot request and ordinary standalone PC boot requests. I haven't worked that out, especially how to detect the second LTSP DHCP request (which looks like an ordinary DHCP request).

Both setups work on a small LAN with 6-7 clients who alternate between life as an LTSP terminal or a standalone PC.

-- TomWelter - 11 Jan 2005

Using IPCOP to configure DHCP in a network with LTSP

The GPLed IPCop distribution (latest and used is 1.4.6) can be combined in a network with the LTSP-Server and clients. Since IPCop usually runs on dedicated hardware (as firewall, DNS, dialup-server, ...) it can not be identical to the LTSP-Server. IPCop includes a ISC 3.0 dhcpd also and it is usually not a good idear to have 2 dhcpd on the same network.

So ltspadmin tool is told to not configure DHCP and IPCop takes over that part. With the Web-GUI you can setup your normal DHCP (and DNS) part and add a host sections for every ltsp-thin-client.

sample dhcpd.conf created by IPCops DHCP-service for LTSP

ddns-update-style none;
deny bootp;
authoritative;
option root-path "192.168.0.251:/opt/ltsp/i386";
option log-servers 192.168.0.251;
option broadcast-address 192.168.0.255;
subnet 192.168.0.0 netmask 255.255.255.0 #GREEN
{
        range 192.168.0.50 192.168.0.100;
        option subnet-mask 255.255.255.0;
        option domain-name "kais.local";
        option routers 192.168.0.250;
        option domain-name-servers 192.168.0.250;
        default-lease-time 3600;
        max-lease-time 7200;
} #GREEN
host fix0 # blauTC
{
        hardware ethernet 00:40:f4:8a:22:ae;
        fixed-address 192.168.0.55;
        next-server 192.168.0.251;
        filename "/tftpboot/lts/2.6.9-ltsp-3/pxelinux.0";
        option root-path "/opt/ltsp/i386";
}

The green (internal) interface hands out the next-server statement which in my example is the actual LTSP-server with IP .0.251, IPCop is 0.250

I have prepared a screenshot (at the bottom end of this page ?) to show what to type in the web-gui to achive this working dhcp-setup. In some cases it is necessary to explicitely type quote-sign (") around the string options, specially in the above global section (root-path). Some dhcp-options IPCop already knows and there is no need (and possiblity) to type that in manually.

In the range from 50 to 100 IPs are give by IPCops DHCPD also to fat clients, asking for DHCP information (like IP, gateway, DNS-Server). The LTSP-stations are booting via PXE, so they need a pxelinux.0 bootloader and the pointer to the next-server, the tftp-server.

-- KaiSchmidt - 14 Jun 2005

filename declaration

Different distributions and different tftp server daemons will set the tftproot variable in different places, and you will need to know what this is in order for your ltsp clients to find the kernel, and if the client misses this, you'll see TFTP Error 1 (file not found) at boot. Unfortunately, there are several places to find this declaration. Check /etc/inetd.conf, /etc/xinetd/tftp, /etc/sysconfig/atftp, or another location if you know it. You'll be looking for something similar to:

server_args   = -c -s /tftpboot

In the event that the server root is /tftpboot, your "file" declaration would appear as follows:

filename "/lts/vmlinuzfilename";

If the server root is /, then simply prepend /tftpboot to the above example.

ToDo^?: Specifics for different distros/tftpds

ISC DHCP Tricks

Automatically assigning hostnames, based on IP addresses

The ISC dhcp server can be told to do a lookup in the DNS or /etc/hosts file to find the hostname that goes with the IP address that is about to be handed to the workstation.

The magic goo to make it work is this statement:

   get-lease-hostnames   true;

That line should be in the global section of the dhcpd.conf file. Preferably up near the top, so it's easy to see when troubleshooting.

BUT! - this won't work, if the use-host-decl-names is also turned on.

Once you've turned the get-lease-hostnames flag on, and the use-host-decl-names flag off, the only other thing you need to do is make sure that you have your workstations entered in the /etc/hosts file, OR you've setup your DNS tables with reverses, so that it will return a hostname when a query is made.

You can test your DNS/hosts setup by saving this little Perl script and running it:

#!/usr/bin/perl -w
use strict;
use Socket;
die "usage:\n\n  $0 ip_addr\n\n" if !defined($ARGV[0]);   # Must have IP addr
my $hostname = gethostbyaddr( inet_aton($ARGV[0]), AF_INET ) || '(none)';
print("hostname: $hostname\n" );

Save the above perl script as a file named check_hostname, or download it here. make it executable, and run it like this:

./check_hostname 192.168.0.1

Substitute the IP address above with the address of the client you are trying to check. You should get an answer similar to this:

hostname: ws001.ltsp

If you get back an aswer of (none), then you need to fix either your /etc/hosts file, or your DNS Reverse mapping.

Automatically using the correct kernel for Etherboot or PXE

When a bootrom sends a DHCP request, it is expecting to get back several pieces of information. Things like IP address, server address, hostname and a filename. The filename is the name of the kernel image to be downloaded. The problem is, Etherboot bootroms and PXE bootroms need to download different types of images. An Etherboot bootrom can download a full Linux kernel with an initrd tacked on the end. This is a file that is typically 1.5 to 2mb in size. A PXE bootrom, on the other hand, is limited to a file no larger than 32kbytes. That's way smaller than even the smallest Linux kernel. PXE is instead expecting to grab a small bootloader known as a Network Bootstrap Program (NBP), which will then turn around and download the real kernel. For our use, pxelinux.0 is a great NBP, and works very will with Linux kernels and LTSP.

So, the trick is having dhcpd pass the correct filename to the bootrom, so that the correct file gets loaded. You could have separate sections in your dhcpd.conf file. Each workstation would need its own section, and it would be identified by the MAC address. This gets tedious when you have more than a few workstations on your network. The way around this is to use a range statement as documented in the previous section, to hand out a dynamic IP address from a pool of addresses. And then examine the vendor-class-identifier to see what type of bootrom is making the request.

  if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
    filename    "/lts/2.4.26-ltsp-2/pxelinux.0";
  }
  else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
    filename    "/lts/vmlinuz-2.4.26-ltsp-2";
  }

How to automatically pass the correct root-path, based on CPU architecture

If you have a network with multiple architecture thin clients, then you'll need to specify the correct root-path for each type of CPU. Currently, x86 and PPC architectures are supported with LTSP. Actually, the PPC isn't fully supported, but several people are working on it, and there are tarballs available, if you have an iMac that you want to boot as an LTSP thin client.

You could have a separate entry in the dhcpd.conf file for each workstation, specifying exactly which directory to use for the root-path. here's an example:

  # x86 client
  host ws001 {
    hardware ethernet   00:E0:06:E8:00:84;
    fixed-address       192.168.0.1;
    option root-path    "/opt/ltsp/i386";
  }

  # PPC client
  host ws002 {
    hardware ethernet   00:05:02:00:12:34;
    fixed-address       192.168.0.2;
    option root-path    "/opt/ltsp/ppc";
  }

In the example above, notice how the root-path entry has different values.

To use the above method, you'd need an entry for each workstation on your network. Not very much fun, when you have lots of them. So, here's a way you can do it automatically, by examining the vendor-class-identifier field that is sent in the request.

Here's an example:

  if substring (option vendor-class-identifier, 20, 3) = "ppc" {
    option root-path "/opt/ltsp/ppc";
  }
  else {
    option root-path "/opt/ltsp/i386";
  }

The above entry works, because ALL dhcp clients are supposed to send a vendor-class-identifier string as part of the DHCP request. And ISC's dhcpd version 3.0 and above can use conditional logic to do different things, based on the outcome of comparisons.

LTSP 4.1 uses dhcpcd as the dhcp client. dhcpcd builds the vendor-class-identifier by taking the full name of the kernel, and appending the system architecture to the end. In the case of the kernel that we tested with, the full vendor-class-identifier was "Linux 2.4.22-ltsp-1 ppc". The substring() function in dhcpd.conf uses an offset, and a length to grab a portion of the string. In our case, an offset of 20 and a length of 3 isolated the string "ppc". We then compare against that, to figure out which root-path to specify. I used Ethereal to watch the DHCP packets, and in the !DHCP Discover packet, I saw the value of the vendor-class-identifier.

dhcpd.conf example

Here's a complete example of a working dhcpd.conf file that can dynamically assign IP addresses to both x86 and ppc thin clients.

default-lease-time            21600;
max-lease-time                21600;
ddns-update-style none;
allow booting;
allow bootp;

option subnet-mask            255.255.255.0;
option broadcast-address      192.168.0.255;
option routers                192.168.0.254;
option log-servers            192.168.0.254;
option domain-name-servers    192.168.0.254;
option domain-name            "ltsp";
next-server                   192.168.0.254;

option option-128             code 128 = string;
option option-129             code 129 = text;

shared-network WORKSTATIONS {
  subnet 192.168.0.0 netmask 255.255.255.0 {
    #
    # Assign a dynamic address from the range of .100 to .253
    #
    range   dynamic-bootp   192.168.0.100   192.168.0.253;

    #
    # This logic handles the first DHCP request from the bootrom.  For
    # the Apple, we need to set the filename and vendor-class-identifier
    # But, for the others, we only need to set the filename
    #
    if substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC" {
      filename      "yaboot";
      option vendor-class-identifier "AAPLBSDPC";
    }
    else {
      if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
        filename    "/lts/2.4.26-ltsp-2/pxelinux.0";     # PXE NBP Boot loader
      }
      else {
        filename    "/lts/vmlinuz-2.4.26-ltsp-2";        # Etherboot kernel
      }
    }    

    #
    # This logic handles the second DHCP request.  This request is coming from
    # the /linuxrc script inside the initrd image.  We need to check the CPU
    # type, so that we pass back the correct root-path, so the correct root
    # filesystem gets mounted.  We wouldn't want a PPC trying to run x86
    # binaries now, would we?
    #
    if substring (option vendor-class-identifier, 20, 3) = "ppc" {
      option root-path "/opt/ltsp/ppc";
    }
    else {
      option root-path "/opt/ltsp/i386";
    }
  }
}

Thanks to Chuck Liebow and Jim Kronebusch for helping to figure out the required arguments for the iMac.

-- JimMcQuillan - 28 Jan 2005

Setting kernel parameters for a group of machines at once

The first half of MAC address is manufacturer code and the second half unique eternet adapter identifier. As network adapters of the same type have usually similar mac-addresses (that only differ within last 2 bytes), it would be wise to automatically configure hosts with same ethernet adapters at once. I needed to configure kernel parameters for a bunch of old machines with ISA ethernet adapters (RTL8019 = NE2000 clone). Machines with ISA ethernet adapters need IO address and IRQ passed to kernel from DHCP. All of the machines had mac-addresses beginning with 52:54:4c:00 and no other machine in the company has the same (check dhcp leases file for that). So I just configured all the adapters to IO address 0x300. The following example shows how to configure kernel for all those machines at once:

if substring(hardware,1,4)=52:54:4c:00
{
  option option-128 e4:45:74:68:00:00;
  option option-129 "NIC=ne IO=0x300";
}

-- AntiSullin - 03 Jun 2005

Changing ramdisk size

In order to change the size of /tmp, two operations are needed:

1) Pass the parameter RAMDISK_SIZE=xxxx in lts.conf (i.e. 8192)

2) Pass two parameters to dhcpd.conf:

    option option-128     e4:45:74:68:00:00;       # NOT a mac address
    option option-129     "ramdisk_size=8192";

Restart dhcp server, and your clients.

-- PerKristianNordnes^? - 5 Mar 2005

(thanx to jammcq and djf)

Adding options to windows dhcp to serve netvista

In windows dhcp add options 12 17 66 67 and create a new option 211

option 12 netvista1 option 17 10.10.10.254:/opt/ltsp/i386 option 66 10.10.10.254 option 67 /opt/ltsp/i386/vmlinux-2.4.19-LTSP-IBMNC option 211 tftp

Remember that windows pads the root-path with 000 so the path passed to the terminal is /opt/ltsp/i386000.

Creating option 211-from command line type netsh..this give a secondary command line.tpye dhcp server..gives a tertiary command line..type add OptionDef^? 211 BootProtocol^? STRING.

Windows dhcp for Macintosh to Use ltsp

The same technique can be used to add option 43 and 60 for Apple products.(It works! See Cpu Architectures section) cliebow@ltsp.org

Lease not found error

This could mean either:

• dhcp is not running
• you did not place a range declaration within your dhcpd.conf

---

• IPCOPs DHCP for LTSP:
  Click here for a screenshot of IPCOP's DHCP screen for LTSP

• dhcpd.conf.new: Fixed tftp path in dhcpd.conf

dnsmasq

An alternative to ISC dhcpd is dnsmasq, "a lightweight, easy to configure DNS forwarder and DHCP server." I (AndrewZ) have used it for over a year with LTSP 4.1, LTSP 4.2, and Etherboot. It's nice having DNS and DHCP in one, simple program.

Hopefully the configuration is self explanatory. The main settings in /etc/dnsmasq.conf include:

• domain
• dhcp-range
• dhcp-host
• dhcp-boot

The following are some sample settings for /etc/dnsmasq.conf:

domain=example.org
# for dynamic IPs
dhcp-range=192.168.0.220,192.168.0.250,120h
# settings for each terminal
dhcp-host=00:02:E3:10:5D:AA,ltsp017,192.168.0.117
# 192.168.0.52 is the IP address of the LTSP server
dhcp-option=17,"192.168.0.52:/opt/ltsp-4.2/i386"
# Etherboot
dhcp-boot=/lts/vmlinuz-2.6.16.1-ltsp-1,boothost,192.168.0.52
# PXE
dhcp-vendorclass=pxe,PXEClient
dhcp-boot=net:pxe,/lts/2.6.17.8-ltsp-1/pxelinux.0,boothost,192.168.0.52

-- AndrewZ - 19 Oct 2006

Another dnsmasq document

J D Freeman wrote another document describing how to setup dnsmasq. Her document can be found here.

Using Smoothwall to pass pxeboot options

Smoothwall v2.0 (outdated) http://community.smoothwall.org/forum/viewtopic.php?t=3196

Smoothwall v3.0 Polar has integrated PXE or Network Boot support. You can find it under Services > dhcp

VandyOmall Scenario: I installed LTSP on an existing Ubuntu. If you want to use Smoothwall or other dedicated router to pass PXE you should install ltps-server instead of ltsp-server-standalone. ltps-server is (also) useful when depending on an external DHCP server.

* what exactly needs to be filled where:

If you want to use Smoothwall router AS a PXE server, rather than passing options, there is Advanced TFTP Server Mod (GUI) (forum-topic) module available for Smoothwall v3.0.

Also available, Advanced TFTP server (forum-topic) for Smoothwall v2.0 (outdated)

quick post-dhcpd.conf-switching for ppc edgy chroot

authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.20 192.168.0.250;
  option domain-name "example.com";
  option domain-name-servers 192.168.0.1;
  option broadcast-address 192.168.0.255;
  option routers 192.168.0.254;
  option subnet-mask 255.255.255.0;
  if substring( option vendor-class-identifier, 0, 9 ) = "PXEClient" {
         filename "/ltsp/i386/pxelinux.0";
  }
  elsif substring (option vendor-class-identifier, 0, 9) = "AAPLBSDPC" {
        filename "/yaboot";
        option vendor-class-identifier "AAPLBSDPC"; 
        option vendor-encapsulated-options 01:01:02:08:04:01:00:00:01:82:
         05:                                    # length
         69:6d:61:63:34;                           # hostname
        option root-path "/opt/ltsp/powerpc";
    }
  else{
         filename "/ltsp/i386/nbi.img";
  }

##second dhcp switcheroo
if substring (option vendor-class-identifier, 0, 3) = "d-i" {
        option root-path "/opt/ltsp/powerpc";
}
else {
        option root-path "/opt/ltsp/i386";
 }

}