Hello Ulrich,

I totally agree with you, it’ll help somehow db update checks in non syncrepl 
usage. 

Brgds,
J-L. 
> On 28 Oct 2021, at 08:47, Ulrich Windl <[email protected]> 
> wrote:
> 
> 
>> 
>>>> 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>
> 
> 
> 

Reply via email to