openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#4949) olcLogLevel not functioning as expected after conversion via '-f slapd.conf -F slapd.d'
by erici＠motown.cc.utexas.edu 04 May '07

04 May '07

Full_Name: Eric Irrgang Version: 2.3.35 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.93.52) When a slapd.conf file is converted to cn=config with -f and -F the loglevel parameter gets converted into multiple olcLogLevel=keyword attribute/value pairs. However, only the last one in the configuration seems to apply. Manually updating dn: cn=config changetype: modify replace: olcLogLevel olcLogLevel: keyword1 keyword2 ... - gets the intended logging behavior. Either the conversion should put all of the loglevel masks in the same olcLogLevel value or cn=config should AND all of the olcLogLevel values.

1 0

(ITS#4948) #if/#elif argument in .../include/ac/time.h
by lucio＠proxima.alt.za 04 May '07

04 May '07

Full_Name: Lucio De Re Version: 2.3.35 and earlier OS: Plan 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.255.250) The arguments on lines 20 and 23 (#if and #elif, respectively) in .../include/ac/time.h ought to be surrounded with "defined()". Whether the existing format is legitimate or not is a matter for the C standards, but I believe that the alternative would be both clearer and more portable. The Plan 9 C pre-processor has a definite issue with it and it seems a reasonable change to implement. There may be other places where a similar change would be beneficial, I'll identify them as I encountered and will provide a comprehensive list on demand. Naturally, there are many other issues applicable specific to porting OpenLDAP to Plan 9, but these seem trivial enough to warrant addressing in a broader context.

1 0

Re: (ITS#4947) monitor schema should appear under subschema entry
by quanah＠zimbra.com 04 May '07

04 May '07

--On Friday, May 04, 2007 2:39 PM +0000 ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > (enhancement, or minor) > > The monitor backend attributes and object classes, when loaded, should > also be exported in the subschema entries at the server. > > I know of one ldap client that breaks because of this: luma. It says it > can't display the cn=monitor entries because it doesn't know the object > classes or attributes. I guess it uses this info to determine how to show > each entry. Not disagreeing, but making the assumption that cn=subschema is readable is also a broken behavior on the luma side. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4947) monitor schema should appear under subschema entry
by ahasenack＠terra.com.br 04 May '07

04 May '07

Full_Name: Andreas Hasenack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) (enhancement, or minor) The monitor backend attributes and object classes, when loaded, should also be exported in the subschema entries at the server. I know of one ldap client that breaks because of this: luma. It says it can't display the cn=monitor entries because it doesn't know the object classes or attributes. I guess it uses this info to determine how to show each entry.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="hyc(a)symas.com"> > ahasenack(a)terra.com.br wrote: >> On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >>> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >>> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >>> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >>> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >>> symbol lookup error: >>> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >>> ldap_back_proxy_authz_ctrl >> >> Howard debugged this on IRC and it turns out that our (mine and >> _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd >> without the unixodbc lib fixes it. > > Yes, so there are two potential issues - the unixodbc shared library seems > to > be statically linked with an older version of libltdl. I didn't run into > this > problem on my build because I don't have that odbc library. Anyway, due to > the link order of the libraries, the lt_dlopen in this library gets used > before the linker resolves to the system's libltdl.so, and it seems that > this > version of lt_dlopen doesn't automatically export the symbols of modules > that > it loads. > > I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is > because there is a new dependency in 2.3.33 between back-meta and > back-ldap. > > The other part of this is that the slapd binary should not be getting > linked > against -lodbc when back_sql is built as a module. > > Although, if back-sql is built statically, and other backends are dynamic, > this problem may still crop up. It seems that fixing -lodbc would be > required > then. I've hit this same problem tonight (no sql though): ./scripts/test030-relay: line 78: kill: (7779) - No such process >>>>> ./scripts/test030-relay failed (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/suretec/src/openldap-2.3.35/tests' make: *** [test] Error 2 slapd.1.log: /home/suretec/src/openldap-2.3.35/servers/slapd/.libs/lt-slapd: symbol lookup error: ../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Config options were: env CC=/usr/local/bin/gcc CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -I/usr/local/include/sasl" \ LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/local/lib/sasl2" \ LIBS="-ldl" \ LD_LIBRARY_PATH="/usr/local/ssl/lib /usr/local/BerkeleyDB.4.2/lib /usr/local/lib/sasl2" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog \ --enable-dynamic --enable-rewrite --disable-sql --disable-ipv6 --disable-shell \ --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers On Debian Sarge 3.1 with custom compiled: openssl-0.9.8e cyrus-sasl-2.1.22 db-4.2.52 heimdal-0.8.1 I can't get past it. Any debug advice? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#4945) slapd drops connections during search results
by mhardin＠symas.com 03 May '07

03 May '07

Full_Name: Matthew Hardin Version: 2.3.35 OS: Windows 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.67.85) If Winsock returns EWOULDBLOCK while sending search results to a client, slapd will stop sending results and close the connection. The problem is in openldap/servers/slapd/result.c at line 173, where it incorrectly checks errno. It should be checking sock_errno(). I note that HEAD already does this.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

