ebackes(a)symas.com wrote: same issue. In our case, yes this could have appeared as early as 2.4.23. 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. these things are applied and sent to accesslog. 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/