Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Good Morning;

After working on setting up an LDAP proxy server to replicate LDAP data, I keep getting the following message:

52a0b5ca send_ldap_result: conn=-1 op=0 p=3

52a0b5ca send_ldap_result: err=32 matched="" text=""

52a0b5ca ==> ldap_back_add("dc=basecorp,dc=net")

52a0b5ca =>ldap_back_getconn: conn 0x7f40ea0 fetched refcnt=1.

/usr/libexec/slapd: symbol lookup error: /usr/libexec/openldap/ undefined symbol: ldap_add_ext

This is with OpenLDAP 2.4.37 on both a Solaris 10 x86 host as well as a RedHat 5.5 host. Both are installed from sources, including the latest BDB distro. sourceserver is the machine I wish to pull data from and sync to destserver (see configs below).

So, the only thing the two machines I've tried running the proxy on have in common is me (ugh!). Is the issue that I've setup the proxy backwards? Perhaps I'm not allowed to add an entry to an LDAP backend? Hopefully, one of y'all can examine my configs below and answer my question as well as many others out there.

My slapd.conf for the proxy:

database ldap
hidden on
suffix "dc=basecorp,dc=net"
rootdn "cn=Manager"
uri    ldaps://

lastmod on

acl-bind  bindmethod=simple

syncrepl  rid=500
          retry="5 5 300 5"

overlay   syncprov

Lastly, allow me to throw mud in the water:

I used nm:

[root@buildtest01 ~]# nm  /usr/libexec/openldap/ | grep ldap_add
                 U ldap_add_ext

And there's my missing symbol. Wth!?

share|improve this question
ldd /usr/libexec/slapd and setting LD_DEBUG=1 ? after setting LD_DEBUG=1 lanch the slapd manualy – c4f4t0r Dec 5 '13 at 20:07
up vote 1 down vote accepted

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 is found in a system library location then it will be used in preference to the correct and freshly installed at runtime. Running ldd against 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 (i.e. --enable-ldap=mod). One possibility is that you have a stray 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, but that's not a dependency of 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/ 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: 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 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...

share|improve this answer
Compiler options: ./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 [root@btnbuildtest01 openldap]# echo $LD_LIBRARY_PATH /usr/libexec/openldap:/lib:/usr/lib:/usr/local/lib 52af701e =>ldap_back_getconn: conn 0x1bf86ea0 fetched refcnt=1. /usr/libexec/slapd: symbol lookup error: /usr/libexec/openldap/ undefined symbol: ldap_add_ext – Eirik Toft Dec 16 '13 at 21:27

This isn't a configuration problem, the error is clear, is telling you, the openldap are looking for a function in /usr/libexec/openldap/ library that isn't there.

On redhat 5, why you don't use the standard ldap in rpm format?

share|improve this answer
Please re-read the issue. This happens on both a solaris 10 machine as well as a red hat box. Two different machines with the same issue. So the configuration issue - can I add an entry using replication to an LDAP backend? (I know what the error message means, I want to know why I'm getting it) – Eirik Toft Dec 5 '13 at 18:41
sorry i missing you used nm to check your library, but anyway your error is slapd don't find the funciton in the library, in nm U letter means "U" The symbol is undefined, What is more important here is however the symbol U before the function name. It says that this function is not defined in the object file and the linker should take it either from other object file or from the library. – c4f4t0r Dec 5 '13 at 20:28
So, the deal is that these LDAP servers run just fine. I'm attempting to setup the push proxy (I have not done this), and thought I might be attempting to do something impossible (like update a database that is mounted as an ldap backend). It would certainly explain the same two errors on different platforms, almost like add was called on a database object that didn't implement the ldap_add_ext function, and maybe no error handling was implemented in the code to catch this. – Eirik Toft Dec 5 '13 at 22:03
I retract my above statement after reviewing the fact that in the source they've clearly implemented this method. Which again, falls back on me. – Eirik Toft Dec 5 '13 at 23:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.