deandra.homeip.net

OpenLDAP implements a single-master replication scheme. All slaves have read-only replicas. All LDAP modify operations are performed on the master, and then replicated to the slaves. This provides a much more robust and lightweight system than eDirectory.

The replication process is fairly robust. The replication damon (slurpd) gracefully handles unreachable hosts, and is multithreaded, so an unreachable replica doesn't cause trouble for all the others.

It is not unheard of for a replica to become inconsistent. This can happen for a variety of reasons. However, since the master is the only replica that can be modified, it is assumed that it is the authoritative source. (ie., if the master and slave disagree, the master is right and the slave is wrong.) This means that the fix for inconsistent replicas is simply to refresh the slave from the master. (ie., delete the slave replica and repopulate it en masse from the master.)

To set up replication, you must first configure the master to replicate. This is done by adding a replica line for each slave, and a replogfile directive. Examples:

replica uri=ldap://slave.example.com:389
binddn="cn=replicator,dc=example,dc=com"
bindmethod=simple credentials=secret

replogfile /var/spool/slurpd/replog

Then you need to configure the slave. You need to ensure the slave slapd configuration is identical to that of the master, including schemas, with the following exceptions:

• Do not include any replica directives. It is usually inappropriate for a slave to also be a master (replica "chains")
• Do not include a replogfile directive
• Include an updatedn line. This dn should match the dn given in the replica line of the master slapd's configuration. It should generally not be the same as the rootdn of the master database.
• Ensure the updatedn user can write to the local database.
• Use the updateref parameter to provide a referral for clients that support it. (the ones shipped with OpenLDAP do not, for security reasons.)

Now you must push an initial replica of the master database to the slave. slurpd keeps the replica in sync as changes are made, but it must be primed:

• Shut down the master and slave slapd's If you need to keep the master running during this process, you can restart it in read-only mode, but adding a readonly on directive to the slapd.conf and restarting slapd.
• Copy the database from the master to the slave. You can copy the database files from one server to another, but a more portable (and less bandwidth-intensive) way to do it is to use slapcat to dump the master database to an LDIF file, copy the LDIF to the slave (using perhaps scp), and then using slapadd to dump the LDIF into the slave database. Examples follow:

  slapcat -b "dc=example,dc=com" > /tmp/dump.ldif
scp /tmp/dump.ldif slave.example.com:/tmp/
ssh slave.example.com "rm -rf /var/lib/ldap/*"
ssh slave.example.com "slapadd -vb dc=example,dc=com < /tmp/dump.ldif"

Now, you can restart the master and slave slapd daemons.

Most of this information came from the OpenLDAP 2.3 admin guide, available at http://www.openldap.org/doc/admin23/