You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2013/02/19 23:31:13 UTC
[Bug 54587] New: LDAPConnectionPoolTimeout does not work in all
cases
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Bug ID: 54587
Summary: LDAPConnectionPoolTimeout does not work in all cases
Product: Apache httpd-2
Version: 2.5-HEAD
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_ldap
Assignee: bugs@httpd.apache.org
Reporter: sf@sfritsch.de
Classification: Unclassified
I got a report from a user that LDAPConnectionPoolTimeout does not work. It
seems removing this check for l->bound fixes his problem:
--- a/modules/ldap/util_ldap.c
+++ b/modules/ldap/util_ldap.c
@@ -715,7 +715,7 @@ static util_ldap_connection_t *
&& !compare_client_certs(dc->client_certs, l->client_certs))
{
if (st->connection_pool_ttl > 0) {
- if (l->bound && (now - l->freed) > st->connection_pool_ttl) {
+ if ((now - l->freed) > st->connection_pool_ttl) {
ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r,
"Removing LDAP connection last used %"
APR_TIME_T_FMT " seconds ago",
(now - l->freed) / APR_USEC_PER_SEC);
Briefly looking through the code, I think this resetting of l->bound may be the
cause of the problem:
/*
* We have just bound the connection to a different user and password
* combination, which might be reused unintentionally next time this
* connection is used from the connection pool. To ensure no confusion,
* we mark the connection as unbound.
*/
ldc->bound = 0;
I haven't looked deeply enough to tell what would be the correct fix.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #16 from Christian Knierim <ch...@gmail.com> ---
The bug still might cause some errors. The occurrence is more seldom.
Let me explain with an example from one of our tests yesterday:
Connection to LDAP is established
[Mon Mar 04 14:46:33.147055 2013] [authnz_ldap:debug] [pid 10701]
mod_authnz_ldap.c(593): [client 10.54.1.199:59811] AH01697: auth_ldap
authenticate: accepting m051021
Client-Connect uses LDAP-authenticate, but this time user (m052246) is already
in cache
[Mon Mar 04 15:06:17.950988 2013] [authnz_ldap:debug] [pid 10701]
mod_authnz_ldap.c(593): [client 10.54.1.199:59884] AH01697: auth_ldap
authenticate: accepting m052246
Now the new patch “reuse.diff” will take place, with “Removing connection”.
Please note that the “2000 seconds ago” is calculated from 15:06 to 15:39.
But at 15:06, the LDAP server was not really asked. So the connection was in
fact idle from 14:46 to 15:39. The server will close after one hour. Good luck
this time.
[Mon Mar 04 15:39:38.356157 2013] [ldap:trace1] [pid 10701] util_ldap.c(732):
[client 10.58.230.5:45009] Removing LDAP connection last used 2000 seconds ago
[Mon Mar 04 15:39:38.356591 2013] [authnz_ldap:debug] [pid 10701]
mod_authnz_ldap.c(501): [client 10.58.230.5:45009] AH01691: auth_ldap
authenticate: using URL
ldaps://ldapqsu.xxx.xxx.de:636/ou=people,dc=hvb,dc=de?uid?one?(objectclass=hvb-userextension)
[Mon Mar 04 15:39:38.356637 2013] [authnz_ldap:trace1] [pid 10701]
mod_authnz_ldap.c(522): [client 10.58.230.5:45009] auth_ldap authenticate:
final authn filter is (&(objectclass=hvb-userextension)(uid=m052237))
[Mon Mar 04 15:39:38.356659 2013] [authnz_ldap:debug] [pid 10701]
mod_authnz_ldap.c(593): [client 10.58.230.5:45009] AH01697: auth_ldap
authenticate: accepting m052237
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #3 from Eric Covener <co...@gmail.com> ---
e.g.
http://people.apache.org/~covener/patches/trunk-ldap_unbind_vs_connttl.diff
this also removes the misleading trace and adds some other trace.
After the unbind during authn, the underlying conn is away. We can reuse an old
"ldc" but not an old underlying conn.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #15 from Eric Covener <co...@gmail.com> ---
> > We analyized and found out, that the LDAPConnectionPoolTTL seems to resetted
> > even if the ldap server is not connected and the information is taken from
> > the local caching file.
> >
Is this just a nuisance that causes a reconnect?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #7 from Eric Covener <co...@gmail.com> ---
maybe this helps? Includes new trace.
http://people.apache.org/~covener/patches/reuse.diff
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Christian Knierim <ch...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |christian.knierim@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #10 from Eric Covener <co...@gmail.com> ---
(In reply to comment #9)
> With the patch applied, the behaviour of timeout looks really good. It is
> working as expected. Thanks!
thanks for reporting & verifying
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #14 from Eric Covener <co...@gmail.com> ---
Actually it's a bit tricky :(
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |FixedInTrunk
--- Comment #11 from Eric Covener <co...@gmail.com> ---
r1452551 in trunk
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #2 from Eric Covener <co...@gmail.com> ---
(In reply to comment #1)
> maybe uldap_connection_unbind() instead of the assignment would help? Any
> details on original symptom?
This does seem to help. When LDAP authn is used, we don't let the bound
connection be re-used nor setaside a bound connection for each basic auth user.
Really unbinding means we lose the connection right away.
Note: we do have to defer the unbind until the end of uldap_cache_checkuserid.
I must have tested with authz where the conns are more easily re-used since
they are not tainted with the basic auth user creds.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #5 from Eric Covener <co...@gmail.com> ---
(In reply to comment #4)
> Hi!
>
> we set LDAPConnectionTimeout 60 in the configuration and tested your
> patch. With this patch, it looks like there is no connection pooling. All
> connections to ldap seem to be closed immediately after the ldap
> authentication process.
>
> ldap_free_request (origid 3, msgid 3)
> ldap_parse_result
> ldap_msgfree
> ldap_get_values
> ldap_msgfree
> ldap_free_connection 1 1
> ldap_send_unbind
> TLS trace: SSL3 alert write:warning:close notify
> ldap_free_connection: actually freed
That is true for connections used for authentication, because they have been
bound as the web users DN/password and should not be re-used. Connections
used for authz should not behave like this though.
The old code marked it as unbound but did not unbind it. This would cause it to
do e.g.:
ldap_open
ldap_simple_bind
(reused)
ldap_simple_bind
I do not know if this is valid. If it were, then I think we just need a third
state instead of bound/unbound and the check for the TTL needs to be aware of
it.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #18 from Eric Covener <co...@gmail.com> ---
(In reply to comment #17)
> Is the provided information from our logfiles enough?
> Or should we provide more details?
It's enough, to suit your needs we'd need to track the time we last did a
successful call on an LDAP handle, this is more work. Since the current field
is part of the API, we need a new field, but maybe LDAPConnectionTTL could just
apply to the new tracking w/o making more options.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Christian Knierim <ch...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Christian Knierim <ch...@gmail.com> ---
With the patch applied, the behaviour of timeout looks really good. It is
working as expected. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #13 from Eric Covener <co...@gmail.com> ---
(In reply to comment #12)
> Hi Eric,
>
> my colleague and me did some further testing. - We observed, that we still
> get admistrative limit exceeded in certain circumstances. - Not that often
> as before, but rarely it occurs.
>
> We analyized and found out, that the LDAPConnectionPoolTTL seems to resetted
> even if the ldap server is not connected and the information is taken from
> the local caching file.
>
> I think, our big issue is solved, but if you have any suggestions how to
> solve this issue, we would be happy to hear about it.
>
> Thanks and regards,
> Christian
Thanks for the detail here, that makes sense -- should not be tough with that
hint
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
Robert Lachmann <la...@web.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lachmannrobert@web.de
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #12 from Christian Knierim <ch...@gmail.com> ---
Hi Eric,
my colleague and me did some further testing. - We observed, that we still get
admistrative limit exceeded in certain circumstances. - Not that often as
before, but rarely it occurs.
We analyized and found out, that the LDAPConnectionPoolTTL seems to resetted
even if the ldap server is not connected and the information is taken from the
local caching file.
I think, our big issue is solved, but if you have any suggestions how to solve
this issue, we would be happy to hear about it.
Thanks and regards,
Christian
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #17 from Robert Lachmann <la...@web.de> ---
Is the provided information from our logfiles enough?
Or should we provide more details?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #6 from Eric Covener <co...@gmail.com> ---
spoke to someone formerly on the IBM LDAP SDK and they say that pattern is
perfectly normal -- so Christian, I will prepare an alternate that monitors the
connection status separate from the bound DN/pass.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #1 from Eric Covener <co...@gmail.com> ---
maybe uldap_connection_unbind() instead of the assignment would help? Any
details on original symptom?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #4 from Christian Knierim <ch...@gmail.com> ---
Hi!
we set LDAPConnectionTimeout 60 in the configuration and tested your patch.
With this patch, it looks like there is no connection pooling. All connections
to ldap seem to be closed immediately after the ldap authentication process.
ldap_free_request (origid 3, msgid 3)
ldap_parse_result
ldap_msgfree
ldap_get_values
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #8 from Christian Knierim <ch...@gmail.com> ---
Hi Eric,
thanks for the patch. We applied it and tested it on our Linux and Solaris
enviroment. It looks really great!
My colleague is now arraning a load and performance test. - I'll give you a
feedback afterwards.
Regards,
Christian
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54587] LDAPConnectionPoolTimeout does not work in all cases
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54587
--- Comment #19 from Eric Covener <co...@gmail.com> ---
This came up in another context and I've found an easy way to improve this that
doesn't run up a bunch of apr_time_now's. We should use the request arrival
time as a conservative baseline, which we can afford to do right after each
successful I/O.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org