deandra.homeip.net

Reasons

slurpd is deprecated and removed from OpenLDAP 2.4. This means that slurpd replication will probably break in the next Debian stable upgrade (lenny), as Lenny ships with 2.4. I decided to get a head-start, and get syncrepl-based replication working on my existing Etch systems before the upgrades come around.

Background

This example uses OpenLDAP 2.3; things have changed greatly in later releases. This example covers setting up a new replica; converting an existing replica from slurpd to syncrepl is similar; I'll note the differences when/if I see them. Don't assume I've got them all.

This example will also sync the entire replica, all contexts and attributes.

Organization

synrepl is consumer-side; updates are pull-based.

initial replica load is done automatically with syncrepl. The master slapd is the provider, the slave slapd is the consumer.

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.

Converting an existing slurpd-based replica to syncrepl

Probably the easiest way to do this is to provision the master/provider slapd for both slurpd and syncrepl replication, then reconfigure each slave, blow away the database, and restart the slave:

1. Provision the master slapd for syncrepl as above, and remove the replica lines for the replica you're going to convert. If you have any other replicas, leave them intact for now.
2. Restart the master slapd.
3. Stop the slave/consumer slapd.
4. Reconfigure the slave/consumer for syncrepl by removing the updatedn and updateref lines, and adding the syncrepl lines.
5. Delete the database on the slave/consumer (by default on Debian this means rm -rf /var/lib/ldap/*
6. Start the slave/consumer slapd. It should immediately pull a complete fresh replica from the master.