Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops

[hyc@symas.com]

Michael Ströder wrote:
> hyc@symas.com wrote:
>>> Configuration:
>>> - MMR with 3 nodes and normal syncrepl.
>>> - slapo-memberof used to populate/update attribute 'memberOf' in user entries.
>>>
>>> If a group entry is modified and slapo-memberof updates the attribute 'memberOf'
>>> in the member's entry the contextCSN value of the server where the LDAP request
>>> was sent to is not updated on the other MMR replicas.
>>
>> I don't understand this sentence, can you rephrase?
>
> I looked into this a bit more:
>
> We have three MMR nodes, let's simply enumerate them as 1, 2 and 3.
>
> When modifying a group entry on 1 'memberOf' gets *locally* updated and the
> contextCSN value for server 1 gets also updated. So far so good.
>
> Now the group modification are pulled by 2 and 3 and slapo-memberof installed
> there *locally* updates attr memberOf and the *local* contextCSN value for 2
> and 3 are updated with new timestamp. But the updated contextCSN values of 2
> and 3 never get replicated to the other instances! So my monitoring check
> shows a long-lasting replication gap. After next server restart all contextCSN
> values get updated.
>
>> Also see ITS#6915.
>
> Sorry, glancing over ITS#6915 I don't understand what it means in this context.

The point of #6915 is that internal ops are not supposed to affect the 
contextCSN. If you're seeing new contextCSNs on 2 and 3 solely due to 
slapo-memberof then some part of #6915 is still broken. We'll need a duplicate 
setup to reproduce this...

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/