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