- openldap-bugs - openldap.org

(ITS#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu 14 Feb '13

14 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

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by balint＠balintreczey.hu 07 Feb '13

07 Feb '13

Hi Howard, Thank you! I have updated the Debian bug report [1]. Cheers, Balint [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038 2013/2/7 Howard Chu <hyc(a)symas.com>: > I've committed an alternate fix for this to git master, filed against > ITS#6365. Please test and let us know your results, thanks. > The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 > > -- > -- 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#7503) slapcat: retry a few times when retrieving an entry
by hyc＠symas.com 07 Feb '13

07 Feb '13

I've committed an alternate fix for this to git master, filed against ITS#6365. Please test and let us know your results, thanks. The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 -- -- 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#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by hyc＠symas.com 06 Feb '13

06 Feb '13

quanah(a)zimbra.com wrote: > --On Wednesday, February 06, 2013 6:33 PM +0000 TCera(a)sjrwmd.com wrote: > >> --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ >> Content-Type: text/plain; charset="us-ascii" >> Content-Transfer-Encoding: quoted-printable >> >> xwiki uses jldap. >> >> http://www.openldap.org/jldap/ > > JLDAP is written in java, and does not use the OpenLDAP C libraries. If > you are going to use Java, I highly recommend you look at the unboundID SDK. > > I would also note that PHP's LDAP Support is known to be utterly broken. > There is no indication anywhere here in your report that indicates a bug > with the OpenLDAP software. If he could reproduce the issue using OpenLDAP's command line tools, there would be reason to suspect libldap. But no such problem occurs for me using e.g. ldapsearch. Closing this ITS. -- -- 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#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by quanah＠zimbra.com 06 Feb '13

06 Feb '13

--On Wednesday, February 06, 2013 6:33 PM +0000 TCera(a)sjrwmd.com wrote: > --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xwiki uses jldap. > > http://www.openldap.org/jldap/ JLDAP is written in java, and does not use the OpenLDAP C libraries. If you are going to use Java, I highly recommend you look at the unboundID SDK. I would also note that PHP's LDAP Support is known to be utterly broken. There is no indication anywhere here in your report that indicates a bug with the OpenLDAP software. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by TCera＠sjrwmd.com 06 Feb '13

06 Feb '13

--_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable xwiki uses jldap. http://www.openldap.org/jldap/ Without delving deeper, I don't know whether jldap uses openldap libraries = or not. I thought that it might since it was an openldap project. Though = if jldap and openldap are different enough then this issue points to a prob= lem then with Active Directory. On the other hand, Windows login, email, .= ..etc. were unaffected by the comma and period in the password. Regardless - take the comma and period out of my password, both tikiwiki an= d xwiki work. --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> xwiki uses jldap.<o:p></o:p> <o:p> </o:p> http://www.openldap.org/jldap/<o:p></o:p> <o:p> </o:p> Without delving deeper, I don't know whether jldap u= ses openldap libraries or not.  I thought that it might since it was a= n openldap project.  Though if jldap and openldap are different enough= then this issue points to a problem then with Active Directory.  On the other hand, Windows login, email, …et= c. were unaffected by the comma and period in the password.  <o:p></o:p> <o:p> </o:p> Regardless - take the comma and period out of my pas= sword, both tikiwiki and xwiki work. <o:p></o:p> </div> </body> </html> --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_--

1 0

Re: (ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by quanah＠zimbra.com 06 Feb '13

06 Feb '13

--On Wednesday, February 06, 2013 12:50 PM +0000 tim(a)cerazone.net wrote: > Full_Name: Tim Cera > Version: 2.4.23-26.el6_3.2 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.252.34.1) > > > Currently using tikiwki (PHP) with LDAP authentication, and began > experimenting with xwiki (Java) also with LDAP authentication. Both > against an Active Directory server. With both systems you cannot > authenticate a password with either a comma or a period, so suspect it is > the underlying OpenLDAP libraries. The test password had both a comma > and period, and the account is locked right now so I can't easily test > which one or both are required to activate the bug. I would suspect you are incorrect if you are having this problem with a Java program, since Java would not be linked to the OpenLDAP C libraries. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by tim＠cerazone.net 06 Feb '13

06 Feb '13

Full_Name: Tim Cera Version: 2.4.23-26.el6_3.2 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.252.34.1) Currently using tikiwki (PHP) with LDAP authentication, and began experimenting with xwiki (Java) also with LDAP authentication. Both against an Active Directory server. With both systems you cannot authenticate a password with either a comma or a period, so suspect it is the underlying OpenLDAP libraries. The test password had both a comma and period, and the account is locked right now so I can't easily test which one or both are required to activate the bug. I did try looking for this bug suspecting that it would have been reported, and didn't find it. Hope this isn't a duplicate.

1 0

Re: (ITS#7520) back-ldap omit-unknown-schema
by tedcheng＠symas.com 06 Feb '13

06 Feb '13

Please find the patch at: https://dl.dropbox.com/u/94235048/back_ldap_omit_unknown_schema.patch The attached file is derived from OpenLDAP Software. By virtue of my employment agreement with Symas Corporation, I have assigned my rights and interest to Symas Corporation. Symas Corporation has not assigned rights and/or interest to any party. I, Ted C. Cheng, am authorized by Symas Corporation, my employer, to release this work under the following terms. Symas Corporation hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ted C. Cheng Symas Corporation

1 0

(ITS#7520) back-ldap omit-unknown-schema
by tedcheng＠symas.com 06 Feb '13

06 Feb '13

Full_Name: Ted C. Cheng Version: HEAD OS: Linux/Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.174.253.197) This patch allows back-ldap to ignore unknown schema defined by a remote (foreign) LDAP server. Clients do not need to handle schema that are not local to the slapd server.

1 0

Re: (ITS#7518) nssov sync'ed up with nss_pam_ldapd.0.8.11
by tedcheng＠symas.com 06 Feb '13

06 Feb '13

The attached file is derived from OpenLDAP Software. By virtue of my employment agreement with Symas Corporation, I have assigned my rights and interest to Symas Corp. Symas Corporation has not assigned rights and/or interest to any party. I, Ted C. Cheng, am authorized by Symas Corporation, my employer, to release this work under the following terms. Symas Corporation hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Ted C. Cheng Symas Corporation On Feb 4, 2013, at 5:01 PM, openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7518. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7518) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7518) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7518 > > Please remember to retain your issue tracking number (ITS#7518) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

Re: (ITS#7519) a suspicious bug about OpenLDAP Software 2.4 Administrator's Guide
by michael＠stroeder.com 05 Feb '13

05 Feb '13

This is a cryptographically signed message in MIME format. --------------ms040601090102040300070904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ouyangguang(a)huawei.com wrote: > But when I browse the functions "ldap_bind" > and "ldap_bind_s", none of LDAP_AUTH_KRBV4, LDAP_AUTH_KRBV41 or LDAP_AU= TH_KRBV42 > mode is supported. So I think it is wrong with the document. > Anybody knows that? This is not a bug. The options you mentioned were for deprecated Krb4 (as= the names show) which you definitely don't want to use. Please post questions about how to use SASL/GSSAPI-Krb5 bind to the openldap-technical mailing list and not into the bug tracker. Ciao, Michael. --------------ms040601090102040300070904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjA1MTQ0NjI1WjAjBgkq hkiG9w0BCQQxFgQU/uCgt9UJwE1eF6/+PhHEzEpoylkwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAdrTmfQp7wmG7rRQ65ZLKN1YbhvY2QtL3Qqg9OscNNpJEfVUzvVbycBXl5zgKz8WAIrzq X44MVDRKMAOf2/voXuKVg29pPIJE2gcGHdY+7IrLeLssuLE5tbqY9yX3BM7Utp1IihOIeAeU wYBOZbthOxrb21aQf8pWatOmyHlkdzlomqjX/h8WBcccCtK66zGVjncDFqxPIarq/M0PSIn3 qJmcz5KBWU6wIt7p//D5hbnqHvyW9j9uHi8HrusNPSdssL+FO8cG0A/HIyOu0Mwp39tet6LR AGpWDGJqWJHYWS4TuNlJWOhPq3esTUJkPSSoh3TT/Z6a+9ExohQgpfLOFgAAAAAAAA== --------------ms040601090102040300070904--

1 0

(ITS#7519) a suspicious bug about OpenLDAP Software 2.4 Administrator's Guide
by ouyangguang＠huawei.com 05 Feb '13

05 Feb '13

Full_Name: OuYang Guang Version: openldap-2.4.33 OS: Suse linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.133.0.1) I'm trying build a ldap client with OpenLDAP-2.4.33 and I want to use Kerberos authentication services. According to the chapter "4.2.3. Kerberos Authentication Service" of OpenLDAP Software 2.4 Administrator's Guide, OpenLDAP clients and servers support Kerberos authentication services. But when I browse the functions "ldap_bind" and "ldap_bind_s", none of LDAP_AUTH_KRBV4, LDAP_AUTH_KRBV41 or LDAP_AUTH_KRBV42 mode is supported. So I think it is wrong with the document. Anybody knows that? Thank you!

1 0

(ITS#7518) nssov sync'ed up with nss_pam_ldapd.0.8.11
by tedcheng＠symas.com 05 Feb '13

05 Feb '13

Full_Name: Ted C. Cheng Version: HEAD OS: Linux/Solaris URL: https://dl.dropbox.com/u/94235048/nssov_sync_w_nss_pam_ldapd_0_8_11.patch Submission from: (NULL) (76.174.253.197) Please find nssov patch in the link provided: 1. Sync'ed up with nss-pam-ldapd 0.8.11: * added nssov_config support * added password_prohibit_message, similar to PADL * self-pwd-changes are made as user identities; root changing user passwords as nssov-pam-pwdmgr-dn 2. Fixed a bug that connection DN was not constructed correctly. 3. Fixed a service debug crash issue when protocol value is NULL 4. Added more debugging msgs

1 0

(ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 02 Feb '13

02 Feb '13

Full_Name: Hallvard B Furuseth Version: mdb.master 48dc782ea612f85e8356a50bfbafe22e5be121cf OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard If a thread modifies a named MDB database and closes it before committing, the changes are lost. The mdb_dbi_close() doc only says we must not close DBs which _other_ theads will reference. I expect mdb_dbi_close() could check if the env has an active write txn where the DB is dirty, and mdb_put() it first. And in any parent txns which have it open, dunno if that's doable. If not, in this case maybe _close() could stash away the DB info so mdb_txn_commit()/mdb_txn_reset0() can save the updates. Note that another mdb_dbi_open() can reuse the closed DBI, so carelessness could e.g. save the changes with the wrong DB name. Test case (no nested txns): #include <lmdb.h> #include <stdio.h> #include <stdlib.h> int main(void) { char *dbname = "test.mdb"; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; int rdonly, rc; MDB_val key = {3, "foo"}, data = {3, "abc"}, rdata; # define E(e) { rc = (e); if (rc) { fprintf(stderr, "%s:%d: %s: %s\n", \ __FILE__, __LINE__, #e, mdb_strerror(rc)); abort(); } } remove(dbname); for (rdonly = 0; rdonly <= MDB_RDONLY; rdonly += MDB_RDONLY) { E(mdb_env_create(&env)); E(mdb_env_set_maxdbs(env, 1)); E(mdb_env_open(env, dbname, MDB_NOSYNC|MDB_NOSUBDIR, 0666)); E(mdb_txn_begin(env, NULL, rdonly, &txn)); E(mdb_dbi_open(txn, NULL, rdonly ? 0 : MDB_CREATE, &dbi)); if (!rdonly) { E(mdb_put(txn, dbi, &key, &data, 0)); mdb_dbi_close(env, dbi); } else { E(mdb_get(txn, dbi, &key, &rdata)); } E(mdb_txn_commit(txn)); mdb_env_close(env); } return 0; }

1 0

Re: (ITS#7516) Mysql backend is readonly with included metadata sql files
by masarati＠aero.polimi.it 01 Feb '13

01 Feb '13

On 02/01/2013 01:56 PM, povilas(a)Daukas.lt wrote: > Full_Name: Povilas Daukas > Version: any > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.63.107.40) > > > > Hi, > > While trying to setup mysql as backend to the openldap server i noticed that it > only allowed reading from the database but not updating as the metadata was not > there to handle the updates. > > So I adopted the functions and sql from PostgreSQL to make it read write. the > file to modify is below. Thank you, but please follow guidelines for contributions here <http://www.openldap.org/devel/contributing.html> to ease review and integration. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7516) Mysql backend is readonly with included metadata sql files
by povilas＠Daukas.lt 01 Feb '13

01 Feb '13

Full_Name: Povilas Daukas Version: any OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.63.107.40) Hi, While trying to setup mysql as backend to the openldap server i noticed that it only allowed reading from the database but not updating as the metadata was not there to handle the updates. So I adopted the functions and sql from PostgreSQL to make it read write. the file to modify is below. Hope you and others will find it useful. Kind regards Paul ---------------------------------------------------------------------- File: servers/slapd/back-sql/rdbms_depend/mysql/testdb_metadata.sql ---------------------------------------------------------------------- -- mappings -- objectClass mappings: these may be viewed as structuralObjectClass, the ones that are used to decide how to build an entry -- id a unique number identifying the objectClass -- name the name of the objectClass; it MUST match the name of an objectClass that is loaded in slapd's schema -- keytbl the name of the table that is referenced for the primary key of an entry -- keycol the name of the column in "keytbl" that contains the primary key of an entry; the pair "keytbl.keycol" uniquely identifies an entry of objectClass "id" -- create_proc a procedure to create the entry -- delete_proc a procedure to delete the entry; it takes "keytbl.keycol" of the row to be deleted -- expect_return a bitmap that marks whether create_proc (1) and delete_proc (2) return a value or not INSERT INTO `ldap_oc_mappings` (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) VALUES ('1', 'inetOrgPerson', 'persons', 'id', 'SELECT create_person()', 'DELETE FROM persons WHERE id=?', 0); INSERT INTO `ldap_oc_mappings` (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) VALUES ('2', 'document', 'documents', 'id', 'SELECT create_doc()', 'DELETE FROM documents WHERE id=?', 0); INSERT INTO `ldap_oc_mappings` (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) VALUES ('3', 'organization', 'institutes', 'id', 'SELECT create_o()', 'DELETE FROM institutes WHERE id=?', 0); INSERT INTO `ldap_oc_mappings` (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) VALUES ('4', 'referral', 'referrals', 'id', 'SELECT create_referral()', 'DELETE FROM referrals WHERE id=?', 0); -- attributeType mappings: describe how an attributeType for a certain objectClass maps to the SQL data. -- id a unique number identifying the attribute -- oc_map_id the value of "ldap_oc_mappings.id" that identifies the objectClass this attributeType is defined for -- name the name of the attributeType; it MUST match the name of an attributeType that is loaded in slapd's schema -- sel_expr the expression that is used to select this attribute (the "select <sel_expr> from ..." portion) -- from_tbls the expression that defines the table(s) this attribute is taken from (the "select ... from <from_tbls> where ..." portion) -- join_where the expression that defines the condition to select this attribute (the "select ... where <join_where> ..." portion) -- add_proc a procedure to insert the attribute; it takes the value of the attribute that is added, and the "keytbl.keycol" of the entry it is associated to -- delete_proc a procedure to delete the attribute; it takes the value of the attribute that is added, and the "keytbl.keycol" of the entry it is associated to -- param_order a mask that marks if the "keytbl.keycol" value comes before or after the value in add_proc (1) and delete_proc (2) -- expect_return a mask that marks whether add_proc (1) and delete_proc(2) are expected to return a value or not INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('1', '1', 'cn', 'concat(persons.name,\' \',persons.surname)', null, 'persons', null, 'SELECT update_person_cn(?,?)', 'SELECT 1 FROM persons WHERE persons.name=? AND persons.id=? AND 1=0', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('2', '1', 'telephoneNumber', 'phones.phone', null, 'persons,phones', 'phones.pers_id=persons.id', 'SELECT add_phone(?,?)', 'DELETE FROM phones WHERE phone=? AND pers_id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('3', '1', 'givenName', 'persons.name', null, 'persons', null, 'UPDATE persons SET name=? WHERE id=?', 'UPDATE persons SET name=\'\' WHERE (name=? OR name=\'\') AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('4', '1', 'sn', 'persons.surname', null, 'persons', null, 'UPDATE persons SET surname=? WHERE id=?', 'UPDATE persons SET surname=\'\' WHERE (surname=? OR surname=\'\') AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('5', '1', 'userPassword', 'persons.password', null, 'persons', 'persons.password IS NOT NULL', 'UPDATE persons SET password=? WHERE id=?', 'UPDATE persons SET password=NULL WHERE password=? AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('6', '1', 'seeAlso', 'seeAlso.dn', null, 'ldap_entries AS seeAlso,documents,authors_docs,persons', 'seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id', null, 'DELETE from authors_docs WHERE authors_docs.doc_id=(SELECT documents.id FROM documents,ldap_entries AS seeAlso WHERE seeAlso.keyval=documents.id AND seeAlso.oc_map_id=2 AND seeAlso.dn=?) AND authors_docs.pers_id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('7', '2', 'description', 'documents.abstract', null, 'documents', null, 'UPDATE documents SET abstract=? WHERE id=?', 'UPDATE documents SET abstract=\'\'\'\' WHERE abstract=? AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('8', '2', 'documentTitle', 'documents.title', null, 'documents', null, 'UPDATE documents SET title=? WHERE id=?', 'UPDATE documents SET title=\'\' WHERE title=? AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('9', '2', 'documentAuthor', 'documentAuthor.dn', null, 'ldap_entries AS documentAuthor,documents,authors_docs,persons', 'documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id', 'INSERT INTO authors_docs (pers_id,doc_id) VALUES ((SELECT ldap_entries.keyval FROM ldap_entries WHERE upper(?)=upper(ldap_entries.dn)),?)', 'DELETE FROM authors_docs WHERE authors_docs.pers_id=(SELECT ldap_entries.keyval FROM ldap_entries WHERE upper(?)=upper(ldap_entries.dn)) AND authors_docs.doc_id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('10', '2', 'documentIdentifier', 'concat(\'document \',documents.id)', null, 'documents', null, null, 'SELECT 1 FROM documents WHERE title=? AND id=? AND 1=0', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('11', '3', 'o', 'institutes.name', null, 'institutes', null, 'UPDATE institutes SET name=? WHERE id=?', 'UPDATE institutes SET name=\'\' WHERE name=? AND id=?', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('12', '3', 'dc', 'lower(institutes.name)', null, 'institutes,ldap_entries AS dcObject,ldap_entry_objclasses as auxObjectClass', 'institutes.id=dcObject.keyval AND dcObject.oc_map_id=3 AND dcObject.id=auxObjectClass.entry_id AND auxObjectClass.oc_name=\'dcObject\'', null, 'SELECT 1 FROM institutes WHERE lower(name)=? AND id=? and 1=0', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('13', '4', 'ou', 'referrals.name', null, 'referrals', null, 'UPDATE referrals SET name=? WHERE id=?', 'SELECT 1 FROM referrals WHERE name=? AND id=? and 1=0', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('14', '4', 'ref', 'referrals.url', null, 'referrals', null, 'UPDATE referrals SET url=? WHERE id=?', 'SELECT 1 FROM referrals WHERE url=? and id=? and 1=0', '3', '0'); INSERT INTO `ldap_attr_mappings` into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return) VALUES ('15', '1', 'userCertificate', 'certs.cert', null, 'persons,certs', 'certs.pers_id=persons.id', null, null, '3', '0'); -- entries mapping: each entry must appear in this table, with a unique DN rooted at the database naming context -- id a unique number > 0 identifying the entry -- dn the DN of the entry, in "pretty" form -- oc_map_id the "ldap_oc_mappings.id" of the main objectClass of this entry (view it as the structuralObjectClass) -- parent the "ldap_entries.id" of the parent of this objectClass; 0 if it is the "suffix" of the database -- keyval the value of the "keytbl.keycol" defined for this objectClass insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (1,'dc=example,dc=com',3,0,1); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (2,'cn=Mitya Kovalev,dc=example,dc=com',1,1,1); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (3,'cn=Torvlobnor Puzdoy,dc=example,dc=com',1,1,2); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (4,'cn=Akakiy Zinberstein,dc=example,dc=com',1,1,3); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (5,'documentTitle=book1,dc=example,dc=com',2,1,1); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (6,'documentTitle=book2,dc=example,dc=com',2,1,2); insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values (7,'ou=Referral,dc=example,dc=com',4,1,1); -- objectClass mapping: entries that have multiple objectClass instances are listed here with the objectClass name (view them as auxiliary objectClass) -- entry_id the "ldap_entries.id" of the entry this objectClass value must be added -- oc_name the name of the objectClass; it MUST match the name of an objectClass that is loaded in slapd's schema insert into ldap_entry_objclasses (entry_id,oc_name) values (1,'dcObject'); insert into ldap_entry_objclasses (entry_id,oc_name) values (4,'pkiUser'); insert into ldap_entry_objclasses (entry_id,oc_name) values (7,'extensibleObject'); ---------------------------------- -- FUNCTIONS TO SUPPORT UPDATES AND DELETIONS -- ---------------------------- -- Function structure for `add_phone` -- ---------------------------- DROP FUNCTION IF EXISTS `add_phone`; DELIMITER ;; CREATE FUNCTION `add_phone`(`input_value` varchar(255),`input_id` int(11)) RETURNS int(11) BEGIN DECLARE return_value int(11); SET return_value = 0; insert into phones (phone,pers_id) values (input_value, input_id); select max(id) into return_value from phones; RETURN return_value; END ;; DELIMITER ; -- ---------------------------- -- Function structure for `create_doc` -- ---------------------------- DROP FUNCTION IF EXISTS `create_doc`; DELIMITER ;; CREATE FUNCTION `create_doc`() RETURNS int(11) BEGIN DECLARE return_value int(11); SET return_value = 0; insert into documents(id,title,abstract) values (null,'',''); select max(id) into return_value from documents; RETURN return_value; END ;; DELIMITER ; -- ---------------------------- -- Function structure for `create_o` -- ---------------------------- DROP FUNCTION IF EXISTS `create_o`; DELIMITER ;; CREATE FUNCTION `create_o`() RETURNS int(11) BEGIN DECLARE return_value int(11); SET return_value = 0; insert into institutes(id,name) values (null,''); select max(id) into return_value from institutes; RETURN return_value; END ;; DELIMITER ; -- ---------------------------- -- Function structure for `create_person` -- ---------------------------- DROP FUNCTION IF EXISTS `create_person`; DELIMITER ;; CREATE FUNCTION `create_person`() RETURNS int(11) BEGIN DECLARE return_value int(11); SET return_value = 0; insert into persons (id,name,surname) values (null,'',''); select max(id) into return_value from persons; RETURN return_value; END ;; DELIMITER ; -- ---------------------------- -- Function structure for `create_referral` -- ---------------------------- DROP FUNCTION IF EXISTS `create_referral`; DELIMITER ;; CREATE FUNCTION `create_referral`() RETURNS int(11) BEGIN DECLARE return_value int(11); SET return_value = 0; insert into referrals(id,name, url) values (null, '', ''); select max(id) into return_value from referrals; RETURN return_value; END ;; DELIMITER ; -- ---------------------------- -- Function structure for `update_person_cn` -- ---------------------------- DROP FUNCTION IF EXISTS `update_person_cn`; DELIMITER ;; CREATE FUNCTION `update_person_cn`(`input_value` varchar(255),`input_id` int(11)) RETURNS int(11) BEGIN #Routine body goes here... update persons set name = ( select case when position(' ' in input_value) = 0 then input_value else substr($1, 1, position(' ' in input_value) - 1) end ),surname = ( select case when position(' ' in input_value) = 0 then '' else substr(input_value, position(' ' in input_value) + 1) end ) where id = input_id; RETURN input_id; END ;; DELIMITER ;

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs