[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
slapd-ldap and Multiple URIs: Dealing with hosts that are down
- To: "openldap-technical@openldap.org" <openldap-technical@openldap.org>
- Subject: slapd-ldap and Multiple URIs: Dealing with hosts that are down
- From: Jesus Jr M Salvo <jesus.m.salvo@gmail.com>
- Date: Wed, 23 Oct 2013 15:08:39 +1100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kn/94iFrqd9V9jxzEZMt1na4YzM6IMfwd9UDN/EAs5M=; b=uog5uwgSuQ/DNFZ1zl6qWGVVUl79ueZ9oV6wTYVP7eeuqKX+WptoKflC+rG9+rTvD3 FULjQKxFLAuNL8B5D49i1QZ6Y9dW9WlLYdFVQPY6qjP1snF6z9tZtW0jt7vhKz9dU74Z ZtGMo+wzdui1X3DNy76hsbHYkN026xBhvNgeoh/Pylgmg3dt3CTsMEAGbiE9WkpTCFD0 XPK4gIMAfSOIaAF1hh42ZTzrZobFouGZnXBzpS3GGxuov1MhHkdl1hyzMjOfHCeCv1nF MqVEXm9b668IHZXUzEixUlekw8nnGfSFuAb73b2SoLzr5REOd/XUDjQZH+JiCvh9+aUJ hFjg==
Using the meta backend, I have specified a list of LDAP URIs.
I am testing what happens if the first URI becomes unresponsive ( e.g.
The host was shutdown, etc. ).
So I deliberately put in a bogus URI as the first URI that I know will
not respond ( TCP SYN would be sent out by OpenLDAP, but no TCP ACK
coming back ):
#####################
backend meta
database meta
access to *
by * read
suffix "dc=ldapproxy,dc=local"
uri ldap://10.10.10.10/dc=aas,dc=priv,dc=ldapproxy,dc=local
ldap://aassydc02.aas.priv/
suffixmassage "dc=aas,dc=priv,dc=ldapproxy,dc=local" "dc=aas,dc=priv"
chase-referrals no
lastmod off
protocol-version 3
timeout 10
#####################
With the above timeout setting, I was hoping that after 10 seconds,
OpenLDAP will try the next URI it the first URI did not respond ...
but it did not as per tshark capture below.
What setting do I need to accomplish what I need ?
0.000000 127.0.0.1 -> 127.0.0.1 TCP 76 50649 > ldap [SYN]
Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=133287492 TSecr=0
WS=128
0.000021 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50649 [SYN, ACK]
Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=133287492
TSecr=133287492 WS=128
0.000035 127.0.0.1 -> 127.0.0.1 TCP 68 50649 > ldap [ACK]
Seq=1 Ack=1 Win=32896 Len=0 TSval=133287492 TSecr=133287492
0.000090 127.0.0.1 -> 127.0.0.1 LDAP 118 bindRequest(1)
"cn=admin,dc=ldapproxy,dc=local" simple
0.000102 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50649 [ACK]
Seq=1 Ack=51 Win=32768 Len=0 TSval=133287492 TSecr=133287492
0.000829 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success
0.000856 127.0.0.1 -> 127.0.0.1 TCP 68 50649 > ldap [ACK]
Seq=51 Ack=15 Win=32896 Len=0 TSval=133287493 TSecr=133287493
0.000909 127.0.0.1 -> 127.0.0.1 LDAP 158 searchRequest(2)
"DC=ldapproxy,DC=local" wholeSubtree
0.001196 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133287493 TSecr=0
WS=128
0.040403 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50649 [ACK]
Seq=15 Ack=141 Win=32768 Len=0 TSval=133287503 TSecr=133287493
1.001055 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133287743 TSecr=0
WS=128
3.006852 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133288244 TSecr=0
WS=128
7.013361 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133289246 TSecr=0
WS=128
15.020550 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133291248 TSecr=0
WS=128
31.052492 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133295256 TSecr=0
WS=128
60.063874 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133302508 TSecr=0
WS=128
61.060500 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133302758 TSecr=0
WS=128
63.065447 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN]
Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133303259 TSecr=0
WS=128