Re: (ITS#5363) ldapsearch hangs when using ldap for host in nsswitch

[rra@stanford.edu]

Howard Chu <hyc@symas.com> writes:

> libldap_r was written solely for use by slapd and slurpd. Anybody else
> who uses it does so at their own risk. Applications are supposed to link
> with libldap. This has been stated several times before.

Unfortunately, I still need to figure out how best to fix the problem and
that by itself doesn't give me a way, but I do understand where you're
coming from.

> Unfortunately your problems with libnss-ldap are outside our purview,
> and any ITS relating to it will just be closed/rejected. The fact that
> nss-ldap is essentially broken is not for us to fix. The problems you
> encounter from breaking our Makefiles in response to the nss-ldap
> problems are also obviously not for us to fix; you did that to yourself.

In, I should point out, a testing version as a short-term way of getting
2.4.7 into the archive so that we could throw out 2.1, which I'm sure
you'd agree is a great good.  :)  I was always planning on trying to
replace this solution with something that you felt you could support; we
were just trying to do one thing at a time.

We'll talk this over and see if there's a way that we can either move from
nss-ldap or try to get it out of the places where it causes problems,
although that's going to be really rough going as you can probably
imagine.  libnss-ldap has over 2,800 installations that report popcon
statistics, which means a *lot* of people are using it.

Thinking out-loud here a bit (because I really want to solve this problem
in the long run in a way that you can support), libnss-ldap and slapd on
the same system are instant death unless everything uses libldap_r.  If we
have slapd conflict with libnss-ldap and then have only slapd use
libldap_r (and make people use libnss-ldapd on systems that are also
running slapd), we may solve a fair chunk of the problem.  The other place
where libldap is pulled in is via PAM, but slapd itself should never need
to call into PAM (even indirectly).

If any slapd backends load dynamic libraries that in turn load libldap,
the world may also explode, but this should only affect back-perl, which
isn't working right now anyway due to the libtool RTLD_GLOBAL issues.

> The other obvious step in this situation is never to use LDAP for
> hostname resolution. ("Doctor, it hurts when I do this." - "Don't do
> that.") LDAP is a much heavier weight protocol than DNS; as such it's
> simply the wrong tool for the job. (Note - I like using DNS servers
> backed by LDAP, but that's a completely different situation.)

Okay.  I can at least pass that along to the user.

Thanks for the response.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>