On May 24, 2019, at 2:15 PM, Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, May 24, 2019 9:23 AM -0400 "John C. Pfeifer" pfeifer@umd.edu wrote:
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.
Looking at http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8990;selectid=8990, ITS#8990 seems to be about deleting values, not adding them. Is there somewhere else that I should be looking for more details?
Having made that changes that you recommended, the config now looks like:
No syncprov config?
Sorry, the config I copied was from a replica; on the masters only:
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckPoint: 100 10 olcSpSessionlog: 250000 olcSpNoPresent: FALSE olcSpReloadHint: FALSE
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpNoPresent: TRUE olcSpReloadHint: TRUE
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
// John Pfeifer Division of Information Technology University of Maryland, College Park