- openldap-bugs - openldap.org

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by quanah＠zimbra.com 29 Apr '14

29 Apr '14

--On April 29, 2014 at 2:42:19 PM +0000 konrad.windszus(a)netcentric.biz wrote: > > --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; /builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23 You waste yours and everyone else's time using the RHEL/CentOS build of OpenLDAP. Get a real build from Symas or the LTB project. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by konrad.windszus＠netcentric.biz 29 Apr '14

29 Apr '14

--Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I got a similar crash when issuing a Bind request.=20 GDB has the following information about that: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f0898ff9700 (LWP 17201)] 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621 1621 rc =3D TXN_BEGIN( env, NULL, txn, = DB_READ_COMMITTED ); The stack trace exposes the following: (gdb) bt full #0 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621 i =3D <value optimized out> rc =3D <value optimized out> data =3D <value optimized out> ctx =3D 0x7f0898ff8b70 #1 0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, = ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) = at id2entry.c:343 bdb =3D 0x7f08d14cf5a0 boi =3D 0x0 txn =3D 0x0 e =3D 0x0 ei =3D <value optimized out> rc =3D <value optimized out> at_name =3D 0x7f08d0abdacd "(null)" lock =3D {off =3D 8, ndx =3D 4294967295, gen =3D 32520, mode =3D = DB_LOCK_WWRITE} #2 0x00007f08d09ef799 in overlay_entry_get_ov (op=3D0x7f0860000970, = dn=3D0x7f08600009a8, oc=3D0x0, ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, = on=3D0x0) at ../../../servers/slapd/backover.c:364 oi =3D 0x7f08d14bd9d0 be =3D 0x7f08d14cf410 db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D = "\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\= 000\000\000\000\000ihdof", be_flags =3D 551504935474,=20 be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D = {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 2566881772, sss_sasl =3D = 32520, sss_update_ssf =3D 0, sss_update_transport =3D 0,=20 sss_update_tls =3D 3081553768, sss_update_sasl =3D 32520, = sss_simple_bind =3D 3513539536}, be_suffix =3D 0x7f08b7acc768, = be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn =3D {bv_len =3D 122,=20 bv_val =3D 0x7f08b7ace810 "z"}, be_schemandn =3D {bv_len =3D = 139675828497508, bv_val =3D 0x7f086010f0b0 "."}, be_rootdn =3D {bv_len =3D= 139675850001328, bv_val =3D 0x7f08d13bf590 ""}, be_rootndn =3D { bv_len =3D 139675417895224, bv_val =3D 0x7f08cc629670 ""}, = be_rootpw =3D {bv_len =3D 7786477098, bv_val =3D 0x28 <Address 0x28 out = of bounds>}, be_max_deref_depth =3D 2566882064, be_def_limit =3D { lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft = =3D 32520, lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, = lms_s_pr =3D -1728085380, lms_s_pr_hide =3D 32520,=20 lms_s_pr_total =3D -1213537992}, be_limits =3D = 0x7f0898ff8310, be_acl =3D 0x7f08d0243101, be_dfltaccess =3D = -1728085408, be_update_ndn =3D {bv_len =3D 139672336465920,=20 bv_val =3D 0x7f08d16c4bb0 "\220Ol\321\b\177"}, = be_update_refs =3D 0x7f08d16c5bd0, be_pending_csn_list =3D = 0x7f0898ff8310, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D = 0, __owner =3D -791385128,=20 __nusers =3D 32520, __kind =3D -802934423, __spins =3D = 32520, __list =3D {__prev =3D 0x0, __next =3D 0x0}},=20 __size =3D = "\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"= , '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, be_pb = =3D 0x7f08d16c4bb0,=20 be_cf_ocs =3D 0x7f0898ff8310, be_private =3D 0x7f08d14c5730, = be_next =3D {stqe_next =3D 0x7f08d0dc87a0}} bi =3D 0x7f08d14bd9d0 rc =3D 32768 #3 0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized out>, = dn=3D<value optimized out>, oc=3D<value optimized out>, ad=3D<value = optimized out>, rw=3D<value optimized out>, e=3D<value optimized out>) at ../../../servers/slapd/backover.c:396 oi =3D <value optimized out> on =3D <value optimized out> __PRETTY_FUNCTION__ =3D "over_entry_get_rw" #4 0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../../servers/slapd/overlays/ppolicy.c:919 ppb =3D 0x7f0860001630 on =3D 0x7f08d14c7540 mod =3D 0x0 m =3D <value optimized out> pwExpired =3D 0 ngut =3D -1 warn =3D -1 age =3D <value optimized out> rc =3D <value optimized out> a =3D <value optimized out> now =3D <value optimized out> pwtime =3D -1 nowstr =3D = "\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b= \177" timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D = 0x7f0898ff8486 ""} bi =3D 0x7f08d14d03e0 e =3D <value optimized out> #5 0x00007f08d0993f5e in slap_response_play (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:402 sc_next =3D 0x7f08600014c8 ---Type <return> to continue, or q <return> to quit--- sc_nextp =3D 0x7f0860001610 rc =3D 32768 sc =3D 0x7f0860001610 scp =3D 0x7f0898ff85e8 #6 0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476 berbuf =3D { buffer =3D = "\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00= 0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\= 000 = \034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\= 000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00= 0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000= \000\340\003M\321\b\177\000\000 = d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00= 0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\= 000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' = <repeats 12 times>, "p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 = \375\324\320\b\177\000\000 = \211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000= \000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D= 111669149703, falign =3D 9.80908925e-45, dalign =3D = 5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 = out of bounds>} ber =3D 0x7f0898ff8630 rc =3D 0 bytes =3D <value optimized out> __PRETTY_FUNCTION__ =3D "send_ldap_response" #7 0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750 tmp =3D 0x0 otext =3D 0x0 oref =3D 0x0 __PRETTY_FUNCTION__ =3D "slap_send_ldap_result" #8 0x00007f08d09a1ba9 in fe_op_bind_success (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:440 No locals. #9 0x00007f08d09a233f in fe_op_bind (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:386 bd =3D 0x7f08d0d505e0 #10 0x00007f08d09a2b19 in do_bind (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:205 ber =3D 0x7f0860000d60 version =3D 3 method =3D 128 mech =3D {bv_len =3D 0, bv_val =3D 0x0} dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca = "uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"} tag =3D <value optimized out> be =3D <value optimized out> #11 0x00007f08d09839f9 in connection_operation (ctx=3D0x7f0898ff8b70, = arg_v=3D0x7f0860000970) at ../../../servers/slapd/connection.c:1109 rc =3D 80 cancel =3D <value optimized out> op =3D 0x7f0860000970 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, = sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, = sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, = r_attr_flags =3D 0,=20 r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D= 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D = {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} tag =3D 96 opidx =3D SLAP_OP_BIND conn =3D 0x7f08d14e3350 memctx =3D 0x7f0860000ed0 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #12 0x00007f08d098434d in connection_read_thread (ctx=3D0x7f0898ff8b70, = argv=3D<value optimized out>) at = ../../../servers/slapd/connection.c:1245 rc =3D <value optimized out> cri =3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D = 0x7f0898ff8b70, nullop =3D <value optimized out>} s =3D <value optimized out> #13 0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper = (xpool=3D0x7f08d13ee170) at ../../../libraries/libldap_r/tpool.c:685 pool =3D 0x7f08d13ee170 task =3D 0x7f089c000f00 work_list =3D <value optimized out> ctx =3D {ltu_id =3D 139674903353088, ltu_key =3D {{ltk_key =3D = 0x7f08d0982540, ltk_data =3D 0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 = <conn_counter_destroy>}, {ltk_key =3D 0x7f08d09dc7d0,=20 ---Type <return> to continue, or q <return> to quit--- ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 = <slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D = 0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, { ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D = 0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, = ltk_data =3D 0x7f086010ead0,=20 ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D= 0x0, ltk_data =3D 0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, = ltk_data =3D 0x0, ltk_free =3D 0} <repeats 26 times>}} kctx =3D <value optimized out> keyslot =3D <value optimized out> hash =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #14 0x00007f08ce8ff9d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #15 0x00007f08ce441b6d in clone () from /lib64/libc.so.6 No symbol table info available. I am using the binary=20 @(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $ = mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/= openldap-2.4.23/build-servers/servers/slapd That should have the patch from Jan included, so I am wondering whether = the original issue is still not solved or whether this is a separate = issue. Thanks, Konrad --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I got = a similar crash when issuing a Bind request. <div>GDB has the = following information about that:</div><div><br></div><div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;"><div = style=3D"margin: 0px;"><div style=3D"margin: 0px;">Program received = signal SIGSEGV, Segmentation fault.</div><div style=3D"margin: = 0px;">[Switching to Thread 0x7f0898ff9700 (LWP 17201)]</div><div = style=3D"margin: 0px;">0x00007f08d0a409f8 in hdb_reader_get = (op=3D<value optimized out>, env=3D0x7f08d14c55a0, = txn=3D0x7f0898ff80a8) at cache.c:1621</div><div style=3D"margin: = 0px;">1621<span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>rc =3D TXN_BEGIN( env, NULL, txn, = DB_READ_COMMITTED );</div></div><div style=3D"margin: = 0px;"><br></div><div style=3D"margin: 0px;">The stack trace exposes the = following:</div><div style=3D"margin: 0px;"><div style=3D"margin: = 0px;">(gdb) bt full</div><div style=3D"margin: 0px;">#0  = 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621</div><div = style=3D"margin: 0px;">        i =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   rc =3D <value optimized out></div><div style=3D"margin: = 0px;">        data =3D <value optimized = out></div><div style=3D"margin: 0px;">        ctx = =3D 0x7f0898ff8b70</div><div style=3D"margin: 0px;">#1  = 0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, = ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) = at id2entry.c:343</div><div style=3D"margin: 0px;">      =   bdb =3D 0x7f08d14cf5a0</div><div style=3D"margin: 0px;">  =       boi =3D 0x0</div><div style=3D"margin: 0px;">  =       txn =3D 0x0</div><div style=3D"margin: 0px;">  =       e =3D 0x0</div><div style=3D"margin: 0px;">  =       ei =3D <value optimized out></div><div = style=3D"margin: 0px;">        rc =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   at_name =3D 0x7f08d0abdacd "(null)"</div><div style=3D"margin: = 0px;">        lock =3D {off =3D 8, ndx =3D = 4294967295, gen =3D 32520, mode =3D DB_LOCK_WWRITE}</div><div = style=3D"margin: 0px;">#2  0x00007f08d09ef799 in = overlay_entry_get_ov (op=3D0x7f0860000970, dn=3D0x7f08600009a8, oc=3D0x0, = ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, on=3D0x0) at = ../../../servers/slapd/backover.c:364</div><div style=3D"margin: = 0px;">        oi =3D 0x7f08d14bd9d0</div><div = style=3D"margin: 0px;">        be =3D = 0x7f08d14cf410</div><div style=3D"margin: 0px;">      =   db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D = "\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\= 000\000\000\000\000ihdof", be_flags =3D 551504935474, </div><div = style=3D"margin: 0px;">          be_restrictops = =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D= 0, sss_tls =3D 2566881772, sss_sasl =3D 32520, sss_update_ssf =3D 0, = sss_update_transport =3D 0, </div><div style=3D"margin: = 0px;">            sss_update_tls =3D = 3081553768, sss_update_sasl =3D 32520, sss_simple_bind =3D 3513539536}, = be_suffix =3D 0x7f08b7acc768, be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn = =3D {bv_len =3D 122, </div><div style=3D"margin: 0px;">  =           bv_val =3D 0x7f08b7ace810 "z"}, = be_schemandn =3D {bv_len =3D 139675828497508, bv_val =3D 0x7f086010f0b0 = "."}, be_rootdn =3D {bv_len =3D 139675850001328, bv_val =3D = 0x7f08d13bf590 ""}, be_rootndn =3D {</div><div style=3D"margin: = 0px;">            bv_len =3D = 139675417895224, bv_val =3D 0x7f08cc629670 ""}, be_rootpw =3D {bv_len =3D = 7786477098, bv_val =3D 0x28 <Address 0x28 out of bounds>}, = be_max_deref_depth =3D 2566882064, be_def_limit =3D {</div><div = style=3D"margin: 0px;">            = lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft =3D 32520, = lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, lms_s_pr =3D = -1728085380, lms_s_pr_hide =3D 32520, </div><div style=3D"margin: = 0px;">            lms_s_pr_total =3D = -1213537992}, be_limits =3D 0x7f0898ff8310, be_acl =3D 0x7f08d0243101, = be_dfltaccess =3D -1728085408, be_update_ndn =3D {bv_len =3D = 139672336465920, </div><div style=3D"margin: 0px;">    =         bv_val =3D 0x7f08d16c4bb0 = "\220Ol\321\b\177"}, be_update_refs =3D 0x7f08d16c5bd0, = be_pending_csn_list =3D 0x7f0898ff8310, be_pcl_mutex =3D {__data =3D = {__lock =3D 0, __count =3D 0, __owner =3D -791385128, </div><div = style=3D"margin: 0px;">              = __nusers =3D 32520, __kind =3D -802934423, __spins =3D 32520, __list =3D = {__prev =3D 0x0, __next =3D 0x0}}, </div><div style=3D"margin: = 0px;">            __size =3D = "\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"= , '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, = be_pb =3D 0x7f08d16c4bb0, </div><div style=3D"margin: 0px;">  =         be_cf_ocs =3D 0x7f0898ff8310, be_private =3D = 0x7f08d14c5730, be_next =3D {stqe_next =3D 0x7f08d0dc87a0}}</div><div = style=3D"margin: 0px;">        bi =3D = 0x7f08d14bd9d0</div><div style=3D"margin: 0px;">      =   rc =3D 32768</div><div style=3D"margin: 0px;">#3  = 0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized = out>, dn=3D<value optimized out>, oc=3D<value optimized = out>, ad=3D<value optimized out>, rw=3D<value optimized = out>, e=3D<value optimized out>)</div><div style=3D"margin: = 0px;">    at ../../../servers/slapd/backover.c:396</div><div = style=3D"margin: 0px;">        oi =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   on =3D <value optimized out></div><div style=3D"margin: = 0px;">        __PRETTY_FUNCTION__ =3D = "over_entry_get_rw"</div><div style=3D"margin: 0px;">#4  = 0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at = ../../../../servers/slapd/overlays/ppolicy.c:919</div><div = style=3D"margin: 0px;">        ppb =3D = 0x7f0860001630</div><div style=3D"margin: 0px;">      =   on =3D 0x7f08d14c7540</div><div style=3D"margin: 0px;">  =       mod =3D 0x0</div><div style=3D"margin: 0px;">  =       m =3D <value optimized out></div><div = style=3D"margin: 0px;">        pwExpired =3D = 0</div><div style=3D"margin: 0px;">        ngut =3D = -1</div><div style=3D"margin: 0px;">        warn =3D = -1</div><div style=3D"margin: 0px;">        age =3D = <value optimized out></div><div style=3D"margin: 0px;">  =       rc =3D <value optimized out></div><div = style=3D"margin: 0px;">        a =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   now =3D <value optimized out></div><div style=3D"margin: = 0px;">        pwtime =3D -1</div><div style=3D"margin:= 0px;">        nowstr =3D = "\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b= \177"</div><div style=3D"margin: 0px;">        = timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D 0x7f0898ff8486 = ""}</div><div style=3D"margin: 0px;">        bi =3D = 0x7f08d14d03e0</div><div style=3D"margin: 0px;">      =   e =3D <value optimized out></div><div style=3D"margin: = 0px;">#5  0x00007f08d0993f5e in slap_response_play = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/result.c:402</div><div style=3D"margin: = 0px;">        sc_next =3D 0x7f08600014c8</div><div = style=3D"margin: 0px;">---Type <return> to continue, or q = <return> to quit---</div><div style=3D"margin: 0px;">    =     sc_nextp =3D 0x7f0860001610</div><div style=3D"margin: = 0px;">        rc =3D 32768</div><div style=3D"margin: = 0px;">        sc =3D 0x7f0860001610</div><div = style=3D"margin: 0px;">        scp =3D = 0x7f0898ff85e8</div><div style=3D"margin: 0px;">#6  = 0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476</div><div = style=3D"margin: 0px;">        berbuf =3D = {</div><div style=3D"margin: 0px;">          = buffer =3D = "\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00= 0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\= 000 = \034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\= 000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00= 0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000= \000\340\003M\321\b\177\000\000 = d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00= 0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\= 000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' = <repeats 12 times>, = "p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 = \375\324\320\b\177\000\000 = \211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000= \000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D= 111669149703, falign =3D 9.80908925e-45, dalign =3D = 5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 = out of bounds>}</div><div style=3D"margin: 0px;">      =   ber =3D 0x7f0898ff8630</div><div style=3D"margin: 0px;">  =       rc =3D 0</div><div style=3D"margin: 0px;">  =       bytes =3D <value optimized out></div><div = style=3D"margin: 0px;">        __PRETTY_FUNCTION__ =3D= "send_ldap_response"</div><div style=3D"margin: 0px;">#7  = 0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750</div><div = style=3D"margin: 0px;">        tmp =3D 0x0</div><div = style=3D"margin: 0px;">        otext =3D = 0x0</div><div style=3D"margin: 0px;">        oref =3D = 0x0</div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "slap_send_ldap_result"</div><div style=3D"margin:= 0px;">#8  0x00007f08d09a1ba9 in fe_op_bind_success = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:440</div><div style=3D"margin: 0px;">No = locals.</div><div style=3D"margin: 0px;">#9  0x00007f08d09a233f in = fe_op_bind (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:386</div><div style=3D"margin: = 0px;">        bd =3D 0x7f08d0d505e0</div><div = style=3D"margin: 0px;">#10 0x00007f08d09a2b19 in do_bind = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:205</div><div style=3D"margin: = 0px;">        ber =3D 0x7f0860000d60</div><div = style=3D"margin: 0px;">        version =3D = 3</div><div style=3D"margin: 0px;">        method =3D = 128</div><div style=3D"margin: 0px;">        mech =3D = {bv_len =3D 0, bv_val =3D 0x0}</div><div style=3D"margin: 0px;">  =       dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca = "uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"}<= /div><div style=3D"margin: 0px;">        tag =3D = <value optimized out></div><div style=3D"margin: 0px;">  =       be =3D <value optimized out></div><div = style=3D"margin: 0px;">#11 0x00007f08d09839f9 in connection_operation = (ctx=3D0x7f0898ff8b70, arg_v=3D0x7f0860000970) at = ../../../servers/slapd/connection.c:1109</div><div style=3D"margin: = 0px;">        rc =3D 80</div><div style=3D"margin: = 0px;">        cancel =3D <value optimized = out></div><div style=3D"margin: 0px;">        op = =3D 0x7f0860000970</div><div style=3D"margin: 0px;">      =   rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, = sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, = sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, = r_attr_flags =3D 0, </div><div style=3D"margin: 0px;">    =           r_operational_attrs =3D 0x0, r_attrs = =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D = 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags = =3D 0}</div><div style=3D"margin: 0px;">        tag = =3D 96</div><div style=3D"margin: 0px;">        = opidx =3D SLAP_OP_BIND</div><div style=3D"margin: 0px;">    =     conn =3D 0x7f08d14e3350</div><div style=3D"margin: = 0px;">        memctx =3D 0x7f0860000ed0</div><div = style=3D"margin: 0px;">        memctx_null =3D = 0x0</div><div style=3D"margin: 0px;">        memsiz = =3D 1048576</div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "connection_operation"</div><div style=3D"margin: = 0px;">#12 0x00007f08d098434d in connection_read_thread = (ctx=3D0x7f0898ff8b70, argv=3D<value optimized out>) at = ../../../servers/slapd/connection.c:1245</div><div style=3D"margin: = 0px;">        rc =3D <value optimized = out></div><div style=3D"margin: 0px;">        cri = =3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D = 0x7f0898ff8b70, nullop =3D <value optimized out>}</div><div = style=3D"margin: 0px;">        s =3D <value = optimized out></div><div style=3D"margin: 0px;">#13 = 0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper = (xpool=3D0x7f08d13ee170) at = ../../../libraries/libldap_r/tpool.c:685</div><div style=3D"margin: = 0px;">        pool =3D 0x7f08d13ee170</div><div = style=3D"margin: 0px;">        task =3D = 0x7f089c000f00</div><div style=3D"margin: 0px;">      =   work_list =3D <value optimized out></div><div = style=3D"margin: 0px;">        ctx =3D {ltu_id =3D = 139674903353088, ltu_key =3D {{ltk_key =3D 0x7f08d0982540, ltk_data =3D = 0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 = <conn_counter_destroy>}, {ltk_key =3D = 0x7f08d09dc7d0, </div><div style=3D"margin: 0px;">---Type = <return> to continue, or q <return> to quit---</div><div = style=3D"margin: 0px;">              = ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 = <slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D = 0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, = {</div><div style=3D"margin: 0px;">          =     ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D = 0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, = ltk_data =3D 0x7f086010ead0, </div><div style=3D"margin: = 0px;">              ltk_free =3D = 0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D = 0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, ltk_data =3D 0x0, = ltk_free =3D 0} <repeats 26 times>}}</div><div style=3D"margin: = 0px;">        kctx =3D <value optimized = out></div><div style=3D"margin: 0px;">        = keyslot =3D <value optimized out></div><div style=3D"margin: = 0px;">        hash =3D <value optimized = out></div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"</div><div = style=3D"margin: 0px;">#14 0x00007f08ce8ff9d1 in start_thread () from = /lib64/libpthread.so.0</div><div style=3D"margin: 0px;">No symbol table = info available.</div><div style=3D"margin: 0px;">#15 0x00007f08ce441b6d = in clone () from /lib64/libc.so.6</div><div style=3D"margin: 0px;">No = symbol table info available.</div></div><div style=3D"margin: = 0px;"><br></div><div style=3D"margin: 0px;">I am using the = binary </div><div style=3D"margin: 0px;"><div style=3D"margin: = 0px;">@(#) $OpenLDAP: slapd 2.4.23 (Feb  3 2014 19:11:35) = $</div><div style=3D"margin: 0px;"><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><a = href=3D"mailto:mockbuild@c6b10.bsys.dev.centos.org">mockbuild(a)c6b10.bsys.d= ev.centos.org</a>:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/bu= ild-servers/servers/slapd</div></div></div></div><div><br></div><div>That = should have the patch from Jan included, so I am wondering whether the = original issue is still not solved or whether this is a separate = issue.</div><div>Thanks,</div><div>Konrad</div><div><br></div></body></htm= l>= --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6--

