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.