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
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
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
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