Hi,
We are running replication checks, including one where we compare "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers.
Relevant config (on each server identically through ansible)
database mdb maxsize 10737418240 suffix "o=company,c=com" rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1
Now using this config, we would expect the contextCSN to be faily up-to-date across all servers, however, this is not always the case.
There are occasions where servers contextCSN become 'outdated', while others are up-to-date. If we query contextCSN though ldapsearch, the correct contextCSN is returned on all servers.
This situation can remain for long, and restarting openldap solves it immediately.
We could of course change our logging to query contextCSN through an ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well.
Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..?
Have a nice weekend, everybody!
MJ
Hi,
For security reason we do a slapcat every night on our main ldapserver and… we have a small desynchronization between our servers during the slapcat…
There is no need for authentication to get the constextCSN and if you use ldapi you don’t need network.
f.g.
Le 13 oct. 2023 à 15:20, cYuSeDfZfb cYuSeDfZfb cyusedfzfb@gmail.com a écrit :
Hi,
We are running replication checks, including one where we compare "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers.
Relevant config (on each server identically through ansible)
database mdb maxsize 10737418240 suffix "o=company,c=com rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1
Now using this config, we would expect the contextCSN to be faily up-to-date across all servers, however, this is not always the case.
There are occasions where servers contextCSN become 'outdated', while others are up-to-date. If we query contextCSN though ldapsearch, the correct contextCSN is returned on all servers.
This situation can remain for long, and restarting openldap solves it immediately.
We could of course change our logging to query contextCSN through an ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well.
Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..?
Have a nice weekend, everybody!
MJ
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
Hi Frédéric,
Wow, you're quick. I tried your suggestion, and it works! :-)
ldapsearch -x -H ldapi:// -b 'o=company,c=com' -s base contextCSN
provides what I need.
Still wonder why "syncprov-checkpoint 100 1" doesn't (always) work, but I will proceed with your suggestion, the anonymous socket connections.
Passe un bon weekend!
On Fri, 13 Oct 2023 at 15:27, Frédéric Goudal < frederic.goudal@bordeaux-inp.fr> wrote:
Hi,
For security reason we do a slapcat every night on our main ldapserver and… we have a small desynchronization between our servers during the slapcat…
There is no need for authentication to get the constextCSN and if you use ldapi you don’t need network.
f.g.
Le 13 oct. 2023 à 15:20, cYuSeDfZfb cYuSeDfZfb cyusedfzfb@gmail.com a
écrit :
Hi,
We are running replication checks, including one where we compare
"slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers.
Relevant config (on each server identically through ansible)
database mdb maxsize 10737418240 suffix "o=company,c=com rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1
Now using this config, we would expect the contextCSN to be faily
up-to-date across all servers, however, this is not always the case.
There are occasions where servers contextCSN become 'outdated', while
others are up-to-date.
If we query contextCSN though ldapsearch, the correct contextCSN is
returned on all servers.
This situation can remain for long, and restarting openldap solves it
immediately.
We could of course change our logging to query contextCSN through an
ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well.
Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..?
Have a nice weekend, everybody!
MJ
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
openldap-technical@openldap.org
-
cYuSeDfZfb cYuSeDfZfb -
Frédéric Goudal