openldap-bugs February 2013

openldap-bugs@openldap.org

22 participants
48 discussions

Re: (ITS#7527) Problems Adding entries to back-mdb database
by hyc＠symas.com 13 Feb '13

13 Feb '13

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: RE24 pulled 11-Feb-2013 > OS: debian wheezy (testing) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.180.239.194) > > > When attempting to add a new entry to a back-mdb database I am seeing > the following failure: > > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" > ldap_add: Other (e.g., implementation specific) error (80) > additional info: index generation failed Since you pulled RE24 on Feb 11, your code should be producing additional error info in syslog. Please send the slapd logs associated with this error. -- -- 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#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu 13 Feb '13

13 Feb '13

Full_Name: Bill MacAllister Version: RE24 pulled 11-Feb-2013 OS: debian wheezy (testing) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.180.239.194) When attempting to add a new entry to a back-mdb database I am seeing the following failure: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" ldap_add: Other (e.g., implementation specific) error (80) additional info: index generation failed The attribute that is causing the failure is suPrivilegeGroup. The schema definition for this attribute is: olcAttributeTypes: ( StanfordLDAPattributeType:19 NAME ( 'suPrivilegeGroup' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The index defined for this attribute is: olcDbIndex: suPrivilegeGroup eq,sub I have been able to successfully load the entry by either: * Modifying the index definition by removing the substring index, i.e. 'olcDbIndex: suPrivilegeGroup eq,sub'. or * Modifying the data. The value 'suPrivilegeGroup: n:all' succeeds and the value 'suPrivilegeGroup: ne:all' fails. Here is a complete failing entry: dn: suRegID=uniqueid1,cn=people,dc=stanford,dc=edu objectClass: suPerson objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: person displayName: Bill MacAllister suCN: bill macallister suDisplayNameLF: MacAllister, Bill suGeneralID: billmacallister suRegID: uniqueid1 suRegisteredName: William Henry MacAllister suRegisteredNameLF: MacAllister, William Henry suSN: macallister suUniqueIdentifier: unique1 sn: macallister o: University ou: netdocs-access:all uid: whm cn: bill macallister cn: william macallister givenName: william givenName: bill suPrivilegeGroup: ne:all I first started investigating this problem because some entries where not present in the directory after a complete refresh from an ldif dumped from a 2.4.26 server. I used slapadd to load the ldif and there were no error messages during the load, just some entries were missing. I expect that the lack of an error message from slapadd is a separate, but related issue.

1 0

Re: (ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com 13 Feb '13

13 Feb '13

--=_alternative 0036332BC1257B11_= Content-Type: text/plain; charset="US-ASCII" Installed the master revision (openldap-648d28f.tar.gz) Test ok . Many thanks, Francesco Policastro From: Pierangelo Masarati <masarati(a)aero.polimi.it> To: <francesco.policastro(a)selex-es.com> Cc: <openldap-its(a)openldap.org> Date: 12/02/2013 17:23 Subject: Re: (ITS#7525) Bad conversion to cn=config format Fixed in git master, please test. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano --=_alternative 0036332BC1257B11_= Content-Type: text/html; charset="US-ASCII" Installed the master revision (openldap-648d28f.tar.gz) Test ok . Many thanks, Francesco Policastro <table width=100%> <tr valign=top> <td>From: <td>Pierangelo Masarati <masarati(a)aero.polimi.it> <tr valign=top> <td>To: <td><francesco.policastro(a)selex-es.com> <tr> <td valign=top>Cc: <td><openldap-its(a)openldap.org> <tr valign=top> <td>Date: <td>12/02/2013 17:23 <tr valign=top> <td>Subject: <td>Re: (ITS#7525) Bad conversion to cn=config format</table> <hr noshade> <tt>Fixed in git master, please test.  p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano </tt> --=_alternative 0036332BC1257B11_=--

1 0

Re: (ITS#7526) Segfault in slapd-meta during olcDbUri modify
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

> Full_Name: John Madden > Version: 2.4.32 > OS: Linux / RHEL6/64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.91.17.188) > > > slapd-meta frontend to another slapd, perform an ldapmodify on the > olcDbUri > (incidentally while troubleshooting incorrect proxy behavior) results in a > segfault. Your backtrace looks useless; however, I could reproduce the problem. A(n almost blind) fix is coming. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7526) Segfault in slapd-meta during olcDbUri modify
by jmadden＠ivytech.edu 12 Feb '13

12 Feb '13

Full_Name: John Madden Version: 2.4.32 OS: Linux / RHEL6/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.91.17.188) slapd-meta frontend to another slapd, perform an ldapmodify on the olcDbUri (incidentally while troubleshooting incorrect proxy behavior) results in a segfault. (gdb) attach 5979 Attaching to process 5979 Reading symbols from /usr/local/libexec/slapd...(no debugging symbols found)...done. Reading symbols from /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f9dc6485700 (LWP 6928)] [New Thread 0x7f9dc6c86700 (LWP 6927)] [New Thread 0x7f9dc7487700 (LWP 5980)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/libcrammd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libplain.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/liblogin.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libgssapiv2.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 glibc-2.12-1.80.el6_3.6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-25.el6_3.1.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9dc6c86700 (LWP 6927)] 0x0000000000516517 in ?? () (gdb) backtrace full #0 0x0000000000516517 in ?? () No symbol table info available. #1 0x0000000000412b2c in ?? () No symbol table info available. #2 0x0000000000438a8b in ?? () No symbol table info available. #3 0x00000000004393b6 in ?? () No symbol table info available. #4 0x00000000004212d9 in ?? () No symbol table info available. #5 0x0000000000421ab5 in ?? () No symbol table info available. #6 0x0000000000570da0 in ?? () No symbol table info available. #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) info registers rax 0x19 25 rbx 0x7f9dc6c83340 140315621602112 rcx 0x0 0 rdx 0x19 25 rsi 0x7f9dc6c83340 140315621602112 rdi 0x7f9dc6c83340 140315621602112 rbp 0x1dbaf00 0x1dbaf00 rsp 0x7f9dc6c80bf0 0x7f9dc6c80bf0 r8 0x0 0 r9 0x7f9dc6c830c0 140315621601472 r10 0x84db78 8706936 r11 0x0 0 r12 0x1d55390 30757776 r13 0x7f9dc6c83340 140315621602112 r14 0x7f9db8112be0 140315374726112 r15 0x7f9db8112670 140315374724720 rip 0x516517 0x516517 eflags 0x10283 [ CF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/16i $pc => 0x516517: mov 0x0,%rdi 0x51651f: test %rdi,%rdi 0x516522: je 0x515858 0x516528: callq 0x43b4e0 0x51652d: xor %ebp,%ebp 0x51652f: movq $0x0,0x0 0x51653b: jmpq 0x515745 0x516540: andl $0xfffffe7f,0x8 0x51654b: xor %ebp,%ebp 0x51654d: jmpq 0x515745 0x516552: andl $0xfffdffff,0x8 0x51655d: xor %ebp,%ebp 0x51655f: jmpq 0x515745 0x516564: movq $0x0,0x138(%rbp) 0x51656f: xor %ebp,%ebp 0x516571: jmpq 0x515745 (gdb) thread apply all backtrace Thread 4 (Thread 0x7f9dc7487700 (LWP 5980)): #0 0x0000003310ce8713 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041e5fa in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f9dc6c86700 (LWP 6927)): #0 0x0000000000516517 in ?? () #1 0x0000000000412b2c in ?? () #2 0x0000000000438a8b in ?? () #3 0x00000000004393b6 in ?? () #4 0x00000000004212d9 in ?? () #5 0x0000000000421ab5 in ?? () #6 0x0000000000570da0 in ?? () #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f9dc6485700 (LWP 6928)): #0 0x000000331140b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000570df5 in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f9dcb64e7c0 (LWP 5979)): #0 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041b951 in ?? () #2 0x00000000004081c5 in ?? () #3 0x0000003310c1ecdd in __libc_start_main () from /lib64/libc.so.6 #4 0x0000000000406a69 in ?? () #5 0x00007fffe3969bc8 in ?? () #6 0x000000000000001c in ?? () #7 0x0000000000000005 in ?? () #8 0x00007fffe396bd7a in ?? () #9 0x00007fffe396bd93 in ?? () #10 0x00007fffe396bd96 in ?? () #11 0x00007fffe396bdbe in ?? () #12 0x00007fffe396bdc1 in ?? () #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7525) Bad conversion to cn=config format
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

Fixed in git master, please test. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com 12 Feb '13

12 Feb '13

Full_Name: Francesco Policastro Version: 2.4.33 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.127.80.134) A slapd.conf using meta backend can include the following uri definition that is accepted as legal uri "ldap://server2.domain2.net/ou=org Unit,dc=second,dc=newco,dc=com" idassert-bind bindmethod=simple binddn="cn=ldap-2,cn=Users,dc=domain2,dc=net" credentials=secret3 chase-referrals no rebind-as-user true map objectclass groupOfNames * map objectclass person * suffixmassage "dc=second,dc=newco,dc=com" "dc=domain2,dc=net" subtree-include "ou=Users,ou=1stlocation,ou=org Unit,dc=second,dc=newco,dc=com" ... "slaptest -f slapd.conf" returns "config file testing succeeded" "slaptest -f slapd.conf -F slapd.d" converts to cn=config format "slaptest -F slapd.d" issues an error: 511a57ef olcDbURI: value #0: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>". 511a57ef config error processing olcMetaSub={1}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>" slaptest: bad configuration directory! I know that the offending words are in the "ou=org Unit" directive; in fact "ou=orgUnit" (with no space) works. The uri sintax permits to enclose the string in quotes and one assumes that spaces are legal. They are only in slapd.conf because the cn=config conversion does not accept them.

