#538 hardcoded sasl2 plugin path in ldaputil.c, saslbind.c
Closed: wontfix None Opened 11 years ago by tjaalton.

The files should probably use the libdir passed on to the configure script as the prefix, because on Debian & Ubuntu $libdir is /usr/lib/$gnu-triplet, so SASL doesn't work without hacks.


Could you provide a patch for this?

diff file to set gnu triplet in the sask2 library path.
diffs.txt

Please replace "s/sask2/sasl2/".

I don't have a host running Debian & Ubuntu handy.
Do you think the attached diff (diffs.txt) solves your problem?
Otherwise, could you provide us your patch?
Thanks!

I forgot that this bug exists.. Yes I can test that patch, but it only fixes it for x86*, while the package is built on all architectures on Debian, at least it would be nice to support arm too which is already invading the datacentres..

Replying to [comment:9 tjaalton]:

I forgot that this bug exists.. Yes I can test that patch, but it only fixes it for x86*, while the package is built on all architectures on Debian, at least it would be nice to support arm too which is already invading the datacentres..

Do you happen to have a patch including the architectures you are aware of? We are more than happy to support them!

Thank you so much for your help!

http://cdimage.debian.org/cdimage/weekly-builds/

has the list of currently supported archs (but not with 'official' gnu names). What's missing is arm64 which should be added at some point and released with Debian 8.0 maybe next year (more details on arm: https://wiki.debian.org/ArmPorts ) . So I guess it's more important to concentrate on armhf/arm64, although 389ds seems to have been built just fine on the others, more niche archs too.

also, 389-ds-base 1.3.1.9 is now in Ubuntu 'saucy' (which will become 13.10 next month), and includes the patch to fix this for i386/amd64. Yet to be tested..

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

seems to work

Bug description: The hardcoded sasl2 path is Fedora/RHEL specific.
It needs to support other architectures with other filesystem
format.

Fix description: This patch supports ARM architectures with GNU
triplet format.

Notes:
1) Although "uname -m" returns "armv7l", the target arch has to be "armv7hl".

2) Preprocessed ldaputil_get_saslpath code on armv7l:

{{{
char
ldaputil_get_saslpath()
{
char
saslpath = getenv("SASL_PATH");
if (((void *)0) == saslpath) {

1034 "ldap/servers/slapd/ldaputil.c"

    saslpath = "/usr/lib/sasl2";
    if (PR_SUCCESS != PR_Access(saslpath, PR_ACCESS_EXISTS)) {
        saslpath = "/usr/lib/arm-linux-gnueabihf";
        if (PR_SUCCESS != PR_Access(saslpath, PR_ACCESS_EXISTS)) {
            saslpath = "/usr/lib/arm-linux-gnueabi";
        }
    }
}

return saslpath;
}
}}}

Tested on Fedora 19. The sasl plugins are located in /usr/lib/sasl2 on Fedora, so the GNU triplet paths are not tested yet.

rpm -ql cyrus-sasl-gssapi

/usr/lib/sasl2/libgssapiv2.so
...

formatting looks a bit off in one place, otherwise, ack

tjaalton - does this patch work for you?

Reviewed by Rich (Thank you!!)

formatting looks a bit off in one place, otherwise, ack
A good catch! I fixed 2 places and pushed the new patch.

Pushed to master:
01df89d..4c1dfaf master -> master
commit 4c1dfaf

tjaalton, let me close this ticket with "fixed" once. I'm also setting "needinfo" flag. If possible, could you please try the patch on your system? If it works ok, please reset it to blank. If you see any problems, please reopen this ticket.
Thank you!!

The patch looks good, I'll add it to the package and test it soon. Thanks!

Metadata Update from @tjaalton:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.3 - 10/13 (October)

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/538

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata