syncrepl skipped entryCSN on openldap-2.4.44 on centos 6
by Daniel Jung
Hi,
I see that some entryCSN have not been synced properly with the provider.
I run multimaster setup and with several slaves and sometimes i see that
some slaves have old entryCSNs and I am syncing them manually with -c
option.
I haven't been able to track the cause nor see anything in the log to
indicate the problem. However, we have had slapd become non-responsive due
to IO blocking on logging. Could this cause syncrepl to miss updating the
entries? Has anyone seen this behaviour?
Thanks
6 years, 9 months
Re: PFS, TLSCipherSuite and Mac OS X interop
by Quanah Gibson-Mount
--On Thursday, February 16, 2017 5:14 PM +0100 Michael Ströder
<michael(a)stroeder.com> wrote:
> HI!
>
> Does anybody here have experience with Mac OS X accessing OpenLDAP server
> regarding TLS cipher suites?
I don't, but I know that OSX is using its own custom SSL library for its
OpenLDAP build, and that has never been run by the OpenLDAP project, so who
knows how well it functions.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
PFS, TLSCipherSuite and Mac OS X interop
by Michael Ströder
HI!
Does anybody here have experience with Mac OS X accessing OpenLDAP server regarding TLS
cipher suites?
OpenLDAP system:
- Debian Jessie
- OpenSSL 1.0.1t (openssl-1.0.1t-1+deb8u6)
- LTB packages openldap-ltb-2.4.44.1
Client is most recent Mac OS X.
In Æ-DIR the default is to only use PFS-secured ciphers:
TLSCipherSuite
ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!ADH
But that does not work. Maybe I overlook something but to me it seems Mac OS X does not
send any PFS ciphers in its ClientHello (see wireshark dissect below).
How to enable PFS ciphers in Mac's libldap?
Ciao, Michael.
------------------------------ snip ------------------------------
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 98
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 94
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 0
Cipher Suites Length: 14
Cipher Suites (7 suites)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 39
Extension: signature_algorithms
Extension: status_request
Extension: signed_certificate_timestamp
Extension: Extended Master Secret
6 years, 9 months
Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount
--On Wednesday, February 15, 2017 12:15 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> On Wed, Feb 15, 2017 at 09:04:48AM -0800, Quanah Gibson-Mount wrote:
>
>> Hm, so there is <http://www.openldap.org/its/index.cgi/?findid=8413>,
>> but not sure that's the same issue.
>
> I do have a 4-way MMR setup, but that seems to be the only simularity.
> It's crashing in mods.c, not search.c, and from a segfault when actually
> dereferencing a null pointer, rather than from an assertion failure
> checking for one. Well, I suppose the other simularity is that it
> happens during replication.
>
> Fortunately it's not that frequent of an occurance, and our load
> balancer pops the load over to the failover master fairly quickly when
> it happens, we usually only lose one transaction that I need to go clean
> up. It typically happens during the heavy update load of our daily
> identity management syncronization batch job.
I would suggest filing an ITS with the full backtrace info, so I can track
it. :) It could be useful to have the entry data from the accesslog as
well for the failed replication op, as we can see the failed entry DN in
the output of your backtrace. For example:
reqStart=20161225113103.000003Z,cn=accesslog
In some ways, although it's hard to be certain, it almost looks like it is
complaining that the end operation couldn't be completed (I.e., the account
being modified didn't have the attribute/value pair in the entry that the
delete was being requested for).
Does the operation complete successfully after slapd is restarted?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
Re: 2.4.44 + ITS 8432 patch segfault in modify_add_values
by Quanah Gibson-Mount
--On Tuesday, February 14, 2017 5:24 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> So I've gotten a total of 5 crashes so far since I updated my production
> environment to 2.4.44 with a locally applied ITS 8432 patch. I finally
> went ahead and built a debug enabled binary to take a better look at the
> core files.
>
> They all have the same signature, SIGSEGV in modify_add_values; and in
> all of them, "&mod->sm_values[mod->sm_numvals]", is NULL. I included a
> full backtrace from one of the cores. Any thoughts as to what might be
> going on here?
Hm, so there is <http://www.openldap.org/its/index.cgi/?findid=8413>, but
not sure that's the same issue.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
2.4.44 + ITS 8432 patch segfault in modify_add_values
by Paul B. Henson
So I've gotten a total of 5 crashes so far since I updated my production
environment to 2.4.44 with a locally applied ITS 8432 patch. I finally
went ahead and built a debug enabled binary to take a better look at the
core files.
They all have the same signature, SIGSEGV in modify_add_values; and in all of
them, "&mod->sm_values[mod->sm_numvals]", is NULL. I included a full
backtrace from one of the cores. Any thoughts as to what might be going on
here?
Thanks...
#0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7fbdef662480, mod=mod@entry=0x7fbdd0000980,
permissive=0, text=text@entry=0x7fbdef6629a0,
textbuf=textbuf@entry=0x7fbdef6624d0 "modify/delete: eduPersonAffiliation: no 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
61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) {
(gdb) print &mod->sm_values[mod->sm_numvals]
$1 = (BerValue *) 0x0
#0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7f3a720f3480, mod=mod@entry=0x7f3a6c0013a0,
permissive=0, text=text@entry=0x7f3a720f39a0,
textbuf=textbuf@entry=0x7f3a720f34d0 "modify/delete: eduPersonAffiliation: no 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
61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) {
(gdb) print &mod->sm_values[mod->sm_numvals]
$1 = (BerValue *) 0x0
#0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7fa36fffd480, mod=mod@entry=0x7fa358000980,
permissive=0, text=text@entry=0x7fa36fffd9a0,
textbuf=textbuf@entry=0x7fa36fffd4d0 "modify/delete: eduPersonAffiliation: no 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
61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) {
(gdb) print &mod->sm_values[mod->sm_numvals]
$1 = (BerValue *) 0x0
#0 0x0000000000485c61 in modify_add_values (e=e@entry=0x7f7e249f8480, mod=mod@entry=0x7f7e10001f00,
permissive=0, text=text@entry=0x7f7e249f89a0,
textbuf=textbuf@entry=0x7f7e249f84d0 "modify/delete: eduPersonAffiliation: no 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
61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) {
(gdb) print &mod->sm_values[mod->sm_numvals]
$1 = (BerValue *) 0x0
#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: no 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
61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) {
(gdb) print &mod->sm_values[mod->sm_numvals]
$1 = (BerValue *) 0x0
(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: no 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=0x7f50727fb9a0,
textbuf=textbuf@entry=0x7f50727fb4d0 "modify/delete: eduPersonAffiliation: no 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\377\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\000\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 = 0x7f5272f53010},
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 = 0x7f5060004220}
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\001\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, sss_update_transport = 0,
sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0xcd0880,
be_nsuffix = 0xca5c90, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0,
bv_val = 0x0}, be_rootdn = {bv_len = 31, bv_val = 0xcd02f0 "cn=ldaproot,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_pending_csn_list = 0xf85dc0,
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 = 0xcd75c0, be_pb = 0x0,
be_cf_ocs = 0x7f526e1e68c0 <mdbocs>, be_private = 0x7f5272f53010, be_next = {stqe_next = 0x0}}
cb = {sc_next = 0x7f50727fb950, sc_response = 0x49b650 <over_back_response>, 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_message_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_matched = 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_sasldata = 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\000\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\000\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\275\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=csupomona,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", <incomplete 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.000003Z,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\000\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, numcsns = 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;20160721062824.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_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, __elision = 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 = 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 = 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, __elision = 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, __elision = 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_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 = 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 = 0x0, c_clientarg = 0x0,
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 = 1482665463, 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 = 0x7f5060001960}, 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 memory 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 times>,
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_tmpmemctx = 0x7f5060000e30,
oh_tmpmfuncs = 0x7787a0 <slap_sl_mfuncs>, oh_counters = 0x7ae000 <slap_counters>,
oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 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 = <optimized 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_counter_init>,
ltk_data = 0x7f5060000d20, ltk_free = 0x4308f0 <conn_counter_destroy>}, {
ltk_key = 0x486ac0 <slap_sl_mem_init>, ltk_data = 0x7f5060000e30,
ltk_free = 0x486990 <slap_sl_mem_destroy>}, {ltk_key = 0x445cd0 <slap_op_free>,
ltk_data = 0x7f50a0113e10, ltk_free = 0x445c30 <slap_op_q_destroy>}, {ltk_key = 0xf85de0,
ltk_data = 0x7f5060102fd0, ltk_free = 0x7f526dfda950 <mdb_reader_free>}, {
ltk_key = 0x7f526dfd07d0 <search_stack>, ltk_data = 0x7f5070ffc010,
ltk_free = 0x7f526dfd08e0 <search_stack_free>}, {ltk_key = 0x7f526dfd0730 <scope_chunk_get>,
ltk_data = 0x7f5060104e60, ltk_free = 0x7f526dfd08b0 <scope_chunk_free>}, {ltk_key = 0xd7f560,
ltk_data = 0x7f50604ab8f0, ltk_free = 0x7f526dfda950 <mdb_reader_free>}, {ltk_key = 0x0,
ltk_data = 0x7f506c40fff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0x0} <repeats 24 times>}}
kctx = <optimized out>
keyslot = <optimized out>
hash = <optimized out>
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#10 0x00007f52722ce494 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#11 0x00007f52719c6edd in clone () from /lib64/libc.so.6
No symbol table info available.
6 years, 9 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Sunday, February 05, 2017 7:12 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
> On Fri, Feb 03, 2017 at 01:25:30PM -0800, Quanah Gibson-Mount wrote:
>
>> It turned out to not be related. :/
>
> Oh, that's disappointing :(. I'm reproducing it multiple times on a daily
> basis on my production systems 8-/, is there anything I can do to help
> track it down? Log dumps from high log levels? I could drop in a custom
> slapd binary on one of them if need be with extra logging code; anything
> that wouldn't unduly impact normal end user functionality...
>
> Thanks much.
I have a test setup from a coworker who managed to trigger this to examine
and see if I can push it into the test script. :)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Sunday, February 05, 2017 10:25 AM -0800 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> --On Friday, February 03, 2017 2:34 PM +0100 "A. Schulze"
> <sca(a)andreasschulze.de> wrote:
>
>>
>>
>> Am 31.01.2017 um 22:21 schrieb A. Schulze:
>>
>>> * but last: make test failed
>>> ( attached make_test_result.txt )
>>
>> the failing test was test059
>
> Ah, whoops. That I was able to reproduce at 25/500 runs.
I've filed <http://www.openldap.org/its/index.cgi/?findid=8589> for the
issue.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 9 months
RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
For this testing call, we particularly need folks to test OpenLDAP with
startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with
the 1.1 series). There is currenly nothing in the test suite that covers
encrypted connections (Although it's on my todo list). To build against
OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT
repository, depending on your build options as the current cyrus-sasl
release does not support the OpenSSL 1.1 series. It can be found at
<https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and
use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that
is where OpenSSL 1.1 support was added). It can be obtained from
<http://h5l.org/>.
Also new with this release is the ability to run "make its" in the tests/
directory. This will run a specific set of tests around past bugs to
ensure there are no regressions. While I've tested this with modular
openldap builds, it has not been tested with the modules and backends built
into slapd, so there could be some issues in that scenario.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
Configure & build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its run through the regression suite.
Thanks!
OpenLDAP 2.4.45 Engineering
Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533)
Fixed libldap handling of Diffie-Hellman parameters (ITS#7506)
Fixed libldap GnuTLS use after free (ITS#8385)
Fixed slapd sasl SEGV rebind in same session (ITS#8568)
Fixed slapd syncrepl filter handling (ITS#8413)
Fixed slapd syncrepl infinite looping mods with delta-sync MMR
(ITS#8432)
Fixed slapd callback struct so older modules without writewait
should function.
Custom modules may need to be updated for sc_writewait
callback (ITS#8435)
Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794)
Fixed slapd-meta uninitialized diagnostic message (ITS#8442)
Fixed slapo-accesslog to honor pauses during purge for cn=config
update (ITS#8423)
Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428)
Build Environment
Added test065 for proxyauthz (ITS#8571)
Fix test008 to be portable (ITS#8414)
Fix its4336 regression test (ITS#8534)
Fix its4337 regression test (ITS#8535)
Fix regression tests to execute on all backends (ITS#8539)
Contrib
Added slapo-autogroup(5) man page (ITS#8569)
Added passwd missing conversion scripts for apr1 (ITS#6826)
Fixed contrib modules where the writewait callback was not
correctly initialized (ITS#8435)
Fixed smbk5pwd to build with newer OpenSSL releases
(ITS#8525)
Documentation
admin24 fixed tls_cipher_suite bindconf option (ITS#8099)
admin24 fixed typo cn=config to be slapd.d (ITS#8449)
Fixed slapd-config(5), slapd.conf(5) clarification on
interval keyword for refreshAndPersist (ITS#8538)
Fixed slapo-ppolicy(5) to clearly note rootdn requirement
(ITS#8565)
Fixed various minor grammar issues in the man pages
(ITS#8544)
LMDB 0.9.20 Release Engineering
Fix mdb_load with escaped plaintext (ITS#8558)
Fix mdb_cursor_last / mdb_put interaction (ITS#8557)
LMDB 0.9.19 Release (2016/12/28)
Fix mdb_env_cwalk cursor init (ITS#8424)
Fix robust mutexes on Solaris 10/11 (ITS#8339)
Tweak Win32 error message buffer
Fix MDB_GET_BOTH on non-dup record (ITS#8393)
Optimize mdb_drop
Fix xcursors after mdb_cursor_del (ITS#8406)
Fix MDB_NEXT_DUP after mdb_cursor_del (ITS#8412)
Fix mdb_cursor_put resetting C_EOF (ITS#8489)
Fix mdb_env_copyfd2 to return EPIPE on SIGPIPE (ITS#8504)
Fix mdb_env_copy with empty DB (ITS#8209)
Fix behaviors with fork (ITS#8505)
Fix mdb_dbi_open with mainDB cursors (ITS#8542)
Fix robust mutexes on kFreeBSD (ITS#8554)
Fix utf8_to_utf16 error checks (ITS#7992)
Fix F_NOCACHE on MacOS, error is non-fatal (ITS#7682)
Build
Make shared lib suffix overridable (ITS#8481)
Documentation
Cleanup doxygen nits
Note reserved vs actual mem/disk usage
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Valgrind detecting memory leak on 2-way multi master setup on RHEL 6 - openldap 2.4.44
by ping-shin ching
Hi,
I'm running two ldap servers (2.4.44) in a 2-Way multi master setup on RHEL 2.6 (glibc 2.12).
Valgrind detects a memory leak every time an entry is deleted a provider.
configure options...
--without-cyrus-sasl \
--disable-bdb \
--disable-hdb \
--enable-ldap \
--enable-mdb \
--enable-constraint
Valgrind output from the provider where the entry was deleted.
.....
==15112== 100 bytes in 1 blocks are possibly lost in loss record 10 of 11
==15112== at 0x4A05EDF: calloc (vg_replace_malloc.c:710)
==15112== by 0x51CA6C: ber_memcalloc_x (memory.c:260)
==15112== by 0x4F4374: ldap_pvt_runqueue_insert (rq.c:48)
==15112== by 0x4D688A: log_cf_gen (accesslog.c:942)
==15112== by 0x4161D2: config_set_vals (config.c:353)
==15112== by 0x485BD0: over_db_config (backover.c:117)
==15112== by 0x41A142: read_config_file (config.c:844)
==15112== by 0x415290: read_config (bconfig.c:4238)
==15112== by 0x407279: main (main.c:797)
==15112==
==15112== 393 bytes in 1 blocks are definitely lost in loss record 11 of 11
==15112== at 0x4A0717A: malloc (vg_replace_malloc.c:298)
==15112== by 0x51CB54: ber_memalloc_x (memory.c:204)
==15112== by 0x43A9EA: ch_malloc (ch_malloc.c:54)
==15112== by 0x4DDFE2: syncprov_qresp (syncprov.c:1061)
==15112== by 0x4DF812: syncprov_op_response (syncprov.c:1981)
==15112== by 0x42F87D: slap_response_play (result.c:508)
==15112== by 0x4303F8: send_ldap_response (result.c:583)
==15112== by 0x4310EB: slap_send_ldap_result (result.c:861)
==15112== by 0x4C7681: mdb_delete (delete.c:464)
==15112== by 0x484C1D: overlay_op_walk (backover.c:677)
==15112== by 0x485692: over_op_func (backover.c:730)
==15112== by 0x438B72: fe_op_delete (delete.c:174)
==15112==
==15112== LEAK SUMMARY:
==15112== definitely lost: 548 bytes in 4 blocks
==15112== indirectly lost: 0 bytes in 0 blocks
==15112== possibly lost: 303 bytes in 5 blocks
==15112== still reachable: 64 bytes in 2 blocks
==15112== suppressed: 0 bytes in 0 blocks
==15112== Reachable blocks (those to which a pointer was found) are not shown.
==15112== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==15112==
==15112== For counts of detected and suppressed errors, rerun with: -v
==15112== Use --track-origins=yes to see where uninitialised values come from
==15112== ERROR SUMMARY: 11 errors from 11 contexts (suppressed: 4 from 4)
==15112== could not unlink /tmp/vgdb-pipe-from-vgdb-to-15112-by-root-on-nsdalvmldap12.isppe.in.telstra.com.au
==15112== could not unlink /tmp/vgdb-pipe-to-vgdb-from-15112-by-root-on-nsdalvmldap12.isppe.in.telstra.com.au
==15112== could not unlink /tmp/vgdb-pipe-shared-mem-vgdb-15112-by-root-on-nsdalvmldap12.isppe.in.telstra.com.au
snippet of syncprov overlay from the slapd.conf
...
mirrormode on
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 10000
syncprov-nopresent TRUE
...
Regards,
Ping
6 years, 10 months
