--On Wednesday, October 05, 2016 12:17 PM +0200 Thomas Hummel thomas.hummel@pasteur.fr wrote:
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) ?
Correct
Of course, I still don't undestand why this entry disapeared in the first place...
What release? There are known issues with syncrepl in various releases.
--Quanah
--
Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, October 05, 2016 9:05 AM -0700 Quanah Gibson-Mount quanah@symas.com wrote:
--On Wednesday, October 05, 2016 12:17 PM +0200 Thomas Hummel thomas.hummel@pasteur.fr wrote:
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) ?
Correct
Of course, I still don't undestand why this entry disapeared in the first place...
What release? There are known issues with syncrepl in various releases.
Actually, I see you're using two releases known to have significant issues with syncrepl. I suggest reading the change log so the importance of running 2.4.44 is clear.
--Quanah
--
Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 10/05/2016 05:05 PM, Quanah Gibson-Mount wrote:
Thanks for your answer.
What release? There are known issues with syncrepl in various releases.
I first noticed the issue between an openldap-2.4.35 (FreeBSD 9.1-RELEASE-p12) provider and openldap-servers-2.4.40-9.el7_2.x86_64 from CentOS Linux release 7.2.1511 (Core) consumer.
Also, the missing entry was the sssd application user (sssd binds using it), may be relevant or not...
By the way, trying to (blindly) reproduce it, I started again from scratch (rm mdb files) and did some systemctl stop slapd.service (and restarts) while the replication was running. Odd enough, I ended up with a 1GB data.mdb file while it's usual size is normally about 43MB (1GB is the max configured and a slapcat semmed to dump the correct expected number of '^dn:' as grepped).
Thanks
-- Thomas HUMMEL
Am Mittwoch, 05. Oktober 2016 17:15 CEST, Thomas Hummel thomas.hummel@pasteur.fr schrieb:
Also, the missing entry was the sssd application user (sssd binds using it), may be relevant or not...
This sounds suspiciously like an access control issue. Can you read this entry via ldapsearch with the credentials of your syncrepl?
By the way, trying to (blindly) reproduce it, I started again from scratch (rm mdb files) and did some systemctl stop slapd.service (and restarts) while the replication was running. Odd enough, I ended up with a 1GB data.mdb file while it's usual size is normally about 43MB (1GB is the max configured and a slapcat semmed to dump the correct expected number of '^dn:' as grepped).
IIRC mdb files don't "grow", the start with the max size (but are sparse files, sotheywon't eat up your disc).
Cheers,Ralf Mattes
On 10/05/2016 05:40 PM, Ralf Mattes wrote:
This sounds suspiciously like an access control issue. Can you read this entry via ldapsearch with the credentials of your syncrepl?
Yes of course I can. This is the first thing I checked ;-) Besides, on an initial sync, this entry gets synchronised as expected. I cannot manage to reproduce the vanishing of this entry...
Does the realease versions I gave you ring some bell about the syncrepl issues you were thinking of ?
Thanks
-- Thomas HUMMEL
openldap-technical@openldap.org
-
Quanah Gibson-Mount -
Ralf Mattes -
Thomas Hummel