Hi Heikki, On Tue, Nov 19, 2013 at 10:52:34PM +0100, Heikki Vatiainen wrote: > On 11/17/2013 11:04 PM, Klara Mall wrote: > > >> I reported it as a bug but it was rejected: > >> https://rt.cpan.org/Public/Bug/Display.html?id=90453 > >> > >> I think Steffen didn't understand what I wanted to say but I replied > >> and tried to explain it again. > > > > Now he did understand it. :) > > It's a bug in Net::LDAP: > > https://rt.cpan.org/Public/Bug/Display.html?id=90459 > > thanks for keeping us informed about this. I think we'll have a note in > the documentation about this too. I'll keep an eye on the ticket to see > what the maintainer says.
A note in the documentation is a good idea I think. As you said mixing TLS / SSL won't be done very often but if you do, it is likely that you are lost because it's so hard to understand where the problem comes from (if you don't ask here and get the information to enable debug output for IO::Socket::SSL ;) ). I remember that I first faced the problem in June when I upgraded from Debian squeeze to wheezy. I didn't understand it. I just remember that (I have a configuration with very many different authentication scenarios) there were different situations where the LDAP connection failed. The most stupid one was where the error appeared only when the first LDAP server was not responding (because only connecting to the second one caused that the TLS/SSL mix had two different LDAP servers). So the backup server was up and running but it could not be used. I managed it to alter the configuration (by trial and error) until it was working at least when no LDAP server had a problem. But I wasn't able to resolve the thing with the backup LDAP server. It was very confusing and frustrating. But now I know everything was caused by the one faulty line in Net::LDAP. I'm so happy that I finally understand the whole thing. Thanks Klara _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
