Dear list!

I am currently chasing some replication problems and I am trying to get my mind around a couple of questions.

Let's assume this:

We have two LDAP servers, server 1 and server 2, which are supposed to be mirrors of each other. The both have their cn=config database and a database with actual data, let's assume it's the dc=example,dc=com database. I want to run not only dc=example,dc=com but also cn=config in mirror mode to make sure that I keep the config in sync and that any changes to the config (e.g. ACls) can be done on one of the servers and will replicate to the other one.

Let's assume this was all working well.

Not server 2 fails and needs a complete reinstall. So I sit there with a slapd binary and no configuration at all.

My idea would be (please tell me if I am on the right path) :

1. I could give server 2 a minimal config which does not contain anything else but "replicate your cn=config from server1". Let's call this a bootstrap config. 2. Once server 2 starts with that bootstrap config, it will fetch cn=config from server1. 3. It will learn from the replicated config that it has to have an dc=example,dc=com database, create it and replicate its content from server1 as well. 4. I would be back in business.

Unfortunately, when I tried, what happened was:

The contextCSN of the bootstrap config on server 2 is newer / higher than the one on server 1 which has not been touched for a while. So server 2 did not fetch the config from server 1 but vice versa, which was not exactly the result I intended. Though it's very consequent and logical behaviour.

My question:

Am I on the complete wrtong track?

Would I have to do the slapcat -> slapadd thing between server 1 and server 2 first (with server 2 offline) and start server 2 only after that?

When I do the slapcat / slapadd thing from server 1 to server 2, do I have to remove any contextCSN / entryCSN entries (as some postings such as http://www.mail-archive.com/openldap-technical@openldap.org/msg00109.html) suggest or would that be just wrong?

Regards, Torsten