Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServiceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates
I have several other secondary ldap from the same source, with the same confiiguration, except the filter is (objectClass=*) and there is no attrs value.
I suspect the error is on the attrs or filter but what do I miss ?
thanks in advance
f.g.
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
--On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal frederic.goudal@bordeaux-inp.fr wrote:
Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServi ceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates
I would definitely add "+" to the list of attrs (all operational attributes).
If you slapcat the db on the consumer, do you see a contextCSN value in the root?
--Quanah
Hello,
Finnaly I have found a solution : on the filter I have added an expression that allow the root object (dc=ipb,dc=fr) to be synchronized. With that, the contextCSN is retrived and apacheDirectoryStudio behave as usual.
BUT for me there are two things left :
- I have found on the list archive someone who had exactly the same problem years ago… so I think the problem is not just mine. But the documentation examples don’t explain how to get the contextCSN. Maybe it should be explained as getting the contextCSN is the only way to check there is no sync problem (and getting the namingContext the way for apacheDirectoryStudio to behave correctly)
- in fact I have done a slapcat and…
dn: dc=ipb,dc=fr structuralObjectClass: glue objectClass: top objectClass: glue entryUUID: 79919fa2-5163-103f-9e87-459e60a64e39 creatorsName: cn=admin,dc=ipb,dc=fr createTimestamp: 20090408121621Z entryCSN: 20090408121621.366621Z#000000#000#000000 modifiersName: cn=admin,dc=ipb,dc=fr modifyTimestamp: 20090408121621Z contextCSN: 20130927152219.157851Z#000000#001#000000 contextCSN: 20131127140429.597497Z#000000#002#000000 contextCSN: 20141208130549.278599Z#000000#004#000000 contextCSN: 20241218113701.508746Z#000000#00a#000000 contextCSN: 20211125151922.406046Z#000000#018#000000 contextCSN: 20241218113143.754713Z#000000#01f#000000
The contextCSN are in the database… but cannot be retrieved.
I will add the + to the attrs. Thanks for the idea.
Fred
Le 18 déc. 2024 à 22:50, Quanah Gibson-Mount quanah@fast-mail.org a écrit :
--On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal frederic.goudal@bordeaux-inp.fr wrote:
Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbServi ceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates
I would definitely add "+" to the list of attrs (all operational attributes).
If you slapcat the db on the consumer, do you see a contextCSN value in the root?
--Quanah
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
Oddly,
" ldapsearch -Y EXTERNAL -H ldapi:/// -b 'dc=...' -s base 'objectClass=dcObject' contextCSN " works here. E.g.: contextCSN: 20130719093756.074776Z#000000#000#000000 contextCSN: 20250102144001.554369Z#000000#001#000000 contextCSN: 20241205131314.243603Z#000000#002#000000 contextCSN: 20241126141340.077960Z#000000#003#000000
Kind regards, Ulrich
-----Original Message----- From: Frédéric Goudal frederic.goudal@bordeaux-inp.fr Sent: Thursday, December 19, 2024 9:20 AM To: Quanah Gibson-Mount quanah@fast-mail.org Cc: Frédéric Goudal frederic.goudal@bordeaux-inp.fr; openldap- technical@openldap.org Subject: [EXT] Re: Unable to get the contextCSN
Hello,
Finnaly I have found a solution : on the filter I have added an expression that allow the root object (dc=ipb,dc=fr) to be synchronized. With that, the contextCSN is retrived and apacheDirectoryStudio behave as usual.
BUT for me there are two things left :
- I have found on the list archive someone who had exactly the same
problem years ago… so I think the problem is not just mine. But the documentation examples don’t explain how to get the contextCSN. Maybe it should be explained as getting the contextCSN is the only way to check there is no sync problem (and getting the namingContext the way for apacheDirectoryStudio to behave correctly)
- in fact I have done a slapcat and…
dn: dc=ipb,dc=fr structuralObjectClass: glue objectClass: top objectClass: glue entryUUID: 79919fa2-5163-103f-9e87-459e60a64e39 creatorsName: cn=admin,dc=ipb,dc=fr createTimestamp: 20090408121621Z entryCSN: 20090408121621.366621Z#000000#000#000000 modifiersName: cn=admin,dc=ipb,dc=fr modifyTimestamp: 20090408121621Z contextCSN: 20130927152219.157851Z#000000#001#000000 contextCSN: 20131127140429.597497Z#000000#002#000000 contextCSN: 20141208130549.278599Z#000000#004#000000 contextCSN: 20241218113701.508746Z#000000#00a#000000 contextCSN: 20211125151922.406046Z#000000#018#000000 contextCSN: 20241218113143.754713Z#000000#01f#000000
The contextCSN are in the database… but cannot be retrieved.
I will add the + to the attrs. Thanks for the idea.
Fred
Le 18 déc. 2024 à 22:50, Quanah Gibson-Mount quanah@fast-mail.org a
écrit :
--On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal
frederic.goudal@bordeaux-inp.fr wrote:
Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbS ervi
ceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates
I would definitely add "+" to the list of attrs (all operational attributes).
If you slapcat the db on the consumer, do you see a contextCSN value in
the root?
--Quanah
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
Hello,
Interesting,
Does it depends on the access and authentication method ?
I use the contextCSN information from a distant monitoring host, so I need the network connexion.
f.g.
Le 3 janv. 2025 à 09:49, Windl, Ulrich u.windl@ukr.de a écrit :
Oddly,
" ldapsearch -Y EXTERNAL -H ldapi:/// -b 'dc=...' -s base 'objectClass=dcObject' contextCSN " works here. E.g.: contextCSN: 20130719093756.074776Z#000000#000#000000 contextCSN: 20250102144001.554369Z#000000#001#000000 contextCSN: 20241205131314.243603Z#000000#002#000000 contextCSN: 20241126141340.077960Z#000000#003#000000
Kind regards, Ulrich
-----Original Message----- From: Frédéric Goudal frederic.goudal@bordeaux-inp.fr Sent: Thursday, December 19, 2024 9:20 AM To: Quanah Gibson-Mount quanah@fast-mail.org Cc: Frédéric Goudal frederic.goudal@bordeaux-inp.fr; openldap- technical@openldap.org Subject: [EXT] Re: Unable to get the contextCSN
Hello,
Finnaly I have found a solution : on the filter I have added an expression that allow the root object (dc=ipb,dc=fr) to be synchronized. With that, the contextCSN is retrived and apacheDirectoryStudio behave as usual.
BUT for me there are two things left :
- I have found on the list archive someone who had exactly the same
problem years ago… so I think the problem is not just mine. But the documentation examples don’t explain how to get the contextCSN. Maybe it should be explained as getting the contextCSN is the only way to check there is no sync problem (and getting the namingContext the way for apacheDirectoryStudio to behave correctly)
- in fact I have done a slapcat and…
dn: dc=ipb,dc=fr structuralObjectClass: glue objectClass: top objectClass: glue entryUUID: 79919fa2-5163-103f-9e87-459e60a64e39 creatorsName: cn=admin,dc=ipb,dc=fr createTimestamp: 20090408121621Z entryCSN: 20090408121621.366621Z#000000#000#000000 modifiersName: cn=admin,dc=ipb,dc=fr modifyTimestamp: 20090408121621Z contextCSN: 20130927152219.157851Z#000000#001#000000 contextCSN: 20131127140429.597497Z#000000#002#000000 contextCSN: 20141208130549.278599Z#000000#004#000000 contextCSN: 20241218113701.508746Z#000000#00a#000000 contextCSN: 20211125151922.406046Z#000000#018#000000 contextCSN: 20241218113143.754713Z#000000#01f#000000
The contextCSN are in the database… but cannot be retrieved.
I will add the + to the attrs. Thanks for the idea.
Fred
Le 18 déc. 2024 à 22:50, Quanah Gibson-Mount quanah@fast-mail.org a
écrit :
--On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal
frederic.goudal@bordeaux-inp.fr wrote:
Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -b dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbS ervi
ceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 exattrs=hasSubordinates
I would definitely add "+" to the list of attrs (all operational attributes).
If you slapcat the db on the consumer, do you see a contextCSN value in
the root?
--Quanah
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
--On Monday, January 6, 2025 11:06 AM +0100 Frédéric Goudal frederic.goudal@bordeaux-inp.fr wrote:
Hello,
Interesting,
Does it depends on the access and authentication method ?
I use the contextCSN information from a distant monitoring host, so I need the network connexion.
Access to any data in the directory is controlled by ACLs.
--Quanah
Hi!
I would say if you can get it using ldapsearch locally, it works in principle; if it does not from remote, I'd check the ACLs being involved.
Kind regards, Ulrich Windl
-----Original Message----- From: Frédéric Goudal frederic.goudal@bordeaux-inp.fr Sent: Monday, January 6, 2025 11:06 AM To: Windl, Ulrich u.windl@ukr.de Cc: Frédéric Goudal frederic.goudal@bordeaux-inp.fr; Quanah Gibson- Mount quanah@fast-mail.org; openldap-technical@openldap.org Subject: [EXT] Re: Unable to get the contextCSN
Hello,
Interesting,
Does it depends on the access and authentication method ?
I use the contextCSN information from a distant monitoring host, so I need the network connexion.
f.g.
Le 3 janv. 2025 à 09:49, Windl, Ulrich u.windl@ukr.de a écrit :
Oddly,
" ldapsearch -Y EXTERNAL -H ldapi:/// -b 'dc=...' -s base
'objectClass=dcObject' contextCSN " works here.
E.g.: contextCSN: 20130719093756.074776Z#000000#000#000000 contextCSN: 20250102144001.554369Z#000000#001#000000 contextCSN: 20241205131314.243603Z#000000#002#000000 contextCSN: 20241126141340.077960Z#000000#003#000000
Kind regards, Ulrich
-----Original Message----- From: Frédéric Goudal frederic.goudal@bordeaux-inp.fr Sent: Thursday, December 19, 2024 9:20 AM To: Quanah Gibson-Mount quanah@fast-mail.org Cc: Frédéric Goudal frederic.goudal@bordeaux-inp.fr; openldap- technical@openldap.org Subject: [EXT] Re: Unable to get the contextCSN
Hello,
Finnaly I have found a solution : on the filter I have added an expression
that
allow the root object (dc=ipb,dc=fr) to be synchronized. With that, the contextCSN is retrived and apacheDirectoryStudio behave
as
usual.
BUT for me there are two things left :
- I have found on the list archive someone who had exactly the same
problem years ago… so I think the problem is not just mine. But the documentation examples don’t explain how to get the contextCSN.
Maybe it
should be explained as getting the contextCSN is the only way to check
there
is no sync problem (and getting the namingContext the way for apacheDirectoryStudio to behave correctly)
- in fact I have done a slapcat and…
dn: dc=ipb,dc=fr structuralObjectClass: glue objectClass: top objectClass: glue entryUUID: 79919fa2-5163-103f-9e87-459e60a64e39 creatorsName: cn=admin,dc=ipb,dc=fr createTimestamp: 20090408121621Z entryCSN: 20090408121621.366621Z#000000#000#000000 modifiersName: cn=admin,dc=ipb,dc=fr modifyTimestamp: 20090408121621Z contextCSN: 20130927152219.157851Z#000000#001#000000 contextCSN: 20131127140429.597497Z#000000#002#000000 contextCSN: 20141208130549.278599Z#000000#004#000000 contextCSN: 20241218113701.508746Z#000000#00a#000000 contextCSN: 20211125151922.406046Z#000000#018#000000 contextCSN: 20241218113143.754713Z#000000#01f#000000
The contextCSN are in the database… but cannot be retrieved.
I will add the + to the attrs. Thanks for the idea.
Fred
Le 18 déc. 2024 à 22:50, Quanah Gibson-Mount quanah@fast-mail.org
a
écrit :
--On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal
frederic.goudal@bordeaux-inp.fr wrote:
Hello,
I just have build a new ldap server @(#) $OpenLDAP: slapd 2.6.8 (Jul 23 2024 09:45:55) $
It is an attenpt to do a partial replication from another ldap server. The objects seem to be synchronized in the logs I have lines like slap_queue_csn: queueing 0x77bfe8109e30 20241218104201.919382Z#000000#00a#000000
where the csn is correct.
What is strange is that if I try to get the contextCSN, from the directoryI have no value returned :
/usr/local/bin/ldapsearch -H ldap://ldapext2024.dmze.ipb.fr -x -s base -
b
dc=ipb,dc=fr contextCSN # extended LDIF # # LDAPv3 # base <dc=ipb,dc=fr> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
# numResponses: 1
The olcSyncrepl value is :
{0}rid=430 provider=ldap://<provider> binddn="uid=ldapsync,ou=people,dc=ipb,dc=fr" bindmethod=simple credentials=secret filter="(| (entryDN:dnSubtreeMatch:=ou=groups,dc=ipb,dc=fr) (entryDN:dnSubtreeMatch:=ou=people,dc=ipb,dc=fr))" searchbase="dc=ipb,dc=fr" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
attrs="uid,sn,givenName,userPassword,mail,member,ipbCompteValide,ipbS
ervi
ceAllow,ipbServiceDeny,ipbPupi" logbase=cn=accesslog type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +"
timeout=1
exattrs=hasSubordinates
I would definitely add "+" to the list of attrs (all operational attributes).
If you slapcat the db on the consumer, do you see a contextCSN value in
the root?
--Quanah
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
openldap-technical@openldap.org
-
Frédéric Goudal -
Quanah Gibson-Mount -
Windl, Ulrich