OpenLDAP Everywhere Reloaded, Part I

IP Address Assignment (DHCP)

If your LDAP clients can't receive an IP address to communicate with the network, they can't communicate with the OpenLDAP servers.

As such, configure ISC dhcpd to use failover pools between the two Linux servers. This ensures that IP addresses always are being handed out to clients. It also ensures that the two Linux servers are not allocating the duplicate addresses to the workstations.

The failover protocol for dhcpd is still in development by ISC at the time of this writing, but it is subject to change in the future. It works fairly well most of the time in its current state, and it's an important part of mitigating the risk of server failure for the directory service.

Create a new file on both linux01.example.com and linux02.example.com by running the command touch /etc/dhcp/dhcpd.conf.failover.

Separate the failover-specific configuration from the main /etc/dhcp/dhcpd.conf file. That way, /etc/dhcp/dhcpd.conf can be synchronized between both servers without destroying the unique configuration in the "failover peer" stanza. You never should synchronize /etc/dhcp/dhcpd.conf.failover between the two Linux servers.

On linux01.example.com, populate /etc/dhcp/dhcpd.conf.failover as follows:

failover peer "dhcp-failover" {
   primary;
   address linux01.example.com;
   port 519;
   peer address linux02.example.com;
   peer port 520;
   max-response-delay 60;
   max-unacked-updates 10;
   load balance max seconds 3;
   mclt 3600;
   split 128;
}

Notice that the parameters split and mclt are specified only on the primary server linux01.example.com.

max-response-delay controls how many seconds one server will wait for communication from the other before it assumes a failure.

split controls how many IP addresses available in the pool are pre-allocated to each DHCP server. The only valid values are from 0 to 255. As per the example, a split 128; value governs that each server takes 50% of the leases of the entire pool.

On linux02.example.com, populate /etc/dhcp/dhcpd.conf.failover as follows:

failover peer "dhcp-failover" {
   secondary;
   address linux02.example.com;
   port 520;
   peer address linux01.example.com;
   peer port 519;
   max-response-delay 60;
   max-unacked-updates 10;
   load balance max seconds 3;
}

Note: IANA has not allocated a reserved port number for ISC dhcpd failover at the time of this writing. This means the port/peer port numbers of 519 and 520 are subject to change.

On both linux01.example.com and linux02.example.com, you now should populate /etc/dhcp/dhcpd.conf with appropriate subnet information. For a very basic example of dhcpd.conf, see the example configuration files provided in the Resources section.

The crucial parameters to have in /etc/dhcp/dhcpd.conf are:

# excerpt of dhcpd.conf on linux01 and linux02

#-----------------
# Global DHCP parameters
#-----------------

# --- outputs heavily suppressed ----

#-----------------
# Failover parameters
#-----------------

include "/etc/dhcp/dhcpd.conf.failover";

# --- outputs heavily suppressed ---

subnet 192.168.3.0 netmask 255.255.255.0 {
   option routers 192.168.3.1;
   option subnet-mask 255.255.255.0;
   option broadcast-address 255.255.255.255;
   pool {
      failover peer "dhcp-failover";
      range 192.168.3.20 192.168.3.250;
   }
}

subnet 192.168.4.0 netmask 255.255.255.0 {
   option routers 192.168.4.1;
   option subnet-mask 255.255.255.0;
   option broadcast-address 255.255.255.255;
   pool {
      failover peer "dhcp-failover";
      range 192.168.4.20 192.168.4.250;
   }
}

These parameters alone are not enough to get a new DHCP server up and running. But, once a working dhcpd.conf is built for your network, add the above parameters for DHCP failover.

Restart dhcpd(8) on both linux01.example.com and linux02.example.com. Do this by running the command /etc/init.d/isc-dhcp-server restart. Check that the dhcpd(8) process did not abort by running ps -ef|grep dhcpd|grep -v grep.

If dhcpd(8) is no longer running, the problem is usually a typo. Re-check in dhcpd.conf and dhcpd.conf.failover that every opening parenthesis (the { character) has a closing parenthesis (the } character). Also check that lines not ending with open/closed parentheses are terminated by a semicolon (;).

Check /var/log/syslog on both servers for messages from dhcpd. When DHCP failover works, both servers should say the pool is "balanced", and that "I move from communications-interrupted to normal" or "I move from startup to normal".

Synchronize /etc/dhcp/dhcpd.conf from linux01.example.com to linux02.example.com every time you modify it. This can be done manually, via an rsync(1) script, via puppetd(8) or via the Network Information Service (though I don't recommend NIS—it's insecure and obsoleted by DNS/LDAP and rsync/puppet).

The drawback to the failover protocol is that it's a long way off from being considered mature. There are plenty of weird situations where the protocol fails to do its job. However, it will not be young forever, and when it does work, it works well. I recommend you monitor your logs and sign up to ISC's dhcp-users mailing list for assistance when things go wrong (see Resources for a link).