Looks like your OpenSSL library depends on -ldl. That's an OpenSSL build problem, not OpenLDAP. Can probably get around it by adding -ldl to LIBS on the configure invocation. This ITS will be closed. ghenry(a)suretecsystems.com wrote: > <quote who="Howard Chu"> >> It works for me. Check your config.log to see why it didn't link. > > Here's the main probs: > > configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include > -I/usr/local/BerkeleyDB.4.2/include conftest.c > configure:19507: $? = 0 > configure:19527: result: yes > configure:19562: checking for openssl/ssl.h > configure:19569: result: yes > configure:19584: checking for SSL_library_init in -lssl > configure:19614: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lresolv >&5 > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function > `dlfcn_bind_func': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function > `dlfcn_bind_func': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function > `dlfcn_bind_var': > : undefined reference to `dlsym' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function > `dlfcn_bind_var': > : undefined reference to `dlerror' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function > `dlfcn_unload': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function > `dlfcn_load': > : undefined reference to `dlopen' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function > `dlfcn_load': > : undefined reference to `dlclose' > /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function > `dlfcn_load': > : undefined reference to `dlerror' > collect2: ld returned 1 exit status > configure:19620: $? = 1 > configure: failed program was: > | /* confdefs.h. * > > | char SSL_library_init (); > | int > | main () > | { > | SSL_library_init (); > | ; > | return 0; > | } > configure:19646: result: no > configure:19657: checking for ssl3_accept in -lssl > configure:19687: /usr/local/bin/gcc -o conftest -g -O2 > -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include > -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl > -lcrypto -lRSAglue -lrsaref -lresolv >&5 > /usr/bin/ld: cannot find -lRSAglue > collect2: ld returned 1 exit status > configure:19693: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > > > Like I said, this didn't happen in 0.9.7, will check my built options with > 0.9.8 > > Gavin. > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

<quote who="Howard Chu"> > It works for me. Check your config.log to see why it didn't link. Here's the main probs: configure:19501: /usr/local/bin/gcc -E -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include conftest.c configure:19507: $? = 0 configure:19527: result: yes configure:19562: checking for openssl/ssl.h configure:19569: result: yes configure:19584: checking for SSL_library_init in -lssl configure:19614: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lresolv >&5 /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x2ae): In function `dlfcn_bind_func': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x333): In function `dlfcn_bind_func': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x3ae): In function `dlfcn_bind_var': : undefined reference to `dlsym' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x431): In function `dlfcn_bind_var': : undefined reference to `dlerror' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x497): In function `dlfcn_unload': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x557): In function `dlfcn_load': : undefined reference to `dlopen' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5b5): In function `dlfcn_load': : undefined reference to `dlclose' /usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o)(.text+0x5ec): In function `dlfcn_load': : undefined reference to `dlerror' collect2: ld returned 1 exit status configure:19620: $? = 1 configure: failed program was: | /* confdefs.h. * | char SSL_library_init (); | int | main () | { | SSL_library_init (); | ; | return 0; | } configure:19646: result: no configure:19657: checking for ssl3_accept in -lssl configure:19687: /usr/local/bin/gcc -o conftest -g -O2 -I/usr/local/ssl/include -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib conftest.c -lssl -lcrypto -lRSAglue -lrsaref -lresolv >&5 /usr/bin/ld: cannot find -lRSAglue collect2: ld returned 1 exit status configure:19693: $? = 1 configure: failed program was: | /* confdefs.h. */ Like I said, this didn't happen in 0.9.7, will check my built options with 0.9.8 Gavin.

1 0

Re: (ITS#4944) 2.3.35 and openssl-0.9.8e
by hyc＠symas.com 03 May '07

03 May '07

It works for me. Check your config.log to see why it didn't link. ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, > only latest 0.9.7m: > > env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ > LDFLAGS="-L/usr/local/ssl/lib" \ > LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ > --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ > --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ > --disable-sql --with-threads --enable-modules --enable-backends=mod \ > --enable-overlays=mod --with-tls --enable-wrappers > > checking openssl/ssl.h usability... yes > checking openssl/ssl.h presence... yes > checking for openssl/ssl.h... yes > checking for SSL_library_init in -lssl... no > checking for ssl3_accept in -lssl... no > checking OpenSSL library version (CRL checking capability)... yes > configure: error: Could not locate TLS/SSL package > > > You probably already know ;-) > > Gavin. > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4944) 2.3.35 and openssl-0.9.8e
by ghenry＠suretecsystems.com 03 May '07

03 May '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Just a heads up to say I couldn't get 2.3.35 to compile with openssl 0.9.8e, only latest 0.9.7m: env CC=gcc CPPFLAGS="-I/usr/local/ssl/include" \ LDFLAGS="-L/usr/local/ssl/lib" \ LD_LIBRARY_PATH="/usr/local/ssl/lib" ./configure \ --prefix=/usr/local --enable-slapd --enable-syslog --with-cyrus-sasl=yes \ --enable-dynamic --enable-rewrite --disable-ipv6 --disable-shell \ --disable-sql --with-threads --enable-modules --enable-backends=mod \ --enable-overlays=mod --with-tls --enable-wrappers checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no checking OpenSSL library version (CRL checking capability)... yes configure: error: Could not locate TLS/SSL package You probably already know ;-) Gavin.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs