10:14 p.m.
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
7:57 a.m.
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
1:57 p.m.
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
4:46 p.m.
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.
--
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
4:51 p.m.
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.
--
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
7:14 a.m.
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...
2:18 p.m.
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:28 a.m.
New subject: OpenLDAP restart required after password change
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
11:24 a.m.
New subject: OpenLDAP restart required after password change
Kamil Wencel <wencel(a)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 Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
11:59 a.m.
New subject: OpenLDAP restart required after password change
Dieter Kluenter writes:
Kamil Wencel <wencel(a)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.
--
Regards,
Hallvard
10:18 p.m.
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).
--
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
10:33 p.m.
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...
--
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
10:41 p.m.
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 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
7:12 a.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:37 a.m.
Howard Chu <hyc(a)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
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
9:49 a.m.
Emmanuel Dreyfus wrote:
Howard Chu <hyc(a)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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5797
days inactive
5801
days old
openldap-software@openldap.org
15 comments
8 participants
participants (8)
-
Aaron Richton -
Dave Horsfall -
Dieter Kluenter -
Hallvard B Furuseth -
Howard Chu -
Kamil Wencel -
manu＠netbsd.org -
Philip Guenther