openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by hyc＠symas.com 31 Jan '15

31 Jan '15

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 from git > OS: openSUSE 13.2 x86-64 > URL: > Submission from: (NULL) (79.227.179.192) Thanks for the report. Fixed in master for ITS#8039, closing this ITS. -- -- 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#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by quanah＠zimbra.com 30 Jan '15

30 Jan '15

--On Friday, January 30, 2015 7:53 PM +0000 michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------000701070908040607050107 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > See gdb output attached. This would likely be due to ITS#8039 then. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

This is a multi-part message in MIME format. --------------000701070908040607050107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit See gdb output attached. --------------000701070908040607050107 Content-Type: text/plain; charset=UTF-8; name="gdb-bt-its8041.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gdb-bt-its8041.txt" #0 send_ldap_control (ber=0x7fc9e8d45130, c=0x30303d6469726580) at result.c:419 rc = 32713 __PRETTY_FUNCTION__ = "send_ldap_control" #1 0x0000000000452574 in slap_response_play (op=0x452574 <slap_response_play+83>, rs=0x7fc9e8d45100) at result.c:506 sc_next = 0x7fc9e8d45130 sc_nextp = 0x7fc9e8d45810 rc = 0 sc = 0x7fc9e0000908 scp = 0x7fc9e8d45130 #2 0x0000000000452d16 in send_ldap_response (op=0x7fc9e8d45810, rs=0x7fc9e8d45530) at result.c:693 berbuf = { buffer = "\002\000\001\000\005A\000\000\377\377\377\377\377\377\377\377!", '\000' <repeats 15 times>, "\250\t\000\340\311\177\000\000\250\t\000\340\311\177\000\000\204\031\000\340\311\177\000\000\316\t\000\340\311\177\000\000\000\000\000\000\000\000\000\000\300\b\000\340\311\177\000\000\003\267>\352\311\177\000\000\000S\324\350\311\177\000\000(\t\000\340\311\177\000\000 \000\000\000\060\000\000\000\260R\324\350\311\177\000\000\360Q\324\350\311\177\000\000(\t\000\340\311\177\000\000P\000\000\000\000\000\000\000\315\350O\000\000\000\000\000X\267>\352\311\177\000\000\377\377\377\377\377\377\377\377(\t\000\340\311\177\000\000\377\377\377\377\377\377\377\377\001\000\000\000\377\377\377\000\300\b\000\340\311\177\000\000"..., ialign = 65538, lalign = 71489730707458, falign = 9.18382988e-41, dalign = 3.5320619972997032e-310, palign = 0x410500010002 <error: Cannot access memory at address 0x410500010002>} ber = 0x7fc9e8d45130 rc = 23 bytes = 140505023260880 __PRETTY_FUNCTION__ = "send_ldap_response" #3 0x00000000004536eb in slap_send_ldap_result (op=0x7fc9e8d45810, rs=0x7fc9e8d45530) at result.c:863 tmp = 0x0 otext = 0x7fc9ea3eb758 "internal error" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #4 0x00007fc9ea3e1053 in syncprov_state_ctrl (op=0x7fc9e8d45810, rs=0x7fc9e8d45530, e=0x7fc9e8d454b0, entry_sync_state=1, ctrls=0x7fc9e0000908, num_ctrls=0, send_cookie=1, cookie=0x7fc9e8d45520) at syncprov.c:243 a = 0x7fc9e8d45480 ret = -1 berbuf = { buffer = "\000\000\001\000\005A\000\000\377\377\377\377\377\377\377\377\001", '\000' <repeats 23 times>, "\250\t\000\340\311\177\000\000\204\031\000\340\311\177", '\000' <repeats 18 times>, "\300\b\000\340\311\177", '\000' <repeats 14 times>, "\001\000\000\000\020\237i\334\311\177\000\000 \t\000\340\311\177\000\000\300\b\000\340\311\177\000\000\000\000\000\000\000\000\000\000\266\237i\334\311\177\000\000\232\t\000\340\311\177\000\000\060T\324\350\311\177\000\000 \t\000\340\311\177", '\000' <repeats 18 times>, " U\324\350\311\177\000\000\020X\324\350\311\177\000\000\350\017\000\000\000\000\000\000"..., ialign = 65536, lalign = 71489730707456, falign = 9.18354962e-41, dalign = 3.5320619972996044e-310, palign = 0x410500010000 <error: Cannot access memory at address 0x410500010000>} ber = 0x7fc9e8d45300 cp = 0x7fc9e0000908 bv = {bv_len = 1, bv_val = 0x7 <error: Cannot access memory at address 0x7>} entryuuid_bv = {bv_len = 8386118574382606194, bv_val = 0x696e556c616e6f69 <error: Cannot access memory at address 0x696e556c616e6f69>} #5 0x00007fc9ea3e2f38 in syncprov_sendresp (op=0x7fc9e8d45810, ri=0x7fc9dc699ed0, so=0x7fc9dc685620, mode=1) at syncprov.c:854 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 80, sr_matched = 0x0, sr_text = 0x7fc9ea3eb758 "internal error", sr_ref = 0x0, sr_ctrls = 0x7fc9e0000908, 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 = 64} cookie = {bv_len = 121, bv_val = 0x7fc9e0000920 "rid=001,sid=001,csn=rid=001,sid=001,csn=20150130194936.884757Z#000000#001#000000;20150130194935.766383Z#000000#003#000000"} csns = {{bv_len = 101, bv_val = 0x7fc9dc699f50 "rid=001,sid=001,csn=20150130194936.884757Z#000000#001#000000;20150130194935.766383Z#000000#003#000000"}, { bv_len = 0, bv_val = 0x0}} e_uuid = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x7fc9e8d45480, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x9df200, a_vals = 0x0, a_nvals = 0x7fc9dc699f00, a_numvals = 0, a_flags = 0, a_next = 0x0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #6 0x00007fc9ea3e336a in syncprov_qplay (op=0x7fc9e8d45810, so=0x7fc9dc685620) at syncprov.c:925 on = 0x7fc9dc14bea0 sr = 0x7fc9dc699fe0 rc = 0 #7 0x00007fc9ea3e359f in syncprov_qtask (ctx=0x7fc9e8d45c10, arg=0x7fc9dc685620) at syncprov.c:986 so = 0x7fc9dc685620 opbuf = {ob_op = {o_hdr = 0x7fc9e8d45980, o_tag = 99, o_time = 1422647372, o_tincr = 0, o_bd = 0x7fc9e8d45680, o_req_dn = {bv_len = 17, bv_val = 0x7fc9dc685bdd "dc=example,dc=com"}, o_req_ndn = {bv_len = 17, bv_val = 0x7fc9dc685bef "dc=example,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0xe10000001f4}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 15461882266100, bv_val = 0x7fc9dc15315c "\020\016"}, rb_edn = { bv_len = 0, bv_val = 0x7fc9dc685b48 "\001"}, rb_ssf = 3697825744, rb_mech = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}}, oq_compare = { rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_increment = -602590884}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_deleteoldrdn = -602590884, rs_newrdn = {bv_len = 0, bv_val = 0x7fc9dc685b48 "\001"}, rs_nnewrdn = { bv_len = 140504962979792, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fc9dc685c01, rs_nnewSup = 0x0}, oq_search = { rs_scope = 2, rs_deref = 0, rs_slimit = 500, rs_tlimit = 3600, rs_limit = 0x7fc9dc15315c, rs_attrsonly = 0, rs_attrs = 0x7fc9dc685b48, rs_filter = 0x7fc9dc6857d0, rs_filterstr = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = { rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = -602590884, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = -602590884, rs_reqdata = 0x0}, rs_old = { bv_len = 140504962980680, bv_val = 0x7fc9dc6857d0 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', 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 = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\003\000\000\001", '\000' <repeats 13 times>, o_controls = 0x7fc9e8d45ac8, o_authz = {sai_method = 128, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 24, bv_val = 0x7fc9dc685bc4 "ou=ou2,dc=example,dc=com"}, sai_ndn = {bv_len = 24, bv_val = 0x7fc9dc685bc4 "ou=ou2,dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 1, oh_connid = 1008, oh_conn = 0xa51320, oh_msgid = 2, oh_protocol = 3, oh_tid = 140505208063744, oh_threadctx = 0x7fc9e8d45c10, oh_tmpmemctx = 0x7fc9e00008c0, oh_tmpmfuncs = 0x7584c0 <slap_sl_mfuncs>, oh_counters = 0x7fc9dc002240, oh_log_prefix = "conn=1008 op=1", '\000' <repeats 241 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fc9e8d45810 be = {bd_info = 0x7fc9dc14b730, bd_self = 0x7fc9dc153080, 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 = 65816, 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 = 0x7fc9dc1467f0, be_nsuffix = 0x7fc9dc146820, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 28, bv_val = 0x7fc9dc146120 "cn=Manager,dc=example,dc=com"}, be_rootndn = {bv_len = 28, bv_val = 0x7fc9dc146170 "cn=manager,dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x7fc9dc146600 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x7fc9dc000990, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7fc9ea826d00 <bdbocs>, be_private = 0x7fc9dc145ce0, be_next = {stqe_next = 0x0}} rc = 0 #8 0x00007fc9f0386cf8 in ldap_int_thread_pool_wrapper (xpool=0x9e94c0) at tpool.c:696 pool = 0x9e94c0 task = 0x7fc9dc699fc0 work_list = 0x9e9558 ctx = {ltu_id = 140505171388160, ltu_key = {{ltk_key = 0x4af132 <slap_sl_mem_create+118>, ltk_data = 0x7fc9e00008c0, ltk_free = 0x4aef57 <slap_sl_mem_destroy+144>}, {ltk_key = 0x43c75c <conn_counter_init+144>, ltk_data = 0x7fc9e01091b0, ltk_free = 0x43c5ae <conn_counter_destroy+144>}, {ltk_key = 0x4572ef <slap_op_free+144>, ltk_data = 0x7fc9e0108df0, ltk_free = 0x457242 <slap_op_groups_free+69>}, {ltk_key = 0x7fc9dc141650, ltk_data = 0x7fc9e0109410, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, { ltk_key = 0x7fc9ea60bef0 <search_stack>, ltk_data = 0x7fc9dafff010, ltk_free = 0x7fc9ea60becd <search_stack_free>}, {ltk_key = 0x7fc9dc5a2dd0, ltk_data = 0x7fc9e0102d30, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc4c6bd0, ltk_data = 0x7fc9e0102e40, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc3ea9d0, ltk_data = 0x7fc9e0102f50, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, { ltk_key = 0x7fc9dc30e310, ltk_data = 0x7fc9e0103060, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc14dd20, ltk_data = 0x7fc9e0103170, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 22 times>}} kctx = 0x0 i = 32 keyslot = 395 hash = 1786060171 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x00007fc9ef55a0a4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #10 0x00007fc9ee5967fd in clone () from /lib64/libc.so.6 No symbol table info available. --------------000701070908040607050107--

1 0

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

Find tests/testrun/ here: http://www.stroeder.com/temp/openldap-its8041.tar.xz This is recent RE24 1a0ae715665489a1169dae3783f961891d879ce3

1 0

(ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

Full_Name: Version: RE24 from git OS: openSUSE 13.2 x86-64 URL: Submission from: (NULL) (79.227.179.192) >>>>> Starting test058-syncrepl-asymmetric for bdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... Using ldapsrcrch to check that central master slapd is running... Starting site1 master slapd on TCP/IP port 9012... Using ldapsearch to check that site1 master is running... Starting site2 master slapd on TCP/IP port 9013... Using ldapsearch to check that site2 master is running... Starting central search slapd on TCP/IP port 9014... Using ldapsearch to check that central search slapd is running... Starting site1 search slapd on TCP/IP port 9015... Using ldapsearch to check that site1 search slapd is running... Starting site2 search slapd on TCP/IP port 9016... Using ldapsearch to check that site2 search slapd is running... Adding schema on ldap://localhost:9011/... Adding backend module on ldap://localhost:9011/... Adding schema on ldap://localhost:9012/... Adding backend module on ldap://localhost:9012/... Adding schema on ldap://localhost:9013/... Adding backend module on ldap://localhost:9013/... Adding schema on ldap://localhost:9014/... Adding backend module on ldap:/FlFlocalhost:9014/... Adding schema on ldap://localhost:9015/... Adding backend module on ldap://localhost:9015/... Adding schema on ldap://localhost:9016/... Adding backend module on ldap://localhost:9016/... Adding database config on central master... Adding database config on site1 master... Adding database config on site2 master... Adding access rules on central master... Adding access rules on site1 master... Adding access rules on site2 master... Adding database config on central search... Adding database config on sit seaearch... Adding database config on site2 search... Populating central master... Adding syncrepl on site1 master... Adding syncrepl on site2 master... Using ldapsearch to check that site1 master received changes... Using ldapsearch to check that site2 master received changes... Populating site1 master... Populating site2 master... Stopping site1 master... Adding syncrepl on central master... Using ldapsearch to check that central master received site2 entries... Using ldapmodify to modify central master...%ReRestarting site1 master slapd on TCP/IP port 9012... ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault (core dumped) $SLAPD -F slapd.d -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 (wd:2/usr/src/michael/openldap-git/re24/openldap/tests/testrun/smc) Using ldapsearch to check that site1 master is running... Using ldapsearch to check that central master received site1 entries... Waiting 1 seconds for syncrepl to receive changes... Waiting 2 seconds for syncrepl to receive changes... Waiting 3 seconds for syncrepl to receive changes... Waiting 4 seconds for syncrepl to receive changes... Waiting 5 seconds for syncrepl to receive changes... ldapsearch failed (32)! ./scripts/test058-syncrepl-asymmetric: line 1051: kill: (22046) - No such process

1 0

Re: (ITS#8040) Add support for Microsoft LDAP_SERVER_LAZY_COMMIT control
by michael＠stroeder.com 30 Jan '15

30 Jan '15

IMHO you or someone else should write a short I-D defining another OID and semantics for that and post that to ldapext. I think it's worth the effort. Ciao, Michael.

1 0

(ITS#8040) Add support for Microsoft LDAP_SERVER_LAZY_COMMIT control
by hyc＠openldap.org 30 Jan '15

30 Jan '15

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (27.130.62.151) Submitted by: hyc For reasons discussed here http://www.openldap.org/lists/openldap-devel/201501/msg00014.html it would be good to implement this control. The behavior is documented here https://msdn.microsoft.com/en-us/library/cc223351.aspx The OID is listed here https://msdn.microsoft.com/en-us/library/cc223320.aspx as 1.2.840.113556.1.4.619

1 0

(ITS#8039) syncprov memory leak
by hyc＠openldap.org 29 Jan '15

29 Jan '15

Full_Name: Howard Chu Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (110.49.207.42) Submitted by: hyc In a 3-way MMR setup I'm seeing a consistent leak of queued Entries in syncprov. I'm not entirely sure of the exact sequence to reproduce it, but this is what I have so far: Test DB is 2.5GB on disk. One of the nodes (server #3) is configured with an mdb maxsize of 1GB, so it will always fail to sync up. The other two have sufficient maxsize configured. While server #3 is running, stop server #1 and #2 and completely reinit their DBs. rm the old files, rerun slapadd -w on server #1 (all new entryUUIDs and entryCSNs). Start server #1. Server #3 will reconnect and start trying to update itself and most of the updates will fail (as it runs out of space). Start server #2 (with an empty DB). It will start syncing from server #1. syncprov leaks will occur on both #2 and #3 during this time. Part of the trigger here appears to be from slapadd'ing the DB on server #1 without using the -S <sid> argument, so the DB contents all have SID #0. In this case updates get sent from #1 to #2 and #3 and syncprov on #2 and #3ueueues them up for transmission to other nodes, respectively. Syncprov doesn't know that it doesn't need to do this, because the SID #0 in the updates doesn't match any of the servers' SID #1, 2, or 3. The point in the code where the leak occurs is not obvious; the queued entries are all refcounted and the refcount is incremented whenever an entry is matched to an outbound queue. The count is decremented when a queue finishes sending the entry. In this particular case, I don't believe the entry is matched to any queue, so it should simply be freed again at the end of syncprov_matchops().

1 0

(ITS#8038) syncrepl presentlist bug
by hyc＠openldap.org 29 Jan '15

29 Jan '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc During a refresh the consumer maintains a presentlist containing the UUIDs of all entries that exist on the provider. At the end of the refresh this list is used to delete any entries on the consumer that don't exist on the provider. In refreshAndPersist, at the end of the refresh phase, the presentlist is not being freed as it should. It remains intact and unused until the persist session breaks and is restarted.

1 0

Re: (ITS#8023) slappasswd with sha2 overlay can generate hashes but not salted hashes
by freebsd＠jonathanprice.org 28 Jan '15

28 Jan '15

I have now made progress in narrowing down the cause further.=0A=0AI have= noticed that it is a regression between FreeBSD 9.x -> FreeBSD 10.x. For= this reason, I will move any updates on this to the FreeBSD bug tracker,= rather than the OpenLDAP one, as the bug is platform specific.=0A=0AFutu= re news will be posted here: https://bugs.freebsd.org/bugzilla/show_bug.c= gi?id=3D197004=0A=0AThank you for your time,=0A=0A-Jonathan=0A=0AJanuary = 22 2015 2:25 PM, freebsd(a)jonathanprice.org wrote: =0A> Sorry for the slow= response, but I have made some progress with the issue.=0A> =0A> (as an = aside, I installed a build from LTB, and unfortunately it does not=0A> co= ntain this overlay)=0A> =0A> I have detailed my findings (including some = trawling through the source)=0A> over on the FreeBSD bug tracker, as I su= spect it could well be a platform=0A> related issue. Nonetheless, it migh= t be worth reading:=0A> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id= =3D197004=0A> =0A> January 14 2015 4:31 PM, "Quanah Gibson-Mount" <quanah= @zimbra.com> wrote:=0A> =0A>> --On Wednesday, January 14, 2015 11:00 AM += 0000 freebsd(a)jonathanprice.org=0A>> wrote:=0A>> =0A>>> Hi,=0A>>> =0A>>> I= tried 2.4.39 under FreeBSD and still had the same issue.=0A>>> =0A>>> I = have also tried the packages for both CentOS 7 and Debian Wheezy, but=0A>= >> unfortunately neither of them include the SHA2 overlay by default.=0A>= >> =0A>>> Finally, I tried installing zimbra-core and zimbra-ldap under C= entOS.=0A>>> When I used this installation, it worked successfully.=0A>>>= =0A>>> I ran slapd -V on the zimbra installation, and it's 2.4.39. Howev= er,=0A>>> based on it still not working on 2.4.39 on FreeBSD it appears t= o have=0A>>> narrowed it down to two reasons: - An issue with the packagi= ng under=0A>>> FreeBSD=0A>>> - The functionality is specific to Zimbra=0A= >>> =0A>>> The next step in the process to narrow this down is to do a ma= nual=0A>>> compilation on CentOS, including the SHA2 overlay. If this wor= ks, then it=0A>>> would confirm it to be a FreeBSD issue, and if it doesn= 't work that would=0A>>> strongly suggest that Zimbra has modified someth= ing.=0A>> =0A>> You could simply grab the LTB project builds. I'm pretty = sure they build=0A>> out the contrib modules.=0A>> =0A>> In any case, I a= lready noted that Zimbra doesn't patch anything in OpenLDAP=0A>> that wou= ld affect this area.=0A>> =0A>> --Quanah=0A>> =0A>> --=0A>> =0A>> Quanah = Gibson-Mount=0A>> Platform Architect=0A>> Zimbra, Inc. =0A>> ____________= ___________________=0A>> =0A>> Zimbra :: the leader in open source messag= ing and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs