- openldap-bugs - openldap.org

(ITS#7414) rwm: ldapmodify, slapd segmentation fault
by jvcelak＠redhat.com 11 Oct '12

11 Oct '12

Full_Name: Jan Vcelak Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Hello, it is possible to crash slapd in certain configuration with rwm overlay enabled, using specific ldapmodify. This problem seems to be present for a very long time. Configuration used (slapd.ldif): dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib64/openldap olcModuleload: rwm.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: hdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub dn: olcOverlay=rwm,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: rwm olcRwmRewrite: {0}rwm-rewriteEngine "on" olcRwmRewrite: {1}rwm-rewriteContext "bindDN" olcRwmRewrite: {2}rwm-rewriteRule "cn=([a-z]+),ou=People,dc=my-domain,dc=com" "uid=$1,ou=People,dc=my-domain,dc=com" Set up and start the server. Add the initial data: dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organizationalUnit description: Root LDAP entry dc: my-domain ou: rootobject dn: cn=Manager,dc=my-domain,dc=com objectClass: organizationalRole cn: Manager dn: ou=People,dc=my-domain,dc=com objectClass: top objectClass: organizationalunit ou: People dn: cn=test1,ou=People,dc=my-domain,dc=com objectClass: inetOrgPerson cn: test1 sn: test Perform following modify operation: dn: cn=test1,ou=People,dc=my-domain,dc=com changetype: modrdn newrdn: cn=test2 deleteoldrdn: 1 newsuperior: ou=People,dc=my-domain,dc=com The slapd daemon will crash, here is the full backtrace: #0 rwm_op_rollback (op=op@entry=0x7fffe8000930, ros=0x7fffe8001738, rs=<optimized out>) at rwm.c:110 No locals. #1 0x00007ffff210f1c2 in rwm_op_cleanup (op=0x7fffe8000930, rs=<optimized out>) at rwm.c:165 cb = 0x7fffe8001718 ros = <optimized out> #2 0x00005555555a606b in slap_cleanup_play (op=op@entry=0x7fffe8000930, rs=rs@entry=0x7ffff1106930) at result.c:541 sc_next = 0x7ffff11065c0 sc_nextp = 0x7fffe8001718 sc = 0x7fffe8001718 scp = 0x7ffff1106018 #3 0x00005555555a6573 in send_ldap_response (op=op@entry=0x7fffe8000930, rs=rs@entry=0x7ffff1106930) at result.c:733 berbuf = { buffer = "\000\000\001\000\001\000\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 24 times>, "F\030\000\350\377\177\000\000\024(\000\350\377\177\000\000\000\000\000\000\000\000\000\000F\030\000\350\377\177\000\000\320\016\000\350\377\177\000\000P\373\275UUU\000\000\200v\357\367\377\177\000\000\001\000\000\000hw\001", '\000' <repeats 17 times>"\266, \252r\367\377\177", '\000' <repeats 11 times>, "a\370<\316m]\037\200*\227\367\377\177\000\000\001\000\000\000UU\000\000\321\323vP\000\000\000\000\350\n\000\350\377\177\000\000\003", '\000' <repeats 23 times>"\225, \362\227\367\311\362\245\303\000\000\000\000\000\000\000\000+\246fUUU\000\000\030ӿUUU\000\000\223\204+\366\377\177\000\000\060\065\020\350\377\177\000\000\000a\370<\316m]\037", ialign = 65536, lalign = 4295032832, falign = 9.18354962e-41, dalign = 2.1220281700514382e-314, palign = 0x100010000 <Address 0x100010000 out of bounds>} ber = <optimized out> rc = 32768 bytes = <optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #4 0x00005555555a7126 in slap_send_ldap_result (op=0x7fffe8000930, rs=0x7ffff1106930) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #5 0x0000555555621a50 in hdb_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:789 bdb = 0x5555559fa4f0 children = 0x55555599d260 entry = 0x55555599cfc0 p_dn = {bv_len = 29, bv_val = 0x7fffe8102399 "ou=People,dc=my-domain,dc=com"} p_ndn = {bv_len = 29, bv_val = 0x7fffe81023c9 ""} new_dn = {bv_len = 38, bv_val = 0x0} new_ndn = {bv_len = 38, bv_val = 0x0} e = <optimized out> p = <optimized out> ei = 0x7fffe8103f00 eip = 0x7fffe410a0a0 nei = 0x7fffe410a0a0 neip = 0x0 textbuf = "0\t\000\350\377\177\000\000\000e\020\361\377\177\000\000 i\237UUU\000\000\230\060\021\362\377\177\000\000\200\241^\366\377\177\000\000\000\000\000\000\316m]\037&\000\000\000\000\000\000\000\060\022\000\350\377\177\000\000\060\t\000\350\377\177\000\000\070\027\000\350\377\177\000\000\000\000\000\000\000\000\000\000)\323\020\362\377\177\000\000&\000\000\000\000\000\000\000\060\022\000\350\377\177\000\000&\000\000\000\000\000\000\000\270\022\000\350\377\177\000\000\000k\237UUU\000\000\000\352\242UUU\000\000\314X\021\362\377\177\000\000\060i\020\361\377\177\000\000\030\027\000\350\377\177\000\000\030\027\000\350\377\177\000\000\060i\020\361\377\177\000\000\332\326\020\362\377\177\000\000\360d\020\361\377\177\000\000\020e\020\361\377\177\000\000\b\000\000\000\000\000\000\000\270\023\000\350\377\177\000\000\b\000\000\000\000\000\000\000\350\023\000\350\377\177\000\000\000k\237UUU\000\000\000\352\242UUU\000" ltid = 0x0 lt2 = 0x7fffe81068f0 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x7fffe8106730, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 4, e_name = {bv_len = 38, bv_val = 0x7fffe8106890 "cn=test2,ou=People,dc=my-domain,dc=com"}, e_nname = { bv_len = 38, bv_val = 0x7fffe81068c0 "cn=test2,ou=people,dc=my-domain,dc=com"}, e_attrs = 0x0, e_ocflags = 256, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x7fffe8103f00} np = <optimized out> np_dn = <optimized out> np_ndn = <optimized out> new_parent_dn = <optimized out> manageDSAit = 0 lock = {off = 164424, ndx = 98, gen = 2, mode = DB_LOCK_WRITE} plock = {off = 157848, ndx = 932, gen = 2, mode = DB_LOCK_READ} nplock = {off = 0, ndx = 1436511616, gen = 21845, mode = 4044383224} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x555555a2ea00, 0x0, 0x7ffff11064a0, 0x7ffff1106480, 0x7ffff1106450} num_ctrls = 0 rc = <optimized out> parent_is_glue = 0 parent_is_leaf = 1 __PRETTY_FUNCTION__ = "hdb_modrdn" #6 0x0000555555603c96 in overlay_op_walk (op=op@entry=0x7fffe8000930, rs=0x7ffff1106930, which=op_modrdn, oi=0x5555559f76b0, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #7 0x0000555555603deb in over_op_func (op=0x7fffe8000930, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x5555559fa350 db = {bd_info = 0x5555558e3620, bd_self = 0x5555559fa350, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, 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 = 0x555555a1df40, be_nsuffix = 0x555555a1df70, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x555555a1e010 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x555555a1e060 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x555555a1dee0 "secret"}, be_max_deref_depth = 15, 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 = 0x0, 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 = 0x555555bdbd80, 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 = 0x5555558e7ec0, be_private = 0x5555559fa4f0, be_next = { stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x555555602ff0 <over_back_response>, sc_cleanup = 0, sc_private = 0x5555559f76b0} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00005555555b0f9c in fe_op_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:314 repl_user = <optimized out> dest_ndn = {bv_len = 38, bv_val = 0x7fffe80016e8 "cn=test2,ou=people,dc=my-domain,dc=com"} dest_pndn = {bv_len = 29, bv_val = 0x7fffe80016c0 "ou=people,dc=my-domain,dc=com"} pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x5555559fa350 bd = 0x5555558ea2c0 diff = <optimized out> #9 0x00005555555b207e in do_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:186 dn = {bv_len = 38, bv_val = 0x7fffe81065c7 "cn=test1,ou=People,dc=my-domain,dc=com"} newrdn = {bv_len = 8, bv_val = 0x7fffe81065ef "cn=test2"} newSuperior = {bv_len = 29, bv_val = 0x7fffe81065fc "ou=People,dc=my-domain,dc=com"} deloldrdn = -1 pnewSuperior = {bv_len = 29, bv_val = 0x7fffe8001658 "ou=People,dc=my-domain,dc=com"} nnewSuperior = {bv_len = 29, bv_val = 0x7fffe80016c0 "ou=people,dc=my-domain,dc=com"} length = 29 #10 0x0000555555595d21 in connection_operation (ctx=ctx@entry=0x7ffff1106b60, arg_v=arg_v@entry=0x7fffe8000930) at connection.c:1150 rc = 80 cancel = <optimized out> op = 0x7fffe8000930 rs = {sr_type = REP_RESULT, sr_tag = 109, sr_msgid = 2, 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 = 108 opidx = SLAP_OP_MODRDN conn = 0x555555a2ea00 memctx = 0x7fffe8000ed0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #11 0x0000555555596079 in connection_read_thread (ctx=0x7ffff1106b60, argv=<optimized out>) at connection.c:1286 rc = <optimized out> cri = {op = 0x7fffe8000930, func = 0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #12 0x00007ffff7b997f3 in ldap_int_thread_pool_wrapper (xpool=0x5555559a1b60) at tpool.c:688 pool = 0x5555559a1b60 task = 0x7fffec0008c0 work_list = <optimized out> ctx = {ltu_id = 140737237776128, ltu_key = {{ltk_key = 0x555555593ee0, ltk_data = 0x7fffe8000dc0, ltk_free = 0x555555593fb0 <conn_counter_destroy>}, {ltk_key = 0x5555555edcc0, ltk_data = 0x7fffe8000ed0, ltk_free = 0x5555555edce0 <slap_sl_mem_destroy>}, {ltk_key = 0x555555bdae00, ltk_data = 0x7fffe81010f0, ltk_free = 0x555555648bb0 <bdb_reader_free>}, {ltk_key = 0x5555555aa480, ltk_data = 0x0, ltk_free = 0x5555555aa3e0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #13 0x00007ffff6e61d14 in start_thread (arg=0x7ffff1107700) at pthread_create.c:309 __res = <optimized out> pd = 0x7ffff1107700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737237776128, 5431369951291209288, 1, 140737354125312, 140737237776128, 23, -5431349871756872120, -5431349957038737848}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> #14 0x00007ffff632a67d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals. No symbol "bt" in current context. #0 rwm_op_rollback (op=op@entry=0x7fffe8000930, ros=0x7fffe8001738, rs=<optimized out>) at rwm.c:110 No locals. #1 0x00007ffff210f1c2 in rwm_op_cleanup (op=0x7fffe8000930, rs=<optimized out>) at rwm.c:165 cb = 0x7fffe8001718 ros = <optimized out> #2 0x00005555555a606b in slap_cleanup_play (op=op@entry=0x7fffe8000930, rs=rs@entry=0x7ffff1106930) at result.c:541 sc_next = 0x7ffff11065c0 sc_nextp = 0x7fffe8001718 sc = 0x7fffe8001718 scp = 0x7ffff1106018 #3 0x00005555555a6573 in send_ldap_response (op=op@entry=0x7fffe8000930, rs=rs@entry=0x7ffff1106930) at result.c:733 berbuf = {buffer = "\000\000\001\000\001\000\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 24 times>, "F\030\000\350\377\177\000\000\024(\000\350\377\177\000\000\000\000\000\000\000\000\000\000F\030\000\350\377\177\000\000\320\016\000\350\377\177\000\000P\373\275UUU\000\000\200v\357\367\377\177\000\000\001\000\000\000hw\001", '\000' <repeats 17 times>"\266, \252r\367\377\177", '\000' <repeats 11 times>, "a\370<\316m]\037\200*\227\367\377\177\000\000\001\000\000\000UU\000\000\321\323vP\000\000\000\000\350\n\000\350\377\177\000\000\003", '\000' <repeats 23 times>"\225, \362\227\367\311\362\245\303\000\000\000\000\000\000\000\000+\246fUUU\000\000\030ӿUUU\000\000\223\204+\366\377\177\000\000\060\065\020\350\377\177\000\000\000a\370<\316m]\037", ialign = 65536, lalign = 4295032832, falign = 9.18354962e-41, dalign = 2.1220281700514382e-314, palign = 0x100010000 <Address 0x100010000 out of bounds>} ber = <optimized out> rc = 32768 bytes = <optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #4 0x00005555555a7126 in slap_send_ldap_result (op=0x7fffe8000930, rs=0x7ffff1106930) at result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #5 0x0000555555621a50 in hdb_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:789 bdb = 0x5555559fa4f0 children = 0x55555599d260 entry = 0x55555599cfc0 p_dn = {bv_len = 29, bv_val = 0x7fffe8102399 "ou=People,dc=my-domain,dc=com"} p_ndn = {bv_len = 29, bv_val = 0x7fffe81023c9 ""} new_dn = {bv_len = 38, bv_val = 0x0} new_ndn = {bv_len = 38, bv_val = 0x0} e = <optimized out> p = <optimized out> ei = 0x7fffe8103f00 eip = 0x7fffe410a0a0 nei = 0x7fffe410a0a0 neip = 0x0 textbuf = "0\t\000\350\377\177\000\000\000e\020\361\377\177\000\000 i\237UUU\000\000\230\060\021\362\377\177\000\000\200\241^\366\377\177\000\000\000\000\000\000\316m]\037&\000\000\000\000\000\000\000\060\022\000\350\377\177\000\000\060\t\000\350\377\177\000\000\070\027\000\350\377\177\000\000\000\000\000\000\000\000\000\000)\323\020\362\377\177\000\000&\000\000\000\000\000\000\000\060\022\000\350\377\177\000\000&\000\000\000\000\000\000\000\270\022\000\350\377\177\000\000\000k\237UUU\000\000\000\352\242UUU\000\000\314X\021\362\377\177\000\000\060i\020\361\377\177\000\000\030\027\000\350\377\177\000\000\030\027\000\350\377\177\000\000\060i\020\361\377\177\000\000\332\326\020\362\377\177\000\000\360d\020\361\377\177\000\000\020e\020\361\377\177\000\000\b\000\000\000\000\000\000\000\270\023\000\350\377\177\000\000\b\000\000\000\000\000\000\000\350\023\000\350\377\177\000\000\000k\237UUU\000\000\000\352\242UUU\000" ltid = 0x0 lt2 = 0x7fffe81068f0 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x7fffe8106730, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 4, e_name = {bv_len = 38, bv_val = 0x7fffe8106890 "cn=test2,ou=People,dc=my-domain,dc=com"}, e_nname = {bv_len = 38, bv_val = 0x7fffe81068c0 "cn=test2,ou=people,dc=my-domain,dc=com"}, e_attrs = 0x0, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fffe8103f00} np = <optimized out> np_dn = <optimized out> np_ndn = <optimized out> new_parent_dn = <optimized out> manageDSAit = 0 lock = {off = 164424, ndx = 98, gen = 2, mode = DB_LOCK_WRITE} plock = {off = 157848, ndx = 932, gen = 2, mode = DB_LOCK_READ} nplock = {off = 0, ndx = 1436511616, gen = 21845, mode = 4044383224} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x555555a2ea00, 0x0, 0x7ffff11064a0, 0x7ffff1106480, 0x7ffff1106450} num_ctrls = 0 rc = <optimized out> parent_is_glue = 0 parent_is_leaf = 1 __PRETTY_FUNCTION__ = "hdb_modrdn" #6 0x0000555555603c96 in overlay_op_walk (op=op@entry=0x7fffe8000930, rs=0x7ffff1106930, which=op_modrdn, oi=0x5555559f76b0, on=0x0) at backover.c:671 func = <optimized out> rc = 32768 #7 0x0000555555603deb in over_op_func (op=0x7fffe8000930, rs=<optimized out>, which=<optimized out>) at backover.c:723 oi = <optimized out> on = <optimized out> be = 0x5555559fa350 db = {bd_info = 0x5555558e3620, bd_self = 0x5555559fa350, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, 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 = 0x555555a1df40, be_nsuffix = 0x555555a1df70, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x555555a1e010 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x555555a1e060 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x555555a1dee0 "secret"}, be_max_deref_depth = 15, 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 = 0x0, 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 = 0x555555bdbd80, 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 = 0x5555558e7ec0, be_private = 0x5555559fa4f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x555555602ff0 <over_back_response>, sc_cleanup = 0, sc_private = 0x5555559f76b0} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00005555555b0f9c in fe_op_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:314 repl_user = <optimized out> dest_ndn = {bv_len = 38, bv_val = 0x7fffe80016e8 "cn=test2,ou=people,dc=my-domain,dc=com"} dest_pndn = {bv_len = 29, bv_val = 0x7fffe80016c0 "ou=people,dc=my-domain,dc=com"} pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x5555559fa350 bd = 0x5555558ea2c0 diff = <optimized out> #9 0x00005555555b207e in do_modrdn (op=0x7fffe8000930, rs=0x7ffff1106930) at modrdn.c:186 dn = {bv_len = 38, bv_val = 0x7fffe81065c7 "cn=test1,ou=People,dc=my-domain,dc=com"} newrdn = {bv_len = 8, bv_val = 0x7fffe81065ef "cn=test2"} newSuperior = {bv_len = 29, bv_val = 0x7fffe81065fc "ou=People,dc=my-domain,dc=com"} deloldrdn = -1 pnewSuperior = {bv_len = 29, bv_val = 0x7fffe8001658 "ou=People,dc=my-domain,dc=com"} nnewSuperior = {bv_len = 29, bv_val = 0x7fffe80016c0 "ou=people,dc=my-domain,dc=com"} length = 29 #10 0x0000555555595d21 in connection_operation (ctx=ctx@entry=0x7ffff1106b60, arg_v=arg_v@entry=0x7fffe8000930) at connection.c:1150 rc = 80 cancel = <optimized out> op = 0x7fffe8000930 rs = {sr_type = REP_RESULT, sr_tag = 109, sr_msgid = 2, 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 = 108 opidx = SLAP_OP_MODRDN conn = 0x555555a2ea00 memctx = 0x7fffe8000ed0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #11 0x0000555555596079 in connection_read_thread (ctx=0x7ffff1106b60, argv=<optimized out>) at connection.c:1286 rc = <optimized out> cri = {op = 0x7fffe8000930, func = 0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #12 0x00007ffff7b997f3 in ldap_int_thread_pool_wrapper (xpool=0x5555559a1b60) at tpool.c:688 pool = 0x5555559a1b60 task = 0x7fffec0008c0 work_list = <optimized out> ctx = {ltu_id = 140737237776128, ltu_key = {{ltk_key = 0x555555593ee0, ltk_data = 0x7fffe8000dc0, ltk_free = 0x555555593fb0 <conn_counter_destroy>}, {ltk_key = 0x5555555edcc0, ltk_data = 0x7fffe8000ed0, ltk_free = 0x5555555edce0 <slap_sl_mem_destroy>}, {ltk_key = 0x555555bdae00, ltk_data = 0x7fffe81010f0, ltk_free = 0x555555648bb0 <bdb_reader_free>}, {ltk_key = 0x5555555aa480, ltk_data = 0x0, ltk_free = 0x5555555aa3e0 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #13 0x00007ffff6e61d14 in start_thread (arg=0x7ffff1107700) at pthread_create.c:309 __res = <optimized out> pd = 0x7ffff1107700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737237776128, 5431369951291209288, 1, 140737354125312, 140737237776128, 23, -5431349871756872120, -5431349957038737848}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> #14 0x00007ffff632a67d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals. #0 0x00000000005a39de in rwm_op_rollback (op=0x7fffe4002960, rs=0x7ffff23e5a50, ros=0x7fffe4003558) at ../../../../servers/slapd/overlays/rwm.c:111 __PRETTY_FUNCTION__ = "rwm_op_rollback" #1 0x00000000005a3c79 in rwm_op_cleanup (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../../servers/slapd/overlays/rwm.c:167 cb = 0x7fffe4003538 ros = 0x7fffe4003558 #2 0x00000000004670e8 in slap_cleanup_play (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/result.c:541 sc_next = 0x7ffff23e5690 sc_nextp = 0x7fffe4003538 sc = 0x7fffe4003538 scp = 0x7ffff23e5080 #3 0x0000000000467b16 in send_ldap_response (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/result.c:733 berbuf = {buffer = "\000\000\001\000\001\000\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 24 times>, "f6\000\344\377\177\000\000\064F\000\344\377\177\000\000\000\000\000\000\000\000\000\000f6\000\344\377\177\000\000\200'\000\344\377\177\000\000\017\326vP\000\000\000\000\000\017ƾ\032\372\235\264\000\000\000\000\000\000\000\000ĥ`", '\000' <repeats 13 times>, "\030+\000\344\377\177\000\000\003", '\000' <repeats 15 times>"\356, &\\\000\000\000\000\000иV\000\000\000\000\000 \314\020\344\377\177\000\000\000\017ƾ\032\372\235\264@R>\362\377\177\000\000H\314\020\344\377\177\000\000\a\000\000\000\000\000\000\000\361\264d\000\000\000\000\000\004\000\000\000\000\000\000\000P0\000\344\377\177", '\000' <repeats 18 times>, "PR>\362\377\177\000\000Pp\275\000\000\000\000", ialign = 65536, lalign = 4295032832, falign = 9.18354962e-41, dalign = 2.1220281700514382e-314, palign = 0x100010000 <Address 0x100010000 out of bounds>} ber = 0x7ffff23e50f0 rc = 32768 bytes = 14 __PRETTY_FUNCTION__ = "send_ldap_response" #4 0x0000000000468318 in slap_send_ldap_result (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/result.c:860 tmp = 0x0 otext = 0x0 oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #5 0x000000000051e4a9 in hdb_modrdn (op=0x7fffe4002960, rs=0x7ffff23e5a50) at modrdn.c:789 bdb = 0x9ebd80 children = 0x9928d0 entry = 0x992630 p_dn = {bv_len = 29, bv_val = 0x7fffe410b7f9 "ou=People,dc=my-domain,dc=com"} p_ndn = {bv_len = 29, bv_val = 0x7fffe410b829 ""} new_dn = {bv_len = 38, bv_val = 0x0} new_ndn = {bv_len = 38, bv_val = 0x0} e = 0xbf3c78 p = 0x0 ei = 0x7fffe410cc20 eip = 0x7fffe410b970 nei = 0x7fffe410b970 neip = 0x0 textbuf = "X5\000\344\377\177\000\000%\231e\000\000\000\000\000PZ>\362\377\177\000\000`)\000\344\377\177\000\000\220U>\362\377\177\000\000\000\000\000\000\000\000\000\000\320{\236\000\000\000\000\000\260}\236\000\000\000\000\000&\000\000\000\000\000\000\000P0\000\344\377\177\000\000&\000\000\000\000\000\000\000\330\060\000\344\377\177\000\000\260}\236\000\000\000\000\000\200(\242\000\000\000\000\000%\231e\000\000\000\000\000PZ>\362\377\177\000\000\320U>\362\377\177\000\000BXZ\000\000\000\000\000PZ>\362\377\177\000\000`)\000\344\377\177\000\000PZ>\362\000\200\000\000\320{\236\000\000\000\000\000\260}\236\000\000\000\000\000\070\065\000\344\377\177\000\000\035\000\000\000\000\000\000\000\340\064\000\344\377\177\000\000\035\000\000\000\000\000\000\000x4\000\344\377\177\000\000\b\000\000\000\000\000\000\000\330\061\000\344\377\177\000\000\b\000\000\000\000\000\000\000\b"... textlen = 256 ltid = 0x0 lt2 = 0x7fffe410d8d0 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn = 0x7fffe40024f0, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 4, e_name = {bv_len = 38, bv_val = 0x7fffe4002650 "cn=test2,ou=People,dc=my-domain,dc=com"}, e_nname = {bv_len = 38, bv_val = 0x7fffe4002680 "cn=test2,ou=people,dc=my-domain,dc=com"}, e_attrs = 0x0, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fffe410cc20} np = 0x0 np_dn = 0x0 np_ndn = 0x7ffff23e5360 new_parent_dn = 0x7ffff23e5350 manageDSAit = 0 lock = {off = 164424, ndx = 98, gen = 2, mode = DB_LOCK_WRITE} plock = {off = 157848, ndx = 932, gen = 2, mode = DB_LOCK_READ} nplock = {off = 0, ndx = 0, gen = 0, mode = DB_LOCK_NG} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x7fffe4003050, 0xa22880, 0x0, 0x7ffff23e54a0, 0x5abe87} num_ctrls = 0 rc = 0 parent_is_glue = 0 parent_is_leaf = 1 settle = 0 __PRETTY_FUNCTION__ = "hdb_modrdn" #6 0x00000000004ebf0c in overlay_op_walk (op=0x7fffe4002960, rs=0x7ffff23e5a50, which=op_modrdn, oi=0x9e0c10, on=0x0) at ../../../servers/slapd/backover.c:671 func = 0x8bd198 rc = 32768 #7 0x00000000004ec141 in over_op_func (op=0x7fffe4002960, rs=0x7ffff23e5a50, which=op_modrdn) at ../../../servers/slapd/backover.c:723 oi = 0x9e0c10 on = 0x9e7bd0 be = 0x9ebbe0 db = {bd_info = 0x8bd140, bd_self = 0x9ebbe0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 264, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, 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 = 0x9d2740, be_nsuffix = 0x9ebbb0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x9ec140 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x9ec190 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x9ec440 "secret"}, be_max_deref_depth = 15, 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 = 0x0, 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 = 0xbd7030, 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 = 0x8c3400, be_private = 0x9ebd80, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x4eacb0 <over_back_response>, sc_cleanup = 0, sc_private = 0x9e0c10} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00000000004ec2d8 in over_op_modrdn (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/backover.c:768 No locals. #9 0x00000000004765fa in fe_op_modrdn (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/modrdn.c:314 repl_user = 0 dest_ndn = {bv_len = 38, bv_val = 0x7fffe4003508 "cn=test2,ou=people,dc=my-domain,dc=com"} dest_pndn = {bv_len = 29, bv_val = 0x7fffe40034e0 "ou=people,dc=my-domain,dc=com"} pdn = {bv_len = 0, bv_val = 0x0} op_be = 0x9ebbe0 bd = 0x8c7620 diff = 0 #10 0x0000000000475d88 in do_modrdn (op=0x7fffe4002960, rs=0x7ffff23e5a50) at ../../../servers/slapd/modrdn.c:186 dn = {bv_len = 38, bv_val = 0x7fffe410cb37 "cn=test1,ou=People,dc=my-domain,dc=com"} newrdn = {bv_len = 8, bv_val = 0x7fffe410cb5f "cn=test2"} newSuperior = {bv_len = 29, bv_val = 0x7fffe410cb6c "ou=People,dc=my-domain,dc=com"} deloldrdn = -1 pnewSuperior = {bv_len = 29, bv_val = 0x7fffe4003478 "ou=People,dc=my-domain,dc=com"} nnewSuperior = {bv_len = 29, bv_val = 0x7fffe40034e0 "ou=people,dc=my-domain,dc=com"} length = 29 #11 0x000000000044fc27 in connection_operation (ctx=0x7ffff23e5b90, arg_v=0x7fffe4002960) at ../../../servers/slapd/connection.c:1150 rc = 80 cancel = 0 op = 0x7fffe4002960 rs = {sr_type = REP_RESULT, sr_tag = 109, sr_msgid = 2, 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 = 108 opidx = SLAP_OP_MODRDN conn = 0xa22880 memctx = 0x7fffe4002780 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0000000000450254 in connection_read_thread (ctx=0x7ffff23e5b90, argv=0x17) at ../../../servers/slapd/connection.c:1286 rc = 0 cri = {op = 0x7fffe4002960, func = 0, arg = 0x0, ctx = 0x7ffff23e5b90, nullop = 0} s = 23 #13 0x00000000005c78ad in ldap_int_thread_pool_wrapper (xpool=0x9973b0) at ../../../libraries/libldap_r/tpool.c:688 pool = 0x9973b0 task = 0x7fffec000a20 work_list = 0x997448 ctx = {ltu_id = 140737257563904, ltu_key = {{ltk_key = 0x44f70c, ltk_data = 0x7fffe40028f0, ltk_free = 0x44f5df <conn_counter_destroy>}, {ltk_key = 0x4caa67, ltk_data = 0x7fffe4002780, ltk_free = 0x4ca88c <slap_sl_mem_destroy>}, {ltk_key = 0x46c531, ltk_data = 0x0, ltk_free = 0x46c484 <slap_op_q_destroy>}, {ltk_key = 0xbd9430, ltk_data = 0x7fffe4106590, ltk_free = 0x56eac3 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7fffe4000ac0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 22 times>, {ltk_key = 0x0, ltk_data = 0x7ffff6c46ba5, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 949 hash = 3994472373 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00007ffff6c45d14 in start_thread (arg=0x7ffff23e6700) at pthread_create.c:309 __res = <optimized out> pd = 0x7ffff23e6700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737257563904, -4915901394837331576, 1, 140737354125312, 140737257563904, 0, 4915909644372648328, 4915916705226662280}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> #15 0x00007ffff611867d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals.

1 0

Re: (ITS#7413) Some UTF-8 characters are wrongly recognized as identical in multi-valued attributes
by hyc＠symas.com 11 Oct '12

11 Oct '12

m.bachmann(a)cms.hu-berlin.de wrote: > Full_Name: Michail Bachmann > Version: 2.4.31 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.20.3.158) > > > > The UTF-8 character 'FEMININE ORDINAL INDICATOR' (U+00AA) is wrongly treated as > 'LATIN SMALL LETTER A' (U+0061), so adding a multi-valued attribute where U+00AA > is replaced with U+0061 (or the other way around) fails: This works as designed. See the Unicode specification, rules for decomposition. > > $ ldapadd -f create.ldif -h localhost -D 'cn=admin,dc=example,dc=com' > > ### create.ldif ### > dn: cn=test,dc=example,dc=com > objectClass: organizationalRole > objectClass: top > cn: test > street: a street > ### /create.ldif ### > > $ ldapmodify -f modify.ldif -h localhost -D 'cn=admin,dc=example,dc=com' > > ### modify.ldif ### > dn: cn=test,dc=example,dc=com > changetype: modify > add: street > street: ª street > - > > ### /modify.ldif ### > > will result in > > ldap_modify: Type or value exists (20) > additional info: modify/add: street: value #0 already exists > > It seems like U+00AA is decomposed into '<super>+U+0061' and then the '<super>' > part is discarded. > > Tested with 2.4.31 (Debian) and 2.4.21 (Ubuntu) > > > -- -- 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#7413) Some UTF-8 characters are wrongly recognized as identical in multi-valued attributes
by m.bachmann＠cms.hu-berlin.de 11 Oct '12

11 Oct '12

Full_Name: Michail Bachmann Version: 2.4.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.20.3.158) The UTF-8 character 'FEMININE ORDINAL INDICATOR' (U+00AA) is wrongly treated as 'LATIN SMALL LETTER A' (U+0061), so adding a multi-valued attribute where U+00AA is replaced with U+0061 (or the other way around) fails: $ ldapadd -f create.ldif -h localhost -D 'cn=admin,dc=example,dc=com' ### create.ldif ### dn: cn=test,dc=example,dc=com objectClass: organizationalRole objectClass: top cn: test street: a street ### /create.ldif ### $ ldapmodify -f modify.ldif -h localhost -D 'cn=admin,dc=example,dc=com' ### modify.ldif ### dn: cn=test,dc=example,dc=com changetype: modify add: street street: ª street - ### /modify.ldif ### will result in ldap_modify: Type or value exists (20) additional info: modify/add: street: value #0 already exists It seems like U+00AA is decomposed into '<super>+U+0061' and then the '<super>' part is discarded. Tested with 2.4.31 (Debian) and 2.4.21 (Ubuntu)

1 0

(ITS#7412) check_password contrib module
by clem.oudot＠gmail.com 11 Oct '12

11 Oct '12

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. --- contrib/slapd-modules/README | 3 + contrib/slapd-modules/check-password/Makefile | 52 +++ contrib/slapd-modules/check-password/README | 146 +++++++++ .../slapd-modules/check-password/check_password.c | 356 +++++++++++++++= ++++++ 4 files changed, 557 insertions(+) create mode 100644 contrib/slapd-modules/check-password/Makefile create mode 100644 contrib/slapd-modules/check-password/README create mode 100644 contrib/slapd-modules/check-password/check_password.c= diff --git a/contrib/slapd-modules/README b/contrib/slapd-modules/README index db74379..d8005ff 100644 --- a/contrib/slapd-modules/README +++ b/contrib/slapd-modules/README @@ -20,6 +20,9 @@ allop (overlay) autogroup (overlay) Automated updates of group memberships. =20 +check_password (plugin) + External password quality check module for ppolicy + cloak (overlay) Hide specific attributes unless explicitely requested =20 diff --git a/contrib/slapd-modules/check-password/Makefile b/contrib/slap= d-modules/check-password/Makefile new file mode 100644 index 0000000..42dd18f --- /dev/null +++ b/contrib/slapd-modules/check-password/Makefile @@ -0,0 +1,52 @@ + +LDAP_SRC =3D ../../.. +LDAP_BUILD =3D ../../.. +LDAP_INC =3D -I$(LDAP_BUILD)/include -I$(LDAP_SRC)/include -I$(LDAP_SRC)= /servers/slapd +LDAP_LIB =3D $(LDAP_BUILD)/libraries/libldap_r/libldap_r.la \ + $(LDAP_BUILD)/libraries/liblber/liblber.la + +CRACKLIB_PATH =3D /usr/share/cracklib/pw_dict +CRACKLIB_INC =3D=20 +CRACKLIB_LIB =3D -lcrack + +CONFIG_PATH =3D /etc/openldap/check_password.conf + +LIBTOOL =3D $(LDAP_BUILD)/libtool +CC =3D gcc +OPT =3D -g -O2 -Wall +DEFS =3D -DHAVE_CRACKLIB -DCRACKLIB_DICTPATH=3D"\"$(CRACKLIB_PATH)\"" \ + -DCONFIG_FILE=3D"\"$(CONFIG_PATH)\"" -DDEBUG +INCS =3D $(LDAP_INC) $(CRACKLIB_INC) +LIBS =3D $(LDAP_LIB) $(CRACKLIB_LIB) + +PROGRAMS =3D check_password.la +LTVER =3D 0:0:0 + +prefix=3D/usr/local +exec_prefix=3D$(prefix) +ldap_subdir=3D/openldap + +libdir=3D$(exec_prefix)/lib +libexecdir=3D$(exec_prefix)/libexec +moduledir =3D $(libexecdir)$(ldap_subdir) + +.SUFFIXES: .c .o .lo + +.c.lo: + $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $< + +all: $(PROGRAMS) + +check_password.la: check_password.lo + $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info $(LTVER) \ + -rpath $(moduledir) -module -o $@ $? $(LIBS) + +clean: + rm -rf *.o *.lo *.la .libs + +install: $(PROGRAMS) + mkdir -p $(DESTDIR)$(moduledir) + for p in $(PROGRAMS) ; do \ + $(LIBTOOL) --mode=3Dinstall cp $$p $(DESTDIR)$(moduledir) ; \ + done + 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 + +check_password.c is an OpenLDAP pwdPolicyChecker module used to check th= e +strength and quality of user-provided passwords. + +This module is used as an extension of the OpenLDAP password policy cont= rols, +see slapo-ppolicy(5) section pwdCheckModule. + +check_password.c will run a number of checks on the passwords to ensure = minimum +strength and quality requirements are met. Passwords that do not meet th= ese +requirements are rejected. + + +Password checks +--------------- + - passwords shorter than 6 characters are rejected if cracklib is used = (because + cracklib WILL reject them). + + - syntactic checks controls how many different character classes are us= ed + (lower, upper, digit and punctuation characters). The minimum number = of + classes is defined in a configuration file. You ca 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. 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.

1 0

(ITS#7411) ldap_get_option.3: Warning from "groff" about a tab in the manual
by bjarniig＠rhi.hi.is 10 Oct '12

10 Oct '12

Full_Name: Bjarni Ingi Gislason Version: 2.4.32 OS: GNU/Linux URL: Submission from: (NULL) (130.208.164.54) Software: openldap Version: 2.4.32 File: doc/man/ldap_get_option.3 Patch: Yes From "groff -b -ww -z -mandoc ldap_get_option.3": groff: ldap_get_option.3: stdin:456: warning: tab character in unquoted macro argument # Output from "nroff" should (usually) have only the left margin adjusted (".ad l"). Otherwise the space between words can be too long. Output for a manual should (usually) have the right margin ragged (".ad l"), as it is not (usually) intended for a book or other professional printing medium. # # Each sentence should begin in a new line. a) The space between sentences is different between formatters. b) Changes in one line do then not affect others, and do therefore not appear as changed in the output of "diff". # Sometimes a small change in space between a roman and an italic character is needed (use ".RI" or ".IR" macros). # Remove spaces at end of lines. # Patch: --- ldap_get_option.3 2012-07-31 16:39:26.000000000 +0000 +++ /tmp/ldap_get_option.3.new 2012-10-09 21:27:10.240593613 +0000 @@ -453,7 +453,7 @@ .BR "char ***" . The caller must not free or otherwise muck with it. .TP -.B LDAP_OPT_X_SASL_NOCANON +.B LDAP_OPT_X_SASL_NOCANON Sets/gets the NOCANON flag. When unset, the hostname is canonicalized. .BR invalue

1 0

Re: (ITS#7348) enhancement: check_password contrib module
by Kurt Zeilenga 10 Oct '12

10 Oct '12

This submission was been placed in a suspended state for intellectual property rights (IPR) reasons. Unfortunately, I got busy with other things and didn't have time to respond. I do now. Generally, as the Foundation requires notices to be provided by authors (or other right holders), it does not accept 3rd party submissions. The Foundation views this as a 3rd party submission as it apparently comes from someone who has no rights in the submission. Generally, the Project does not duplication distribution of materials otherwise made available. This material appears to be distributed by the LTB Project and the Project sees no reason to supplant their effects. The submitter is not listed as a member of the LTB Project and assumes the submitter is not authorized to speak on behalf of the LTB Project. The contribution is missing appropriate IPR Notices. See <http://www.openldap.org/devel/contributing.html>. These MUST be provided by the authors (or other rights holders). IPR notices provided by non-authors will not be considered. For these reasons, your submission is rejected. If it is the LTB Project's wish to contribute this material to the OpenLDAP Project, their Project Leader (who we believed also authored portions of this material), working in cooperation with other authors, should personally submit the materials, with appropriate IPR notices, and a statement that they wish the OpenLDAP Project to include the materials in OpenLDAP Software and shepherd further development. This ITS will now be closed.

1 0

Re: (ITS#7348) enhancement: check_password contrib module
by hyc＠symas.com 10 Oct '12

10 Oct '12

Guillaume.Rousse(a)inria.fr wrote: > Ping ? Can I have any kind of feedback ? As the ITS status says, it's on hold due to IPR concerns. Kurt can explain further. -- -- 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#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 10 Oct '12

10 Oct '12

Ceci est un message signC) cryptographiquement au format MIME. --------------ms010005020603050107040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Ping ? Can I have any kind of feedback ? --------------ms010005020603050107040502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJYDCC BJUwggN9oAMCAQICECu5mlkLgTFbaSg8Mgwue0kwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UE BhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMB4X DTExMDExMTAwMDAwMFoXDTE0MDExMDIzNTk1OVowWDELMAkGA1UEBhMCRlIxDjAMBgNVBAoT BUlOUklBMRkwFwYDVQQDExBHdWlsbGF1bWUgUk9VU1NFMR4wHAYJKoZIhvcNAQkCFg9yb3Vz c2VAaW5yaWEuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU9hkZ4j+MxXqQ 310Pah2QqpshhbJ8T9bACuYEcIdsZuxCYDUgJUVZJmHZK6IZbX4xiVr85pSHPJYG8z0nXXh4 ZXN0iPGVd2/YFpcqt2rB+KDydyrioXfLNiS6JZeKWEaPhKh/5C6/E898XwxB7VzV4meEDOpJ 4si8pNkCnPFFLMXfH/IG4lFvMj9qwfTIMGymB5/hLnZBm5/pK0Bm6wUESvN6YWFRjZ0ctd5p bvDG/vZpjQiavHC+r4YSLBgeFUb4W5N6XGXNsxZvUCRc4mC6XaiDaId75klRxFTdDmtynnLl 44mm6KJws158b3YC1kGACTYJaT+01R+D08PsVy2bAgMBAAGjggF2MIIBcjAfBgNVHSMEGDAW gBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUT8X4ighZJ1th5zEgoWZwKTXpQcIw DgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYDVR0fBDgwNjA0oDKgMIYuaHR0 cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNybDByBggrBgEFBQcB AQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVSRU5BUGVy c29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLnRjcy50ZXJlbmEub3JnMCQG A1UdEQQdMBuBGUd1aWxsYXVtZS5Sb3Vzc2VAaW5yaWEuZnIwDQYJKoZIhvcNAQEFBQADggEB AEItBMmkv3DtWrx5KhZDlYV+ZLht8pFJTiK84GtnZ0dh+8pUSCzk8QS8Hly9gyiTfmTyZXiy UpnVXLLatBp3kgOw9ZCbdGj3TB6iOvHzHKaUHq/jdVf/S2CVlkU1ekRa5UnbsxFObZnZRu0G 2Lb4DbbwZYmS9OgGDzueBQ5B64X5yZXUueXnrgJMBa2JCT9QGvs6Px9src1ZyCArWTLGUmu2 NsaOI+WJMXdByLHOPJZp5A52dPPsnwDoyYrNrXPXngXXL0Pz3JPsKCA3lvb52oQkXDjqgm5o rYdHKhbxJvHG9WozyCppVBgSYve0IVyVfBWXLiCtTWnpY//DA23Hd2cwggTDMIIDq6ADAgEC AhBz/lf637jFCIF7Zrlr8C3vMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA5 MDUxODAwMDAwMFoXDTI4MTIzMTIzNTk1OVowOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRF UkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyBXZ9TNqI6GQDc+7BUTDqx9KNYUaIYWgT/jwQOJKQ5v+W7Gwv7RX3HWA QUtkGvbbT2+P0CVFNfnqy0r6+9rT7UWIEZQ25MyoDe/FPTftFnvjwpWeWDN/Ivv4/+zmvtuu CmUlIofab4SLRuhAhig/v1YI4krpg6LpIvst+rYoH5HBw3H7U8ArTqQMoW6dVe3s4SSHOgji DRzkxE3Qyyf6hGTm0ZedViRbk7spLkPiQWo94kpl/JpfWoaHvIfHeYCWmVHGkA9kkZl9EN2s LAMq4Xhk/s49TvQrUBFL0VjUmwPwf/U7U7BTQ/vFL8QEKRo6rNdV6dEOldE7MX94T64pLQID AQABo4IBTTCCAUkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYE FGNNQ1oZSD/ERsECur/uDuWCt2amMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wWAYDVR0fBFEwTzBNoEugSYZHaHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25h bmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29j c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEABiupUy8T3Fw5FsyGn15Me3L7 7I1Vil6aCv9TTHb0Bj1Qz1fwos+vmYyq/qAZdj6ZAzL6dYM4irtrmqUME7LUG3bmlC5nmFnj kWwCkJqcyGBLVavKiFqNK+VplQMH0dQO/CQiLlmxY6Rf7dkjcuSczjpcbB9PqQDJHf76f0Ut ti6E3Q8noFkYTtV2JUX0mSZ522+fI/dDuysPBKOBJiy3ezX5PXdfQCHmfx2lllq90MsWOmy7 YYuK/QQ5RArLLOHLzi4QmBrb4JPtSWRkCCCft6NQ8KLdyrTGfAw9514V3CeG5Do7UloXq6kG UyudCXNkHAHD/TDShwNv5BUDejlfaDGCAwcwggMDAgEBME8wOzELMAkGA1UEBhMCTkwxDzAN BgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2ko PDIMLntJMAkGBSsOAwIaBQCgggGNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTAxMDE1MTQ1MFowIwYJKoZIhvcNAQkEMRYEFISpiKvxYJ/cJnbtLJAt y+oy8hXXMF4GCSsGAQQBgjcQBDFRME8wOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVO QTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2koPDIMLntJMGAGCyqG SIb3DQEJEAILMVGgTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQD ExJURVJFTkEgUGVyc29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEF AASCAQBSTpiPHQsxT9U0zme6qRLWCJXDvU6vfyPzeM+6Fb6t9iH9RlXrmNKBPx501HQWCfwf K/OGGzzNULpU3N3pTp++BRoyPnNPVmIwLe1MedC7SMf/5oL2p8KTGu+VUPd0TXaJihfXwq0+ sThwq9O1464Cfxr+n27k/GSvU3AHsn3j59BqSdGZUXs+Dg/42acuWoV2xYL0ZjyRt8d1ZoU7 3U5TWKTEIAP5zMnSvBfHbfV4HUEIl9AVKtPaaaq4L1aQnByyEG6cN39R4N+LPwQXVW4pBwuI nKUF8FImmM3tovtb0aINf83d+RFuAhGEUGxLLFgYRGHzxRdCSIC85rOry1C4AAAAAAAA --------------ms010005020603050107040502--

1 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 09 Oct '12

09 Oct '12

arun s wrote: > Hi, > To try and overcome this issue, we tried two fixes: > > 1. Every time a user was deleted from a group, we force-updated the user > object manually to make sure its entryCSN got updated and it got > replicated properly. This is an expensive operation and did not scale > well for big group sizes (10-20k), and did not work out. This is also one of the reasons the code in memberof.c was reverted. Working as you suggest *cannot* scale. It makes no difference whether you do it in your external client or inside slapd, the amount of actual work required to replicate everything quickly grows out of control. This is why the documentation states that memberof must be configured on each replica - the only way to successfully execute the amount of work is to distribute the work evenly to each replica. > 2. We then tried to do the same thing in OpenLDAP. We noticed in the > memberof.c commits that there were a couple of patches to force the > entryCSN of the user object to get updated. (http://tinyurl.com/8k4qrdj > and http://tinyurl.com/9akqgfl)These have since been reverted because of > access log and some replication issues, but for us, speed was a higher > priority. I reapplied these patches back to the code. This solved the > member-of replication issue, but we noticed that occasionally under a > heavy load, there was a sudden surge in OpenLDAP's memory usage going up > to whatever memory was available and finally crashing. > > We have gone back to option (1) though (2) would be the preferred option. > > Any help on figuring out why (2) caused the memory bloat would be really > great. I can provide more details/memory traces if needed. > > We will be glad to contribute any fixes once we are able to nail down > the issue. Probably this conversation should continue on the openldap-devel mailing list. It needs some new design work; it is not a simple bugfix. > > Thanks, > Arunkumar > ------------------------------------------------------------------------------ > *From:* Howard Chu <hyc(a)symas.com> > *To:* arun s <arunkumar_1123(a)yahoo.com> > *Cc:* "openldap-its(a)openldap.org" <openldap-its(a)openldap.org> > *Sent:* Monday, 1 October 2012 6:59 PM > *Subject:* Re: (ITS#7400) Memberof and Syncrepl incompatibility > > arun s wrote: > > Hi, > > Yes, I am able to reproduce the issue with 2.4.32 > > > > Making sense of the logs for the exact reproduction is hard since it needs a > > lot of operations in a short time. But this will probably help: > > > > 1. At the start of the test, the group temp_group existed. > > > > 2. I created a user temp_user and added temp_user to temp_group. > > > > 3. During replication, the group was replicated first and I got an error 32 > > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object > > (This does not exist in the readslave yet). > > > > 4. The temp_user object was replicated next, and as you see, querying it does > > show a memberOf attribute, proving that this field was replicated. (Note that > > I have run OpenLDAP with debug as -1 and verified that the replicated data has > > the memberOf field in it. I can provide this too if needed.) > > I see. The current code drops the memberOf attribute if it was not explicitly > requested in the search. However, by default the consumer requests "+" which > means "all operational attributes" and so slapd considers memberOf to have > been requested. We need to reconsider this aspect of the design. > > > > 5. The more serious problem occurs when the sequence is reversed and the group > > has been deleted as a last operation - The user is replicated first, but since > > the group is deleted, it is never replicated and a stale memberOf entry stays > > with the user. -- -- 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#7400) Memberof and Syncrepl incompatibility
by arunkumar_1123＠yahoo.com 09 Oct '12

09 Oct '12

--1251447850-1386810138-1349783312=:99375 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0ATo try and overcome this issue, we tried two fixes:=0A=0A1. Every tim= e a user was deleted from a group, we force-updated the user=A0=0Aobject ma= nually to make sure its entryCSN got updated and it got=A0=0Areplicated pro= perly. This is an expensive operation and did not scale=A0=0Awell for big g= roup sizes (10-20k), and did not work out.=0A=0A2. We then tried to do the = same thing in OpenLDAP. We noticed in the=A0=0Amemberof.c commits that ther= e were a couple of patches to force the=A0=0AentryCSN of the user object to= get updated. (http://tinyurl.com/8k4qrdj=A0=0Aand http://tinyurl.com/9akqg= fl)These have since been reverted because of=A0=0Aaccess log and some repli= cation issues, but for us, speed was a higher=A0=0Apriority. I reapplied th= ese patches back to the code. This solved the=A0=0Amember-of replication is= sue, but we noticed that occasionally under a=A0=0Aheavy load, there was a = sudden surge in OpenLDAP's memory usage going up=A0=0Ato whatever memory wa= s available and finally crashing.=0A=0AWe have gone back to option (1) thou= gh (2) would be the preferred option.=0A=0AAny help on figuring out why (2)= caused the memory bloat would be really=A0=0Agreat. I can provide more det= ails/memory traces if needed.=0A=0AWe will be glad to contribute any fixes = once we are able to nail down=A0=0Athe issue.=0A=0AThanks,=0AArunkumar=0A= =0A________________________________=0A From: Howard Chu <hyc(a)symas.com>=0AT= o: arun s <arunkumar_1123(a)yahoo.com> =0ACc: "openldap-its(a)openldap.org" <op= enldap-its(a)openldap.org> =0ASent: Monday, 1 October 2012 6:59 PM=0ASubject:= Re: (ITS#7400) Memberof and Syncrepl incompatibility=0A =0Aarun s wrote:= =0A> Hi,=0A> Yes, I am able to reproduce the issue with 2.4.32=0A> =0A> Mak= ing sense of the logs for the exact reproduction is hard since it needs a= =0A> lot of operations in a short time. But this will probably help:=0A> = =0A> 1. At the start of the test, the group temp_group existed.=0A> =0A> 2.= I created a user temp_user and added temp_user to temp_group.=0A> =0A> 3. = During replication, the group was replicated first and I got an error 32=0A= > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user ob= ject=0A> (This does not exist in the readslave yet).=0A> =0A> 4. The temp_u= ser object was replicated next, and as you see, querying it does=0A> show a= memberOf attribute, proving that this field was replicated. (Note that=0A>= I have run OpenLDAP with debug as -1 and verified that the replicated data= has=0A> the memberOf field in it. I can provide this too if needed.)=0A=0A= I see. The current code drops the memberOf attribute if it was not explicit= ly requested in the search. However, by default the consumer requests "+" w= hich means "all operational attributes" and so slapd considers memberOf to = have been requested. We need to reconsider this aspect of the design.=0A> = =0A> 5. The more serious problem occurs when the sequence is reversed and t= he group=0A> has been deleted as a last operation - The user is replicated = first, but since=0A> the group is deleted, it is never replicated and a sta= le memberOf entry stays=0A> with the user.=0A=0A--=A0 -- Howard Chu=0A=A0 = CTO, Symas Corp.=A0 =A0 =A0 =A0 =A0 http://www.symas.com=0A=A0 Director, Hi= ghland Sun=A0 =A0 http://highlandsun.com/hyc/=0A=A0 Chief Architect, OpenLD= AP=A0 http://www.openldap.org/project/ --1251447850-1386810138-1349783312=:99375 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div style=3D"font-fa= mily: 'times new roman', 'new york', times, serif; font-size: 12pt; "><span= >=0A=0A=0A=0A=0A=0A=0A=0A<div class=3D"p1">Hi,</div></span></div><div><div>= To try and overcome this issue, we tried two fixes:</div><div><br></div><di= v>1. Every time a user was deleted from a group, we force-updated the user&= nbsp;</div><div>object manually to make sure its entryCSN got updated and i= t got </div><div>replicated properly. This is an expensive operation a= nd did not scale </div><div>well for big group sizes (10-20k), and did= not work out.</div><div><br></div><div>2. We then tried to do the same thi= ng in OpenLDAP. We noticed in the </div><div>memberof.c commits that t= here were a couple of patches to force the </div><div>entryCSN of the = user object to get updated. (http://tinyurl.com/8k4qrdj </div><div>and= http://tinyurl.com/9akqgfl)These have since been reverted because of = </div><div>access log and some replication issues, but for us, speed was a = higher </div><div>priority. I reapplied these patches back to the code= . This solved the </div><div>member-of replication issue, but we noticed that occas= ionally under a </div><div>heavy load, there was a sudden surge in Ope= nLDAP's memory usage going up </div><div>to whatever memory was availa= ble and finally crashing.</div><div><br></div><div>We have gone back to opt= ion (1) though (2) would be the preferred option.</div><div><br></div><div>= Any help on figuring out why (2) caused the memory bloat would be really&nb= sp;</div><div>great. I can provide more details/memory traces if needed.</d= iv><div><br></div><div>We will be glad to contribute any fixes once we are = able to nail down </div><div>the issue.</div><div><br></div><div>Thank= s,</div><div>Arunkumar</div></div> <div style=3D"font-family: 'times new r= oman', 'new york', times, serif; font-size: 12pt; "> <div style=3D"font-fam= ily: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div = dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1"> <b><span style=3D"font-weight:bold;">From:</span></b> Howard Chu <hyc(a)symas.com&= gt;<br> <b><span style=3D"font-weight: bold;">To:</span></b> arun s <aru= nkumar_1123(a)yahoo.com> <br><b><span style=3D"font-weight: bold;">Cc:</sp= an></b> "openldap-its(a)openldap.org" <openldap-its(a)openldap.org> <br> = <b><span style=3D"font-weight: bold;">Sent:</span></b> Monday, 1 October 20= 12 6:59 PM<br> <b><span style=3D"font-weight: bold;">Subject:</span></b> Re= : (ITS#7400) Memberof and Syncrepl incompatibility<br> </font> </div> <br>a= run s wrote:<br>> Hi,<br>> Yes, I am able to reproduce the issue with= 2.4.32<br>> <br>> Making sense of the logs for the exact reproductio= n is hard since it needs a<br>> lot of operations in a short time. But t= his will probably help:<br>> <br>> 1. At the start of the test, the g= roup temp_group existed.<br>> <br>> 2. I created a user temp_user and= added temp_user to temp_group.<br>> <br>> 3. During replication, the group was replicated first and I got an error 32<br>> (NO_SUCH_OBJECT) = when it tried to modify the memberOf of the temp_user object<br>> (This = does not exist in the readslave yet).<br>> <br>> 4. The temp_user obj= ect was replicated next, and as you see, querying it does<br>> show a me= mberOf attribute, proving that this field was replicated. (Note that<br>&gt= ; I have run OpenLDAP with debug as -1 and verified that the replicated dat= a has<br>> the memberOf field in it. I can provide this too if needed.)<= br><br>I see. The current code drops the memberOf attribute if it was not e= xplicitly requested in the search. However, by default the consumer request= s "+" which means "all operational attributes" and so slapd considers membe= rOf to have been requested. We need to reconsider this aspect of the design= .<br>> <br>> 5. The more serious problem occurs when the sequence is = reversed and the group<br>> has been deleted as a last operation - The user is replicated first, but since<br>> the group is deleted, it= is never replicated and a stale memberOf entry stays<br>> with the user= .<br><br>--  -- Howard Chu<br>  CTO, Symas Corp.    &n= bsp;     <a href=3D"http://www.symas.com/" target=3D"_blank">htt= p://www.symas.com</a><br>  Director, Highland Sun    <a hre= f=3D"http://highlandsun.com/hyc/" target=3D"_blank">http://highlandsun.com/= hyc/</a><br>  Chief Architect, OpenLDAP  <a href=3D"http://www.op= enldap.org/project/" target=3D"_blank">http://www.openldap.org/project/</a>= <br><br><br> </div> </div> </div></body></html> --1251447850-1386810138-1349783312=:99375--

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 08 Oct '12

08 Oct '12

> >> I will note that Mandriva, at least, continually updates the version > >> of OpenLDAP they ship, unlike most distributions, so it definitely > >> isn't all. And my point is, Red Hat could do better, and I'd like to > >> see them do better. I'd like to see Debian/Ubuntu do better too. > >> I.e., this isn't specific to Red Hat, but the discussion here is about > >> Red Hat, and what it can do. I discuss Debian and what it can do > >> better with the Debian devs on their openldap dev list. > > > > Then I'd like to hear what Jan and the other Red Hat OpenLDAP > > maintainers have to say. As for Fedora, I usualy rebase the package immediately when the new upstream version is available. And I do it in the stable and newer releases (for today it would be stable F17, alpha F18, and Rawhide). And if there is a problem in older Fedora, I just pick the patch. So we are definitelly not behind with Fedora -- the last submitted updates can be found here: https://admin.fedoraproject.org/updates/search/openldap As for RHEL it is more complicated, the rebases are allowed rarely. We cannot afford any API/ABI breakage and regressions. and I can imagine that a new feature in OpenLDAP changes the current behavior or affects some other component. I can remind a bug which appeared after rebase to 2.4.31 in Fedora and we do not want to cause a similar problems in RHEL: https://bugzilla.redhat.com/show_bug.cgi?id=771484 http://www.openldap.org/its/index.cgi?findid=7167 I would like to see newer OpenLDAP in RHEL because it would be easier for me to maintain it. But I'm not sure if the advantages will outweight the disadvantages and if our customers will benefit from it rather than be forced to deal with new problems. > Ok. One thing I do with Debian is help triage issues that are reported > there with the upstream ITS system if the issues do not appear to be due to > the usage of an old version. If there is a simple way to do that with Red > Hat, I could help there as well. When there is a new bug report, I usualy try to reproduce with the package from RHEL or Fedora. And then with the newest OpenLDAP from git master. If I'm able to reproduce, I always create a report in your ITS. Jan

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 07 Oct '12

07 Oct '12

On Oct 7, 2012, at 11:04 AM, Michael Ströder wrote: > chuck.lever(a)oracle.com wrote: >> It appears that the schema LDIF files shipped with OpenLDAP are strictly >> for basic LDAP attribute type and object class definitions. Everything >> else is considered a "user schema," including schemas for implementing a >> DNS or NIS backend, and so on. It appears to me that FedFS would fall into >> this latter category, and thus should not be included in the packaged >> schema. > > There are various schema files shipped with OpenLDAP source. In opposite to > other LDAP servers not all schema files are enabled by default. I see. > But it seems to me that > > https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif > > does not contain exactly the same schema elements like defined in > > http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13 The oss.oracle.com fedfs-utils home page has been deprecated, and will go away soon. That site contains an outdated version of the NSDB schema. Since then, we have attempted to address comments received from openldap-technical. The version defined in the current IETF NSDB protocol draft, which you link to above, is the authoritative version. We may see one or two more revisions as the draft goes through the final IESG review process. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 07 Oct '12

07 Oct '12

This is a cryptographically signed message in MIME format. --------------ms060706000603000508050902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable chuck.lever(a)oracle.com wrote: > It appears that the schema LDIF files shipped with OpenLDAP are strictl= y > for basic LDAP attribute type and object class definitions. Everything= > else is considered a "user schema," including schemas for implementing = a > DNS or NIS backend, and so on. It appears to me that FedFS would fall = into > this latter category, and thus should not be included in the packaged > schema. There are various schema files shipped with OpenLDAP source. In opposite = to other LDAP servers not all schema files are enabled by default. But it seems to me that https://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif does not contain exactly the same schema elements like defined in http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-13 Ciao, Michael. --------------ms060706000603000508050902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIxMDA3MTUwNDU1WjAjBgkq hkiG9w0BCQQxFgQUn45Ie943claWxEltvXj9KkPQ5CIwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEASdFJWmwg6o8+45+N2/K5j5/Bgop65wO2Xs8wL0f8XYBT1IlCgm2B78w4xEX/eKLYXae8 jiZ4+iYuWevD5uaufqzc0abNhObQGfcGxo2zU2IqmcnxRdKjSavb+E99V/I2X96j9CA4W5b6 lajdyuGxcomdEgMQv1BGXukfLQptvdXgwiUyxd21f5s/n46CCQy5VvkFBd1CZRxwYWl0pmdi QeHSAJ6qFZgwFSRUctt1SxcqpmleKx9muf96Cy44XJhy7E4g4VJ5VKjf4MVERKL0CFTEPNkd bURQx7kYJaR01rNuRmkP7eOb/9+2c4qn40enb7qGH0pDke+mZupHPmyysQAAAAAAAA== --------------ms060706000603000508050902--

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 05 Oct '12

05 Oct '12

On 10/05/2012 02:12 PM, quanah(a)zimbra.com wrote: > --On Friday, October 05, 2012 2:11 AM +0000 richm(a)stanfordalumni.org wrote: > >>> Certainly, here's a recent example: >>> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html> >> I guess I missed it, but exactly which OpenLDAP release(s) had the fix >> for this particular problem? That is, how could Red Hat have avoided >> this problem by rebasing to a later OpenLDAP? > My guess is it was fixed in 2.4.26 or 2.4.27. There have been numerous > fixes to cn=config support since 2.4.23, so it is hard to know specifically > which one fixes the above issue. ;) I've gone through the entire thread again. I still don't know 1) what caused the hanging problem with slaptest 2) if upgrading to 2.4.32 fixed the problem https://www.openldap.org/lists/openldap-technical/201210/msg00024.html " # slaptest -v -d 448 -f ./slapd.conf.new -F /etc/openldap/slapd.d The last step just hangs and does not do anything even after waiting 45 minutes. " Do you know if there was a specific hanging problem with slaptest used to convert slapd.conf to slapd.d in 2.4.1-2.4.23 that would have been fixed by rebasing to 2.4.26-2.4.27? How can you be sure that upgrading to 2.4.32 will fix the problem that this guy was having? No one asked him to use gdb to attach to the process to see what was going on. No one asked him to provide the log output of the -d 448 log level. Is it possible that his issue was unrelated to the version of openldap he was using? I guess we'll never know. I've looked through the list of changes at http://www.openldap.org/software/release/changes.html I do see several fixes for cn=config/slapd.d issues in 2.4.24 and later. But I don't see any that look like they have something to do with hanging. I would still like to know a specific problem in Red Hat's OpenLDAP, that has been reported by a customer/user, that would have been avoided by rebasing. It would be a good data point to present to management to say "we could have avoided all of these customer problems by rebasing instead of cherry picking patches". > >>> I will note that Mandriva, at least, continually updates the version >>> of OpenLDAP they ship, unlike most distributions, so it definitely >>> isn't all. And my point is, Red Hat could do better, and I'd like to >>> see them do better. I'd like to see Debian/Ubuntu do better too. >>> I.e., this isn't specific to Red Hat, but the discussion here is about >>> Red Hat, and what it can do. I discuss Debian and what it can do >>> better with the Debian devs on their openldap dev list. >> Then I'd like to hear what Jan and the other Red Hat OpenLDAP >> maintainers have to say. > Ok. One thing I do with Debian is help triage issues that are reported > there with the upstream ITS system if the issues do not appear to be due to > the usage of an old version. If there is a simple way to do that with Red > Hat, I could help there as well. Here is the current RHEL 6 openldap bug list - https://bugzilla.redhat.com/buglist.cgi?list_id=641623&classification=Red%2… Here is the current Fedora openldap bug list - https://bugzilla.redhat.com/buglist.cgi?list_id=641625&classification=Fedor… If you have a bugzilla account, you can simply add the link to the ITS as a comment in the bugzilla bug. That would be most appreciated. Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 05 Oct '12

05 Oct '12

--On Friday, October 05, 2012 2:11 AM +0000 richm(a)stanfordalumni.org wrote: >> Certainly, here's a recent example: >> <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html> > > I guess I missed it, but exactly which OpenLDAP release(s) had the fix > for this particular problem? That is, how could Red Hat have avoided > this problem by rebasing to a later OpenLDAP? My guess is it was fixed in 2.4.26 or 2.4.27. There have been numerous fixes to cn=config support since 2.4.23, so it is hard to know specifically which one fixes the above issue. ;) >> I will note that Mandriva, at least, continually updates the version >> of OpenLDAP they ship, unlike most distributions, so it definitely >> isn't all. And my point is, Red Hat could do better, and I'd like to >> see them do better. I'd like to see Debian/Ubuntu do better too. >> I.e., this isn't specific to Red Hat, but the discussion here is about >> Red Hat, and what it can do. I discuss Debian and what it can do >> better with the Debian devs on their openldap dev list. > > Then I'd like to hear what Jan and the other Red Hat OpenLDAP > maintainers have to say. Ok. One thing I do with Debian is help triage issues that are reported there with the upstream ITS system if the issues do not appear to be due to the usage of an old version. If there is a simple way to do that with Red Hat, I could help there as well. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 04 Oct '12

04 Oct '12

On 10/04/2012 06:07 PM, Quanah Gibson-Mount wrote: > --On Thursday, October 04, 2012 11:29 PM +0000 > richm(a)stanfordalumni.org wrote: > >> If a customer reports such a problem, Red Hat will respond. > > Again, reactive rather than proactive. Red Hat is not entirely reactive. > >>> There have been approximately 450 committed fixes to RE24 since 2.4.23 >>> was released. So you have about 5% of the fixes in your build. That >>> is just so very encouraging to hear, isn't it? As a customer, >>> wouldn't you truly feel that Red Hat was doing its best for you, but >>> grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair >>> number of those patches you have actually have zero to do with >>> OpenLDAP itself, but with MozNSS... So we're down to what? 3%? >> >> If you will concede the point that quantity != quality, then so will I. > > Certainly, but a fair number of those commits are actual bug fixes. > 2.4.23 in particular had some significant issues. > >> So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new >> features or regressions, ever? > > We have introduced new features, sure. MDB and delta-syncrepl for MMR > would be examples. But they don't impact existing functionality. Famous last words. > And certainly can be the case that regressions are introduced. I'm > not saying to immediately upgrade to the latest OpenLDAP release every > time it comes out. One has to have some common sense about it. > However, it has been over 2 years since 2.4.23 was released. Many > significant and real issues have been fixed since that 2.4.23 was > done, with numerous fixes in the syncrepl area and the cn=config DB, > which Red Hat deploys on RHEL6. Ok. Fair enough. This then gets to the point about whether the Red Hat OpenLDAP maintainers would be willing and able to do this. > >> If this is really the case, then why would Debian or any other >> distribution not want to rebase every time OpenLDAP has a 2.4.x+1 >> release? The FAQ says ". . . upgrading to newer versions is often >> desireable but also means introducing change into stable releases, which >> is exactly opposite to the point of release stability". So it's ok for >> Debian to take a hard line for release stability, but not Red Hat? Or >> is your problem really that Red Hat doesn't openly proclaim that the >> OpenLDAP server included with the distribution is not for "a large site, >> a complicated installation" or the like? So if Red Hat were to provide >> such a disclaimer, it would be ok for Red Hat to take a hard line for >> release stability? > > Debian provides a backports channel that allows its users to update to > later releases. And no, I don't find Debian's hard line any more > acceptable, but at least they provide a supported solution. Red Hat > doesn't provide any supported alternative. Ok. This is feasible. I know that Red Hat has done things like this in the past. This is something that could be done. > >> So what's the difference between Debian and Red Hat with respect to >> OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not >> Debian stable? I suppose the same thing applies to Red Hat - if a Red >> Hat customer has "a large site, a complicated installation, or problems >> for which [they] need to seek help here", they will probably be willing >> to pay extra for extra attention, in the form of adding additional >> resources to build and maintain OpenLDAP themselves, or hiring a firm >> like Symas. > > If you think I don't bash Debian, then you haven't been paying > attention. ;) In any case, my point is about improving how Red Hat > handles things, not about bashing. There are improvements that can be > made. It's hard not to pay attention to you. But I guess your point is that Debian does provide a supported way to get newer versions of packages even on older, stable releases, and that is an important distinction. > > >> Most of the complaints I see from users in the OpenLDAP community are >> about the TLS/SSL support in RHEL6. Do you have evidence to the >> contrary? > > Certainly, here's a recent example: > <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html> I guess I missed it, but exactly which OpenLDAP release(s) had the fix for this particular problem? That is, how could Red Hat have avoided this problem by rebasing to a later OpenLDAP? > >>>>> And then that leads to the question of what exactly they are >>>>> paying RedHat for support for in the first place. >>>> >>>> I like how you use "RedHat" instead of "Red Hat". >>> >>> I like how you avoided addressing my point. >> >> I see your point. I get it - the OpenLDAP community is not happy with >> the way Red Hat handles OpenLDAP. If you are really, truly concerned >> about Red Hat customers using OpenLDAP software, what are you going to >> do about it? If your goal is to get Red Hat to rebase OpenLDAP >> releases on a regular basis, how can you achieve that goal? Complain to >> Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the >> temerity to use rhel/fedora/centos and ask a question in #ldap and >> # openldap and the OpenLDAP mailing lists? If a critical mass of paying >> Red Hat customers tells Red Hat that they are not happy with OpenLDAP, >> then Red Hat will do something about it. That's the demand side. >> >> Red Hat (and probably all OS distributions) has the same problem to some >> extent with all upstream projects. There are probably Apache upstream >> community members who are unhappy with the way Red Hat deals with Apache >> releases. >> >> As for the supply side, if Jan and the other OpenLDAP maintainers feel >> that it is better to rebase than patch, then that's a good start. They >> are the ones who are on the hook - it's their necks if things don't work >> correctly. Once they convince themselves, then they have to convince >> QE, Doc, support, and management that it really is the best policy. And >> part of it is Red Hat's policy towards release stability, which adds >> additional process, but is workable. > > > I will note that Mandriva, at least, continually updates the version > of OpenLDAP they ship, unlike most distributions, so it definitely > isn't all. And my point is, Red Hat could do better, and I'd like to > see them do better. I'd like to see Debian/Ubuntu do better too. > I.e., this isn't specific to Red Hat, but the discussion here is about > Red Hat, and what it can do. I discuss Debian and what it can do > better with the Debian devs on their openldap dev list. Then I'd like to hear what Jan and the other Red Hat OpenLDAP maintainers have to say. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--On Thursday, October 04, 2012 11:29 PM +0000 richm(a)stanfordalumni.org wrote: > If a customer reports such a problem, Red Hat will respond. Again, reactive rather than proactive. >> There have been approximately 450 committed fixes to RE24 since 2.4.23 >> was released. So you have about 5% of the fixes in your build. That >> is just so very encouraging to hear, isn't it? As a customer, >> wouldn't you truly feel that Red Hat was doing its best for you, but >> grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair >> number of those patches you have actually have zero to do with >> OpenLDAP itself, but with MozNSS... So we're down to what? 3%? > > If you will concede the point that quantity != quality, then so will I. Certainly, but a fair number of those commits are actual bug fixes. 2.4.23 in particular had some significant issues. > So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new > features or regressions, ever? We have introduced new features, sure. MDB and delta-syncrepl for MMR would be examples. But they don't impact existing functionality. And certainly can be the case that regressions are introduced. I'm not saying to immediately upgrade to the latest OpenLDAP release every time it comes out. One has to have some common sense about it. However, it has been over 2 years since 2.4.23 was released. Many significant and real issues have been fixed since that 2.4.23 was done, with numerous fixes in the syncrepl area and the cn=config DB, which Red Hat deploys on RHEL6. > If this is really the case, then why would Debian or any other > distribution not want to rebase every time OpenLDAP has a 2.4.x+1 > release? The FAQ says ". . . upgrading to newer versions is often > desireable but also means introducing change into stable releases, which > is exactly opposite to the point of release stability". So it's ok for > Debian to take a hard line for release stability, but not Red Hat? Or > is your problem really that Red Hat doesn't openly proclaim that the > OpenLDAP server included with the distribution is not for "a large site, > a complicated installation" or the like? So if Red Hat were to provide > such a disclaimer, it would be ok for Red Hat to take a hard line for > release stability? Debian provides a backports channel that allows its users to update to later releases. And no, I don't find Debian's hard line any more acceptable, but at least they provide a supported solution. Red Hat doesn't provide any supported alternative. > So what's the difference between Debian and Red Hat with respect to > OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not > Debian stable? I suppose the same thing applies to Red Hat - if a Red > Hat customer has "a large site, a complicated installation, or problems > for which [they] need to seek help here", they will probably be willing > to pay extra for extra attention, in the form of adding additional > resources to build and maintain OpenLDAP themselves, or hiring a firm > like Symas. If you think I don't bash Debian, then you haven't been paying attention. ;) In any case, my point is about improving how Red Hat handles things, not about bashing. There are improvements that can be made. > Most of the complaints I see from users in the OpenLDAP community are > about the TLS/SSL support in RHEL6. Do you have evidence to the contrary? Certainly, here's a recent example: <https://www.openldap.org/lists/openldap-technical/201210/msg00024.html> >>>> And then that leads to the question of what exactly they are >>>> paying RedHat for support for in the first place. >>> >>> I like how you use "RedHat" instead of "Red Hat". >> >> I like how you avoided addressing my point. > > I see your point. I get it - the OpenLDAP community is not happy with > the way Red Hat handles OpenLDAP. If you are really, truly concerned > about Red Hat customers using OpenLDAP software, what are you going to > do about it? If your goal is to get Red Hat to rebase OpenLDAP > releases on a regular basis, how can you achieve that goal? Complain to > Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the > temerity to use rhel/fedora/centos and ask a question in #ldap and ># openldap and the OpenLDAP mailing lists? If a critical mass of paying > Red Hat customers tells Red Hat that they are not happy with OpenLDAP, > then Red Hat will do something about it. That's the demand side. > > Red Hat (and probably all OS distributions) has the same problem to some > extent with all upstream projects. There are probably Apache upstream > community members who are unhappy with the way Red Hat deals with Apache > releases. > > As for the supply side, if Jan and the other OpenLDAP maintainers feel > that it is better to rebase than patch, then that's a good start. They > are the ones who are on the hook - it's their necks if things don't work > correctly. Once they convince themselves, then they have to convince > QE, Doc, support, and management that it really is the best policy. And > part of it is Red Hat's policy towards release stability, which adds > additional process, but is workable. I will note that Mandriva, at least, continually updates the version of OpenLDAP they ship, unlike most distributions, so it definitely isn't all. And my point is, Red Hat could do better, and I'd like to see them do better. I'd like to see Debian/Ubuntu do better too. I.e., this isn't specific to Red Hat, but the discussion here is about Red Hat, and what it can do. I discuss Debian and what it can do better with the Debian devs on their openldap dev list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 04 Oct '12

04 Oct '12

On 10/04/2012 03:19 PM, Quanah Gibson-Mount wrote: > --On Wednesday, October 03, 2012 10:42 PM +0000 > richm(a)stanfordalumni.org wrote: > >> This is quite off-topic, but I could not resist replying. > > Agreed, but Jan opened it up for discussion. > >> On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote: >>> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com >>> wrote: >>> >>>> I understand that you don't want to support older OpenLDAP versions, >>>> builds with non-default libraries, etc. But the users will rather use >>>> the package from their distribution, instead of compiling it by >>>> themselves. And we cannot support users' builds, because we do not >>>> have >>>> the sources and the build environment under control. And we cannot >>>> rebase the packages freely. >>> Redhat needs to come up with a solution to this problem, because >>> they are >>> putting their users in a catch-22 situation. Either they get support >>> from RedHat for a package that will not work, >> >> There are many Red Hat customers who are happy using the openldap server >> that comes with the distribution, and they do escalate problems through >> the support they are paying for, and they do get help and fixes that >> they pay for. > > There are many people who use Red Hat. There are many of those many > who don't use openldap at all. There are many people just now > migrating to RHEL6. My question would be -- Why is Red Hat being > reactive instead of proactive? Upgrade your builds to include the > latest patch level. Also, you may have "many" happy customers using > the distribution version, but I wonder how many would be "happy" if > they knew the risks they were being exposed to because Red Hat will > not update the build. Like data loss in sync replication, etc. If a customer reports such a problem, Red Hat will respond. > >>> or they build their own, and can't >>> get support from RedHat. >> >> Why should they get support from Red Hat if they build their own (in >> which case they have to support it themselves, or use the openldap >> community), or install 3rd party software (in which case they should get >> support from whoever provided the software)? > > You missed my point entirely. My point is they shouldn't have to > build it themselves in the first place. Red Hat, as the provider, > should be a *responsible* entity, and upgrade the build being > provided, so none of their customers get put in the untenable > situation they now face. Either build it themselves to get a working > OpenLDAP server and lose Red Hat support, or deal with the fact that > they are provided with a bad build. > >>> There are reasons new *patch* level releases are >>> made. I see zero reason why RedHat cannot update the versions of >>> OpenLDAP they ship since the fixes are incremental. No one should be >>> running OpenLDAP 2.4.23 as a *production server*. >> >> The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are >> running 2.4.23 with many patches backported from later openldap >> releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 - >> note the "-26" which means a lot more than 26 patches. > > Sorry, but the number "26" is quite unimpressive. It is not meant to impress, just a statement of fact that the RHEL OpenLDAP 2.4.23 is not a stock 2.4.23, but contains many patches backported from 2.4.24 and later. > How many of those 26 patches deal with fixing Red Hat's busted MozNSS > bits? Many, not all. > Your statement here is like having a mechanic tell me how much better > my vehicle is now because he replaced one of twelve bad spark plugs. I did not mean to imply that more patches == better. I just meant more patches == not stock 2.4.23. > > There have been approximately 450 committed fixes to RE24 since 2.4.23 > was released. So you have about 5% of the fixes in your build. That > is just so very encouraging to hear, isn't it? As a customer, > wouldn't you truly feel that Red Hat was doing its best for you, but > grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair > number of those patches you have actually have zero to do with > OpenLDAP itself, but with MozNSS... So we're down to what? 3%? If you will concede the point that quantity != quality, then so will I. > > >>> Keep the RPM version string the >>> same, and note the upstream release in the RPM patchlevel, if that is >>> necessary, but fix the actual code to be current. >> >> That's not what many Red Hat customers pay for. They pay for very >> stable releases with only critical patches applied. The Red Hat >> customers that want to use newer versions have many options - use Fedora >> (which does track upstream openldap closely), build their own, go to >> Symas, etc. > > As is often noted, Fedora is for "bleeding edge". Patch level > releases are not bleeding edge. They are INCREMENTAL FIXES. If Red > Hat's goal is to provide a "stable release", then your current > strategy is utterly flawed. You aren't providing a stable release. > Your fixing your distribution to a *random* release, and then holding > all your customers to that release, regardless of how broken it might > be. If your goal is truly to provide a stable release, then upgrade > the patch level. If I was asking you to jump from 2.3 to 2.4, or 2.4 > to 2.5, where the minor level was changing, I'd agree that would not > qualify as stable. I'm not. I'm saying be responsible, and do right > by your customers. Given them actual stable builds of OpenLDAP, > instead of hiding behind this excuse of sticking to a specific version > for "stability". You will notice that the OpenLDAP foundation does > not mark *any* release as "stable". And that is because people would > use that in the same broken fashion Red Hat is applying here. So moving from OpenLDAP 2.4.x to 2.4.x+1 does not introduce any new features or regressions, ever? If this is really the case, then why would Debian or any other distribution not want to rebase every time OpenLDAP has a 2.4.x+1 release? The FAQ says ". . . upgrading to newer versions is often desireable but also means introducing change into stable releases, which is exactly opposite to the point of release stability". So it's ok for Debian to take a hard line for release stability, but not Red Hat? Or is your problem really that Red Hat doesn't openly proclaim that the OpenLDAP server included with the distribution is not for "a large site, a complicated installation" or the like? So if Red Hat were to provide such a disclaimer, it would be ok for Red Hat to take a hard line for release stability? > > >>> This is why the Debian folks *wisely* recommend that people do *not* >>> use >>> the distribution build for a production server. >> >> Can you point me to a link that has that statement in context? > > Absolutely. They were kind enough to contribute it to the OpenLDAP > FAQ. I'm actually surprised you aren't familiar with it at this point, > given that I routinely note it on IRC and the mailing list: > > <http://www.openldap.org/faq/data/cache/1456.html> So what's the difference between Debian and Red Hat with respect to OpenLDAP? That is, why bash Red Hat's handling of OpenLDAP and not Debian stable? I suppose the same thing applies to Red Hat - if a Red Hat customer has "a large site, a complicated installation, or problems for which [they] need to seek help here", they will probably be willing to pay extra for extra attention, in the form of adding additional resources to build and maintain OpenLDAP themselves, or hiring a firm like Symas. > > >>> As long as RedHat keeps up this policy, the only advice ever for RedHat >>> customers is to build their own RPMs, and get support elsewhere, since >>> RedHat clearly can't keep working server versions together for their >>> customers. >> >> Clearly. Except for the many customers who are quite happy. > > See above. You say they are happy, but would they actually be happy > if they knew the risks Red Hat was knowingly putting their data > under? And in that "happiness" quotient, are you counting the > increasing number of people emailing the -technical list and asking > question on IRC about why their OpenLDAP build is so broken? I'm > think that is likely not the case. Most of the complaints I see from users in the OpenLDAP community are about the TLS/SSL support in RHEL6. Do you have evidence to the contrary? As for other comments, see below. > >>> And then that leads to the question of what exactly they are >>> paying RedHat for support for in the first place. >> >> I like how you use "RedHat" instead of "Red Hat". > > I like how you avoided addressing my point. I see your point. I get it - the OpenLDAP community is not happy with the way Red Hat handles OpenLDAP. If you are really, truly concerned about Red Hat customers using OpenLDAP software, what are you going to do about it? If your goal is to get Red Hat to rebase OpenLDAP releases on a regular basis, how can you achieve that goal? Complain to Jan and I in an OpenLDAP ITS? Bash Red Hat to every user who has the temerity to use rhel/fedora/centos and ask a question in #ldap and #openldap and the OpenLDAP mailing lists? If a critical mass of paying Red Hat customers tells Red Hat that they are not happy with OpenLDAP, then Red Hat will do something about it. That's the demand side. Red Hat (and probably all OS distributions) has the same problem to some extent with all upstream projects. There are probably Apache upstream community members who are unhappy with the way Red Hat deals with Apache releases. As for the supply side, if Jan and the other OpenLDAP maintainers feel that it is better to rebase than patch, then that's a good start. They are the ones who are on the hook - it's their necks if things don't work correctly. Once they convince themselves, then they have to convince QE, Doc, support, and management that it really is the best policy. And part of it is Red Hat's policy towards release stability, which adds additional process, but is workable. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--On Wednesday, October 03, 2012 10:42 PM +0000 richm(a)stanfordalumni.org wrote: > This is quite off-topic, but I could not resist replying. Agreed, but Jan opened it up for discussion. > On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote: >> --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote: >> >>> I understand that you don't want to support older OpenLDAP versions, >>> builds with non-default libraries, etc. But the users will rather use >>> the package from their distribution, instead of compiling it by >>> themselves. And we cannot support users' builds, because we do not have >>> the sources and the build environment under control. And we cannot >>> rebase the packages freely. >> Redhat needs to come up with a solution to this problem, because they are >> putting their users in a catch-22 situation. Either they get support >> from RedHat for a package that will not work, > > There are many Red Hat customers who are happy using the openldap server > that comes with the distribution, and they do escalate problems through > the support they are paying for, and they do get help and fixes that > they pay for. There are many people who use Red Hat. There are many of those many who don't use openldap at all. There are many people just now migrating to RHEL6. My question would be -- Why is Red Hat being reactive instead of proactive? Upgrade your builds to include the latest patch level. Also, you may have "many" happy customers using the distribution version, but I wonder how many would be "happy" if they knew the risks they were being exposed to because Red Hat will not update the build. Like data loss in sync replication, etc. >> or they build their own, and can't >> get support from RedHat. > > Why should they get support from Red Hat if they build their own (in > which case they have to support it themselves, or use the openldap > community), or install 3rd party software (in which case they should get > support from whoever provided the software)? You missed my point entirely. My point is they shouldn't have to build it themselves in the first place. Red Hat, as the provider, should be a *responsible* entity, and upgrade the build being provided, so none of their customers get put in the untenable situation they now face. Either build it themselves to get a working OpenLDAP server and lose Red Hat support, or deal with the fact that they are provided with a bad build. >> There are reasons new *patch* level releases are >> made. I see zero reason why RedHat cannot update the versions of >> OpenLDAP they ship since the fixes are incremental. No one should be >> running OpenLDAP 2.4.23 as a *production server*. > > The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are > running 2.4.23 with many patches backported from later openldap > releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 - > note the "-26" which means a lot more than 26 patches. Sorry, but the number "26" is quite unimpressive. How many of those 26 patches deal with fixing Red Hat's busted MozNSS bits? Your statement here is like having a mechanic tell me how much better my vehicle is now because he replaced one of twelve bad spark plugs. There have been approximately 450 committed fixes to RE24 since 2.4.23 was released. So you have about 5% of the fixes in your build. That is just so very encouraging to hear, isn't it? As a customer, wouldn't you truly feel that Red Hat was doing its best for you, but grabbing a full 5% of fixes to OpenLDAP? And lets not forget a fair number of those patches you have actually have zero to do with OpenLDAP itself, but with MozNSS... So we're down to what? 3%? >> Keep the RPM version string the >> same, and note the upstream release in the RPM patchlevel, if that is >> necessary, but fix the actual code to be current. > > That's not what many Red Hat customers pay for. They pay for very > stable releases with only critical patches applied. The Red Hat > customers that want to use newer versions have many options - use Fedora > (which does track upstream openldap closely), build their own, go to > Symas, etc. As is often noted, Fedora is for "bleeding edge". Patch level releases are not bleeding edge. They are INCREMENTAL FIXES. If Red Hat's goal is to provide a "stable release", then your current strategy is utterly flawed. You aren't providing a stable release. Your fixing your distribution to a *random* release, and then holding all your customers to that release, regardless of how broken it might be. If your goal is truly to provide a stable release, then upgrade the patch level. If I was asking you to jump from 2.3 to 2.4, or 2.4 to 2.5, where the minor level was changing, I'd agree that would not qualify as stable. I'm not. I'm saying be responsible, and do right by your customers. Given them actual stable builds of OpenLDAP, instead of hiding behind this excuse of sticking to a specific version for "stability". You will notice that the OpenLDAP foundation does not mark *any* release as "stable". And that is because people would use that in the same broken fashion Red Hat is applying here. >> This is why the Debian folks *wisely* recommend that people do *not* use >> the distribution build for a production server. > > Can you point me to a link that has that statement in context? Absolutely. They were kind enough to contribute it to the OpenLDAP FAQ. I'm actually surprised you aren't familiar with it at this point, given that I routinely note it on IRC and the mailing list: <http://www.openldap.org/faq/data/cache/1456.html> >> As long as RedHat keeps up this policy, the only advice ever for RedHat >> customers is to build their own RPMs, and get support elsewhere, since >> RedHat clearly can't keep working server versions together for their >> customers. > > Clearly. Except for the many customers who are quite happy. See above. You say they are happy, but would they actually be happy if they knew the risks Red Hat was knowingly putting their data under? And in that "happiness" quotient, are you counting the increasing number of people emailing the -technical list and asking question on IRC about why their OpenLDAP build is so broken? I'm think that is likely not the case. >> And then that leads to the question of what exactly they are >> paying RedHat for support for in the first place. > > I like how you use "RedHat" instead of "Red Hat". I like how you avoided addressing my point. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7409) ldapsearch issue using * in filters
by quanah＠zimbra.com 04 Oct '12

04 Oct '12

--On Thursday, October 04, 2012 9:14 AM +0000 fishakos(a)yahoo.gr wrote: > When i try to use the command >> ldapsearch -h localhost -LLL -x -s sub -d 32 -b > bill=postpaid,msisdn=*,dc=cosmote,dc=ro -b is the base, not a filter. Your search is invalid, and you definitely have provided an invalid DN syntax. This ITS will be closed. I would note that back-ndb was never finished, and is considered beta at best. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7410) ldapsearch issue using * in filters
by fishakos＠yahoo.gr 04 Oct '12

04 Oct '12

Full_Name: Panagiotis Psarrakos Version: 2.4.31 OS: CentOS release 5.5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.205.53.214) My environment consists of MySQL Cluster database with 2 Data nodes and 2 mysql nodes. I have installed openLDAP at both mysql nodesusing back-ndb for retrieving data from MySQL Cluster database. The table OL_dn2id contains entries like the sample below eid |objectclass | a0 | a1 | a2 | a3 --------------------------------------------------------------------------------- 2790113 |entitlement@top| dc=ro | dc=cosmote | msisdn=40765494677 | bill=prepaid --------------------------------------------------------------------------------- 993566 |usertable@top | dc=ro | dc=cosmote | msisdn=40765494677 | bill=postpaid I need to perfrom search based on msisdn or based on attribute bill (bill can have values prepaid/postpaid) When i try to use the command >ldapsearch -h localhost -LLL -x -s sub -d 32 -b bill=postpaid,msisdn=*,dc=cosmote,dc=ro then i receive the error Invalid DN syntax (34) Additional information: invalid DN As i understand i have to use both columns a3 and a2 in order to do searches based on bill attribute but i need to have all msisdn based on the bill value Is there a limitation in openLDAP implementation in using the character * for wildcard LDAP searches?

1 0

(ITS#7409) ldapsearch issue using * in filters
by fishakos＠yahoo.gr 04 Oct '12

04 Oct '12

Full_Name: Panagiotis Psarrakos Version: 2.4.31 OS: CentOS release 5.5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.205.53.214) My environment consists of MySQL Cluster database with 2 Data nodes and 2 mysql nodes. I have installed openLDAP at both mysql nodesusing back-ndb for retrieving data from MySQL Cluster database. The table OL_dn2id contains entries like the sample below eid |objectclass | a0 | a1 | a2 | a3 --------------------------------------------------------------------------------- 2790113 |entitlement@top| dc=ro | dc=cosmote | msisdn=40765494677 | bill=prepaid --------------------------------------------------------------------------------- 993566 |usertable@top | dc=ro | dc=cosmote | msisdn=40765494677 | bill=postpaid I need to perfrom search based on msisdn or based on attribute bill (bill can have values prepaid/postpaid) When i try to use the command >ldapsearch -h localhost -LLL -x -s sub -d 32 -b bill=postpaid,msisdn=*,dc=cosmote,dc=ro then i receive the error Invalid DN syntax (34) Additional information: invalid DN As i understand i have to use both columns a3 and a2 in order to do searches based on bill attribute but i need to have all msisdn based on the bill value Is there a limitation in openLDAP implementation in using the character * for wildcard LDAP searches?

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

This is quite off-topic, but I could not resist replying. On 10/03/2012 03:29 PM, quanah(a)zimbra.com wrote: > --On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote: > >> I understand that you don't want to support older OpenLDAP versions, >> builds with non-default libraries, etc. But the users will rather use >> the package from their distribution, instead of compiling it by >> themselves. And we cannot support users' builds, because we do not have >> the sources and the build environment under control. And we cannot >> rebase the packages freely. > Redhat needs to come up with a solution to this problem, because they are > putting their users in a catch-22 situation. Either they get support from > RedHat for a package that will not work, There are many Red Hat customers who are happy using the openldap server that comes with the distribution, and they do escalate problems through the support they are paying for, and they do get help and fixes that they pay for. > or they build their own, and can't > get support from RedHat. Why should they get support from Red Hat if they build their own (in which case they have to support it themselves, or use the openldap community), or install 3rd party software (in which case they should get support from whoever provided the software)? > There are reasons new *patch* level releases are > made. I see zero reason why RedHat cannot update the versions of OpenLDAP > they ship since the fixes are incremental. No one should be running > OpenLDAP 2.4.23 as a *production server*. The openldap in RHEL6 is *not* a *stock* openldap 2.4.23. They are running 2.4.23 with many patches backported from later openldap releases. The current version is openldap-2.4.23-26.el6_3.2.x86_64 - note the "-26" which means a lot more than 26 patches. > Keep the RPM version string the > same, and note the upstream release in the RPM patchlevel, if that is > necessary, but fix the actual code to be current. That's not what many Red Hat customers pay for. They pay for very stable releases with only critical patches applied. The Red Hat customers that want to use newer versions have many options - use Fedora (which does track upstream openldap closely), build their own, go to Symas, etc. > > This is why the Debian folks *wisely* recommend that people do *not* use > the distribution build for a production server. Can you point me to a link that has that statement in context? > > As long as RedHat keeps up this policy, the only advice ever for RedHat > customers is to build their own RPMs, and get support elsewhere, since > RedHat clearly can't keep working server versions together for their > customers. Clearly. Except for the many customers who are quite happy. > And then that leads to the question of what exactly they are > paying RedHat for support for in the first place. I like how you use "RedHat" instead of "Red Hat". > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by quanah＠zimbra.com 03 Oct '12

03 Oct '12

--On Wednesday, October 03, 2012 8:33 AM +0000 jvcelak(a)redhat.com wrote: > I understand that you don't want to support older OpenLDAP versions, > builds with non-default libraries, etc. But the users will rather use > the package from their distribution, instead of compiling it by > themselves. And we cannot support users' builds, because we do not have > the sources and the build environment under control. And we cannot > rebase the packages freely. Redhat needs to come up with a solution to this problem, because they are putting their users in a catch-22 situation. Either they get support from RedHat for a package that will not work, or they build their own, and can't get support from RedHat. There are reasons new *patch* level releases are made. I see zero reason why RedHat cannot update the versions of OpenLDAP they ship since the fixes are incremental. No one should be running OpenLDAP 2.4.23 as a *production server*. Keep the RPM version string the same, and note the upstream release in the RPM patchlevel, if that is necessary, but fix the actual code to be current. This is why the Debian folks *wisely* recommend that people do *not* use the distribution build for a production server. As long as RedHat keeps up this policy, the only advice ever for RedHat customers is to build their own RPMs, and get support elsewhere, since RedHat clearly can't keep working server versions together for their customers. And then that leads to the question of what exactly they are paying RedHat for support for in the first place. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 10:18 AM, Howard Chu wrote: > Thanks for your comments, Rich. > > richm(a)stanfordalumni.org wrote: >>> On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >>>> Back to this point - surely OpenLDAP libldap is not the only piece of >>>> software that expects to use OpenSSL-style cipher suite names. >>>> libldap is >>>> certainly not the best place to put this translation. >>> I'm not sure about that. We tried to go a "compatible" way with >>> OpenLDAP, >>> don't know about other projects. I will take a look. >> This is the nss_compat_ossl library approach, which attempts to make >> moznss look as much like openssl as possible to applications. I thought >> about trying to use that with openldap a few years ago when we first >> started looking at having openldap support moznss, but Howard had >> already done a great deal of work to make the tls code "pluggable" with >> tls2.c and tls_m.c, which takes the approach of using the moznss code >> directly rather than indirectly through another layer . This has been >> the preferred approach of the Red Hat and Fedora teams that were >> attempting to replace openssl with moznss. nss_compat_ossl has not been >> actively worked on for a couple of years, and would require many changes >> to support multi-init, multiple key/cert databases, and other fixes that >> have gone into tls_m.c. >> >> I suppose we could try to get some sort of openssl cipher name support >> directly in upstream moznss, but they would probably assert that it >> doesn't belong there either. >> >> Maybe we could use nss_compat_ossl to do the mapping of cipher names >> from openssl to moznss? > > That makes sense to me, although if as you say it hasn't been actively > maintained, that sounds like another problem. But certainly if other > apps are using it, then aren't they going to want new cipher suite > support too? > Yes, and imho nss_compat_ossl is the place to do this. But, would it be possible to update the cipher suite list in tls_m.c first, to bring it up to date, then work on updating the compat library?

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 03 Oct '12

03 Oct '12

Thanks for your comments, Rich. richm(a)stanfordalumni.org wrote: >> On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >>> Back to this point - surely OpenLDAP libldap is not the only piece of >>> software that expects to use OpenSSL-style cipher suite names. libldap is >>> certainly not the best place to put this translation. >> I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, >> don't know about other projects. I will take a look. > This is the nss_compat_ossl library approach, which attempts to make > moznss look as much like openssl as possible to applications. I thought > about trying to use that with openldap a few years ago when we first > started looking at having openldap support moznss, but Howard had > already done a great deal of work to make the tls code "pluggable" with > tls2.c and tls_m.c, which takes the approach of using the moznss code > directly rather than indirectly through another layer . This has been > the preferred approach of the Red Hat and Fedora teams that were > attempting to replace openssl with moznss. nss_compat_ossl has not been > actively worked on for a couple of years, and would require many changes > to support multi-init, multiple key/cert databases, and other fixes that > have gone into tls_m.c. > > I suppose we could try to get some sort of openssl cipher name support > directly in upstream moznss, but they would probably assert that it > doesn't belong there either. > > Maybe we could use nss_compat_ossl to do the mapping of cipher names > from openssl to moznss? That makes sense to me, although if as you say it hasn't been actively maintained, that sounds like another problem. But certainly if other apps are using it, then aren't they going to want new cipher suite support too? -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by richm＠stanfordalumni.org 03 Oct '12

03 Oct '12

On 10/03/2012 02:33 AM, jvcelak(a)redhat.com wrote: > Hello, > > On Tuesday 02 of October 2012 14:01:16, hyc(a)symas.com wrote: >> Let's be very clear. I'm not rejecting patches because they come from Red >> Hat. Anyone can plainly see that we have accepted many patches from Red >> Hat. I'm rejecting patches because the relevant code sucks, and when things >> related to them break, the OpenLDAP Project takes the heat even though >> we're not responsible for the breakage. There are CVEs issued against >> OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. >> I wouldn't have a problem with these patches if they actually worked, or if >> Red Hat took the blame when they don't work, but that's not what has >> happened. Instead we get CVE-2012-2668. This was my fault - just a straight up coding error. I take the blame for this. >> We get users asking why their TLS >> connections don't work after upgrading from one RedHat release to the next. >> We get a pointless support burden because users say "we have to run the Red >> Hat packages otherwise they won't support us" but then they don't actually >> ask Red Hat for support, they ask us. I have been active in the openldap community - mailing lists, irc - in answering questions about openldap + moznss. My assumption is that any TLS/SSL problems with openldap on RHEL/Fedora/CentOS are problems with the moznss code. I realize that it is a support burden because the first instinct of a user is to blame openldap. I try to deflect as much of that as possible towards Red Hat. I try to get people who are paid RHEL users to go through support. I try to get "free" users to file bugs. > Sometimes a security bug appears. We are not flawless. I do not know how we > should take the blame. The CVE clearly stated that this is a problem only with > Mozilla NSS backend. Which is used only by Fedora, RHEL, and their derivates. > And the affected code was from RH, anyone can see it in VCS. Tell me what did > you expect us to do and we can try to do it next time. > > If our users have a problem, they should first contact our support. Or create > a bug in our issue tracker. We cannot prevent them from contacting upstream. > And you can always say them 'Sorry, we cannot help you.' if the question is > not general enough or the problem depends on our build. > I understand that you don't want to support older OpenLDAP versions, builds > with non-default libraries, etc. But the users will rather use the package > from their distribution, instead of compiling it by themselves. And we cannot > support users' builds, because we do not have the sources and the build > environment under control. And we cannot rebase the packages freely. > > On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: >> Back to this point - surely OpenLDAP libldap is not the only piece of >> software that expects to use OpenSSL-style cipher suite names. libldap is >> certainly not the best place to put this translation. > I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, > don't know about other projects. I will take a look. This is the nss_compat_ossl library approach, which attempts to make moznss look as much like openssl as possible to applications. I thought about trying to use that with openldap a few years ago when we first started looking at having openldap support moznss, but Howard had already done a great deal of work to make the tls code "pluggable" with tls2.c and tls_m.c, which takes the approach of using the moznss code directly rather than indirectly through another layer . This has been the preferred approach of the Red Hat and Fedora teams that were attempting to replace openssl with moznss. nss_compat_ossl has not been actively worked on for a couple of years, and would require many changes to support multi-init, multiple key/cert databases, and other fixes that have gone into tls_m.c. I suppose we could try to get some sort of openssl cipher name support directly in upstream moznss, but they would probably assert that it doesn't belong there either. Maybe we could use nss_compat_ossl to do the mapping of cipher names from openssl to moznss? > > Jan > >

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 03 Oct '12

03 Oct '12

Hello, On Tuesday 02 of October 2012 14:01:16, hyc(a)symas.com wrote: > Let's be very clear. I'm not rejecting patches because they come from Red > Hat. Anyone can plainly see that we have accepted many patches from Red > Hat. I'm rejecting patches because the relevant code sucks, and when things > related to them break, the OpenLDAP Project takes the heat even though > we're not responsible for the breakage. There are CVEs issued against > OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. > I wouldn't have a problem with these patches if they actually worked, or if > Red Hat took the blame when they don't work, but that's not what has > happened. Instead we get CVE-2012-2668. We get users asking why their TLS > connections don't work after upgrading from one RedHat release to the next. > We get a pointless support burden because users say "we have to run the Red > Hat packages otherwise they won't support us" but then they don't actually > ask Red Hat for support, they ask us. Sometimes a security bug appears. We are not flawless. I do not know how we should take the blame. The CVE clearly stated that this is a problem only with Mozilla NSS backend. Which is used only by Fedora, RHEL, and their derivates. And the affected code was from RH, anyone can see it in VCS. Tell me what did you expect us to do and we can try to do it next time. If our users have a problem, they should first contact our support. Or create a bug in our issue tracker. We cannot prevent them from contacting upstream. And you can always say them 'Sorry, we cannot help you.' if the question is not general enough or the problem depends on our build. I understand that you don't want to support older OpenLDAP versions, builds with non-default libraries, etc. But the users will rather use the package from their distribution, instead of compiling it by themselves. And we cannot support users' builds, because we do not have the sources and the build environment under control. And we cannot rebase the packages freely. On Tuesday 02 of October 2012 14:18:49, hyc(a)symas.com wrote: > Back to this point - surely OpenLDAP libldap is not the only piece of > software that expects to use OpenSSL-style cipher suite names. libldap is > certainly not the best place to put this translation. I'm not sure about that. We tried to go a "compatible" way with OpenLDAP, don't know about other projects. I will take a look. Jan

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 02 Oct '12

02 Oct '12

hyc(a)symas.com wrote: > Jan Vcelak wrote: >> Of course, cipher suite enumeration in MozNSS is possible. But >> translation from OpenSSL names without the translation table would be >> very messy. I still think this is a better solution. Back to this point - surely OpenLDAP libldap is not the only piece of software that expects to use OpenSSL-style cipher suite names. libldap is certainly not the best place to put this translation. -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 02 Oct '12

02 Oct '12

Jan Vcelak wrote: > Of course, cipher suite enumeration in MozNSS is possible. But > translation from OpenSSL names without the translation table would be > very messy. I still think this is a better solution. > >> There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for >> review >> here, plus 2 already committed for 2.4.33. We will not accept patches >> that >> require constant revisiting every time NSS updates. This is too much. >> No more. > > I'm sending one patch per change. And looking at the patches, I do not > think I'm introducing new bugs. It's mostly a fixes for issues present > in the code before I started sending my first patches. And be sure that > I'm testing the TLS heavily before submitting anything. > > I do not understand why you strictly refuse anything which comes from > Fedora or Red Hat. We decided to use MozNSS and you can disagree. We > still want to fix the problems with that backend to use it without any > pain. Sorry, I really do not feel like your feedback is constructive. Let's be very clear. I'm not rejecting patches because they come from Red Hat. Anyone can plainly see that we have accepted many patches from Red Hat. I'm rejecting patches because the relevant code sucks, and when things related to them break, the OpenLDAP Project takes the heat even though we're not responsible for the breakage. There are CVEs issued against OpenLDAP security holes, even though the bugs are in MozNSS, not OpenLDAP. I wouldn't have a problem with these patches if they actually worked, or if Red Hat took the blame when they don't work, but that's not what has happened. Instead we get CVE-2012-2668. We get users asking why their TLS connections don't work after upgrading from one RedHat release to the next. We get a pointless support burden because users say "we have to run the Red Hat packages otherwise they won't support us" but then they don't actually ask Red Hat for support, they ask us. It may seem like this feedback is not constructive, but to me it is not productive for the Project to support a crypto library that was designed for use in a web browser and still assumes that its callers always have a human user sitting in front. Bugs like #7316 shouldn't ever have happened. None of this should come as a surprise to you since I've been stating this from the very first moment MozNSS support was ever mentioned. The NSS crypto architecture was never suited for any setting other than a single user application. It is completely inappropriate for use as a multi-user system library, or in a headless server environment. That was true 4 years ago when we first started working with it and it clearly hasn't improved by today. -- -- 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#7367) [PATCH] MozNSS: update list of supported cipher suites
by jvcelak＠redhat.com 02 Oct '12

02 Oct '12

> This is completely the wrong approach. There is no way you should be > putting > hardcoded constants in libldap that are tied to specific MozNSS > versions. The > MozNSS library needs to provide a cipher enumerator API. Let me quote OpenLDAP documentation: | When using Mozilla NSS, the OpenSSL cipher suite specifications are | used and translated into the format used internally by Mozilla NSS. And FAQ page about Mozilla NSS in OpenLDAP: | OpenLDAP can use Mozilla NSS as the TLS/SSL implementation. If you | previously used OpenLDAP with OpenSSL, and have certificate files, | cipher suites, and other TLS settings specified in your configuration | files, those settings should work exactly the same way with Mozilla | NSS - OpenLDAP with Mozilla NSS knows how to read those settings, | files, etc. and apply them in the same way. The goal is that you | will not be able to tell you are using OpenLDAP with Mozilla NSS | because it will work exactly the same as OpenLDAP with OpenSSL. Which means that if we decided at some point to make the MozNSS layer compatible with OpenSSL, we have to keep up with it now. Of course, cipher suite enumeration in MozNSS is possible. But translation from OpenSSL names without the translation table would be very messy. I still think this is a better solution. > There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for > review > here, plus 2 already committed for 2.4.33. We will not accept patches > that > require constant revisiting every time NSS updates. This is too much. > No more. I'm sending one patch per change. And looking at the patches, I do not think I'm introducing new bugs. It's mostly a fixes for issues present in the code before I started sending my first patches. And be sure that I'm testing the TLS heavily before submitting anything. I do not understand why you strictly refuse anything which comes from Fedora or Red Hat. We decided to use MozNSS and you can disagree. We still want to fix the problems with that backend to use it without any pain. Sorry, I really do not feel like your feedback is constructive. Jan

1 0

Re: (ITS#7367) [PATCH] MozNSS: update list of supported cipher suites
by hyc＠symas.com 01 Oct '12

01 Oct '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20120823-moznss-update-list-of-ciph… > Submission from: (NULL) (209.132.186.34) > > > I'm attaching patch which updates the list of supported cipher suites for > Mozilla NSS backend. All ciphers currently implemented in NSS (3.13.5) are > included. Recall what I said in ITS#7388 about an endless stream of patches to an unmaintainable code base... This is completely the wrong approach. There is no way you should be putting hardcoded constants in libldap that are tied to specific MozNSS versions. The MozNSS library needs to provide a cipher enumerator API. There were 11 MozNSS patches in 2.4.32. Looks like 5 more waiting for review here, plus 2 already committed for 2.4.33. We will not accept patches that require constant revisiting every time NSS updates. This is too much. No more. Tell the NSS guys to fix their design, or tell Red Hat to use a crypto library that actually works for the intended purpose. MozNSS clearly doesn't. > Default ciphers are selected on the same basis as in OpenSSL. > NULL/EXPORT/LOW/MEDIUM/HIGH classification is taken from OpenSSL as well. > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 01 Oct '12

01 Oct '12

arun s wrote: > Hi, > Yes, I am able to reproduce the issue with 2.4.32 > > Making sense of the logs for the exact reproduction is hard since it needs a > lot of operations in a short time. But this will probably help: > > 1. At the start of the test, the group temp_group existed. > > 2. I created a user temp_user and added temp_user to temp_group. > > 3. During replication, the group was replicated first and I got an error 32 > (NO_SUCH_OBJECT) when it tried to modify the memberOf of the temp_user object > (This does not exist in the readslave yet). > > 4. The temp_user object was replicated next, and as you see, querying it does > show a memberOf attribute, proving that this field was replicated. (Note that > I have run OpenLDAP with debug as -1 and verified that the replicated data has > the memberOf field in it. I can provide this too if needed.) I see. The current code drops the memberOf attribute if it was not explicitly requested in the search. However, by default the consumer requests "+" which means "all operational attributes" and so slapd considers memberOf to have been requested. We need to reconsider this aspect of the design. > > 5. The more serious problem occurs when the sequence is reversed and the group > has been deleted as a last operation - The user is replicated first, but since > the group is deleted, it is never replicated and a stale memberOf entry stays > with the user. -- -- 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#7400) Memberof and Syncrepl incompatibility
by arunkumar_1123＠yahoo.com 01 Oct '12

01 Oct '12

---872237384-2137566121-1349092304=:39209 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0AYes, I am able to reproduce the issue with 2.4.32=0A=0A=0AMaking sens= e of the logs for the exact reproduction is hard since it needs a lot of op= erations in a short time. But this will probably help:=0A=0A1. At the start= of the test, the group temp_group existed.=0A=0A2. I created a user temp_u= ser and added temp_user to temp_group.=0A=0A3. During replication, the grou= p was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried= to modify the memberOf of the temp_user object (This does not exist in the= readslave yet).=0A=0A4. The temp_user object was replicated next, and as y= ou see, querying it does show a memberOf attribute, proving that this field= was replicated. (Note that I have run OpenLDAP with debug as -1 and verifi= ed that the replicated data has the memberOf field in it. I can provide thi= s too if needed.)=0A=0A5. The more serious problem occurs when the sequence= is reversed and the group has been deleted as a last operation - The user = is replicated first, but since the group is deleted, it is never replicated= and a stale memberOf entry stays with the user.=0A=0A=0ALOGS:=0A=0A5069157= c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,ou=3Dgroup,dc=3D= example,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A5069157c syn= crepl_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c sync= repl_entry: rid=3D179 inserted UUID 31090ab1-f8a7-4363-83c2-c0ac0d3918d4=0A= 5069157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry:= rid=3D179 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A5069157c slap= _queue_csn: queing 0x4270c730 20121001040100.779862Z#000000#000#000000=0A50= 69157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.779862Z#= 000000#000#000000=0A5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"= uid=3Dtemp_user,dc=3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou= =3Dgroup,dc=3Dexample,dc=3Dcom" failed err=3D32=0A5069157c syncrepl_entry: = rid=3D179 be_modify ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom (0)=0A= 5069157c syncrepl_message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexam= ple,dc=3Dcom, UUID: 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069157c syncrep= l_entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)=0A5069157c syncrepl= _entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea692aa073c=0A5069= 157c syncrepl_entry: rid=3D179 be_search (0)=0A5069157c syncrepl_entry: rid= =3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0A5069157c syncrepl_entry: rid= =3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)=0A=0AThe object tem= p_user:=0A=0Adn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom=0AmemberOf: ou=3Dtem= p_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom=0A=0A=0AWhat is interesting is tha= t in this case, the memberOf field being replicated actually protects the s= lave from incorrect data as the temp_user entry was not present at the time= the group got replicated (The user entry was the second entry in the repli= cation order). On the other hand, a reversed path during replication causes= the mentioned bug.=0A=0AThanks=0A=0A=0A=0A________________________________= =0A From: Howard Chu <hyc(a)symas.com>=0ATo: arunkumar_1123(a)yahoo.com =0ACc: = openldap-its(a)openldap.org =0ASent: Sunday, 30 September 2012 8:51 PM=0ASubj= ect: Re: (ITS#7400) Memberof and Syncrepl incompatibility=0A =0Aarunkumar_1= 123(a)yahoo.com wrote:=0A> Full_Name: Arunkumar shanmugam=0A> Version: 2.4.29= =0A> OS: rhel5=0A> URL: ftp://ftp.openldap.org/incoming/=0A> Submission fro= m: (NULL) (203.83.248.32)=0A>=0A>=0A> Hi,=0A>=0A> I'm currently using Openl= dap 2.4.29 to model an Authorization platform. I=0A> noticed some inconsist= ent behavior with syncrepl and memberof overlays.=0A=0ADoes this issue occu= r with the current release, 2.4.32?=0A>=0A> The issue happens as follows:= =0A>=0A> If I Create groups with a large number of members and delete them = in quick=0A> succession on the writemaster, the data replicated to the read= slave is=0A> incorrect, in particular, the memberof fields of the User obje= cts.=0A>=0A> This seems to happen because the memberof field is getting rep= licated to the=0A> slave nodes, although the documentation states that it s= houldn't.=0A=0AIndeed. Do you have debug logs showing the replication traff= ic, and showing =0Athat the memberof attribute got replicated?=0A=0A> While= =0A> replicating, the User object is replicated inclusive of the memberof f= ields, but=0A> by the time the syncrepl search comes to the group object, i= t has already been=0A> deleted, and hence not replicated. This leaves a dan= gling memberof field in the=0A> read slave instance.=0A>=0A> I was wonderin= g if anyone has faced this issues (I did not see any ITS related=0A> to thi= s), and has a workaround.=0A>=0A> Thanks,=0A> Arunkumar=0A>=0A>=0A=0A=0A-- = =0A=A0 -- Howard Chu=0A=A0 CTO, Symas Corp.=A0 =A0 =A0 =A0 =A0 http://www= .symas.com=0A=A0 Director, Highland Sun=A0 =A0 http://highlandsun.com/hyc/= =0A=A0 Chief Architect, OpenLDAP=A0 http://www.openldap.org/project/ ---872237384-2137566121-1349092304=:39209 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ti= mes new roman, new york, times, serif;font-size:12pt"><div><span style=3D"c= olor: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size= : 13px; background-color: transparent; ">Hi,</span></div><div style=3D"colo= r: rgb(69, 69, 69); font-size: 13px; font-family: arial, helvetica, sans-se= rif; background-color: transparent; font-style: normal; "><span style=3D"co= lor: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size:= 13px; background-color: transparent; "><span class=3D"Apple-tab-span" styl= e=3D"white-space:pre">=09</span>Yes, I am able to reproduce the issue with = 2.4.32</span><br></div><div style=3D"color: rgb(69, 69, 69); font-size: 13p= x; font-family: arial, helvetica, sans-serif; background-color: transparent= ; font-style: normal; "><span><br style=3D"color: rgb(69, 69, 69); font-fam= ily: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color:= rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; ">Making = sense of the logs for the exact reproduction is hard since it needs a lot o= f operations in a short time. But this will probably help:</span><br style= =3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font= -size: 13px; "><br style=3D"color: rgb(69, 69, 69); font-family: arial, hel= vetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69= ); font-family: arial, helvetica, sans-serif; font-size: 13px; ">1. At the = start of the test, the group temp_group existed.</span><br style=3D"color: = rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px= ; "><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, san= s-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-fam= ily: arial, helvetica, sans-serif; font-size: 13px; ">2. I created a user t= emp_user and added temp_user to temp_group.</span><br style=3D"color: rgb(6= 9, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "><br sty= le=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; fo= nt-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-family: arial,= helvetica, sans-serif; font-size: 13px; ">3. During replication, the group= was replicated first and I got an error 32 (NO_SUCH_OBJECT) when it tried = to modify the memberOf of the temp_user object (This does not exist in the = readslave yet).</span><br style=3D"color: rgb(69, 69, 69); font-family: ari= al, helvetica, sans-serif; font-size: 13px; "><br style=3D"color: rgb(69, 6= 9, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "><span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">4. The temp_user object was replicated next, and as yo= u see, querying it does show a memberOf attribute, proving that this field = was replicated. (Note that I have run OpenLDAP with debug as -1 and verifie= d that the replicated data has the memberOf field in it. I can provide this = too if needed.)</span><br style=3D"color: rgb(69, 69, 69); font-family: ari= al, helvetica, sans-serif; font-size: 13px; "><br style=3D"color: rgb(69, 6= 9, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "><span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5. The more serious problem occurs when the sequence i= s reversed and the group has been deleted as a last operation - The user is= replicated first, but since the group is deleted, it is never replicated a= nd a stale memberOf entry stays with the user.</span><br style=3D"color: rg= b(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; = "><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-= serif; font-size: 13px; "><br style=3D"color: rgb(69, 69, 69); font-family:= arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb= (69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; ">LOG= S:</span><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica= , sans-serif; font-size: 13px; "><br style=3D"color: rgb(69, 69, 69); font-= family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"col= or: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: = 13px; ">5069157c syncrepl_message_to_entry: rid=3D179 DN: ou=3Dtemp_group,o= u=3Dgroup,dc=3Dexample,dc=3Dcom, UUID: 31090ab1-f8a7-4363-83c2-c0ac0d3918d4= </span><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, = sans-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-= family: arial, helvetica, sans-serif; font-size: 13px; ">5069157c syncrepl_= entry: rid=3D179 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)</span><br style=3D"co= lor: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size:= 13px; "><span style=3D"color: rgb(69, 69, 69); font-family: arial, helveti= ca, sans-serif; font-size: 13px; ">5069157c syncrepl_entry: rid=3D179 inserted UUID 31090a= b1-f8a7-4363-83c2-c0ac0d3918d4</span><br style=3D"color: rgb(69, 69, 69); f= ont-family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D= "color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-si= ze: 13px; ">5069157c syncrepl_entry: rid=3D179 be_search (0)</span><br styl= e=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; fon= t-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-family: arial, = helvetica, sans-serif; font-size: 13px; ">5069157c syncrepl_entry: rid=3D17= 9 ou=3Dtemp_group,ou=3Dgroup,dc=3Dexample,dc=3Dcom</span><br style=3D"color= : rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13= px; "><span style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica,= sans-serif; font-size: 13px; ">5069157c slap_queue_csn: queing 0x4270c730 = 20121001040100.779862Z#000000#000#000000</span><br style=3D"color: rgb(69, = 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb= (69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "= >5069157c slap_graduate_commit_csn: removing 0xfa035c0 20121001040100.77986= 2Z#000000#000#000000</span><br style=3D"color: rgb(69, 69, 69); font-family= : arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rg= b(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; = ">5069157c conn=3D-1 op=3D0: memberof_value_modify DN=3D"uid=3Dtemp_user,dc= =3Dexample,dc=3Dcom" add memberOf=3D"ou=3Dtemp_group,ou=3Dgroup,dc=3Dexampl= e,dc=3Dcom" failed err=3D32</span><br style=3D"color: rgb(69, 69, 69); font= -family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"co= lor: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size:= 13px; ">5069157c syncrepl_entry: rid=3D179 be_modify ou=3Dtemp_group,ou=3D= group,dc=3Dexample,dc=3Dcom (0)</span><br style=3D"color: rgb(69, 69, 69); = font-family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font= -family: arial, helvetica, sans-serif; font-size: 13px; ">5069157c syncrepl= _message_to_entry: rid=3D179 DN: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom, UUI= D: 748bd1a9-6be3-450b-809c-5ea692aa073c</span><br style=3D"color: rgb(69, 6= 9, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; "><span= style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif= ; font-size: 13px; ">5069157c syncrepl_entry: rid=3D179 LDAP_RES_SEARCH_ENT= RY(LDAP_SYNC_ADD)</span><br style=3D"color: rgb(69, 69, 69); font-family: a= rial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb(6= 9, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; ">5= 069157c syncrepl_entry: rid=3D179 inserted UUID 748bd1a9-6be3-450b-809c-5ea= 692aa073c</span><br style=3D"color: rgb(69, 69, 69); font-family: arial, he= lvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 6= 9); font-family: arial, helvetica, sans-serif; font-size: 13px; ">5069157c syncrepl_entry: = rid=3D179 be_search (0)</span><br style=3D"color: rgb(69, 69, 69); font-fam= ily: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color:= rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13p= x; ">5069157c syncrepl_entry: rid=3D179 uid=3Dtemp_user,dc=3Dexample,dc=3Dc= om</span><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica= , sans-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69); fon= t-family: arial, helvetica, sans-serif; font-size: 13px; ">5069157c syncrep= l_entry: rid=3D179 be_add uid=3Dtemp_user,dc=3Dexample,dc=3Dcom (0)</span><= br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-ser= if; font-size: 13px; "><br style=3D"color: rgb(69, 69, 69); font-family: ar= ial, helvetica, sans-serif; font-size: 13px; "><span style=3D"color: rgb(69= , 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px; ">Th= e object temp_user:</span><br style=3D"color: rgb(69, 69, 69); font-family: arial, = helvetica, sans-serif; font-size: 13px; "><br style=3D"color: rgb(69, 69, 6= 9); font-family: arial, helvetica, sans-serif; font-size: 13px; "><span sty= le=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; fo= nt-size: 13px; ">dn: uid=3Dtemp_user,dc=3Dexample,dc=3Dcom</span><br style= =3D"color: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font= -size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-family: arial, h= elvetica, sans-serif; font-size: 13px; ">memberOf: ou=3Dtemp_group,ou=3Dgro= up,dc=3Dexample,dc=3Dcom</span><br style=3D"color: rgb(69, 69, 69); font-fa= mily: arial, helvetica, sans-serif; font-size: 13px; "><br style=3D"color: = rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: 13px= ; "><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica, san= s-serif; font-size: 13px; "><span style=3D"color: rgb(69, 69, 69); font-fam= ily: arial, helvetica, sans-serif; font-size: 13px; ">What is interesting is that in this case, t= he memberOf field being replicated actually protects the slave from incorre= ct data as the temp_user entry was not present at the time the group got re= plicated (The user entry was the second entry in the replication order). On= the other hand, a reversed path during replication causes the mentioned bu= g.</span><br style=3D"color: rgb(69, 69, 69); font-family: arial, helvetica= , sans-serif; font-size: 13px; "><br style=3D"color: rgb(69, 69, 69); font-= family: arial, helvetica, sans-serif; font-size: 13px; "><span style=3D"col= or: rgb(69, 69, 69); font-family: arial, helvetica, sans-serif; font-size: = 13px; ">Thanks</span></span></div><div><br></div> <div style=3D"font-famil= y: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div st= yle=3D"font-family: 'times new roman', 'new york', times, serif; font-size:= 12pt; "> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> <hr size=3D"1"= > <b><span style=3D"font-weight:bold;">From:</span></b> Howard Chu <hyc(a)symas.com&= gt;<br> <b><span style=3D"font-weight: bold;">To:</span></b> arunkumar_1123= @yahoo.com <br><b><span style=3D"font-weight: bold;">Cc:</span></b> openlda= p-its(a)openldap.org <br> <b><span style=3D"font-weight: bold;">Sent:</span><= /b> Sunday, 30 September 2012 8:51 PM<br> <b><span style=3D"font-weight: bo= ld;">Subject:</span></b> Re: (ITS#7400) Memberof and Syncrepl incompatibili= ty<br> </font> </div> <br><a ymailto=3D"mailto:arunkumar_1123@yahoo.com" hr= ef=3D"mailto:arunkumar_1123@yahoo.com">arunkumar_1123(a)yahoo.com</a> wrote:<= br>> Full_Name: Arunkumar shanmugam<br>> Version: 2.4.29<br>> OS: = rhel5<br>> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_= blank">ftp://ftp.openldap.org/incoming/</a><br>> Submission from: (NULL)= (203.83.248.32)<br>><br>><br>> Hi,<br>><br>> I'm currently = using Openldap 2.4.29 to model an Authorization platform. I<br>> noticed= some inconsistent behavior with syncrepl and memberof overlays.<br><br>Does thi= s issue occur with the current release, 2.4.32?<br>><br>> The issue h= appens as follows:<br>><br>> If I Create groups with a large number o= f members and delete them in quick<br>> succession on the writemaster, t= he data replicated to the readslave is<br>> incorrect, in particular, th= e memberof fields of the User objects.<br>><br>> This seems to happen= because the memberof field is getting replicated to the<br>> slave node= s, although the documentation states that it shouldn't.<br><br>Indeed. Do y= ou have debug logs showing the replication traffic, and showing <br>that th= e memberof attribute got replicated?<br><br>> While<br>> replicating,= the User object is replicated inclusive of the memberof fields, but<br>&gt= ; by the time the syncrepl search comes to the group object, it has already= been<br>> deleted, and hence not replicated. This leaves a dangling memberof field in the<br>> read slave instance.<br>><br>&gt= ; I was wondering if anyone has faced this issues (I did not see any ITS re= lated<br>> to this), and has a workaround.<br>><br>> Thanks,<br>&g= t; Arunkumar<br>><br>><br><br><br>-- <br>  -- Howard Chu<br>&nb= sp; CTO, Symas Corp.          <a href=3D"http://= www.symas.com/" target=3D"_blank">http://www.symas.com</a><br>  Direc= tor, Highland Sun    <a href=3D"http://highlandsun.com/hyc/" tar= get=3D"_blank">http://highlandsun.com/hyc/</a><br>  Chief Architect, = OpenLDAP  <a href=3D"http://www.openldap.org/project/" target=3D"_blan= k">http://www.openldap.org/project/</a><br><br><br> </div> </div> </div></= body></html> ---872237384-2137566121-1349092304=:39209--

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu 01 Oct '12

01 Oct '12

Thanks, my 2 mirror (Master-Master) server say : ebuild U ] net-nds/openldap-2.4.30::gentoo [2.4.23-r1::MC-link-NOC] upgrading to 2.4.30 doesn't cause problems , its correct ? Can i upgrade quietly or i have to do some pre-operations ? Thanks Il giorno 28/set/2012, alle ore 18:57, Quanah Gibson-Mount ha scritto: > --On Friday, September 28, 2012 10:04 AM +0000 a.stefanello(a)mclink.eu wrote: > >> Full_Name: Andrea Stefanello >> Version: 2.4.23-r1 > > Use a current openldap build. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7400) Memberof and Syncrepl incompatibility
by hyc＠symas.com 30 Sep '12

30 Sep '12

arunkumar_1123(a)yahoo.com wrote: > Full_Name: Arunkumar shanmugam > Version: 2.4.29 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.83.248.32) > > > Hi, > > I'm currently using Openldap 2.4.29 to model an Authorization platform. I > noticed some inconsistent behavior with syncrepl and memberof overlays. Does this issue occur with the current release, 2.4.32? > > The issue happens as follows: > > If I Create groups with a large number of members and delete them in quick > succession on the writemaster, the data replicated to the readslave is > incorrect, in particular, the memberof fields of the User objects. > > This seems to happen because the memberof field is getting replicated to the > slave nodes, although the documentation states that it shouldn't. Indeed. Do you have debug logs showing the replication traffic, and showing that the memberof attribute got replicated? > While > replicating, the User object is replicated inclusive of the memberof fields, but > by the time the syncrepl search comes to the group object, it has already been > deleted, and hence not replicated. This leaves a dangling memberof field in the > read slave instance. > > I was wondering if anyone has faced this issues (I did not see any ITS related > to this), and has a workaround. > > Thanks, > Arunkumar > > -- -- 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#7408 published: SECURITY: OpenLDAP multimaster out of sync
by openldap-its＠OpenLDAP.org 30 Sep '12

30 Sep '12

Private ITS#7408 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=7408

1 0

Re: (ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

I've just noticed, that there are subclasses that match the filter criteria. I.e. (attr1>=100) filter part matched attr1 attribute, but (attr1<=200) matched some attr2 (attr2=42) attribute in the same object, and attr2 is a subclass of attr1. This is probably not a bug, better I'll ask the mail-list.

1 0

Re: (ITS#7406) Search with scope for newer entries don't work
by quanah＠zimbra.com 28 Sep '12

28 Sep '12

--On Friday, September 28, 2012 10:04 AM +0000 a.stefanello(a)mclink.eu wrote: > Full_Name: Andrea Stefanello > Version: 2.4.23-r1 Use a current openldap build. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7407) (&(>=)(<=)) filter does not honor upper bound (<=)
by devel＠romanr.info 28 Sep '12

28 Sep '12

Full_Name: Roman Rybalko Version: git a1c2dc6 OS: Linux Debian x64 URL: ftp://ftp.openldap.org/incoming/romanr-120928.tgz Submission from: (NULL) (82.146.61.98) olcAttributeTypes: ( 2.999.777.1.1.1.3 NAME 'logOrderingInteger' DESC 'Integer with ordering' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) olcAttributeTypes: ( 2.999.777.1.1.2.16 NAME 'logTimeInteger' DESC 'Integer time representation' SUP logOrderingInteger ) olcDbIndex: logTimeInteger Search filter (&(logTimeInteger>=1348137600)(logTimeInteger<=1348137620)) provides entries with logTimeInteger>1348137620. Should be only entries with logTimeInteger>=1348137600 and logTimeInteger<=1348137620. See data on ftp.

1 0

(ITS#7406) Search with scope for newer entries don't work
by a.stefanello＠mclink.eu 28 Sep '12

28 Sep '12

Full_Name: Andrea Stefanello Version: 2.4.23-r1 OS: Gentoo Base System release 1.12.14 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.21.176.129) Hi, i have this problem , searching a just created entries using base DN OU doesn't works, searching with his real base DN works. This happened with all new entries. This is an example : SEARCH USING BASE ou=mail : #ldapsearch -b ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS doesn't find nothing . SEARCH USING BASE cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN : #ldapsearch -b cn=DOMAIN.COM,ou=mail,OTHER OU-ROOTDN mailaddress=MAILADDRESS find the entry. The scope used is "sub". After a couple of hour(i think 2 hours) the entry can be found even with the first query, using the "contenitor" ou just like somethings appenned inside the DB. There is a way to find out why we have this behaviour ? Can it be a index problem ? (mailAddress index is ok otherwise the second query shall not work, right?) Can i force something on ldap to resync something inside to find the entry just after is creation ? Thanks for your answer.

1 0

RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com 27 Sep '12

27 Sep '12

Thanks, Quanah. We will try this version and see how it performs. Venkatesh -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Tuesday, September 25, 2012 1:12 PM To: BAGLODI, VENKATESH; openldap-its(a)openldap.org Subject: RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues --On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote: > Thank you so much for the quick reply. We are a bit hesitant to try > 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as > it is mentioned on your Web site > (http://www.openldap.org/software/release/readme.html)? I've been using BDB 4.7.25 (+all patches) for several years, and it has been quite stable. No deadlocks. This version is used on all Zimbra deployments across the world, with plenty of customers having millions of entry DBs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ghola＠rebelbase.com 27 Sep '12

27 Sep '12

I'll have to see if I can track down stderr when this happens. Here is the configuration on that host: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/custom.schema include /etc/openldap/schema/ldapux.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/puppet.schema TLSVerifyClient never TLSCertificateFile /etc/openldap/slapd.pem TLSCertificateKeyFile /etc/openldap/slapd.pem TLSCACertificateFile /etc/openldap/ca.pem pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel sync reverse-lookup on # old ACLs include /etc/openldap/legacy.acl # new ACLs include /etc/openldap/new.acl # Allow anonymous access to userPassword for directory binds access to dn.onelevel="ou=users,dc=example2,dc=net" attrs="userPassword" by anonymous auth by self read by * none # Secure unix passwords access to dn.onelevel="ou=users,ou=posix,dc=example2,dc=net" attrs="userPassword" by self read by * none # Secure unix passwords # legacy access to dn.onelevel="ou=people,dc=example,dc=com" attrs="userPassword" by self read by * none access to dn.onelevel="ou=people,dc=example2,dc=net" attrs="userPassword" by self read by * none # posix info is public access to dn.subtree="ou=posix,dc=example2,dc=net" by * read # posix info is public # legacy access to dn.subtree="ou=people,dc=example,dc=com" by * read access to dn.subtree="ou=people,dc=example2,dc=net" by * read access to dn.subtree="ou=group,dc=example2,dc=net" by * read # access to the base dn access to dn.base="dc=example2,dc=net" by * read # access to the base dn # legacy access to dn.base="dc=example,dc=com" by * none # basic access # legacy access to dn.subtree="dc=example,dc=com" by * none # basic access access to * by users read by * none database hdb suffix "dc=example2,dc=net" rootdn "cn=manager,dc=example2,dc=net" rootpw password index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryUUID,modifyTimestamp eq index location eq index service subinitial index uniqueMember eq directory /var/lib/ldap sizelimit unlimited cachesize 1000000 idlcachesize 3000000 overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net syncrepl rid=1 provider=ldap://syncrepl.example2.net:389 type=refreshAndPersist searchbase="dc=example2,dc=net" bindmethod=simple binddn=user=sync-user,ou=users,dc=example2,dc=net starttls=critical credentials=password retry="10 100 300 +" database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=example,dc=com" "dc=example2,dc=net" overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by hyc＠symas.com 27 Sep '12

27 Sep '12

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.32 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.148.0.72) > > > We are seeing this a few times a week in our environment. Can you provide a sample config to reproduce the issue? What is the exact error message on stderr that accompanies this assert? > #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 > #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 > #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, > oldctrls=0x11251620) at ppolicy.c:870 > #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) > at ppolicy.c:895 > #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at > result.c:541 > #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at > result.c:733 > #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) > at result.c:860 > #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 > #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 > #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) > at op.c:210 > #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at > op.c:243 > #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 > #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at > bind.c:383 > #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 > #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, > arg_v=0x11144d40) at connection.c:1150 > #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at > connection.c:1286 > #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at > tpool.c:688 > #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 > #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 > #24 0x0000000000000000 in ?? () > > -- -- 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#7399) ¡¾Syncrepl¡¿when consumer doing the syncrepl with the provider, reboot the consumer, the cusummer does not continue the task any more
by hyc＠symas.com 27 Sep '12

27 Sep '12

xinrong.li(a)163.com wrote: > Full_Name: mark > Version: 2.4.20 > OS: sles11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (113.116.144.106) > > The current version is 2.4.32. Bugs in old versions will not be investigated. If you can still encounter this issue in the current release, we can work from there. For now this ITS will be closed. > I meet some problem when doing as following: > --> consumer and provider OK. mean that if you add/delete some records to > provider, consumer will sync with the provder > > --> let consumer ldap service stop > --> provider add 100 records > --> consumer start and it will begin to sync the 100 records from provider > --> consumer restart when have sync 60 records from provider > --> consumer wounld not Syncrepl the rest 40 records from provider > > --> then, you add or delete some records, consumer will sync with provider OK > except the 40 records > > May anyone give me some help? thanks! > > my slapd.conf content is thus: > > provider: > database bdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > comsumer: > database hdb > suffix dc=Example,dc=com > rootdn dc=Example,dc=com > directory /var/ldap/db > index objectclass,entryCSN,entryUUID eq > > syncrepl rid=123 > provider=ldap://provider.example.com:389 > type=refreshOnly > interval=01:00:00:00 > searchbase="dc=example,dc=com" > filter="(objectClass=organizationalPerson)" > scope=sub > attrs="cn,sn,ou,telephoneNumber,title,l" > schemachecking=off > bindmethod=simple > binddn="cn=syncuser,dc=example,dc=com" > credentials=secret > > > > -- -- 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#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 27 Sep '12

27 Sep '12

It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema. Comments?

1 0

Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com 27 Sep '12

27 Sep '12

marco(a)schirrmeister.net wrote: > On Sep 18, 2012, at 1:59 PM, hyc(a)symas.com wrote: > >> Marco Schirrmeister wrote: >>> I pulled latest RE24 on Sep 15th and now I get this. >>> >>> ... >>> indexing id=00010d0e >>> indexing id=00010d0f >>> 5056de89 => mdb_tool_entry_reindex: txn_commit failed: Unknown error 18446744073709520830 (-30786) >> >> That was fixed yesterday in commit 8bb10add2465eee34e79abeaa62011e3e234effb. >> Please pull RE24 again today and try again, it should all be working fine. > > Just tested with latest RE24 > > indexing id=00010d0e > indexing id=00010d0f > 50587b72 => mdb_tool_entry_reindex: txn_commit failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786) Thanks for your help, this is now fixed in 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#7405) Improve refint documentation
by hyc＠symas.com 27 Sep '12

27 Sep '12

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) > > > As per debian bug#688857: > > Modifications made by refint are not replicated. They neither update the > modification timestamp nor the CSN used for replication. This is serious > data loss, because the replicas gets out of sync pretty quickly. There > seems to be no way to recover from this discrepancy without doing a > complete replication. > > While this seems to be known, it is not documented at all in the > man-pages related to the refint and memberof overlays. Also it violates > the principle of least surprise, because the changes are not limited to > operational attributes. slapo-refint(5) manpage updated in master. slapo-memberof(5) was updated in 2.4.26 (ITS#6915) so at least that part of the bug report is invalid. -- -- 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#7405) Improve refint documentation
by quanah＠OpenLDAP.org 26 Sep '12

26 Sep '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) As per debian bug#688857: Modifications made by refint are not replicated. They neither update the modification timestamp nor the CSN used for replication. This is serious data loss, because the replicas gets out of sync pretty quickly. There seems to be no way to recover from this discrepancy without doing a complete replication. While this seems to be known, it is not documented at all in the man-pages related to the refint and memberof overlays. Also it violates the principle of least surprise, because the changes are not limited to operational attributes.

1 0

Re: (ITS#7404) back-ldap connection cache error
by hyc＠symas.com 26 Sep '12

26 Sep '12

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.19.96.255) > Submitted by: hyc > > > back-ldap resets the local DN of a connection after a Bind request, even if the > Bind failed. Subsequent operations for that DN will reuse this connection, even > though it hasn't bound successfully. This is clearly wrong. Hm, false alarm. back-ldap is correct here. Something else is lying about its identity... -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs