openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

Re: (ITS#5696) Patch - support Mozilla NSS for crypto operations
by rmeggins＠redhat.com 10 Mar '09

10 Mar '09

Kurt(a)OpenLDAP.org wrote: > On Feb 25, 2009, at 1:42 AM, hyc(a)symas.com wrote: > > >> The -compat code is LGPL. I'm considering copying the ciphersuite >> handling and >> a few other pieces out of there, directly into our tree. There's a >> lot of >> other baggage in the compat library we don't need, and there's some >> OpenSSL >> emulation that would interfere with the NSS code we already have. >> Any problem >> with excerpting the bits we need? >> > > I would need to take a very careful look at this. In general, the > answer is "NO", don't bring in LGPL code into our primary code base > (standalone LGPL in contrib is another matter). > The license change to the nss_compat_ossl package has been committed - http://svn.fedorahosted.org/svn/identity/common/trunk/nss_compat_ossl/ > -- Kurt > > > > >

1 0

(ITS#6013) test045 failing
by ghenry＠OpenLDAP.org 10 Mar '09

10 Mar '09

Full_Name: Gavin Henry Version: RE_2_4 OS: Fedora 10 i386 URL: ftp://ftp.openldap.org/incoming/test045-syncreplication-proxied-10.03.09.ta… Submission from: (NULL) (212.159.59.85) Submitted by: ghenry ./run test045 Cleaning up test run directory leftover from previous run. Running ./scripts/test045-syncreplication-proxied... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Starting proxy slapd on TCP/IP port 9013... Using ldapsearch to check that proxy slapd is running... 1 > Using ldapadd to populate the master directory... 1 < Comparing retrieved entries from master and slave... 2 > Stopping the provider, sleeping 15 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... Waiting 7 seconds for syncrepl to receive changes... 2 < Comparing retrieved entries from master and slave... test failed - master and slave databases differ testrun attached. Thanks, Gavin.

1 0

(ITS#6005)
by rupreht-mobi2＠olympus.ru 10 Mar '09

10 Mar '09

%ldapsearch -x -w xxxxxxx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" Ok %ldapsearch -Wx -h mail -b "ou=transport,dc=test,dc=ru" -D "cn=replic,dc=test,dc=ru" Enter LDAP Password: # extended LDIF # # LDAPv3 ..... # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 Segmentation fault

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by hyc＠symas.com 09 Mar '09

09 Mar '09

martin.konold(a)erfrakon.de wrote: > Full_Name: Martin Konold > Version: 2.4.15 > OS: Linux > URL: http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch > Submission from: (NULL) (91.46.180.44) > > > Previous versions of OpenLDAP could show a sig11 when doing slapcat (using bdb > backend). > > The version 2.4.15 improved in this respect already though doing a slapcat with > an emtpy db still results in a segmentation fault. > > The following small patch by andreas.mack at erfrakon.de resolves this issue > > http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch > > The patch is used by the Kolab Project in productive installations What exactly do you mean by an empty db? I see: >>> ada:~/OD/o24/tests> rm testrun/db.1.a/* ada:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf bdb_db_open: warning - no DB_CONFIG file found in directory /home/hyc/OD/o24/tests/testrun/db.1.a: (2). Expect poor performance for suffix "dc=example,dc=com". bdb_db_open: database "dc=example,dc=com": db_open(/home/hyc/OD/o24/tests/testrun/db.1.a/id2entry.bdb) failed: No such file or directory (2). backend_startup_one: bi_db_open failed! (2) slap_startup failed ada:~/OD/o24/tests> <<< Please provide steps to reproduce the segfault, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 09 Mar '09

09 Mar '09

Full_Name: Martin Konold Version: 2.4.15 OS: Linux URL: http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch Submission from: (NULL) (91.46.180.44) Previous versions of OpenLDAP could show a sig11 when doing slapcat (using bdb backend). The version 2.4.15 improved in this respect already though doing a slapcat with an emtpy db still results in a segmentation fault. The following small patch by andreas.mack at erfrakon.de resolves this issue http://www.erfrakon.de/konold/openldap-2.4.15.empty-db-segfault.patch The patch is used by the Kolab Project in productive installations Regards, -- martin

1 0

Re: (ITS#5983) ldappasswd returns "Additional info: password hash failed" in Solaris 10 SPARC
by mariusp44＠gmail.com 09 Mar '09

09 Mar '09

so I finally found what's the problem. I run openldap in chroot. In Solaris, function lutil_entropy() uses /dev/urandom (if configure script finds it which is my case) to generate random strings for salt. Since in chroot it was not able to open /dev/urandom since it was not existent in chroot jail and there is no any error message loged in the lutil_entropy() when open() returns value <0. it simply returns up to calling function. Once I mknod dev/urandom in chroot everything started to work properly. So it is definately not the bug nor is it compiler flaw. Not sure if it's required by coding standards but I would log some informative message if function fails to open a device apart from very generic "implementation specific" message. Thanks all for help, /M. ando(a)sys-net.it wrote: > mariusp44(a)gmail.com wrote: >> sorry, if I was misunderstood. I am not asking to do my legwork. Just >> trying to understand what is going wrong. Sorry, if it seemed that way. >> >> I installed Sun Studio 12 (latest) and the problem is the same. I don't >> think Sun Studio is not working compiler. Just looks very unlikely. IT >> compiles everything without single problem. both 32 and 64 bit memory >> models. >> >> Perhaps I was not entirely clear. Weird thing is that it is only not >> working when changing password using ldappasswd and hash is set to SMD5 >> SSHA or CRYPT. If I manually change the password setting userPassword >> after generating it with slappasswd using say SSHA, it works fine. I >> mean user can bind using password that is stored in SSHA or SMD5. That >> tells me that slapd can still do encryption properly and check against >> hashes in question. At some point it needs to generate a hash and does >> it properly. Only when slapd is asked to change a password with >> ldappasswd it is unable to generate proper hash. Unless process is >> entirely different when changing password and authorizing against password. >> I am not insisting it is a bug in slapd code. But I am running out of >> ideas what else could be wrong and was just hoping that somebody else is >> using openldap on the same architecture and perhaps experienced >> something similar. > > Since no one else is seeing the problem, I already recommended that you > step in the (non-optimized) code with a debugger and see why this > happens. The right place to start is slap_passwd_hash_type(), whose > failure is setting the error message you see. > > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > >

1 0

Re: (ITS#5836) hung writers
by hyc＠symas.com 09 Mar '09

09 Mar '09

quanah(a)OpenLDAP.org wrote: > --On November 28, 2008 10:49:36 PM +0000 quanah(a)OpenLDAP.org wrote: > >> slapd ends up hanging indefinitely. This happened with 8 replicas >> connected to the server, where for four of those replicas, the connection >> between the master and the replica wouldn't connect (but you could go >> from the replica to the master) at some point after the initial >> connection was made. >> >> Patch to HEAD from Howard is committed. > > > Patch from Howard needs to be expanded so that a new keyword is used for > the idle timer here, rather than the value from idletimeout. This will > require some reworking of the daemon to wake up for that interval as well. Committed to HEAD - added a writetimeout config keyword. -- -- Howard Chu CTO, 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#6011) test050 segfault
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Tuesday, March 10, 2009 1:23 AM +0000 openldap-its(a)OpenLDAP.org wrote: This doesn't look good to me... (gdb) thread 1 [Switching to thread 1 (process 5616)]#1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 129 p = ber_bvchr( &csn, '#' ); (gdb) print p $4 = 0x434388a0 "ï¿½\210CC" (gdb) print csn $5 = {bv_len = 226880736, bv_val = 0x0} --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6011) test050 segfault
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/9/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Current RE24 segfaults in test050 for me. Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 (gdb) thr apply all bt Thread 7 (process 5559): #0 0x00002b457abc55b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b457a40cb2b in ldap_pvt_thread_join (thread=1088002368, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000435dbf in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418104 in main (argc=8, argv=0x7fff306aeb18) at ../../../servers/slapd/main.c:948 Thread 6 (process 5574): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435071 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (process 5589): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b457a660bce in ber_error_print (data=0x4171d920 "ber_scanf fmt ({mW}) ber:\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b457a660edb in ber_pvt_log_printf (errlvl=1, loglvl=261, fmt=0x2b457a664bee "ber_scanf fmt (%s) ber:\n") at ../../../libraries/liblber/bprint.c:141 #5 0x00002b457a65be36 in ber_scanf (ber=0xde6fee0, fmt=0x516949 "{mW}") at ../../../libraries/liblber/decode.c:784 #6 0x00000000004b3434 in syncrepl_message_to_entry (si=0x2aaaac0195e0, op=0x4171e690, msg=0xde63100, modlist=0x4171e418, entry=0x4171e4e0, syncstate=1) at ../../../servers/slapd/syncrepl.c:1855 #7 0x00000000004afbe0 in do_syncrep2 (op=0x4171e690, si=0x2aaaac0195e0) at ../../../servers/slapd/syncrepl.c:887 #8 0x00000000004b1546 in do_syncrepl (ctx=0x4171ed90, arg=0x2aaaac016d00) at ../../../servers/slapd/syncrepl.c:1348 #9 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #10 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #11 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (process 5590): #0 0x00000000004c3ed3 in slap_compose_sync_cookie (op=0x0, cookie=0x2aaaac017640, csn=0x0, rid=1, sid=2) at ../../../servers/slapd/ldapsync.c:47 #1 0x00000000004aefcc in do_syncrep1 (op=0x42438690, si=0x2aaaac017480) at ../../../servers/slapd/syncrepl.c:661 #2 0x00000000004b14b4 in do_syncrepl (ctx=0x42438d90, arg=0x2aaaac0182b0) at ../../../servers/slapd/syncrepl.c:1336 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (process 5615): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 #3 0x00002b457a660c18 in ber_error_print (data=0x42c38850 "<= ldap_bv2dn(cn=config)=0 \n") at ../../../libraries/liblber/bprint.c:87 #4 0x00002b457a433465 in ldap_log_printf (ld=0x0, loglvl=4, fmt=0x2b457a447b90 "<= ldap_bv2dn(%s)=%d %s\n") at print.c:60 #5 0x00002b457a4201fc in ldap_bv2dn_x (bvin=0x2aaab000b1b0, dn=0x42c38f50, flags=0, ctx=0x0) at getdn.c:892 #6 0x0000000000453ccb in dnNormalize (use=2, syntax=0xd810b10, mr=0xd815030, val=0x2aaab000b1b0, out=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/dn.c:438 #7 0x000000000045e7e4 in ordered_value_normalize (usage=2, ad=0xd81c310, mr=0xd815030, val=0x2aaab000b1b0, normalized=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/value.c:583 #8 0x0000000000458cf3 in slap_mods_check (op=0x42c39630, ml=0x2aaab000b200, text=0x42c39238, textbuf=0x42c39130 "p\221�B", textlen=256, ctx=0x0) at ../../../servers/slapd/modify.c:625 #9 0x00000000004b35c8 in syncrepl_message_to_entry (si=0x2aaaac0177a0, op=0x42c39630, msg=0x2aaab000afa0, modlist=0x42c393b8, entry=0x42c39480, syncstate=1) at ../../../servers/slapd/syncrepl.c:1892 #10 0x00000000004afbe0 in do_syncrep2 (op=0x42c39630, si=0x2aaaac0177a0) at ../../../servers/slapd/syncrepl.c:887 #11 0x00000000004b1546 in do_syncrepl (ctx=0x42c39d90, arg=0x2aaaac00db90) at ../../../servers/slapd/syncrepl.c:1348 #12 0x0000000000439047 in connection_read_thread (ctx=0x42c39d90, argv=0x9) at ../../../servers/slapd/connection.c:1225 #13 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #14 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #15 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (process 5767): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b457a40cb53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x43c3bd90, arg=0xdc43fc0) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (process 5616): #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 #1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 #2 0x00002aaaaaab9799 in syncprov_op_response (op=0x4343a630, rs=0x4343a1b0) at ../../../../servers/slapd/overlays/syncprov.c:1673 #3 0x000000000044e039 in slap_response_play (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:349 #4 0x000000000044e24f in send_ldap_response (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:423 #5 0x000000000044f101 in slap_send_ldap_result (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:692 #6 0x00000000004272f3 in config_back_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/bconfig.c:5197 #7 0x00000000004c206a in overlay_op_walk (op=0x4343a630, rs=0x4343a1b0, which=op_modify, oi=0xda30020, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c226d in over_op_func (op=0x4343a630, rs=0x4343a1b0, which=op_modify) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c234b in over_op_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/backover.c:755 #10 0x00000000004b7209 in syncrepl_updateCookie (si=0xdc44440, op=0x4343a630, pdn=0xd83fd20, syncCookie=0x4343a420) at ../../../servers/slapd/syncrepl.c:2979 #11 0x00000000004afc79 in do_syncrep2 (op=0x4343a630, si=0xdc44440) at ../../../servers/slapd/syncrepl.c:894 #12 0x00000000004b1546 in do_syncrepl (ctx=0x4343ad90, arg=0xdc44850) at ../../../servers/slapd/syncrepl.c:1348 #13 0x0000000000439047 in connection_read_thread (ctx=0x4343ad90, argv=0xe) at ../../../servers/slapd/connection.c:1225 #14 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #15 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #16 0x000000395e0d1e3d in clone () from /lib64/libc.so.6

1 0

ldapsearch weird results - wild card not working as expected
by Simon McGregor 09 Mar '09

09 Mar '09

I wrote a script to add groups to my ldap directory --------------------------------- #!/bin/sh # Get the latest gid gidlast="`ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1`" newgid="`echo "$gidlast + 1" | bc`" echo "newgid: $newgid" # Make the Mods echo "dn: cn=$1,ou=Group,dc=mydomain,dc=com" > /tmp/modify.ldap echo "changetype: add" >> /tmp/modify.ldap echo "objectClass: posixGroup" >> /tmp/modify.ldap echo "objectClass: top" >> /tmp/modify.ldap echo "cn: $1" >> /tmp/modify.ldap echo "gidNumber: $newgid" >> /tmp/modify.ldap # Run the Update ldapmodify -x -f /tmp/modify.ldap -h myserver -D cn=Manager,dc=mydomain,dc=com -w mypasswd ---------------------------------- This correctly creates a new group eg. ./mkgroup.sh mygroup01 $ ldapsearch -x "cn=mygroup01" -h myserver produces -> # mygroup01, Group, mydomain.com dn: cn=mygroup01,ou=Group,dc=mydomain,dc=com objectClass: posixGroup objectClass: top cn: mygroup01 gidNumber: 7435 memberUid: dummyuser The issue is the following: $ ldapsearch -x "cn=mygroup*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7435 $ ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7434 In other words the wild card is not picking up the new group even though it is actually there. Perhaps someone can show me the error of my ways but I think both results should return the same value I am running centos 5 with openldap-clients-2.3.27-8.el5_2.4 openldap-servers-2.3.27-8.el5_2.4 openldap-2.3.27-8.el5_2.4 openldap-devel-2.3.27-8.el5_2.4 The information contained in this email and any attachments is strictly confidential. If you are not the intended recipient you must not disclose or use the information contained in it. If you have received this email in error please notify us immediately by return email and delete the document. Domain Principal Pty Ltd accepts no liability for any loss or damage caused by this email or its attachments due to viruses interference interception corruption or unauthorised access.

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009