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. ( http://www.openldap.org/doc/admin24/replication.html )

 

After a little searching I found. ( http://deandra.homeip.net/node/33 )

 

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
provider=ldap://provider.example.com:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=example,dc=com"
schemachecking=off
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=secret

 

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.
 

tax_term_view
Category Tags
Linux LDAP, LDAP Replication