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
Sorry, one paragraph was still incomplete
- 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
... we had to decide in which direction to fix the data on a per-entry basis, and I'm not sure that works with slapd -c. So we "filled the missing bits" on the other master with each accounts output from ldifdiff (see below).
Best regards again, Karsten
Hi Karsten, I'll leave the questions about replication to the experts, but:
On Thu, Sep 20, 2018 at 10:29:11PM +0200, Karsten Heymann wrote:
- 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?
Yes.
I've been working on it and I think the code is working, but still need to test it more thoroughly. Should be included in OpenLDAP 2.5; the changes are a little too invasive for 2.4 at this point.
If yes, could this *please* be added to the manpage and the documentation? Pretty please?
The Debian package was patched to note this in the slapd-config(5) man page. IIRC the man page patch was rejected upstream in favour of just fixing the code.
- Is ldapwhoami supposed to also print out the result of a
authz-regexp mapping?
I believe it is, yes. (Except "instead" rather than "also", but I think that's what you meant.)
Ryan
Am Thu, 20 Sep 2018 22:29:11 +0200 schrieb 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.)
- 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?
- Is ldapwhoami supposed to also print out the result of a
authz-regexp mapping?
Yes
- 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.
No
- 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?
First write should win, depending on timestamp
- 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
If you have a log database with sufficient old data and matching timestamps and csn's it might be possible. But a slapcat and slapdadd would be easier.
[...]
-Dieter
On 9/21/18 10:45 AM, Dieter Klünter wrote:
Am Thu, 20 Sep 2018 22:29:11 +0200 schrieb Karsten Heymann karsten.heymann@gmail.com:
- 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?
First write should win, depending on timestamp
@Dieter: Did you mean last write should win?
In theory OpenLDAP does conflict resolution based on the "timestamp" in the entryCSN attribute value. This also means that you need really tight time synchronization.
In general if you have really *many* concurrent writes going to several MMR replicas you will likely run into trouble. I'd recommend to avoid that.
Another problem with naive load-balancing is that most applications do read-after-write operations within very short time span which will fail because of replication latency.
Ciao, Michael.
Hello,
I'd like to point out a new overlay that I wrote: https://github.com/davidcoutadeur/explockout
The aim is to require the user to wait for an exponential time before he can authenticate again, after some failed authentications. The overlay is quite simple: it relies on ppolicy for adding pwdFailureTime attribute and compute the time the user has to wait.
Maybe some of you can consider it useful. Please anyone feel free to give your opinion, comments or improvements. Also if OpenLDAP team is interested, I would be glad to have it incorporated in official OpenLDAP contrib modules.
David
David Coutadeur wrote:
Hello,
I'd like to point out a new overlay that I wrote: https://github.com/davidcoutadeur/explockout
The aim is to require the user to wait for an exponential time before he can authenticate again, after some failed authentications. The overlay is quite simple: it relies on ppolicy for adding pwdFailureTime attribute and compute the time the user has to wait.
Maybe some of you can consider it useful. Please anyone feel free to give your opinion, comments or improvements. Also if OpenLDAP team is interested, I would be glad to have it incorporated in official OpenLDAP contrib modules.
We've often discussed using such a wait approach for password failures. Sounds useful.
David
openldap-technical@openldap.org
-
David Coutadeur -
Dieter Klünter -
Howard Chu -
Karsten Heymann -
Michael Ströder -
Ryan Tandy