rlm_python and dynload problem
Aurélien Geron
aureliengeron.freeradius at wifirst.fr
Thu Jan 6 15:46:07 CET 2011
Hi Josip,
Here are a few commands that I just launched on my server:
#uname -a
Linux maggie 2.6.26-2-amd64 #1 SMP Thu Nov 25 04:30:55 UTC 2010 x86_64 GNU/Linux
#dpkg -l | grep libltdl
ii libltdl3 1.5.26-4+lenny1 A system independent dlopen wrapper for GNU
ii libltdl7 2.2.6b-2~bpo50+1 A system independent dlopen wrapper for GNU
#dpkg -l | grep freeradius
ii freeradius 2.1.10+dfsg-2~bpo50+1 a high-performance and highly configurable R
ii freeradius-common 2.1.10+dfsg-2~bpo50+1 FreeRADIUS common files
ii freeradius-ldap 2.1.10+dfsg-2~bpo50+1 LDAP module for FreeRADIUS server
ii freeradius-mysql 2.1.10+dfsg-2~bpo50+1 MySQL module for FreeRADIUS server
ii freeradius-utils 2.1.10+dfsg-2~bpo50+1 FreeRADIUS client utilities
ii libfreeradius2 2.1.10+dfsg-2~bpo50+1 FreeRADIUS shared library
#ldd /usr/sbin/freeradius
linux-vdso.so.1 => (0x00007fff701db000)
libfreeradius-radius-2.1.10.so => /usr/lib/freeradius/libfreeradius-radius-2.1.10.so (0x00007f1018ce1000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00007f1018ac9000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00007f10188b5000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1018699000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f1018461000)
libltdl.so.7 => /usr/lib/libltdl.so.7 (0x00007f1018258000)
libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f1018006000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f1017c6b000)
libc.so.6 => /lib/libc.so.6 (0x00007f1017918000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1018f03000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f1017714000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f10174fd000)
=> FreeRADIUS seems to rely on libltdl.so.7, as expected.
#ls -la /usr/lib/libltdl.so.7*
lrwxrwxrwx 1 root root 16 2010-12-29 17:41 /usr/lib/libltdl.so.7 -> libltdl.so.7.2.1
-rw-r--r-- 1 root root 36408 2010-08-13 13:51 /usr/lib/libltdl.so.7.2.1
#ltrace -S -o freeradius.ltrace -C freeradius -X
#tail freeradius.ltrace
<... write resumed> ) = 96
vsnprintf(""", 4414891, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 0x435dac) = 45
vsnprintf("\001\200\255\373\351\177", 4396650, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 0x43166a) = 81
write(1, "/etc/freeradius/modules/python[6"..., 82 <unfinished ...>
SYS_write(1, "/etc/freeradius/modules/python[6"..., 82) = 82
<... write resumed> ) = 82
free(0xfd4930) = <void>
exit(1 <unfinished ...>
SYS_exit_group(1 <no return ...>
+++ exited (status 1) +++
#grep -i advise freeradius.ltrace
=> [no output] Apparently, the string "advise" is nowhere in ltrace's output.
#grep lt_dl freeradius.ltrace
lt_dlpreload_default(0x4303c0, 0x1bbe030, 1, 0x1be15d0, 4) = 0
lt_dlinit(0x4303c0, 0x1bbe030, 1, 0x1be15d0, 4) = 0
lt_dlsetsearchpath(0x1bea110, 0x7f27c34d4086, 0, 0xffffffff, 0) = 0
lt_dlopenext(0x7fff94d3d210, 0x7fff94d3d000, 0, 0x7fff94d3d219, 0x2525252525252525 <unfinished ...>
<... lt_dlopenext resumed> ) = 0x1cffe10
lt_dlsym(0x1cffe10, 0x7fff94d3d110, 0x2d2d2d2d2d2d2d2d, 0x2d2d2d2d2d6d002d, 0xfefefefefefefeff) = 0x7f27c2771f40
lt_dlopenext(0x7fff94d3d210, 0x1d004a6, 0, 0xffffffff, 0x2525252525252525 <unfinished ...>
<... lt_dlopenext resumed> ) = 0x1d00970
lt_dlsym(0x1d00970, 0x7fff94d3d110, 0x2d2d2d2d2d2d2d2d, 0x2d2d2d2d2d6d002d, 0xfefefefefefefeff) = 0x7f27c256f360
lt_dlopenext(0x7fff94d3d210, 0x1d00fd7, 0, 0xffffffff, 0x2525252525252525 <unfinished ...>
<... lt_dlopenext resumed> ) = 0x1d01730
lt_dlsym(0x1d01730, 0x7fff94d3d110, 0xfeff6d6e68736071, 0x6e6f69746172, 0xfefefefefefefeff) = 0x7f27c236c3a0
lt_dlopenext(0x7fff94d3d210, 0x1d00fd4, 0, 0xffffffff, 0x2525252525252525 <unfinished ...>
<... lt_dlopenext resumed> ) = 0x1d020b0
lt_dlsym(0x1d020b0, 0x7fff94d3d110, 0xfefeff646c68736d, 0x656d69746e, 0xfefefefefefefeff) = 0x7f27c216a580
lt_dlopenext(0x7fff94d3d210, 0x1d02744, 0, 0xffffffff, 0x2525252525252525 <unfinished ...>
<... lt_dlopenext resumed> ) = 0x1d02af0
lt_dlsym(0x1d02af0, 0x7fff94d3d110, 0xfefeff646bff6d6e, 0x656d006e6f, 0xfefefefefefefeff) = 0x7f27c1f674e0
I hope this answers your questions.
Thanks,
Aurélien
Le 6 janv. 2011 à 14:44, Josip Rodin a écrit :
> On Thu, Jan 06, 2011 at 11:26:44AM +0100, Aurélien Geron wrote:
>> Hi and happy new year to everyone,
>>
>> In april I wrote the message below about python modules not being able to
>> load dynamic libraries on Debian Lenny.
>
>> I did not have time to test this ever since, but I just did, and
>> unfortunately, I still have the same problem on Debian Lenny, using the
>> latest FreeRADIUS backport for Lenny (it is based on FreeRADIUS 2.1.10,
>> the Debian package is labelled "2.1.10+dfsg-2~bpo50+1").
>>
>>> - running a perfectly standard Debian Lenny (2.6.26-2-amd64)
>>> - installed the latest freeradius package from the lenny-backports
>>> (2.1.8+dfsg-1~bpo50+1)
>
> Can you verify that your exact freeradius packages used now - do indeed link
> to libltdl7 and use the new code?
>
> Generic amd64 packages should be fine, but do check just in case...
>
> Perhaps also use ltrace to find the symbol lookup function used?
> You need to see some lt_dladvise_*() and/or lt_dlopenadvise() mentioned.
>
> (Assuming the cause for this is http://bugs.debian.org/416266 )
>
> --
> 2. That which causes joy or happiness.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list