On Fri, 19 Aug 2016, David Kowis wrote:
On 08/16/2016 10:51 PM, Alexander Bokovoy wrote:
On Tue, 16 Aug 2016, David Kowis wrote:
On 08/15/2016 09:27 PM, David Kowis wrote:
On 08/15/2016 08:05 PM, Rob Crittenden wrote:
David Kowis wrote:
On 08/15/2016 04:33 AM, Petr Spacek wrote:
This is weird as LDAP SASL & GSSAPI is pretty standard thing.

In any case, you can check server logs or use tcpdump/wireshark and
see if the
error somes from LDAP server or if it is client side error.

That would tell us where to focus.

I think I know what's going on, but not why it's going on:

This bug lead me to wonder where the directory server was finding it's
GSSAPI modules.

For some reason dirsrv is looking in /usr/lib/sasl2 for it's sasl
modules, when they're actually installed in /usr/lib/i386-linux-gnu/sasl2

A symlink:
ln -s /usr/lib/i386-linux-gnu/sasl2 /usr/lib/sasl2

and then suddenly:
ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GS2-IAKERB
supportedSASLMechanisms: GS2-KRB5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: ANONYMOUS

Should I file a new bug with ubuntu? Did I find some weird i386 only bug
that should've been fixed?
Please file a bug against CyrusSASL in Ubuntu because it is library's
duty to handle own modules -- while it provides sasl_set_path() to
application to define where to load modules from, the defaults should be
set reasonably. 389-ds does not use sasl_set_path().

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to