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.