1 0

(ITS#7524) Seg fault of slapd with back-meta traffic
by jorge.perez.burgos＠ericsson.com 12 Feb '13

12 Feb '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) PROBLEM Sending high load traffic to several slapd servers that are proxying the traffic to only one slapd. It can seen that in this situation originating servers crash sporadically. POSSIBLE SOLUTION In back-meta/conn.c in the method meta_back_retry it seems that the binding flag is not set properly in the following situation: /* restore the "binding" flag, in case */ if ( binding ) { LDAP_BACK_CONN_BINDING_SET( msc ); } if ( rc == LDAP_SUCCESS ) { quarantine = 0; rc = meta_back_single_dobind( op, rs, mcp, candidate, sendok, mt->mt_nretries, 0 ); Setting the binding flag before calling meta_back_single_dobind seems to solve the issue (LDAP_BACK_CONN_BINDING_SET( msc );) CORE DUMP TRACE This is the backtrace of the core dumped. Program terminated with signal 6, Aborted. #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 #1 0x00002ad023475340 in abort () from /lib64/libc.so.6 #2 0x00002ad02346d486 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000051cfe1 in meta_back_bind_op_result (op=0x69d2580, rs=0x2aab95e57c70, mc=0x2aab62a44740, candidate=2, msgid=1, sendok=<value optimized out>, dolock=0) at bind.c:392 #4 0x000000000051d130 in meta_back_proxy_authz_bind (mc=0x2aab62a44740, candidate=2, op=0x69d2580, rs=0x2aab95e57c70, sendok=LDAP_BACK_DONTSEND, dolock=0) at bind.c:1590 #5 0x000000000051d37b in meta_back_single_dobind (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND, nretries=<value optimized out>, dolock=0) at bind.c:605 #6 0x000000000052714d in meta_back_retry (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND) at conn.c:769 #7 0x00000000004db025 in meta_back_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:1154 #8 0x00000000004636d9 in fe_op_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:402 #9 0x00000000004c4e02 in overlay_op_walk (op=0x69d2580, rs=0x2aab95e57c70, which=op_search, oi=0x8088000, on=0x0) at backover.c:671 #10 0x00000000004c5307 in over_op_func (op=0x69d2580, rs=0x2aab95e57c70, which=op_search) at backover.c:723 #11 0x0000000000463ee5 in do_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:247 #12 0x0000000000460f45 in connection_operation (ctx=0x2aab95e57e50, arg_v=<value optimized out>) at connection.c:1308 #13 0x0000000000461e05 in connection_read_thread (ctx=0x2aab95e57e50, argv=<value optimized out>) at connection.c:1444 #14 0x000000000055cb7c in ldap_int_thread_pool_wrapper (xpool=0x8028000) at tpool.c:688 #15 0x00002ad022ec92a3 in start_thread () from /lib64/libpthread.so.0 #16 0x00002ad02350549d in clone () from /lib64/libc.so.6

1 0

(ITS#7523) ldap valsort control is not documented
by quanah＠OpenLDAP.org 11 Feb '13

11 Feb '13

Full_Name: Quanah Gibson-Mount Version: 2.4.33 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) The slapo-valsort(5) man page does not mention the fact that the LDAP_CONTROL_VALSORT (1.3.6.1.4.1.4203.666.5.14 can be specified to allow the returning of the values with weights present.

1 0

(ITS#7522) Admin Guide: bugs in example
by openldap＠laimbock.com 10 Feb '13

10 Feb '13

Full_Name: Patrick Laimbock Version: RE24 OS: CentOS 6.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.210.175.192) In the OpenLDAP Admin Guide on page 38 it says: 34. olcSuffix: "dc=example,dc=com" 35. olcDbDirectory: /usr/local/var/openldap-data 36. olcRootDN: "cn=Manager,dc=example,dc=com" 37. olcRootPW: secret 38. olcDbIndex: uid pres,eq 39. olcDbIndex: cn,sn,uid pres,eq,approx,sub When I try to slapadd that example config I get the following errors: 5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) 5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) /etc/openldap34/slapd.d: line 1: duplicate index definition for attr "uid" When I remove the quotes from the olcSuffix (line 34) and olcRootDN (line 36) entries and remove the double uid from either line 38 or line 39 then the slapadd action is successful.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2013