help appreciated for radium+sasl configuration

[maketsi]

2013/8/14 Jesse Bowling <jessebowling at gmail.com>

> Try setting RA_MIN_SSF=40 on the client config. I'd also try ensuring you
> do a 'make clean' and then recompile clients and servers to ensure you got
> the SASL code in. If resetting the RA-MIN_SSF works, let us know; that's
> worry documenting...
>

Hi,

I tested that too for completeness. As you should know, that does not
affect anything for two reasons: server does not seem to return any auth
methods to choose from in the first place, and second, client basically
should automatically select whatever is needed to comply with the server
minimum if it's below the client's max.

But this is now fixed!
As the server didn't return any auth methods, I started investigating it
further with gdb (stepping code and poking vars) and googling around. As
the site is quite busy and I was running the radium instance in foreground
mode with debug logs, I didn't notice that radium actually generated some
syslog entries too, revealing immediately what's the real problem:
Aug 15 09:06:13 host radium: unable to dlopen /usr/lib/sasl2/libplain.so.2:
/usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32

Yum in CentOS installs both 32bit and 64bit versions, unless yum is
explicitly hackishly configured to exclude 32bit packages. 32bit version is
put in /usr/lib/sasl2 and 64bit version in /usr/lib64/sasl2. Argus is
staticly pointed to 32bit location in the code:
common/argus_output.c:#define PLUGINDIR "/usr/lib/sasl2"

I replaced the libs with 64bit versions and now things are flowing
correctly:
radium[25595.40096b67c12a0000]: 10:03:49.684243
ArgusSendSaslString(0x2608800, 0x25f6b20, 12) {DIGEST-MD5}

I don't know if that could be detected somehow in the argus code, but it
would be easy to test out by replacing sasl libs with non-working files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130815/7a5dcc6b/attachment.html>