openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Can't compile OpenLDAP with Berkekey DB: File format not recognized
by ben＠fallinganvils.com 06 Dec '07

06 Dec '07

This is my first openldap install. I am installing by compiling from source on a debian box logged in as myself in my home directory. Berkeley DB is not installed systemwide. LDAP libraries are installed systemwide, but I want to install the whole openldap tarball in my home directory and use that/run an ldap server etc. Only libraries are installed systemwide. No ldap server software is installed systemwide. I do have root access, but I don't think I should need it. If I can get it installed under /home/ben, after some experimentation, I'll install it in /home/openldap after creating an openldap user. I don't know what the debian system uses the ldap libraries it came with for, but I should be able to use my own local version without dealing with that I would think. This is what I do : 1) Install Berkeley DB 4.6.21 in /home/ben/opt/bdb $ cd db-4.6.21/build_unix $ ../dist/configure --prefix=/home/ben/opt/bdb $ make && make install $ export LD_RUN_PATH=/home/ben/opt/bdb/lib $ export CPPFLAGS='-I /home/ben/opt/bdb/include' $ export LDFLAGS='-L /home/ben/opt/bdb/lib' $ cd 2) Install OpenLDAP $ cd openldap-2.4.6 $ ./configure --prefix=/home/ben/opt/openldap $ make depend $ make Making all in /home/ben/src/openldap/openldap-2.4.6 Entering subdirectory include make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/include' Entering subdirectory libraries make[1]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries' Making all in /home/ben/src/openldap/openldap-2.4.6/libraries Entering subdirectory liblutil make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' /bin/sh ../..//libtool --mode=link cc -static -g -O2 -L /home/ben/opt/bdb/lib -o dtest dtest.o liblber.la ../../libraries/liblutil/liblutil.a -lresolv cc -g -O2 /home/ben/opt/bdb/lib -o dtest dtest.o -L/home/ben/src/openldap/openldap-2.4.6/libraries/liblber ./.libs/liblber.a ../../libraries/liblutil/liblutil.a -lresolv /usr/bin/ld: /home/ben/opt/bdb/lib: No such file: File format not recognized collect2: ld returned 1 exit status make[2]: *** [dtest] Error 1 make[2]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries/liblber' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/ben/src/openldap/openldap-2.4.6/libraries' make: *** [all-common] Error 1 3) Let's investigate: $ ls /home/ben/opt/bdb bin docs include lib $ ls -l /home/ben/opt/bdb/lib -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb-4.6.a -rw-r--r-- 1 ben ben 813 Nov 28 21:44 libdb-4.6.la -rwxr-xr-x 1 ben ben 1248813 Nov 28 21:44 libdb-4.6.so lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb-4.so -> libdb-4.6.so -rw-r--r-- 1 ben ben 1571838 Nov 28 21:44 libdb.a lrwxrwxrwx 1 ben ben 12 Nov 28 21:44 libdb.so -> libdb-4.6.so $ vi libdb-4.6.a The first bit looks like: !<arch> / 1196286289 0 0 0 27970 ` ^@^@^E0^@^@m\xea^@^@m\xea^@^@m\xea^@^@m\xea^@^@u"^@^@ Not sure what that means, but someone might... $ vi libdb-4.so The first bit looks like: ^?ELF^A^A^A^@^@^@^@^@^@^@^@^@^C^@^C^@^A^@^@^@\xf0i^A^@4^@^@^@x\xde^Q^@^@^@^@^@4^ @ ^@^D^@(^@^_^@^\^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@\xe8\x85^Q^@\xe8 Hey! more nonsense, but ELF is familiar and seems like a plausable for a linux library... I also get this error with openldap-2.3.39 and db-4.5.20 I could not use openldap-2.3.39 with db-4.6.21 because I get incompatible version. The configure scripts looks for db versions 4.2 though 4.5 and spits out that error otherwise. Anyway, thanks for any help.

2 1

