This article will cover the installation of two OpenLDAP instances on different nodes. OpenLDAP will be configured to provide multi-master replication. Writes should still be sent to a single server, but both can be used for directory reads. In the event of failure of the write node, a load balancer or similar solution could fail writes over to the other node. OpenLDAP multi-master replication to me doesn’t seem like true multi-master replication, rather an active-active read LDAP database with hot standby of a write database. In this author’s opinion, (Oracle) Sun JDS and Forgerock OpenDJ offer far superior replication abilities.

This article will not cover OpenLDAP basics which you can already find within the administration guide available from OpenLDAP. Review the documentation available there before proceeding with this tutorial.

Servers being used, both running CentOS 6.3 x86_64:

Prerequisite Tasks

Unless noted, perform all steps on both nodes. Add to /etc/hosts in case there is a failure in DNS name resolution:

Install prerequisite packages:

Software Compilation and Installation

Presuming all source has been copied to each server and is available under /usr/local/src, compile and install the latest version of (Oracle) Berkeley DB (available from Oracle):

By default, this will install to /usr/local/BerkeleyDB.5.3 which is sufficient for our needs and standards of installing to /usr/local/<package>-<version>. Create a symlink to assist in upgrading the software, and to save keystrokes whilst administering the system.

Build OpenLDAP. 2.4.33 (again, available from OpenLDAP) was the latest available stable version at time of writing.

Run a quick test to ensure that the installation has been successful using the supplied default OpenLDAP configuration:

Our OpenLDAP installation is now complete on both nodes. We can now continue on to our configuration.

OpenLDAP Configuration

Modify ldap.conf as follows. This file can be used to set appropriate OpenLDAP environment variables:

Now, modify slapd.conf as follows:

In the previous section, we defined the location of OpenLDAP’s PID file and argument file and loaded in the following modules:

• syncprov.la - For synchronisation/replication
• accesslog.la - So we can easily configure the overlay for access logging should we choose to
• back_bdb.la - The BDB backend

Configure the BDB database definition section of the file as follows:

This is self-explanatory. Choose a sensible location for your LDAP data directory.

Before the indices section add:

This configuration will cause a BDB recovery checkpoint to be made after 10MB written to the directory, or 720 minutes, whichever occurs first. These values can be tailored to your specific recovery conditions. cachesize defined here will keep 50,000 directory entries cached in memory - again, adjust this for your site.

Next, configure BDB via the dbconfig mechanism. Add the following entries to slapd.conf noting that we are creating a 256MB in memory cache for BDB, and defining some sensible values around locks and log buffers, etc:

Now configure replication. It is important that the refreshAndPersist replication type is selected. This means that after the period specified in interval (which is when the initial replication connection will be made) the connection will persist and data will be refreshed almost immediately. As there is still some delay and fluidity in when the replication will occur, you should still only write to a single “preferred” master.

Let’s examine the above syncrepl configuration in a little more detail. Our rid is our replication ID which should be configured to the same value as the serverID specified previously. The LDAP provider is then defined (as we’re building a 2 node cluster, this should point at the other node). The binddn is specified, as well as the method and credentials to be used for the bind. type was covered above, but to reiterate: ensure you use refreshAndPersist for this. An initial replication interval of 10 seconds is specified. retry is set to 5 x 5 second retries. If those fail, 5 more retries 300 seconds apart are used. If they fail too, then syncrepl will stop retrying. A timeout period of 1 second is defined.

At the end of the file after index definitions, add the following configuration:

Note that we enable mirrormode by setting its value to TRUE, and the syncprov extension by way of the overlay directive. The syncprov-checkpoint here will update the contextCSN in the database after either 1000 successful write operations, or 60 minutes since the last time the contextCSN was written to the database. syncprov-nopresent is set to TRUE meaning that the consumer requesting the replication operation to indicate that it wishes to force a complete transfer of the DIT irrespective of any other settings or values - such as the Sync Cookie.

The configuration on gooby is identical, except a rid of 2 is specified, and the provider in gooby‘s slapd.conf is dolan.

As our credentials are in plaintext (we can fix this - view the manual pages for slapd.conf and slappasswd for details which are beyond the scope of this tutorial) so ensure that appropriate restrictive permissions are set on slapd.conf:

Create the directory for our database:

Start slapd in debug mode and ensure there are no errors:

If both OpenLDAP instances start correctly in the foreground, press ^C to shut them down.

Testing Multi-master Replication

Start OpenLDAP in normal daemonised mode:

Test by loading some LDIF data onto dolan. For now, we’ll just create an Organisational Unit (OU) and our main dc=tokiwinter,dc=com DN. Create the LDIF:

And load it:

Let’s make sure dolan has the entries loaded:

Let’s check that replication has occurred and that gooby also has the entries.

You may find that no entries are returned. This is because the base DN did not exist on gooby. Let’s add the base DN onto gooby, and restart slapd:

Now run the search again, and you should see the OU (which we didn’t manually add to gooby) correctly replicated:

Let’s now add another domain entry onto dolan and check for correct replication:

And check the status on gooby:

Perfect - the new domain entry has been successfully replicated! So - ensure your base DNs are created ideally before enabling replication for the first time to avoid this little hiccup.

To finish up, create an init.d script for slapd and use chkconfig to set it to start up when the system changes runlevel.

Conclusion

This article has shown how to build BerkeleyDB and OpenLDAP from source, and how to configure two OpenLDAP nodes to provide multi-master mirrormode replication between each other.

This configuration has many practical uses, and is widely used where simultaneous reads occur, and a node is specified as a writable master. The master can easily be failed over to the second node via a load-balancer or DNS when a failure occurs.