Le 26/06/2012 21:25, Quanah Gibson-Mount a écrit :
--On Tuesday, June 26, 2012 10:27 AM +0200 Guillaume Rousse guillomovitch@gmail.com wrote:
Le 25/06/2012 20:06, Quanah Gibson-Mount a écrit :
--On Monday, June 25, 2012 1:46 PM +0200 Guillaume Rousse guillomovitch@gmail.com wrote:
Hello list.
I recently faced a strange issue while upgrading from openldap 2.3 to 2.4 (from centos 5.7 to 6.2, actually): the change was transparent for every applications excepted Zimbra, for which any authentication attempt was suffering from an unexplained 30s additional delay. Just switching from explicit TLS usage on port 389 to explicit SSL usage on port 636 was enough to fix the issue.
I would use ldapsearch -d -1 to see what function it was hanging in.
Unfortunatly (sort of), I can't reproduce the issue with any other client as zimbra itself... ldapsearch works fine, even when run from the same host as zimbra.
ldapsearch against the zimbra server works fine (no delay on closing)? Then that would imply the issue is with whatever client is making the connection to Zimbra. It looks like slapd is simply detecting the connection was never closed properly after about 30 seconds, and taking care of closing it. I don't specifically see any issue here. Initially I thought you were saying you were seeing this issue while initiating a connection, not while closing it.
Sorry, I'm not a Zimbra admin, and I may have been confusing in my explanations. The problem occurs with Zimbra acting as an LDAP client against an external LDAP server, performing a bind operation for authenticating users, with the following behaviour:
Zimbra against on openldap 2.3.x server, with TLS on port 389: OK Zimbra against on openldap 2.4.x server, on port 636: OK Zimbra against on openldap 2.4.x server, with TLS on port 389: 30s delay
The mail admin is supposed to report a bug to Zimbra support.