(ITS#5266) "authorization failure: invalid authcid" during SASL auto_transition
by dwhite＠olp.net 06 Dec '07

06 Dec '07

Full_Name: Dan White Version: 2.3.39 OS: Linux URL: http://support.olp.net/ldap/log2.txt Submission from: (NULL) (65.161.252.42) If I enable SASL auto_transition, I receive the following error during authentication: SASL(-14): authorization failure: invalid authcid I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch). I'm using the bdb backend. I'm also using Debian Etch with the following versions of software: Cyrus SASL 2.1.22(.dfsg1-8) libdb 4.2.52(+dfsg-2) libc6 2.3.6(.ds1-13etch2) PAM 0.79(-4) pam_ldap 184(-2) I'm using saslauthd's PAM backend, and in turn using pam_ldap for authentication, although I don't believe the problem is related to the saslauthd/pam configuration. Here's the client side output from the attempted bind: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: ldap_sasl_interactive_bind_s: Insufficient access (50) additional info: SASL(-14): authorization failure: invalid authcid If I turn off auto_transition, it works: hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a SASL/PLAIN authentication started Please enter your password: SASL username: abrown(a)olp.net SASL SSF: 0 hiro:~# My slapd.conf SASL service file looks like: hiro:~# cat /usr/lib/sasl2/slapd.conf keytab: /etc/krb5.keytab-ldap pwcheck_method: saslauthd auxprop_plugin: slapd auto_transition: yes log_level: 7 And the server log (loglevel -1) is located at: http://support.olp.net/ldap/log2.txt The error appears to be occurring while transitioning the password to the auxprop store, in the slap_sasl_authorize function: /* Skip SLAP_SASL_PROP_CONN */ prop_getnames( props, slap_propnames+1, auxvals ); /* Should not happen */ if ( !auxvals[0].values ) { sasl_seterror( sconn, 0, "invalid authcid" ); return SASL_NOAUTHZ; } What I'm expecting to happen during the bind, is to have SASL overwrite my userPassword and cmusaslsecretOTP attributes, via the slapd auxprop plugin. I have a lot of passwords in crypted form (which PAM authenticates), and I'm aiming towards a clear-text password store by using this functionality.

1 0

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

hyc(a)symas.com writes: > As I recall, the only reason we needed the waking counter here was to > make sure we never filled the pipe buffer, which would cause a > single-threaded server to deadlock. We can simply set the pipe to > nonblocking instead, and eliminate the counter. Sounds good... > The other point was that if there was already a pending wake event, > there was no reason to write another one. Aha! Now the code makes more sense to me:-) And if 'waking' is just a boolean flag, we can keep it as long as it is treated that way. #define WAKE_LISTENER(w) do { \ if ((w) && !waking) { \ waking = 1; \ tcp_write( SLAP_FD2SOCK(wake_sds[1]), "0", 1 ); \ } \ } while (0) I need to stare at it a bit to look for race conditions with readers. I don't suggest to hold next RE24 for this though. It's hardly urgent, and should be tested a bit --without-threads first. -- Regards, Hallvard

1 0

