The openldap-techincal traffic Michael mentioned is almost certainly
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
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
So: the recent change that exposed this was something that changed the
these things are applied and sent to accesslog.
Changing memberof again to reveal only the group changes should probably a
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.
Symas - The LDAP Guys
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/