Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to syncrhonize a ldap slave and master server. The master server is using openldap 2.3.43-12 and the slave server is using openldap 2.4.23. I copied over the files in /var/lib/ldap, started the server and got this error:

Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=mydomaine,dc=fr): Program version 4.7 doesn't match environment version 4.4
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_open: database "dc=mydomaine,dc=fr" cannot be opened, err -30971. Restore from backup!
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb(dc=mydomaine,dc=fr): txn_checkpoint interface requires an environment configured for the transaction subsystem
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=mydomaine,dc=fr": txn_checkpoint failed: Invalid argument (22).
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: backend_startup_one (type=bdb, suffix="dc=mydomaine,dc=fr"): bi_db_open failed! (-30971)
Oct 22 16:16:41 xe-ldap-slave1 slapd[12111]: bdb_db_close: database "dc=mydomaine,dc=fr": alock_close failed

I have used the db_upgrade command to upgrade the database files on the new slave server, but I still get the same error when starting slapd.

The master server is Centos 5.5 32bit & openldap 2.3.43-12 The slave server is Centos 6.3 64 bit & openldap 2.4.23 Everything was installed using yum.

What is the proper method to synchronize database files from an ldap master server and slave server when the slave server is more recent then the master?

I have followed the suggestion from 84104, but I am getting an error on the slave

syncrepl configuration

syncrepl  rid=003
        retry="60 +"

This syncrepl configuration is working fine on the other slave servers.

Here is the error on the slave:

Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: slap_client_connect: URI=ldaps:// DN="cn=syncuser,dc=mydomaine,dc=fr" ldap_sasl_bind_s failed (-1)
Oct 23 18:28:30 xe-ldap-slave1 slapd[1415]: do_syncrepl: rid=003 rc -1 retrying 

Here is the error on the master:

Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 ACCEPT from IP= (IP= 
Oct 23 18:29:30 ldap0 slapd[15265]: conn=201 fd=35 closed (TLS negotiation failure) 

I can do an ldap search on the master just fine with the user configured for synchronization from the new slave server.

ldapsearch -LLL -x -H ldaps:// -x -W -b dc=mydomaine,dc=fr-D"cn=syncuser,dc=mydomaine,dc=fr"
share|improve this question
slurpd or syncrepl? – 84104 Oct 22 '12 at 20:39
I'm using syncrepl – Craig Efrein Oct 23 '12 at 14:13
Do you have tls certificates in place? – cstamas Oct 23 '12 at 17:17
Yes the certificats are in place. They are the same ones being used by the other slave servers. I added in the syncrepl configuration. – Craig Efrein Oct 24 '12 at 8:44
up vote 1 down vote accepted

LDAP replication under syncrepl is quite robust. The servers don't have to be the same version, they just need to understand each other. (Proper multi-master requires 2.4.X, but that's not what you're asking about as far as I can tell.)

"The consumer replica can be constructed from a consumer-side or a provider-side backup at any synchronization status." Most notably in this case, is that syncrepl can create a proper replica on a server which has never been synced before by any method.

What do to:

  1. stop the replica's slapd
  2. remove the contents of /var/lib/ldap (except DB_CONFIG)
  3. make sure your syncrepl or olcsyncrepl directive is correct
  4. start the replica's slapd
  5. wait for the replica to sync

Note: Use of certain overlays (e.g. memberof) will cause you to lose (override) the operational attributes creatorsName and createTimestamp on the replica, but otherwise everything will be the same.

share|improve this answer
Your answer looks quite promising. I did as you suggested but I am getting this error: ldap_sasl_bind_s failed. I updated my answer with additional elements – Craig Efrein Oct 23 '12 at 16:27
@CraigEfrein Looks like the replica doesn't trust the provider's certificate. Remember that syncrepl doesn't use /etc/openldap/ldap.conf, but rather its own inline tls directives. – 84104 Oct 23 '12 at 17:00
You were right, I found that by adding tls_reqcert=never to the syncrepl configuration, the TLS errors were no longer a problem. Once that was taken care of, the ldap slave synchronized itself automatically with the master like you said it would. I gave you a +1 vote but someone took it away. I think that's unfair since you did point me in the right direction – Craig Efrein Oct 24 '12 at 10:39

IMHO you should run the same version on the master and on the slaves.

If you really want it this way transfer the data in LDIF format: slapcat and slapadd can be used to dump and restore the database. These are offline utilities so stop the ldap servers before use.

EDIT: As far as I recall replication is fragile, I don't say using the same version is mandatory just recommended.

db_upgrade directly modifies the files slapd previously created. It can happen that the end result is ok.

share|improve this answer
Thank you cstamas. Just to confirm the only way to upgrade to a new ldap version on the slave is to upgrade the master as well? What is the db_upgrade program for if it can't be used in this situation? – Craig Efrein Oct 22 '12 at 15:14

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.