On Thu, 29 Aug 2002, Phil Chambers wrote:
> I am not an LDAP expert, so I may need to be corrected here. If so,
> my apologies. It may also be a difference between versions of LDAP (I
> have openldap2).
IANALE either, but I test with OpenLDAP2 (though a very silly small
amount of data). Note that I put up a testing version of Exim yesterday,
with revised LDAP code (but which doesn't affect this issue).
> I have only looked at the SEARCH_LDAP_AUTH case, but expect the same
> problem in all cases . As far as I can see control_ldap_search() in
> ldap.c will only work along the list of ldap servers if ldap_init()
> fails.
The latest code uses ldap_initialize() for OpenLDAP2, but the effect is
the same. I don't agree with your conclusion, however. The return from a
failing ldap_init[ialize]() is exactly the same as from a failing
ldap_bind(), the the working along the list should be the same.
Aha! But you are talking about SEARCH_LDAP_AUTH (which happens for an
ldapauth lookup). That is different. That does do a fail if ldap_bind()
fails.
> The
> man page for ldap_init() says it does not make a connection, so the
> connection is made by the call to ldap_bind(). I have checked some
> code outside of exim and find that ldap_init() still retuns OK even
> when given the name of a server which does not run ldap. It looks to
> me as if one needs to check the return code from ldap_bind() for
> LDAP_UNAVAILABLE and treat that as DEFER.
I agree with that for the ldapauth case (from what little I know about
LDAP). Looking at the error list, I see also LDAP_BUSY. In fact, perhaps
what is needed is an explicit check for LDAP_INVALID_CREDENTIALS for the
current behaviour, with anything else just carrying on. I'll do some
experiments. The code change would be utterly trivial.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
