openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by quanah＠openldap.org 09 Mar '17

09 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.3 and higher OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapo-memberOf overlay is not safe to use in a replicated environment due to the way in which replication occurs. In particular, slapo-memberOf works fine as long as all user objects are created before any group objects. As soon as there are user objects that are members of a group where the user object was created after the group, breakage will occur if any consumer falls back into REFRESH mode. This is particularly trivial to reproduce by simply setting up a new empty consumer and allowing it to populate via REFRESH. This limitation should be clearly noted in the man page and the admin guide documentation. It is possible to set up slapo-dynlist to operate as a replacement for slapo-memberOf, and it is safe in a replicated environment. The tricky part of using slapo-dynlist is that membership information must be maintained by updating user objects rather than by updating group objects, which may be difficult for end users depending on how they perform group management. Example configuration: .... include "/opt/symas/etc/openldap/schema/memberof.schema" include "/opt/symas/etc/openldap/schema/dyngroup.schema" .... moduleload dynlist.la .... database mdb .... index memberOf ... overlay dynlist dynlist-attrset groupOfUrls memberURL member Then in the database: dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: memberOfOC memberOf: cn=testgroup,ou=Group,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfURLs cn: testgroup memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e xample,dc=com) member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The memberOf schema I came up with on the fly. It would need a different OID for the objectClass, and possibly a different objectClass name, as I stole those from ppolicy for testing purposes: attributetype ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'memberOfOC' SUP top AUXILIARY MUST ( memberOf ) )

1 0

(ITS#8612) lmdb build fails on illumos / solaris
by lorban＠bitronix.be 06 Mar '17

06 Mar '17

Full_Name: Ludovic Orban Version: OS: OmniOS r151020 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:a03f:1cdc:c300:384b:af79:f57c:b134) Building lmdb on illumos fails with the following error: mdb.c: In function 'mdb_env_copythr': mdb.c:9036:6: error: too many arguments to function 'sigwait' sigwait(&set, &tmp); ^ In file included from mdb.c:132:0: /usr/include/signal.h:165:12: note: declared here extern int sigwait(sigset_t *); ^ This happens because to use sigwait on illumos, you have to add the -D_POSIX_PTHREAD_SEMANTICS switch to the compiler. Changing the Makefile THREADS line to add the switch solves the problem: THREADS = -pthread -D_POSIX_PTHREAD_SEMANTICS FYI, I haven't tested on sun/oracle solaris but I guess it suffers from the exact same problem.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 06 Mar '17

06 Mar '17

--On Monday, March 06, 2017 5:24 PM +0000 mberg(a)synacor.com wrote: > Reading back over the report on ITS-8281, the reported behavior would > have been a collision of generating a new contextCSN as well as > duplicating the producer's SID. So it's generated contextCSN would > have masked the one it never committed from the original master. I'm not sure what you mean by duplicating the producer's SID. Both nodes had unique SID values. There were no duplicated SIDs. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8611) Option to block SSL renegotation after X attempts
by quanah＠openldap.org 06 Mar '17

06 Mar '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Using SSL renegotiation is a common form of DoS attack against services. It should be possible to configure the max # of times a client can request the server renegotiate the SSL layer before being dropped. Alternatively, an option to completely disable SSL renegotiation in the slapd configuration may also be desirable.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 06 Mar '17

06 Mar '17

Reading back over the report on ITS-8281, the reported behavior would have been a collision of generating a new contextCSN as well as duplicating the producer's SID. So it's generated contextCSN would have masked the one it never committed from the original master. However, the point still stands that the contextCSN entry is *not* being written to the access log by the first server (A) here. It is only being written by the second server (B). So in the scenario that is supposed to be addressed by the fix - a second MMR node with an uninitialized database is in its initial refresh, it wouldn't be receiving contextCSN updates through the access log because they simply aren't there. To me the logical behaviour would be that a new node would remain without a recorded contextCSN until it receives the sync cookie along with the refreshDone message. Sending an explicit contextCSN update after every single accesslog entry seems an awfully expensive and unintuitive approach to fixing a refresh issue. TL;DR: The objection raised in scenario #3 stands if you are initializing a new MMR node, since. Or in a single master + replica scenario. Or to rephrase, if these entries are intended and necessary, shouldn't they be generated on the original server as well? This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8610) ldaps not usable with DNS SRV
by Silvio.Wanka＠fiege.com 06 Mar '17

