[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#7372) slapd-meta stops at first unreachable target
Full_Name: Liam Gretton
Version: 2.4.32
OS: SLES 11 SP 2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (143.210.13.77)
Although multiple targets can be specified in slapd-meta's uri directive to
provide failover should any become unreachable, in practice it seems that
secondary targets are almost never contacted and the failover mechanism doesn't
work as documented.
There was a discussion about this here:
http://www.openldap.org/lists/openldap-technical/201208/msg00103.html
What I've been trying to simulate are the various modes by which a uri target
will become unavailable.
Having gone through this and let the system time out each time, I've found it
does fail over under one of the conditions listed below, but it takes about 15
minutes to do so.
Scenarios:
1. slapd starts, first target is unreachable;
2. slapd starts, first target is reachable but has no service running;
3. slapd already running, first target up and connected then later
becomes unreachable.
Simulations:
a. 'Unreachable' simulated by blocking outbound access with the
following iptables rule:
iptables -A OUTPUT -d host1 -j DROP
b. 'Unreachable' simulated making the first target a host that is up but
with no service running.
Results:
Case 1a: slapd retries host1 continuously and times out after about
180s. No attempt is made to contact additional targets.
Case 2b: slapd retries host1 continuously and times out after about
180s. No attempt is made to contact additional targets.
Case 3a: slapd retries host1 continuously, doubling an internal timeout
value each time, eventually timing out after 19 retries and about 15m.
It does then fall through to host2 and subsequent connections don't
attempt to contact host1.
I also simulated failure with the iptables rule 'iptables -A OUTPUT -d host1 -j
REJECT'. The only difference was that with scenario 1, slapd timed out after
about 3s but still didn't attempt to contact subsequent targets.
Here's my config. I've also tried setting nretries explicitly to 3, but
it makes no difference.
database meta
suffix dc=local
rootdn cn=administrator,dc=local
rootpw secret
network-timeout 1
uri ldap://host1:3268/ou=dc1,dc=local
ldap://host2:3268/
ldap://host3:3268/
suffixmassage "ou=dc1,dc=local" "dc=example,dc=com"
idassert-bind bindmethod=simple
binddn="cn=proxyuser,dc=example,dc=com"
credentials="password"
idassert-authzfrom "dn.exact:cn=administrator,dc=local"
These results suggest to me that network-timeout and nretries (which
should default to 3) don't work as documented.