With so much redacted from both the config and the change operations, it makes it fairly difficult to comment further. For example, you could be a victim of ITS#8990, but you would have to provide unredacted results of the two sets of changes as they appear in the accesslog DBs from both masters (In ITS#8990, a change propagates correctly between to MMR servers, but is written incorrectly into the accesslog DB of one of the masters).I have just read ITS#8990. While that is a concern for us, that did not come into play in the particular example that I cited (values were being added to an attribute).
Adding values to an attribute is exactly what ITS#8990 was dealing with, so I'm not sure you think it's not a concern. The issue was with the way in which the attribute was modified.
Having made that changes that you recommended, the config now looks like:
No syncprov config? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>