06 Mar '17

Full_Name: Silvio Wanka Version: openldap-client-2.4.44 OS: FreeBSD 10.3-RELEASE-p16 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.138.118.158) Hi, if I use "ldap:///dc%3Dexample%2Cdc%3Dorg" on a test system all works properly but I must use LDAPS on a DMZ system and so I try "ldaps:///dc%3Dexample%2Cdc%3Dorg" but this search for a ldap DNS SRV record which of course returns the normal ldap port not the ldaps port. This can't work, because a firewall is between. Is this normal (by design) or an bug? There is also an old discussion on your site: http://www.openldap.org/lists/openldap-technical/201203/msg00027.html. IMO should OpenSSL either support DNS SRV lookup for each scheme or for none. TIA, Silvio

1 0

(ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 05 Mar '17

05 Mar '17

Full_Name: Paul B. Henson Version: 2.4.44 + ITS 8432 patch OS: Linux (Gentoo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (96.251.22.157) As discussed in: https://www.openldap.org/lists/openldap-technical/201702/msg00077.html I'm getting random segfaults with openldap 2.4.44 (with the ITS 8432 patch applied) with the following backtrace: (gdb) bt full #0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7f50727fb480, mod=mod@entry=0x7f50600019a0, permissive=0, text=text@entry=0x7f50727fb9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=textlen@entry=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/mods.c:61 rc = <optimized out> op = 0x4fe045 "add" a = <optimized out> pmod = {sm_desc = <optimized out>, sm_values = 0x0, sm_nvalues = 0x0, sm _numvals = <optimized out>, sm_op = <optimized out>, sm_flags = <optimized out>, sm_type = {bv_len = <optimized out>, bv_val = <optimized out>}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007f526dfccd0c in mdb_modify_internal (op=op@entry=0x7f50727fc600, tid=tid@entry=0x1088a90, modlist=0x7f5060001960, e=e@entry=0x7f50727fb480, text=text@entry=0x7f50727f b9a0, textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: n o such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:137 rc = <optimized out> err = <optimized out> mod = 0x7f50600019a0 ml = 0x7f50600019a0 save_attrs = 0x7f5060004270 ap = 0x7f5272f53010 glue_attr_delete = <optimized out> got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007f526dfce134 in mdb_modify (op=0x7f50727fc600, rs=0x7f50727fb980) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/back-mdb/mod ify.c:624 mdb = 0x7f5272f53010 e = 0x7f5060004220 manageDSAit = <optimized out> textbuf = "modify/delete: eduPersonAffiliation: no such attribute\000\37 7\037\000\000\000\000\000\000\000@\003\315\000\000\000\000\000\200\271\177rP\177 \000\000\021\000\000\000\000\000\000\000.,\020`P\177\000\000 \360o\315\000\000\000\000\000\360\002\315\000\000\000\000\000\037\000\000\000\00 0\000\000\000\000\306\177rP\17 7\000\000\300\064\000`P\177\000\000\000\000\000\000\000\000\000\000\360o\315\000 \000\000\000\000 T\315\000\000 \000\000\000\000\306\177rP\177\000\000\270\232N\000\000\000\000\000 l\315\000\000\000\000\000\350\064\000`P\17 7\000\000\000\306\177rP\177\000\000\000\000\000\000\000\000\000\000"... txn = 0x1088a90 opinfo = {moi_oe = {oe_next = {sle_next = 0x7f50727fb930}, oe_key = 0x7f 5272f53010}, moi_txn = 0x1088a90, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7f50727fb430 dummy = {e_id = 66196, e_name = {bv_len = 40, bv_val = 0x7f50600041e8 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_nname = {bv_len = 40, bv_val = 0x7f5060004d18 "uid=aapriest,ou=user,dc=csupomona,dc=edu"}, e_attrs = 0xd202e8, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7f50 60004220} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f50727fb250} num_ctrls = 0 numads = 55 #3 0x000000000049c2ea in overlay_op_walk (op=op@entry=0x7f50727fc600, rs=0x7f50727fb980, which=op_modify, oi=0xcd6a40, on=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:6 77 func = <optimized out> rc = <optimized out> #4 0x000000000049c441 in over_op_func (op=0x7f50727fc600, rs=<optimized out>, which=<optimized out>) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/backover.c:7 30 oi = <optimized out> on = <optimized out> be = 0xcd0ac0 db = {bd_info = 0x7f526e1e6d40 <bi>, bd_self = 0xcd0ac0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\0 01\000\000\001", '\000' <repea ts 14 times>, "\001", be_flags = 563464, 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, ss s_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_s uffix = 0xcd0880, be_nsuffix = 0xca5c90, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_sc hemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldapr oot,dc=csupomona,dc=edu"}, be_rootndn = {bv_len = 31, bv_val = 0xcd0340 "cn=ldaproot,dc=csupomona ,dc=edu"}, be_rootpw = { bv_len = 38, bv_val = 0xca49a0 "{SSHA}XXXXXXXXXXXXXXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, 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 = 0xca5840, be_acl = 0xcd1c80, be_dfltaccess = ACL_READ, be_ extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_p ending_csn_list = 0xf85dc0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nuse rs = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0xcd 75c0, be_pb = 0x0, be_cf_ocs = 0x7f526e1e68c0 <mdbocs>, be_private = 0x7f5272f53010, be_n ext = {stqe_next = 0x0}} cb = {sc_next = 0x7f50727fb950, sc_response = 0x49b650 <over_back_respon se>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0xcd6a40} sc = <optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x000000000048d938 in syncrepl_message_to_op (si=si@entry=0xcd8520, op=op@entry=0x7f50727fc600, msg=0x7f5060102940) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:2 394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x48cd60 <syncrepl_mes sage_to_op>}, oe_si = 0xcd8520} ber = 0x7f50604b5390 modlist = 0x7f5060496f60 ls = 0x778940 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_mat ched = 0x0, sr_text = 0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: 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_sasld ata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x7f5060003490, sc_response = 0x48c8d0 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0x0 txtbuf = "@\277\177rP\177\000\000\020\274\177rP\177\000\000X\371P\000\00 0\000\000\000\266P\246rR\177\0 00\000@\277\177rP\177\000\000X\371P\000\000\000\000\000\240\272\177rP\177\000\00 0\060\275\246rR\177\000\000X\3 71P\000\000\000\000\000@^\246rR\177\000\000\000\000\000\000\000\000\000\000\002\ 000\000\000P\177\000\000\020\0 00\000\000\000\000\000\000\260\272\177rP\177\000\000\377\377\377\377\377\377\377 \377&\000\000\017\000\000\000\ 000\020\t\020\230P\177\000\000x\215I`P\177\000\000\177\215I`P\177\000\000\000\27 5\177rP\177\000\000p\234\305\0 00\000\000\000\000@\275\177rP\177\000\000 \205\315\000\000\000\000\000\313\343I\000\000\000\000\000\020", '\00 0' <repeats 23 times>... bdn = {bv_len = 40, bv_val = 0x7f50600013ac "uid=aapriest,ou=user,dc=csu pomona,dc=edu"} dn = {bv_len = 40, bv_val = 0x7f5060001c48 "\360!"} ndn = {bv_len = 40, bv_val = 0x7f5060001cd8 "\340\034"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7f506049fb80 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 #6 0x00000000004915d7 in do_syncrep2 (op=op@entry=0x7f50727fc600, si=si@entry=0xcd8520) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 013 match = <optimized out> syncUUID = {{bv_len = 16, bv_val = 0x7f506049fb47 "~\373\337l\214\335IȻ\346\230\350\r\n", <inc omplete sequence \316>}, { bv_len = 0, bv_val = 0x0}} cookie = {bv_len = 15, bv_val = 0x7f506049fb59 "rid=003,sid=003"} rctrls = 0x7f506049abe0 rctrlp = <optimized out> bdn = {bv_len = 44, bv_val = 0x7f506000135a "reqStart=20161225113103.000 003Z,cn=accesslog"} si_tag = <optimized out> entry = <optimized out> punlock = -1 syncstate = 1 retdata = 0x0 retoid = 0x78 <error: Cannot access memory at address 0x78> syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "@\373I`P\177\000\ 000h\373I`P\177\000\000h\373I` P\177", '\000' <repeats 26 times>, "п\177rP\177\000\000\000\000\000\000R\177\000\000\001\000\000\000\000\000\0 00\000dZ\023qR\177\000\000Dh,\200\207\001\305\345\000\000\000\000\001\000\000\00 0\200\255J`P\177\000\000`\305\ 177rP\177\000\000\257X\244qR\177\000\000\031p-rR\177\000\000\000\000\000\000\000 \000\000\000\b\246\246rR\177\0 00\000\060", '\000' <repeats 15 times>, "\001\000\000\000\000\000\000\000d"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e- 319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7f50727fbf40 msg = 0x7f5060102940 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 3, octet_str = {bv_len = 15, bv_val = 0x7f5060498d70 "rid=003,sid=003"}, sid = 3, sc_next = {stqe _next = 0x0}} syncCookie_req = {ctxcsn = 0x7f50604a6c10, sids = 0x7f50604996c0, numcsn s = 4, rid = 3, octet_str = { bv_len = 183, bv_val = 0x7f50604984e0 "rid=003,sid=000,csn=20161225102351.582901Z# 000000#000#000000;201612130230 51.387118Z#000000#001#000000;20160721062752.989665Z#000000#002#000000;2016072106 2824.859874Z#000000#003#000000 "}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 11 tout_p = 0x7f50727fbc00 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" #7 0x0000000000495793 in do_syncrepl (ctx=ctx@entry=0x7f50727fcb90, arg=arg@entry=0xcd8a00) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/syncrepl.c:1 564 rtask = 0xcd8a00 si = 0xcd8520 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INV ALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __cou nt = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__ prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_star ttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = { bv_len = 0, bv_val = 0x503e42 ""}, c_peer_name = {bv_len = 0, bv_val = 0x503e42 ""}, c_listener = 0x506e00 <dummy_list>, 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 = 0 x0}, 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}, s ai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protoco l = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x 0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__d ata = {__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, __nu sers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}} , __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__d ata = {__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_i n_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 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 = 0x 0}}, 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 = 0x0, c_clientarg = 0 x0, c_send_ldap_result = 0x442d90 <slap_send_ldap_result>, c_send_search_entry = 0x4437d0 <slap_send_search_entry>, c_send_search_reference = 0x444d10 <slap_send_search_reference>, c_send_ldap_extended = 0x4434a0 <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x443640 <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7f50727fc770, o_tag = 102, o_time = 14826654 63, o_tincr = 13, o_bd = 0x7f50727fb690, o_req_dn = {bv_len = 40, bv_val = 0x7f506049f2c0 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_req_ndn = {bv_len = 40, bv_val = 0x7f506049f300 "uid=aapriest,ou=user,dc=csupomona,dc=edu" }, o_request = {oq_add = { rs_modlist = 0x7f5060001960, rs_e = 0x1}, oq_bind = {rb_method = 1610619232, 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 = 0x7f5060001 960}, oq_modify = { rs_mods = {rs_modlist = 0x7f5060001960, rs_no_opattrs = 1 '\001' }, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7f5060001960, 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 = 1610619232, rs_deref = 32592, 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 = 1610619232}, oq_cancel = {rs_msgid = 1610619232}, oq_ extended = {rs_reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access m emory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs _reqoid = { bv_len = 139983184730464, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, 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 t imes>, o_controls = 0x7f50727fc8c0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldaproot,dc=csupomona ,dc=edu"}, sai_ndn = { sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7f5060004198, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7f5060102c10 "20161225113103.634923Z#000000#000#000000" }, o_private = 0x0, o_extra = {slh_first = 0x7f50727fb430}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 3, oh_conn = 0x7f50727fc340, oh_msgid = 0, oh_protocol = 0, oh_tid = 139983495091968, oh_threadctx = 0x7f50727fcb90, oh_tmpmemct x = 0x7 oh_tmpmfuncs = 0x7787a0 <slap_sl_mfuncs>, oh_counters = 0x7ae000 <sl ap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_exten sions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7f50727fbd00, 0x0 <repeats 14 times>}} op = 0x7f50727fc600 rc = 0 dostop = 0 s = 16 i = <optimized out> defer = 1 fail = 0 freeinfo = 0 be = 0xcd0ac0 #8 0x0000000000433037 in connection_read_thread (ctx=0x7f50727fcb90, argv=0x10) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/servers/slapd/connection.c :1296 rc = <optimized out> cri = {op = 0x0, func = 0x4954b0 <do_syncrepl>, arg = 0xcd8a00, ctx = <o ptimized out>, nullop = <optimized out>} s = <optimized out> #9 0x00007f5272c83a32 in ldap_int_thread_pool_wrapper (xpool=0xc63a40) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4 .44/libraries/libldap_r/tpool. c:696 pool = 0xc63a40 task = 0x7f50a8000a20 work_list = <optimized out> ctx = {ltu_id = 139983495091968, ltu_key = {{ltk_key = 0x430810 <conn_co unter_init>, ltk_data = 0x7f5060000d20, ltk_free = 0x4308f0 <conn_counter_destr oy>}, { ltk_key = 0x486ac0 <slap_sl_mem_init>, ltk_data = 0x7f5060000e30, ltk_free = 0x486990 <slap_sl_mem_destroy>}, {ltk_key = 0x445cd0 <s lap_op_free>, ltk_data = 0x7f50a0113e10, ltk_free = 0x445c30 <slap_op_q_destroy> }, {ltk_key = 0xf85de0, ltk_data = 0x7f5060102fd0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, { ltk_key = 0x7f526dfd07d0 <search_stack>, ltk_data = 0x7f5070ffc010 , ltk_free = 0x7f526dfd08e0 <search_stack_free>}, {ltk_key = 0x7f526 dfd0730 <scope_chunk_get>, ltk_data = 0x7f5060104e60, ltk_free = 0x7f526dfd08b0 <scope_chunk_ free>}, {ltk_key = 0xd7f560, ltk_data = 0x7f50604ab8f0, ltk_free = 0x7f526dfda950 <mdb_reader_f ree>}, {ltk_key = 0x0, ltk_data = 0x7f506c40fff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_da ta = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"

1 0

Re: (ITS#8575) Argon2 Password hashing contrib module
by quanah＠symas.com 04 Mar '17

04 Mar '17

--On Thursday, January 26, 2017 1:36 PM +0000 simon(a)slevermann.de wrote: > This patch adds a password hashing module for the argon2 function to the > contrib/slapd-modules/passwd/ modules. Argon2 is a relatively new hash > function which has won the Password Hashing Competition > (https://password-hashing.net) Discussed with Simon in IRC, he is going to look at making the modifications necessary so that this module can also use libsodium. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:57 PM +0000 quanah(a)symas.com wrote: > Your context for points 1-3 are invalid as the entire issue was around > N-way MMR (and their individual serverID contextCSNs) so non-master > replicas are beside the point. In addition, a correct setup via the most > recent tools would include replicas pulling from all masters, vs a single > master. So there is no replica only pulling from an "active" or > "passive" master in a correct setup. Replicas pull from *all* masters > when deployed correctly. See also > <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> For background on ITS#8281, the context was: 2 (or more) MMR nodes fully populated with X number of entries. Add a new MMR node (with no database populated) While the MMR node is in REFRESH mode, stop/start slapd on that node. The interuption in the REFRESH phase results in the DB not fully replicating (Stopped at the point in which slapd was stopped). This is clearly described in the initial report, where only 625/15000 users got replicated due to stopping slapd. The discussion about what to do when there's no contextCSN generated yet on a new system, where it is single master/consumer was an orthogonal but related discussion, in relation to the value of generating a contextCSN at startup or not. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 03 Mar '17

03 Mar '17

--On Friday, March 03, 2017 9:36 PM +0000 mberg(a)synacor.com wrote: > I'm not precisely sure how this relates to 8281, since that seemed to > be fixed by not generating an initial contextCSN for newly initialized > databases and telling consumers to smeg off if they tried to connect > before a contextCSN was written (presumably by a successful REFRESH in > a newly initialized MMR provider, or an initial write in a single- > master provider). See <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=cd8f…>, where the code was clearly modified to push the contextCSN's through where before they were not. The entire issue around ITS#8281 was REFRESH mode in MMR failing if the server was stopped and restarted midstream while doing the refresh, with the wrong CSN value being stored. The changes in ITS#8281 ensure it maintains the correct CSN value internally. Your context for points 1-3 are invalid as the entire issue was around N-way MMR (and their individual serverID contextCSNs) so non-master replicas are beside the point. In addition, a correct setup via the most recent tools would include replicas pulling from all masters, vs a single master. So there is no replica only pulling from an "active" or "passive" master in a correct setup. Replicas pull from *all* masters when deployed correctly. See also <https://bugzilla.zimbra.com/show_bug.cgi?id=95200> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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