New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
389-ds-base does not compile against MozLDAP libraries #847
Comments
Comment from rmeggins (@richm) at 2013-09-13 21:34:50 Replying to [ticket:47510 mvocu]:
The fix is to define this in slapi-plugin.h. There are many of these near the top of that file.
Is mozldap included with Debian? |
Comment from mvocu at 2013-09-13 21:47:45 No, MozLDAP is not included with Debian. After adding the #define LDAP_CANCELLED 0x76, the compilation ends with: ldap/servers/slapd/daemon.c: In function 'handle_closed_connection': |
Comment from mvocu at 2013-09-13 21:53:21 The reason I am trying to use MozLDAP instead of OpenLDAP is that Debian's OpenLDAP is linked against GnuTLS, not OpenSSL (and certainly not Mozilla NSS). I can compile, link and run the slapd against the Debian's OpenLDAP libraries (with 389-ds using Mozilla NSS), but I experience strange connection errors in passthru plugin when connecting to the (already deployed) configuration server. I attribute these errors to the TLS layer, as passthru plugin is using the underlying GnuTLS library, but I was not able to find the real cause. |
Comment from mvocu at 2013-09-13 22:05:50 And yes - after applying the obvious workarounds (basically hiding everything that does not compile in #ifdef USE_OPENLDAP ... #endif), the resulting ns-slapd works, including the passthru to config server (no change in configuration needed). |
Comment from rmeggins (@richm) at 2013-09-13 22:18:47 Replying to [comment:2 mvocu]:
Hmm, this is going to be a problem for every Debian/Ubuntu user. We (the 389 team) really need to figure out how to handle platforms that don't have openldap that supports moznss (and ldif - older versions of openldap did not have support for libldif). I really want to be able to build 389 with whatever openldap is provided by the OS. This means that we will have to change 389 so that it does not assume openldap is using NSS. This will take a good bit of work.
add #if defined(USE_OPENLDAP) and #endif around the
same thing - add a #if defined(USE_OPENLDAP) and #ifdef block around this |
Comment from rmeggins (@richm) at 2013-09-13 22:19:25 Replying to [comment:4 mvocu]:
Ok, that's good to know. Can you attach your patches to this ticket? |
Comment from mvocu at 2013-09-13 22:30:33 patch to enable compilation with mozilla ldap sdk |
Comment from mvocu at 2013-09-13 22:47:54 Patch attached. Maybe supporting openldap with different ssl would not be that much work; I was not able to figure out what was the real problem in my case. Maybe there was missing some configuration of openldap/gnutls (cacertdir comes to my mind, supported cipher suites, ...) that was not propagated from the slapd configuration. The server side of SSL was working fine with NSS, the problem was in client side (passthru, have not tried replication though). In any case, the ability to turn on debugging of the ldap library would have been of great help, eg. something like ldap_set_option(..., LDAP_OPT_DEBUG_LEVEL, ...) |
Comment from mreynolds (@mreynolds389) at 2013-09-27 19:22:57 attachment |
Comment from mreynolds (@mreynolds389) at 2013-09-27 19:23:28 Thanks mvocu for the patch! Sending out for review... |
Comment from mreynolds (@mreynolds389) at 2013-09-27 19:34:57 git merge mozldap git push origin master commit 069657f [mareynol@localhost ds]$ git checkout 389-ds-base-1.3.1 git cherry-pick -x master git push origin 389-ds-base-1.3.1 |
Comment from rmeggins (@richm) at 2013-09-27 22:16:28
Isn't it just FILE * - no struct? as in
If so, then you'll also have to use fopen()/fclose() instead of PR_Open/PR_Close |
Comment from mreynolds (@mreynolds389) at 2013-09-28 01:42:45 Replying to [comment:15 richm]:
I get other warnings/errors when I try changing this around. I just casted ldif_fd_in to (FILE *). New patch attached... |
Comment from rmeggins (@richm) at 2013-09-28 01:52:29 Here is the declaration from /usr/include/mozldap/ldif.h
What warnings/errors do you get? |
Comment from mreynolds (@mreynolds389) at 2013-09-28 02:07:00 Revision 2 |
Comment from mreynolds (@mreynolds389) at 2013-09-28 02:09:41 Replying to [comment:17 richm]:
Err, I think I read the one warning from the wrong workspace, and thought something else was going on. FILE works fine, new patch attached. |
Comment from mreynolds (@mreynolds389) at 2013-09-28 05:03:33 git merge ticket47510 git push origin master commit 820b448 1.3.1 git push origin 389-ds-base-1.3.1 commit a1ab932 |
Comment from mreynolds (@mreynolds389) at 2013-09-28 06:53:02 git merge ticket47510 git push origin master git checkout 389-ds-base-1.3.1 git push origin 389-ds-base-1.3.1 |
Comment from mreynolds (@mreynolds389) at 2013-10-04 01:10:26 Ported all the changes to 1.2.11(for EPEL 5) git merge mozldap git push origin 389-ds-base-1.2.11 commit 847150a |
Comment from mreynolds (@mreynolds389) at 2013-10-04 01:39:29 attachment |
Comment from mreynolds (@mreynolds389) at 2013-10-04 01:40:23 Found/fixed more Repl Sync failures: git merge mozldap git push origin master commit 8516b55 |
Comment from mvocu at 2017-02-11 22:57:57 Metadata Update from @mvocu:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/47510
The 389-ds-base package does not compile when instructed to use Mozilla LDAP SDK rather then OpenSSL. The resulting error is:
ldap/servers/slapd/opshared.c: In function 'op_shared_search':
ldap/servers/slapd/opshared.c:469:16: error: 'LDAP_CANCELLED' undeclared (first use in this function)
ldap/servers/slapd/opshared.c:469:16: note: each undeclared identifier is reported only once for each function it appears in
It seems that LDAP_CANCELLED constant is OpenLDAP specific (ldap.h: #define LDAP_CANCELLED 0x76), Mozilla LDAP does not define it.
I am trying to compile 389-ds-base-1.3.1.8 (but the error is present at least since 1.3.1.0) on Debian 7.1 with mozldap-6.0.7.
The text was updated successfully, but these errors were encountered: