ebackes@symas.com wrote:

The openldap-techincal traffic Michael mentioned is almost certainly the

same issue. In our case, yes this could have appeared as early as 2.4.23.

What I'm seeing now is that formerly memberof functioned with accesslog in a

delta-syncrepl type environment by having each stage of replication (master, hub, replica, etc) run the overlay to supply the changes. It seems like originally only the group change went through and the overlay relied on reqStart collisions to prevent its internal operations from reaching the replication log.

So: the recent change that exposed this was something that changed the order

these things are applied and sent to accesslog.

Changing memberof again to reveal only the group changes should probably a

separate ITS, or perhaps a discussion (openldap-devel) on how we want it to work. As-is, the fix in git master breaks compatibility with configurations from prior releases.

The breakage seems to go back to ITS#6329.

The original design for memberOf was for the internal modifications to not be replicated. Instead, any replicas that wanted to maintain member information was expected to run an identical memberOf overlay configuration.

The fact that memberOf didn't update the entryCSN on its internal modifications was intentional. This design constraint was broken by the fix to ITS#6329. The patch for #6329 and any ripple effect from it needs to be reverted.

In general it's incorrect to replicate internal operations. The fanout from replicating every internal operation would be too large and the information content of what is being replicated is essentially nil. When the servers are configured identically they will maintain identical data by virtue of the overlays on each node performing the same internal operations in response to a given sequence of user operations.

Emily Backes Symas - The LDAP Guys ebackes@symas.com