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 > > >
