(ITS#7219) back-mdb crash when used as accesslog
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: HEAD 3/30/2012
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.108.184.39)
4f764244 => access_allowed: search access to
"reqStart=20120330232137.000001Z,cn=accesslog" "reqStart" requested
4f764244 <= root access granted
4f764244 => access_allowed: search access granted by manage(=mwrscxd)
4f764244 <= test_filter 6
4f764244 send_ldap_result: conn=-1 op=0 p=0
4f764244 send_ldap_result: err=0 matched="" text=""
4f764244 ==> mdb_delete: reqStart=20120330215514.000205Z,cn=accesslog
4f764244 mdb_dn2entry("cn=accesslog")
4f764244 => mdb_dn2id("cn=accesslog")
4f764244 <= mdb_dn2id: got id=0x1
4f764244 => mdb_entry_decode:
4f764244 <= mdb_entry_decode
4f764244 mdb_dn2entry("reqStart=20120330215514.000205Z,cn=accesslog")
4f764244 => mdb_dn2id("reqStart=20120330215514.000205Z,cn=accesslog")
4f764244 <= mdb_dn2id: got id=0x12d
4f764244 => mdb_entry_decode:
4f764244 <= mdb_entry_decode
4f764244 => access_allowed: delete access to "cn=accesslog" "children"
requested
4f764244 <= root access granted
4f764244 => access_allowed: delete access granted by manage(=mwrscxd)
4f764244 => access_allowed: delete access to
"reqStart=20120330215514.000205Z,cn=accesslog" "entry" requested
4f764244 <= root access granted
4f764244 => access_allowed: delete access granted by manage(=mwrscxd)
4f764244 => mdb_dn2id_delete 0x12d
slapd: ./../../../libraries/libmdb/mdb.c:5136: mdb_node_move: Assertion
`!((long)srcnode&1)' failed.
Thread 6 (Thread 0x7fd7d82b6700 (LWP 32051)):
#0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550,
mutex=0x7d4528) at thr_posix.c:277
No locals.
#2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at
tpool.c:675
pool = 0x7d4520
task = 0x0
work_list = 0x7d45b8
ctx = {ltu_id = 140565021419264, ltu_key = {{ltk_key = 0x4b380b,
ltk_data = 0x934f10, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key =
0x7fffda4bc010, ltk_data = 0x934f50,
ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0} <repeats 27 times>, {ltk_key = 0x0, ltk_data =
0x7ffff66c9ca9, 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 = 448
hash = 3457894848
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4 0x00007ffff642570d in clone () from /lib/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 5 (Thread 0x7fd7d8ab7700 (LWP 32050)):
#0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550,
mutex=0x7d4528) at thr_posix.c:277
No locals.
#2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at
tpool.c:675
pool = 0x7d4520
task = 0x0
work_list = 0x7d45b8
ctx = {ltu_id = 140565029811968, ltu_key = {{ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data =
0x7ffff66c9ca9, 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 = 336
hash = 1932182864
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4 0x00007ffff642570d in clone () from /lib/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 4 (Thread 0x7fd7d92b8700 (LWP 32049)):
#0 0x00007ffff66cd85c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7b8e2be in ldap_pvt_thread_cond_wait (cond=0x7d4550,
mutex=0x7d4528) at thr_posix.c:277
No locals.
#2 0x00007ffff7b8cc22 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at
tpool.c:675
pool = 0x7d4520
task = 0x0
work_list = 0x7d45b8
ctx = {ltu_id = 140565038204672, ltu_key = {{ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0} <repeats 29 times>, {ltk_key = 0x0, ltk_data =
0x7ffff66c9ca9, 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 = 545
hash = 1836313121
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4 0x00007ffff642570d in clone () from /lib/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 3 (Thread 0x7fd7d9ab9700 (LWP 32048)):
#0 0x00007ffff6372a75 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0x00007ffff63765c0 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0x00007ffff636b941 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3 0x00007ffff140aedc in mdb_node_move (csrc=0x7fd7d9ab7890,
cdst=0x7fd7d9ab7b30) at ./../../../libraries/libmdb/mdb.c:5136
rc = 0
srcnode = 0x661d8b9
key = {mv_size = 44, mv_data = 0x7fffda4bc0d0}
data = {mv_size = 1, mv_data = 0x817c60}
srcpg = 140737240913598
flags = 0
__PRETTY_FUNCTION__ = "mdb_node_move"
#4 0x00007ffff140c8e7 in mdb_rebalance (mc=0x7fd7d9ab7b30) at
./../../../libraries/libmdb/mdb.c:5537
node = 0x661a502
rc = 0
ptop = 1
mn = {mc_next = 0x100000000, mc_orig = 0x700000008, mc_xcursor = 0x0,
mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40,
mc_dbflag = 0x800000008 <Address 0x800000008 out of bounds>, mc_snum =
3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040, 0x661d070,
0x7fd7d9ab7920, 0x7ffff140fb9c,
0x7fd7d9ab7af0, 0x7fffda4bc0d0, 0x7fd7d9ab7b80, 0x400000004,
0x7fd7d9ab7b80, 0x7ffff1401865, 0x1d9ab99c0, 0x934a00, 0x78, 0x7fd7d9ab7bd0,
0x6613328, 0x84, 0x1, 0x1,
0x7fd7d9ab79b0, 0x1f14056be, 0x934d40, 0x7fd7d9ab7bd0, 0x6614ff0,
0x6614ff0, 0x6614ff0, 0x6613300, 0x7fd7d9ab7bb0, 0x7ffff1405cdf, 0x8,
0x1da52fff0, 0x661c8b8}, mc_ki = {1,
12, 30, 0, 20464, 1633, 0, 0, 49142, 1633, 0, 0, 49224, 1633, 0, 0,
48240, 1633, 0, 0, 984, 0, 0, 0, 18409, 63036, 32767, 0, 4, 0, 23, 0}}
__PRETTY_FUNCTION__ = "mdb_rebalance"
#5 0x00007ffff140bf61 in mdb_page_merge (csrc=0x7fd7d9ab7b30, cdst=0x934b88) at
./../../../libraries/libmdb/mdb.c:5366
rc = 0
i = 12
j = 24
srcnode = 0x7febda5e4c28
key = {mv_size = 74, mv_data = 0x7febda5e4c30}
data = {mv_size = 0, mv_data = 0x7febda5e4c7a}
nkeys = 12
__PRETTY_FUNCTION__ = "mdb_page_merge"
#6 0x00007ffff140c938 in mdb_rebalance (mc=0x934b88) at
./../../../libraries/libmdb/mdb.c:5541
node = 0x661bff6
rc = 0
ptop = 2
mn = {mc_next = 0x661c060, mc_orig = 0x7ffff140195a, mc_xcursor = 0x0,
mc_txn = 0x6613300, mc_dbi = 4, mc_db = 0x934d10, mc_dbx = 0x934d40, mc_dbflag =
0x6613328 "x\372\317",
mc_snum = 3, mc_top = 2, mc_flags = 5, mc_pg = {0x6619030, 0x661a040,
0x661b050, 0x7febda5e4000, 0x300000000, 0x6613300, 0x6613300, 0x7fd7d9ab7d70,
0x7ffff1407bc7, 0x817c60,
0x934b88, 0x6618020, 0x0, 0x0, 0x6613300, 0x1, 0x6613398, 0x91bcb0,
0x6614f69, 0x1, 0x6614ff0, 0x7fd7d9ab7d70, 0x0, 0x0, 0x6613300, 0x1, 0x6613398,
0x91bcb0, 0x6614f69, 0x1,
0x6614ff0, 0x1}, mc_ki = {1, 13, 0, 0, 32208, 55723, 32727, 0,
53262, 1633, 0, 0, 53344, 1633, 0, 0, 52360, 1633, 0, 0, 984, 0, 0, 0, 18409,
63036, 32767, 0, 32056, 55723,
32727, 0}}
__PRETTY_FUNCTION__ = "mdb_rebalance"
#7 0x00007ffff140caf0 in mdb_cursor_del0 (mc=0x934b88, leaf=0x661d00e) at
./../../../libraries/libmdb/mdb.c:5569
rc = 0
#8 0x00007ffff1409637 in mdb_cursor_del (mc=0x934b88, flags=0) at
./../../../libraries/libmdb/mdb.c:4524
leaf = 0x661d00e
rc = 0
#9 0x00007ffff14094f8 in mdb_cursor_del (mc=0x934a00, flags=0) at
./../../../libraries/libmdb/mdb.c:4497
leaf = 0x6618f7c
rc = 0
#10 0x00007ffff13f9c30 in mdb_dn2id_delete (op=0x7fd7d9ab8460, mc=0x934a00,
id=301) at dn2id.c:220
rc = 0
#11 0x00007ffff13e938c in mdb_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0) at
delete.c:336
mdb = 0x7ffff7e2c010
pdn = {bv_len = 12, bv_val = 0x937500 "cn=accesslog"}
e = 0xeffce0
p = 0xeffb40
manageDSAit = 0
children = 0x7cfc20
entry = 0x7cf980
txn = 0x6613300
mc = 0x934a00
opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key =
0x7ffff7e2c010}, moi_txn = 0x6613300, moi_ref = 1, moi_flag = 0 '\000'}
moi = 0x7fd7d9ab7ef0
preread_ctrl = 0x0
ctrls = {0x0, 0xfffffffffffffff9, 0x7fd7d9ab7f30, 0x800000,
0x7fd7d9ab99c0, 0x4}
num_ctrls = 0
parent_is_glue = 0
parent_is_leaf = 0
__PRETTY_FUNCTION__ = "mdb_delete"
#12 0x00000000004d4a48 in overlay_op_walk (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0,
which=op_delete, oi=0x9a3d80, on=0x0) at backover.c:671
func = 0x7ffff1617d18
rc = 32768
#13 0x00000000004d4c86 in over_op_func (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0,
which=op_delete) at backover.c:723
oi = 0x9a3d80
on = 0x8bca80
be = 0x8b75f0
db = {bd_info = 0x7ffff1617cc0, bd_self = 0x8b75f0, be_ctrls =
"\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001",
'\000' <repeats 14 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 = 0x8bdcd0, be_nsuffix = 0x8b8390, be_schemadn = {bv_len = 0, bv_val =
0x0}, be_schemandn = {
bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val =
0x8aab00 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8c4af0 "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 =
0x8a34a0, 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 = 0x91bc60, 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 =
0x7ffff1617ac0, be_private = 0x7ffff7e2c010,
be_next = {stqe_next = 0x8a7a80}}
cb = {sc_next = 0x7ffff0fa1c60, sc_response = 0x4d3780
<over_back_response>, sc_cleanup = 0, sc_private = 0x9a3d80}
sc = 0x823978
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#14 0x00000000004d4e6f in over_op_delete (op=0x7fd7d9ab8460, rs=0x7fd7d9ab82d0)
at backover.c:780
No locals.
#15 0x00007ffff0d97f61 in accesslog_purge (ctx=0x7fd7d9ab8b70, arg=0x8c4220) at
accesslog.c:689
i = 0
rtask = 0x8c4220
li = 0x8c4110
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 = 0x4f9d90 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9d90
""}, c_listener = 0x501ca0,
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 = 0x454a15 <slap_send_ldap_result>,
c_send_search_entry = 0x45571d <slap_send_search_entry>,
c_send_search_reference = 0x457c43 <slap_send_search_reference>,
c_send_ldap_extended = 0x45527c <slap_send_ldap_extended>,
c_send_ldap_intermediate = 0x4554fa <slap_send_ldap_intermediate>}
opbuf = {ob_op = {o_hdr = 0x7fd7d9ab85d0, o_tag = 74, o_time =
1333150209, o_tincr = 3, o_bd = 0x7fd7d9ab80e0, o_req_dn = {bv_len = 44,
bv_val = 0x926990 "reqStart=20120330215514.000205Z,cn=accesslog"},
o_req_ndn = {bv_len = 44, bv_val = 0x9374e0
"reqStart=20120330215514.000205Z,cn=accesslog"}, o_request = {
oq_add = {rs_modlist = 0x1, rs_e = 0xffffffffffffffff}, oq_bind =
{rb_method = 1, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn
= {bv_len = 1,
bv_val = 0x75cd60 "\003"}, rb_ssf = 3651896336, rb_mech =
{bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}}, oq_compare =
{rs_ava = 0x1}, oq_modify = {
rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1 '\377'},
rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x1, rs_no_opattrs = -1
'\377'}, rs_deleteoldrdn = 0,
rs_newrdn = {bv_len = 1, bv_val = 0x75cd60 "\003"}, rs_nnewrdn =
{bv_len = 140565046592528, bv_val = 0x1b <Address 0x1b out of bounds>},
rs_newSup = 0xeffa98,
rs_nnewSup = 0x0}, oq_search = {rs_scope = 1, rs_deref = 0,
rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 1, rs_attrs =
0x75cd60,
rs_filter = 0x7fd7d9ab8410, rs_filterstr = {bv_len = 27, bv_val
= 0xeffa98 "\220\200\253\331\327\177"}}, oq_abandon = {rs_msgid = 1}, oq_cancel
= {rs_msgid = 1},
oq_extended = {rs_reqoid = {bv_len = 1, bv_val =
0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0,
rs_reqdata = 0x1}, oq_pwdexop = {
rs_extended = {rs_reqoid = {bv_len = 1, bv_val =
0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, rs_flags = 0,
rs_reqdata = 0x1}, rs_old = {
bv_len = 7720288, bv_val = 0x7fd7d9ab8410 "\246"}, rs_new =
{bv_len = 27, bv_val = 0xeffa98 "\220\200\253\331\327\177"}, 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 = 1 '\001', o_acl_priv =
ACL_NONE, o_nocaching = 0 '\000',
o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000',
o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 times>,
o_controls = 0x7fd7d9ab8718,
o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0},
sai_dn = {bv_len = 9, bv_val = 0x8aab00 "cn=config"}, sai_ndn = {bv_len = 9,
bv_val = 0x8c4af0 "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 = 0xeffa98, o_ctrls = 0x0, o_csn
= {bv_len = 40,
bv_val = 0x7fd7d9ab8ae0
"20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}, o_private =
0x0, o_extra = {slh_first = 0x7fd7d9ab7ef0}, o_next = {
stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid =
18446744073709551615, oh_conn = 0x7fd7d9ab8820, oh_msgid = 0, oh_protocol = 0,
oh_tid = 140565046597376,
oh_threadctx = 0x7fd7d9ab8b70, oh_tmpmemctx = 0x932e70, oh_tmpmfuncs
= 0x75d320, oh_counters = 0x7607a0, oh_log_prefix = "conn=-1 op=0", '\000'
<repeats 243 times>},
ob_controls = {0x0 <repeats 32 times>}}
op = 0x7fd7d9ab8460
rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = -30798,
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}
cb = {sc_next = 0x0, sc_response = 0x7ffff0d9787e <log_old_lookup>,
sc_cleanup = 0, sc_private = 0x7fd7d9ab8380}
f = {f_choice = 166, f_un = {f_un_result = -643070992, f_un_desc =
0x7fd7d9ab83f0, f_un_ava = 0x7fd7d9ab83f0, f_un_ssa = 0x7fd7d9ab83f0, f_un_mra =
0x7fd7d9ab83f0,
f_un_complex = 0x7fd7d9ab83f0}, f_next = 0x0}
ava = {aa_desc = 0x825a60, aa_value = {bv_len = 15, bv_val =
0x7fd7d9ab8b20 "20120330232509Z"}}
pd = {slots = 699800, used = 699702, dn = 0x7fd7d43d0010, ndn =
0x7fd7d32eb010, csn = {bv_len = 40,
bv_val = 0x7fd7d9ab8ae0
"20120330232137.106577Z#000000#000#000000p\213\253\331\327\177"}}
timebuf = "20120330232509Z\000\300\231\253\331\327\177"
csnbuf = "20120330232137.106577Z#000000#000#000000p\213\253\331\327\177",
'\000' <repeats 11 times>"\227, \253\331\327\177\000"
old = 1333149909
__PRETTY_FUNCTION__ = "accesslog_purge"
#16 0x00007ffff7b8ccc9 in ldap_int_thread_pool_wrapper (xpool=0x7d4520) at
tpool.c:688
pool = 0x7d4520
task = 0x9267e0
work_list = 0x7d45b8
ctx = {ltu_id = 140565046597376, ltu_key = {{ltk_key = 0x4b380b,
ltk_data = 0x932e70, ltk_free = 0x4b3630 <slap_sl_mem_destroy>}, {ltk_key =
0x7fffda4bc010, ltk_data = 0x933110,
ltk_free = 0x7ffff13fc523 <mdb_reader_free>}, {ltk_key =
0x7ffff13f23c4, ltk_data = 0x7fd7d54b4010, ltk_free = 0x7ffff13f23a1
<search_stack_free>}, {
ltk_key = 0x7ffff13efda9, ltk_data = 0x7fd7d74b5010, ltk_free =
0x7ffff13efd61 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free =
0} <repeats 25 times>, {
ltk_key = 0x0, ltk_data = 0x7ffff66c9ca9, 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 = 433
hash = 310601137
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#17 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#18 0x00007ffff642570d in clone () from /lib/libc.so.6
No symbol table info available.
#19 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (Thread 0x7fd7da2ba700 (LWP 32047)):
#0 0x00007ffff6425d03 in epoll_wait () from /lib/libc.so.6
No symbol table info available.
#1 0x0000000000439597 in slapd_daemon_task (ptr=0x7fffffffe3bc) at
daemon.c:2539
ns = 1
at = 0
nfds = 2
revents = 0x7ffff4b31010
tvp = 0x7fd7da2b7dc0
cat = {tv_sec = 1333150509, tv_usec = 0}
i = 1
nwriters = 0
now = 1333150209
tv = {tv_sec = 300, tv_usec = 0}
tdelta = 1
rtask = 0x8ab9c0
l = 1
last_idle_check = 1333150209
ebadf = 0
tid = 0
#2 0x00007ffff66c89ca in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#3 0x00007ffff642570d in clone () from /lib/libc.so.6
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7ffff7fef700 (LWP 32046)):
#0 0x00007ffff66ca03d in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#1 0x00007ffff7b8e1ff in ldap_pvt_thread_join (thread=140565054990080,
thread_return=0x0) at thr_posix.c:197
No locals.
#2 0x000000000043a7a9 in slapd_daemon () at daemon.c:2930
i = 0
rc = 0
listener_tid = 0x926840
#3 0x0000000000416d4f in main (argc=11, argv=0x7fffffffe5c8) at main.c:1012
i = 11
no_detach = 1
rc = 0
urls = 0x7b10b0 "ldapi:///"
username = 0x7b1090 "root"
groupname = 0x0
sandbox = 0x0
syslogUser = 128
pid = 0
waitfds = {3817984, 0}
g_argc = 11
g_argv = 0x7fffffffe5c8
configfile = 0x0
configdir = 0x7b10d0 "/opt/zimbra/data/ldap/config"
serverName = 0x7fffffffe871 "slapd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x4f9828 ""
l = 140737488348318
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
11 years, 8 months
Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by quanah＠zimbra.com
--On Thursday, March 29, 2012 1:59 PM +0000 Laurent.LeGrandois(a)atos.net
wrote:
> This is a multi-part message in MIME format.
> --------------060203070300020608020002
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
>
> Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit :
>> Laurent.LeGrandois(a)atos.net wrote:
>>> This is a multi-part message in MIME format.
>>> --------------070001090703090002060300
>>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>>> Content-Transfer-Encoding: quoted-printable
>>>
>>> Hi,
>>>
>>> any news concerning integration of this patch ?
>> An alternate patch is now in git master, please test.
> Ok, we will test it : any modifications to do for 2.4.28 version ?
Please respond once you've tested. Since there were changes to back-perl
for 2.4.29, it may not apply cleanly to a 2.4.28 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
11 years, 8 months
Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com
Ondrej Kuznik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/27/2012 01:30 PM, hyc(a)symas.com wrote:
>> ondrej.kuznik(a)acision.com wrote:
>>> Full_Name: Ondrej Kuznik
>>> Version: HEAD
>>> OS: Linux
>>>
>> I have pushed patches 1-3 to git master. patch 4 seems to require additional work.
>
> I have reworked the remaining patches according to your suggestions, the
> resulting patchset is at:
> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitori...
Committed to master, thanks for the patches.
>
> The attached file is derived from OpenLDAP Software. All of the
> modifications to OpenLDAP Software represented in the following
> patch(es) were developed by Acision. Acision has not assigned rights
> and/or interest in this work to any party. I, Ondrej Kuznik am
> authorized by Acision, my employer, to release this work under the
> following terms.
>
> The attached modifications to OpenLDAP Software are subject to the
> following notice:
> Copyright 2012 Acision
> Redistribution and use in source and binary forms, with or without
> modification, are permitted only as authorized by the OpenLDAP Public
> License.
>
> - --
> Ondrej Kuznik
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5
> YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP
> =8OdU
> -----END PGP SIGNATURE-----
>
> This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 8 months
Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net
This is a multi-part message in MIME format.
--------------060203070300020608020002
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 29/03/2012 15:14, hyc(a)symas.com a =E9crit :
> Laurent.LeGrandois(a)atos.net wrote:
>> This is a multi-part message in MIME format.
>> --------------070001090703090002060300
>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>> Content-Transfer-Encoding: quoted-printable
>>
>> Hi,
>>
>> any news concerning integration of this patch ?
> An alternate patch is now in git master, please test.
Ok, we will test it : any modifications to do for 2.4.28 version ?
Thanks
>> Thanks
>>
>> Laurent Le Grandois
>>
>>
>> Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =3DE9crit :
>>> Now the new patch encode the binary data to base64 by using slap_ad_i=
s_=3D
>> binary to check if it's binary data, and using lutil_b64_ntop for the =
enc=3D
>> ode.
>
--=20
Cordialement,
*Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>=
*
Architecte Open Source
Campus AtoS - River Ouest
Pacific 3 Sud 8
+33 (0) 1 73 26 16 32
+33 (0) 6 70 01 25 61
80, Quai Voltaire 95877 Bezons Cedex
Signature IOC <http://www.atos.net>
--------------060203070300020608020002
Content-Type: multipart/related;
boundary="------------050102040904060500010807"
--------------050102040904060500010807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Le 29/03/2012 15:14, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit :
<blockquote
cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org"
type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:Laurent.LeGrandois@atos.net">Laurent.LeGrandois(a)atos.net</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This is a multi-part message in MIME format.
--------------070001090703090002060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
any news concerning integration of this patch ?
</pre>
</blockquote>
<pre wrap="">
An alternate patch is now in git master, please test.</pre>
</blockquote>
Ok, we will test it : any modifications to do for 2.4.28 version ? <br>
Thanks<br>
<blockquote
cite="mid:201203291314.q2TDEUiO066709@boole.openldap.org"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
Thanks
Laurent Le Grandois
Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a =E9crit :
</pre>
<blockquote type="cite">
<pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_=
</pre>
</blockquote>
<pre wrap="">binary to check if it's binary data, and using lutil_b64_ntop for the enc=
ode.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-signature"><br>
<font face="CMU Sans Serif"> Cordialement,<br>
<img src="cid:part1.08050501.09040401@atos.net" border="0"><br>
<br>
<b><a
href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent
Le Grandois</a></b><br>
<font style="font-size: 8pt;"> <br>
Architecte Open Source<br>
<br>
Campus AtoS - River Ouest<br>
Pacific 3 Sud 8<br>
+33 (0) 1 73 26 16 32<br>
+33 (0) 6 70 01 25 61<br>
80, Quai Voltaire 95877 Bezons Cedex<br>
</font> </font> <a href="http://www.atos.net"> <img
src="cid:part3.07070802.03040503@atos.net" alt="Signature
IOC" border="0"></a> </div>
</div>
</body>
</html>
--------------050102040904060500010807
Content-Type: image/gif;
name="blue_strip.gif"
Content-Transfer-Encoding: base64
Content-ID: <part1.08050501.09040401(a)atos.net>
Content-Disposition: inline;
filename="blue_strip.gif"
R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA
AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7
--------------050102040904060500010807
Content-Type: image/gif;
name="atos_logo_small.gif"
Content-Transfer-Encoding: base64
Content-ID: <part3.07070802.03040503(a)atos.net>
Content-Disposition: inline;
filename="atos_logo_small.gif"
R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P
4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik
cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7
fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6
rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK
N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA
SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo
CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11
xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2
NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD
3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq
4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC
AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl
ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw
qBchAAA7
--------------050102040904060500010807--
--------------060203070300020608020002--
11 years, 8 months
Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by hyc＠symas.com
Laurent.LeGrandois(a)atos.net wrote:
> This is a multi-part message in MIME format.
> --------------070001090703090002060300
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> any news concerning integration of this patch ?
An alternate patch is now in git master, please test.
>
> Thanks
>
> Laurent Le Grandois
>
>
> Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit :
>> Now the new patch encode the binary data to base64 by using slap_ad_is_=
> binary to check if it's binary data, and using lutil_b64_ntop for the enc=
> ode.
>>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 8 months
Re: (ITS#7182) back-ldap monitoring improvements
by ondrej.kuznik＠acision.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/27/2012 01:30 PM, hyc(a)symas.com wrote:
> ondrej.kuznik(a)acision.com wrote:
>> Full_Name: Ondrej Kuznik
>> Version: HEAD
>> OS: Linux
>>
> I have pushed patches 1-3 to git master. patch 4 seems to require additional work.
I have reworked the remaining patches according to your suggestions, the
resulting patchset is at:
ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120329-back-ldap-monitori...
The attached file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following
patch(es) were developed by Acision. Acision has not assigned rights
and/or interest in this work to any party. I, Ondrej Kuznik am
authorized by Acision, my employer, to release this work under the
following terms.
The attached modifications to OpenLDAP Software are subject to the
following notice:
Copyright 2012 Acision
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public
License.
- --
Ondrej Kuznik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk90XwAACgkQ9GWxeeH+cXuruQCfenFjCDLAbx+kk/jzpoogGGu5
YLoAn1SwLfVvCZtl1SHEQsuSyi+bAThP
=8OdU
-----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
11 years, 8 months
Re: RE : (ITS#7149) Back-perl, Back-shell and Binary Data
by Laurent.LeGrandois＠atos.net
This is a multi-part message in MIME format.
--------------070001090703090002060300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi,
any news concerning integration of this patch ?
Thanks
Laurent Le Grandois
Le 06/02/2012 18:23, jiashun.qian(a)atos.net a =E9crit :
> Now the new patch encode the binary data to base64 by using slap_ad_is_=
binary to check if it's binary data, and using lutil_b64_ntop for the enc=
ode.
>
>
> *** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11=
-25 19:52:29.000000000 +0100
> --- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +=
0100
> ***************
> *** 16,21 ****
> --- 16,22 ----
> */
>
> #include "perl_back.h"
> + #include "lutil.h"
>
> int
> perl_back_modify(
> ***************
> *** 26,31 ****
> --- 27,33 ----
> Modifications *modlist =3D op->orm_modlist;
> int count;
> int i;
> + struct berval b64_data;
>
> PERL_SET_CONTEXT( PERL_INTERPRETER );
> ldap_pvt_thread_mutex_lock(&perl_interpreter_mutex );
> ***************
> *** 61,67 ****
> mods->sm_values !=3D NULL&& mods->sm_=
values[i].bv_val !=3D NULL;
> i++ )
> {
> ! XPUSHs(sv_2mortal(newSVpv( mods->sm_val=
ues[i].bv_val, 0 )));
> }
>
> /* Fix delete attrib without value. */
> --- 63,80 ----
> mods->sm_values !=3D NULL&& mods->sm_=
values[i].bv_val !=3D NULL;
> i++ )
> {
> ! if ( slap_ad_is_binary(mods->sm_desc) )=
{
> ! b64_data.bv_len =3D LUTIL_BASE6=
4_ENCODE_LEN(mods->sm_values[i].bv_len) + 1;
> ! b64_data.bv_val =3D ber_memallo=
c( b64_data.bv_len + 1 );
> ! b64_data.bv_len =3D lutil_b64_n=
top(
> ! (unsigned char =
*) mods->sm_values[i].bv_val,
> ! mods->sm_values=
[i].bv_len,
> ! b64_data.bv_val=
, b64_data.bv_len );
> ! XPUSHs(sv_2mortal(newSVpv( b64_=
data.bv_val, 0 )));
> ! ber_memfree( b64_data.bv_val );
> ! } else {
> ! XPUSHs(sv_2mortal(newSVpv( mods=
->sm_values[i].bv_val, 0 )));
> ! }
> }
>
> /* Fix delete attrib without value. */
>
>
> *** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11=
-25 19:52:29.000000000 +0100
> --- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +=
0100
> ***************
> *** 37,42 ****
> --- 37,43 ----
>
> #include "slap.h"
> #include "shell.h"
> + #include "lutil.h"
>
> int
> shell_back_modify(
> ***************
> *** 50,55 ****
> --- 51,57 ----
> Entry e;
> FILE *rfp, *wfp;
> int i;
> + struct berval b64_data;
>
> if ( si->si_modify =3D=3D NULL ) {
> send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM,
> ***************
> *** 105,112 ****
>
> if( mod->sm_values !=3D NULL ) {
> for ( i =3D 0; mod->sm_values[i].bv_val !=3D N=
ULL; i++ ) {
> ! fprintf( wfp, "%s: %s\n", mod->sm_desc-=
>ad_cname.bv_val,
> ! mod->sm_values[i].bv_val /* bin=
ary! */ );
> }
> }
>
> --- 107,126 ----
>
> if( mod->sm_values !=3D NULL ) {
> for ( i =3D 0; mod->sm_values[i].bv_val !=3D N=
ULL; i++ ) {
> ! if ( slap_ad_is_binary(mod->sm_desc) ) =
{
> ! b64_data.bv_len =3D LUTIL_BASE6=
4_ENCODE_LEN(mod->sm_values[i].bv_len) + 1;
> ! b64_data.bv_val =3D ber_memallo=
c( b64_data.bv_len + 1 );
> ! b64_data.bv_len =3D lutil_b64_n=
top(
> ! (unsigned char =
*) mod->sm_values[i].bv_val,
> ! mod->sm_values[=
i].bv_len,
> ! b64_data.bv_val=
, b64_data.bv_len );
> ! fprintf( wfp, "%s: %s\n", mod->=
sm_desc->ad_cname.bv_val,
> ! b64_data.bv_val );
> ! ber_memfree( b64_data.bv_val );
> ! } else {
> ! fprintf( wfp, "%s: %s\n", mod->=
sm_desc->ad_cname.bv_val,
> ! mod->sm_values[i].bv_va=
l );
> ! }
> }
> }
>
>
> ________________________________________
> De : openldap-bugs-bounces(a)OpenLDAP.org [openldap-bugs-bounces@OpenLDAP=
.org] de la part de hyc(a)symas.com [hyc(a)symas.com]
> Date d'envoi : jeudi 2 f=E9vrier 2012 21:44
> =C0 : openldap-its(a)openldap.org
> Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data
>
> llg(a)portaildulibre.fr wrote:
>> Le 02/02/2012 20:32, hyc(a)symas.com a =E9crit :
>>> jiashun.qian(a)atos.net wrote:
>>>> Full_Name: Jiashun QIAN
>>>> Version: 2.4.28
>>>> OS: CentOS 6
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (85.115.60.180)
>>>>
>>>>
>>>> The backend shell and the backend perl can't handle some binary data=
.
>>>>
>>>> This occurs only with MODIFY because when ADD the binary data is enc=
oded in
>>>> base64 but not MODIFY.
>>>>
>>>> The binary data is truncated when if it contains \0. In fact, data i=
s stored in
>>>> a linked list of char * and treated as characters.
>>>>
>>>> ---
>>>> servers/slapd/back-perl/modify.c
>>>> XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 )));
>>>> ---
>>>>
>>>> The type of mods->sm_values[i].bv_val is char*.
>>>>
>>>> To handle the binary data, for back-perl, just change another functi=
on mXPUSHp,
>>>> which we can put the exacte length of mod->sm_values[i].bv_val as pa=
rameter,
>>>> it's mod->sm_values[i].bv_len. So it will push the total data.
>>> That is obviously the wrong approach. Since these backends communicat=
e using
>>> LDIF, binary values should be base64 encoded according to the LDIF ru=
les.
>> The input LDIF file for ldap_modify contains base64 encoded
>> usercertificate, but back-perl receives binary data.
>> This behaviour only occured with modification action : with add action=
,
>> certificate is received base64 encoded.
> Yes, I already understood that. You're still not understanding what I s=
aid.
> Your patch should do the appropriate checks for binary data and do the =
proper
> base64 encoding for the modify values that back-perl (or back-shell) se=
nds to
> the perl module (or shell script).
>
> This has nothing to do with the input LDIF file, this is about how slap=
d
> transmits internal data from a backend to the external perl or shell sc=
ripts.
>
>>> Thanks for the patch, but we can't merge it since the provided soluti=
on is wrong.
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
>
>
> ________________________________
>
>
> Ce message et les pi=E8ces jointes sont confidentiels et r=E9serv=E9s =E0=
l'usage exclusif de ses destinataires. Il peut =E9galement =EAtre prot=E9=
g=E9 par le secret professionnel. Si vous recevez ce message par erreur, =
merci d'en avertir imm=E9diatement l'exp=E9diteur et de le d=E9truire. L'=
int=E9grit=E9 du message ne pouvant =EAtre assur=E9e sur Internet, la res=
ponsabilit=E9 du groupe Atos ne pourra =EAtre engag=E9e quant au contenu =
de ce message. Bien que les meilleurs efforts soient faits pour maintenir=
cette transmission exempte de tout virus, l'exp=E9diteur ne donne aucune=
garantie =E0 cet =E9gard et sa responsabilit=E9 ne saurait =EAtre engag=E9=
e pour tout dommage r=E9sultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended so=
lely for the addressee; it may also be privileged. If you receive this e-=
mail in error, please notify the sender immediately and destroy it. As it=
s integrity cannot be secured on the Internet, the Atos group liability c=
annot be triggered for the message content. Although the sender endeavors=
to maintain a computer virus-free network, the sender does not warrant t=
hat this transmission is virus-free and will not be liable for any damage=
s resulting from any virus transmitted.
>
>
--=20
Cordialement,
*Laurent Le Grandois <http://people.portaildulibre.fr/%7Ellg/qr-code.png>=
*
Architecte Open Source
Campus AtoS - River Ouest
Pacific 3 Sud 8
+33 (0) 1 73 26 16 32
+33 (0) 6 70 01 25 61
80, Quai Voltaire 95877 Bezons Cedex
Signature IOC <http://www.atos.net>
--------------070001090703090002060300
Content-Type: multipart/related;
boundary="------------050007050004070007020800"
--------------050007050004070007020800
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
any news concerning integration of this patch ? <br>
<br>
Thanks<br>
<br>
Laurent Le Grandois<br>
<br>
<br>
Le 06/02/2012 18:23, <a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> a écrit :
<blockquote
cite="mid:201202061723.q16HNLgD077070@boole.openldap.org"
type="cite">
<pre wrap="">Now the new patch encode the binary data to base64 by using slap_ad_is_binary to check if it's binary data, and using lutil_b64_ntop for the encode.
*** ../openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100
--- servers/slapd/back-perl/modify.c 2012-02-06 17:41:44.638861010 +0100
***************
*** 16,21 ****
--- 16,22 ----
*/
#include "perl_back.h"
+ #include "lutil.h"
int
perl_back_modify(
***************
*** 26,31 ****
--- 27,33 ----
Modifications *modlist = op->orm_modlist;
int count;
int i;
+ struct berval b64_data;
PERL_SET_CONTEXT( PERL_INTERPRETER );
ldap_pvt_thread_mutex_lock( &perl_interpreter_mutex );
***************
*** 61,67 ****
mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL;
i++ )
{
! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 )));
}
/* Fix delete attrib without value. */
--- 63,80 ----
mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL;
i++ )
{
! if ( slap_ad_is_binary(mods->sm_desc) ) {
! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mods->sm_values[i].bv_len) + 1;
! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 );
! b64_data.bv_len = lutil_b64_ntop(
! (unsigned char *) mods->sm_values[i].bv_val,
! mods->sm_values[i].bv_len,
! b64_data.bv_val, b64_data.bv_len );
! XPUSHs(sv_2mortal(newSVpv( b64_data.bv_val, 0 )));
! ber_memfree( b64_data.bv_val );
! } else {
! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 )));
! }
}
/* Fix delete attrib without value. */
*** ../openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100
--- servers/slapd/back-shell/modify.c 2012-02-06 17:40:14.861837487 +0100
***************
*** 37,42 ****
--- 37,43 ----
#include "slap.h"
#include "shell.h"
+ #include "lutil.h"
int
shell_back_modify(
***************
*** 50,55 ****
--- 51,57 ----
Entry e;
FILE *rfp, *wfp;
int i;
+ struct berval b64_data;
if ( si->si_modify == NULL ) {
send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM,
***************
*** 105,112 ****
if( mod->sm_values != NULL ) {
for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) {
! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val,
! mod->sm_values[i].bv_val /* binary! */ );
}
}
--- 107,126 ----
if( mod->sm_values != NULL ) {
for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) {
! if ( slap_ad_is_binary(mod->sm_desc) ) {
! b64_data.bv_len = LUTIL_BASE64_ENCODE_LEN(mod->sm_values[i].bv_len) + 1;
! b64_data.bv_val = ber_memalloc( b64_data.bv_len + 1 );
! b64_data.bv_len = lutil_b64_ntop(
! (unsigned char *) mod->sm_values[i].bv_val,
! mod->sm_values[i].bv_len,
! b64_data.bv_val, b64_data.bv_len );
! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val,
! b64_data.bv_val );
! ber_memfree( b64_data.bv_val );
! } else {
! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val,
! mod->sm_values[i].bv_val );
! }
}
}
________________________________________
De : <a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a> [<a class="moz-txt-link-abbreviated" href="mailto:openldap-bugs-bounces@OpenLDAP.org">openldap-bugs-bounces(a)OpenLDAP.org</a>] de la part de <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> [<a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a>]
Date d'envoi : jeudi 2 février 2012 21:44
À : <a class="moz-txt-link-abbreviated" href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>
Objet : Re: (ITS#7149) Back-perl, Back-shell and Binary Data
<a class="moz-txt-link-abbreviated" href="mailto:llg@portaildulibre.fr">llg(a)portaildulibre.fr</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Le 02/02/2012 20:32, <a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> a écrit :
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:jiashun.qian@atos.net">jiashun.qian(a)atos.net</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Full_Name: Jiashun QIAN
Version: 2.4.28
OS: CentOS 6
URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a>
Submission from: (NULL) (85.115.60.180)
The backend shell and the backend perl can't handle some binary data.
This occurs only with MODIFY because when ADD the binary data is encoded in
base64 but not MODIFY.
The binary data is truncated when if it contains \0. In fact, data is stored in
a linked list of char * and treated as characters.
---
servers/slapd/back-perl/modify.c
XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 )));
---
The type of mods->sm_values[i].bv_val is char*.
To handle the binary data, for back-perl, just change another function mXPUSHp,
which we can put the exacte length of mod->sm_values[i].bv_val as parameter,
it's mod->sm_values[i].bv_len. So it will push the total data.
</pre>
</blockquote>
<pre wrap="">That is obviously the wrong approach. Since these backends communicate using
LDIF, binary values should be base64 encoded according to the LDIF rules.
</pre>
</blockquote>
<pre wrap="">The input LDIF file for ldap_modify contains base64 encoded
usercertificate, but back-perl receives binary data.
This behaviour only occured with modification action : with add action,
certificate is received base64 encoded.
</pre>
</blockquote>
<pre wrap="">
Yes, I already understood that. You're still not understanding what I said.
Your patch should do the appropriate checks for binary data and do the proper
base64 encoding for the modify values that back-perl (or back-shell) sends to
the perl module (or shell script).
This has nothing to do with the input LDIF file, this is about how slapd
transmits internal data from a backend to the external perl or shell scripts.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Thanks for the patch, but we can't merge it since the provided solution is wrong.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
--
-- Howard Chu
CTO, Symas Corp. <a class="moz-txt-link-freetext" href="http://www.symas.com">http://www.symas.com</a>
Director, Highland Sun <a class="moz-txt-link-freetext" href="http://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a>
Chief Architect, OpenLDAP <a class="moz-txt-link-freetext" href="http://www.openldap.org/project/">http://www.openldap.org/project/</a>
________________________________
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div class="moz-signature"><br>
<font face="CMU Sans Serif"> Cordialement,<br>
<img src="cid:part1.08020906.06070706@atos.net" border="0"><br>
<br>
<b><a
href="http://people.portaildulibre.fr/%7Ellg/qr-code.png">Laurent
Le Grandois</a></b><br>
<font style="font-size: 8pt;"> <br>
Architecte Open Source<br>
<br>
Campus AtoS - River Ouest<br>
Pacific 3 Sud 8<br>
+33 (0) 1 73 26 16 32<br>
+33 (0) 6 70 01 25 61<br>
80, Quai Voltaire 95877 Bezons Cedex<br>
</font> </font> <a href="http://www.atos.net"> <img
src="cid:part3.07050008.03070309@atos.net" alt="Signature
IOC" border="0"></a> </div>
</div>
</body>
</html>
--------------050007050004070007020800
Content-Type: image/gif;
name="blue_strip.gif"
Content-Transfer-Encoding: base64
Content-ID: <part1.08020906.06070706(a)atos.net>
Content-Disposition: inline;
filename="blue_strip.gif"
R0lGODlhgAADAKIAAABnoX+z0ECNuZ/G3P///wAAAAAAAAAAACH5BAEAAAQALAAAAACAAAMA
AAMTCLrc/jDKSau9OOvNu/9gKI5OAgA7
--------------050007050004070007020800
Content-Type: image/gif;
name="atos_logo_small.gif"
Content-Transfer-Encoding: base64
Content-ID: <part3.07050008.03070309(a)atos.net>
Content-Disposition: inline;
filename="atos_logo_small.gif"
R0lGODlhgAAlAMQAAABnoX9/f7/Z53+z0ECNuRBxp9/s8+/1+Z/G3M/i7SB6rTCEs2CgxK/P
4nCqyo+81lCXvt/f37+/v////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ACH5BAEAABMALAAAAACAACUAAAX/YCCOZGmeaKqubOu+6CTPdG3feK7vfO//wKBwSCwaj8ik
cslsOp/QqHRKrVqv2Kx2y+16fQaBOPHlAc7oNACRE6gF0MODoD4XCA52uVZXE9pvTwMFfXV7
fIVoBjhuaXBMB3SJaoc0AwOSfQ+MgT0HlwMNizgMk2oFlTULiQs0CQSwq2kLsLU1nwwTpbN6
rnUKeWIImX+pMganaqMTjaZnNA2EooUEyxMOark1A2jFxthoELtoDjPNzjPgqOB9BWQymQAK
N9xn3qkKaQgNavMy56Zk1APwJ18id/DS+NvWzdiEBGkKHJhgEM07A6DGnWEA6hKzNAMmqIFA
SOHEeAC0/90w8C4Vu5QyXsKsAfARjYprAE4wIAtNSI1nFPRyaKPkmQYyIEa0UbMGgjc6Jxzo
CUAiQDTAWhKdwA8Nqhk4ASCl0ZQGhFkf08xQioYNyn4DrKXSWG7GwI00O81Qo0dNy7Nock11
xmBiqgNGAWhFFtHwP70P1RimqvJpQ4GJ2409ZDmoDapryEI+t/Cu4sdeaXwKW0frF8DOwol2
NPtMq2OnyESt0YABa3uHDsSu47gsajSWTj14kOaejQZvAcjl0nn4mU3Hz9iUoWbz4EkQeESD
3AX08Ntp0WyfQPXe90JDc8hcv4UxmgZi8uvPPArgZhnVAYCdDO8R14Np9GnB3K1lpKiBHUAq
4cbXNpnBZEBWOCTAXxlUxcdbPxKmMSACvxHQwEQGPJCZRLp4BUEoYjwAGxro1SdAgPhleBUC
AhQYFAEVWgfHVc4keIVpat0QnXZdmWJeIno8OUldXSCJnJKJwCFTHWxY2c87BwA1SQEeauEl
ADgsCcAjDZTYkgFiBhVSDSlKaYcD09mon3467pmfY8x0hECeBzQwAAMEXOKaDQcI8EBHAzyw
qBchAAA7
--------------050007050004070007020800--
--------------070001090703090002060300--
11 years, 8 months
Re: (ITS#7218) Not deleted in Syncrepl
by hyc＠symas.com
s_hira(a)nifty.com wrote:
> Full_Name: HIRABAYASHI Satoshi
> Version: v2.4.30
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (221.250.200.130)
>
>
> I confirmed the problem that was not deleted in syncrepl of V2.4.30.
Thanks for the report, fixed now in git master.
>
> The provider operates it in "syncprov-sessionlog 100".
> After I delete 150 in a provider, and going syncrepl
> Only 100 cases are deleted in the consumer side.
>
> After examining it, the following parts seem to have a problem.
>
> servers/slapd/overlays/syncprov.c:2638
> if ( sl->sl_num> 0 ) {
> int i;
> for ( i=0; i<sl->sl_numcsns; i++ ) {
> /* SID not present == new enough */
> if ( minsid< sl->sl_sids[i] ) {
> do_play = 1;
> break;
> }
> /* SID present and new enough */
> if ( minsid == sl->sl_sids[i]
> && ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) {
> do_play = 1;
> break;
> }
> }
> /* SID not present == new enough */
> if ( i == sl->sl_numcsns )
> do_play = 1;
> }
> if ( do_play ) {
> do_present = 0;
> /* mutex is unlocked in playlog */
> syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );
> } else {
> ldap_pvt_thread_mutex_unlock(&sl->sl_mutex );
> }
>
> Then, it corrected as follows.
> ===
> - if ( minsid == sl->sl_sids[i]
> -&& ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) {
> + if ( minsid == sl->sl_sids[i] ) {
> + if ( ber_bvcmp(&mincsn,&sl->sl_mincsn[i] )>= 0 ) {
> do_play = 1;
> + }
> break;
> }
>
> Is this correction wrong?
>
>
> HIRABAYASHI Satoshi
> s_hira(a)nifty.com
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 8 months
(ITS#7218) Not deleted in Syncrepl
by s_hira＠nifty.com
Full_Name: HIRABAYASHI Satoshi
Version: v2.4.30
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (221.250.200.130)
I confirmed the problem that was not deleted in syncrepl of V2.4.30.
The provider operates it in "syncprov-sessionlog 100".
After I delete 150 in a provider, and going syncrepl
Only 100 cases are deleted in the consumer side.
After examining it, the following parts seem to have a problem.
servers/slapd/overlays/syncprov.c:2638
if ( sl->sl_num > 0 ) {
int i;
for ( i=0; i<sl->sl_numcsns; i++ ) {
/* SID not present == new enough */
if ( minsid < sl->sl_sids[i] ) {
do_play = 1;
break;
}
/* SID present and new enough */
if ( minsid == sl->sl_sids[i]
&& ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) {
do_play = 1;
break;
}
}
/* SID not present == new enough */
if ( i == sl->sl_numcsns )
do_play = 1;
}
if ( do_play ) {
do_present = 0;
/* mutex is unlocked in playlog */
syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );
} else {
ldap_pvt_thread_mutex_unlock( &sl->sl_mutex );
}
Then, it corrected as follows.
===
- if ( minsid == sl->sl_sids[i]
- && ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) {
+ if ( minsid == sl->sl_sids[i] ) {
+ if ( ber_bvcmp( &mincsn, &sl->sl_mincsn[i] ) >= 0 ) {
do_play = 1;
+ }
break;
}
Is this correction wrong?
HIRABAYASHI Satoshi
s_hira(a)nifty.com
11 years, 8 months
Re: (ITS#7182) back-ldap monitoring improvements
by hyc＠symas.com
ondrej.kuznik(a)acision.com wrote:
> Full_Name: Ondrej Kuznik
> Version: HEAD
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120228-back-ldap-monitori...
> Submission from: (NULL) (62.168.56.1)
>
>
> I have prepared some patches to back-ldap (and one to back-monitor) that expose
> operation and connection monitoring information from a running back-ldap
> database and I would like to see this or similar functionality included in the
> OpenLDAP codebase.
>
> The url above contains a patchset against HEAD for review.
>
> The following things are yet to be resolved:
> - there is no monitoring of completed operations yet, only operations initiated
> against the remote database(s).
> - the binds performed by the ldap_back_default_rebind function are not counted
> - slapo-chain has not been tested yet
> - test suite integration: back-ldap looks excluded from the test suite
> - better connection handling (connections should have stable identifiers)
I have pushed patches 1-3 to git master. patch 4 seems to require additional work.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
11 years, 8 months
