openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

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

RE: (ITS#4934) Port change
by Babu.Suresh＠pacificlife.com 02 May '07

02 May '07

Thank you..this was resolved after I implemented ACL in slapd.conf. _babu -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Wednesday, May 02, 2007 9:20 AM To: Suresh, Babu; openldap-its(a)openldap.org Subject: Re: (ITS#4934) Port change --On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration ------------------------------------------------------------------------------ The information in this e-mail and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information. If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited. If you believe that you have received this e-mail in error, please contact the sender immediately and delete the e-mail and all of its attachments. ==============================================================================

1 0

Re: (ITS#4934) Port change
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 21, 2007 12:03:23 AM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.8.254) > > > My openldap was running on default port 389 and imported all schema & > data. Now I would like to change the port to different..would be > 4000/5000. OpenLDAP process started successfully with non default port > but I am getting "error 32 no such object" when try to browse the data > using soferra. > > is it possible to change the port anytime? Yes. It sounds like perhaps softerra has a bug. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4930) slaptest should be quiet on success
by quanah＠zimbra.com 02 May '07

02 May '07

--On April 18, 2007 9:42:20 AM +0000 jsafranek(a)redhat.com wrote: > Full_Name: Jan Safranek > Version: 2.3.35 > OS: Linux (Fedora 6) > URL: > Submission from: (NULL) (62.40.79.66) > > > The 'slaptest' tool is a bit verbose, it sends 'config file testing > succeeded' to stderr. IMHO it should do not output anything, especially > to stderr, if everything is all right. > > Here is a small patch, causing the slaptest to display the aforementioned > message only if -v switch is used: > > Index: servers/slapd/slaptest.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/slaptest.c,v > retrieving revision 1.9 > diff -r1.9 slaptest.c > 107c107,108 > < fprintf( stderr, "config file testing succeeded\n"); > --- >> if (verbose) >> fprintf( stderr, "config file testing succeeded\n"); The point of slaptest is to tell users whether or not things are okay. Having slaptest exit with nothing displayed somewhat defeats that purpose... --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 02 May '07

02 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard As far as I can tell from tpool.c, ldap_pvt_thread_pool_destroy() will act prematurely if another thread pauses: ldap_pvt_thread_pool_destroy (...) { ... if ( pool->ltp_open_count ) { ldap_pvt_thread_cond_broadcast(&pool->ltp_cond); ldap_pvt_thread_cond_wait(&pool->ltp_cond, &pool->ltp_mutex); } ... since ldap_pvt_thread_pool_resume() broadcasts on the same mutex. Also ldap_pvt_thread_pool_resume() will reset ltp_state to RUNNING instead of FINISHING/STOPPING. If that can happen, the fix would be: (a) use while() instead of if(), (b) keep an ltp_unpaused_state along with ltp_pause which is _pause does not change and _resume copies to ltp_state, or just remove LDAP_INT_THREAD_POOL_PAUSING in favor of an ltp_pausing flag. (And possibly some code which currently checks ltp_state ought to check ltp_unpaused_state instead, I'm not sure.) (c) if _destroy() can be called while LDAP_INT_THREAD_POOL_PAUSING, I think the other if()s around ltp_cond need to be while() too.

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