Chapter 7 Referrals, Aliases & Proxies (Chaining)

7.6 Historical Information Only

OpenLDAP Slurpd Style Replication (Obsoleted in 2.4)

This information describes slurpd style replication which was obsoleted in OpenLDAP 2.4. It is of historical interest and is maintained for those users (pre OpenLDAP 2.4) who may have legacy operational systems.

Slurpd style replication used a 'push' replication strategy and is obsoleted from version 2.4. Documentation is maintained here for historical reasons and for anyone marooned on older versions of OpenLDAP. It is configured and controlled as shown in Figure 7.2-1:

7.5-1 Slurpd Style Replication

When slapd (1) running the Master DIT (7) receives a modify operation (9) it updates the DIT and a timestamped copy of the transaction is written to the log file (2) defined in the master's slapd.conf (5) file replogfile directive.

Slurpd (3) when initially loaded obtains its operational parameters from slapd.conf (5). At a periodic time defined by replicationinterval slurpd will read the log file (2) defined by the replogfile directive and write the updates (10) to one (or more) slave DITs (8) defined by the replica directive(s) in slapd.conf (5).

The slave DIT (8) is a read only copy for all clients except a client which binds using the DN defined by updatedn. The slave server (4) returns the LDAP URI defined by updateref to all modify operations from clients (except those initiated using the DN in updatedn). Both updatedn and updateref are defined in the slapd.conf (6) file. The DN defined in updatedn in (6) MUST be the same as that defined in the replica directive (binddn= parameter) in (5) for this slave instance.

7.6.1 Slurpd Replication Errors (Obsoleted in 2.4)

If slurpd (3) fails to update the slave instance it creates a REJECTION file whose name is the same as that defined in the replogfile directive with .rej appended as shown below:

# slapd.conf reploglogfile directive
replogfile /var/log/ldap/slave1.log

# REJECTION file will be named
# /var/log/ldap/slave1.log.rej

Each error message in the REJECTION log file is the same as that used in the normal transaction log but is preceded by a line starting with the keyword ERROR containing the error message. An example is shown below:

ERROR: No such attribute
replica: slave1.example.com:389
time: 809618633
dn: uid=rsmith,dc=example,dc=com
changetype: modify
replace: description
description: clown
-
replace: modifiersName
modifiersName: uid=rsmith,dc=example,dc=com
-
replace: modifyTimestamp
modifyTimestamp: 20000805073308Z

To fix the errors either the slave may edited (in the case above to add a description attribute to the entry) or the REJECTION log may be edited to correct the errors (in the above example the replace: description line could be changed to add: description). There is no need to remove lines beginning with ERROR since these are ignored. After appropriate remedial action the REJECTION file may be re-applied by running slurpd in a single-shot mode (after stopping any currently running slurpd) using the following command:

slurpd -o -r /var/log/ldap/slave1.log.rej

# where -r defines the path to the REJECTION file 
# and -o indicates single-shot mode

Slurpd will apply the transactions in the defined (-r) file and exit. The normal slurpd should now be restarted.

Slurpd Configuration Examples:

Master slapd.conf configuration:

# slapd master
# global section - check file every 5 minutes
replicationinterval 300

# database section
database bdb
...
# simple security to slave located at ldap-rep1.example.com 
# with a cleartext password
# directive only used by slurpd
replica uri=ldap://ldap-rep1.example.com bindmethod=simple
  binddn="uid=admin,ou=admin,dc=example,dc=com" credentials=guess
	
# saves changes to specfied file
# directive used by both slapd and slurpd
replogfile /var/log/ldap/slavedit.log

Slave slapd.conf configuration (on host ldap-rep1.example.com):

# slapd slave
# global section - check file every 5 minutes


# database section
database bdb
...

# defines the dn that is used in the
# replica directive of the master
# directive only used by slurpd
updatedn "uid=admin,ou=admin,dc=example,dc=com"
	
# referral given if a client tries to update slave
updateref ldap://master-ldap.example.com

7.6.2 Syncing DIT before Slurpd Replication

Before slurpd replication can occur the DITs (Master and Slave(s)) must be known to be in the same state. A manual synchronization process must be performed first as itemised below:

Note: Slurpd was obsoleted in OpenLDAP 2.3 and is included here for completeness. In the case of OpenLDAP using syncrepl style replication a slave or multi-master can synchronize starting from an empty DIT. However, the process defined below may also be used and depending on the volumes involved may offer a more efficient (quicker) starting point.

Stop the LDAP server that will contain the master DIT instance. This is essential to prevent further DIT updates.
Create an LDIF copy of the DIT to be replicated using the appropriate off-line tools for the LDAP server.

(For OpenLDAP use slapcat).
Configure the server running the master DIT instance.

For OpenLDAP using slurp style replication - add the replica, replogfile and replicationinterval directives to the slapd.conf file. Do not restart the server at this time.

Note: If running OpenLDAP using the on-line configuration feature (cn=config) the server must be active.
Move the LDIF file created in step 2 above to the the server(s) that will run the slave or multi-master (applies to sysncrepl only) instance.
Stop the LDAP server that will run the slave or multi-master (applies to syncrepl only) instance .
Apply the LDIF file moved in step 4 to the server using the appropriate off-line tools for the LDAP server.

(For OpenLDAP use slapadd). Since the server has not been configured the -n (dbnum) option should be used.
Configure the server that will run the slave or multi-master (applies to syncrepl only) instance to act as either a slave or a multi-master (applies to syncrepl only).

For OpenLDAP using slurpd style replication only this will involve defining a database directive and all its associated directives (since the -n dbnum directive was used to add the DIT the order in which this is defined is very important - for replication specifically add the updatedn directive and the updateref directives.

Note: If running OpenLDAP using the run-time configuration feature (cn=config) the server must be active.
If a master-slave configuration, start the server running the slave DIT instance. Confirm it is working. If a multi-master configuration (applies to sysncrepl only) start this copy of the master and confirm it is running.
Start the server running the master instance of the DIT or the second master in a multi-master configuration (applies to sysncrepl only).
Perform a test transaction on the master (or one of the masters in a multi-master configuration - syncrepl only) and confirm it has been propagated to the slave (or second master - syncrepl only). If not, start looking at the logs. And panic. Always helps.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.