Michael Ströder wrote: > [email protected] 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/
