It's about time that I posted something that's a little more technically minded than previous posts.
I have to replicated an LDAP database in a backup cluster so that should the main cluster go down, the secondary servers can be brought online. Here are the steps I've taken to allow a correctly configured LDAP server (LDAP1) to be replicated on a second machine (LDAP2).
Here's a little GLOSSARY of terms:
SLAPD - the LDAP SERVER (runs on both machines as this is what we're trying to replicate)
SLURPD - the daemon that handles replication (runs on the master server).
Master (LDAP1 ) Setup
You should have a working LDAP server in place on this machine - if not then these steps aren't going to work.
1. You need to specify the replicas in your /etc/openldap/slapd.conf file. binddn= on the slapd server should match the updatedn= parameter on the slurpd server, with write access to the slave database. This should not be the same dn as the master LDAP rootdn (or the slave one).
2. Add a replogfile= directive, from which slurpd will read the changes to slapd.
Example:
replica uri=ldap://slave.foo.bar:389
binddn="cn=Replicator,dc=foo,dc=bar"
bindmethod=simple
credentials=secret
If you want to use port 636 instead of 389 - simple substitute one for the other. If you are using SSL - set ldap:// to ldaps:// and specify port 636 too. Also note that 'uri=' is used instead of the deprecated 'host=' option. If you stick with that you get lots of TLS errors.
Slave (LDAP2) Setup
Currently, you're slave server should have no ldap-server installed on it (you may have some client LDAP scripts, but these shouldn't interfere with the new setup).
The server needs to be setup identically to the master server, (copy over /etc/ldap.conf, /etc/openldap/ldap.conf and /etc/openldap/slapd.conf,) but with the following changes:
1. Do not create a replica directive*.
2. Do not include the replogfile.
Example:
updatedn "cn=Replicator,dc=foo,dc=bar"
updateref ldaps://master.foo.bar:636
3. The updatedn= parameter should match the binddn= parameter of the replica in slapd.conf
4. The updateref= parameter can be used to define the URL the slave should return if an update request is received.
* It is possible to have a slurpd slave pulling information off another slurpd slave, but in most cases it is inappropriate.
5. Chance all references to the original server (ldap.foo.bar) so the new server (slave.foo.bar).
6. For the purpose of ACLS, add: access to *
by dn.exact="cn=Replicator,dc=foo,dc=bar" =xw
by * none break
to the start of your list of ACLs.
SSL/TLS
If you're using TLS/SSL - make sure your certificates have the commonName attribute set to the FQDN of the machine they're on (eg. slave.foo.bar).
Going Live
This is always my favourite bit. It sometimes goes fantastically - but most of the time I fall back on my face. I'm sure this is great reading if you're following my instructions, but I thought I'd stick it in as some sort of disclaimer.
To make sure that the databases are identical, you must shutdown the master server on LDAP1. I advise against doing this during the normal working day if lots of people use the server. People could get mad. If you need the server to be live whilst you are maintaining it (I DO NOT RECOMMEND THIS) then you can restart the LDAP server in read-only mode (which will not allow people to modify it). However, in my experience, saving the work for when no one is about is better.
If you're running LDAP server on different architectures, it's better to use slapcat to output an *.ldif file to import into the slave DB (as copying databases across architectures will increase chances of issues).
I hope this works for you - it's fairly simple and much is borrowed from other guides - but it is a little clearer to me now how to do it. If you know better ways, please notify me using the comments and I'll update the main article.
(I do not recommend sticking with the credentials on this page).
Troubleshooting
err=49 = wrong credentials (you have got your username/password wrong).