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
Show replies by date
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