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 <[email protected]> > Sent: Monday, January 6, 2025 11:06 AM > To: Windl, Ulrich <[email protected]> > Cc: Frédéric Goudal <[email protected]>; Quanah Gibson- > Mount <[email protected]>; [email protected] > 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 <[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 > > >
