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.