Проблемы с бэкендом LDAP в OpenLDAP

As surmised @c4f4t0r, you're not (yet) having configuration problems -- you're having build related problems.

TL;DR: don't use dynamic backends, they're mostly broken unless you fiddle with the build process. Skip to the update below for the gruesome details...

You probably have old or non-OpenLDAP LDAP libraries in the default system locations. I do not believe the configure script is smart enough to test for this condition, or that the build process is sufficiently robust to handle it. For example if an old libldap.so is found in a system library location then it will be used in preference to the correct and freshly installed libldap.so at runtime. Running ldd against back_ldap-2.4.so should show this.

You may be able to fix this (without rebuilding) by adding the relevant directory to the environment variable LD_LIBRARY_PATH so that the directory with the newest OpenLDAP libraries is searched first (make sure to export the variable).

Or, fix it (preferably) at build time, by running configure with the LDFLAGS environment variable set with an RPATH which will hard-code a library search path into the binaries you build.

You haven't given your configure options or installation path etc. I have used variations on this in the past:

export LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/ssl/lib"

in the case where I want to use a non-system OpenSSL, the same applies for using a non-system version of BerkeleyDB. On Solaris you may need to use "-R" instead of "-rpath" (if you're using gcc with the Sun linker rather than the GNU linker):

export LDFLAGS="-L/usr/local/ssl/lib -R/usr/local/ssl/lib"

In your case you probably just need to set the rpath (-Wl,-rpath or -R), not -L (though I recommend using both when for the cases of OpenSSL and BerkeleyDB).

Update You are building with:

/configure --prefix=/usr --sysconfdir=/etc --enable-slapd --enable-crypt \
    --enable-modules --enable-bdb=mod --enable-hdb=mod --enable-ldap=yes \
    --enable-perl=mod --enable-overlays=mod --with-tls --with-gnu-ld

Note "--enable-ldap=yes", this builds the LDAP-backend statically into slapd, it does not create a dynamically loadable back_ldap.so (i.e. --enable-ldap=mod). One possibility is that you have a stray back_ldap.so that you are trying to load into your server, and an un-needed moduleload back_ldap. However, slapd will not allow you to load a dynamic module when a static module of the same name exists, so your slapd binary does not appear to be as you have described.

Run slapd -VVV to confirm static backends.

Assuming back_ldap is static you should be able to work around this problem, and remove any errant moduleload and stale .so for good measure.

I have a strong suspicion there is some libtool, dependency error or linker issue lurking here. I can reproduce this with a dynamic back_ldap. ldap_add_ext is indeed an unresolved symbol which isn't necessarily a problem (due to explicit dlopen() for modules), but that symbol is not exported by slapd. It is exported by libldap.so, but that's not a dependency of back_ldap.so and nothing else causes libldap to be loaded. (This also means the advice I gave above won't solve the problem, since it's not simply as simple as a library path problem.)

What's happening (i.e. the error you're seeing) is that the symbol ldap_add_ext isn't being resolved until it's required ("lazy" binding). When you try to add an LDAP object it is finally required of course. Then the wheels come off. (Should you feel the urge, you can break it at start-time by exporting LD_BIND_NOW=1 which turns off lazy binding, then start slapd, though odds are a different symbol will trip it.)

Right now the simplest option is to work with a static back_ldap (--enable-ldap=yes, and perhaps make clean && make depend && make install to be certain that slapd is correctly built). A less simple option is to use LD_PRELOAD=/usr/lib/libldap.soLD_PRELOAD=/usr/lib/libldap_r.so to work around the dependency problem, and cross-your fingers hoping that doesn't have some odd side-effects.

OK, this ancient email covers the problem: http://www.openldap.org/lists/openldap-software/200211/msg00469.html slapd is linked against a static libldap_r.a by default, this limits the symbols that will be available to those known at link time. Since the dynamic modules are loaded at run time with dlopen() the linker doesn't have visibility of their requirements (symbols/libraries).

One might reasonably conclude that dynamic building of (some) backends has been pretty much broken for some time.

So, either don't use dynamic backends (recommended), or fudge the build (not so recommended) with something like:

make depend && make
rm servers/slapd/slapd
LTSTATIC="" make -e     # alternative to editing the Makefile
make install

This links slapd against the libldap_r.so you just built instead of the .a, so all symbols can be loaded when needed (it also makes slapd about 15% smaller on disk). I haven't run an operational LDAP server with this, YMMV. There must be some similar or alternative solutions used by distros...