>>> Quanah Gibson-Mount <[email protected]> schrieb am 25.10.2021 um 17:15 in Nachricht <BA996D86ACF3015D89F3395A@[192.168.1.11]>:
> > ‑‑On Monday, October 25, 2021 1:29 PM +0000 [email protected] wrote: > >> Dears, >> >> I found the cause if I can tell it like this, in fact, it's only for >> cn=config for which there are replication settings set for the 4MMR but >> not for the replica, then the contextCSN of replica isn't modified when I >> do any kind of modification to its cn=config. >> >> I still have a question about it, is there a way to know if cn=config is >> updated (in any area) for a replica which has not syncrepl accord ? like >> contextCSN attribute ? >> >> I knew that entryCSN is modified for the object modified but it's object >> by object and I'd like to have it globaly. > > A contextCSN is only maintained on a database that is replicated. If your > consumers don't also replicate cn=config, then there will not be any > contextCSN on the cn=config db. One question would be, why do you have > consumers at all if you're running in an MMR environment? Alternatively, > if there is some need that mandates consumers, there are examples in the > test suite on how to set things up so that a group of consumers share a > replicated database (See test059 or test086). Hi! The point is whether it was some historical design decision to make slapo-syncprov provide the contextCSN. It would be a rather handy modification timestamp for a database independently from syncing. My guess it that it might be rather easy to add it to the base slapd. Also: Does contextCSN correspond to RFC 4533's syncCookie? Regards, Ulrich > > Regards, > Quanah > > ‑‑ > > Quanah Gibson‑Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>
