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 <[email protected]> a écrit : > > > > --On Wednesday, December 18, 2024 11:47 AM +0100 Frédéric Goudal > <[email protected]> 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
