[Date Prev][Date Next]
Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
- From: firstname.lastname@example.org
- Date: Tue, 1 Oct 2013 08:01:56 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Michael Ströder wrote:
> email@example.com wrote:
>>> - 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/