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 <[email protected]> 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 <[email protected]> >> Sent: Thursday, December 19, 2024 9:20 AM >> To: Quanah Gibson-Mount <[email protected]> >> Cc: Frédéric Goudal <[email protected]>; openldap- >> [email protected] >> 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 <[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,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
