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]:
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) {
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.
/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
git patch file (master) -- revised 0001-Ticket-538-hardcoded-sasl2-plugin-path-in-ldaputil.c.patch
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.