Nick (gagravarr) wrote,

Enabling replication with OpenLDAP 2.4 on RHEL 6 with cn=config (olc....)

The last time I setup replication on OpenLDAP, it was on Debian with a single slapd.conf file. This time both machines were running Redhat Enterprise RHEL 6, using the OLC / cn=config style of configuration, with ldif files. I found quite a lot of information on how to setup replication, quite a lot on using ldap modify to change cn=config, but not a lot on using cn=config ldif files for replication. Having worked out which bits to follow and which to ignore, I thought I'd document it for others to hopefully learn from!

This guide assumes you're familiar with OpenLDAP replication, want to use Syncrepl, are using RHEL 6 for your master and your slave(s), and have already got your directory working on the master, set permissions etc.

Step 1 - Create a read only replication account

Using your favourite tools, create a new account (objectclass = account) in your directory, with a suitable name (eg uid=replication or some such). Set a secure password on it, and make a note of that. Next, edit /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif and grant read permissions to this user on all attributes. Any it can't see won't get replicated, so tweak your olcAccess statements as needed. A basic setup would look like:
olcAccess: {0}to attrs=userPassword
  by self =xw
  by dn.exact="uid=pwreset,dc=example,dc=org" =xw
  by dn.exact="uid=replicate,dc=example,dc=org" read
  by anonymous auth
  by * none
olcAccess: {1}to *
  by anonymous auth
  by self write
  by dn.exact="uid=replicate,dc=example,dc=org" read
  by users read
  by * none

Step 2 - Enable the syncprov module

On all machines (master and slaves), create a new file /etc/openldap/slapd.d/cn=config/ called cn=module{0}.ldif . Into it place:
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
Note that if you're on a 32 bit system, you'll need /usr/lib/openldap not lib64. This file will trigger the loading of the syncprov module, and the bdb one if needed. If you want to add more modules later for other things, you can either add them to the ordered olcModuleLoad list, or add cn=module{1}.ldif and list them in there

Step 3 - Turn on syncprov for each directory

syncprov needs to be enabled for each directory, which in the default config would mean for olcDatabase={2}bdb, and possibly olcDatabase={0}config too. For now, I've opted to enable syncprov for both, but only pull the former, but I may change that in time.

Firstly, create two new directories, /etc/openldap/slapd.d/cn=config/olcDatabase={0}config/ and /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb/ - these directories should match with a similar .ldif file of the same name, just without the .ldif. Into each one, create a file olcOverlay={0}syncprov.ldif which will hold the syncprov config for each directory. The file should look something like (depending on your chosen settings):
dn: olcOverlay={0}syncprov
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
# Sync Setup for the main LDAP Database
olcOverlay: {0}syncprov
# Sync Checkpoints every 20 changes or 1 hour
olcSpCheckpoint: 20 60
# Keep a fair number of operations in the log
olcSpSessionlog: 1000
Restart slapd on the master server, and ensure it starts without error.

Step 4 - Configure the slave(s) to poll the master

Finally, on each slave we need to configure the directory to pull from the master. This will use the syncprov module load we setup earlier in step 2, which needs to be done for each server!

Edit your database config file, eg /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif and add to the bottom of it an entry like:
olcSyncrepl: rid=135
  retry="60 30 300 +"
The rid needs to be unique per slave, and needs to be a three digit number, I've found a suitable part of the IP address to be a good option to go for!

On each slave, ensure there's an empty directory, then start slapd. Within a short while, a search should then show all the data from the master, and you're good to go!

If you hit problems, try running /usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -u ldap -d 255 to start the server in debug mode with logging to the console. The logs can be a little cryptic, but with googling you ought to be able to work out what's wrong and fix!

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.