You are viewing gagravarr

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

[ 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]
Previous Entry Share Next Entry
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
  provider="ldaps://ldap-master.example.org:389/"
  type=refreshAndPersist
  retry="60 30 300 +"
  searchbase="dc=example,dc=org"
  bindmethod=simple
  binddn="uid=replicate,dc=example,dc=org"
  credentials=MYsecurePASSWORD
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!
linkReply

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

Open Ldap Replication - Step 4 question/clarification

(Link)

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.

Thanks.

-Dave

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

Re: Open Ldap Replication - Step 4 question/clarification

(Link)

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
From: (Anonymous)
2013-10-16 05:17 am (UTC)

Re: Open Ldap Replication - Step 4 question/clarification

(Link)

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.
From: (Anonymous)
2013-10-28 07:14 pm (UTC)

RID unique

(Link)

Hello,

I'm confused.

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

ldap
/\
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!
From: gagravarr
2013-10-29 01:32 pm (UTC)

Re: RID unique

(Link)

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)