Hi,
Seems like loading SLAPI plugins is broken. I tried to play with addrdnvalues.c from the distribution, compiled it like it was recommended in the README:
gcc -shared -I../../../include -Wall -g -o libaddrdnvalues-plugin.so addrdnvalues.c
and tried to load from slapd.conf:
plugin preoperation /usr/local/lib/libaddrdnvalues-plugin.so addrdnvalues_preop_init
Here is what I've got running slapd:
================================================================================ [root@localhost ~]# /usr/local/libexec/slapd -u ldap -g ldap -d stats -f /etc/openldap/slapd.conf 4e9e21b0 @(#) $OpenLDAP: slapd 2.X (Oct 19 2011 02:18:15) $ mitya@localhost.localdomain:/usr/local/libexec/slapd failed to load plugin /usr/local/lib/libaddrdnvalues-plugin.so: file not found 4e9e21b0 slapd stopped. 4e9e21b0 connections_destroy: nothing to destroy. ================================================================================
The file /usr/local/lib/libaddrdnvalues-plugin.so exists and is readable; strace shows that it is in fact being opened successfully. Putting it into /usr/lib, /usr/lib/openldap and other locations does not help. This "file not found" message in fact is a well-known libltdl issue: lt_dlerror() reports "file not found" in any case of unsuccessful library loading attempt, including missing dependencies and unresolved symbols. Libtoolizing this plugin and supplying a .la file instead of .so does not help either. I am running current git master under Mandriva 2010.2 with libtool 2.2.6b, tried libtool 2.4 with the same result. Linking the plugin with explicit -lldap -lslapi (to satisfy potentially unresolved symbols) does not help. libslapi.so is in the library path. Statically linked slapd (with slapi_, ldap_ and ber_ functions) works the same way. Any suggestions?
Dimitri
On Wed, 19 Oct 2011, Dimitri wrote:
potentially unresolved symbols) does not help. libslapi.so is in the library path. Statically linked slapd (with slapi_, ldap_ and ber_ functions) works the same way. Any suggestions?
Set your dynamic linker to debugging mode(s), and see if you can get a clue as to what precisely is going wrong with the dlopen()?
Set your dynamic linker to debugging mode(s), and see if you can get a clue as to what precisely is going wrong with the dlopen()?
Matter is, OpenLDAP loads SLAPI plugins (as well as backend modules) with the help of libtools' ltdl library, a cross-platform wrapper over platform specific dynamic library loading mechanisms. If you know how to enable debug mode for ltdl, I'll be thankful if you tell me about it :)
Dimitri
On Wed, 19 Oct 2011, Dimitri wrote:
Set your dynamic linker to debugging mode(s), and see if you can get a clue as to what precisely is going wrong with the dlopen()?
Matter is, OpenLDAP loads SLAPI plugins (as well as backend modules) with the help of libtools' ltdl library, a cross-platform wrapper over platform specific dynamic library loading mechanisms. If you know how to enable debug mode for ltdl, I'll be thankful if you tell me about it :)
Perhaps you could compile libltdl defining LT_DEBUG_LOADERS.
However, this is probably beside the point. I'd sooner check with a debugger if you're actually calling dlopen("/proper/path/to/the.so"). If you are, it's unlikely that you'll need to debug libtool itself; it has successfully performed its wrapping and things are now in the hands of your linker. I doubt you'd find anything of note by debugging libtool itself in this scenario.
If you never make it to an actual dlopen(), you're right, you may want libtool debugging.
I have tried putting ld-linux.so into debug mode (using LD_DEBUG=all), but it has shown no anomalies. Seems like it's purely ltdl issue. Does anyone have any evidence of SLAPI plugins being successfully loaded? If yes, which version of ltdl was used?
Dimitri
However, this is probably beside the point. I'd sooner check with a debugger if you're actually calling dlopen("/proper/path/to/the.so"). If you are, it's unlikely that you'll need to debug libtool itself; it has successfully performed its wrapping and things are now in the hands of your linker. I doubt you'd find anything of note by debugging libtool itself in this scenario.
If you never make it to an actual dlopen(), you're right, you may want libtool debugging.
Yes, plugin library is actually being loaded. But after that it pulls libslapi.so, unsuccessfully. My bad, last time I haven't noticed an important line in ld-linux.so debug output:
/usr/local/lib/libslapi-2-devel.so.0: error: symbol lookup error: undefined symbol: entry2str_mutex (fatal)
That's why ltdl cannot load a plugin. However, this doesn't make things much clearer: that entry2str_mutex symbol is definitely present in the slapd binary, according to nm output:
[root@localhost slapd]$ nm slapd | grep entry2str_mutex 082676b0 B entry2str_mutex
Dimitri
On 19/10/2011 6:05 μμ, Dimitri wrote:
I have tried putting ld-linux.so into debug mode (using LD_DEBUG=all), but it has shown no anomalies. Seems like it's purely ltdl issue. Does anyone have any evidence of SLAPI plugins being successfully loaded? If yes, which version of ltdl was used?
Dimitri
I am using LTB Project RPMs and Symas Silver RPMs (I am using x86_64 on CentOS 5.7) which have SLAPI enabled. OpenLDAP v2.4.26 is available.
I've tested SLAPI with slapi-dnsnotify on Symas Silver RPMs and worked flawlessly.
ltdl version: libltdl.so.3.1.4.
Nick
Dimitri wrote:
However, this is probably beside the point. I'd sooner check with a debugger if you're actually calling dlopen("/proper/path/to/the.so"). If you are, it's unlikely that you'll need to debug libtool itself; it has successfully performed its wrapping and things are now in the hands of your linker. I doubt you'd find anything of note by debugging libtool itself in this scenario.
If you never make it to an actual dlopen(), you're right, you may want libtool debugging.
Yes, plugin library is actually being loaded. But after that it pulls libslapi.so, unsuccessfully. My bad, last time I haven't noticed an important line in ld-linux.so debug output:
/usr/local/lib/libslapi-2-devel.so.0: error: symbol lookup error: undefined symbol: entry2str_mutex (fatal)
Let me guess - you're on Debian or Ubuntu.
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/478827
That's why ltdl cannot load a plugin. However, this doesn't make things much clearer: that entry2str_mutex symbol is definitely present in the slapd binary, according to nm output:
[root@localhost slapd]$ nm slapd | grep entry2str_mutex 082676b0 B entry2str_mutex
Sounds like the slapd binary was not built correctly (so the symbol didn't get exported from the binary) or the libslapi binary was not built correctly (and doesn't have a runtime link dependency on the slapd binary).
Nick Milas wrote:
On 19/10/2011 6:05 μμ, Dimitri wrote:
I have tried putting ld-linux.so into debug mode (using LD_DEBUG=all), but it has shown no anomalies. Seems like it's purely ltdl issue. Does anyone have any evidence of SLAPI plugins being successfully loaded? If yes, which version of ltdl was used?
Dimitri
I am using LTB Project RPMs and Symas Silver RPMs (I am using x86_64 on CentOS 5.7) which have SLAPI enabled. OpenLDAP v2.4.26 is available.
I've tested SLAPI with slapi-dnsnotify on Symas Silver RPMs and worked flawlessly.
Thanks for the independent confirmation. The original poster is probably on a Debian-derived distro with a broken libltdl, and that's their problem, not an OpenLDAP Project issue.
ltdl version: libltdl.so.3.1.4.
Dimitri,
If you are on Debian-Ubuntu (or similar), you could try using Symas Silver version for Debian which is SLAPI enabled:
Release notes: http://www.symas.com/updates/?p=85 Downloads: http://www.symas.net/portal
Good luck, Nick
On 19/10/2011 7:13 μμ, Howard Chu wrote:
The original poster is probably on a Debian-derived distro
False alert everyone - SLAPI plugins do work normally. I am using Mandriva, and, since Mandriva's OpenLDAP is built without SLAPI support, I had to build OpenLDAP myself. First time I've configured it with just "--enable-slapi --enable-bdb" (and plugins did not load), then I've tried "--enable-slapi --enable-dynamic --enable-bdb", and everything worked. Would be good if "--enable-slapi" would automatically imply "--enable-dynamic", since it isn't very obvious for an end-user.
Dimitri
P.S. For those who might be interested, I've completed an alpha version of OATH HOTP plugin, and it works pretty well. See my previous post for details.
openldap-technical@openldap.org
-
Aaron Richton -
Dimitri -
Howard Chu -
Nick Milas