(ITS#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/test004bug.tbz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test004-modify" gets noSuchObject when it attempts to delete "cn=James A Jones 2,ou=Information Technology Division, ou=People,dc=example,dc=com". The tests do not fully support back-ldif, but I don't see why this one should fail. The entry is present as testrun/db.1.a/dc=example,dc=com/ou=people/ou=information technology division/cn=james a jones 2.ldif. tests$ ./run -b ldif test004-modify Cleaning up test run directory leftover from previous run. Running ./scripts/test004-modify... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing slapd modify operations... Testing modify, add, and delete... ldapmodify failed (32)! tests$ grep '^conn=' testrun/slapd.1.log | tail -n6 conn=1 op=6 do_delete conn=1 op=6 DEL dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" conn=1 op=6 RESULT tag=107 err=32 text= conn=1 op=7 do_unbind conn=1 op=7 UNBIND conn=1 fd=8 closed

1 0

Re: (ITS#5248) non-atomic signal variables
by hyc＠symas.com 06 Dec '07

06 Dec '07

h.b.furuseth(a)usit.uio.no wrote: > Fixed the easy cases in HEAD. > WAKE_LISTENER under --without-threads remains. > As I recall, the only reason we needed the waking counter here was to make sure we never filled the pipe buffer, which would cause a single-threaded server to deadlock. We can simply set the pipe to nonblocking instead, and eliminate the counter. The other point was that if there was already a pending wake event, there was no reason to write another one. -- -- 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#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Fixed the easy cases in HEAD. WAKE_LISTENER under --without-threads remains. -- Hallvard

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 06 Dec '07

06 Dec '07

This stack trace looks a little funny, but I think this should be fixed now in HEAD. Andrew Bartlett wrote: > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) thread apply all bt > > Thread 6 (Thread 1082132816 (LWP 26448)): > #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 > #1 0x000000000042af5a in ?? () > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 5 (Thread 1090525520 (LWP 26453)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1098918224 (LWP 26455)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so > #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so > #6 0x00000000004c545f in hdb_cache_entry_db_relock () > #7 0x00000000004c5c00 in hdb_cache_modify () > #8 0x00000000004a03bd in hdb_modify () > #9 0x0000000000500036 in ?? () > #10 0x0000000000500382 in ?? () > #11 0x000000000043bd15 in ?? () > #12 0x000000000043e52f in ?? () > #13 0x000000000043f158 in slap_send_ldap_result () > #14 0x00000000004c314d in hdb_add () > #15 0x00000000004888d2 in overlay_op_walk () > #16 0x0000000000488dd5 in ?? () > #17 0x00000000004343d7 in fe_op_add () > #18 0x0000000000434bdc in do_add () > #19 0x000000000042dd86 in ?? () > #20 0x000000000042e21d in ?? () > #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > ---Type <return> to continue, or q <return> to quit--- > #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1107310928 (LWP 26456)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1115703632 (LWP 26457)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so > #5 0x00000000004c52c4 in ?? () > #6 0x00000000004c6a89 in hdb_cache_find_id () > #7 0x00000000004c9f99 in hdb_dn2entry () > #8 0x00000000004a3cd0 in hdb_referrals () > #9 0x00000000004888d2 in overlay_op_walk () > #10 0x0000000000488dd5 in ?? () > #11 0x0000000000438f90 in backend_check_referrals () > #12 0x000000000043427b in fe_op_add () > #13 0x0000000000434bdc in do_add () > #14 0x000000000042dd86 in ?? () > #15 0x000000000042e21d in ?? () > #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 46912500832560 (LWP 26443)): > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > #1 0x0000000000428ca2 in slapd_daemon () > #2 0x0000000000418519 in main () > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) > > -- -- 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#5258) memberof-Overlay issue when deleting all values of the "memberof-member-ad" attribute
by ando＠sys-net.it 06 Dec '07

06 Dec '07

rhafer(a)suse.de wrote: Found it. A fix will follow, perhaps not too shortly. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5262) test008 failures
by hyc＠symas.com 06 Dec '07

06 Dec '07

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: >> hyc(a)OpenLDAP.org wrote: >>> Full_Name: Howard Chu >>> Version: HEAD/RE24/RE23 >>> OS: Linux > I take this back; it wasn't recompiled yet. The current code in HEAD has > passed over 100 iterations. I'll leave it running overnight. This is now fixed in HEAD/RE24. I suppose it ought to be fixed in RE23 as well if we're going to do another 2.3 release. -- -- 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#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org 06 Dec '07

06 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > The comparison fails after the first modify step, an entry that should have been > deleted is still present on the slave. > > The presentlist is still left over from the initial query, and hasn't been > emptied yet. This appears to be a missing step when the initial query > transitions from Refresh to Persist mode. This broke after patching ITS#5210. That means the corresponding fix needs to go into RE23 as well, and any syncrepl.c without this patch will not work with newer syncprov. -- -- 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

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