[syslog-ng] load failures in afsocket and afsql

[Balazs Scheidler]

Hi,

This is a rather long message, not only from a single person. But I'll
try to answer inline and give a summary at the end, to start sorting
things out.

On Tue, 2010-12-14 at 16:34 -0600, Martin Holste wrote:
> I do recall that spoof-source would not work on SLES 10--I had to
> upgrade to SLES 11.2 in order to get the non-broken libnet.

I think that was an unrelated problem. In that case syslog-ng could be
built, but the checksum of packets were not correctly calculated.

> On Tue, Dec 14, 2010 at 4:18 PM, Matthew Hall <mhall at mhcomputing.net> wrote:
> > megahall at logproxy2:~$ readelf -d /home/y/lib64/syslog-ng/libafsocket.so
> >
> > Dynamic section at offset 0x19978 contains 29 entries:
> >  Tag        Type                         Name/Value
> >  0x0000000000000001 (NEEDED)             Shared library: [libsyslog-ng.so.0]
> >  0x0000000000000001 (NEEDED)             Shared library: [libssl.so.108]
> >  0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.108]
> >  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
> >  0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
> >  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
> >  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
> >  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
> >  0x000000000000000e (SONAME)             Library soname: [libafsocket-tls.so]
> >  0x000000000000000f (RPATH)              Library rpath: [/home/y/lib64:/usr/lib64]
> >  ...
> >
> > It looks to me like libafsocket itself is built broken because it does
> > not declare its libnet dependency that it picks up when spoof source is
> > enabled.

Hmm.. this is strange. In my build of syslog-ng, libafsocket.so is
linked against libnet (and I also build into a private prefix):

 0x0000000000000001 (NEEDED)             Shared library: [libsyslog-ng.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.0.9.8]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.0.9.8]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libnet.so.1]            <---
 0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

the thing that determines whether afsocket is linked against libnet or not is LIBNET_LIBS 
variable as detected by the configure script.

You can check your config.status script to see your value, mine has this:

$ grep LIBNET_LIBS config.status 
S["LIBNET_LIBS"]="-lnet"

This is pasted into the libafsocket.so linker command line, in 
modules/afsocket/Makefile.am


> >
> > Matthew.

> >> > According to the glib API:
> >> >
> >> > First of all g_module_open() tries to open file_name as a module. If that
> >> > fails and file_name has the ".la"-suffix (and is a libtool archive) it tries
> >> > to open the corresponding module. If that fails and it doesn't have the
> >> > proper module suffix for the platform (G_MODULE_SUFFIX), this suffix will be
> >> > appended and the corresponding module will be opended. If that fails and
> >> > file_name doesn't have the ".la"-suffix, this suffix is appended and
> >> > g_module_open() tries to open the corresponding module. If eventually that
> >> > fails as well, NULL is returned.
> >> >
> >> > So in order for 210 to get executed to write the message, g_module_open must
> >> > have had NULL retval.
> >> >
> >> > As above, this could happen when:
> >> >
> >> > opening as a module fails
> >> > opening as a module.la fails
> >> > opening as a module.platform_suffix fails
> >> > opening as a module.platform_suffix.la fails
> >> >
> >> > The error returned from g_module_error gets output as:
> >> >
> >> > /home/y/lib64/syslog-ng/libafsocket.so: undefined symbol: libnet_build_ipv4
> >> > /home/y/lib64/syslog-ng/libafsql.so: undefined symbol: dbi_result_free
> >> >
> >> > Wondering what to try now to debug it further.

The glib .la parser peek out 3 values from the .la file:

installed
dlname
libdir

these are used to locate the .so file and the dependency loading is not
affected. (those are performed by the dynamic linker).

> >> >
> >> > Matthew.
> >> >
> >> > On Tue, Dec 14, 2010 at 11:18:37AM -0800, Matthew Hall wrote:
> >> >> Hello,
> >> >>
> >> >> I'm aware of rpath overall but not an expert at its usage as I have not
> >> >> needed it for previous environments I've used. I have been using:
> >> >>
> >> >> export CFLAGS="-I /home/y/include"
> >> >> export LDFLAGS="-Wl,-rpath,/home/y/lib64"
> >> >>
> >> >> and my libs are:
> >> >>
> >> >> /home/y/lib64/libnet.so.1.5.0:      ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped
> >> >> /home/y/lib64/libdbi.so.1.0.0:      ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
> >> >> /home/y/lib64/dbd/libdbdmysql.so:   ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
> >> >> /home/y/lib64/dbd/libdbdsqlite3.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
> >> >>
> >> >> with all the usual symlinks.
> >> >>
> >> >> The readelf shows the rpath is as follows on each:
> >> >>
> >> >> Library rpath: [/home/y/lib64]
> >> >>
> >> >> Strace seems to show that the libnet and libdbi don't get opened
> >> >> (whether I follow parent or child syslog-ng).
> >> >>
> >> >> What could I try next? My thought was perhaps GDB but that will get very
> >> >> messy very quickly. :-(

The root cause seems to be that your afsocket.so is not linked against
libnet.so

It'd be wise to check out the link command line and the LIBNET_LIBS
value suggested above.

-- 
Bazsi