Le 28/06/2012 01:41, Quanah Gibson-Mount a écrit :
--On Wednesday, June 27, 2012 3:31 PM +0200 Guillaume Rousse
<[email protected]> wrote:
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
Ok, so what you are saying is:
You upgraded your OS to CentOS6
You use external auth
The external auth from CentOS6 to your own LDAP server shows a 30 second
delay on closing.
Almost :)
I upgraded the OS of the machine running the LDAP server, the zimbra
server didn't change. So, that's the external auth from a RHEL 5.8
system running Zimbra 7, against a Centos 6.2 system running OpenLDAP
2.4.24.
That sounds like a bug in Java/JNDI. I did see some 30 second issues
with RHEL6, but it was with initiating a connection, not closing it.
Indeed. I don't see why either the ldap server or the ldap client would
need to perform any DNS query once the connection has been accepted, and
the TLS negociation was successful.
You can see more about that at
<https://stomp.colorado.edu/blog/blog/2011/06/29/on-rhel-6-ssh-dns-firewalls-and-slow-logins/>
I would note that JNDI behavior varies based on startTLS vs SSL on port
636 as well.
Interesting. We tried the workaround, on both side (openldap server,
then zimbra server), without any behaviour change.
The only thing I'm unsure, tough, is about the moment where a change in
resolver configuration has an effect. As the resolver is technicaly a
part of the glibc, and can never get reloaded, I guess it uses the file
timestamp to detect file modification and reload it immediatly.
Also, I'll try to find some other example of java-based applications
acting as LDAP client, in our environement
--
BOFH excuse #443:
Zombie processes detected, machine is haunted.
