A couple of questions regarding replication and user mapping

[Karsten Heymann <karsten.heymann@gmail.com>]

Hi,

I'm having a rough week as a long planned ldap migration this week
went semi-bad, in that we noticed a good day after the new cluster
went productive that both masters and both clients started to diverge
data-wise. I'm still sorting out the details, but while
troubleshooting some questions arose already.

(I'm running 2.4.46+dfsg-5~bpo9+1 on debian 9 with two masters
(syncrepl, mirror mode) behind a load balancer and two slaves, also
behind a load balancer. I was authenticating the replication with
client certificates, but had to switch back to simple bind usind
rootdn/rootpw als sync credentials to rule out any acl problems
causing our problems.)

1. I've read in an older debian bug report, that changing
olcAuthRegexp requires a slapd restart in order to be effective. Is
that still the case? If yes, could this *please* be added to the
manpage and the documentation? Pretty please?

2. Is ldapwhoami supposed to also print out the result of a
authz-regexp mapping?

3. The slapd.conf manpage mentions: "The replaced name can be either a
DN, i.e. a string prefixed by "dn:", or an LDAP URI." Is prepending
dn: really required? The examples on
https://www.openldap.org/doc/admin24/sasl.html don't have it.

4. What happens when a lot of concurrent writes happen to two masters
configured in mirror mode? We had a loadbalancer misconfiguration and
the loadbalancers were using simple round robin to write to the
masters. Can this result in diverging content on the two masters?

5. At one time we had diverging content on both masters for the same
entries, probably due to a broken acl config that did not allow the
sync user to see all alltributes on the other master. Is there any way
to cause a "re-sync" of an entry without actually changing data on the
entry? The only way I found was to use slapd -c, but

And finally not a question, but a recommendation for anyone in a
similiar situation: The ldifdiff-tool
(https://github.com/nxadm/ldifdiff) proved extremely valuable in
sorting out the mess and understanding what actually was the situation
data-wise between the systems.

Best regards
Karsten