Log in

Enabling replication with OpenLDAP 2.4 on RHEL 6 with cn=config (olc....) - Nick [entries|archive|friends|userinfo]

[ website | gagravarr.org ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Enabling replication with OpenLDAP 2.4 on RHEL 6 with cn=config (olc....) [Aug. 14th, 2013|06:41 pm]
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!

From: (Anonymous)
2013-09-24 05:38 pm (UTC)

Open Ldap Replication - Step 4 question/clarification

Thank you for this posting. As I am not a full time LDAP administrator yours is the first article I've read that clearly explained LDAP replication with a minimum number of words.

One question: In step 4 of your procedure you modify olcDatabase={2}bdb.ldif to add an olcSyncrepl paragraph. It is not clear from your description whether or not the same modification would also be needed to olcDatabase={0}config.ldif. If so, would the rid need to be the same or different?

I will try to figure this out on my own, but if this can be clarified I believe that your article will be even more valuable.



(Reply) (Thread)
From: gagravarr
2013-09-24 08:53 pm (UTC)

Re: Open Ldap Replication - Step 4 question/clarification

You'd only need to add it to olcDatabase={0}config.ldif if you also wanted to sync your cn=config directory over to your slave server. If you only want to send the data, and leave your configuration in ldif files (which you sync manually), you don't need to enable sync in olcDatabase={0}config.ldif file
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-10-16 05:17 am (UTC)

Re: Open Ldap Replication - Step 4 question/clarification

To Nick et al,

I just wanted to give you a great big "Thank You!!!!!!"

I was soooo frustrated considering this was my first time ever setting up openldap and getting my head wrapped around the whole cn=config thing.

This worked like a charm!

Thank you.
(Reply) (Parent) (Thread)
From: (Anonymous)
2013-10-28 07:14 pm (UTC)

RID unique


I'm confused.

I have 5 masters ldap and 70 consumers ldap (on 70 differents centers).
Here the schema i use:

ldap-01 -------------- ldap-02 -------------- ldap-03 -------------- ldap-04
/ | | \
ldap-center01 ldap-center17 ldap-center36 ldap-center54
... ... ... ...
ldap-center16 ldap-center35 ldap-center53 ldap-center70

On ldap server:
ldap-01: rid=101
ldaṕ-02: rid=102
ldaṕ-03: rid=103
ldaṕ-04: rid=104

On ldap-01 server:
ldap: rid=100
ldap-center01: rid=111
ldap-center16: rid=126

On ldap-02 server:
ldap: rid=100
ldap-center01: rid=127
ldap-center16: rid=145

On ldap-03 server:
ldap: rid=100
ldap-center01: rid=146
ldap-center16: rid=163

On ldap-04 server:
ldap: rid=100
ldap-center01: rid=164
ldap-center16: rid=180

On ldap-center01 server:
ldap: rid=101

On ldap-center16 server:
ldap: rid=101

On ldap-center17 server:
ldap: rid=102

On ldap-center35 server:
ldap: rid=102

On ldap-center36 server:
ldap: rid=103

On ldap-center53 server:
ldap: rid=103

On ldap-center54 server:
ldap: rid=104

On ldap-center70 server:
ldap: rid=104

I don't know if my "rid=" are right or not.
I don't know if i can put the same "rid" number (rid=100) on each masters (ldap-0x).
I don't know if i can put the same "rid" number (rid=101|102|103|104) for each center for each ldap-0x tree.

Thanks very much!
(Reply) (Thread)
From: gagravarr
2013-10-29 01:32 pm (UTC)

Re: RID unique

I think that the rid has to be unique on the slave. From the docs

<rid> identifies a consumer replica locally within the consumer server. It is used to relate the cookie to the syncrepl definition in slapd.conf(5) which has the matching replica identifier. The must have no more than 3 decimal digits. The command line cookie overrides the synchronization cookie stored in the consumer replica database.

I think for a given slave, each master it talks to needs a unique rid. It looks like the rid is slave scoped though

Edited at 2013-10-29 01:33 pm (UTC)
(Reply) (Parent) (Thread)
From: (Anonymous)
2015-01-23 08:27 am (UTC)

info : Size limit exceeded

warning !
if you are a big directory change olcLimits on the master
replication may not work when this happens, entries such as the following appear the log:
slapd[209]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (4) Size limit exceeded
slapd[209]: do_syncrep2: rid=001 (4) Size limit exceeded
(in the slave)

conn=1013 op=1 SEARCH RESULT tag=101 err=4 nentries=500 text=
(in the master)

This can occur if a replica is created when there are more than 500 objects in the LDAP.
500 is the default maximum number of objects that can returned in a search.

Change the value :
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
replace: olcSizeLimit
olcSizeLimit: 50000
(Reply) (Thread)
From: flotho
2015-04-26 01:10 pm (UTC)
Found on another thread, the user password has to be in clear in the slave conf!
(Reply) (Thread)
From: flotho
2015-04-26 01:24 pm (UTC)

Slave don't polling the users


I've finally succeed in making the replication working. The database of the slave is now fill with groups and OU but there is no users inside.
Any idea where it could come from?
(Reply) (Thread)
From: (Anonymous)
2017-01-05 04:27 pm (UTC)


There is bad info on this page. The bad is the editing of the ldif files directly. Unless I am missing something with the version supplied with RHEL6. But the ldif files are auto generated and should be created/edited with ldap* commands, ie, ldapmodify. Each file has a CRC in the file, and if they don't match, you will get errors from slaptest. You can get around it by getting a CRC of the file and adding it to the file, but it's a lot of extra work.
(Reply) (Thread)