- openldap-bugs - openldap.org

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

This is a multi-part message in MIME format. --------------090902020105000306040907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> mattias(a)centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. Please see if the attached patch alters the behavior. 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/ --------------090902020105000306040907 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/overlays/rwm.c b/servers/slapd/overlays/rwm.c index 05cf98a..37e52cb 100644 --- a/servers/slapd/overlays/rwm.c +++ b/servers/slapd/overlays/rwm.c @@ -1277,7 +1277,7 @@ rwm_attrs( Operation *op, SlapReply *rs, Attribute** a_first, int stripEntryDN ) NULL ); if ( rc != LDAP_SUCCESS ) { - BER_BVZERO( &(*ap)->a_nvals[i] ); + ber_dupbv( &(*ap)->a_nvals[i], &(*ap)->a_vals[i] ); } } BER_BVZERO( &(*ap)->a_nvals[i] ); --------------090902020105000306040907--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> mattias(a)centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. The assertion leads me to believe that one of the values received from the remote server violated the attribute syntax, and so the value failed in the normalizer on the local slapd. What is the remote server? It's a bit strange that changing the configuration, but leaving the remote server unchanged, avoids the problem. > In any case, I have a different configuration now, that solves the problem > in another way (by using two separate local databases -- one for the > translucent overlay and one for the subordinate directory.) Another > problem with the previous configuration was that I was getting "user > modification of overlay database not permitted" errors when using > ldapadd/ldapmodify (seems the translucent overlay can not be stacked with > the rwm overlay.) > > Mattias -- -- 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#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 30 Jan '12

30 Jan '12

------------hvfQvbIMuXxQGZ2Ols8tGf Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu <hyc(a)symas.com> wrote: > mattias(a)centaurix.com wrote: >> Full_Name: Mattias Andersson >> Version: 2.4.25 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.182.107.220) > > Please provide a full gdb backtrace from the assertion failure. I've > reproduced this configuration locally but see no crash using ldapsearch. > I don't have the Softerra browser. Ok, see attachment. The problem is not reproducible with ldapsearch. >> This is a security vulnerability, since it would be enough to send an >> LDAP query >> to take down the server. > > We don't consider crashes/DOS to be a security vulnerability. A > vulnerability is anything which allows users to see information they > should not be allowed to see; in the case of a crash no information can > be retrieved so all data is completely secure. You're right, but it's a service vulnerability -- the server must be online in order for our users to be able to log in. In any case, I have a different configuration now, that solves the problem in another way (by using two separate local databases -- one for the translucent overlay and one for the subordinate directory.) Another problem with the previous configuration was that I was getting "user modification of overlay database not permitted" errors when using ldapadd/ldapmodify (seems the translucent overlay can not be stacked with the rwm overlay.) Mattias ------------hvfQvbIMuXxQGZ2Ols8tGf Content-Disposition: attachment; filename=gdb-slapd.txt Content-Type: text/plain; name="gdb-slapd.txt" Content-Transfer-Encoding: Quoted-Printable GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.= html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copyin= g" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. (gdb) handle SIG33 pass nostop noprint Signal Stop Print Pass to program Description SIG33 No No Yes Real-time event 33 (gdb) set pagination 0 (gdb) attach 4625 Attaching to process 4625 ptrace: No such process. (gdb) attach 4824 Attaching to process 4824 ptrace: No such process. (gdb) attach 4864 Attaching to process 4864 Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/deb= ug/usr/sbin/slapd...done. done. Reading symbols from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2...(no = debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 Reading symbols from /usr/lib/libslp.so.1...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/x86_64-linux-gnu/libsasl2.so.2...(no debug= ging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libsasl2.so.2 Reading symbols from /lib/x86_64-linux-gnu/libcrypt.so.1...(no debugging= symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcrypt.so.1 Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols found= )...done. Loaded symbols for /usr/lib/libltdl.so.7 Reading symbols from /lib/x86_64-linux-gnu/libwrap.so.0...(no debugging = symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libwrap.so.0 Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debuggi= ng symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f66e2c7d700 (LWP 4865)] Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging sym= bols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6 Reading symbols from /lib/x86_64-linux-gnu/libresolv.so.2...(no debuggin= g symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libresolv.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgnutls.so.26...(no deb= ugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgnutls.so.26 Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.11...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgcrypt.so.11 Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging s= ymbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1 Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging sy= mbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2 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 /usr/lib/x86_64-linux-gnu/libkrb5.so.3...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5.so.3 Reading symbols from /usr/lib/x86_64-linux-gnu/libk5crypto.so.3...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 Reading symbols from /lib/x86_64-linux-gnu/libcom_err.so.2...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcom_err.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libkrb5support.so.0...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 Reading symbols from /usr/lib/x86_64-linux-gnu/libtasn1.so.3...(no debug= ging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libtasn1.so.3 Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging sym= bols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libz.so.1 Reading symbols from /lib/x86_64-linux-gnu/libgpg-error.so.0...(no debug= ging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgpg-error.so.0 Reading symbols from /lib/x86_64-linux-gnu/libkeyutils.so.1...(no debugg= ing symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libkeyutils.so.1 Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debug= ging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...(no debugging symb= ols found)...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so...(no d= ebugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so...(= no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so...(= no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so Reading symbols from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0...(no debu= gging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so...(no = debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-5.1.so...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-5.1.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libplain.so...(no d= ebugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libplain.so Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols f= rom /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-4.8.so...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-4.8.so Reading symbols from /usr/lib/ldap/back_ldap-2.4.so.2...Reading symbols = from /usr/lib/debug/usr/lib/ldap/back_ldap-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_ldap-2.4.so.2 Reading symbols from /usr/lib/ldap/back_relay-2.4.so.2...Reading symbols= from /usr/lib/debug/usr/lib/ldap/back_relay-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_relay-2.4.so.2 Reading symbols from /usr/lib/ldap/translucent-2.4.so.2...Reading symbol= s from /usr/lib/debug/usr/lib/ldap/translucent-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/translucent-2.4.so.2 Reading symbols from /usr/lib/ldap/rwm-2.4.so.2...Reading symbols from /= usr/lib/debug/usr/lib/ldap/rwm-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/rwm-2.4.so.2 0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/libpthr= ead.so.0 (gdb) continue Continuing. [New Thread 0x7f66e247c700 (LWP 4874)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f66e247c700 (LWP 4874)] 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace full #0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li= bc.so.6 No symbol table info available. #3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a= 40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236 i =3D <optimized out> j =3D <optimized out> __PRETTY_FUNCTION__ =3D "attr_dup2" #4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build= d/openldap-2.4.25/servers/slapd/attr.c:279 i =3D <optimized out> tmp =3D 0x7f66e9a40db8 anew =3D 0x7f66e9a40e08 #5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x= 7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989= __PRETTY_FUNCTION__ =3D "entry_dup2" #6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f= 66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.= c:1493 on =3D 0x7f66e99b43c0 rwmap =3D <optimized out> e =3D 0x7f66e9a2cee8 dn =3D {bv_len =3D 0, bv_val =3D 0x0} ndn =3D {bv_len =3D 0, bv_val =3D 0x0} dc =3D {rwmap =3D 0x7f66e99b45a0, conn =3D 0x7f66e91dde50, ctx =3D= 0x7f66e33e5ec3 "searchEntryDN", rs =3D 0x0} rc =3D <optimized out> __PRETTY_FUNCTION__ =3D "rwm_send_entry" #7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:= 1735 on =3D <optimized out> rwmap =3D <optimized out> rc =3D <optimized out> #8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.= c:237 oi =3D <optimized out> on =3D 0x7f66e99b43c0 rc =3D 32768 be =3D 0x7f66e99b7340 db =3D {bd_info =3D 0x7f66e99b43c0, bd_self =3D 0x7f66e99b7340, = be_ctrls =3D "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times= >, "\001", be_flags =3D 257, be_restrictops =3D 0, be_requires =3D 0, be= _ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sas= l =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tl= s =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x= 7f66e99b4180, be_nsuffix =3D 0x7f66e99b41b0, be_schemadn =3D {bv_len =3D= 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be= _rootdn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0= , bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_= deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D 100, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0,= be_acl =3D 0x0, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D= 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7= f66e99d2850, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, = __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {= __prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, = __align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66= e3c160a0, be_private =3D 0x7f66e99b7500, be_next =3D {stqe_next =3D 0x0}= } #9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:= 505 sc_next =3D 0x0 sc_nextp =3D 0x7f66e247a690 rc =3D 32768 sc =3D 0x7f66e247a5e0 scp =3D 0x7f66e247a5e0 #10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r= s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul= t.c:997 berbuf =3D {buffer =3D "\230\244G\342f\177\000\000\222M\303\350f= \177\000\000x\n\244\351f\177\000\000 ", '\000' <repeats 15 times>, "\n\0= 23\000\000\000\000\000\000 `\260\351f\177\000\000\020\000\000\000f\177\0= 00\000\240\243G\342f\177\000\000\060\243G\342f\177\000\000d\001\000\000\= 000\000\000\000n\374\300\351f\177\000\000 \247c\351f\177\000\000{\001\00= 0\000\000\000\000\000=C8=A3G\342f\177\000\000\220\n\244\351f\177\000\000= \000\000\000\000\000\000\000\000P\374\300\351f\177\000\000S\374\300\351f= \177\000\000\000\000\000\000\000\000\000\000P\374\300\351f\177\000\000\2= 60]\260\351f\177\000\000\260]\260\351f\177\000\000p\271G\342f\177\000\00= 0\367\377\377\377\000\000\000\000\000u\233\351f\177\000\000\000\000\000\= 000\000\000\000\000\342/\346\350f\177\000\000\002\000\001\000\000\001\00= 0\000\000\000\000\000\000\000\000\000\202\001", '\000' <repeats 13 times= >, ialign =3D -498621288, lalign =3D 140079859737752, falign =3D -9.2069= 0575e+20, dalign =3D 6.9208646370683671e-310, palign =3D 0x7f66e247a498 = "\021"} ber =3D 0x7f66e247a2c0 a =3D <optimized out> i =3D <optimized out> j =3D <optimized out> rc =3D 0 bytes =3D <optimized out> userattrs =3D <optimized out> acl_state =3D {as_desc =3D 0x0, as_access =3D ACL_NONE, as_vd_ac= l =3D 0x0, as_vd_acl_present =3D 0, as_vd_acl_count =3D 0, as_vd_mask =3D= 1, as_result =3D -1, as_fe_done =3D 0} attrsonly =3D <optimized out> ad_entry =3D 0x7f66e995acc0 e_flags =3D 0x0 #11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o= ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/= search.c:335 ent =3D {e_id =3D 0, e_name =3D {bv_len =3D 17, bv_val =3D 0x7f6= 6e9b068f8 "dc=3Dchalmers,dc=3Dse"}, e_nname =3D {bv_len =3D 17, bv_val =3D= 0x7f66e9b06958 "dc=3Dchalmers,dc=3Dse"}, e_attrs =3D 0x7f66e9a407c8, e_= ocflags =3D 0, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x= 0} bdn =3D {bv_len =3D 17, bv_val =3D 0x7f66e9c0fc59 "dc=3Dchalmers= ,dc=3Dse"} li =3D <optimized out> lc =3D 0x7f66e9c06400 tv =3D {tv_sec =3D 0, tv_usec =3D 100000} stoptime =3D 1327979004 res =3D 0x7f66e9c0fa80 e =3D <optimized out> rc =3D 0 msgid =3D 2 match =3D {bv_len =3D 0, bv_val =3D 0x0} filter =3D {bv_len =3D 15, bv_val =3D 0x7f66e9b06680 "(objectCla= ss=3D*)"} i =3D <optimized out> attrs =3D <optimized out> freetext =3D 0 filter_undef =3D 0 do_retry =3D 0 dont_retry =3D 1 ctrls =3D 0x0 references =3D 0x0 __PRETTY_FUNCTION__ =3D "ldap_back_search" #12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/= translucent.c:1111 on =3D 0x7f66e99b7160 ov =3D 0x7f66e99b7340 cb =3D {sc_next =3D 0x7f66e247a690, sc_response =3D 0x7f66e35ebc= d0 <translucent_search_cb>, sc_cleanup =3D 0, sc_private =3D 0x7f66e247a= 5b0} tc =3D {db =3D 0x7f66e247a6b0, on =3D 0x7f66e99b7160, orig =3D 0= x7f66e9b06658, list =3D 0x0, step =3D 0, slimit =3D 100, attrs =3D 0x7f6= 6e9b066a0} fl =3D 0x0 fr =3D 0x0 fbv =3D <optimized out> rc =3D 0 #13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7= f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160= ) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659 func =3D 0x7f66e99b71b8 rc =3D 32768 #14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim= ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser= vers/slapd/backover.c:721 oi =3D <optimized out> on =3D <optimized out> be =3D 0x7f66e99b3f70 db =3D {bd_info =3D 0x7f66e99b7160, bd_self =3D 0x7f66e99b3f70, = be_ctrls =3D "\000", '\001' <repeats 15 times>, '\000' <repeats 16 times= >, be_flags =3D 275, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set= =3D {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0,= sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0,= sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x7f66e99b= 4180, be_nsuffix =3D 0x7f66e99b41b0, be_schemadn =3D {bv_len =3D 0, bv_v= al =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn = =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, bv_val= =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_deref_de= pth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms= _s_soft =3D 100, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D = 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl= =3D 0x0, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7f66e9= 9d27c0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __own= er =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__pre= v =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, __ali= gn =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66e39f3= 020, be_private =3D 0x7f66e99b4100, be_next =3D {stqe_next =3D 0x0}} cb =3D {sc_next =3D 0x0, sc_response =3D 0x7f66e935aa50 <over_ba= ck_response>, sc_cleanup =3D 0, sc_private =3D 0x7f66e99b41e0} sc =3D <optimized out> rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372 bd =3D 0x7f66e95f9a80 #16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24= 7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217 base =3D {bv_len =3D 17, bv_val =3D 0x7f66e9b05f9b "dc=3Dchalmer= s,dc=3Dse"} siz =3D 1 off =3D 0 i =3D <optimized out> #17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar= g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con= nection.c:1113 rc =3D 80 cancel =3D <optimized out> op =3D 0x7f66e9b06020 rs =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr= _err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrl= s =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x7f66e9a2cee8, r_attr= _flags =3D 17, r_operational_attrs =3D 0x7f66e9a40ac0, r_attrs =3D 0x7f6= 6e9b066a0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata = =3D 0x7f66e9a2cee8}, sru_extended =3D {r_rspoid =3D 0x7f66e9a2cee8 "", r= _rspdata =3D 0x11}}, sr_flags =3D 2} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D 0x7f66e91dde50 memctx =3D 0x7f66e9b05f50 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, = argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c= onnection.c:1249 rc =3D <optimized out> cri =3D {op =3D 0x7f66e9b06020, func =3D 0, arg =3D 0x0, ctx =3D= 0x7f66e247bb60, nullop =3D <optimized out>} s =3D <optimized out> #19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r= -2.4.so.2 No symbol table info available. #20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 No symbol table info available. #21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #22 0x0000000000000000 in ?? () No symbol table info available. (gdb) info registers rax 0x0 0 rbx 0x7fff061cce37 140733295939127 rcx 0xffffffffffffffff -1 rdx 0x6 6 rsi 0x130a 4874 rdi 0x1300 4864 rbp 0x7f66e7d591da 0x7f66e7d591da rsp 0x7f66e2479d28 0x7f66e2479d28 r8 0x7f66e247c700 140079859746560 r9 0x3c206a60206e6f69 4332579802623930217 r10 0x8 8 r11 0x206 518 r12 0xec 236 r13 0x7f66e9394c94 140079976238228 r14 0x7f66e9394ca1 140079976238241 r15 0x7f66e7d591da 140079952925146 rip 0x7f66e7c343a5 0x7f66e7c343a5 <raise+53> eflags 0x206 [ PF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/16i $pc =3D> 0x7f66e7c343a5 <raise+53>: cmp $0xfffffffffffff000,%rax 0x7f66e7c343ab <raise+59>: ja 0x7f66e7c343bf <raise+79> 0x7f66e7c343ad <raise+61>: repz retq = 0x7f66e7c343af <raise+63>: nop 0x7f66e7c343b0 <raise+64>: test %eax,%eax 0x7f66e7c343b2 <raise+66>: jg 0x7f66e7c34395 <raise+37> 0x7f66e7c343b4 <raise+68>: test $0x7fffffff,%eax 0x7f66e7c343b9 <raise+73>: je 0x7f66e7c343d0 <raise+96> 0x7f66e7c343bb <raise+75>: neg %eax 0x7f66e7c343bd <raise+77>: jmp 0x7f66e7c34395 <raise+37> 0x7f66e7c343bf <raise+79>: mov 0x361a52(%rip),%rdx # 0x7f66= e7f95e18 0x7f66e7c343c6 <raise+86>: neg %eax 0x7f66e7c343c8 <raise+88>: mov %eax,%fs:(%rdx) 0x7f66e7c343cb <raise+91>: or $0xffffffffffffffff,%rax 0x7f66e7c343cf <raise+95>: retq = 0x7f66e7c343d0 <raise+96>: mov %esi,%eax (gdb) thread apply all backtrace Thread 3 (Thread 0x7f66e247c700 (LWP 4874)): #0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li= bc.so.6 #3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a= 40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236 #4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build= d/openldap-2.4.25/servers/slapd/attr.c:279 #5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x= 7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989= #6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f= 66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.= c:1493 #7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:= 1735 #8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.= c:237 #9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:= 505 #10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r= s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul= t.c:997 #11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o= ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/= search.c:335 #12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/= translucent.c:1111 #13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7= f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160= ) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659 #14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim= ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser= vers/slapd/backover.c:721 #15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372 #16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24= 7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217 #17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar= g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con= nection.c:1113 #18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, = argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c= onnection.c:1249 #19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r= -2.4.so.2 #20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #22 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f66e2c7d700 (LWP 4865)): #0 0x00007f66e7cdfef3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.= so.6 #1 0x00007f66e92ea440 in slapd_daemon_task (ptr=3D<optimized out>) at /= build/buildd/openldap-2.4.25/servers/slapd/daemon.c:2528 #2 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #3 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f66e928d740 (LWP 4864)): #0 0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #1 0x00007f66e92ec9a2 in slapd_daemon () at /build/buildd/openldap-2.4.= 25/servers/slapd/daemon.c:2922 #2 0x00007f66e92d4013 in main (argc=3D3, argv=3D<optimized out>) at /bu= ild/buildd/openldap-2.4.25/servers/slapd/main.c:1008 (gdb) quit A debugging session is active. Inferior 1 [process 4864] will be detached. Quit anyway? (y or n) Quitting: Can't detach Thread 0x7f66e2c7d700 (LWP = 4865): No such process ------------hvfQvbIMuXxQGZ2Ols8tGf--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 30 Jan '12

30 Jan '12

mattias(a)centaurix.com wrote: > Full_Name: Mattias Andersson > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.182.107.220) Please provide a full gdb backtrace from the assertion failure. I've reproduced this configuration locally but see no crash using ldapsearch. I don't have the Softerra browser. > I have configured a proxy server using both the relay backend and the > translucent overlay: > > backend hdb > backend relay > > database hdb > directory /var/lib/ldap > suffix "dc=foo,dc=example,dc=com" > rootdn "cn=admin,dc=foo,dc=example,dc=com" > rootpw secret > index objectClass eq > > database relay > suffix "dc=example,dc=com" > overlay rwm > rwm-suffixmassage "dc=foo,dc=example,dc=com" > overlay translucent > uri ldap://ldap.example.com > > This configuration makes it possible for me to override attributes in the remote > ldap directory and at the same time extend the local directory with new entries. > This has been tested and works for authorization in a linux environment. > > If I issue an LDAP search query, as follows, > > ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 > > it will yield the following debug output: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=1000 op=2 UNBIND > conn=1000 fd=11 closed > > However, if I query the server using the Softerra LDAP Administrator software > (Windows), the slapd daemon crashes with an assertion error: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: > Assertion `j< i' failed. > Aborted > > This is a security vulnerability, since it would be enough to send an LDAP query > to take down the server. We don't consider crashes/DOS to be a security vulnerability. A vulnerability is anything which allows users to see information they should not be allowed to see; in the case of a crash no information can be retrieved so all data is completely secure. -- -- 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#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 29 Jan '12

29 Jan '12

Full_Name: Mattias Andersson Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.182.107.220) I have configured a proxy server using both the relay backend and the translucent overlay: backend hdb backend relay database hdb directory /var/lib/ldap suffix "dc=foo,dc=example,dc=com" rootdn "cn=admin,dc=foo,dc=example,dc=com" rootpw secret index objectClass eq database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=foo,dc=example,dc=com" overlay translucent uri ldap://ldap.example.com This configuration makes it possible for me to override attributes in the remote ldap directory and at the same time extend the local directory with new entries. This has been tested and works for authorization in a linux environment. If I issue an LDAP search query, as follows, ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 it will yield the following debug output: slapd starting conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND conn=1000 fd=11 closed However, if I query the server using the Softerra LDAP Administrator software (Windows), the slapd daemon crashes with an assertion error: slapd starting conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted This is a security vulnerability, since it would be enough to send an LDAP query to take down the server. Mattias

1 0

(ITS#7142) slapadd with tool-threads hangs on failure
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.28, master OS: Linux x86_64 URL: http://folk.uio.no/hbf/toobig.sh Submission from: (NULL) (195.1.106.125) Submitted by: hallvard slapadd hangs if bi_tool_entry_put() fails. Tested with back-ldif patched for bi_tool_entry_put() to return NOID after 6 entries, and on master with mdb and an LDIF > DB maxsize. Test program enclosed. Backtrace: Thread 2 (Thread 0x7fb3745fd700 (LWP 31479)): #0 0x000000371fc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000048acaf in getrec_thr (ctx=<value optimized out>) at slapadd.c:296 #2 0x000000371fc077f1 in start_thread () from /lib64/libpthread.so.0 Thread 1 (Thread 0x7fb37542e7c0 (LWP 31478)): #0 0x000000371fc0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000048a8e5 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:454 #2 0x0000000000406ea5 in main (argc=5, argv=<value optimized out>) at main.c:655 I don't want to touch that code, don't remember why nearby code uses ldap_pvt_tread_yield() instead of the clean way of having two conds (one for producer and one for consumer to wait for).

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 16:52:05 GMT, michael(a)stroeder.com wrote: > Hmm, it seems I get better result linking smbk5pwd with > contrib/slapd-modules/smbk5pwd/Makefile containing: > > LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs > -L../../../libraries/liblber/.libs > > instead of just > > LDAP_LIB=-lldap_r -llber > > Is that the right solution when rpath is already set when invoking > configure? If you build *and install* the rest of OpenLDAP first and then build smbk5pwd, I imagine it'll work fine if -L and -rpath are the same. Otherwise you should point -L at where all the libraries-to-be-installed are, which with a dynamic build is the .lib/ directories. After all -L is for build time and -rpath for runtime, and they should be set so that you build against the same libraries you will run with. At least I hope that's all. I wouldn't be surprised if some libtool magic introduces more complications:-( -- Hallvard

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

michael(a)stroeder.com wrote: > Uumpf! I forgot to update my local version of > > contrib/slapd-modules/smbk5pwd/Makefile > > after pulling from git. This Makefile does not use prefix and LDFLAGS used > with ./configure before. Hmm, it seems I get better result linking smbk5pwd with contrib/slapd-modules/smbk5pwd/Makefile containing: LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs -L../../../libraries/liblber/.libs instead of just LDAP_LIB=-lldap_r -llber Is that the right solution when rpath is already set when invoking configure? Ciao, Michael.

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

Hallvard B Furuseth wrote: > On Sat, 28 Jan 2012 15:10:24 GMT, michael(a)stroeder.com wrote: >> Core was generated by `/opt/openldap-RE24/libexec/slapd (...) >> (...) >> #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 > > Looks like slapd is linked to the wrong libldap_r, and you need > to configure with something like > > $ pr=/opt/openldap-RE24 > $ ./configure --prefix=$pr LDFLAGS="-L$pr/lib -Wl,-rpath,$pr/lib" Uumpf! I forgot to update my local version of contrib/slapd-modules/smbk5pwd/Makefile after pulling from git. This Makefile does not use prefix and LDFLAGS used with ./configure before. Please close this ITS. Ciao, Michael.

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 15:10:24 GMT, michael(a)stroeder.com wrote: > Core was generated by `/opt/openldap-RE24/libexec/slapd (...) > (...) > #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 Looks like slapd is linked to the wrong libldap_r, and you need to configure with something like $ pr=/opt/openldap-RE24 $ ./configure --prefix=$pr LDFLAGS="-L$pr/lib -Wl,-rpath,$pr/lib" -- Hallvard

1 0

(ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

Full_Name: Version: RE24 git a9b2c4fd2457fb502e9a2d47307e72ab2ec4b59d OS: openSUSE 11.4 x86_64 URL: Submission from: (NULL) (84.163.33.76) slapd was started with: -h "ldap://0.0.0.0:53123 ldapi://%2Ftmp%2Fopenldap-e2-infra-testbed" I can reproduce this always in a test bed but currently with a confidential customer configuration. Please request more information if really needed and I will try to provide a test config without confidential information. Core was generated by `/opt/openldap-RE24/libexec/slapd -d config,stats -h ldap://0.0.0.0:53123 ldapi:'. Program terminated with signal 11, Segmentation fault. #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) info threads * 1 Thread 20121 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 (gdb) thread 1 [Switching to thread 1 (Thread 20121)]#0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) bt full #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 ludp = 0x100000000 next = 0x7fc67d751040 #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #2 0x00007fc67d515b1f in ?? () from /usr/lib64/libldap_r-2.4.so.2 No symbol table info available. #3 0x00007fff849df338 in ?? () No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. (gdb) frame 0 #0 0x00007fc684f37cfb in ldap_free_urllist (ludlist=0x100000000) at url.c:1515 1515 next = ludp->lud_next; (gdb) info locals ludp = 0x100000000 next = 0x7fc67d751040

1 0

Re: (ITS#7140) mdb crash in slapadd(too large LDIF)
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 12:44:13 GMT, h.b.furuseth(a)usit.uio.no wrote: > The commit branches in mdb_tool_entry_<put,reindex> also reset > mdb->mi_attrs[*]->ai_cursor. Should the abort branches do the same? Also mdb_tool_entry_put() resets mdb_writes on commit but not abort. Relevant with slapadd -c, I suppose. mdb_tool_entry_reindex() never resets mdb_writes, so -q does not work. -- Hallvard

1 0

(ITS#7140) mdb crash in slapadd(too large LDIF)
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

Full_Name: Hallvard B Furuseth Version: RE24 OS: Linux x86_64 URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard When bumping into the database maxsize with slapadd: mdb_tool_entry_put() does not reset idcursor after mdb_txn_abort(), so idcursor gets closed twice and slapadd crashes. Blind fix: s/cursor = NULL;/idcursor = NULL;/ on tools.c line 684. This is what the mdb_txn_commit() branch does. The commit branches in mdb_tool_entry_<put,reindex> also reset mdb->mi_attrs[*]->ai_cursor. Should the abort branches do the same?

1 0

(ITS#7138) smbk5pwd: Fix uninitialized keys[1] in shadowLastChange
by fumiyas＠osstech.co.jp 27 Jan '12

27 Jan '12

Full_Name: SATOH Fumiyasu Version: 2.4.28 OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.28-smbk5pwd-fix-shadow-support… Submission from: (NULL) (220.100.28.128) slapd dies with the following message if "smbk5pwd-enable shadow" is set in slapd: mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed.

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by quanah＠zimbra.com 27 Jan '12

27 Jan '12

--On Friday, January 27, 2012 12:46 PM +0100 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> -R/opt/zimbra/openssl/lib > > FWIW: > Setting rpath with -R did not work for me on Linux. I had to use > -Wl,-rpath instead. I did not re-test recently though. It only works on older linux systems, some of which I still support. For me, newer ones ignore it and do the rest of the linking correctly. --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#7137) Wrong -R path for installed programs
by holm＠informatik.umu.se 27 Jan '12

27 Jan '12

--On 26 januari 2012 13.30.22 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > There is something wrong in what you're doing, I don't know where. I built using a > builddir (since I don't usually, but you did), and it worked correctly for me. I have found the problem! If you use --disable-static without using --enable-dynamic, the executables are dynamically linked BUT with the wrong rpath. In this case, I think configure should either quit with an error pointing out the contradiction OR link dynamically with the correct rpath. Thank You for your help in sorting this out! Regards, Åke Holmlund

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by michael＠stroeder.com 27 Jan '12

27 Jan '12

quanah(a)zimbra.com wrote: > -R/opt/zimbra/openssl/lib FWIW: Setting rpath with -R did not work for me on Linux. I had to use -Wl,-rpath instead. I did not re-test recently though. Ciao, Michael.

1 0

Re: (ITS#7137) Wrong -R path for installed programs
by quanah＠zimbra.com 26 Jan '12

26 Jan '12

--On Thursday, January 26, 2012 9:11 AM +0000 holm(a)informatik.umu.se wrote: > --On 25 januari 2012 13.47.34 -0800 Quanah Gibson-Mount > <quanah(a)zimbra.com> wrote: > I handle OpenLDAP the same way as all other software. This is basically > what I do: > > cd OpenLDAPsources > mkdir builddir > cd builddir > env CFLAGS="-O2" \ > ../configure \ > --prefix=/opt/OpenLDAP \ > --enable-shared \ > --disable-static \ > --sysconfdir=/var/conf \ > --localstatedir=/var/conf/openldap/var \ > --disable-hdb \ > --disable-monitor \ > --enable-rlookups \ > --enable-accesslog \ > --enable-modules > make > make install > > Everything is installed in the right place but the rpath is wrong. > One interesting thing. The executables are not created in the .libs > direcotrys and they are not relinked at install. The .libs directorys > are created but not used. The libraries, on the other hand, ARE > created in the .libs directorys and relinked at install time. There is something wrong in what you're doing, I don't know where. I built using a builddir (since I don't usually, but you did), and it worked correctly for me. Note that my dependancy libs are all also in their own dirs, so I have to specify how to link to them in configure/make, but I do not tell it where to link to for finding the OpenLDAP libs: LD_LIBRARY_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyru s-sasl/lib:/opt/zimbra/libtool/lib LDFLAGS="-L/opt/zimbra/openssl/lib -L/opt/zimbra/bdb/lib -L/opt/zimbra/cyrus-sasl/lib -L/opt/zimbra/libtool/lib -R/opt/zimbra/openssl/lib -R/opt/zimbra/bdb/lib -R/opt/zimbra/libtool/lib -R/opt/zimbra/cyrus-sasl/lib" CPPFLAGS="-I/opt/zimbra/bdb/include -I/opt/zimbra/cyrus-sasl/include -I/opt/zimbra/openssl/include -I/opt/zimbra/libtool/include" CFLAGS="-g -O0" ../configure --prefix=/opt/zimbra/openldap-2.4.28-linktest --with-cyrus-sasl --with-tls=openssl --enable-dynamic --enable-slapd --enable-modules --enable-backends=mod --disable-shell --disable-sql --disable-bdb --disable-ndb --enable-overlays=mod --enable-debug --enable-spasswd --enable-crypt LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make depend LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make -j2 LD_RUN_PATH=/opt/zimbra/openssl/lib:/opt/zimbra/bdb/lib:/opt/zimbra/cyrus-sasl/lib:/opt/zimbra/libtool/lib make prefix=/opt/zimbra/openldap-2.4.28-linktest install strip="" [build@zre-rhel6-64 builddir]$ cd /opt/zimbra/openldap-2.4.28-linktest/bin/ [build@zre-rhel6-64 bin]$ ldd ldapsearch linux-vdso.so.1 => (0x00007fffa99ff000) libldap-2.4.so.2 => /opt/zimbra/openldap-2.4.28-linktest/lib/libldap-2.4.so.2 (0x00007f780f6cd000) liblber-2.4.so.2 => /opt/zimbra/openldap-2.4.28-linktest/lib/liblber-2.4.so.2 (0x00007f780f4bc000) libsasl2.so.2 => /opt/zimbra/cyrus-sasl-2.1.25.4z/lib/libsasl2.so.2 (0x00007f780f2a1000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003000e00000) libssl.so.1.0.0 => /opt/zimbra/openssl/lib/libssl.so.1.0.0 (0x00007f780f03b000) libcrypto.so.1.0.0 => /opt/zimbra/openssl/lib/libcrypto.so.1.0.0 (0x00007f780ec8b000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003003e00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003003200000) libc.so.6 => /lib64/libc.so.6 (0x0000003001200000) /lib64/ld-linux-x86-64.so.2 (0x0000003000a00000) libfreebl3.so => /lib64/libfreebl3.so (0x0000003004200000) --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#7137) Wrong -R path for installed programs
by holm＠informatik.umu.se 26 Jan '12

26 Jan '12

--On 25 januari 2012 13.47.34 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, January 25, 2012 9:33 PM +0000 holm(a)informatik.umu.se wrote: > >> Full_Name: ?ke Holmlund >> Version: 2.4.28 >> OS: Solaris 10, Ubuntu 10.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:6b0:e:4a43::25) >> >> >> After compiling and installing OpenLDAP, the tools and servers are linked >> with the wrong library path. They use the libraries in the source tree >> instead of the installed libraries. > > It sounds to me like you failed to correctly set your paths etc while compiling and > installing then. I build OpenLDAP on some 20 different Linux distributions with a > large variety of gcc and kernel releases, and the RPATH always correct. I handle OpenLDAP the same way as all other software. This is basically what I do: cd OpenLDAPsources mkdir builddir cd builddir env CFLAGS="-O2" \ ../configure \ --prefix=/opt/OpenLDAP \ --enable-shared \ --disable-static \ --sysconfdir=/var/conf \ --localstatedir=/var/conf/openldap/var \ --disable-hdb \ --disable-monitor \ --enable-rlookups \ --enable-accesslog \ --enable-modules make make install Everything is installed in the right place but the rpath is wrong. One interesting thing. The executables are not created in the .libs direcotrys and they are not relinked at install. The .libs directorys are created but not used. The libraries, on the other hand, ARE created in the .libs directorys and relinked at install time. Regards, Åke Holmlund -------------------------------------------------------------------------- Åke Holmlund Phone: 090 - 786 57 16 Umeå University Fax: 090 - 786 65 50 Dept of Informatics Email: holm(a)informatik.umu.se 901 87 Umeå SWEDEN > > --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#7128 OpenLDAP for Win7 error
by hyc＠symas.com 25 Jan '12

25 Jan '12

The OpenLDAP Project has nothing to do with the file you referenced. Contact whoever created those binaries for assistance. This ITS will be closed. -- -- 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#7136) [PATCH] MozNSS: store TLS params until the deferred initialization is finished
by hyc＠symas.com 25 Jan '12

25 Jan '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120125-nss-params-deferred-init.p… > Submission from: (NULL) (209.132.186.34) > > > Deferred TLS initialization is used with Mozilla NSS. The real initialization > takes place when the TLS context is needed for the first time. If the > initialization parameters were freed immediately after tlsm_ctx_init was called, > they were not available at the time of deferred initialization which caused > segmentation fault. > > This situation happens e.g. with syncrepl. > > With this patch, initialization parameters are copied and stored until the > deferred initialization is finished. The parameters are freed afterwards. > > Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=783431 > > Patch uploaded. Thanks, committed to git master. > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat 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. -- -- 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#7135) [PATCH] MozNSS, PEM: fix segfault when TLS certificate key is not set
by hyc＠symas.com 25 Jan '12

25 Jan '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120125-nss-pem-segfault-tls-certk… > Submission from: (NULL) (209.132.186.34) > > > Slapd segfaults when PEM certificate is used with Mozilla NSS crypto backend and > olcTLSCertificateKeyFile is not set. > > Original report: https://bugzilla.redhat.com/show_bug.cgi?id=772890 > > Patch is uploaded. Thanks, committed to git master. > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat 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. -- -- 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#7137) Wrong -R path for installed programs
by quanah＠zimbra.com 25 Jan '12

25 Jan '12

--On Wednesday, January 25, 2012 9:33 PM +0000 holm(a)informatik.umu.se wrote: > Full_Name: ?ke Holmlund > Version: 2.4.28 > OS: Solaris 10, Ubuntu 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:6b0:e:4a43::25) > > > After compiling and installing OpenLDAP, the tools and servers are linked > with the wrong library path. They use the libraries in the source tree > instead of the installed libraries. It sounds to me like you failed to correctly set your paths etc while compiling and installing then. I build OpenLDAP on some 20 different Linux distributions with a large variety of gcc and kernel releases, and the RPATH always correct. --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#7137) Wrong -R path for installed programs
by holm＠informatik.umu.se 25 Jan '12

25 Jan '12

Full_Name: Åke Holmlund Version: 2.4.28 OS: Solaris 10, Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:6b0:e:4a43::25) After compiling and installing OpenLDAP, the tools and servers are linked with the wrong library path. They use the libraries in the source tree instead of the installed libraries. Example from Ubuntu: ldd ldapsearch linux-vdso.so.1 => (0x00007fffefd6a000) libldap-2.4.so.2 => /src/new/OpenLDAP/openldap-2.4.28/build-lnx/libraries/libldap/.libs/libldap-2.4.so.2 (0x00007f264082c000) liblber-2.4.so.2 => /src/new/OpenLDAP/openldap-2.4.28/build-lnx/libraries/liblber/.libs/liblber-2.4.so.2 (0x00007f264061c000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00007f26403e5000) libdl.so.2 => /lib/libdl.so.2 (0x00007f26401e1000) libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00007f263ff8e000) libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00007f263fbfe000) libresolv.so.2 => /lib/libresolv.so.2 (0x00007f263f9e5000) libc.so.6 => /lib/libc.so.6 (0x00007f263f661000) /lib64/ld-linux-x86-64.so.2 (0x00007f2640a77000) libz.so.1 => /lib/libz.so.1 (0x00007f263f44a000) Note that libldap and liblber in /src/new... are used instead of the libraries installed in /opt/OpenLDAP/lib. The same problem occurs in Solaris 10.

1 0

(ITS#7136) [PATCH] MozNSS: store TLS params until the deferred initialization is finished
by jvcelak＠redhat.com 25 Jan '12

25 Jan '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120125-nss-params-deferred-init.p… Submission from: (NULL) (209.132.186.34) Deferred TLS initialization is used with Mozilla NSS. The real initialization takes place when the TLS context is needed for the first time. If the initialization parameters were freed immediately after tlsm_ctx_init was called, they were not available at the time of deferred initialization which caused segmentation fault. This situation happens e.g. with syncrepl. With this patch, initialization parameters are copied and stored until the deferred initialization is finished. The parameters are freed afterwards. Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=783431 Patch uploaded. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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.

1 0

(ITS#7135) [PATCH] MozNSS, PEM: fix segfault when TLS certificate key is not set
by jvcelak＠redhat.com 25 Jan '12

25 Jan '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120125-nss-pem-segfault-tls-certk… Submission from: (NULL) (209.132.186.34) Slapd segfaults when PEM certificate is used with Mozilla NSS crypto backend and olcTLSCertificateKeyFile is not set. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=772890 Patch is uploaded. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat 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.

1 0

Re: (ITS#7134) Referential Integrity implement in LDAP
by quanah＠zimbra.com 24 Jan '12

24 Jan '12

--On Wednesday, January 25, 2012 6:11 AM +0000 jasminindia(a)gmail.com wrote: > Full_Name: Crack Jack > Version: 2.4.28 > OS: Red Hat > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (174.26.62.117) > > > we have two separate nodes called Roles and Permission. Roles contains > set of permissions. > How we can define relationship between Roles and permissions? > In case if delete permissions than Role must be deleted. > I referred openLDAP document but no more information. I heard about > "alias". will that help for referential integrity? The ITS system is for reporting bugs, not for asking usage questions. This ITS will be closed. If you have questions about how to use and configure OpenLDAP, then submit them to the openldap-technical(a)openldap.org mailing list. --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#7134) Referential Integrity implement in LDAP
by jasminindia＠gmail.com 24 Jan '12

24 Jan '12

Full_Name: Crack Jack Version: 2.4.28 OS: Red Hat URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (174.26.62.117) we have two seperate nodes called Roles and Permission. Roles contains set of permissions. How we can define relationship between Roles and permissions? In case if delete permissions than Role must be deleted. I referred openLDAP document but no more information. I heard about "alias". will that help for referential integrity?

1 0

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by quanah＠zimbra.com 24 Jan '12

24 Jan '12

--On Tuesday, January 24, 2012 11:50 PM +0000 dpmcgee(a)gmail.com wrote: > On Tue, Jan 24, 2012 at 5:46 PM, Howard Chu <hyc(a)symas.com> wrote: >> Dan McGee wrote: >>> >>> On Tue, Jan 24, 2012 at 3:38 PM, Howard Chu<hyc(a)symas.com> ??wrote: >>>> >>>> dpmcgee(a)gmail.com wrote: >>>>> >>>>> >>>>> Full_Name: Dan McGee >>>>> Version: 2.4.28 >>>>> OS: Arch Linux, 3.0.2 kernel >>>>> URL: >>>>> Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) >>>>> >>>>> >>>>> Running the test suite looks like a disaster because every time the >>>>> test server >>>>> is killed you see lines like this (probably 1409 times for every >>>>> single test, >>>>> who knows): >>>> >>>> >>>> >>>> Sounds like this is a dup of ITS#7118. A potential fix has been >>>> committed to >>>> git master; you should recompile both libldap and libldap_r with the >>>> patch >>>> to verify if the fix is effective. Please test and report back, thanks. >>> >>> >>> Appears to address the problem. The test suite is running without >>> errors at the moment. Thanks for the quick response! >> >> >> Thanks for verifying. Unfortunately, the previous patch was incomplete >> (and would break init.c on some non-Linux platforms). A new patch is now >> in git, if you could test again, thanks. > > Can you please give links to patches, or at least commit IDs? Your > directions are quite vague, as I only see one patch in git that > matches "7118" when searched for > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git&a=search&h=HEAD& > st=commit&s=7118). If > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=270ef33 > acf18dc13bfd07f8a8e66b446f80e7d27 is not what I should be testing, please > let me know. >From <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=summary>: 10 min ago Howard ChuCleanup gssapi_flags -> ldo_gssapi_flags master commit | commitdiff | tree | snapshot 11 min ago Howard ChuMore for prev commit (270ef33acf18dc13bfd07f8a8e66b446f... commit | commitdiff | tree | snapshot 2 hours ago Howard ChuITS#7118, #7133 tentative fix commit | commitdiff | tree | snapshot -- 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#7133) slapd dies with SIGSEGV on SIGHUP
by hyc＠symas.com 24 Jan '12

24 Jan '12

Dan McGee wrote: > On Tue, Jan 24, 2012 at 5:46 PM, Howard Chu<hyc(a)symas.com> wrote: >> Thanks for verifying. Unfortunately, the previous patch was incomplete (and >> would break init.c on some non-Linux platforms). A new patch is now in git, >> if you could test again, thanks. > > Can you please give links to patches, or at least commit IDs? Your > directions are quite vague, as I only see one patch in git that > matches "7118" when searched for > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git&a=search&h=HEAD&st=…). > If http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=270ef33ac… > is not what I should be testing, please let me know. Ah sorry, it's this: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=7ff18967… -- -- 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#7133) slapd dies with SIGSEGV on SIGHUP
by dpmcgee＠gmail.com 24 Jan '12

24 Jan '12

On Tue, Jan 24, 2012 at 5:46 PM, Howard Chu <hyc(a)symas.com> wrote: > Dan McGee wrote: >> >> On Tue, Jan 24, 2012 at 3:38 PM, Howard Chu<hyc(a)symas.com> wrote: >>> >>> dpmcgee(a)gmail.com wrote: >>>> >>>> >>>> Full_Name: Dan McGee >>>> Version: 2.4.28 >>>> OS: Arch Linux, 3.0.2 kernel >>>> URL: >>>> Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) >>>> >>>> >>>> Running the test suite looks like a disaster because every time the test >>>> server >>>> is killed you see lines like this (probably 1409 times for every single >>>> test, >>>> who knows): >>> >>> >>> >>> Sounds like this is a dup of ITS#7118. A potential fix has been committed >>> to >>> git master; you should recompile both libldap and libldap_r with the >>> patch >>> to verify if the fix is effective. Please test and report back, thanks. >> >> >> Appears to address the problem. The test suite is running without >> errors at the moment. Thanks for the quick response! > > > Thanks for verifying. Unfortunately, the previous patch was incomplete (and > would break init.c on some non-Linux platforms). A new patch is now in git, > if you could test again, thanks. Can you please give links to patches, or at least commit IDs? Your directions are quite vague, as I only see one patch in git that matches "7118" when searched for (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git&a=search&h=HEAD&st=…). If http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=270ef33ac… is not what I should be testing, please let me know. -Dan

1 0

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by hyc＠symas.com 24 Jan '12

24 Jan '12

Dan McGee wrote: > On Tue, Jan 24, 2012 at 3:38 PM, Howard Chu<hyc(a)symas.com> wrote: >> dpmcgee(a)gmail.com wrote: >>> >>> Full_Name: Dan McGee >>> Version: 2.4.28 >>> OS: Arch Linux, 3.0.2 kernel >>> URL: >>> Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) >>> >>> >>> Running the test suite looks like a disaster because every time the test >>> server >>> is killed you see lines like this (probably 1409 times for every single >>> test, >>> who knows): >> >> >> Sounds like this is a dup of ITS#7118. A potential fix has been committed to >> git master; you should recompile both libldap and libldap_r with the patch >> to verify if the fix is effective. Please test and report back, thanks. > > Appears to address the problem. The test suite is running without > errors at the moment. Thanks for the quick response! Thanks for verifying. Unfortunately, the previous patch was incomplete (and would break init.c on some non-Linux platforms). A new patch is now in git, if you could test again, 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

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by dpmcgee＠gmail.com 24 Jan '12

24 Jan '12

On Tue, Jan 24, 2012 at 3:38 PM, Howard Chu <hyc(a)symas.com> wrote: > dpmcgee(a)gmail.com wrote: >> >> Full_Name: Dan McGee >> Version: 2.4.28 >> OS: Arch Linux, 3.0.2 kernel >> URL: >> Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) >> >> >> Running the test suite looks like a disaster because every time the test >> server >> is killed you see lines like this (probably 1409 times for every single >> test, >> who knows): > > > Sounds like this is a dup of ITS#7118. A potential fix has been committed to > git master; you should recompile both libldap and libldap_r with the patch > to verify if the fix is effective. Please test and report back, thanks. Appears to address the problem. The test suite is running without errors at the moment. Thanks for the quick response! -Dan

1 0

Re: (ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 24 Jan '12

24 Jan '12

This might be a dup of ITS#7113.

1 0

Re: (ITS#7118) [PATCH] Improve SASL plugin handling
by hyc＠symas.com 24 Jan '12

24 Jan '12

thomas(a)koeller.dyndns.org wrote: > That is certainly true, however, it misses the point I am trying to make. > I want to provide a fix for the problem I encountered. > >> From a user's perspective, it is certainly preferable for the whole thing > to 'just work', instead of being provided with instructions about how to > configure one's system to avoid problems that arise when using the standard > configuration. This places the burden on the user, for no other gain than > being able to load a module that cannot be used anyway. With the change I > proposed, slapd can work with every standard cyrus-sasl installation right > away, no special configuration required, and the problem is solved once > and forever. Unfortunately, your approach *doesn't* fix the problem once and forever. It's testing for a hardcoded library name. The approach is obviously doomed, since library names are highly platform-dependent, and it doesn't address the possibility that some other plugin will show up in the future with the same linkage issues. I've committed a change to the struct layout, in git master, which might solve the problem. (See ITS#7133 also). Please test and report back, 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

Re: (ITS#7133) slapd dies with SIGSEGV on SIGHUP
by hyc＠symas.com 24 Jan '12

24 Jan '12

dpmcgee(a)gmail.com wrote: > Full_Name: Dan McGee > Version: 2.4.28 > OS: Arch Linux, 3.0.2 kernel > URL: > Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) > > > Running the test suite looks like a disaster because every time the test server > is killed you see lines like this (probably 1409 times for every single test, > who knows): Sounds like this is a dup of ITS#7118. A potential fix has been committed to git master; you should recompile both libldap and libldap_r with the patch to verify if the fix is effective. Please test and report back, thanks. > > >>>>>> Test succeeded > ./scripts/test000-rootdse: line 84: 3589 Segmentation fault $SLAPD -f > $CONF1 -h $URI1 -d $LVL $TIMING> $LOG1 2>&1 >>>>>> test000-rootdse completed OK for bdb. > > > Here is a GDB backtrace of that: > > > Program received signal SIGHUP, Hangup. > 0x00007f6a3727306f in pthread_join () from /lib/libpthread.so.0 > (gdb) c > Continuing. > [Thread 0x7f6a32e0c700 (LWP 2789) exited] > [Thread 0x7f6a3260b700 (LWP 2804) exited] > > Program received signal SIGSEGV, Segmentation fault. > 0x00007f6a36f42a84 in free () from /lib/libc.so.6 > (gdb) bt > #0 0x00007f6a36f42a84 in free () from /lib/libc.so.6 > #1 0x00007f6a3440f320 in ?? () from /usr/lib/libldap-2.4.so.2 > #2 0x00007f6a3850a0b8 in _dl_close_worker () from /lib/ld-linux-x86-64.so.2 > #3 0x00007f6a3850ab4c in _dl_close () from /lib/ld-linux-x86-64.so.2 > #4 0x00007f6a385052a6 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2 > #5 0x00007f6a360884cf in ?? () from /lib/libdl.so.2 > #6 0x00007f6a3608800f in dlclose () from /lib/libdl.so.2 > #7 0x00007f6a376d13a4 in _sasl_done_with_plugins () > from /usr/lib/libsasl2.so.2 > #8 0x00007f6a376c935b in sasl_done () from /usr/lib/libsasl2.so.2 > #9 0x0000000000481fc9 in slap_sasl_destroy () > #10 0x000000000045f108 in slap_destroy () > #11 0x00000000004195b9 in main () > > > And given that there is SASL stuff in the backtrace, this machine is running > libsasl 2.1.23. > > -- -- 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#7133) slapd dies with SIGSEGV on SIGHUP
by dpmcgee＠gmail.com 24 Jan '12

24 Jan '12

A paste of a snippet of the test log showing the scary looking but mostly harmless output: http://paste.pocoo.org/show/540176/

1 0

(ITS#7133) slapd dies with SIGSEGV on SIGHUP
by dpmcgee＠gmail.com 24 Jan '12

24 Jan '12

Full_Name: Dan McGee Version: 2.4.28 OS: Arch Linux, 3.0.2 kernel URL: Submission from: (NULL) (2002:47c2:29f0:1:21f:d0ff:fea2:ee12) Running the test suite looks like a disaster because every time the test server is killed you see lines like this (probably 1409 times for every single test, who knows): >>>>> Test succeeded ./scripts/test000-rootdse: line 84: 3589 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 >>>>> test000-rootdse completed OK for bdb. Here is a GDB backtrace of that: Program received signal SIGHUP, Hangup. 0x00007f6a3727306f in pthread_join () from /lib/libpthread.so.0 (gdb) c Continuing. [Thread 0x7f6a32e0c700 (LWP 2789) exited] [Thread 0x7f6a3260b700 (LWP 2804) exited] Program received signal SIGSEGV, Segmentation fault. 0x00007f6a36f42a84 in free () from /lib/libc.so.6 (gdb) bt #0 0x00007f6a36f42a84 in free () from /lib/libc.so.6 #1 0x00007f6a3440f320 in ?? () from /usr/lib/libldap-2.4.so.2 #2 0x00007f6a3850a0b8 in _dl_close_worker () from /lib/ld-linux-x86-64.so.2 #3 0x00007f6a3850ab4c in _dl_close () from /lib/ld-linux-x86-64.so.2 #4 0x00007f6a385052a6 in _dl_catch_error () from /lib/ld-linux-x86-64.so.2 #5 0x00007f6a360884cf in ?? () from /lib/libdl.so.2 #6 0x00007f6a3608800f in dlclose () from /lib/libdl.so.2 #7 0x00007f6a376d13a4 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 #8 0x00007f6a376c935b in sasl_done () from /usr/lib/libsasl2.so.2 #9 0x0000000000481fc9 in slap_sasl_destroy () #10 0x000000000045f108 in slap_destroy () #11 0x00000000004195b9 in main () And given that there is SASL stuff in the backtrace, this machine is running libsasl 2.1.23.

1 0

(ITS#7132) syncrepl uses freed naming attrs
by h.b.furuseth＠usit.uio.no 24 Jan '12

24 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.28, master OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard syncrepl_entry() reads naming attrs in an entry saved by dn_callback() in an internal search, after the search returned and released the entry. Found with valgrind and -DSLAP_NO_SL_MALLOC in test017 with mdb. Fixing.

1 0

(ITS#7131) Wrong integer types for connection loops
by h.b.furuseth＠usit.uio.no 23 Jan '12

23 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.28, master OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard connection_<first,next,done>() expect a ber_socket_t*connindex, but the callers pass an int*. Fixing.

1 0

Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by masarati＠aero.polimi.it 23 Jan '12

23 Jan '12

> Full_Name: Manny > Version: 2.4.23 > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.171.77.1) > > > Hi there. > > I'm posting this into the ITS as I didn't get a response on the mailing > list > after 1 week. > > I'm using the latest stable release of openldap, with back-sql and > postgresql as a backend. > I have an sssd which uses this openldap server for ID providing and > authentication. > A recent update in this sssd changed the filter used to retrieve > groupids of users, which surfaced what seems to be a bug in backsql. > >>From my investigation it seems to me that when constructing the search > query, openldap tries to use the UPPER function on every criteria in > the WHERE clause, no matter which type it is. This causes an error in > postgresql, as the gidNumber that is supposed to be filtered is of > type "bigint". I don't recall seeing your message in openldap-technical, which it belongs to. In any case, there should be a field in ldap_at_mappings that tells how and when an attribute value needs to be uppercased. However, I can't check right now whether it works as intended, and back-sql is unmaintained. p.

1 0

(ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac＠gmail.com 23 Jan '12

23 Jan '12

Full_Name: Manny Version: 2.4.23 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.171.77.1) Hi there. I'm posting this into the ITS as I didn't get a response on the mailing list after 1 week. I'm using the latest stable release of openldap, with back-sql and postgresql as a backend. I have an sssd which uses this openldap server for ID providing and authentication. A recent update in this sssd changed the filter used to retrieve groupids of users, which surfaced what seems to be a bug in backsql. >From my investigation it seems to me that when constructing the search query, openldap tries to use the UPPER function on every criteria in the WHERE clause, no matter which type it is. This causes an error in postgresql, as the gidNumber that is supposed to be filtered is of type "bigint". I could simply remove "upper_func" from my slapd.conf, but I need it for other queries. Changing the field gidNumber in the database to text would also be a workaround, but I'd rather prefer this fixed in backsql. Anyways, here is the important part of my slapd.conf: #----------------------------------------------- database sql suffix "dc=mydomain,dc=at" rootdn "cn=Manager,dc=mydomain,dc=at" rootpw mysecret dbname mydbname dbuser mydbuser dbpasswd myuserpw subtree_cond "UPPER(ldap_entries.dn) LIKE UPPER('%'||?)" insentry_stmt "insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)" upper_func "upper" upper_needs_cast "yes" strcast_func "text" concat_pattern "?||?" has_ldapinfo_dn_ru no sizelimit -1 #----------------------------------------------- The error can be reproduced in my case when running this command: #----------------------------------------------- ldapsearch -H ldaps://127.0.0.1/ -b ou=groups,ou=myserver,dc=mydomain,dc=at -D "uid=myuser,ou=users,ou=myserver,dc=mydomain,DC=at" '(gidNumber=512)' -W #----------------------------------------------- Which results in this output: #----------------------------------------------- # extended LDIF # # LDAPv3 # base <ou=groups,ou=myserver,dc=mydomain,dc=at> with scope subtree # filter: (gidNumber=512) # requesting: ALL # # search result search: 2 result: 80 Other (e.g., implementation specific) error #----------------------------------------------- Here is the interesting part of the level 255 log output: #----------------------------------------------- <==backsql_oc_get_candidates(): 0 ==>backsql_oc_get_candidates(): oc="sambaDomain" ==>backsql_srch_query() ==>backsql_process_filter() <==backsql_process_filter() succeeded <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap WHERE samba_domain_ldap.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND 7=7 Constructed query: SELECT DISTINCT ldap_entries.id,samba_domain_ldap.id,text('sambaDomain') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,samba_domain_ldap WHERE samba_domain_ldap.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND 7=7 id: '6' (sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT" <==backsql_oc_get_candidates(): 0 ==>backsql_oc_get_candidates(): oc="inetOrgPerson" ==>backsql_srch_query() ==>backsql_process_filter() ==>backsql_process_filter_attr(gidNumber) <==backsql_process_filter_attr(gidNumber) <==backsql_process_filter() succeeded <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND (upper(OS_USER.gidnumber)='512') Constructed query: SELECT DISTINCT ldap_entries.id,OS_USER.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,OS_USER WHERE OS_USER.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND UPPER(ldap_entries.dn) LIKE UPPER('%'||?) AND (upper(OS_USER.gidnumber)='512') id: '8' (sub)dn: "%OU=GROUPS,OU=MYSERVER,DC=MYDOMAIN,DC=AT" backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: function upper(bigint) does not exist at character 288;#012Error while executing the query" #----------------------------------------------- Thanks a lot

1 0

Re: (ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by hyc＠symas.com 21 Jan '12

21 Jan '12

kacarstensen(a)csupomona.edu wrote: > I've investigated this issue a little bit more since my initial bug > report. > I'm not sure if connection_write is supposed to validate that a stream > is active before or after calling slapd_clr_write, but it seems like the > assertion wouldn't be an issue if that validation were performed before > calling slapd_clr_write. To test this thought, I rebuilt openldap 2.4.28 > with the following patch: > > --- openldap-2.4.28/servers/slapd/connection.c 2011-11-25 10:52:29.000000000 -0800 > +++ openldap-2.4.28-new/servers/slapd/connection.c 2012-01-12 13:35:45.000000000 -0800 > @@ -1893,8 +1893,6 @@ > > assert( connections != NULL ); > > - slapd_clr_write( s, 0 ); > - > c = connection_get( s ); > if( c == NULL ) { > Debug( LDAP_DEBUG_ANY, > @@ -1903,6 +1901,8 @@ > return -1; > } > > + slapd_clr_write( s, 0 ); > + > #ifdef HAVE_TLS > if ( c->c_is_tls&& c->c_needs_tls_accept ) { > connection_return( c ); > > and tried to reproduce the problem under the same circumstances as > reported in my initial bug report. The master slapd tolerated the > misconfigured replicas for 5 days without crashing; before, it would > crash reliably within a half hour or so. I didn't notice any regressions > due to the patch, though the master slapd wasn't exposed to a typical > workload during the experiment. > > Any thoughts on this patch? Sounds OK to me, committed to git master. 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#7129) slapo-valsort(5) missing description of LDAP_CONTROL_VALSORT
by quanah＠OpenLDAP.org 20 Jan '12

20 Jan '12

Full_Name: Version: 2.4.28 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) While the slapo-valsort manual page describes the ways in which data can be sorted and displayed, it does not note the fact that there is a control that can be used to disable it from applying to a search result: LDAP_CONTROL_VALSORT This is useful information for people wishing to use the overlay.

1 0

Re: (ITS#7127) Syncrepl config uses freed data
by hyc＠symas.com 19 Jan '12

19 Jan '12

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.21++, master > OS: > URL: > Submission from: (NULL) (195.1.106.125) > Submitted by: hallvard > > > In syncrepl_config(), ldap_pvt_runqueue_remove() frees 're', > then the retract statement reads 're->routine': > > ldap_pvt_runqueue_remove(&slapd_rq, re ); > ldap_pvt_thread_mutex_unlock(&slapd_rq.rq_mutex ); > if ( ldap_pvt_thread_pool_retract(&connection_pool, > re->routine, re )> 0 ) > > Formally I think the pointer 're' itself is invalid after freeing it, > so the ISO C-clean fix would involve calling retract() first. If > that's wrong: I assume the thread pool is paused at this point, so > the task can not be started (and use re) before it can be retracted, > and we can just just read re->routine before freeing re. Makes sense. Fixed in master. > > Found by Valgrind in test063-delta-multimaster. -- -- 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#7127) Syncrepl config uses freed data
by h.b.furuseth＠usit.uio.no 19 Jan '12

19 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.21++, master OS: URL: Submission from: (NULL) (195.1.106.125) Submitted by: hallvard In syncrepl_config(), ldap_pvt_runqueue_remove() frees 're', then the retract statement reads 're->routine': ldap_pvt_runqueue_remove( &slapd_rq, re ); ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); if ( ldap_pvt_thread_pool_retract( &connection_pool, re->routine, re ) > 0 ) Formally I think the pointer 're' itself is invalid after freeing it, so the ISO C-clean fix would involve calling retract() first. If that's wrong: I assume the thread pool is paused at this point, so the task can not be started (and use re) before it can be retracted, and we can just just read re->routine before freeing re. Found by Valgrind in test063-delta-multimaster.

1 0

Re: (ITS#7113) broken read-only replica results in assertion failure and crash on master slapd process
by kacarstensen＠csupomona.edu 17 Jan '12

17 Jan '12

I've investigated this issue a little bit more since my initial bug report. With loglevel conns sync in slapd.conf, the following are the last messages written to the log before slapd crashes: Jan 12 09:33:19 shelley slapd[2482]: Jan 12 09:33:19 shelley slapd[2482]: daemon: write active on 15 Jan 12 09:33:19 shelley slapd[2482]: daemon: epoll: listen=9 active_threads=0 tvp=zero Jan 12 09:33:19 shelley slapd[2482]: daemon: epoll: listen=10 active_threads=0 tvp=zero Jan 12 09:33:19 shelley slapd[2482]: daemon: activity on 1 descriptor Jan 12 09:33:19 shelley slapd[2482]: daemon: activity on: Jan 12 09:33:19 shelley slapd[2482]: 15rw Jan 12 09:33:19 shelley slapd[2482]: ber_flush2 failed errno=32 reason="Broken pipe" Jan 12 09:33:19 shelley slapd[2482]: connection_closing: readying conn=1377 sd=15 for close Jan 12 09:33:19 shelley slapd[2482]: send_search_entry: conn 1377 ber write failed. Jan 12 09:33:19 shelley slapd[2482]: connection_resched: attempting closing conn=1377 sd=15 Jan 12 09:33:19 shelley slapd[2482]: daemon: removing 15 Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: connection_get(15): connection not used Jan 12 09:33:19 shelley slapd[2482]: connection_read(15): no connection! Jan 12 09:33:19 shelley slapd[2482]: connection_read(15) error Jan 12 09:33:19 shelley slapd[2482]: Jan 12 09:33:19 shelley slapd[2482]: daemon: write active on 15 "daemon: write active on 15" comes from line 2660 or so of daemon.c. Here's that with some context: for ( i = 0; nwfds > 0; i++ ) { ber_socket_t wd; if ( ! SLAP_EVENT_IS_WRITE( i ) ) continue; wd = i; SLAP_EVENT_CLR_WRITE( wd ); nwfds--; Debug(LDAP_DEBUG_CONNS, "daemon: write active on %d\n", wd, 0, 0); /* * NOTE: it is possible that the connection was closed and that * the stream is now inactive. connection_write() must validate * the stream is still active. * * ITS#4338: if the stream is invalid, there is no need to close it * here. It has already been closed in connection.c. */ if ( connection_write( wd ) < 0 ) { if ( SLAP_EVENT_IS_READ( wd)) { SLAP_EVENT_CLR_READ( (unsigned) wd); nrfds--; } } } We do some housekeeping on the descriptor, then call connection_write to take care of the write. Here's connection_write from connection.c: int connection_write(ber_socket_t s) { Connection *c; Operation *op; assert( connections != NULL ); slapd_clr_write( s, 0 ); c = connection_get( s ); if( c == NULL ) { Debug( LDAP_DEBUG_ANY, "connection_write(%ld): no connection!\n", (long)s, 0, 0 ); return -1; } [...] connection_get seems to perform the validation that is mentioned by the comment in daemon.c, but connection_get is called after slapd_clr_write, which is the source of the assertion implicated by the backtrace in the initial bug report: void slapd_clr_write( ber_socket_t s, int wake ) { int id = DAEMON_ID(s); ldap_pvt_thread_mutex_lock( &slap_daemon[id].sd_mutex ); if ( SLAP_SOCK_IS_WRITE( id, s )) { assert( SLAP_SOCK_IS_ACTIVE( id, s )); SLAP_SOCK_CLR_WRITE( id, s ); slap_daemon[id].sd_nwriters--; } ldap_pvt_thread_mutex_unlock( &slap_daemon[id].sd_mutex ); WAKE_LISTENER(id,wake); } I'm not sure if connection_write is supposed to validate that a stream is active before or after calling slapd_clr_write, but it seems like the assertion wouldn't be an issue if that validation were performed before calling slapd_clr_write. To test this thought, I rebuilt openldap 2.4.28 with the following patch: --- openldap-2.4.28/servers/slapd/connection.c 2011-11-25 10:52:29.000000000 -0800 +++ openldap-2.4.28-new/servers/slapd/connection.c 2012-01-12 13:35:45.000000000 -0800 @@ -1893,8 +1893,6 @@ assert( connections != NULL ); - slapd_clr_write( s, 0 ); - c = connection_get( s ); if( c == NULL ) { Debug( LDAP_DEBUG_ANY, @@ -1903,6 +1901,8 @@ return -1; } + slapd_clr_write( s, 0 ); + #ifdef HAVE_TLS if ( c->c_is_tls && c->c_needs_tls_accept ) { connection_return( c ); and tried to reproduce the problem under the same circumstances as reported in my initial bug report. The master slapd tolerated the misconfigured replicas for 5 days without crashing; before, it would crash reliably within a half hour or so. I didn't notice any regressions due to the patch, though the master slapd wasn't exposed to a typical workload during the experiment. Any thoughts on this patch? -- Kevan Carstensen <kacarstensen(a)csupomona.edu> Operating Systems Analyst, I&IT Systems, Cal Poly Pomona

1 0

RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 14 Jan '12

14 Jan '12

--_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBIb3dhcmQsDQoNCk5pY2UgdG8ga25vdyB5b3XimLoNCldvdWxkIHlvdSB0ZWxsIG1lIHdo byBJIGNhbiBjb250YWN0IHRvIGdldCB0aGlzIHJvYWRtYXAgaW5mb3JtYXRpb24gb2YgT3BlbkxE QVAgZGlyZWN0b3J5IHNlcnZlciBpbiAyMDEyPw0KVGhhbmtzIGluIGFkdmFuY2UuDQoNCkJlc3Qg cmVnYXJkcywNCkhlbnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dh cmQgQ2h1IFttYWlsdG86aHljQHN5bWFzLmNvbV0NClNlbnQ6IDIwMTLlubQx5pyIMTTml6UgMTg6 MzcNClRvOiBRaW5neXVuIFpodQ0KQ2M6IG9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmcNClN1Ympl Y3Q6IFJlOiAoSVRTIzcxMjQpIENvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9hZG1h cCBvZiBPcGVuTERBUCBkaXJlY3Rvcnkgc2VydmVyIGZvciAyMDEyPw0KDQpxemh1QHRpYmNvLXN1 cHBvcnQuY29tIHdyb3RlOg0KPiBIZWxsbywgVGVhbSwNCj4NCj4gU29ycnkgdG8gZGlzdHVyYiB5 b3UsIGhvd2V2ZXIsIGl0IGlzIHVyZ2VudCBmb3IgdXMgdG8ga25vdyB0aGUgcm9hZG1hcCBvZiBP cGVuTERBUCBEaXJlY3RvcnkgU2VydmVyIHNvZnR3YXJlIGluIDIwMTIuIE1lYW53aGlsZSwgSSB0 aGluayB0aGF0IGl0IGlzIGFsc28gaGVscGZ1bCB0byB5b3VyIHByb2R1Y3QuIEkgbG9vayBmb3J3 YXJkcyB0byB5b3VyIHF1aWNrIHJlc3BvbnNlLiBJdCBpcyBmaW5lIHRoYXQgeW91IGNhbiB0ZWxs IHVzIHdobyBjYW4gYW5zd2VyIHRoaXMgcXVlc3Rpb24gZm9yIG1lIGlmIHlvdSBjYW4ndCBhbnN3 ZXIgdGhlc2UgcXVlc3Rpb25zLCB3ZSBzaGFsbCBkaXJlY3RseSBjb250YWN0IHRoZW0uIFRoYW5r cy4NCg0KVGhlIElUUyBpcyBmb3IgYnVnIHJlcG9ydHMsIG5vdCBmb3IgaW5mb3JtYXRpb24gcmVx dWVzdHMuIFRoaXMgSVRTIHdpbGwgYmUgY2xvc2VkLg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IEhl bnJ5DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFpbmd5dW4gWmh1DQo+ IFNlbnQ6IDIwMTLDhMOqMcOUw4IxMsOIw5UgMjA6MjUNCj4gVG86ICdvcGVubGRhcC1pdHNAT3Bl bkxEQVAub3JnJw0KPiBDYzogJ01hZ2dpZSBXb25nJw0KPiBTdWJqZWN0OiBSRTogKElUUyM3MTI0 KSBDb3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGly ZWN0b3J5IHNlcnZlciBmb3IgMjAxMj8NCj4NCj4gRGVhciB0ZWFtLA0KPg0KPiBDb3VsZCB5b3Ug cGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGlyZWN0b3J5IHNlcnZl ciBmb3IgMjAxMj8NCj4gV2UgYXJlIGludGVyZXN0ZWQgaW4gZmluZGluZyBvdXQNCj4gICDCocKk IEFueSBuZXcgcmVsZWFzZXMgcGxhbm5pbmcgaW4gMjAxMi4gSWYgYW55LCB3aGF0IGFyZSB0aGUg bmV3IGZlYXR1cmVzPw0KPiAgIMKhwqQgQW55IHBsYW4gdG8gc3VwcG9ydCBXaW5kb3dzNywgUkhF TDYueCBhbmQgQUlYIDcuMT8NCj4NCj4gVGhhbmtzJiAgQmVzdCByZWdhcmRzLA0KPiBIZW5yeQ0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvcGVubGRhcC1pdHNAT3BlbkxE QVAub3JnIFttYWlsdG86b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZ10NCj4gU2VudDogMjAxMsOE w6oxw5TDgjEyw4jDlSAyMDoyMg0KPiBUbzogUWluZ3l1biBaaHUNCj4gU3ViamVjdDogUmU6IChJ VFMjNzEyNCkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1lIHRoZSByb2FkbWFwIG9mIE9wZW5M REFQIGRpcmVjdG9yeSBzZXJ2ZXIgZm9yIDIwMTI/DQo+DQo+DQo+ICoqKiBUSElTIElTIEFOIEFV VE9NQVRJQ0FMTFkgR0VORVJBVEVEIFJFUExZICoqKg0KPg0KPiBUaGFua3MgZm9yIHlvdXIgcmVw b3J0IHRvIHRoZSBPcGVuTERBUCBJc3N1ZSBUcmFja2luZyBTeXN0ZW0uICBZb3VyDQo+IHJlcG9y dCBoYXMgYmVlbiBhc3NpZ25lZCB0aGUgdHJhY2tpbmcgbnVtYmVyIElUUyM3MTI0Lg0KPg0KPiBP bmUgb2Ygb3VyIHN1cHBvcnQgZW5naW5lZXJzIHdpbGwgbG9vayBhdCB5b3VyIHJlcG9ydCBpbiBk dWUgY291cnNlLg0KPiBOb3RlIHRoYXQgdGhpcyBtYXkgdGFrZSBzb21lIHRpbWUgYmVjYXVzZSBv dXIgc3VwcG9ydCBlbmdpbmVlcnMNCj4gYXJlIHZvbHVudGVlcnMuICBUaGV5IG9ubHkgd29yayBv biBPcGVuTERBUCB3aGVuIHRoZXkgaGF2ZSBzcGFyZQ0KPiB0aW1lLg0KPg0KPiBJZiB5b3UgbmVl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0byB5b3VyDQo+ IGlzc3VlIHJlcG9ydCwgeW91IG1heSBkbyBzbyBieSByZXBseWluZyB0byB0aGlzIG1lc3NhZ2Uu ICBOb3RlIHRoYXQNCj4gYW55IG1haWwgc2VudCB0byBvcGVubGRhcC1pdHNAb3BlbmxkYXAub3Jn IHdpdGggKElUUyM3MTI0KQ0KPiBpbiB0aGUgc3ViamVjdCB3aWxsIGF1dG9tYXRpY2FsbHkgYmUg YXR0YWNoZWQgdG8gdGhlIGlzc3VlIHJlcG9ydC4NCj4NCj4gICAgICAgICAgbWFpbHRvOm9wZW5s ZGFwLWl0c0BvcGVubGRhcC5vcmc/c3ViamVjdD0oSVRTIzcxMjQpDQo+DQo+IFlvdSBtYXkgZm9s bG93IHRoZSBwcm9ncmVzcyBvZiB0aGlzIHJlcG9ydCBieSBsb2FkaW5nIHRoZSBmb2xsb3dpbmcN Cj4gVVJMIGluIGEgd2ViIGJyb3dzZXI6DQo+ICAgICAgaHR0cDovL3d3dy5PcGVuTERBUC5vcmcv aXRzL2luZGV4LmNnaT9maW5kaWQ9NzEyNA0KPg0KPiBQbGVhc2UgcmVtZW1iZXIgdG8gcmV0YWlu IHlvdXIgaXNzdWUgdHJhY2tpbmcgbnVtYmVyIChJVFMjNzEyNCkNCj4gb24gYW55IGZ1cnRoZXIg bWVzc2FnZXMgeW91IHNlbmQgdG8gdXMgcmVnYXJkaW5nIHRoaXMgcmVwb3J0LiAgSWYNCj4geW91 IGRvbid0IHRoZW4geW91J2xsIGp1c3Qgd2FzdGUgb3VyIHRpbWUgYW5kIHlvdXJzIGJlY2F1c2Ug d2UNCj4gd29uJ3QgYmUgYWJsZSB0byBwcm9wZXJseSB0cmFjayB0aGUgcmVwb3J0Lg0KPg0KPiBQ bGVhc2Ugbm90ZSB0aGF0IHRoZSBJc3N1ZSBUcmFja2luZyBTeXN0ZW0gaXMgbm90IGludGVuZGVk IHRvDQo+IGJlIHVzZWQgdG8gc2VlayBoZWxwIGluIHRoZSBwcm9wZXIgdXNlIG9mIE9wZW5MREFQ IFNvZnR3YXJlLg0KPiBTdWNoIHJlcXVlc3RzIHdpbGwgYmUgY2xvc2VkLg0KPg0KPiBPcGVuTERB UCBTb2Z0d2FyZSBpcyB1c2VyIHN1cHBvcnRlZC4NCj4gICAgICAgICAgaHR0cDovL3d3dy5PcGVu TERBUC5vcmcvc3VwcG9ydC8NCj4NCj4gLS0tLS0tLS0tLS0tLS0NCj4gQ29weXJpZ2h0IDE5OTgt MjAwNyBUaGUgT3BlbkxEQVAgRm91bmRhdGlvbiwgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCj4NCj4N Cj4NCj4NCg0KDQotLQ0KICAgLS0gSG93YXJkIENodQ0KICAgQ1RPLCBTeW1hcyBDb3JwLiAgICAg ICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCiAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAg IGh0dHA6Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KICAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERB UCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjdC8NCg0K --_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSLlrovkvZMiIHNpemU9IjIiPg0KPGRpdj5EZWFy IEhvd2FyZCw8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBzZXJpZiI+ Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj5OaWNlIHRvIGtub3cgeW91PGZvbnQgZmFjZT0iV2lu Z2RpbmdzIiBzaXplPSIyIj5KPC9mb250PjwvZGl2Pg0KPGRpdj5Xb3VsZCB5b3UgdGVsbCBtZSB3 aG8gSSBjYW4gY29udGFjdCB0byBnZXQgdGhpcyByb2FkbWFwIGluZm9ybWF0aW9uIG9mIE9wZW5M REFQIGRpcmVjdG9yeSBzZXJ2ZXIgaW4gMjAxMj88L2Rpdj4NCjxkaXY+VGhhbmtzIGluIGFkdmFu Y2UuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiwgc2VyaWYiPiZuYnNw OzwvZm9udD48L2Rpdj4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj5IZW5yeTwvZGl2 Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KDQpGcm9tOiBIb3dh cmQgQ2h1IFs8YSBocmVmPSJtYWlsdG86aHljQHN5bWFzLmNvbSI+bWFpbHRvOmh5Y0BzeW1hcy5j b208L2E+XSA8YnI+DQoNClNlbnQ6IDIwMTLlubQx5pyIMTTml6UgMTg6Mzc8YnI+DQoNClRvOiBR aW5neXVuIFpodTxicj4NCg0KQ2M6IG9wZW5sZGFwLWl0c0BvcGVubGRhcC5vcmc8YnI+DQoNClN1 YmplY3Q6IFJlOiAoSVRTIzcxMjQpIENvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9h ZG1hcCBvZiBPcGVuTERBUCBkaXJlY3Rvcnkgc2VydmVyIGZvciAyMDEyPzwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8 ZGl2PnF6aHVAdGliY28tc3VwcG9ydC5jb20gd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgSGVsbG8s IFRlYW0sPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBTb3JyeSB0byBkaXN0dXJi IHlvdSwgaG93ZXZlciwgaXQgaXMgdXJnZW50IGZvciB1cyB0byBrbm93IHRoZSByb2FkbWFwIG9m IE9wZW5MREFQIERpcmVjdG9yeSBTZXJ2ZXIgc29mdHdhcmUgaW4gMjAxMi4gTWVhbndoaWxlLCBJ IHRoaW5rIHRoYXQgaXQgaXMgYWxzbyBoZWxwZnVsIHRvIHlvdXIgcHJvZHVjdC4gSSBsb29rIGZv cndhcmRzIHRvIHlvdXIgcXVpY2sgcmVzcG9uc2UuIEl0IGlzIGZpbmUgdGhhdCB5b3UgY2FuIHRl bGwgdXMNCndobyBjYW4gYW5zd2VyIHRoaXMgcXVlc3Rpb24gZm9yIG1lIGlmIHlvdSBjYW4ndCBh bnN3ZXIgdGhlc2UgcXVlc3Rpb25zLCB3ZSBzaGFsbCBkaXJlY3RseSBjb250YWN0IHRoZW0uIFRo YW5rcy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSBJVFMgaXMgZm9yIGJ1ZyBy ZXBvcnRzLCBub3QgZm9yIGluZm9ybWF0aW9uIHJlcXVlc3RzLiBUaGlzIElUUyB3aWxsIGJlIGNs b3NlZC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEJlc3QgcmVnYXJkcyw8L2Rp dj4NCjxkaXY+Jmd0OyBIZW5yeTwvZGl2Pg0KPGRpdj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPC9kaXY+DQo8ZGl2PiZndDsgRnJvbTogUWluZ3l1biBaaHU8L2Rpdj4NCjxkaXY+Jmd0 OyBTZW50OiAyMDEyPGZvbnQgZmFjZT0iQ291cmllciBOZXcsIG1vbm9zcGFjZSI+w4TDqjwvZm9u dD4xPGZvbnQgZmFjZT0iQ291cmllciBOZXcsIG1vbm9zcGFjZSI+w5TDgjwvZm9udD4xMjxmb250 IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOIw5U8L2ZvbnQ+IDIwOjI1PC9kaXY+DQo8 ZGl2PiZndDsgVG86ICdvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnJzwvZGl2Pg0KPGRpdj4mZ3Q7 IENjOiAnTWFnZ2llIFdvbmcnPC9kaXY+DQo8ZGl2PiZndDsgU3ViamVjdDogUkU6IChJVFMjNzEy NCkgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIG1lIHRoZSByb2FkbWFwIG9mIE9wZW5MREFQIGRp cmVjdG9yeSBzZXJ2ZXIgZm9yIDIwMTI/PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyBEZWFyIHRlYW0sPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBDb3VsZCB5b3Ug cGxlYXNlIHByb3ZpZGUgbWUgdGhlIHJvYWRtYXAgb2YgT3BlbkxEQVAgZGlyZWN0b3J5IHNlcnZl ciBmb3IgMjAxMj88L2Rpdj4NCjxkaXY+Jmd0OyBXZSBhcmUgaW50ZXJlc3RlZCBpbiBmaW5kaW5n IG91dDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7IDxmb250IGZhY2U9IkNvdXJpZXIgTmV3 LCBtb25vc3BhY2UiPsKhwqQ8L2ZvbnQ+IEFueSBuZXcgcmVsZWFzZXMgcGxhbm5pbmcgaW4gMjAx Mi4gSWYgYW55LCB3aGF0IGFyZSB0aGUgbmV3IGZlYXR1cmVzPzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5i c3A7Jm5ic3A7IDxmb250IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsKhwqQ8L2ZvbnQ+ IEFueSBwbGFuIHRvIHN1cHBvcnQgV2luZG93czcsIFJIRUw2LnggYW5kIEFJWCA3LjE/PC9kaXY+ DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBUaGFua3MmYW1wOyZuYnNwOyBCZXN0IHJlZ2Fy ZHMsPC9kaXY+DQo8ZGl2PiZndDsgSGVucnk8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7IEZyb206IG9wZW5sZGFwLWl0c0BPcGVuTERB UC5vcmcgWzxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnIj5tYWlsdG86 b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZzwvYT5dPC9kaXY+DQo8ZGl2PiZndDsgU2VudDogMjAx Mjxmb250IGZhY2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOEw6o8L2ZvbnQ+MTxmb250IGZh Y2U9IkNvdXJpZXIgTmV3LCBtb25vc3BhY2UiPsOUw4I8L2ZvbnQ+MTI8Zm9udCBmYWNlPSJDb3Vy aWVyIE5ldywgbW9ub3NwYWNlIj7DiMOVPC9mb250PiAyMDoyMjwvZGl2Pg0KPGRpdj4mZ3Q7IFRv OiBRaW5neXVuIFpodTwvZGl2Pg0KPGRpdj4mZ3Q7IFN1YmplY3Q6IFJlOiAoSVRTIzcxMjQpIENv dWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBtZSB0aGUgcm9hZG1hcCBvZiBPcGVuTERBUCBkaXJlY3Rv cnkgc2VydmVyIGZvciAyMDEyPzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rp dj4NCjxkaXY+Jmd0OyAqKiogVEhJUyBJUyBBTiBBVVRPTUFUSUNBTExZIEdFTkVSQVRFRCBSRVBM WSAqKio8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFRoYW5rcyBmb3IgeW91ciBy ZXBvcnQgdG8gdGhlIE9wZW5MREFQIElzc3VlIFRyYWNraW5nIFN5c3RlbS4mbmJzcDsgWW91cjwv ZGl2Pg0KPGRpdj4mZ3Q7IHJlcG9ydCBoYXMgYmVlbiBhc3NpZ25lZCB0aGUgdHJhY2tpbmcgbnVt YmVyIElUUyM3MTI0LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgT25lIG9mIG91 ciBzdXBwb3J0IGVuZ2luZWVycyB3aWxsIGxvb2sgYXQgeW91ciByZXBvcnQgaW4gZHVlIGNvdXJz ZS48L2Rpdj4NCjxkaXY+Jmd0OyBOb3RlIHRoYXQgdGhpcyBtYXkgdGFrZSBzb21lIHRpbWUgYmVj YXVzZSBvdXIgc3VwcG9ydCBlbmdpbmVlcnM8L2Rpdj4NCjxkaXY+Jmd0OyBhcmUgdm9sdW50ZWVy cy4mbmJzcDsgVGhleSBvbmx5IHdvcmsgb24gT3BlbkxEQVAgd2hlbiB0aGV5IGhhdmUgc3BhcmU8 L2Rpdj4NCjxkaXY+Jmd0OyB0aW1lLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg SWYgeW91IG5lZWQgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGluIHJlZ2FyZHMg dG8geW91cjwvZGl2Pg0KPGRpdj4mZ3Q7IGlzc3VlIHJlcG9ydCwgeW91IG1heSBkbyBzbyBieSBy ZXBseWluZyB0byB0aGlzIG1lc3NhZ2UuJm5ic3A7IE5vdGUgdGhhdDwvZGl2Pg0KPGRpdj4mZ3Q7 IGFueSBtYWlsIHNlbnQgdG8gb3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZyB3aXRoIChJVFMjNzEy NCk8L2Rpdj4NCjxkaXY+Jmd0OyBpbiB0aGUgc3ViamVjdCB3aWxsIGF1dG9tYXRpY2FsbHkgYmUg YXR0YWNoZWQgdG8gdGhlIGlzc3VlIHJlcG9ydC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnP3N1YmplY3Q9KElU UyM3MTI0Ij5tYWlsdG86b3BlbmxkYXAtaXRzQG9wZW5sZGFwLm9yZz9zdWJqZWN0PShJVFMjNzEy NDwvYT4pPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBZb3UgbWF5IGZvbGxvdyB0 aGUgcHJvZ3Jlc3Mgb2YgdGhpcyByZXBvcnQgYnkgbG9hZGluZyB0aGUgZm9sbG93aW5nPC9kaXY+ DQo8ZGl2PiZndDsgVVJMIGluIGEgd2ViIGJyb3dzZXI6PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5PcGVuTERBUC5vcmcv aXRzL2luZGV4LmNnaT9maW5kaWQ9NzEyNCI+aHR0cDovL3d3dy5PcGVuTERBUC5vcmcvaXRzL2lu ZGV4LmNnaT9maW5kaWQ9NzEyNDwvYT48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 IFBsZWFzZSByZW1lbWJlciB0byByZXRhaW4geW91ciBpc3N1ZSB0cmFja2luZyBudW1iZXIgKElU UyM3MTI0KTwvZGl2Pg0KPGRpdj4mZ3Q7IG9uIGFueSBmdXJ0aGVyIG1lc3NhZ2VzIHlvdSBzZW5k IHRvIHVzIHJlZ2FyZGluZyB0aGlzIHJlcG9ydC4mbmJzcDsgSWY8L2Rpdj4NCjxkaXY+Jmd0OyB5 b3UgZG9uJ3QgdGhlbiB5b3UnbGwganVzdCB3YXN0ZSBvdXIgdGltZSBhbmQgeW91cnMgYmVjYXVz ZSB3ZTwvZGl2Pg0KPGRpdj4mZ3Q7IHdvbid0IGJlIGFibGUgdG8gcHJvcGVybHkgdHJhY2sgdGhl IHJlcG9ydC48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFBsZWFzZSBub3RlIHRo YXQgdGhlIElzc3VlIFRyYWNraW5nIFN5c3RlbSBpcyBub3QgaW50ZW5kZWQgdG88L2Rpdj4NCjxk aXY+Jmd0OyBiZSB1c2VkIHRvIHNlZWsgaGVscCBpbiB0aGUgcHJvcGVyIHVzZSBvZiBPcGVuTERB UCBTb2Z0d2FyZS48L2Rpdj4NCjxkaXY+Jmd0OyBTdWNoIHJlcXVlc3RzIHdpbGwgYmUgY2xvc2Vk LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgT3BlbkxEQVAgU29mdHdhcmUgaXMg dXNlciBzdXBwb3J0ZWQuPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5PcGVuTERB UC5vcmcvc3VwcG9ydC8iPmh0dHA6Ly93d3cuT3BlbkxEQVAub3JnL3N1cHBvcnQvPC9hPjwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgLS0tLS0tLS0tLS0tLS08L2Rpdj4NCjxkaXY+ Jmd0OyBDb3B5cmlnaHQgMTk5OC0yMDA3IFRoZSBPcGVuTERBUCBGb3VuZGF0aW9uLCBBbGwgUmln aHRzIFJlc2VydmVkLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+LS08L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IC0tIEhvd2FyZCBD aHU8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IENUTywgU3ltYXMgQ29ycC4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cDovL3d3dy5zeW1hcy5jb20iPmh0dHA6Ly93d3cuc3ltYXMuY29tPC9hPjwvZGl2Pg0KPGRp dj4mbmJzcDsmbmJzcDsgRGlyZWN0b3IsIEhpZ2hsYW5kIFN1biZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vaGlnaGxhbmRzdW4uY29tL2h5Yy8iPmh0dHA6Ly9oaWdobGFu ZHN1bi5jb20vaHljLzwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7IENoaWVmIEFyY2hpdGVj dCwgT3BlbkxEQVAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVj dC8iPmh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3QvPC9hPjwvZGl2Pg0KPGRpdj48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4sIHNlcmlmIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8L2Zv bnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C193E097DA77BB4482B17A5E5802BF23A1117AB75Bparcexch01tib_--

1 0

Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by hyc＠symas.com 14 Jan '12

14 Jan '12

qzhu(a)tibco-support.com wrote: > Hello, Team, > > Sorry to disturb you, however, it is urgent for us to know the roadmap of OpenLDAP Directory Server software in 2012. Meanwhile, I think that it is also helpful to your product. I look forwards to your quick response. It is fine that you can tell us who can answer this question for me if you can't answer these questions, we shall directly contact them. Thanks. The ITS is for bug reports, not for information requests. This ITS will be closed. > > Best regards, > Henry > -----Original Message----- > From: Qingyun Zhu > Sent: 2012Äê1ÔÂ12ÈÕ 20:25 > To: 'openldap-its(a)OpenLDAP.org' > Cc: 'Maggie Wong' > Subject: RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? > > Dear team, > > Could you please provide me the roadmap of OpenLDAP directory server for 2012? > We are interested in finding out > ¡¤ Any new releases planning in 2012. If any, what are the new features? > ¡¤ Any plan to support Windows7, RHEL6.x and AIX 7.1? > > Thanks& Best regards, > Henry > -----Original Message----- > From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] > Sent: 2012Äê1ÔÂ12ÈÕ 20:22 > To: Qingyun Zhu > Subject: Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? > > > *** 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#7124. > > 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#7124) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7124) > > 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=7124 > > Please remember to retain your issue tracking number (ITS#7124) > 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. > > > > -- -- 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#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012?
by qzhu＠tibco-support.com 13 Jan '12

13 Jan '12

Hello, Team, Sorry to disturb you, however, it is urgent for us to know the roadmap of OpenLDAP Directory Server software in 2012. Meanwhile, I think that it is also helpful to your product. I look forwards to your quick response. It is fine that you can tell us who can answer this question for me if you can't answer these questions, we shall directly contact them. Thanks. Best regards, Henry -----Original Message----- From: Qingyun Zhu Sent: 2012Äê1ÔÂ12ÈÕ 20:25 To: 'openldap-its(a)OpenLDAP.org' Cc: 'Maggie Wong' Subject: RE: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? Dear team, Could you please provide me the roadmap of OpenLDAP directory server for 2012? We are interested in finding out ¡€ Any new releases planning in 2012. If any, what are the new features? ¡€ Any plan to support Windows7, RHEL6.x and AIX 7.1? Thanks& Best regards, Henry -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Sent: 2012Äê1ÔÂ12ÈÕ 20:22 To: Qingyun Zhu Subject: Re: (ITS#7124) Could you please provide me the roadmap of OpenLDAP directory server for 2012? *** 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#7124. 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#7124) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#7124) 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=7124 Please remember to retain your issue tracking number (ITS#7124) 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs