- openldap-bugs - openldap.org

Re: (ITS#7014) TLS: certificate hostnames are being checked when TLS_REQCERT is se to allow
by hyc＠symas.com 25 Aug '11

25 Aug '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: http://jvcelak.fedorapeople.org/openldap/0001-TLS-do-not-check-hostname-whe… > Submission from: (NULL) (209.132.186.34) > > > Hello. > > If server certificate hostname does not match the server hostname, connection is > closed even if client has set TLS_REQCERT to 'allow'. This is wrong - the > documentation says, that bad certificates are being ignored when TLS_REQCERT is > set to 'allow'. (Other certificate failures (like invalid CA) are handled as > expected - at least with MozNSS.) > > I'm attaching patch, which fixes this behavior. The patch applies on master > branch. (OpenLDAP FTP server for incoming patches reports 'No space left on > device.', that's why I uploaded the patch to fedorapeople.org.) Thanks, applied to 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 24 Aug '11

24 Aug '11

hans.moser(a)ofd-z.niedersachsen.de wrote: > Full_Name: Marc Patermann > Version: 2.4.26 > OS: SLES 11 SP1 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.37.205.30) > > > Hi, > > thankfully Howard tracked down the issue I posted on openldap-technical as > "provider crash on high replication load" down to: > > "I believe the problem is much simpler - the backglue code doesn't install a > handler for the Abandon operation, and this is preventing syncprov's abandon > handler from running, so it never gets to clean up when a consumer connection > closes. > > By now you should submit a bug report to the ITS so we can track this further. > It should only require a small patch to the backglue code." > > The provider has three databases, which are glued together under one root > database. > Each of the three subordinates is replicated by about 60 consumers. > On heavy replication load (all 180 consumers do initial sync), I can crash the > server with on little mod on an object in one of the subordinate databases. > > If I can provide any further information on this, please let me know. A patch for backglue.c is in git master, please test. Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7029) delta-syncrepl MMR segfault
by quanah＠zimbra.com 24 Aug '11

24 Aug '11

--On Wednesday, August 24, 2011 7:41 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.26 + delta-sync MMR > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) Specific segv info from gdb: Core was generated by `/opt/zimbra/openldap/sbin/slapd -l LOCAL0 -u zimbra -h ldap://zqa-128.eng.vmwar'. Program terminated with signal 11, Segmentation fault. #0 0x00007fb1a8515470 in ber_dupbv_x (dst=0x9263c60, src=0x5e, ctx=0x0) at memory.c:500 500 if ( src->bv_val == NULL ) { --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#7029) delta-syncrepl MMR segfault
by quanah＠OpenLDAP.org 24 Aug '11

24 Aug '11

Full_Name: Quanah Gibson-Mount Version: 2.4.26 + delta-sync MMR OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Full backtrace follows. Once this occurs, slapd will not restart. Thread 7 (Thread 7328): #0 0x00007fb1a6c20d03 in epoll_wait () from /lib/libc.so.6 No symbol table info available. #1 0x0000000000438960 in slapd_daemon_task (ptr=0x0) at daemon.c:2528 ns = 1 at = 0 nfds = 10 revents = 0x1f9d000 tvp = 0x7fb195fcbda0 cat = {tv_sec = 1314213868, tv_usec = 0} i = 1 nwriters = 0 now = 1314213788 tv = {tv_sec = 80, tv_usec = 0} tdelta = 1 rtask = 0x242b2d0 l = 2 last_idle_check = 1314213245 ebadf = 0 tid = 0 #2 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #3 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #4 0x0000000000000000 in ?? () No symbol table info available. Thread 6 (Thread 7332): #0 0x00007fb1a7d4685c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007fb1a8730032 in ldap_pvt_thread_cond_wait (cond=0x1e411f0, mutex=0x1e411c8) at thr_posix.c:277 No locals. #2 0x00007fb1a872ea82 in ldap_int_thread_pool_wrapper (xpool=0x1e411c0) at tpool.c:672 pool = 0x1e411c0 task = 0x0 work_list = 0x1e41258 ctx = {ltu_id = 140400668747520, ltu_key = {{ltk_key = 0x43c795, ltk_data = 0x22be100, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x4b2102, ltk_data = 0x22ad440, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x458555, ltk_data = 0x6d37400, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x220f800, ltk_data = 0x24cd160, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x7fb1a368a7d9, ltk_data = 0xd2a1000, ltk_free = 0x7fb1a368a7b6 <search_candidates+569>}, { ltk_key = 0x24a3000, ltk_data = 0x22bf9a0, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x0, ltk_data = 0xf2b4400, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 582 hash = 2017604166 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 5 (Thread 7331): #0 0x00007fb1a7d4685c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007fb1a8730032 in ldap_pvt_thread_cond_wait (cond=0x1e411f0, mutex=0x1e411c8) at thr_posix.c:277 No locals. #2 0x00007fb1a872ea82 in ldap_int_thread_pool_wrapper (xpool=0x1e411c0) at tpool.c:672 pool = 0x1e411c0 task = 0x0 work_list = 0x1e41258 ctx = {ltu_id = 140400677140224, ltu_key = {{ltk_key = 0x4b2102, ltk_data = 0x22adec0, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x43c795, ltk_data = 0x22be900, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x458555, ltk_data = 0x6d37c00, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x220f800, ltk_data = 0x24cd420, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x7fb1a368a7d9, ltk_data = 0x9281000, ltk_free = 0x7fb1a368a7b6 <search_candidates+569>}, { ltk_key = 0x24a3000, ltk_data = 0x22bf420, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x0, ltk_data = 0xf2b2000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 983 hash = 1919713239 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 4 (Thread 7330): #0 0x00007fb1a7d4685c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007fb1a8730032 in ldap_pvt_thread_cond_wait (cond=0x1e411f0, mutex=0x1e411c8) at thr_posix.c:277 No locals. #2 0x00007fb1a872ea82 in ldap_int_thread_pool_wrapper (xpool=0x1e411c0) at tpool.c:672 pool = 0x1e411c0 task = 0x0 work_list = 0x1e41258 ctx = {ltu_id = 140400685532928, ltu_key = {{ltk_key = 0x43c795, ltk_data = 0x22be000, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x4b2102, ltk_data = 0x22ad400, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x458555, ltk_data = 0x6d37000, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x220f800, ltk_data = 0x24cd580, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x7fb1a368a7d9, ltk_data = 0xb291000, ltk_free = 0x7fb1a368a7b6 <search_candidates+569>}, { ltk_key = 0x24a3000, ltk_data = 0x22bf000, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x0, ltk_data = 0x1f21600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 871 hash = 394001255 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 3 (Thread 7329): #0 0x00007fb1a7d4685c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007fb1a8730032 in ldap_pvt_thread_cond_wait (cond=0x1e411f0, mutex=0x1e411c8) at thr_posix.c:277 No locals. #2 0x00007fb1a872ea82 in ldap_int_thread_pool_wrapper (xpool=0x1e411c0) at tpool.c:672 pool = 0x1e411c0 task = 0x0 work_list = 0x1e41258 ctx = {ltu_id = 140400693925632, ltu_key = {{ltk_key = 0x43c795, ltk_data = 0x230d900, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x4b2102, ltk_data = 0x22079c0, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x458555, ltk_data = 0x7081000, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x220f800, ltk_data = 0x24cd6e0, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x7fb1a368a7d9, ltk_data = 0x719a000, ltk_free = 0x7fb1a368a7b6 <search_candidates+569>}, { ltk_key = 0x24a3000, ltk_data = 0x24cdc60, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x0, ltk_data = 0xf2b3200, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 376 hash = 309631352 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #4 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #5 0x0000000000000000 in ?? () No symbol table info available. Thread 2 (Thread 7326): #0 0x00007fb1a7d4303d in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00007fb1a872ff73 in ldap_pvt_thread_join (thread=140400702318336, thread_return=0x0) at thr_posix.c:197 No locals. #2 0x0000000000439b76 in slapd_daemon () at daemon.c:2922 i = 0 rc = 0 listener_tid = 0x22bddb0 #3 0x0000000000416a67 in main (argc=9, argv=0x7fffb556bda8) at main.c:983 i = 9 no_detach = 0 rc = 0 urls = 0x1e31000 "ldap://zqa-128.eng.vmware.com:389 ldapi:///" username = 0x1e2e020 "root" groupname = 0x0 sandbox = 0x0 syslogUser = 128 g_argc = 9 g_argv = 0x7fffb556bda8 configfile = 0x0 configdir = 0x1e2d040 "/opt/zimbra/data/ldap/config" serverName = 0x7fffb556dd95 "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x4f9448 "" l = 140401019110528 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" Thread 1 (Thread 7333): #0 0x00007fb1a8515470 in ber_dupbv_x (dst=0x9263c60, src=0x5e, ctx=0x0) at memory.c:500 new = 0x9263c60 #1 0x00007fb1a8515560 in ber_dupbv (dst=0x9263c60, src=0x5e) at memory.c:523 No locals. #2 0x0000000000449a1f in attr_valadd (a=0x4493b58, vals=0x4c1d0d0, nvals=0x5e, nn=1) at attr.c:433 i = 0 v2 = 0x9263c60 #3 0x0000000000449bc4 in attr_merge (e=0x7fb1937c78f0, desc=0xf2fb480, vals=0x4c1d0d0, nvals=0x5e) at attr.c:487 i = 1 a = 0x4493b50 __PRETTY_FUNCTION__ = "attr_merge" #4 0x00000000004b121a in modify_add_values (e=0x7fb1937c78f0, mod=0x4c1d098, permissive=0, text=0x7fb1937c7e50, textbuf=0x7fb1937c7a20 "modify/delete: zimbraContactMaxNumEntries: no such attribute", textlen=256) at mods.c:161 rc = 32689 op = 0x516494 "replace" a = 0x0 pmod = {sm_desc = 0xf2fb480, sm_values = 0x4c1d0d0, sm_nvalues = 0x5e, sm_numvals = 1, sm_op = 2, sm_flags = 0, sm_type = {bv_len = 57, bv_val = 0x21 <Address 0x21 out of bounds>}} __PRETTY_FUNCTION__ = "modify_add_values" #5 0x00000000004b1a72 in modify_replace_values (e=0x7fb1937c78f0, mod=0x4c1d098, permissive=0, text=0x7fb1937c7e50, textbuf=0x7fb1937c7a20 "modify/delete: zimbraContactMaxNumEntries: no such attribute", textlen=256) at mods.c:376 No locals. #6 0x00007fb1a3681abc in hdb_modify_internal (op=0x7fb1937c8440, tid=0xf2c5c60, modlist=0x4c1d050, e=0x7fb1937c78f0, text=0x7fb1937c7e50, textbuf=0x7fb1937c7a20 "modify/delete: zimbraContactMaxNumEntries: no such attribute", textlen=256) at modify.c:169 rc = 32689 err = 0 mod = 0x4c1d098 ml = 0x4c1d098 save_attrs = 0x4492910 ap = 0x7fb1937c79e0 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "hdb_modify_internal" #7 0x00007fb1a36838a2 in hdb_modify (op=0x7fb1937c8440, rs=0x7fb1937c7e30) at modify.c:638 bdb = 0x2345c00 e = 0x43b9218 ei = 0x6d56ab0 manageDSAit = 2 textbuf = "modify/delete: zimbraContactMaxNumEntries: no such attribute\000\313*\005\000\000\001\000\000\000\000\000\060~|\223\261\177\000\000@{|\223\261\177\000\000Y\r$\243\261\177\000\000\060~|\223\261\177\000\000@\204|\223\261\177\000\000\030\360\301\004\000\000\000\000\260<\357\001\000\000\000\000\320z|\223\261\177\000\000\372\326r\250\261\177\000\000\200\201|\223\261\177\000\000h\360\301\004\000\000\000\000H\360\301\004\000\000\000\000@\v3\002\000\000\000\000\000\306\064\002\000\000\000\000\210\000\000\000\000\000\000\000\060~|\223\261\177\000\000@\204|\223\261\177\000\000\000\000\000\000\000\000\000\000(\000\000\000\000\000\000\000\240~|\223\261\177\000\000\030\360\301\004\000\000\000\000\300~|\223\261\177"... textlen = 256 ltid = 0xf2c5dc0 lt2 = 0xf2c5c60 opinfo = {boi_oe = {oe_next = {sle_next = 0x7fb1937c7ec0}, oe_key = 0x2345c00}, boi_txn = 0xf2c5dc0, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0 '\000'} dummy = {e_id = 94, e_name = {bv_len = 70, bv_val = 0xf40f640 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, e_nname = {bv_len = 70, bv_val = 0xf40f690 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, e_attrs = 0x4493a68, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x6d56ab0} lock = {off = 2388280, ndx = 584, gen = 3, mode = DB_LOCK_READ} num_retries = 0 preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x7fb1a8514f6a, 0x0, 0x7fb1937c7a00, 0x7fb1937c7ab0, 0x4492988} num_ctrls = 0 rc = -1820551424 #8 0x00000000004d3314 in overlay_op_walk (op=0x7fb1937c8440, rs=0x7fb1937c7e30, which=op_modify, oi=0x1edac00, on=0x0) at backover.c:671 func = 0x7fb1a38a9018 rc = 32768 #9 0x00000000004d3552 in over_op_func (op=0x7fb1937c8440, rs=0x7fb1937c7e30, which=op_modify) at backover.c:723 oi = 0x1edac00 on = 0x1ecfe00 be = 0x234fe00 db = {bd_info = 0x7fb1a38a8fc0, bd_self = 0x234fe00, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 39176, 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 = 0x231d500, be_nsuffix = 0x231d4c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x22eb420 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x22eb400 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x2309620, 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 = 0x3b15280, 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 = 0x1e98580, be_pb = 0x0, be_cf_ocs = 0x7fb1a38a8d20, be_private = 0x2345c00, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fb1937c7ea0, sc_response = 0x4d204c <over_back_response>, sc_cleanup = 0, sc_private = 0x1edac00} sc = 0x7a8514e25 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #10 0x00000000004d36bd in over_op_modify (op=0x7fb1937c8440, rs=0x7fb1937c7e30) at backover.c:762 No locals. #11 0x00000000004c0053 in syncrepl_message_to_op (si=0x1e98580, op=0x7fb1937c8440, msg=0x9242140) at syncrepl.c:2304 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4bf0ac}, oe_si = 0x1e98580} ber = 0xf3b2690 modlist = 0x22a9980 ls = 0x75d2c0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7fb1937c7a20 "modify/delete: zimbraContactMaxNumEntries: no such attribute", 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} cb = {sc_next = 0x4c1f018, sc_response = 0x4c73fd <null_callback>, sc_cleanup = 0, sc_private = 0x0} text = 0x0 txtbuf = '\000' <repeats 16 times>, "p\200|\223\261\177", '\000' <repeats 18 times>, "\001", '\000' <repeats 23 times>"\330, \320+\002", '\000' <repeats 12 times>"\330, \320+\002\000\000\000\000\300\200|\223\261\177", '\000' <repeats 34 times>, "\n\000\000\000\000\000\000\000p#\345\001\000\000\000\000\300Z\343\001\000\000\000\000\371\377\377\377\377\377\377\377\020\201|\223\261\177\000\000R\370\273\246\261\177\000\000\000\000\000\000\000\000\000\000@!$\t\000\000\000\000\360\200|\223\261\177", '\000' <repeats 18 times>"\277, ZQ\250\261\177\000\000@l*\002", '\000' <repeats 12 times>"\240, \271\060\017\000\000\000\000@\361\a\a\000\000\000" textlen = 256 bdn = {bv_len = 70, bv_val = 0xf38705b "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} dn = {bv_len = 70, bv_val = 0x4c1d548 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} ndn = {bv_len = 70, bv_val = 0x4c1d650 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0xf30ba00 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #12 0x00000000004bb1e6 in do_syncrep2 (op=0x7fb1937c8440, si=0x1e98580) at syncrepl.c:986 match = 86690595 cookie = {bv_len = 60, bv_val = 0x6d32319 "rid=100,sid=002,csn=20110824192307.974094Z#000000#002#000000"} rctrls = 0xf3b1510 rctrlp = 0xf30b840 syncUUIDs = 0x7fb1937c82b0 bdn = {bv_len = 44, bv_val = 0xf387009 "reqStart=20110824192307.000039Z,cn=accesslog"} syncUUID = {bv_len = 16, bv_val = 0x6d32307 "=\374\334\316b\322\020\060\201F\273\264\355vw\220"} si_tag = 140400660350501 entry = 0x7fb1937c8220 punlock = 0 syncstate = 1 retdata = 0x100000 retoid = 0x38 <Address 0x38 out of bounds> len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 30 times>, "#\323\006\000\000\000\000U#\323\006\000\000\000\000U#\323\006", '\000' <repeats 28 times>, "@\203|\223\261\177\000\000\271\000s\250\261\177\000\000@\203|\223\261\177\000\000@\361u\000\000\000\000\000@\203|\223\261\177\000\000\343\210E\000\000\000\000\000X\204|\223\261\177\000\000\271\000s\250\261\177\000\000\220\203|\223\261\177\000\000\020\323\070\004\000\000\000\000?|\223\261\177\000\000\006Qu\250\261\177\000\000@\204|\223\261\177\000\000\064\204|\223\261\177\000\000\300\006;\017\001\000\000\000\300L\261\003\000\000\000\000\220\006;\017\000\000\000\000@\204|\223\261\177\000\000?|\223\261\177\000\000\371\360C\000\000\000\000\000?|\223\261\177\000\000\b\323\070\004\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7fb1937c82b0 msg = 0x9242140 syncCookie = {ctxcsn = 0xf30b9a0, sids = 0x6d31878, numcsns = 1, rid = 100, octet_str = {bv_len = 60, bv_val = 0x9242100 "rid=100,sid=002,csn=20110824192307.974094Z#000000#002#000000"}, sid = 2, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x9242180, sids = 0xf3b1730, numcsns = 3, rid = 100, octet_str = {bv_len = 0, bv_val = 0x0}, sid = 1, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 0 tout_p = 0x7fb1937c81f0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #13 0x00000000004bd3ed in do_syncrepl (ctx=0x7fb1937c8b50, arg=0x1e36e10) at syncrepl.c:1519 rtask = 0x1e36e10 si = 0x1e98580 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_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}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9990 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9990 ""}, c_listener = 0x501720, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_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}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_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}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x453e95 <slap_send_ldap_result>, c_send_search_entry = 0x454b9d <slap_send_search_entry>, c_send_search_reference = 0x457084 <slap_send_search_reference>, c_send_ldap_extended = 0x4546fc <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x45497a <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fb1937c85b0, o_tag = 102, o_time = 1314213788, o_tincr = 19, o_bd = 0x7fb1937c7c20, o_req_dn = {bv_len = 70, bv_val = 0xf3b2640 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, o_req_ndn = {bv_len = 70, bv_val = 0xf3b2e60 "uid=test.1314213788237.26,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com"}, o_request = {oq_add = {rs_modlist = 0x4c1d050, rs_e = 0x1}, oq_bind = { rb_method = 79810640, rb_cred = {bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = { rs_ava = 0x4c1d050}, oq_modify = {rs_mods = {rs_modlist = 0x4c1d050, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x4c1d050, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 79810640, rs_deref = 0, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 79810640}, oq_cancel = {rs_msgid = 79810640}, oq_extended = {rs_reqoid = {bv_len = 79810640, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 79810640, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fb1937c86f8, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x22eb420 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x22eb400 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x4c1f048, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0xf3b3720 "20110824192307.974094Z#000000#002#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fb1937c7970}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 100, oh_conn = 0x7fb1937c8800, oh_msgid = 0, oh_protocol = 0, oh_tid = 140400660354816, oh_threadctx = 0x7fb1937c8b50, oh_tmpmemctx = 0x2208680, oh_tmpmfuncs = 0x75d220, oh_counters = 0x7a01e0, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 16 times>, 0x7fb1937c8180, 0x0 <repeats 15 times>}} op = 0x7fb1937c8440 rc = 0 dostop = 0 s = 23 i = 36335616 defer = 1 fail = 0 freeinfo = 0 be = 0x234fe00 #14 0x000000000043d1f5 in connection_read_thread (ctx=0x7fb1937c8b50, argv=0x17) at connection.c:1276 rc = 0 cri = {op = 0x0, func = 0x4bcdea <do_syncrepl>, arg = 0x1e36e10, ctx = 0x7fb1937c8b50, nullop = 0} s = 23 #15 0x00007fb1a872eb29 in ldap_int_thread_pool_wrapper (xpool=0x1e411c0) at tpool.c:685 pool = 0x1e411c0 task = 0x4380020 work_list = 0x1e41258 ctx = {ltu_id = 140400660354816, ltu_key = {{ltk_key = 0x4b2102, ltk_data = 0x2208680, ltk_free = 0x4b1ee4 <slap_sl_mem_destroy>}, {ltk_key = 0x24a3000, ltk_data = 0x22f06e0, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x7fb1a368a7d9, ltk_data = 0x4d1d000, ltk_free = 0x7fb1a368a7b6 <search_candidates+569>}, { ltk_key = 0x220f800, ltk_data = 0x22f0840, ltk_free = 0x7fb1a369eb0f <bdb_monitor_update+219>}, {ltk_key = 0x43c795, ltk_data = 0x2315f00, ltk_free = 0x43c5d9 <conn_counter_destroy>}, {ltk_key = 0x458555, ltk_data = 0x6d37800, ltk_free = 0x4584a8 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x1f21600, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 694 hash = 3543316150 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #16 0x00007fb1a7d419ca in start_thread () from /lib/libpthread.so.0 No symbol table info available. #17 0x00007fb1a6c2070d in clone () from /lib/libc.so.6 No symbol table info available. #18 0x0000000000000000 in ?? () No symbol table info available.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 24 Aug '11

24 Aug '11

Fixed up some whitespace formatting. New version is james-leddy-110824.patch on incoming ftp ftp://ftp.openldap.org/incoming/james-leddy-110824.patch

1 0

(ITS#7028) [PATCH] various manpage fixes
by jvcelak＠redhat.com 24 Aug '11

24 Aug '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: Submission from: (NULL) (209.132.186.34) Hi, I have uploaded various manual page fixes which are included in Fedora. ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-slapo-unique.patch - adds information about missing quotes around keyword and uri (maybe ITS #6181) - adds missing <attribute...> parameter ftp://ftp.openldap.org/incoming/jvcelak-20110804-man-ldap_sync.patch - fixes invalid prototype of ldap_sync_destroy Jan

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

File at james-leddy-110823.patch.1 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 Inc. Red Hat Inc. has not assigned rights and/or interest in this work to any party. I, James M. Leddy am authorized by Red Hat Inc., my employer, to release this work under the following terms. Red Hat Inc. 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. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by james.leddy＠redhat.com 23 Aug '11

23 Aug '11

Full_Name: James M Leddy Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.187.233.202) >From RFC 2782: A client MUST attempt to contact the target host with the lowest-numbered priority it can reach. This patch sorts the DNS SRV records by their priority, and additionally gives records with a larger weight a higher probability of appearing earlier. This way, the DNS SRV records are tried in the order of their priority.

1 0

Re: (ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

hans.moser(a)ofd-z.niedersachsen.de schrieb: > Full_Name: Marc Patermann > Version: 2.4.26 > OS: SLES 11 SP1 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.37.205.30) This is only a double post (reloading the ITS page by accident) of #7025 and can be closed. Sorry. Marc

1 0

(ITS#7026) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

Full_Name: Marc Patermann Version: 2.4.26 OS: SLES 11 SP1 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.205.30) Hi, thankfully Howard tracked down the issue I posted on openldap-technical as "provider crash on high replication load" down to: "I believe the problem is much simpler - the backglue code doesn't install a handler for the Abandon operation, and this is preventing syncprov's abandon handler from running, so it never gets to clean up when a consumer connection closes. By now you should submit a bug report to the ITS so we can track this further. It should only require a small patch to the backglue code." The provider has three databases, which are glued together under one root database. Each of the three subordinates is replicated by about 60 consumers. On heavy replication load (all 180 consumers do initial sync), I can crash the server with on little mod on an object in one of the subordinate databases. If I can provide any further information on this, please let me know.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by masarati＠aero.polimi.it 23 Aug '11

23 Aug '11

> >> back-sql calls backsql_BindParamBerVal(), which indeed considers the >> data as >> SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but >> back-sql >> will need to know what attribute values need to be treated as binaries. >> A >> general approach to this requires to modify the attribute mapping, to >> add a >> "type" flag. >> >> p. >> > I have carefully read the documentation (man slapd-sql) but could not > find how to modify the attribute mapping and add a "type" flag. I meant: modify the code. Since back-sql is basically unmaintained (any volunteers out there?) this feature won't likely be added, not to mention the fact that it would break all existing installations. p.

1 0

(ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hans.moser＠ofd-z.niedersachsen.de 23 Aug '11

23 Aug '11

Full_Name: Marc Patermann Version: 2.4.26 OS: SLES 11 SP1 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.37.205.30) Hi, thankfully Howard tracked down the issue I posted on openldap-technical as "provider crash on high replication load" down to: "I believe the problem is much simpler - the backglue code doesn't install a handler for the Abandon operation, and this is preventing syncprov's abandon handler from running, so it never gets to clean up when a consumer connection closes. By now you should submit a bug report to the ITS so we can track this further. It should only require a small patch to the backglue code." The provider has three databases, which are glued together under one root database. Each of the three subordinates is replicated by about 60 consumers. On heavy replication load (all 180 consumers do initial sync), I can crash the server with on little mod on an object in one of the subordinate databases. If I can provide any further information on this, please let me know.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by daniil＠chics.ru 23 Aug '11

23 Aug '11

> back-sql calls backsql_BindParamBerVal(), which indeed considers the data as > SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql > will need to know what attribute values need to be treated as binaries. A > general approach to this requires to modify the attribute mapping, to add a > "type" flag. > > p. > I have carefully read the documentation (man slapd-sql) but could not find how to modify the attribute mapping and add a "type" flag.

1 0

Re: (ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by Pierangelo Masarati 22 Aug '11

22 Aug '11

back-sql calls backsql_BindParamBerVal(), which indeed considers the data as SQL_C_CHAR, SQL_VARCHAR. A binary variant can be easily defined, but back-sql will need to know what attribute values need to be treated as binaries. A general approach to this requires to modify the attribute mapping, to add a "type" flag. p.

1 0

Re: (ITS#6993)
by masarati＠aero.polimi.it 22 Aug '11

22 Aug '11

> Hello > > This problem occurs at the end of the connection init. > At the end of the connection_init, the connection is provided to the > listener list (through slapd_add_internal call) and then, the connection > mutex is freed. > > ==> At this point, the connection is available to the listener but the > back end initialization has not been done. > > The backend_connection_init call is done out of the connection mutex > protection. > If the connection mutex is freed after the connection_init call, all the > back end should performed their initialization before it could be used > in the operation Thank you. I understand your point, and I agree that the connection initialization is not over until all backends had an opportunity to deal with it. My concern is about any harm this change may cause to existing code. A quick search in official backends and overlays shows that only slapo-rwm(5) is currently setting this hook. Let alone this possible bug, this fact triggers something in my mind: bi_connection_init() might not be the best place for your initialization to occur. In fact, this is intended to provide something to *all* connections, but a connection being created does not imply that your backend will be used, so it may be a waste of resources to initialize your backend for *all* connections. You might be better off initializing your backend's connections only when they are actually needed, i.e. each operation within your backend should (mutex-protected) check whether initialization occurred and, if it didn't, do it; if it's ongoing, just pause waiting for it to finish. p.

1 0

(ITS#6993)
by yann.carre＠alcatel-lucent.com 22 Aug '11

22 Aug '11

Hello This problem occurs at the end of the connection init. At the end of the connection_init, the connection is provided to the listener list (through slapd_add_internal call) and then, the connection mutex is freed. ==> At this point, the connection is available to the listener but the back end initialization has not been done. The backend_connection_init call is done out of the connection mutex protection. If the connection mutex is freed after the connection_init call, all the back end should performed their initialization before it could be used in the operation Regards Yann Carre

1 0

Re: (ITS#6993) Backend Connection problem
by masarati＠aero.polimi.it 22 Aug '11

22 Aug '11

[you must reply to the ITS to have your messages injected in the system] > Hello > > This problem occurs at the end of the connection init. > At the end of the connection_init, the connection is provided to the > listener list (through slapd_add_internal call) and then, the connection > mutex is freed. > > ==> At this point, the connection is available to the listener but the > back end initialization has not been done. > > The backend_connection_init call is done out of the connection mutex > protection. > If the connection mutex is freed after the connection_init call, all the > back end should performed their initialization before it could be used > in the operation

1 0

(ITS#7024) OpenLDAP does not save the attribute "jpegPhoto" in the sql database
by daniil＠chics.ru 22 Aug '11

22 Aug '11

Full_Name: Daniil Harun Version: 2.4.26 OS: FreeBSD, Linux URL: Submission from: (NULL) (80.85.151.246) OpenLDAP does not save the attribute "jpegphoto" in the sql database. Use back-sql, unixodbc and postgresql database. The reason for the problem of the use of the data type SQL_VARCHAR instead of SQL_LONGVARBINARY. slapd debug output: backsql_modify_internal(): adding new values for attribute "jpegPhoto" backsql_modify_internal(): arg(2)=1 backsql_modify_internal(): arg(1)="����"; executing "UPDATE personal SET jpegphoto=? WHERE id=?" backsql_modify_internal(): add_proc execution failed (rc=-1, prc=0) Return code: -1 nativeErrCode=7 SQLengineState=22021 msg="ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query" SQL tracing is enabled: [ODBC][23880][1313994179.641693][SQLPrepare.c][196] Entry: Statement = 0x293eae00 SQL = [UPDATE personal SET jpegphoto=? WHERE id=?][length = 42 (SQL_NTS)] [ODBC][23880][1313994179.641791][SQLPrepare.c][371] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.641886][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 2 Param Type = 1 C Type = -27 SQL_C_UBIGINT SQL Type = 4 SQL_INTEGER Col Def = 0 Scale = 0 Rgb Value = 0xbf1fc7a4 Value Max = 0 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.641988][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642182][SQLBindParamet[ODBC][23880][1313994179.641693][SQLPrepare.c][196] Entry: Statement = 0x293eae00 SQL = [UPDATE personal SET jpegphoto=? WHERE id=?][length = 42 (SQL_NTS)] [ODBC][23880][1313994179.641791][SQLPrepare.c][371] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.641886][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 2 Param Type = 1 C Type = -27 SQL_C_UBIGINT SQL Type = 4 SQL_INTEGER Col Def = 0 Scale = 0 Rgb Value = 0xbf1fc7a4 Value Max = 0 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.641988][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642182][SQLBindParameter.c][217] Entry: Statement = 0x293eae00 Param Number = 1 Param Type = 1 C Type = 1 SQL_C_CHAR SQL Type = 12 SQL_VARCHAR Col Def = 2790 Scale = 0 Rgb Value = 0x29529700 Value Max = 2790 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.642284][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642741][SQLExecute.c][187] Entry: Statement = 0x293eae00 [ODBC][23880][1313994179.645733][SQLExecute.c][348] Exit:[SQL_ERROR] DIAG [22021] ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query er.c][217] Entry: Statement = 0x293eae00 Param Number = 1 Param Type = 1 C Type = 1 SQL_C_CHAR SQL Type = 12 SQL_VARCHAR Col Def = 2790 Scale = 0 Rgb Value = 0x29529700 Value Max = 2790 StrLen Or Ind = 0x0 [ODBC][23880][1313994179.642284][SQLBindParameter.c][397] Exit:[SQL_SUCCESS] [ODBC][23880][1313994179.642741][SQLExecute.c][187] Entry: Statement = 0x293eae00 [ODBC][23880][1313994179.645733][SQLExecute.c][348] Exit:[SQL_ERROR] DIAG [22021] ERROR: invalid byte sequence for encoding "UTF8": 0xff; Error while executing the query OpenLDAP uses the wrong data - types SQL_C_CHAR,SQL_VARCHAR instead of SQL_C_BINARY,SQL_LONGVARBINARY. How to make use of the correct data types?

1 0

ITS#7021
by masarati＠aero.polimi.it 21 Aug '11

21 Aug '11

All in all, I think it is better to stick with the spec and with the documentation, although I also added some notes to slapo-ppolicy(5). p.

1 0

Re: (ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> Full_Name: Manuel Gaupp > Version: 2.4.26 > OS: Linux 2.6.18 (CentOS 5.6 x86_64) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.208.112.253) > > > Under the following circumstances OpenLDAP crashes when a chained search > does not return with result code 0: > - "rwm" overlay used in a global context > - "chain" overlay used in a database specifix context > > (gdb) bt > #0 0x0000000400040004 in ?? () > #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) > at result.c:539 > #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:724 > #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, > rs=0x42a07ca0) at chain.c:1165 > #5 0x00000000004820ca in over_back_response (op=0x197834b0, > rs=0x42a07ca0) > at backover.c:237 > #6 0x000000000042e535 in slap_response_play (op=0x197834b0, > rs=0x42a07ca0) > at result.c:505 > #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, > rs=0x42a07ca0) > at result.c:579 > #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, > rs=0x42a07ca0) at result.c:851 > #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:499 > #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 > #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:402 > #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, > which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 > #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, > which=op_search) at backover.c:723 > #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) > at search.c:247 > #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, > arg_v=<value optimized out>) at connection.c:1138 > #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) > at tpool.c:685 > #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 > #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 > > OpenLDAP 2.4.26 was built using: > ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb > > This issue can be reproduced using the following configuration > (referred as 'slapd.conf.proxy') > ------------------------------------------ > overlay rwm > # There might be some rewrite directives > database bdb > suffix "o=example" > rootdn "cn=admin,o=example" > rootpw secret > directory /root/db.proxy > overlay chain > chain-return-error true > chain-uri "ldap://localhost:38977" > ------------------------------------------ > The process is started on port 389 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" > > Create the following entry in this server: > dn: cn=ldap,o=example > objectclass: extensibleObject > objectclass: referral > ref: ldap://localhost:38977/cn=real,o=example > > To reproduce the error there has to be another server where the referral > points to. It contains the following minimal configuration: > (referred as 'slapd.conf.server') > ------------------------------------------ > database bdb > suffix "cn=real,o=example" > rootdn "cn=admin,cn=real,o=example" > rootpw secret > directory /root/db.server > ------------------------------------------ > The process is started on port 38977 with plain ldap > /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" > > Using the following ldapsearch, slapd crashes: > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "ou=abc,cn=ldap,o=example" 1.1 > > Whereas the following ldapsearch returns with "success" > ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ > -x -b "cn=ldap,o=example" 1.1 > > Deactivating the "rwm" overlay prevents from this issue. So I think the > problem can be found somewhere in the rwm sources. I'm afraid that's unavoidable given the stacking order of the overlays. This will likely be fixed only when ITS#6166 is addressed, i.e. in OpenLDAP 2.5. p.

1 0

Re: (ITS#6993) Backend Connection problem
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> Full_Name: Yann Carre > Version: 2.4.26 > OS: red hat 5 (64 bits) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.208.49.20) > > > I work on a specific Backend > I have provided in my back end a function to the bi_connection_init > pointer. > This function adds a context needed in the operation backend function > (search, > ...) > > When several connections start up, my LDAP server crashes. > The crash arrives because the context is not created before the call to > do_searh. > The connection is provided to the application Backend before my Back end > connection_init. > I have checked it with the debugger and see that the thread with > initialize the > connection is suspend before the backend connection_init. In another > thread, the > search function is executed without any context attached to the > connection. > > This problem seems to be bring because the connection mutex is freed > before the > calling of the Back end connection_init in the function connection_init > (connection.c). > > I have moved this mutex after the backend connection_init and it seems to > work. > > Would you confirm this analysis and take the correction in account? Honestly, if that context you mention is connection-specific, I don't see how this could happen, since operations on that connection should not be possible until connection_init() returns. OTOH, if the context is global, you should initialize it differently, and protect it from being used before its initialization is complete, e.g. by a specific mutex that is completely internal to your backend. In any case, it is not clear how this can be an OpenLDAP bug. You should provide a clearer evidence. In the absence, I'd consider this ITS closed. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 19 Aug '11

19 Aug '11

> masarati(a)aero.polimi.it wrote: >> The patch is the result of my reading in 5 minutes a single portion of a >> spec I read in detail years ago, so my interpretation could not be the >> most correct. > > But your interpretation makes sense: E.g. system accounts most times do > not > need to change their own password. And for security reasons you might want > to > avoid that. Think of a the case where the password of a more exposed > system is > known by an attacker (which is likely a very bad case anyway). But at > least > the attacker should not be able to disable this service by setting a new > password. > > Yes, this can be done with ACLs. But you might already have a password > policy > assigned to this special system accounts because you don't want the system > accounts' password to expire. So adding an extra ACL is more work > especially > if system accounts are spread across a more complicated DIT. Well, as a counter-example, if security is compromised, then setting pwdAllowUserChange to FALSE would only prevent password modification for users that fall under that password policy, while others would need to be protected anyway using ACLs. And if security is seriously compromised, none of these would work, because rootdn circumvents all checks. So giving different orthogonal means to obtain similar but not identical effects sounds to me making things more complicated than they ought to be. Given the fact that pwdAllowUserChange is a gross subset of ACLs, I'd rather discourage its usage through clear documentation than try to make it conform to some or some other interpretation of the specs. p.

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by michael＠stroeder.com 18 Aug '11

18 Aug '11

masarati(a)aero.polimi.it wrote: > The patch is the result of my reading in 5 minutes a single portion of a > spec I read in detail years ago, so my interpretation could not be the > most correct. But your interpretation makes sense: E.g. system accounts most times do not need to change their own password. And for security reasons you might want to avoid that. Think of a the case where the password of a more exposed system is known by an attacker (which is likely a very bad case anyway). But at least the attacker should not be able to disable this service by setting a new password. Yes, this can be done with ACLs. But you might already have a password policy assigned to this special system accounts because you don't want the system accounts' password to expire. So adding an extra ACL is more work especially if system accounts are spread across a more complicated DIT. Ciao, Michael.

1 0

(ITS#7023) TLSCACertificateFile description in slapd.conf.5 is missing critical information
by Frank.Swasey＠uvm.edu 18 Aug '11

18 Aug '11

Full_Name: Francis Swasey Version: 2.4.26 OS: Linux URL: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.… Submission from: (NULL) (132.198.107.64) The following referenced patch copies critical information that should be in the slapd.conf.5 man page from the admin guide: http://www.uvm.edu/~fcs/0001-document-TLSCACertificateFile-in-the-man-page.…

1 0

Re: (ITS#7021) pwdAllowUserChange: FALSE disallows password change by anybody
by masarati＠aero.polimi.it 18 Aug '11

18 Aug '11

> masarati(a)aero.polimi.it wrote: >>>> Then the patch is trivial: >>>> [..] >>>> If there's consensus, I'll commit it. >>> >>> Seems like a pointless change. You must set ACLs for this type of >>> modification >>> to be allowed. Since you must set ACLs anyway, there is no good reason >>> to >>> use >>> the pwdAllowUserChange policy setting in the first place. In general >>> the >>> pwdAllowUserChange option is only useful on systems that do not already >>> provide fine grained access controls. >> >> Agree (see my previous message). For this purpose, I suggest to add, in >> slapo-ppolicy(5), a comment about discouraging the use of >> pwdAllowUserChange since OpenLDAP provides fine-grain ACLs. > > I already knew that this can be achieved by ACLs but... > > 1. OpenLDAP should behave as stated in the ppolicy spec and the man-pages. > > 2. sometimes it'd be more handy to use this flag in an already existing > pwdPolicy entry than defining additional ACLs. > > Since this patch seems so trivial why not commit it? The patch is the result of my reading in 5 minutes a single portion of a spec I read in detail years ago, so my interpretation could not be the most correct. Since Howard implemented slapo-ppolicy(5), I believe his interpretation of the spec is more accurate. The fact that he interprets this flag as a complete replacement of ACLs on systems where they are not granular enough lets me think that its behavior should be broader (i.e. apply to all users) rather than strictly sticking to the word (i.e. apply to self only). That's why I'm seeking consensus before committing a patch (that could be harmful, as the current behavior of slapo-ppolicy(5) makes this flag work as a complete alternative to ACLs, while the new behavior, not complemented by appropriate ACLs, could allow anybody but self to change the pwd). p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs