OpenLDAP 2.3.35
I know about the time limit on the search, but is there a user-specified one on the connect?
I ask because when our primary LDAP server went down for maintenance, the various applications took around 2-3 minutes before trying the secondary server (accompanied by much wailing and gnashing of teeth).
I would've thought that the fail-over would have been practically instantaneous (which it is if the server in question is also the client's host); perhaps we have an errant packet filter in the way, but that's beyond the scope of this list.
As of 2.3.28, libldap's connections use TCP keepalives. You should be able to configure your networking stack to get the desired behavior.
On Wed, 18 Jul 2007, Dave Horsfall wrote:
OpenLDAP 2.3.35
I know about the time limit on the search, but is there a user-specified one on the connect?
I ask because when our primary LDAP server went down for maintenance, the various applications took around 2-3 minutes before trying the secondary server (accompanied by much wailing and gnashing of teeth).
I would've thought that the fail-over would have been practically instantaneous (which it is if the server in question is also the client's host); perhaps we have an errant packet filter in the way, but that's beyond the scope of this list.
-- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
On Wed, 18 Jul 2007, Dave Horsfall wrote:
I know about the time limit on the search, but is there a user-specified one on the connect?
The LDAP_OPT_NETWORK_TIMEOUT option sets a timeout on the connect() call itself. Its value is a struct timeval, so:
struct timeval tv; int err;
tv.tv_sec = timeout_in_seconds; tv.tv_usec = 0;
err = ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, &tv); if (err != LDAP_SUCCESS) report_the_error(err);
Note that the OS's normal timeout for connection attempts acts as the upper limit on the timeout: requesting a longer timeout will have no effect.
The above option *ONLY* affects the connection attempt and nothing after that.
Philip Guenther
On Wed, 18 Jul 2007, Aaron Richton wrote:
As of 2.3.28, libldap's connections use TCP keepalives. You should be able to configure your networking stack to get the desired behavior.
But the connection has yet to be made, so keepalives don't enter into it.
We're a homogenous FreeBSD shop, so I'd like to eliminate either FreeBSD or OpenLDAP as a possibility before filing this as a bug with one or the other. Can someone please do:
On client.example.net, set up ldap.conf with
URI ldap://server1.example.net ldap://server2.example.net
Server1, although resolving, does not run an LDAP server (and may not phyically exist). If it's on the same subnet as the client, then so much the better as that eliminates any router issues.
What I am seeing is a timeout of a minute before switching to Server2.
LDAP debugging:
ldap_create ldap_url_parse_ext(ldap://server2.example.net) ldap_url_parse_ext(ldap://server1.example.net) ldap_search put_filter: "(uid=daveh)" put_filter: simple put_simple_filter: "uid=daveh" ldap_send_initial_request ldap_new_connection ldap_int_open_connection ldap_connect_to_host: TCP server1.example.net:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.9:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3
Delay occurs here...
ldap_is_sock_ready: 3 ldap_is_socket_ready: error on socket 3: errno: 60 (Operation timed out) ldap_close_socket: 3 ldap_int_open_connection ldap_connect_to_host: TCP server2.example.net:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.XX.XX.XX:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_is_sock_ready: 3 ldap_ndelay_off: 3 ldap_open_defconn: successful
Etc.
Kernel trace around then:
1184800925.257583 CALL socket(0x2,0x1,0) 1184800925.257602 RET socket 3 1184800925.257624 CALL setsockopt(0x3,0x6,0x1,0xbfbfd8dc,0x4) 1184800925.257637 RET setsockopt 0 1184800925.257677 CALL fcntl(0x3,0x3,0x2804e58d) 1184800925.257689 RET fcntl 2 1184800925.257701 CALL fcntl(0x3,0x4,0x6) 1184800925.257712 RET fcntl 0 1184800925.257731 CALL connect(0x3,0x804f1a0,0x10) 1184800925.257793 RET connect -1 errno 36 Operation now in progress 1184800925.257826 CALL select(0x400,0,0xbfbfd850,0,0)
Delay here.
1184801000.246370 RET select 1 1184801000.246438 CALL getpeername(0x3,0xbfbfd790,0xbfbfd78c) 1184801000.246450 RET getpeername -1 errno 57 Socket is not connected 1184801000.246505 CALL read(0x3,0xbfbfd78b,0x1) 1184801000.246519 RET read -1 errno 60 Operation timed out 1184801000.246543 CALL shutdown(0x3,0x2) 1184801000.246556 RET shutdown -1 errno 22 Invalid argument 1184801000.246576 CALL close(0x3) 1184801000.246593 RET close 0
Revealingly, should the client attempt to contact itself first (where there is no server) then the switch-over happens right away, but the network guru swears up and down that there are no packet filters in the way.
On Wed, 18 Jul 2007, Philip Guenther wrote:
The LDAP_OPT_NETWORK_TIMEOUT option sets a timeout on the connect() call itself. Its value is a struct timeval, so:
That's worth a try; thanks.
On Thu, 19 Jul 2007, Dave Horsfall wrote:
But the connection has yet to be made, so keepalives don't enter into it.
Ah, I read "connection timeout" in the wrong sense here. As Philip's answer discussed, LDAP_OPT_NETWORK_TIMEOUT should result in
ldap_connect_timeout: fd: 3 tm: -1 async: 0
the "tm" value being lowered, resulting in
1184800925.257826 CALL select(0x400,0,0xbfbfd850,0,0)
delaying for less, and you should note that last select() argument changing to a timeval that matches your parameter. Give it a try...
Dave Horsfall wrote:
On Wed, 18 Jul 2007, Aaron Richton wrote:
As of 2.3.28, libldap's connections use TCP keepalives. You should be able to configure your networking stack to get the desired behavior.
But the connection has yet to be made, so keepalives don't enter into it.
We're a homogenous FreeBSD shop, so I'd like to eliminate either FreeBSD or OpenLDAP as a possibility before filing this as a bug with one or the other. Can someone please do:
On client.example.net, set up ldap.conf with
URI ldap://server1.example.net ldap://server2.example.net
Server1, although resolving, does not run an LDAP server (and may not phyically exist). If it's on the same subnet as the client, then so much the better as that eliminates any router issues.
What I am seeing is a timeout of a minute before switching to Server2.
That would be normal when trying to contact a nonexistent host, and depends entirely on your kernel's TCP stack/connection timeouts. As already noted, you can explicitly set a shorter timeout using LDAP_OPT_NETWORK_TIMEOUT.
Revealingly, should the client attempt to contact itself first (where there is no server) then the switch-over happens right away, but the network guru swears up and down that there are no packet filters in the way.
When a host is alive but simply has no server on the requested port, the TCP stack immediately sends a "connection refused" response to the client, so generally there should be no delay. Again, this is normal, and any "network guru" should know that.
Hi List,
I am using OpenLDAP 2.3.35 and was wondering if I really have to restart openldap after changing the userpassword attribute in the tree.
Is that true or do I have to do something else in order to have the changed password effective immediately without restarting openldap ?
Thanks a lot,
Kamil
Kamil Wencel wencel@radion.org writes:
Hi List,
I am using OpenLDAP 2.3.35 and was wondering if I really have to restart openldap after changing the userpassword attribute in the tree.
No, you don't have to restart slapd, who told you this ?
Dieter Kluenter writes:
Kamil Wencel wencel@radion.org writes:
I am using OpenLDAP 2.3.35 and was wondering if I really have to restart openldap after changing the userpassword attribute in the tree.
No, you don't have to restart slapd, who told you this ?
Maybe he or his source is confusing it with rootpw, which is set in slapd.conf. You must restart slapd for changes to slapd.conf to take effect. Though you can avoid that in OpenLDAP 2.3 or higher: It supports "database config", which lets you update the slapd configuration over the LDAP protocol.
On Thu, 19 Jul 2007, Dave Horsfall wrote:
On Wed, 18 Jul 2007, Philip Guenther wrote:
The LDAP_OPT_NETWORK_TIMEOUT option sets a timeout on the connect() call itself. Its value is a struct timeval, so:
That's worth a try; thanks.
It worked; thanks! I've wound it back to 5 seconds, so the typical user would see a delay of 15-20 seconds at fail-over time (we do a lot of chained LDAP lookups at login time).
(Still waiting to be unmoderated, after a change of email domain).
On Thu, 19 Jul 2007, Aaron Richton wrote:
1184800925.257826 CALL select(0x400,0,0xbfbfd850,0,0)
delaying for less, and you should note that last select() argument changing to a timeval that matches your parameter. Give it a try...
No need; Howard spotted the real problem (as usual); it's in the next post. Thanks anyway.
I didn't see any point in participating in a semi-realtime discussion whilst still being moderated...
On Thu, 19 Jul 2007, Howard Chu wrote:
What I am seeing is a timeout of a minute before switching to Server2.
That would be normal when trying to contact a nonexistent host, and depends entirely on your kernel's TCP stack/connection timeouts. As already noted, you can explicitly set a shorter timeout using LDAP_OPT_NETWORK_TIMEOUT.
Which I've now built into our applications, as OpenLDAP itself would appear to have no support for this situation. I suppose I should contribute a patch or something, along the lines of "CONN_TIMEOUT 5" etc.
Revealingly, should the client attempt to contact itself first (where there is no server) then the switch-over happens right away, but the network guru swears up and down that there are no packet filters in the way.
When a host is alive but simply has no server on the requested port, the TCP stack immediately sends a "connection refused" response to the client, so generally there should be no delay. Again, this is normal, and any "network guru" should know that.
My fault; I misled said guru...
Dave Horsfall wrote:
On Thu, 19 Jul 2007, Howard Chu wrote:
What I am seeing is a timeout of a minute before switching to Server2.
That would be normal when trying to contact a nonexistent host, and depends entirely on your kernel's TCP stack/connection timeouts. As already noted, you can explicitly set a shorter timeout using LDAP_OPT_NETWORK_TIMEOUT.
Which I've now built into our applications, as OpenLDAP itself would appear to have no support for this situation. I suppose I should contribute a patch or something, along the lines of "CONN_TIMEOUT 5" etc.
That is definitely something we consider to be application-specific. Building the setting into your app is the correct solution.
In general, settings in the config file must always be overridable, so a new config option would also need to provide a new command line argument for the ldap* tools.
Otherwise, you might find yourself unable to ldapsearch a distant LDAP server because your timeout that you tuned for your local servers is too short...
Howard Chu hyc@symas.com wrote:
That is definitely something we consider to be application-specific. Building the setting into your app is the correct solution.
In general, settings in the config file must always be overridable, so a new config option would also need to provide a new command line argument for the ldap* tools.
Otherwise, you might find yourself unable to ldapsearch a distant LDAP server because your timeout that you tuned for your local servers is too short...
But there is a default setting, the point is just that it's hard-coded. Having it system-configurable and user-configurable would not hurt, IMO
Emmanuel Dreyfus wrote:
Howard Chu hyc@symas.com wrote:
That is definitely something we consider to be application-specific. Building the setting into your app is the correct solution.
In general, settings in the config file must always be overridable, so a new config option would also need to provide a new command line argument for the ldap* tools.
Otherwise, you might find yourself unable to ldapsearch a distant LDAP server because your timeout that you tuned for your local servers is too short...
But there is a default setting, the point is just that it's hard-coded. Having it system-configurable and user-configurable would not hurt, IMO
You haven't thought it through. If a config file universally sets a short value and a particular application is not written to handle timeouts and retries then it will fail mysteriously. Application code must be aware of timeouts and since they must be explicitly coded for them already, it is only appropriate to leave this setting to them.
libldap has no default setting for the connection timeout, that is purely an OS/kernel item.
openldap-software@openldap.org
-
Aaron Richton -
Dave Horsfall -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Kamil Wencel -
manu＠netbsd.org -
Philip Guenther