openldap-bugs April 2014

openldap-bugs@openldap.org

18 participants
43 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2014