Hello,
I'm planning a migration from openldap-2.4.35 (FreeBSD 9.1-RELEASE-p12) to openldap-2.4.40 (CentOS 7).
On BSD, I have 3 slapd.conf/hdb servers : one provider and 2 consumers (classical syncprov overlay / syncrepl refreshAndPersist setup).
On linux, I've set up 3 new cn=config/lmdb servers in a simliar manner.
For a smooth migration, I also configured syncrepl on the linux provider so that it is also a consumer of the BSD provider. So this is a simple BSD provider -> linux provider-and-consumer -> linux consumer chain, not a multi-master setup.
Everything worked fine and I could indeed check that modifying, say an attribute of my dn, on the FreeBSD provider was replicated to the BSD consumers, the Linux provider and then the Linux consumers.
Unfortunately, I noticed that, after a while (at least it seems that it occurred after a while, I'd swear the entry was there from the start), the sssd entry (cn=sssd,ou=ldap,dc=pasteur,dc=fr) - used by sssd to bind - was missing on the Linux provider-and-consumer. That in itself may be an mystery I must figure out.
But more important, I noticed that this entry would not be replicated although it IS present on the BSD provider, even after slapd restarts.
Only if I remove the database files and restart from scratch get all the entries - including this one - get replicated from the BSD provider to the linux provider-consumer.
Is my setup only supposed to work ? Is the difference of slapd versions a problem ? Is the fact that both providers manage the same rootDSE a problem ?
Thanks
-- Thomas HUMMEL
I'm answering some parts of my own question :
as a matter of fact, the entry missing in my replica has an entryCSN lesser than the contestCSN. I guess that's the reason why it is not synchronised.
Does that mean that, if for some reason, the replica gets out of sync in a similar manner, missing entries will never get synch'ed again unless - by "chance" - touched (modified) again (in which case they'll get a new entryCSN) ?
Of course, I still don't undestand why this entry disapeared in the first place...
Thanks
-- Thomas HUMMEL
openldap-technical@openldap.org