1 0

(ITS#7845) slapd debug in the background
by wingcheungma＠gmail.com 28 Apr '14

28 Apr '14

Full_Name: Wing Cheung Ma Version: 2.4.23 OS: Rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (54.240.196.185) Hello, I have been running slapd with -d 1 and the logfile directive in my slapd.conf file. The issue is that I also want slapd to fork into the background once the process starts. The bash script that starts up this process needs to exit before the deployment is considered a success. Is there a way to get debugging information in my logs without using syslog and without having slapd running the foreground? Thanks -Wing

1 0

(ITS#7844) LMDB Delete Cursor inconsistencies
by armon.dadgar＠gmail.com 26 Apr '14

26 Apr '14

Full_Name: Armon Dadgar Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.200.38.131) When using a transaction across multiple named tables, it seems that if I am iterating and deleting I can trigger a condition that causes some rows to be missed by the cursor. There is a test case here that can reproduce it: https://gist.github.com/armon/11338944 You can run it using: go run test.go mdb_table.go Here is one of my test runs: https://gist.github.com/armon/11338967 In that test, I would expect all 128 entries to be deleted, but only 43 are before the cursor stops returning new rows.

1 0

(ITS#7843) ldap_set_option on LDAP not working
by korylprince＠gmail.com 25 Apr '14

25 Apr '14

Full_Name: Kory Prince Version: 2.4.39 OS: Linux (Arch/Ubuntu) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.49.164.94) Consider the following code: #include <stdio.h> #include <ldap.h> void main() { LDAP *ld; int status = ldap_initialize(&ld, "ldaps://server:636"); if (status == LDAP_SUCCESS) { printf("initialize success\n"); } status = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/certs/ca-certificates.crt"); status = ldap_simple_bind_s(ld, "bindDN", "pass"); if (status == LDAP_SUCCESS) { printf("bind success\n"); } else { printf("%s\n", ldap_err2string(status)); } } This works as expected. However changing the set_option line to status = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/certs/ca-certificates.crt"); (setting the option on the LDAP) causes the bind to fail. Using python-ldap gives me a bit more info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate) I have compiled libldap 2.4.39 on Arch and Ubuntu and am getting the same result. Interestingly enough, the version that comes packaged on Ubuntu 12.04 (2.4.28) works fine, but compiling that version myself gives the same error.

1 0

(ITS#7842) mdb readers/writer exclusion protocol, as implemented, is racy.
by rsbx＠acm.org 22 Apr '14

22 Apr '14

Full_Name: Raymond S Brand Version: mdb.master OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.145.137.13) [I would have uploaded this to the ftp.openldap.org but there was no space.] As implemented, the mdb readers/writer exclusion protocol has a race condition that could result in a writer reclaiming and over-writing pages still in use by a reader. Pseudo code of the snapshot locking protocols of reader and writer transactions. The labeled sections, for the purposes of this analysis, can be assumed to execute atomically. READER ====== *R1* t0 = meta[0].txid; t1 = meta[1].txid if (t1 > t0) t0 = t1 *R2* readers[me].txid = t0 *R3* snapshot_root = meta[t0&1].snapshot *R4* /* lookup data */ *R5* readers[me].txid = -1 // Release snapshot WRITER ====== *W1* lock(writer, EXCLUSIVE) curr_txid = meta[0].txid if (meta[1].txid > curr_txid) curr_txid = meta[1].txid *W2* oldest = curr_txid for (i=0; i<reader_slots; i++) t = readers[i].txid if (t != -1 && t < oldest) oldest = t *W3* reclaim_old_pages(oldest) /* ** Commit new transaction */ *W4* unlock(writer) --------------------------------------------------------------------------- Adversarial scheduling analysis: The following timeline demonstrates that a writer can reclaim pages in use by a reader. T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 R1 R2 R3 R4 W1 W2 W3 W4 * W1 W2 W3 T0 Reader has found the latest txid, Xn. T1->T4 Reader is not scheduled to run and a write transaction commits, Xn+1. T5 Reader is still not scheduled and another write transaction starts. T6 Writer finds that the oldest referenced transaction is the last committed transaction, Xn+1. T7 Reader records Xn in the reader table. T8 Reader gets the snapshot root page for transaction Xn. T9 Writer, believing that Xn+1 is the oldest reference transaction, reclaims the pages of transaction Xn. T10 Reader attempts to navigate pages of a transaction, Xn, that has been reclaimed and "Bad Things Happen". In fact, bad things will happen if an even number of write transactions commit between W4 and W1, represented by the '*', in the timeline above. The fix is to search for the highest txid in R1 and between R2 and R3. Optionally, followed by recording the txid, of the snapshot root found in R3, in the reader's reader table slot to, possibly, increase the number of reclaimable transactions. The lack of compiler and memory barriers in the implementation of the locking protocol is also of concern. Beyond the above, the code in mdb_txn_renew0() after the "/* Copy the DB info and flags */" comment appears to have a number of data races. --- libraries/liblmdb/mdb.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index e0f551e..908417c 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -533,11 +533,11 @@ typedef struct MDB_rxbody { * started from so we can avoid overwriting any data used in that * particular version. */ - txnid_t mrb_txnid; + volatile txnid_t mrb_txnid; /** The process ID of the process owning this reader txn. */ - MDB_PID_T mrb_pid; + volatile MDB_PID_T mrb_pid; /** The thread ID of the thread owning this txn. */ - pthread_t mrb_tid; + volatile pthread_t mrb_tid; } MDB_rxbody; /** The actual reader record, with cacheline padding. */ @@ -585,12 +585,12 @@ typedef struct MDB_txbody { * This is recorded here only for convenience; the value can always * be determined by reading the main database meta pages. */ - txnid_t mtb_txnid; + volatile txnid_t mtb_txnid; /** The number of slots that have been used in the reader table. * This always records the maximum count, it is not decremented * when readers release their slots. */ - unsigned mtb_numreaders; + volatile unsigned mtb_numreaders; } MDB_txbody; /** The actual reader table definition. */ @@ -854,7 +854,7 @@ typedef struct MDB_meta { /** Any persistent environment flags. @ref mdb_env */ #define mm_flags mm_dbs[0].md_flags pgno_t mm_last_pg; /**< last used page in file */ - txnid_t mm_txnid; /**< txnid that committed this page */ + volatile txnid_t mm_txnid; /**< txnid that committed this page */ } MDB_meta; /** Buffer for a stack-allocated meta page. @@ -2303,10 +2303,12 @@ mdb_txn_renew0(MDB_txn *txn) if (txn->mt_flags & MDB_TXN_RDONLY) { if (!ti) { + /* No readers table; app responsible for locking */ meta = env->me_metas[ mdb_env_pick_meta(env) ]; txn->mt_txnid = meta->mm_txnid; txn->mt_u.reader = NULL; } else { + /* Has readers table */ MDB_reader *r = (env->me_flags & MDB_NOTLS) ? txn->mt_u.reader : pthread_getspecific(env->me_txkey); if (r) { @@ -2347,8 +2349,12 @@ mdb_txn_renew0(MDB_txn *txn) return rc; } } - txn->mt_txnid = r->mr_txnid = ti->mti_txnid; txn->mt_u.reader = r; + r->mr_txnid = ti->mti_txnid; + + /* Really need a memory barrier here */ + + txn->mt_txnid = r->mr_txnid = ti->mti_txnid; meta = env->me_metas[txn->mt_txnid & 1]; } } else { @@ -2376,10 +2382,10 @@ mdb_txn_renew0(MDB_txn *txn) } /* Copy the DB info and flags */ - memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); + memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); /* Racy */ /* Moved to here to avoid a data race in read TXNs */ - txn->mt_next_pgno = meta->mm_last_pg+1; + txn->mt_next_pgno = meta->mm_last_pg+1; /* Racy */ for (i=2; i<txn->mt_numdbs; i++) { x = env->me_dbflags[i]; -- 1.9.0.138.g2de3478

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 22 Apr '14

22 Apr '14

hello, FYI, I just stumbled on an old topic from 2011: --------------------------------- 8< --------------------------------- Re: cn=config replication to consumer / slave servers ________________________________ To: Christopher Strider Cook <ccook(a)pandora.com> Subject: Re: cn=config replication to consumer / slave servers From: Howard Chu <hyc(a)symas.com> Date: Tue, 19 Apr 2011 17:27:58 -0700 Cc: Quanah Gibson-Mount <quanah(a)zimbra.com>, openldap-technical(a)openldap.org ________________________________ Christopher Strider Cook wrote: > So, the pointer to test059 was exactly what this issue needed and > following it has lead me to an very good working setup with one puzzling > final step. > The problem I now face is that the initial cn=config entries used to do > the first sync do not get overwritten by the data from the master. So > the install password doesn't get replaced nor do the updated retry > timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries have > newer timestamps than those on the master. > How can this be overcome from the perspective of the slave server. > Updating the entries on the master triggers the update as you would > expect. Is there a way to put the stub entries onto the slave with a > timestamp in the past so that they get overwritten during the first > sync? Or is there another way to trigger them to be updated? Use slapd -c. Read the slapd(8) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------------------------- 8< --------------------------------- you always answer "use slapd -c" to this type of question, but you _never_ mention that newer entries are never overwritten by older entries. so _in this context_ this answer is useless building the consumer before the provider is not an option, also _in this context_ so the only option left is to update the master with an empty modify ldif to force update of the timestamps I personnaly use --------------------------------- 8< --------------------------------- dn: cn=config changetype: modify dn: olcDatabase={-1}frontend,cn=config changetype: modify dn: olcDatabase={0}config,cn=config changetype: modify --------------------------------- 8< --------------------------------- besides, if you do this update with a user from a different database, e.g cn=admin,dc=my,dc=tld the seed replication fails because modifiersName contains a non existing DN (at the time of the replication). I consider this a bug also. anyway, thanks for your dedicated time and effort. OpenLDAP is really a great software. I have a lot to learn yet. so please bear with me :-) best regards, 2014-04-20 11:33 GMT+04:00 Jephte Clain <jephte.clain(a)univ-reunion.fr>: > hello, > > thanks for your answer. > see my response below > > 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: >> Jephte.Clain(a)univ-reunion.fr wrote: >>> >>> Full_Name: Jephte CLAIN >>> Version: 2.4.39 >>> OS: Debian 6 64bits >>> URL: http://jclain.fr/openldap-its/ >>> Submission from: (NULL) (93.176.62.129) >>> >>> >>> I have scripts to test several replication scenarii, that setup the LDAP >>> environment then allow me to play with parameters as I see fit. >>> >>> I believe that there is a bug with the "seed replication" that allow one >>> to >>> build an exact clone of a master with minimal configuration on the slave >>> side. >> >> >> There is no bug. The syncrepl consumer is working as designed. If you want >> the consumer's entries to be automatically overwritten, create the consumer >> first so that its seed entries have older timestamps than the provider. > > ok, it works as designed. I just didn't know what the design was :-) > quoting man slapd: > Use only the rid part to force a full reload. > I guess I didn't notice that the word "full" have a different meaning > here than usual > > about creating the consumer first. you are kidding, right? in > production, the provider exists long before the consumer is set up. > the tests I do are based on the production state. > > anyway, my automated scripts "touch" the provider after setting up the > slave, so this is not a problem. > It's just that I would prefer not to have wasted time wondering why > the slave was not being updated even though I asked for a "full" > reload > > Thanks for your answer. It's now clearer in my mind. > I Cc the openldap-technical list, this can help others. > >> >>> note: the tests below require 2 VMs, or running the two slapd instances in >>> chroots, because a clone replica requires the data files to be in the same >>> path... >> >> >> That's far overkill. All you need to do is configure your test scripts to >> use relative pathnames. test049 (and others) in the test suite already >> operates this way. > > ok thanks for pointing this out > It has been a while since I read the tests scripts. I should have paid > more attention... > >> >> Closing this ITS. >> >>> I attach two scripts to replicate the problem. they require root (they >>> uses >>> chroots) >>> this is with openldap 2.4.39 on debian squeeze. some paths may have to be >>> fixed >>> in the scripts below >>> >>> use jclain-20140419-0start.sh to: >>> - create a ldap server to be served on ldap://localhost:3890 >>> - start the master in chroot >>> (the logs are in /jclain-slapd-test/master.data/slapd.log) >>> - create a seed ldap replica to be served on ldap://localhost:3891 with >>> ldap://localhost:3890 as the provider >>> - start it in chroot with option -c rid=0 >>> (the logs are in /jclain-slapd-test/slave.data/slapd.log) >>> >>> use jclain-20140419-1stop.sh to: >>> - stop the servers >>> - umount the chroots >>> >>> If I understand the manual correctly, after 0start.sh, the replica should >>> be >>> identical to the master thanks to -c rid=0 >>> BUT, the log on the replica says: >>> >>> 534d5481 dn_callback : new entry is older than ours cn=config ours >>> 20140415154713.807278Z#000000#000#000000, new >>> 20140415154704.888204Z#000000#000#000000 >>> >>> and indeed, the seed entries are NOT overwritten >>> I have to "touch" them on the master to force the replication. >>> >>> I have uploaded the scripts to http://jclain.fr/openldap-its/ >>> >>> thanks in advance >>> >>> -- Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

(ITS#7841) high disk utilization
by dmitrii.fonariuk＠gmail.com 21 Apr '14

21 Apr '14

Full_Name: Dmitrii Fonariuk Version: 2.4.38 OS: rhEL6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) There is a big value of DISK WRITE parameter in utility Iotop when in MDB a lot of Free pages (Freelist Status). Supposedly this situation arises from memory management algorithm. The algorithm FIFO is used for pages block allocation in free pages pool. We touched and dirty different pages on every modification transaction, which then flushed to disk by system process Flush. Perhaps it would be better to use the LIFO, which will to dirty the same pages by different transactions, which reduces the load on the disk? we use MDB with EnvFlags writemap and mapasync.

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 20 Apr '14

20 Apr '14

hello, thanks for your answer. see my response below 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: > Jephte.Clain(a)univ-reunion.fr wrote: >> >> Full_Name: Jephte CLAIN >> Version: 2.4.39 >> OS: Debian 6 64bits >> URL: http://jclain.fr/openldap-its/ >> Submission from: (NULL) (93.176.62.129) >> >> >> I have scripts to test several replication scenarii, that setup the LDAP >> environment then allow me to play with parameters as I see fit. >> >> I believe that there is a bug with the "seed replication" that allow one >> to >> build an exact clone of a master with minimal configuration on the slave >> side. > > > There is no bug. The syncrepl consumer is working as designed. If you want > the consumer's entries to be automatically overwritten, create the consumer > first so that its seed entries have older timestamps than the provider. ok, it works as designed. I just didn't know what the design was :-) quoting man slapd: Use only the rid part to force a full reload. I guess I didn't notice that the word "full" have a different meaning here than usual about creating the consumer first. you are kidding, right? in production, the provider exists long before the consumer is set up. the tests I do are based on the production state. anyway, my automated scripts "touch" the provider after setting up the slave, so this is not a problem. It's just that I would prefer not to have wasted time wondering why the slave was not being updated even though I asked for a "full" reload Thanks for your answer. It's now clearer in my mind. I Cc the openldap-technical list, this can help others. > >> note: the tests below require 2 VMs, or running the two slapd instances in >> chroots, because a clone replica requires the data files to be in the same >> path... > > > That's far overkill. All you need to do is configure your test scripts to > use relative pathnames. test049 (and others) in the test suite already > operates this way. ok thanks for pointing this out It has been a while since I read the tests scripts. I should have paid more attention... > > Closing this ITS. > >> I attach two scripts to replicate the problem. they require root (they >> uses >> chroots) >> this is with openldap 2.4.39 on debian squeeze. some paths may have to be >> fixed >> in the scripts below >> >> use jclain-20140419-0start.sh to: >> - create a ldap server to be served on ldap://localhost:3890 >> - start the master in chroot >> (the logs are in /jclain-slapd-test/master.data/slapd.log) >> - create a seed ldap replica to be served on ldap://localhost:3891 with >> ldap://localhost:3890 as the provider >> - start it in chroot with option -c rid=0 >> (the logs are in /jclain-slapd-test/slave.data/slapd.log) >> >> use jclain-20140419-1stop.sh to: >> - stop the servers >> - umount the chroots >> >> If I understand the manual correctly, after 0start.sh, the replica should >> be >> identical to the master thanks to -c rid=0 >> BUT, the log on the replica says: >> >> 534d5481 dn_callback : new entry is older than ours cn=config ours >> 20140415154713.807278Z#000000#000#000000, new >> 20140415154704.888204Z#000000#000#000000 >> >> and indeed, the seed entries are NOT overwritten >> I have to "touch" them on the master to force the replication. >> >> I have uploaded the scripts to http://jclain.fr/openldap-its/ >> >> thanks in advance >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- cordialement, Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by hyc＠symas.com 19 Apr '14

19 Apr '14

Jephte.Clain(a)univ-reunion.fr wrote: > Full_Name: Jephte CLAIN > Version: 2.4.39 > OS: Debian 6 64bits > URL: http://jclain.fr/openldap-its/ > Submission from: (NULL) (93.176.62.129) > > > I have scripts to test several replication scenarii, that setup the LDAP > environment then allow me to play with parameters as I see fit. > > I believe that there is a bug with the "seed replication" that allow one to > build an exact clone of a master with minimal configuration on the slave side. There is no bug. The syncrepl consumer is working as designed. If you want the consumer's entries to be automatically overwritten, create the consumer first so that its seed entries have older timestamps than the provider. > note: the tests below require 2 VMs, or running the two slapd instances in > chroots, because a clone replica requires the data files to be in the same > path... That's far overkill. All you need to do is configure your test scripts to use relative pathnames. test049 (and others) in the test suite already operates this way. Closing this ITS. > I attach two scripts to replicate the problem. they require root (they uses > chroots) > this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed > in the scripts below > > use jclain-20140419-0start.sh to: > - create a ldap server to be served on ldap://localhost:3890 > - start the master in chroot > (the logs are in /jclain-slapd-test/master.data/slapd.log) > - create a seed ldap replica to be served on ldap://localhost:3891 with > ldap://localhost:3890 as the provider > - start it in chroot with option -c rid=0 > (the logs are in /jclain-slapd-test/slave.data/slapd.log) > > use jclain-20140419-1stop.sh to: > - stop the servers > - umount the chroots > > If I understand the manual correctly, after 0start.sh, the replica should be > identical to the master thanks to -c rid=0 > BUT, the log on the replica says: > > 534d5481 dn_callback : new entry is older than ours cn=config ours > 20140415154713.807278Z#000000#000#000000, new > 20140415154704.888204Z#000000#000#000000 > > and indeed, the seed entries are NOT overwritten > I have to "touch" them on the master to force the replication. > > I have uploaded the scripts to http://jclain.fr/openldap-its/ > > thanks in advance > > -- -- 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#7840) bug with initial/seed syncrepl
by Jephte.Clain＠univ-reunion.fr 19 Apr '14

19 Apr '14

Full_Name: Jephte CLAIN Version: 2.4.39 OS: Debian 6 64bits URL: http://jclain.fr/openldap-its/ Submission from: (NULL) (93.176.62.129) I have scripts to test several replication scenarii, that setup the LDAP environment then allow me to play with parameters as I see fit. I believe that there is a bug with the "seed replication" that allow one to build an exact clone of a master with minimal configuration on the slave side. note: the tests below require 2 VMs, or running the two slapd instances in chroots, because a clone replica requires the data files to be in the same path... I attach two scripts to replicate the problem. they require root (they uses chroots) this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed in the scripts below use jclain-20140419-0start.sh to: - create a ldap server to be served on ldap://localhost:3890 - start the master in chroot (the logs are in /jclain-slapd-test/master.data/slapd.log) - create a seed ldap replica to be served on ldap://localhost:3891 with ldap://localhost:3890 as the provider - start it in chroot with option -c rid=0 (the logs are in /jclain-slapd-test/slave.data/slapd.log) use jclain-20140419-1stop.sh to: - stop the servers - umount the chroots If I understand the manual correctly, after 0start.sh, the replica should be identical to the master thanks to -c rid=0 BUT, the log on the replica says: 534d5481 dn_callback : new entry is older than ours cn=config ours 20140415154713.807278Z#000000#000#000000, new 20140415154704.888204Z#000000#000#000000 and indeed, the seed entries are NOT overwritten I have to "touch" them on the master to force the replication. I have uploaded the scripts to http://jclain.fr/openldap-its/ thanks in advance

1 0

Re: (ITS#7839) openldap libdb5 support
by michael＠stroeder.com 17 Apr '14

17 Apr '14

hyc(a)symas.com wrote: > Further footnote - this is why we recommend nss-pam-ldapd or nssov, which > fully isolates applications from the underlying nss/pam libraries. And why we > don't recommend SSSD. A shame they had to go off and reinvent the wheel > without actually fixing its underlying problems. Some people never learn. Hmm. AFAICT sssd also isolates from the nss/pam libraries. The pam_sss and libnss_sss modules also communicate with sssd over a Unix domain socket just like the other demons and accompanying modules you prefer do. Ciao, Michael.

1 0

Re: (ITS#7839) openldap libdb5 support
by hyc＠symas.com 17 Apr '14

17 Apr '14

quanah(a)zimbra.com wrote: > --On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote: > >> Full_Name: Marc Schildt >> Version: 2.4.24 - 2.4.39 > > The OpenLDAP project is in no way associated with the utterly broken builds > provided by Debian. I would note that you cannot simply change the version > of BDB that OpenLDAP is linked to and expect your database to work. You > *must* slapcat your db using the old version of BDB, then upgrade openldap, > then import with slapdd into the new build of OpenLDAP with the newer BDB. > Nothing in your report specifically sounds like an issue with OpenLDAP > itself. > > I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS > will be closed. As a footnote - you cannot have two versions of BDB linked into the same process and expect things to work. If changing the version of BDB that OpenLDAP is built with breaks SSSD, then you have a runtime linking problem, and again, that's something to take up with your distro. Not an OpenLDAP issue. Further footnote - this is why we recommend nss-pam-ldapd or nssov, which fully isolates applications from the underlying nss/pam libraries. And why we don't recommend SSSD. A shame they had to go off and reinvent the wheel without actually fixing its underlying problems. Some people never learn. -- -- 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#7839) openldap libdb5 support
by quanah＠zimbra.com 17 Apr '14

17 Apr '14

--On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote: > Full_Name: Marc Schildt > Version: 2.4.24 - 2.4.39 The OpenLDAP project is in no way associated with the utterly broken builds provided by Debian. I would note that you cannot simply change the version of BDB that OpenLDAP is linked to and expect your database to work. You *must* slapcat your db using the old version of BDB, then upgrade openldap, then import with slapdd into the new build of OpenLDAP with the newer BDB. Nothing in your report specifically sounds like an issue with OpenLDAP itself. I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7839) openldap libdb5 support
by marc.schildt＠idealo.de 17 Apr '14

17 Apr '14

Full_Name: Marc Schildt Version: 2.4.24 - 2.4.39 OS: Debian wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.162.49.126) Hello, we identified problems with the slapd version provided with debian wheezy. Our workstations are using sssd for auth against our openldap-server. The setup works well with slapd 2.4.23-7.3 on Debian squeeze. But, after building a new LDAP server on Debian wheezy, sssd stops working correctly and authentification of the workstations is not working anymore. Debian wheezy is using the slapd 2.4.31-1+nmu2. The following sssd versions we had tested with on different OS: sssd.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms sssd-client.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms sssd 1.8.6-0ubuntu0.3 We then tried to self compile openldap on debian wheezy (source from openldap.org). >From openldap2.4.39 down to 2.4.24 the built packages still did not work correctly with sssd. Reaching 2.4.23, the source won't compile anymore. So, after checking the change log, we saw that in 2.4.24 support for Berkley DB 5.1 was introduced in the source and for 2.4.23, db4.8 is needed. We have then compiled the Berkley DB 4.8 source from debian squeeze on debian wheezy and 2.4.23 was compiling cleanly. And, surprise, the combination of openldap and sssd was working as expected. After this success, we continued with a rebuild of openldap 2.4.31-1+nmu2 against the newly installed libdb4.8-dev libs. And again, we happily seeing openldap 2.4.31-1+nmu2 (built against libdb4.8) working like a charm together with sssd. So, maybe there is a major problem with libdb5 support introduced in openldap version 2.4.24 ? slapd.conf: # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ######################### # Global Directives # ######################### # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/my.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb moduleload memberof moduleload refint # The maximum number of entries that is returned for a search operation sizelimit unlimited loglevel stats # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # Global ACL's access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * read ######################### # DB Directives # ######################### database hdb cachesize 20000 suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}123456 directory "/var/lib/ldap" checkpoint 1024 5 # INDEXING index default eq index objectClass,memberUid,uidNumber,gidNumber eq,pres index givenName,dc,displayName,distinguishedName eq,pres index cn,sn,mail,uid eq,pres,sub index member,memberOf,uniqueMember eq,pres # syncprov index entryUUID,entryCSN,ou eq index nisMapName,nisMapEntry eq,pres,sub # samba index sambaSID,sambaPrimaryGroupSID,sambaDomainName,sambaGroupType,sambaSIDList eq syncrepl rid="200" provider="ldaps://ldap-provider.example.com" searchbase="dc=example,dc=com" type="refreshAndPersist" retry="2 30 60 +" filter="objectClass=*" scope="sub" attrs="*,+" sizelimit="unlimited" timelimit="unlimited" binddn="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" bindmethod="simple" credentials="123456" tls_reqcert="allow" # DB ACL's access to * by dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" write by * break limits dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" size=unlimited time=unlimited access to attrs=sambaNTPassword by dn.exact="cn=sambaconnect,dc=example,dc=com" read by self write by * none limits dn.exact="cn=sambaconnect,dc=example,dc=com" size=unlimited time=unlimited access to attrs=userPassword,userPKCS12 by self write by * auth access to * by dn.exact="cn=accessuser,dc=example,dc=com" read by * break limits dn.exact="cn=accessuser,dc=example,dc=com" size=unlimited time=unlimited # Overlay Config overlay memberof memberof-refint true memberof-dangling error memberof-dn cn=memberof-overlay overlay refint refint_attributes member memberOf manager owner seeAlso refint_nothing cn=refinit.nothing,ou=system,dc=example,dc=com TLSCACertificateFile /etc/ldap/certs/ldap-ca.pem TLSCertificateFile /etc/ldap/certs/ldap-consumer2.example.com.pem TLSCertificateKeyFile /etc/ldap/certs/ldap-consumer2.example.com.key TLSVerifyClient allow sssd.conf: # # RESET SSS cache: # service sssd stop # rm /var/lib/sss/db/cache_* # service sssd start [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = INTERN [nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 50 entry_negative_timeout = 15 [pam] reconnection_retries = 3 offline_credentials_expiration = 30 offline_failed_login_attempts = 0 offline_failed_login_delay = 5 [domain/LDAP] enumerate = true cache_credentials = true id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://ldap-consumer2.example.com ldap_search_base = dc=example,dc=com ldap_tls_reqcert = allow ldap_tls_cacert = /etc/ssl/certs/ldap-ca.pem slapd_sssd_request_succsess.log → slapd 2.4.23-7.3 / libdb 4.8.30-2: Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 ACCEPT from IP=172.30.2.191:49845 (IP=0.0.0.0:636) Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 TLS established tls_ssf=128 ssf=128 Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN highestCommittedUSN Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 BIND dn="" method=128 Apr 15 17:43:45 ldap-slave slapd[1810]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 RESULT tag=97 err=0 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1000 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SEARCH RESULT tag=101 err=0 nentries=181 text= Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SEARCH RESULT tag=101 err=0 nentries=253 text= Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))" Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SEARCH RESULT tag=101 err=0 nentries=22 text= Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 op=8 UNBIND Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 fd=17 closed slapd_sssd_request_no_succsess.log → slapd 2.4.31-1+nmu2 / libdb 5.1.29-5: Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 ACCEPT from IP=172.30.2.191:58270 (IP=0.0.0.0:636) Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 TLS established tls_ssf=128 ssf=128 Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN highestCommittedUSN Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 BIND dn="" method=128 Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 RESULT tag=97 err=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 op=10 UNBIND Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 fd=28 closed

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 16 Apr '14

16 Apr '14

One more thing to note: We see some coincidence between the seg faults and situations where the load on the machine goes up and number of pending threads in back-monitor had values in the range of 16 to 22 (threads is 16 for four cores).

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 15 Apr '14

15 Apr '14

Michael Ströder wrote: > On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote >> Can you run slapd with ElectricFence and post stack traces and diagnostics >> from any crashes there? > > Hmm, I will look into it. > But I'm a bit cautious running such a component in production. > Would running with MALLOC_CHECK_ be also reasonable helpful? Possibly using MALLOC_CHECK_=3 could give us a clue, yes. > > BTW: The configuration uses back-mdb. > > Another strange thing to note: > The archived syslog files revealed that the bind-DN rewriting is currently > *not* used by the LDAP clients at all. So I really wonder where it even calls > into slapo-rwm during normal operation. Good question. > > Ciao, Michael. > > > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 15 Apr '14

15 Apr '14

On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote > Can you run slapd with ElectricFence and post stack traces and diagnostics > from any crashes there? Hmm, I will look into it. But I'm a bit cautious running such a component in production. Would running with MALLOC_CHECK_ be also reasonable helpful? BTW: The configuration uses back-mdb. Another strange thing to note: The archived syslog files revealed that the bind-DN rewriting is currently *not* used by the LDAP clients at all. So I really wonder where it even calls into slapo-rwm during normal operation. Ciao, Michael.

1 0

Re: (ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

----==c72dbb1057ded1e9651a6f0c83ebf46f Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit Attached a patch against git master. Hopefully I did not mess up the ppolicy.ldif with the wrapped lines. I, Michael Ströder, hereby place the attached 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. ----==c72dbb1057ded1e9651a6f0c83ebf46f Content-Type: text/x-patch; name="openldap-its-7838.patch" Content-Disposition: attachment; filename="openldap-its-7838.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZiBiL3NlcnZlcnMv c2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZgppbmRleCBiMmYzODY3Li5mYTEwYjg4IDEwMDY0NAot LS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LmxkaWYKKysrIGIvc2VydmVycy9zbGFw ZC9zY2hlbWEvcHBvbGljeS5sZGlmCkBAIC0zNSwyOCArMzUsMzcgQEAgY246IHBwb2xpY3kKIG9s Y0F0dHJpYnV0ZVR5cGVzOiB7MH0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjEgTkFNRSAncHdk QXR0cmlidXRlJyBFUVVBTElUWQogICBvYmplY3RJZGVudGlmaWVyTWF0Y2ggU1lOVEFYIDEuMy42 LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjM4ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MX0oIDEuMy42 LjEuNC4xLjQyLjIuMjcuOC4xLjIgTkFNRSAncHdkTWluQWdlJyBFUVVBTElUWSBpbgotIHRlZ2Vy TWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSAp CisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYu MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5 cGVzOiB7Mn0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjMgTkFNRSAncHdkTWF4QWdlJyBFUVVB TElUWSBpbgotIHRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3 IFNJTkdMRS1WQUxVRSApCisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRj aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkK IG9sY0F0dHJpYnV0ZVR5cGVzOiB7M30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQgTkFNRSAn cHdkSW5IaXN0b3J5JyBFUVVBTElUWQotICBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x LjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgIGludGVnZXJNYXRjaCBPUkRFUklO RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEK KyAgLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezR9KCAxLjMuNi4xLjQu MS40Mi4yLjI3LjguMS41IE5BTUUgJ3B3ZENoZWNrUXVhbGl0eScgRVFVQUwKLSBJVFkgaW50ZWdl ck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUg KQorIElUWSBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggU1lOVEFY IDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyCisgMS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRy aWJ1dGVUeXBlczogezV9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42IE5BTUUgJ3B3ZE1pbkxl bmd0aCcgRVFVQUxJVFkKLSAgaW50ZWdlck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjEx NS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorICBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdl ck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuCisgIDEuMjcg U0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7Nn0oIDEuMy42LjEuNC4xLjQyLjIu MjcuOC4xLjcgTkFNRSAncHdkRXhwaXJlV2FybmluZycgRVFVQQotIExJVFkgaW50ZWdlck1hdGNo IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorIExJ VFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBTWU5UQVggMS4z LjYuMS40LjEuMTQ2Ni4xMTUuCisgMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0 ZVR5cGVzOiB7N30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjggTkFNRSAncHdkR3JhY2VBdXRo TkxpbWl0JyBFUQotIFVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYu MTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgVUFMSVRZIGludGVnZXJNYXRjaCBPUkRFUklO RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTEKKyA1LjEy MS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezh9KCAxLjMuNi4xLjQu MS40Mi4yLjI3LjguMS45IE5BTUUgJ3B3ZExvY2tvdXQnIEVRVUFMSVRZIGIKICBvb2xlYW5NYXRj aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuNyBTSU5HTEUtVkFMVUUgKQogb2xj QXR0cmlidXRlVHlwZXM6IHs5fSggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTAgTkFNRSAncHdk TG9ja291dER1cmF0aW9uJyBFCi0gUVVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEu NC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgUVVBTElUWSBpbnRlZ2VyTWF0 Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2 LjEKKyAxNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQogb2xjQXR0cmlidXRlVHlwZXM6IHsxMH0o IDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExIE5BTUUgJ3B3ZE1heEZhaWx1cmUnIEVRVUFMCi0g SVRZIGludGVnZXJNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcgU0lO R0xFLVZBTFVFICkKKyBJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01h dGNoICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMQorIDIxLjEuMjcgU0lOR0xFLVZBTFVF ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTF9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMiBO QU1FICdwd2RGYWlsdXJlQ291bnRJbnRlcgotIHZhbCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIFNZ TlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgCi0gKQorIHZh bCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBT WU5UQVggMS4zLjYuMS40LjEuCisgMTQ2Ni4xMTUuMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9s Y0F0dHJpYnV0ZVR5cGVzOiB7MTJ9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMyBOQU1FICdw d2RNdXN0Q2hhbmdlJyBFUVVBTAogIElUWSBib29sZWFuTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x LjE0NjYuMTE1LjEyMS4xLjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTN9 KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xNCBOQU1FICdwd2RBbGxvd1VzZXJDaGFuZ2UnIApk aWZmIC0tZ2l0IGEvc2VydmVycy9zbGFwZC9zY2hlbWEvcHBvbGljeS5zY2hlbWEgYi9zZXJ2ZXJz L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQppbmRleCA2YzVmYjcwLi5hYjE1NTgzIDEwMDY0 NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQorKysgYi9zZXJ2ZXJz L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQpAQCAtMTEwLDYgKzExMCw3IEBAIGF0dHJpYnV0 ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xCiBhdHRyaWJ1dGV0eXBlICggMS4zLjYu MS40LjEuNDIuMi4yNy44LjEuMgogICAgICAgTkFNRSAncHdkTWluQWdlJwogICAgICAgRVFVQUxJ VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM VUUgKQogCkBAIC0xMjUsNiArMTI2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy LjIuMjcuOC4xLjIKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4zCiAg ICAgICBOQU1FICdwd2RNYXhBZ2UnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAg IE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEu MTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE0MCw2ICsxNDIs NyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMwogYXR0cmlidXRl dHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQKICAgICAgIE5BTUUgJ3B3ZEluSGlzdG9y eScKICAgICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9y ZGVyaW5nTWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwog ICAgICAgU0lOR0xFLVZBTFVFICkKIApAQCAtMTY2LDYgKzE2OSw3IEBAIGF0dHJpYnV0ZXR5cGUg KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS40CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEu NDIuMi4yNy44LjEuNQogICAgICAgTkFNRSAncHdkQ2hlY2tRdWFsaXR5JwogICAgICAgRVFVQUxJ VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM VUUgKQogCkBAIC0xODIsNiArMTg2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy LjIuMjcuOC4xLjUKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42CiAg ICAgICBOQU1FICdwd2RNaW5MZW5ndGgnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAg ICAgIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40 LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE5OCw2ICsy MDMsNyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNgogYXR0cmli dXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjcKICAgICAgIE5BTUUgJ3B3ZEV4cGly ZVdhcm5pbmcnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAgIE9SREVSSU5HIGlu dGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIx LjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTIxMCw2ICsyMTYsNyBAQCBhdHRyaWJ1 dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNwogYXR0cmlidXRldHlwZSAoIDEuMy42 LjEuNC4xLjQyLjIuMjcuOC4xLjgKICAgICAgIE5BTUUgJ3B3ZEdyYWNlQXV0aE5MaW1pdCcKICAg ICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5n TWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAg U0lOR0xFLVZBTFVFICkKIApAQCAtMjQxLDYgKzI0OCw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMu Ni4xLjQuMS40Mi4yLjI3LjguMS45CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4y Ny44LjEuMTAKICAgICAgIE5BTUUgJ3B3ZExvY2tvdXREdXJhdGlvbicKICAgICAgIEVRVUFMSVRZ IGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2gKICAgICAg IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAgU0lOR0xFLVZBTFVF ICkKIApAQCAtMjU0LDYgKzI2Miw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4y LjI3LjguMS4xMAogYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiAg ICAgICBOQU1FICdwd2RNYXhGYWlsdXJlJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisg ICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEu NC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCkBAIC0yNjksNiAr Mjc4LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiBhdHRy aWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTIKICAgICAgIE5BTUUgJ3B3ZEZh aWx1cmVDb3VudEludGVydmFsJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisgICAgICBP UkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0 NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCg== ----==c72dbb1057ded1e9651a6f0c83ebf46f--

1 0

(ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

Full_Name: Version: HEAD and RE24 OS: URL: Submission from: (NULL) (212.227.35.93) For search pwdPolicy entries with certain parameters it would be handy to be able to search e.g. with (pwdMaxAge>=1). Therefore ORDERING integerOrderingMatch should be added to all Integer attribute types in ppolicy.schema and ppolicy.ldif.

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 15 Apr '14

15 Apr '14

Michael Ströder wrote: > hyc(a)symas.com wrote: >>> slapd occasionally seg faults. >>> We can't reproduce it with a certain configuration. >>> >>> This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 >>> linked against OpenSSL under a separate prefix. >>> >>> slapo-rwm is patched according to ITS#7723 but I can't tell whether >>> it's related to ITS#7723 or not. Hence the separate ITS. >> >> What behavior do you get by reverting the #7723 patch? > > The patch was applied because we had these seg faults before. > I'd rather say nothing changed in our case with the patch. > Crashes happen once or twice a week or so. > Also it was impossible to crash the non-patched installation with a test > script acting like described in ITS#7723. > > Fixing this would be highly appreciated but I can't provide a simple config > reproducing it. Can you run slapd with ElectricFence and post stack traces and diagnostics from any crashes there? > > The following rwm directives are in the frontend part: > > overlay rwm > rwm-rewriteEngine on > rwm-drop-unrequested-attrs no > # uid=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (uid=foo) > rwm-rewriteMap slapd uid2dn "ldap:///ou=xxxxx?entryDN?sub?" > rwm-rewriteContext bindDN > rwm-rewriteRule "^(uid=[^,]+),ou=xxxxx$" "${uid2dn($1)}" ":@I" > # serverFqdn=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching > (serverFqdn=foo) > rwm-rewriteMap slapd fqdn2dn "ldap:///ou=xxxxx?entryDN?sub?" > rwm-rewriteContext bindDN > rwm-rewriteRule "^(serverFqdn=[^,]+),ou=xxxxx$" "${fqdn2dn($1)}" ":@I" > > In a former configuration version these directives were in the backend > ou=xxxxx part. Because of the seg faults I moved it which made things slightly > better but hard to tell. In another configuration variant I even experienced > seg faults with *slapcat*. > > This is a two-layer replication topology with several MMR providers and > read-only consumers which use SASL/EXTERNAL with client certs for > authentication and authz-regexp mapping to authz-DNs. If things are wrong > during consumer initialization sometimes even the providers crashes. > > Ciao, Michael. > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 14 Apr '14

14 Apr '14

hyc(a)symas.com wrote: >> slapd occasionally seg faults. >> We can't reproduce it with a certain configuration. >> >> This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 >> linked against OpenSSL under a separate prefix. >> >> slapo-rwm is patched according to ITS#7723 but I can't tell whether >> it's related to ITS#7723 or not. Hence the separate ITS. > > What behavior do you get by reverting the #7723 patch? The patch was applied because we had these seg faults before. I'd rather say nothing changed in our case with the patch. Crashes happen once or twice a week or so. Also it was impossible to crash the non-patched installation with a test script acting like described in ITS#7723. Fixing this would be highly appreciated but I can't provide a simple config reproducing it. The following rwm directives are in the frontend part: overlay rwm rwm-rewriteEngine on rwm-drop-unrequested-attrs no # uid=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (uid=foo) rwm-rewriteMap slapd uid2dn "ldap:///ou=xxxxx?entryDN?sub?" rwm-rewriteContext bindDN rwm-rewriteRule "^(uid=[^,]+),ou=xxxxx$" "${uid2dn($1)}" ":@I" # serverFqdn=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (serverFqdn=foo) rwm-rewriteMap slapd fqdn2dn "ldap:///ou=xxxxx?entryDN?sub?" rwm-rewriteContext bindDN rwm-rewriteRule "^(serverFqdn=[^,]+),ou=xxxxx$" "${fqdn2dn($1)}" ":@I" In a former configuration version these directives were in the backend ou=xxxxx part. Because of the seg faults I moved it which made things slightly better but hard to tell. In another configuration variant I even experienced seg faults with *slapcat*. This is a two-layer replication topology with several MMR providers and read-only consumers which use SASL/EXTERNAL with client certs for authentication and authz-regexp mapping to authz-DNs. If things are wrong during consumer initialization sometimes even the providers crashes. Ciao, Michael.

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 14 Apr '14

14 Apr '14

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: 2.4.39 with patches > OS: > URL: > Submission from: (NULL) (212.227.35.93) > > > slapd occasionally seg faults. > We can't reproduce it with a certain configuration. > > This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 > linked against OpenSSL under a separate prefix. > > slapo-rwm is patched according to ITS#7723 but I can't tell whether > it's related to ITS#7723 or not. Hence the separate ITS. What behavior do you get by reverting the #7723 patch? > > master commit for the reference counting patch used: > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=5f524c44… > > Here's the stack trace (obfuscated filter and search base): > > Program terminated with signal 11, Segmentation fault. > #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt full > #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #1 0x00000000004f776b in rewrite_var_cmp (c1=0x7f8abaffb680, c2=0x7f8a884fba80) > at var.c:43 > v1 = 0x7f8abaffb680 > v2 = 0x7f8a884fba80 > __PRETTY_FUNCTION__ = "rewrite_var_cmp" > #2 0x0000000000500920 in avl_find (root=0x7f8a892823b0, data=0x7f8abaffb680, > fcmp=0x4f76a8 <rewrite_var_cmp>) at avl.c:545 > cmp = 0 > #3 0x00000000004f797e in rewrite_var_find (tree=0x7f8a892823b0, > name=0x7f8c9ff4b319 "searchFilter") at var.c:115 > var = {lv_name = 0x7f8c9ff4b319 "searchFilter", lv_flags = -1534643252, > lv_value = {bv_len = 140233568059984, bv_val = 0x7f8a89523fa0 ""}} > __PRETTY_FUNCTION__ = "rewrite_var_find" > #4 0x00000000004f5f51 in rewrite_session_var_set_f (info=0x1b4f770, > cookie=0x7f8c9fee2510, name=0x7f8c9ff4b319 "searchFilter", > value=0x7f8aac1d93a0 > "(&(member=uid=xxxxx,cn=yyyyy,ou=zzzzz)(objectClass=posixGroup)(cn=*))", > flags=15) at session.c:222 > session = 0x7f8a89523f90 > var = 0x1ffb > __PRETTY_FUNCTION__ = "rewrite_session_var_set_f" > #5 0x00007f8c9ff41836 in rwm_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) > at rwm.c:955 > on = 0x1b4f530 > rwmap = 0x1b4f710 > rc = 32652 > dc = {rwmap = 0x7f8abaffb960, conn = 0x0, ctx = 0xffffffffffffffa8 > <Address 0xffffffffffffffa8 out of bounds>, rs = 0x2e90e50} > fstr = {bv_len = 0, bv_val = 0x0} > f = 0x0 > an = 0x0 > text = 0x0 > roc = 0x7f8aac1d95e8 > #6 0x00000000004cf13b in overlay_op_walk (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, > which=op_search, oi=0x1b4d270, on=0x1b4f530) at backover.c:661 > func = 0x1b4f588 > rc = 32768 > #7 0x00000000004cf3ef in over_op_func (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, > which=op_search) at backover.c:723 > oi = 0x1b4d270 > on = 0x1b4f530 > be = 0x772340 > db = {bd_info = 0x1b4f530, bd_self = 0x772340, be_ctrls = "\000", '\001' > <repeats 16 times>, '\000' <repeats 15 times>, be_flags = 131840, be_restrictops > = 0, be_requires = 19, be_ssf_set = { > sss_ssf = 128, sss_transport = 0, sss_tls = 0, sss_sasl = 0, > sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, > sss_update_sasl = 0, sss_simple_bind = 0}, > be_suffix = 0x1acae40, be_nsuffix = 0x1acae90, be_schemadn = {bv_len = > 12, bv_val = 0x1ba32d0 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = > 0x1ba2c80 "cn=subschema"}, be_rootdn = { > bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, > be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = > {lms_t_soft = 3600, lms_t_hard = 0, > lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = > 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1b54bd0, > be_dfltaccess = ACL_READ, > be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, > be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = > {__lock = 0, __count = 0, __owner = 0, __nusers = 0, > __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, > __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = > 0x0, be_cf_ocs = 0x768e88, be_private = 0x0, > be_next = {stqe_next = 0x1acaee0}} > cb = {sc_next = 0x0, sc_response = 0x4ce266 <over_back_response>, > sc_cleanup = 0, sc_private = 0x1b4d270} > sc = 0x7f8aac1d9578 > rc = 32768 > __PRETTY_FUNCTION__ = "over_op_func" > #8 0x00000000004cf4cf in over_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) > at backover.c:750 > No locals. > #9 0x0000000000440982 in do_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at > search.c:247 > base = {bv_len = 8, bv_val = 0x7f8a8801d589 "ou=zzzzz"} > siz = 7 > off = 0 > i = 7 > #10 0x000000000043d2da in connection_operation (ctx=0x7f8abaffcba0, > arg_v=0x7f8aadb03a70) at connection.c:1155 > rc = 80 > cancel = 32650 > op = 0x7f8aadb03a70 > rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = > {sru_search = {r_entry = 0x0, r_attr_flags = 0, > r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref > = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata > = 0x0}}, sr_flags = 0} > tag = 99 > opidx = SLAP_OP_SEARCH > conn = 0x7f8c9fee2510 > memctx = 0x7f8aac028250 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #11 0x00007f8ca4871c81 in ldap_int_thread_pool_wrapper (xpool=0x1aa7f70) at > tpool.c:688 > pool = 0x1aa7f70 > task = 0x7f8aa57bb7a0 > work_list = 0x1aa8008 > ctx = {ltu_id = 140233819543296, ltu_key = {{ltk_key = 0x43ce31, > ltk_data = 0x7f8aac028140, ltk_free = 0x43cc83 <conn_counter_destroy>}, {ltk_key > = 0x4af7af, ltk_data = 0x7f8aac028250, > ltk_free = 0x4af5d4 <slap_sl_mem_destroy>}, {ltk_key = 0x1c58fc0, > ltk_data = 0x7f8aac024fb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, > {ltk_key = 0x7f8ca15b6b94, > ltk_data = 0x7f8a9f0f7010, ltk_free = 0x7f8ca15b6b4c > <scope_chunk_free>}, {ltk_key = 0x457c69, ltk_data = 0x7f8a88063040, ltk_free = > 0x457bbc <slap_op_q_destroy>}, { > ltk_key = 0x7f8ca15b9a39, ltk_data = 0x7f8a94be7010, ltk_free = > 0x7f8ca15b9a16 <search_stack_free>}, {ltk_key = 0x1c67c80, ltk_data = > 0x7f8ab46aadb0, > ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} > kctx = 0x0 > ---Type <return> to continue, or q <return> to quit--- > i = 32 > keyslot = 377 > hash = 3746453881 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #12 0x00007f8ca2feab50 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > No symbol table info available. > #13 0x00007f8ca2d350ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #14 0x0000000000000000 in ?? () > No symbol table info available. > > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 14 Apr '14

14 Apr '14

Full_Name: Michael Ströder Version: 2.4.39 with patches OS: URL: Submission from: (NULL) (212.227.35.93) slapd occasionally seg faults. We can't reproduce it with a certain configuration. This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 linked against OpenSSL under a separate prefix. slapo-rwm is patched according to ITS#7723 but I can't tell whether it's related to ITS#7723 or not. Hence the separate ITS. master commit for the reference counting patch used: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=5f524c44… Here's the stack trace (obfuscated filter and search base): Program terminated with signal 11, Segmentation fault. #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00000000004f776b in rewrite_var_cmp (c1=0x7f8abaffb680, c2=0x7f8a884fba80) at var.c:43 v1 = 0x7f8abaffb680 v2 = 0x7f8a884fba80 __PRETTY_FUNCTION__ = "rewrite_var_cmp" #2 0x0000000000500920 in avl_find (root=0x7f8a892823b0, data=0x7f8abaffb680, fcmp=0x4f76a8 <rewrite_var_cmp>) at avl.c:545 cmp = 0 #3 0x00000000004f797e in rewrite_var_find (tree=0x7f8a892823b0, name=0x7f8c9ff4b319 "searchFilter") at var.c:115 var = {lv_name = 0x7f8c9ff4b319 "searchFilter", lv_flags = -1534643252, lv_value = {bv_len = 140233568059984, bv_val = 0x7f8a89523fa0 ""}} __PRETTY_FUNCTION__ = "rewrite_var_find" #4 0x00000000004f5f51 in rewrite_session_var_set_f (info=0x1b4f770, cookie=0x7f8c9fee2510, name=0x7f8c9ff4b319 "searchFilter", value=0x7f8aac1d93a0 "(&(member=uid=xxxxx,cn=yyyyy,ou=zzzzz)(objectClass=posixGroup)(cn=*))", flags=15) at session.c:222 session = 0x7f8a89523f90 var = 0x1ffb __PRETTY_FUNCTION__ = "rewrite_session_var_set_f" #5 0x00007f8c9ff41836 in rwm_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at rwm.c:955 on = 0x1b4f530 rwmap = 0x1b4f710 rc = 32652 dc = {rwmap = 0x7f8abaffb960, conn = 0x0, ctx = 0xffffffffffffffa8 <Address 0xffffffffffffffa8 out of bounds>, rs = 0x2e90e50} fstr = {bv_len = 0, bv_val = 0x0} f = 0x0 an = 0x0 text = 0x0 roc = 0x7f8aac1d95e8 #6 0x00000000004cf13b in overlay_op_walk (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, which=op_search, oi=0x1b4d270, on=0x1b4f530) at backover.c:661 func = 0x1b4f588 rc = 32768 #7 0x00000000004cf3ef in over_op_func (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, which=op_search) at backover.c:723 oi = 0x1b4d270 on = 0x1b4f530 be = 0x772340 db = {bd_info = 0x1b4f530, bd_self = 0x772340, be_ctrls = "\000", '\001' <repeats 16 times>, '\000' <repeats 15 times>, be_flags = 131840, be_restrictops = 0, be_requires = 19, be_ssf_set = { sss_ssf = 128, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1acae40, be_nsuffix = 0x1acae90, be_schemadn = {bv_len = 12, bv_val = 0x1ba32d0 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x1ba2c80 "cn=subschema"}, be_rootdn = { bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1b54bd0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x768e88, be_private = 0x0, be_next = {stqe_next = 0x1acaee0}} cb = {sc_next = 0x0, sc_response = 0x4ce266 <over_back_response>, sc_cleanup = 0, sc_private = 0x1b4d270} sc = 0x7f8aac1d9578 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00000000004cf4cf in over_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at backover.c:750 No locals. #9 0x0000000000440982 in do_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at search.c:247 base = {bv_len = 8, bv_val = 0x7f8a8801d589 "ou=zzzzz"} siz = 7 off = 0 i = 7 #10 0x000000000043d2da in connection_operation (ctx=0x7f8abaffcba0, arg_v=0x7f8aadb03a70) at connection.c:1155 rc = 80 cancel = 32650 op = 0x7f8aadb03a70 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7f8c9fee2510 memctx = 0x7f8aac028250 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #11 0x00007f8ca4871c81 in ldap_int_thread_pool_wrapper (xpool=0x1aa7f70) at tpool.c:688 pool = 0x1aa7f70 task = 0x7f8aa57bb7a0 work_list = 0x1aa8008 ctx = {ltu_id = 140233819543296, ltu_key = {{ltk_key = 0x43ce31, ltk_data = 0x7f8aac028140, ltk_free = 0x43cc83 <conn_counter_destroy>}, {ltk_key = 0x4af7af, ltk_data = 0x7f8aac028250, ltk_free = 0x4af5d4 <slap_sl_mem_destroy>}, {ltk_key = 0x1c58fc0, ltk_data = 0x7f8aac024fb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x7f8ca15b6b94, ltk_data = 0x7f8a9f0f7010, ltk_free = 0x7f8ca15b6b4c <scope_chunk_free>}, {ltk_key = 0x457c69, ltk_data = 0x7f8a88063040, ltk_free = 0x457bbc <slap_op_q_destroy>}, { ltk_key = 0x7f8ca15b9a39, ltk_data = 0x7f8a94be7010, ltk_free = 0x7f8ca15b9a16 <search_stack_free>}, {ltk_key = 0x1c67c80, ltk_data = 0x7f8ab46aadb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 ---Type <return> to continue, or q <return> to quit--- i = 32 keyslot = 377 hash = 3746453881 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8ca2feab50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #13 0x00007f8ca2d350ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available.

1 0

(ITS#7836) Incorrect behavior with problematic LDAP server
by tarkhil＠over.ru 13 Apr '14

13 Apr '14

Full_Name: Alex Povolotsky Version: 2.4.36 OS: FreeBSD 9.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.178.228.111) Hello I'm using failover setup for my LDAP authentication === ldap.conf === BASE dc=org,dc=ru URI ldap://serv1 ldap://serv2 TIMEOUT 3 NETWORK_TIMEOUT 3 TIMELIMIT 3 SUDOERS_BASE ou=sudoers,dc= nss_base_passwd o=infotel,dc= pam_filter objectClass=posixAccount === Today, serv1 failed, become unaccessible but not down. I can connect to LDAP port, but server closes the connection immediately. In this case, second URI does not work. Any ldap tool fails ("Cannot connect to server"). Shutting down interface helped, but I suppose that there must be an option to try second URI on such an error.

1 0

(ITS#7835) slapadd should ignore comment lines in LDIF input
by michael＠stroeder.com 13 Apr '14

13 Apr '14

Full_Name: Version: HEAD OS: not relevant here URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.227.190.41) slapadd should be capable of reading LDIFv1 compliant files with comment lines. Currently it refuses to read/parse a LDIF file beginning with a comment line: 534a67f0 str2entry: entry -1 has no dn slapadd: could not parse entry (line=1)

1 0

(ITS#7834) MDB_MULTIPLE can insert multiple keys
by h.b.furuseth＠usit.uio.no 12 Apr '14

12 Apr '14

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.11 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.191.45.35) Submitted by: hallvard mdb_cursor_put(,new key, multiple data items, MDB_MULTIPLE) inserts several identical keys as well as multiple data items. Broken since 0.9.10 by 4c8f57615c5ca7b014c038e59c1045182e74f5ad. OpenLDAP is not affected, since it no longer uses MDB_MULTIPLE. Root cause: mdb_cursor_put() does not reset the 'insert' flag when looping through MDB_MULTIPLE. Recently it uses that flag to decode whether to delete the old key before re-inserting it. Also MDB_MULTIPLE breaks MDB_db.md_entries so mdb_stat() reports the wrong number of entries. This was always so. The 'insert' flag also affects cursor tracking. I have not checked how. Fix: Reset 'insert' before looping, and move setting C_INITIALIZED at 'done:' before that again. This should make MDB_MULTIPLE behave like a sequence of put()s, except it does not repeat spill/touch.

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by hyc＠symas.com 10 Apr '14

10 Apr '14

dcoutadeur(a)linagora.com wrote: > Full_Name: David Coutadeur > Version: 2.4.39 > OS: Debian wheezy 64 > URL: http://62.210.236.82/incoming/ppm-1.0.tar.gz > Submission from: (NULL) (92.103.166.6) > > > > Hi, > > I am proposing this module extending password policy for integration into > contrib/slapd-modules. (see URL attached) > > I get inspired by the ltb check password module, but I finally rewrote > everything from scratch to better include new functionnalities. > > You can consider this as a replacement for ITS Incoming/7412 > > The code has been tested a little, and a work has been done to make the code > cleaner, but do not hesitate for any suggestion or remark. I took a brief look at it. The config file syntax seems a bit awkward, how do you distinguish a new class name from an existing reserved keyword? I'd like to hear other people's opinion on the actual checks being performed. > David > > -- -- 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#7833) ldap client configuration issue
by hyc＠symas.com 10 Apr '14

10 Apr '14

prabhs(a)gmail.com wrote: > Full_Name: prabhakar > Version: 4.3 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.161.164.4) > > > When root file system is full, we are observing that ldap client file is getting > deleted. LDAP authentication failing, again we need to reconfigure the ldap > client. There is no such OpenLDAP version 4.3. > > Is there any way to overcome this issue. > > libsldap: Status: 2 Mesg: Unable to load configuration > '/var/ldap/ldap_client_file' (''). There is no such OpenLDAP component named libsldap. It appears you're not using OpenLDAP software at all. We're not the right people to help you. 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

(ITS#7833) ldap client configuration issue
by prabhs＠gmail.com 10 Apr '14

10 Apr '14

Full_Name: prabhakar Version: 4.3 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.161.164.4) When root file system is full, we are observing that ldap client file is getting deleted. LDAP authentication failing, again we need to reconfigure the ldap client. Is there any way to overcome this issue. libsldap: Status: 2 Mesg: Unable to load configuration '/var/ldap/ldap_client_file' ('').

1 0

Re: (ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by quanah＠zimbra.com 08 Apr '14

08 Apr '14

--On April 9, 2014 at 1:55:26 AM +0000 ryan(a)nardis.ca wrote: > Hi, > > This ITS says "fixed in master" and appears to be in 2.5 as well. > However 2.4 seems to still be affected. Is this fix a candidate for 2.4? It will be in 2.4.40 and is now in RE24. Thanks for catching that. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7500) libldap starttls crashes if invalid GnuTLS cipher suite string
by ryan＠nardis.ca 08 Apr '14

08 Apr '14

Hi, This ITS says "fixed in master" and appears to be in 2.5 as well. However 2.4 seems to still be affected. Is this fix a candidate for 2.4? thanks, Ryan

1 0

(ITS#7412)
by dcoutadeur＠linagora.com 04 Apr '14

04 Apr '14

Hi, Can you consider this alternative to replace ltb-check-password module into the contrib overlays ? (ITS#7832) Proposing ppolicy extended module for OpenLDAP http://www.openldap.org/its/index.cgi?findid=7832 Thank you in advance. David

1 0

(ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 04 Apr '14

04 Apr '14

Full_Name: David Coutadeur Version: 2.4.39 OS: Debian wheezy 64 URL: http://62.210.236.82/incoming/ppm-1.0.tar.gz Submission from: (NULL) (92.103.166.6) Hi, I am proposing this module extending password policy for integration into contrib/slapd-modules. (see URL attached) I get inspired by the ltb check password module, but I finally rewrote everything from scratch to better include new functionnalities. You can consider this as a replacement for ITS Incoming/7412 The code has been tested a little, and a work has been done to make the code cleaner, but do not hesitate for any suggestion or remark. David

1 0

(ITS#7831) Double Free in autogroup.c
by mwarren＠symas.com 04 Apr '14

04 Apr '14

Full_Name: Mark Warren Version: 2.4.38 OS: Ubuntu 12.04.4 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.70.80.130) A double-free has been located in contrib/slapd-modules/autogroup/autogroup.c Lines: 1208 and 1215 Proposed solution: Remove Line 1215 diff --git a/contrib/slapd-modules/autogroup/autogroup.c b/contrib/slapd-modules/autogroup/autogroup.c index a977561..5bafe2f 100644 --- a/contrib/slapd-modules/autogroup/autogroup.c +++ b/contrib/slapd-modules/autogroup/autogroup.c @@ -1212,7 +1212,6 @@ autogroup_response( Operation *op, SlapReply *rs ) autogroup_add_group( op, agi, group_agd, NULL, &op->o_req_ndn, 1, 1); - overlay_entry_release_ov( op, e, 0, on ); ldap_pvt_thread_mutex_unlock( &agi->agi_mutex ); return SLAP_CB_CONTINUE; }

1 0

Re: (ITS#7412) check_password contrib module
by hyc＠symas.com 04 Apr '14

04 Apr '14

clem.oudot(a)gmail.com wrote: > Full_Name: Clément OUDOT > Version: > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > As said by Guillaume Rousse in ITS#7348 ( > http://www.openldap.org/its/index.cgi/Incoming?id=7348;selectid=7348#themesg), I > would like to contribute the check_password module to OpenLDAP. > diff --git a/contrib/slapd-modules/check-password/README b/contrib/slapd-= > modules/check-password/README > new file mode 100644 > index 0000000..10191c2 > --- /dev/null > +++ b/contrib/slapd-modules/check-password/README > @@ -0,0 +1,146 @@ > + > +check_password.c - OpenLDAP pwdChecker library > + > +2007-06-06 Michael Steinmann <msl(a)calivia.com> > +2008-01-30 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> > +2009 Clement Oudot <clem.oudot(a)gmail.com> - LTB-project > +2009 Jerome HUET - LTB-project > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) were > developed by Clément OUDOT clem.oudot(a)gmail.com. I have not assigned rights > and/or interest in this work to any party. Something is not clear here. Your README clearly lists 3 other authors' names, yet your rights statement claims that you are the sole author. I don't see how we can safely touch this contribution with such ambiguous provenance. > > I, Clément OUDOT, 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#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 03 Apr '14

03 Apr '14

Another mdb_cursor_del() issue: If the next operation moves/peeks at the cursor position, it does not always reset the C_DEL flag: * mdb_cursor_put(,&existing_key,, MDB_APPEND or MDB_NOOVERWRITE) works like mdb_cursor_get(, &existing_key,, MDB_SET) but does not clear C_DEL. So MDB_NEXT after that stays at &existing_key. The enclosed program illustrates this: the MDB_NEXTs give different results after the cursor was positioned at "f". * I'm guessing mdb_cursor_count() should reset C_DEL on the main cursor: The mdb_cursor_del() semantics seems to be something like "the cursor moves to the next item, however if the next operation is an MDB_NEXT* operation then it also returns that item. So the manner you peek at the cursor position determines whether the the next item is "next" or "current". But I haven't thought carefully about C_DEL vs. DUPSORT cursors. BTW, mc->mc_flags &= ~C_DEL; would be a bit simpler than if (mc->mc_flags & C_DEL) mc->mc_flags ^= C_DEL; ################################################################ #include <stdio.h> #include <stdlib.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(void) { int rc, i; char ch, *act; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; MDB_cursor *cursor; MDB_cursor_op op; remove("test.mdb"); E(mdb_env_create(&env)); E(mdb_env_open(env, "test.mdb", MDB_NOSUBDIR, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, 0, &dbi)); E(mdb_cursor_open(txn, dbi, &cursor)); for (op=MDB_NEXT, act="NEXT";; op=MDB_GET_CURRENT, act="GET_CURRENT") { MDB_val key, data = {0, ""}; for (ch = 'a'; ch <= 'h'; ch++) E(mdb_cursor_put(cursor, &(MDB_val){1, &ch}, &data, 0)); for (i = 0; i < 2; i++) { E(mdb_cursor_get(cursor, &key, NULL, MDB_FIRST)); E(mdb_cursor_del(cursor, 0)); if (i == 0) { E(mdb_cursor_get(cursor, &(MDB_val){1, "f"}, NULL, MDB_SET)); } else { rc = mdb_cursor_put(cursor, &(MDB_val){1, "f"}, &data, MDB_NOOVERWRITE); /* C_DEL vs. MDB_NEXT bug? */ CHECK(rc == MDB_KEYEXIST, "no-overwrite"); } rc = mdb_cursor_get(cursor, &key, &data, op); if (rc == MDB_SUCCESS) printf("MDB_%s = %c\n", act, *(char *)key.mv_data); else printf("MDB_%s = %s\n", act, mdb_strerror(rc)); } if (op == MDB_GET_CURRENT) break; } mdb_txn_abort(txn); mdb_env_close(env); return 0; }

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 02 Apr '14

02 Apr '14

I wrote: > Nope. 69edafe28aef03b965c3d911be9ab8e340f914e1 "ITS#7829 more for > prev commit" breaks test054-syncreplication-parallel-load in RE24 > (with normal pagesize), every 2nd run or so. Or rather fca18d2586259c0e802d0276f86be696863b1905, not the ID I was using when bisecting:-)

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 02 Apr '14

02 Apr '14

Howard Chu writes: > Thanks, confirmed. In a nested rebalance, doing a page merge with the > neighbor on the left was discarding the rebalanced state. Fixed now in > mdb.master Nope. 69edafe28aef03b965c3d911be9ab8e340f914e1 "ITS#7829 more for prev commit" breaks test054-syncreplication-parallel-load in RE24 (with normal pagesize), every 2nd run or so. Running ./scripts/test054-syncreplication-parallel-load for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entry in the provider... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify provider directory... ldapmodify failed (80)! slapd.1.log says: 533bbaa2 mdb_modrdn: new ndn=cn=rosco p. coltrane,ou=retired,ou=people,dc=example,dc=com 533bbaa2 => mdb_dn2id("cn=rosco p. coltrane,ou=retired,ou=people,dc=example,dc=com") 533bbaa2 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 533bbaa2 => mdb_dn2id_delete 0x2a 533bbaa2 <= mdb_dn2id_delete 0x2a: -30798 533bbaa2 <=- mdb_modrdn: dn2id del failed: MDB_NOTFOUND: No matching key/data pair found (-30798) 533bbaa2 send_ldap_result: conn=1002 op=8 p=3 533bbaa2 send_ldap_result: err=80 matched="" text="DN index delete fail" This dn2id.c assert() would catch it. Passing -MDB_SET to catch it in a patched liblmdb before that. diff --git a/servers/slapd/back-mdb/dn2id.c b/servers/slapd/back-mdb/dn2id.c index ceacb17..8cb9d91 100644 --- a/servers/slapd/back-mdb/dn2id.c +++ b/servers/slapd/back-mdb/dn2id.c @@ -243,3 +243,4 @@ mdb_dn2id_delete( do { - rc = mdb_cursor_get( mc, &key, &data, MDB_SET ); + rc = mdb_cursor_get( mc, &key, &data, -MDB_SET ); + assert(!rc); if ( !rc ) { mdb.c fails at 1st assert, the rest is for handling -MDB_SET: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 10a8358..71b0b93 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -5348,2 +5348,3 @@ mdb_cursor_set(MDB_cursor *mc, MDB_val *key, MDB_val *data, rc = mc->mc_dbx->md_cmp(key, &nodekey); + mdb_cassert(mc, op != (MDB_cursor_op)-MDB_SET || rc >= 0 || mc->mc_top); if (rc == 0) { @@ -5460,3 +5461,3 @@ set1: if (F_ISSET(leaf->mn_flags, F_DUPDATA)) { - if (op == MDB_SET || op == MDB_SET_KEY || op == MDB_SET_RANGE) { + if (op == MDB_SET || op == (MDB_cursor_op)-MDB_SET || op == MDB_SET_KEY || op == MDB_SET_RANGE) { rc = mdb_cursor_first(&mc->mc_xcursor->mx_cursor, data, NULL); @@ -5651,2 +5652,3 @@ mdb_cursor_get(MDB_cursor *mc, MDB_val *key, MDB_val *data, case MDB_SET_RANGE: + case (MDB_cursor_op)-MDB_SET: if (key == NULL) { @@ -5747,2 +5749,3 @@ fetchm: DPRINTF(("unhandled/unimplemented cursor operation %u", op)); + mdb_cassert(mc, 0); /* just checking that we never get here */ rc = EINVAL; #2 mdb_assert_fail () #3 mdb_cursor_set (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281, exactp=0x7fabbf2761f0) at mdb.c:5349 #4 mdb_cursor_get (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281) at mdb.c:5657 #5 mdb_dn2id_delete (op=0x7fabb4000960, mc=0x7fabb4102bb0, id=42, nsubs=1) at dn2id.c:244 #6 mdb_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:476 #7 overlay_op_walk (op=0x7fabb4000960, rs=0x7fabbf276910, which=op_modrdn, oi=0x1c2c120, on=0x0) at backover.c:671 #8 over_op_func (op=0x7fabb4000960, rs, which) at backover.c:723 #9 fe_op_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:314 #10 do_modrdn (op=0x7fabb4000960, rs=0x7fabbf276910) at modrdn.c:186 #11 connection_operation (ctx=0x7fabbf276a70, arg_v=0x7fabb4000960) at connection.c:1155 #12 connection_read_thread (ctx=0x7fabbf276a70, argv) at connection.c:1291 #13 ldap_int_thread_pool_wrapper (xpool=0x1bd7370) at tpool.c:688 (gdb) frame 3 #3 mdb_cursor_set (mc=0x7fabb4102bb0, key=0x7fabbf276260, data=0x7fabbf276250, op=4294967281, exactp=0x7fabbf2761f0) at mdb.c:5349 5349 mdb_cassert(mc, op != (MDB_cursor_op)-MDB_SET || rc >= 0 || mc->mc_top); (gdb) info locals nodekey = {mv_size = 8, mv_data = 0x7fabb01092da} rc = -8 mp = 0x7fabb0108310 leaf = 0x7fabb01092d2 __FUNCTION__ = "mdb_cursor_set" (gdb) set output-radix 16 (gdb) p *mp $1 = {mp_p = {p_pgno = 0x51, p_next = 0x51}, mp_pad = 0x0, mp_flags = 0x12, mp_pb = {pb = {pb_lower = 0x44, pb_upper = 0xa2a}, pb_pages = 0xa2a0044}, mp_ptrs = {0xfc2}} (gdb) p *leaf $2 = {mn_lo = 0x2e, mn_hi = 0x0, mn_flags = 0x0, mn_ksize = 0x8, mn_data = "\020"} (gdb) p *(MDB_ID*)key->mv_data $3 = 0x8 (gdb) p *(MDB_ID*)nodekey.mv_data $4 = 0x10 -- Hallvard

1 0

Re: (ITS#7742) New: PBKDF2 module for OpenLDAP
by michael＠stroeder.com 01 Apr '14

01 Apr '14

hyc(a)symas.com wrote: > hamano(a)osstech.co.jp wrote: >> Full_Name: HAMANO Tsukasa >> Version: git master >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/0001-New-PBKDF2-module.patch >> Submission from: (NULL) (240b:10:2640:bf0:c1b8:b6c9:76f:8964) >> >> >> PBKDF2(RFC 2898) suport for OpenLDAP >> See README for details. > > Thanks for the submission, added to git master. Any chance to have this in upcoming 2.4.40? I've successfully tested it before in a local build. Ciao, Michael.

1 0

Re: (ITS#7742) New: PBKDF2 module for OpenLDAP
by hyc＠symas.com 01 Apr '14

01 Apr '14

hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/0001-New-PBKDF2-module.patch > Submission from: (NULL) (240b:10:2640:bf0:c1b8:b6c9:76f:8964) > > > PBKDF2(RFC 2898) suport for OpenLDAP > See README for details. Thanks for the submission, added to git master. > > -- > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > have not assigned rights and/or interest in this work to any party. > > Copyright 2013 HAMANO Tsukasa <hamano(a)osstech.co.jp> > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > -- -- 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#7829) MDB mdb_cursor_del causes records to be skipped
by armon.dadgar＠gmail.com 01 Apr '14

01 Apr '14

--533b042f_327b23c6_a8c6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree that it would be great to have MDB=5FNOT=46OUND returned instead of EINVAL. =46or my purposes, I needed a work around to the issue, and this seemed to work. Additionally because I=E2=80=99m in Go an= d not C, I cannot easily make use of the system definition for EINVAL. Best Regards, Armon Dadgar =46rom:=C2=A0Hallvard Breien =46uruseth h.b.furuseth=40usit.uio.no Reply:=C2=A0Hallvard Breien =46uruseth h.b.furuseth=40usit.uio.no Date:=C2=A0April 1, 2014 at 8:36:43 AM To:=C2=A0armon.dadgar=40gmail.com armon.dadgar=40gmail.com Cc:=C2=A0openldap-its=40openldap.org openldap-its=40openldap.org Subject:=C2=A0 Re: (ITS=237829) MDB mdb=5Fcursor=5Fdel causes records to = be skipped =20 On =46ri, 2014-03-28 at 04:58 +0000, armon.dadgar=40gmail.com wrote: =20 > I have a gist demonstrating this: https://gist.github.com/armon/9825666= =20 Some notes about this code: =20 // LMDB will return EINVAL(22) for the GET=5FCURRENT op if =20 // there is no further keys. We treat this as no more =20 // keys being found. =20 if num, ok :=3D err.(mdb.Errno); ok && num =3D=3D 22 =7B =20 println(=22errno 22=22) =20 err =3D mdb.Not=46ound =20 =7D =20 The value of EINVAL is OS-dependent, it need not be 22. =20 EINVAL means you did something wrong, it's a bad idea to =20 assume it means any particular wrong thing. =46or one thing, =20 mdb might not keep catching that error. I'd follow up =20 with a test check that there are indeed no more keys. =20 That said, mdb=5Fcursor=5Fdel() followed by MDB=5FGET=5FCURRENT =20 seems to me a sensible thing to want to do. So I think =20 MDB=5FGET=5FCURRENT should return MDB=5FNOT=46OUND here. And maybe =20 also after cursor=5Fnext() returned MDB=5FNOT=46OUND, and on an =20 empty DB. OTOH maybe cursors would need to keep more state =20 to tell this from user errors which should get EINVAL. =20 --533b042f_327b23c6_a8c6 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline <html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</= style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>I agree that it would = be great to have MDB=5FNOT=46OUND returned</div><div id=3D=22bloop=5Fcust= omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r= gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>instead of EINVAL. =46= or my purposes, I needed a work around to the</div><div id=3D=22bloop=5Fc= ustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color= : rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>issue, and this see= med to work. Additionally because I=E2=80=99m in Go and not</div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size= :13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22>C, I ca= nnot easily make use of the system definition for EINVAL.</div><div id=3D= =22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size= :13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></d= iv> <div id=3D=22bloop=5Fsign=5F1396376480489799936=22 class=3D=22bloop=5F= sign=22><div style=3D=22font-family:helvetica,arial;font-size:13px=22>Bes= t Regards,</div><div style=3D=22font-family:helvetica,arial;font-size:13p= x=22>Armon Dadgar<br></div></div> <div style=3D=22color:black=22><br>=46r= om: <span style=3D=22color:black=22>Hallvard Breien =46uruseth</span= > <a href=3D=22mailto:h.b.furuseth=40usit.uio.no=22>h.b.furuseth=40usit.u= io.no</a><br>Reply: <span style=3D=22color:black=22>Hallvard Breien = =46uruseth</span> <a href=3D=22mailto:h.b.furuseth=40usit.uio.no=22>h.b.f= uruseth=40usit.uio.no</a><br>Date: <span style=3D=22color:black=22>A= pril 1, 2014 at 8:36:43 AM</span><br>To: <span style=3D=22color:blac= k=22>armon.dadgar=40gmail.com</span> <a href=3D=22mailto:armon.dadgar=40g= mail.com=22>armon.dadgar=40gmail.com</a><br>Cc: <span style=3D=22col= or:black=22>openldap-its=40openldap.org</span> <a href=3D=22mailto:openld= ap-its=40openldap.org=22>openldap-its=40openldap.org</a><br>Subject:&nbsp= ;<span style=3D=22color:black=22> Re: (ITS=237829) MDB mdb=5Fcursor=5Fdel= causes records to be skipped <br></span></div><br> <blockquote type=3D=22= cite=22 class=3D=22clean=5Fbq=22><span><div><div></div><div>On =46ri, 201= 4-03-28 at 04:58 +0000, armon.dadgar=40gmail.com wrote: <br>> I have a gist demonstrating this: https://gist.github.com/armon/= 9825666 <br> <br>Some notes about this code: <br> // LMDB will return EINVAL(22) for the GET=5FCURRENT op if <br> // there is no further keys. We treat this as no more <br> // keys being found. <br> if num, ok :=3D err.(mdb.Errno); ok && num =3D=3D 22 =7B <br> println(=22errno 22=22) <br> err =3D mdb.Not=46ound <br> =7D <br> <br>The value of EINVAL is OS-dependent, it need not be 22. <br> <br>EINVAL means you did something wrong, it's a bad idea to <br>assume it means any particular wrong thing. =46or one thing, <br>mdb might not keep catching that error. I'd follow up <br>with a test check that there are indeed no more keys. <br> <br> <br>That said, mdb=5Fcursor=5Fdel() followed by MDB=5FGET=5FCURRENT <br>seems to me a sensible thing to want to do. So I think <br>MDB=5FGET=5FCURRENT should return MDB=5FNOT=46OUND here. And maybe <br>also after cursor=5Fnext() returned MDB=5FNOT=46OUND, and on an <br>empty DB. OTOH maybe cursors would need to keep more state <br>to tell this from user errors which should get EINVAL. <br> <br></div></div></span></blockquote></body></html> --533b042f_327b23c6_a8c6--

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 01 Apr '14

01 Apr '14

On Fri, 2014-03-28 at 04:58 +0000, armon.dadgar(a)gmail.com wrote: > I have a gist demonstrating this: https://gist.github.com/armon/9825666 Some notes about this code: // LMDB will return EINVAL(22) for the GET_CURRENT op if // there is no further keys. We treat this as no more // keys being found. if num, ok := err.(mdb.Errno); ok && num == 22 { println("errno 22") err = mdb.NotFound } The value of EINVAL is OS-dependent, it need not be 22. EINVAL means you did something wrong, it's a bad idea to assume it means any particular wrong thing. For one thing, mdb might not keep catching that error. I'd follow up with a test check that there are indeed no more keys. That said, mdb_cursor_del() followed by MDB_GET_CURRENT seems to me a sensible thing to want to do. So I think MDB_GET_CURRENT should return MDB_NOTFOUND here. And maybe also after cursor_next() returned MDB_NOTFOUND, and on an empty DB. OTOH maybe cursors would need to keep more state to tell this from user errors which should get EINVAL.

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by hyc＠symas.com 31 Mar '14

31 Mar '14

Hallvard Breien Furuseth wrote: > Sorry, forgot the crash info. Thanks, confirmed. In a nested rebalance, doing a page merge with the neighbor on the left was discarding the rebalanced state. Fixed now in mdb.master > > mdb.c:7419: Assertion 'NUMKEYS(mc->mc_pg[ptop]) > 1' failed in mdb_rebalance() > > (gdb) p *mc->mc_pg[ptop] > $1 = { > mp_p = {p_pgno = 24, p_next = 0x18}, mp_pad = 0, mp_flags = 17, > mp_pb = {pb = {pb_lower = 18, pb_upper = 1016}, pb_pages = 66584594}, > mp_ptrs = {1016} > } > (gdb) info locals > node = 0x0 > rc = -268443168 > ptop = 0 > minkeys = 1 > mn = { > mc_next = 0x7ffff5ce0010, mc_backup = 0x7fffe41013a0, mc_xcursor = 0x0, > mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, > mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42c3fb0 "\002", > mc_snum = 2, mc_top = 1, mc_flags = 65, > mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x2efffe300, 0x7fffefffe0c0, 0x7fffefffe0a0, 0x7fffefffe2c0, > 0x7fffefffe2c0, 0x53e7cd, 0x7fffefffe1c0, 0x7fffe40019f0, 0x7fffe41013a0, 0x7fffefffe2c0, 0x30c3669909, > 0xfbad8001, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe130, 0x7fffefffe2d0, 0x7fffefffe180, > 0x49c7ca, 0x7fffefffe140, 0x7fffefffe1dc, 0x1100000000, 0x0, 0x7fffefffe2d0, 0x7fffe4101528, 0x7fffefffe180, 0x1, > 0x7fffe81099d4, 0x7fffefffe260, 0x100000008}, > mc_ki = {5416, 58384, 32767, 0, 39380, 59408, 32767, 0, 39364, 59408, 32767, 0, 39400, 59408, 32767, 0, 39332, > 59408, 32767, 0, 68, 0, 0, 0, 15369, 50024, 48, 0, 57792, 61439, 32767, 0} > } > oldki = 0 > __FUNCTION__ = "mdb_rebalance" > (gdb) p *mc > $2 = { > mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7fffe4101528, > mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, > mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42cb3e6 "\t\n\n", > mc_snum = 2, mc_top = 1, mc_flags = 65, > mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x0, 0x40, 0x44, 0x0, 0x6a206e616d726568, 0x6f65703d756f2c72, > 0x653d63642c656c70, 0x642c656c706d6178, 0x302e006d6f633d63, 0x30235a3632353631, 0x2d1, 0x7fffe4000338, 0x81, > 0x7fffe4102c40, 0x7fffe42c7860, 0x20, 0x64, 0x0, 0x4, 0x1a, 0x19, 0x10, 0xe, 0xd, 0xb, 0xa, 0x9, 0x140, 0x84, > 0x0}, > mc_ki = {0, 5, 0, 0, 22160, 63214, 32767, 0, 32769, 0, 0, 0, 64592, 70, 0, 0, 22160, 63214, 32767, 0, 32775, 0, 0, > 0, 63424, 70, 0, 0, 22160, 63214, 32767, 0} > } > > Backtrace: > #2 mdb_assert_fail () > #3 mdb_rebalance (mc=0x7fffe41013a0) at mdb.c:7419 > #4 mdb_cursor_del0 (mc=0x7fffe41013a0) at mdb.c:7496 > #5 mdb_cursor_del (mc=0x7fffe41013a0, flags=0) at mdb.c:6360 > #6 mdb_idl_delete_keys (be, cursor=0x7fffe41013a0, keys, id=7) at idl.c:608 > #7 indexer (op=0x7fffe4000950, txn, ai, ad=0x838180, atname=0x837fc8, vals=0x7fffe40019f0, id=7, opid=2, mask=1814) at index.c:258 > #8 index_at_values (op=0x7fffe4000950, txn=0x7fffe42c9700, ad, type=0x837f60, tags=0x8381a0, vals=0x7fffe40019f0, id=7, opid=2) at index.c:337 > #9 mdb_index_values (op, txn, desc, vals, id, opid) at index.c:386 > #10 mdb_index_entry (op=0x7fffe4000950, txn=0x7fffe42c9700, opid=2, e=0x7fffe40017d0) at index.c:558 > #11 mdb_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:347 > #12 overlay_op_walk (op=0x7fffe4000950, rs=0x7fffefffe910, which=op_delete, oi=0x7fffe81036a0, on=0x0) at backover.c:671 > #13 over_op_func (op=0x7fffe4000950, rs, which) at backover.c:723 > #14 fe_op_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:174 > #15 do_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:95 > #16 connection_operation (ctx=0x7fffefffea70, arg_v=0x7fffe4000950) at connection.c:1155 > #17 connection_read_thread (ctx=0x7fffefffea70, argv) at connection.c:1291 > #18 ldap_int_thread_pool_wrapper (xpool=0x83b3b0) at tpool.c:688 > > Test output: > Running ldapadd to build slapd config database... > Running ldapadd to build slapd database... > Search the entire database... > Running ldapmodify to add a member... > Re-search the entire database... > Running ldapmodify to rename a member... > Re-search the entire database... > Running ldapmodify to rename a group... > Re-search the entire database... > Running ldapmodify to add self... > Re-search the entire database... > Running ldapdelete to remove a member... > Re-search the entire database... > Running ldapdelete to remove a group... > Re-search the entire database... > Adding groups with MAY member type schemas... > > Log ends with: > 533898e1 => index_entry_del( 7, "cn=Jessica Rabbit,ou=People,dc=example,dc=com" ) > 533898e1 mdb_idl_delete_keys: 7 [860433ad] > 533898e1 mdb_idl_delete_keys: 7 [00000000] > 533898e1 mdb_idl_delete_keys: 7 [aaacba45] > 533898e1 mdb_idl_delete_keys: 7 [e10d2617] > -- -- 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#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 30 Mar '14

30 Mar '14

Sorry, forgot the crash info. mdb.c:7419: Assertion 'NUMKEYS(mc->mc_pg[ptop]) > 1' failed in mdb_rebalance() (gdb) p *mc->mc_pg[ptop] $1 = { mp_p = {p_pgno = 24, p_next = 0x18}, mp_pad = 0, mp_flags = 17, mp_pb = {pb = {pb_lower = 18, pb_upper = 1016}, pb_pages = 66584594}, mp_ptrs = {1016} } (gdb) info locals node = 0x0 rc = -268443168 ptop = 0 minkeys = 1 mn = { mc_next = 0x7ffff5ce0010, mc_backup = 0x7fffe41013a0, mc_xcursor = 0x0, mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42c3fb0 "\002", mc_snum = 2, mc_top = 1, mc_flags = 65, mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x2efffe300, 0x7fffefffe0c0, 0x7fffefffe0a0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x53e7cd, 0x7fffefffe1c0, 0x7fffe40019f0, 0x7fffe41013a0, 0x7fffefffe2c0, 0x30c3669909, 0xfbad8001, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe2c0, 0x7fffefffe130, 0x7fffefffe2d0, 0x7fffefffe180, 0x49c7ca, 0x7fffefffe140, 0x7fffefffe1dc, 0x1100000000, 0x0, 0x7fffefffe2d0, 0x7fffe4101528, 0x7fffefffe180, 0x1, 0x7fffe81099d4, 0x7fffefffe260, 0x100000008}, mc_ki = {5416, 58384, 32767, 0, 39380, 59408, 32767, 0, 39364, 59408, 32767, 0, 39400, 59408, 32767, 0, 39332, 59408, 32767, 0, 68, 0, 0, 0, 15369, 50024, 48, 0, 57792, 61439, 32767, 0} } oldki = 0 __FUNCTION__ = "mdb_rebalance" (gdb) p *mc $2 = { mc_next = 0x0, mc_backup = 0x0, mc_xcursor = 0x7fffe4101528, mc_txn = 0x7fffe42c9700, mc_dbi = 6, mc_db = 0x7fffe42c9890, mc_dbx = 0x7fffe42c3fb0, mc_dbflag = 0x7fffe42cb3e6 "\t\n\n", mc_snum = 2, mc_top = 1, mc_flags = 65, mc_pg = {0x7fffe4102840, 0x7fffe8109670, 0x0, 0x40, 0x44, 0x0, 0x6a206e616d726568, 0x6f65703d756f2c72, 0x653d63642c656c70, 0x642c656c706d6178, 0x302e006d6f633d63, 0x30235a3632353631, 0x2d1, 0x7fffe4000338, 0x81, 0x7fffe4102c40, 0x7fffe42c7860, 0x20, 0x64, 0x0, 0x4, 0x1a, 0x19, 0x10, 0xe, 0xd, 0xb, 0xa, 0x9, 0x140, 0x84, 0x0}, mc_ki = {0, 5, 0, 0, 22160, 63214, 32767, 0, 32769, 0, 0, 0, 64592, 70, 0, 0, 22160, 63214, 32767, 0, 32775, 0, 0, 0, 63424, 70, 0, 0, 22160, 63214, 32767, 0} } Backtrace: #2 mdb_assert_fail () #3 mdb_rebalance (mc=0x7fffe41013a0) at mdb.c:7419 #4 mdb_cursor_del0 (mc=0x7fffe41013a0) at mdb.c:7496 #5 mdb_cursor_del (mc=0x7fffe41013a0, flags=0) at mdb.c:6360 #6 mdb_idl_delete_keys (be, cursor=0x7fffe41013a0, keys, id=7) at idl.c:608 #7 indexer (op=0x7fffe4000950, txn, ai, ad=0x838180, atname=0x837fc8, vals=0x7fffe40019f0, id=7, opid=2, mask=1814) at index.c:258 #8 index_at_values (op=0x7fffe4000950, txn=0x7fffe42c9700, ad, type=0x837f60, tags=0x8381a0, vals=0x7fffe40019f0, id=7, opid=2) at index.c:337 #9 mdb_index_values (op, txn, desc, vals, id, opid) at index.c:386 #10 mdb_index_entry (op=0x7fffe4000950, txn=0x7fffe42c9700, opid=2, e=0x7fffe40017d0) at index.c:558 #11 mdb_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:347 #12 overlay_op_walk (op=0x7fffe4000950, rs=0x7fffefffe910, which=op_delete, oi=0x7fffe81036a0, on=0x0) at backover.c:671 #13 over_op_func (op=0x7fffe4000950, rs, which) at backover.c:723 #14 fe_op_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:174 #15 do_delete (op=0x7fffe4000950, rs=0x7fffefffe910) at delete.c:95 #16 connection_operation (ctx=0x7fffefffea70, arg_v=0x7fffe4000950) at connection.c:1155 #17 connection_read_thread (ctx=0x7fffefffea70, argv) at connection.c:1291 #18 ldap_int_thread_pool_wrapper (xpool=0x83b3b0) at tpool.c:688 Test output: Running ldapadd to build slapd config database... Running ldapadd to build slapd database... Search the entire database... Running ldapmodify to add a member... Re-search the entire database... Running ldapmodify to rename a member... Re-search the entire database... Running ldapmodify to rename a group... Re-search the entire database... Running ldapmodify to add self... Re-search the entire database... Running ldapdelete to remove a member... Re-search the entire database... Running ldapdelete to remove a group... Re-search the entire database... Adding groups with MAY member type schemas... Log ends with: 533898e1 => index_entry_del( 7, "cn=Jessica Rabbit,ou=People,dc=example,dc=com" ) 533898e1 mdb_idl_delete_keys: 7 [860433ad] 533898e1 mdb_idl_delete_keys: 7 [00000000] 533898e1 mdb_idl_delete_keys: 7 [aaacba45] 533898e1 mdb_idl_delete_keys: 7 [e10d2617] -- Hallvard

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by h.b.furuseth＠usit.uio.no 30 Mar '14

30 Mar '14

hyc(a)symas.com writes: > Thanks for the report. Fixed now in mdb.master. That fix breaks test052-memberof with pagesize 1024. Unrealistic, but it's not a MAXKEYSIZE issue so it should not have made a difference. Tested with RE24 9e22d8f2cd5ed10cd1dd22acbd729a49e5ecc1ab + mdb.master~ or mdb.master ac3acc121855e4297d597a4d71e9863e1e1e2450 + this patch: diff --git a/libraries/liblmdb/lmdb.h b/libraries/liblmdb/lmdb.h index 2ebd43f..3f4a167 100644 --- a/libraries/liblmdb/lmdb.h +++ b/libraries/liblmdb/lmdb.h @@ -411,4 +411,4 @@ typedef enum MDB_cursor_op { /** Too big key/data, key is empty, or wrong DUPFIXED size */ -#define MDB_BAD_VALSIZE (-30781) -#define MDB_LAST_ERRCODE MDB_BAD_VALSIZE +#define MDB_BAD_VALSIZE (abort(),-30781) /* we don't hit MDB_MAXKEYSIZE */ +#define MDB_LAST_ERRCODE (-30781) /** @} */ diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 7e29058..ad9bfc6 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -405,3 +405,3 @@ static txnid_t mdb_debug_start; #ifndef MDB_MAXKEYSIZE -#define MDB_MAXKEYSIZE 511 +#define MDB_MAXKEYSIZE 400 /* max-max is 446 for psize=1024 on 64-bit hosts */ #endif @@ -3536,3 +3536,3 @@ mdb_env_open2(MDB_env *env) newenv = 1; - env->me_psize = env->me_os_psize; + env->me_psize = 1024; if (env->me_psize > MAX_PAGESIZE) -- Hallvard

1 0

Re: (ITS#7829) MDB mdb_cursor_del causes records to be skipped
by hyc＠symas.com 28 Mar '14

28 Mar '14

armon.dadgar(a)gmail.com wrote: > Full_Name: Armon Dadgar > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.78.97.10) > > > I have an issue where when iterating over data and deleting keys, the cursor > will incorrectly skip rows, and then returns an early NOTFOUND even though more > records still exist. > > I have a gist demonstrating this: https://gist.github.com/armon/9825666 > > I am using small Go wrapper around LMDB, version 0.9.11. > > The expected behavior is to numbers 1..91 printed. However, when I run it, > it gets to 16 and returns no further rows. > > Thanks for the report. Fixed now in mdb.master. -- -- 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#7825) LMDB: misleading error message
by timur.kristof＠gmail.com 28 Mar '14

28 Mar '14

On Fri Mar 28 2014 18:36:11 GMT+0100 (CET), Howard Chu wrote: > timur.kristof(a)gmail.com wrote: > > > Here's a small test case which will demonstrate it: > > http://pastebin.com/hHwD1srf > > As an aside, this is some pretty horrible code. Why are you using > MDB_GET_CURRENT after all of your cursor_get calls? It truly is horrendous. I wrote it in an attempt to (roughly) reproduce what one of my examples did in javascript. Then when I discovered what the issue really was, I forgot to clean it up before pastebinning. I hope it's still okay as a testcase for this bugreport :) > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Timur Sent from my Jolla

1 0

Re: (ITS#7825) LMDB: misleading error message
by hyc＠symas.com 28 Mar '14

28 Mar '14

timur.kristof(a)gmail.com wrote: > Here's a small test case which will demonstrate it: > http://pastebin.com/hHwD1srf As an aside, this is some pretty horrible code. Why are you using MDB_GET_CURRENT after all of your cursor_get calls? -- -- 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#7830) MDB Size grown a lot during massive updates and concurrent read access
by antonin.meunier＠cgi.com 28 Mar '14

28 Mar '14

Full_Name: Antonin Meunier Version: 2.4.39 OS: Red Hat 6.5 URL: Submission from: (NULL) (195.6.127.108) Ldap is set to a maximum MDB database size of 80GB. Ldap uses 20GB of effective Size. There are approximately 60 index , 1500000 peoples and 4500000 groups. The LDAP is accessed in read / write by about 20 tomcat. In parallel to this, update treatment (inject ldif) are started performing lots of massive upates (750 000, 500 000 groups). When processing the massives updates, the MDB size increases to the 80max and therefore the treatment plant updates. If I stop all tomcat, the problem no longer occurs. So it seems that the problem comes from locks that are placed on the pages of indexes and data by readers and force to create new pages for changes with conservation of all intermediate pages. After that, the only way to find a "normal" size is to export the ldap , delete it and re-import the backup. The LDAP database is then again 20GB

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs