Openldap 2.3 to 2.4 upgrade broke replication.

Submitted by rmiddle on Wed, 06/10/2009 - 19:31

It looks like the old slurp interface is gone from Openldap 2.4. ( )


After a little searching I found. ( )


The text looks good.  Her server looks to be on Shaw Cable Modem.  So I copied what was import for me below.


Set up the provider


Add the following lines to the provider's slapd.conf:


rootdn "cn=admin,dc=example,dc=com
moduleload syncprov
overlay syncprov


These lines load the syncprov modules and activate the sync provider overlay. They also define a rootdn, which is needed for syncrepl to work.


syncprov-checkpoint 100 10


Checkpoint the contextCSN checkpoints on the provider. In this example, if more than 100 operations or 10 minutes have elapsed since the last checkpoint, a new one is made. (contextCSN indicates the synchronization state of the context. Checkpoints are done to ensure that replication is not duplicated if a server restarts.)


syncprov-sessionlog 100


Determines the size of the session log, which keeps track of the replication. The session log, in this example, will not exceed 100 entries.


You'll probably also want to set up an index for the attributes syncrepl uses, so synchronizations will go faster:


index objectclass,entryCSN,entryUUID eq


Set up the consumer


Add the following lines to your consumer's slapd:


index objectclass,entryCSN,entryUUID eq


rootdn "cn=admin,dc=example,dc=com"


syncrepl rid=123
retry="60 10 300 +"


This defines this directory as a consumer replica.


rid denotes which replica this is. I couldn't find this in the LDAP documentation, but rid probably must be unique among your replica set.


provider is the URI of the LDAP server you're replicating from.


type determines the type of replica search you're performing. refreshOnly Tells the consumer that you're going to pull updates at intervals, (and must be accompanied by an interval line.) refreshAndPersist tells the consumer to keep a persistent search open, so changes on the master are immediately replicated to the slaves.


retry tells the slave when to retry the master if the connection fails. The example above says, "retry every sixty seconds for ten tries, and then retry every 300 seconds indefinitely."


searchbase determines the search base of the sync search. This would be used to replicate only a fragment of the master database.


schemachecking tells the consumer whether or not to enforce the schema when updating from the master. If turned off, the loaded schema definitions on the master and slaves doesn't have to match exactly.


bindmethod, binddn, and credentials determine the user the consumer will bind to the provider as. The consumer uses the rootdn when updating its own database. You can specify any user here you want, so long as that user has the necessary access privileges to read the portion of the database you're trying to replicate. I used the rootdn for this, but that's probably not a good idea.

Category Tags
Linux LDAP, LDAP Replication