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).

______________________

Stewart Walters is a Solutions Architect with more than 15 years' experience in the Information Technology industry. Amongst other industry certifications, he is a Senior Level Linux Professional (LPIC-3).

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Reply to comment | Linux Journal

visit the site's picture

Undeniably imagine that that you said. Your favourite justification appeared to
be at the net the simplest factor to have in mind of.
I say to you, I certainly get annoyed even as people consider issues that they plainly
do not recognise about. You controlled to hit the nail upon the highest
as well as outlined out the entire thing with no need side
effect , other folks can take a signal. Will likely
be again to get more. Thank you

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix