- openldap-bugs - openldap.org

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

T24gNC83LzE2LCAxMjowNCBBTSwgIm9wZW5sZGFwLWJ1Z3Mgb24gYmVoYWxmIG9mIHF1YW5haEB6 aW1icmEuY29tIiA8b3BlbmxkYXAtYnVncy1ib3VuY2VzQG9wZW5sZGFwLm9yZyBvbiBiZWhhbGYg b2YgcXVhbmFoQHppbWJyYS5jb20+IHdyb3RlOg0KDQo+LS1PbiBUaHVyc2RheSwgQXByaWwgMDcs IDIwMTYgNDoyMiBBTSArMDAwMCBxdWFuYWhAemltYnJhLmNvbSB3cm90ZToNCj4NCj4+IFNvIHRo ZSBjaGFuZ2UgaXMgc3RpbGwgY29ycmVjdGx5IHJlcGxpY2F0ZWQgdG8gdGhlIHJlcGxpY2F0aW5n IE1NUiBub2RlLg0KPg0KPkkgc2VlIHRoZSBzYW1lIGJlaGF2aW9yIHdpdGggdGhlIGV4YW1wbGUg Y29uZmlndXJhdGlvbiB0aGF0IHdhcyBwcm92aWRlZCBhcyANCj53ZWxsLiAgV2hpbGUgdGhlIENT TiBiaXQgbWF5IG5vdCBiZSBsb2dnZWQsIHRoZSBjaGFuZ2UgaXMgcmVwbGljYXRlZCBhcyBpdCAN Cj5zaG91bGQgYmUuDQoNCjxzbmlwPg0KPg0KPlNvIHdoaWxlIHRoZSBsYWNrIG9mIHRoZSAsY3Nu IGJpdCBpcyBhbm5veWluZy4uLiBJIHNlZSBubyBhY3R1YWwgZGF0YSBsb3NzLCANCj5ldGMuDQoN Cg0KUXVhbmFoLA0KDQogIEnigJlsbCBnbyBwZWVyIGRlZXBlciBpbnRvIHRoZSBsb2dzIG9uIHRo ZSBjb25zdW1lciBzaWRlLiAgDQoNCiAgSWYgSSBmaW5kIHRoZSBzYW1lIGhlcmUsIHRoYXQgaW5k aWNhdGVzIHRoZSBwcm92aWRlciBpcyBzYXlpbmcg4oCcdGhlcmUgYXJlIGNoYW5nZXPigJ0gYnV0 IG5vdCBzZW5kaW5nIHRoZSBDU04gYW5kIHN5bmNyZXBsIGlzIHJldHJpZXZpbmcgYW5kIGFwcGx5 aW5nIHRoZSBjaGFuZ2VzLCBidXQgbm90IHVwZGF0aW5nIHRoZSBDU04gaW4gdGhlIERTQSBvZiB0 aGUgY29uc3VtZXIuICBXaGljaCBzdWdnZXN0cyB0aGF0IHN5bmNyZXBsIG5lZWRzIGEgcGF0Y2gg b3IgdGhhdCBJIHNob3VsZCBub3QgYmUgdHJ1c3RpbmcgdGhlIENTTiB2YWx1ZSBpbiB0aGUgY29u c3VtZXLigJlzIERTQSBpbiB0aGUgY2hlY2tfc3luY3JlcGwgc2NyaXB0IChhbHRob3VnaCwgSSBj YW7igJl0IHRoaW5rIG9mIGFub3RoZXIgcXVpY2sgd2F5IHRvIGFzc2VzcyB3aGV0aGVyIHRoZSBw cm92aWRlciBhbmQgY29uc3VtZXIgYXJlIGluIHN5bmMgLSBvZmYgdGhlIHRvcCBvZiBteSBoZWFk KS4gIEV2ZW50dWFsbHksIHN5bmNwcm92IGRvZXMgc2VuZCB0aGUgQ1NOIGFuZCB0aGUgY29uc3Vt ZXLigJlzIENTTiBnZXRzIHVwZGF0ZWQsIHNvIHRoaW5ncyByZXBvcnQgYXMgaGF2aW5nIGNhdWdo dCB1cC4NCg0KLSBGcmFuaw0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 07 Apr '16

07 Apr '16

--_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We already contacted Hyperion Support regarding this, However, still failed to start the OpenLDAP service. And we're thinking if it's in the setup of OpenLDAP. Kindly advise. Thank you ________________________________ This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local l= aw, electronic communications with Accenture and its affiliates, including = e-mail and instant messaging (including content), may be scanned by our sys= tems for the purposes of information security and assessment of internal co= mpliance with Accenture policy. ___________________________________________________________________________= ___________ www.accenture.com --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:m=3D"http://schema= s.microsoft.com/office/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html= 40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p> We already contacted Hyperion Support regarding this= , <o:p></o:p> However, still failed to start the OpenLDAP service.= <o:p></o:p> And we're thinking if it's in the setup of OpenLDAP.= <o:p></o:p> <o:p> </o:p> Kindly advise. Thank you<o:p></o:p> </div> <hr> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications w= ith Accenture and its affiliates, including e-mail and instant messaging (i= ncluding content), may be scanned by our systems for the purposes of inform= ation security and assessment of internal compliance with Accenture policy. ___________________________________________________________________________= ___________ www.accenture.com </body> </html> --_000_3bf83b446b8443aaaf25ce51fd410db7BLUPR4202MB0257048dmgdm_--

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 4:22 AM +0000 quanah(a)zimbra.com wrote: > So the change is still correctly replicated to the replicating MMR node. I see the same behavior with the example configuration that was provided as well. While the CSN bit may not be logged, the change is replicated as it should be. Provider: Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_queue_csn: queueing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: slap_graduate_commit_csn: removing 0x4ab3600 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap002 slapd[22212]: syncprov_sendresp: cookie=rid=100 Apr 6 22:59:28 zre-ldap002 slapd[22212]: conn=1003 op=1 RESULT tag=103 err=0 etime=0.084274 text= Replica: Apr 6 22:59:28 zre-ldap003 slapd[7947]: do_syncrep2: rid=100 cookie=rid=100 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_queue_csn: queueing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: slap_graduate_commit_csn: removing 0x37403c0 20160407035928.515652Z#000000#000#000000 Apr 6 22:59:28 zre-ldap003 slapd[7947]: syncrepl_message_to_op: rid=100 be_modify uid=fcs,ou=People,dc=uvm,dc=edu (0) So while the lack of the ,csn bit is annoying... I see no actual data loss, etc. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 4:05 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: > > Hi Frank, > > Actually, I see this affects all forms of replication. On my ldap > servers it is much more frequent than hourly: > Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, > cookie=rid=102,sid=003 Interestingly, for MMR, this does not result in any data loss, as the changes are replicated w/o problem: MMR node taking writes: Apr 6 21:56:47 ldap01 slapd[34514]: slap_queue_csn: queueing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: slap_graduate_commit_csn: removing 0x10bfcc80 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap01 slapd[34514]: conn=2909 op=286509 RESULT tag=103 err=0 etime=0.000935 text= Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 MMR node receiving writes: Apr 6 21:56:47 ldap02 slapd[61570]: do_syncrep2: rid=102 cookie=rid=102,sid=003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x80ee240 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_queue_csn: queueing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: syncprov_matchops: skipping original sid 003 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x420c2c0 20160407025647.107497Z#000000#003#000000 Apr 6 21:56:47 ldap02 slapd[61570]: slap_graduate_commit_csn: removing 0x80ee240 20160407025647.107497Z#000000#003#000000 So the change is still correctly replicated to the replicating MMR node. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 12:05 AM +0000 Frank.Swasey(a)uvm.edu wrote: Hi Frank, Actually, I see this affects all forms of replication. On my ldap servers it is much more frequent than hourly: Apr 6 20:57:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 20:58:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:00:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:01:24 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:03:29 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:04:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:06:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:02 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:07:51 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:09:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:10:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:11:26 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:13:03 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:17:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:18:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:21:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:23:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:25:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:26:57 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:27:55 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:29:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:30:38 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:31:10 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:32:20 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:33:27 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:35:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:37:07 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:38:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:39:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:40:16 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:41:11 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:42:59 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:43:32 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:44:31 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:45:50 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:48:36 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:00 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:51:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:53:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:54:28 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:55:21 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:56:47 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:58:04 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 21:59:05 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:01 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:01:33 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:02:30 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 Apr 6 22:03:41 ldap01 slapd[34514]: syncprov_sendresp: to=004, cookie=rid=102,sid=003 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 07 Apr '16

07 Apr '16

--On Thursday, April 07, 2016 12:04 AM +0000 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > On 4/6/16, 4:01 PM, "openldap-bugs on behalf of quanah(a)zimbra.com" > <openldap-bugs-bounces(a)openldap.org on behalf of quanah(a)zimbra.com> wrote: > >> Hi Frank, >> >> I'm going to see if I can reproduce this in my setup with your >> configurations. I did notice that you don't have the syncprov overlay >> loaded on your replica, which is generally recommended. > > Quanah, > > I've never heard that recommendation. Nor, do I find it in the > slapo-syncprov man page or the Administrator's guide discussion of the > syncprov overlay and delta-syncrepl configuration. Please provide a > reference to that recommendation. You just read it. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 07 Apr '16

07 Apr '16

T24gNC82LzE2LCA0OjAxIFBNLCAib3BlbmxkYXAtYnVncyBvbiBiZWhhbGYgb2YgcXVhbmFoQHpp bWJyYS5jb20iIDxvcGVubGRhcC1idWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnIG9uIGJlaGFsZiBv ZiBxdWFuYWhAemltYnJhLmNvbT4gd3JvdGU6DQoNCj5IaSBGcmFuaywNCj4NCj5JJ20gZ29pbmcg dG8gc2VlIGlmIEkgY2FuIHJlcHJvZHVjZSB0aGlzIGluIG15IHNldHVwIHdpdGggeW91ciANCj5j b25maWd1cmF0aW9ucy4gIEkgZGlkIG5vdGljZSB0aGF0IHlvdSBkb24ndCBoYXZlIHRoZSBzeW5j cHJvdiBvdmVybGF5IA0KPmxvYWRlZCBvbiB5b3VyIHJlcGxpY2EsIHdoaWNoIGlzIGdlbmVyYWxs eSByZWNvbW1lbmRlZC4NCg0KUXVhbmFoLA0KDQogIEnigJl2ZSBuZXZlciBoZWFyZCB0aGF0IHJl Y29tbWVuZGF0aW9uLiAgTm9yLCBkbyBJIGZpbmQgaXQgaW4gdGhlIHNsYXBvLXN5bmNwcm92IG1h biBwYWdlIG9yIHRoZSBBZG1pbmlzdHJhdG9y4oCZcyBndWlkZSBkaXNjdXNzaW9uIG9mIHRoZSBz eW5jcHJvdiBvdmVybGF5IGFuZCBkZWx0YS1zeW5jcmVwbCBjb25maWd1cmF0aW9uLiAgUGxlYXNl IHByb3ZpZGUgYSByZWZlcmVuY2UgdG8gdGhhdCByZWNvbW1lbmRhdGlvbi4NCg0KLSBGcmFuaw0K DQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Wednesday, April 06, 2016 7:58 PM +0000 Frank.Swasey(a)uvm.edu wrote: > SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpb > GRz > IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1Z > SBm > b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgd > Ghl > IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd > 29y > ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBza > W5n bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K Hi Frank, I'm going to see if I can reproduce this in my setup with your configurations. I did notice that you don't have the syncprov overlay loaded on your replica, which is generally recommended. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

SSBoYXZlIGJhY2tlZCBvdXQgdGhlIElUUyM4MjgxIHBhdGNoIGZyb20gbXkgbG9jYWwgYnVpbGRz IG9mIDIuNC40MyBhbmQgMi40LjQ0LiBUaGV5IGhhdmUgYm90aCBydW4gd2l0aG91dCBpc3N1ZSBm b3IgdHdvIGhvdXJzIGVhY2guICBUaGVyZWZvcmUsIEnigJltIHByZXR0eSBzdXJlIHRoYXQgdGhl IGNhdXNlIG9mIHRoZSBzeW5jcHJvdiBmYWlsdXJlIGlzIHRoYXQgcGF0Y2guICBJdCBtYXkgd29y ayB3ZWxsIGluIGFuIE1NUiBlbnZpcm9ubWVudCwgYnV0IGl0IGlzIGZhaWxpbmcgaW4gYSBzaW5n bGUgbWFzdGVyIHNldHVwLg0KDQotIEZyYW5rDQoNCg0K

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

SSBhbSBidWlsZGluZyBhIHZlcnNpb24gb2YgMi40LjQzIHdpdGggSVRTODI4MSByZW1vdmVkLiAg V2lsbCBzZWUgaWYgdGhhdCByZXNvbHZlcyB0aGUgaXNzdWUuDQoNCuKAlA0KRnJhbmsgU3dhc2V5 DQpTeXN0ZW1zIEFyY2hpdGVjdHVyZSAmIEFkbWluaXN0cmF0aW9uDQoNCg0KDQoNCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcGVubGRhcC1idWdzIDxvcGVubGRhcC1i dWdzLWJvdW5jZXNAb3BlbmxkYXAub3JnPiBvbiBiZWhhbGYgb2YgIkZyYW5rLlN3YXNleUB1dm0u ZWR1IiA8RnJhbmsuU3dhc2V5QHV2bS5lZHU+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDYsIDIw MTYgYXQgNzo0NSBBTQ0KVG86ICJvcGVubGRhcC1pdHNAb3BlbmxkYXAub3JnIiA8b3BlbmxkYXAt aXRzQG9wZW5sZGFwLm9yZz4NClN1YmplY3Q6IFJlOiAoSVRTIzgzOTYpIHN5bmNwcm92IGhvdXJs eSBmYWlscyB0byBhbnN3ZXIgc3luY3JlcGwNCg0KPldXVnpkR1Z5WkdGNUxDQkpJR0oxYVd4MElH RnVaQ0IwWlhOMFpXUWdNaTQwTGpRMExDQXlMalF1TkRNc0lHRnVaQ0F5TGpRdU5ESWcNCj5kMmww YUc5MWRDQjBhR1VnYm05eWJXRnNJRzF2WkdsbWFXTmhkR2x2Ym5NZ2RHaGhkQ0JKSUcxaGEyVWdk RzhnZEdobElHTnZaR1VnDQo+WW1GelpTNGdJQTBLRFFwSklHaGhkbVVnWm05MWJtUWdkR2hoZENC aWIzUm9JREl1TkM0ME5DQmhibVFnTWk0MExqUXpJR2hoZG1VZw0KPmRHaHBjeUJtWVdsc2RYSmxJ SGRwZEdocGJpQmhiaUJvYjNWeUlHOW1JSE4wWVhKMGFXNW5JSFJvWlNCd2NtbHRZWEo1SUhObGNu WmwNCj5jaUJoYm1RZ2IyNWpaU0JoYmlCb2IzVnlJR0ZtZEdWeUlHbDBJR1pwY25OMElHaGhjSEJs Ym5NdUlDQlVhR1VnTWk0MExqUXlJR052DQo+WkdVZ2FHRnpJR0psWlc0Z2NuVnVibWx1WnlCbWIz SWdiM1psY2lCbWFXWjBaV1Z1SUdodmRYSnpJRzV2ZHlCb1lYTWdibTkwSUdaaA0KPmFXeGxaQ0Jo ZENCaGJHd3VEUW9OQ2xSb1pTQnpZM0pwY0hRZ1NTQjFjMlZrSUhSdklHSjFhV3hrSUhSb1pYTmxJ R2x6SUdGMllXbHMNCj5ZV0pzWlNCb1pYSmxPZzBLRFFwb2RIUndPaTh2ZDNkM0xuVjJiUzVsWkhV dmZtWmpjeTl2Y0dWdWJHUmhjRjlwZEhNdlluVnBiR1F0DQo+YjNCbGJteGtZWEF1YzJnTkNnMEs0 b0NVRFFwR2NtRnVheUJUZDJGelpYa05DbE41YzNSbGJYTWdRWEpqYUdsMFpXTjBkWEpsSUNZZw0K PlFXUnRhVzVwYzNSeVlYUnBiMjROQ2cwSw0KPg0KPg0KPg0K

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

WWVzdGVyZGF5LCBJIGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIg d2l0aG91dCB0aGUgbm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUg YmFzZS4gIA0KDQpJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUg dGhpcyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZl ciBhbmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNv ZGUgaGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciBmaWZ0ZWVuIGhvdXJzIG5vdyBoYXMgbm90IGZh aWxlZCBhdCBhbGwuDQoNClRoZSBzY3JpcHQgSSB1c2VkIHRvIGJ1aWxkIHRoZXNlIGlzIGF2YWls YWJsZSBoZXJlOg0KDQpodHRwOi8vd3d3LnV2bS5lZHUvfmZjcy9vcGVubGRhcF9pdHMvYnVpbGQt b3BlbmxkYXAuc2gNCg0K4oCUDQpGcmFuayBTd2FzZXkNClN5c3RlbXMgQXJjaGl0ZWN0dXJlICYg QWRtaW5pc3RyYXRpb24NCg0K

1 0

Re: (ITS#8397) Unable to start LDAP Service in Windows
by hyc＠symas.com 06 Apr '16

06 Apr '16

charisse.ann.m.jorge(a)accenture.com wrote: > Full_Name: charisse.ann.m.jorge > Version: 2.3.7 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.16.158) > > > Hi > > we are experiencing the same issue as ITS#6106, the only difference is our LDAP > Version is 2.3.7. > > 1) Start the LDAP Service in Windows > 2) System will prompt error: > Windows could not start the Hyperion Foundation OpenLDAP on local computer. > For more information, review the system event log. If this is non-Microsoft > Service, contact the service vendor, and refer to service-specific error code > 16. > > 3) Go to Windows Event Viewer, System Log > Notice that there's an error log with description: > The Hyperion Foundation OpenLDAP Service terminated with service-specific > error 16 > > i tried running slapd.exe -d -1 > > E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 > @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ > @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd > daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ > daemon_init: 1 listeners to open... > ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) > daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. > connections_destroy: nothing to destroy. > > please advise. Do as the error message says and contact your service vendor. Apparently that's Hyperion Foundation. Not us. 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

(ITS#8397) Unable to start LDAP Service in Windows
by charisse.ann.m.jorge＠accenture.com 06 Apr '16

06 Apr '16

Full_Name: charisse.ann.m.jorge Version: 2.3.7 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.16.158) Hi we are experiencing the same issue as ITS#6106, the only difference is our LDAP Version is 2.3.7. 1) Start the LDAP Service in Windows 2) System will prompt error: Windows could not start the Hyperion Foundation OpenLDAP on local computer. For more information, review the system event log. If this is non-Microsoft Service, contact the service vendor, and refer to service-specific error code 16. 3) Go to Windows Event Viewer, System Log Notice that there's an error log with description: The Hyperion Foundation OpenLDAP Service terminated with service-specific error 16 i tried running slapd.exe -d -1 E:\Hyperion\products\Foundation\openLDAP>slapd.exe -d -1 @(#) $OpenLDAP: slapd 2.3.7 (Sep 28 2005 17:09:57) $ @DILEEP:/c/opldap15/openldap-2.3.7/servers/slapd daemon_init: ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: listen on ldap://$J(LOCALHOSTNAMESHORT):58089/ daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap://$J(LOCALHOSTNAMESHORT):58089/) daemon: invalid host $J(LOCALHOSTNAMESHORT)slapd stopped. connections_destroy: nothing to destroy. please advise.

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠zimbra.com 06 Apr '16

06 Apr '16

--On Tuesday, April 05, 2016 11:35 PM +0000 Frank.Swasey(a)uvm.edu wrote: It's ok, it is trivial to run through a mime decoder. So the regression was added in 2.4.43. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

U2Vjb25kIGF0dGVtcHQgLSBzb21ldGhpbmcgYWJvdXQgbXkgZmlyc3QgYXR0ZW1wdCBzZWVtcyB0 byBoYXZlIHRyaXBwZWQgdGhlIHNwYW0gZmlsdGVyIGF0IGdhdXNzLg0KDQpUb2RheSwgSSBoYXZl IGJ1aWx0IGFuZCB0ZXN0ZWQgMi40LjQ0LCAyLjQuNDMsIGFuZCAyLjQuNDIgd2l0aG91dCB0aGUg bm9ybWFsIG1vZGlmaWNhdGlvbnMgdGhhdCBJIG1ha2UgdG8gdGhlIGNvZGUgYmFzZS4gIEkgaGF2 ZSBmb3VuZCB0aGF0IGJvdGggMi40LjQ0IGFuZCAyLjQuNDMgaGF2ZSB0aGlzIGZhaWx1cmUgd2l0 aGluIGFuIGhvdXIgb2Ygc3RhcnRpbmcgdGhlIHByaW1hcnkgc2VydmVyIGFuZCBvbmNlIGFuIGhv dXIgYWZ0ZXIgaXQgZmlyc3QgaGFwcGVucy4gIFRoZSAyLjQuNDIgY29kZSBoYXMgYmVlbiBydW5u aW5nIGZvciBvdmVyIHR3byBob3VycyBub3cgKGFuZCBqdXN0IGFzIGluIG15IHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQpIGhhcyBub3QgZmFpbGVkIGF0IGFsbC4NCg0KVGhlIG9wdGlvbnMgSSBhbSB1 c2luZyB3aXRoIGNvbmZpZ3VyZSBhcmU6DQoNCmV4cG9ydCBDRkxBR1M9Ii1ETkRFQlVHIC1EX1JF RU5UUkFOVCAtZlBJQyINCmV4cG9ydCBMSUJTPSItbHB0aHJlYWQiDQouL2NvbmZpZ3VyZSBcDQog ICAgICAgIC1xIFwNCiAgICAgICAgLS1lbmFibGUtZHluYW1pYyBcDQogICAgICAgIC0tZW5hYmxl LXN0YXRpYyBcDQogICAgICAgIC0td2l0aC10aHJlYWRzPXBvc2l4IFwNCiAgICAgICAgLS13aXRo LXRscz1vcGVuc3NsIFwNCiAgICAgICAgLS13aXRoLWN5cnVzLXNhc2wgXA0KICAgICAgICAtLWVu YWJsZS13cmFwcGVycyBcDQogICAgICAgIC0tZW5hYmxlLXBhc3N3ZCBcDQogICAgICAgIC0tZW5h YmxlLWNsZWFydGV4dCBcDQogICAgICAgIC0tZW5hYmxlLWNyeXB0IFwNCiAgICAgICAgLS1lbmFi bGUtc3Bhc3N3ZCBcDQogICAgICAgIC0tZW5hYmxlLWxtcGFzc3dkIFwNCiAgICAgICAgLS1lbmFi bGUtbW9kdWxlcyBcDQogICAgICAgIC0tZW5hYmxlLWlwdjYgXA0KICAgICAgICBcDQogICAgICAg IC0tZW5hYmxlLXNsYXBkIFwNCiAgICAgICAgLS1lbmFibGUtYmFja2VuZHM9bW9kIFwNCiAgICAg ICAgLS1kaXNhYmxlLW5kYiBcDQogICAgICAgIC0tZGlzYWJsZS1zcWwgXA0KICAgICAgICAtLWRp c2FibGUtcGVybCBcDQogICAgICAgIC0tZGlzYWJsZS1zaGVsbCBcDQogICAgICAgIC0tZW5hYmxl LW92ZXJsYXlzPW1vZA0KDQoNCuKAlA0KRnJhbmsgU3dhc2V5DQpTeXN0ZW1zIEFyY2hpdGVjdHVy ZSAmIEFkbWluaXN0cmF0aW9uDQo=

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 06 Apr '16

06 Apr '16

VG9kYXksIEkgaGF2ZSBidWlsdCBhbmQgdGVzdGVkIDIuNC40NCwgMi40LjQzLCBhbmQgMi40LjQy IHdpdGhvdXQgdGhlIG5vcm1hbCBtb2RpZmljYXRpb25zIHRoYXQgSSBtYWtlIHRvIHRoZSBjb2Rl IGJhc2UuICBJIGhhdmUgZm91bmQgdGhhdCBib3RoIDIuNC40NCBhbmQgMi40LjQzIGhhdmUgdGhp cyBmYWlsdXJlIHdpdGhpbiBhbiBob3VyIG9mIHN0YXJ0aW5nIHRoZSBwcmltYXJ5IHNlcnZlciBh bmQgb25jZSBhbiBob3VyIGFmdGVyIGl0IGZpcnN0IGhhcHBlbnMuICBUaGUgMi40LjQyIGNvZGUg aGFzIGJlZW4gcnVubmluZyBmb3Igb3ZlciB0d28gaG91cnMgbm93IChhbmQganVzdCBhcyBpbiBt eSBwcm9kdWN0aW9uIGVudmlyb25tZW50KSBoYXMgbm90IGZhaWxlZCBhdCBhbGwuDQoNClRoZSBv cHRpb25zIEkgYW0gdXNpbmcgd2l0aCBjb25maWd1cmUgYXJlOg0KDQpleHBvcnQgQ0ZMQUdTPSIt RE5ERUJVRyAtRF9SRUVOVFJBTlQgLWZQSUMiDQpleHBvcnQgTElCUz0iLWxwdGhyZWFkIg0KLi9j b25maWd1cmUgXA0KICAgICAgICAtcSBcDQogICAgICAgIC0tZW5hYmxlLWR5bmFtaWMgXA0KICAg ICAgICAtLWVuYWJsZS1zdGF0aWMgXA0KICAgICAgICAtLXdpdGgtdGhyZWFkcz1wb3NpeCBcDQog ICAgICAgIC0td2l0aC10bHM9b3BlbnNzbCBcDQogICAgICAgIC0td2l0aC1jeXJ1cy1zYXNsIFwN CiAgICAgICAgLS1lbmFibGUtd3JhcHBlcnMgXA0KICAgICAgICAtLWVuYWJsZS1wYXNzd2QgXA0K ICAgICAgICAtLWVuYWJsZS1jbGVhcnRleHQgXA0KICAgICAgICAtLWVuYWJsZS1jcnlwdCBcDQog ICAgICAgIC0tZW5hYmxlLXNwYXNzd2QgXA0KICAgICAgICAtLWVuYWJsZS1sbXBhc3N3ZCBcDQog ICAgICAgIC0tZW5hYmxlLW1vZHVsZXMgXA0KICAgICAgICAtLWVuYWJsZS1pcHY2IFwNCiAgICAg ICAgXA0KICAgICAgICAtLWVuYWJsZS1zbGFwZCBcDQogICAgICAgIC0tZW5hYmxlLWJhY2tlbmRz PW1vZCBcDQogICAgICAgIC0tZGlzYWJsZS1uZGIgXA0KICAgICAgICAtLWRpc2FibGUtc3FsIFwN CiAgICAgICAgLS1kaXNhYmxlLXBlcmwgXA0KICAgICAgICAtLWRpc2FibGUtc2hlbGwgXA0KICAg ICAgICAtLWVuYWJsZS1vdmVybGF5cz1tb2QNCg0KDQrigJQNCkZyYW5rIFN3YXNleQ0KU3lzdGVt cyBBcmNoaXRlY3R1cmUgJiBBZG1pbmlzdHJhdGlvbg0KDQoNCg0KDQoNCg==

1 0

Re: (ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠zimbra.com 05 Apr '16

05 Apr '16

--On Sunday, April 03, 2016 3:34 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) Closing this ITS, it was related to a bug in the code in our side that sets the DH Param bits for slapd, that has a race condition, where the file may be 0 sized initially. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

1 0

(ITS#8396) syncprov hourly fails to answer syncrepl
by Frank.Swasey＠uvm.edu 04 Apr '16

04 Apr '16

Full_Name: Francis Swasey Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.2 (Maipo) URL: http://www.uvm.edu/~fcs/openldap_its/syncprov_files.tar.gz Submission from: (NULL) (132.198.104.198) Once an hour, the primary server logs a syncprov_sendresp that does not include a csn. When that happens, the replica misses that there were changes and does not update and therefore falls behind. The URI provides files for the primary and replica. replica/slapd_db.ldif -- starting database replica/slapd.conf -- replica's slapd configuration file (you'll need to create your own ssl certs) replica/syncrepl_audit.sh -- Runs on the replica (edit the email address and the path to check_syncrepl replica/check_syncrepl -- Used by nagios to report csn being in sync or not primary/slapd_db.ldif -- starting database (almost exactly like the replica's version) primary/slapd.conf -- primary's slapd configuration file (you'll need to create your own ssl certs) primary/syncprov_audit.sh -- greps the system log (edit the path) looking for the syncprov error primary/makechanges.sh -- edit to change the name of the ldap server and run this to make constant changes The bad log entries that coincide with check_syncrepl finding the replica has fallen behind are like: Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 They appear once an hour.

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 04 Apr '16

04 Apr '16

My initial report was garbled. What I mean is that a protection violation occurs in mdb.c when I add a 13'th item to a multiset and I compile with one of the mentioned compilers and with -fPIC -O3. The code works fine when compiled with older GCC compilers or with -O0 or with -fno-strict-aliasing. Given what I read at https://gcc.gnu.org/bugs/ under section "Casting does not work as expected when optimization is turned on", I suspect the problem is simply that a pointer variable is not following the ISO C aliasing rules and breaks with the new, more aggressive compiler optimization. Here is the part that fails: for (i=0; i<NUMKEYS(fp); i++) mp->mp_ptrs[i] = fp->mp_ptrs[i] + offset; If this turns out to not be straightforward, I can try building a small test program to reproduce the problem. On 04/03/2016 09:44 AM, Howard Chu wrote: > bdallen(a)nps.edu wrote: >> Full_Name: Bruce Allen >> Version: 2.4.44 >> OS: Fedora 23 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (205.155.65.226) >> >> >> LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when >> compiled >> using these compilers: >> * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) >> * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW >> 5.2.0-1.fc23) >> >> The crash happens afterrititing the 12'th item (with the same key but >> different >> value using flags MDB_NODUPDATA and MDB_DUPSORT). > > Your message appears garbled here. Please send a test case with steps > to reproduce. >> >> The problem goes away when compiling mdb.c with the >> -fno-strict-aliasing flag. >> >> > >

1 0

Re: (ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by hyc＠symas.com 03 Apr '16

03 Apr '16

bdallen(a)nps.edu wrote: > Full_Name: Bruce Allen > Version: 2.4.44 > OS: Fedora 23 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.155.65.226) > > > LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled > using these compilers: > * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) > * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) > > The crash happens afterrititing the 12'th item (with the same key but different > value using flags MDB_NODUPDATA and MDB_DUPSORT). Your message appears garbled here. Please send a test case with steps to reproduce. > > The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag. > > -- -- 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

(ITS#8395) DH Params code causes startTLS failure while slapd initializes the code
by quanah＠openldap.org 03 Apr '16

03 Apr '16

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) While testing the new DH params code for slapd, we found that there is an interval in which slapd will break for startTLS connections while it loads in the DH key. Example: Slapd is up and running, accepts startTLS connections just fine: Apr 2 21:13:08 zre-ldap002 slapd[4844]: conn=1004 fd=13 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=AES256-SHA256 Then we update olcTLSDHParamFile to add a DH key: Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD dn="cn=config" Apr 2 21:13:09 zre-ldap002 slapd[4844]: conn=1005 op=22 MOD attr=olcTLSDHParamFile Immediately after this, all startTLS attempts fail for the next few minutes: Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 fd=14 ACCEPT from IP=10.137.242.52:48327 (IP=10.137.242.52:389) Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 STARTTLS Apr 2 21:13:15 zre-ldap002 slapd[4844]: conn=1008 op=0 RESULT oid= err=52 etime=0.000078 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1008 fd=14 closed Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 ACCEPT from IP=10.137.242.52:48328 (IP=10.137.242.52:389) Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 STARTTLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=0 RESULT oid= err=52 etime=0.000054 text=Could not initialize TLS Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 op=1 UNBIND Apr 2 21:13:16 zre-ldap002 slapd[4844]: conn=1009 fd=14 closed Apr 2 21:13:17 zre-ldap002 slapd[4844]: connD1D1010 fd=14 ACCEPT from IP=10.137.242.52:48329 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 STARTTLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=0 RESULT oid= err=52 etime=0.000124 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1010 fd=14 closed Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 ACCEPT from IP=10.137.242.52:48330 (IP=10.137.242.52:389) Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=0 STARTTLS Apr 2 21:13:18 zre-lda0202 slapd[4844]: conn=1011 op=0 RESULT oid= err=52 etime=0.000075 text=Could not initialize TLS Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 op=1 UNBIND Apr 2 21:13:18 zre-ldap002 slapd[4844]: conn=1011 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 ACCEPT from IP=10.137.242.52:48331 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=0 RESULT oid= err=52 etime=0.000098 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1012 fd=14 closed Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 ACCEPT from IP=10.137.242.52:48332 (IP=10.137.242.52:389) Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 STARTTLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=0 RESULT oid= err=52 etime=0.000062 text=Could not initialize TLS Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 op=1 UNBIND Apr 2 21:13:20 zre-ldap002 slapd[4844]: conn=1013 fd=14 closed Apr 2 21:13"22 zre-ldap0 s slapd[4844]: conn=1014 fd=14 ACCEPT from IP=10.137.242.52:48333 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=0 RESULT oid= err=52 etime=0.000108 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 op=1 UNBIND Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1014 fd=14 closed Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 fd=14 ACCEPT from IP=10.137.242.52:48334 (IP=10.137.242.52:389) Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 STARTTLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=0 RESULT oid= err=52 etime=0.000066 text=Could not initialize TLS Apr 2 21:13:22 zre-ldap002 slapd[4844]: conn=1015 op=1 UNBIND .... Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022d%d=14 ACCEPT from IP=10.137.242.52:48339 (IP=10.137.242.52:389) Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 STARTTLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 op=0 RESULT oid= err=52 etime=0.000143 text=Could not initialize TLS Apr 2 21:14:01 zre-ldap002 slapd[4844]: conn=1022 fd=14 closed (connection lost) Eventually it recovers: Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 ACCEPT from IP=10.137.242.52:48340 (IP=10.137.242.52:389) Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 op=0 STARTTLS Apr 2 21:16:02 zre-ldap002 slapd[4844]: connD1D1027 op=0 RESULT oid= err=0 etime=0.000085 text= Apr 2 21:16:02 zre-ldap002 slapd[4844]: conn=1027 fd=14 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=AES128-SHA256 My guess is that startTLS is essentially broken while slapd spends time loading in the DH key. I would think that during this time, slapd should be deferring connections rather than accepting them immediately.

1 0

(ITS#8394) LMDB fails GCC5 without -fno-strict-aliasing
by bdallen＠nps.edu 02 Apr '16

02 Apr '16

Full_Name: Bruce Allen Version: 2.4.44 OS: Fedora 23 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.155.65.226) LMDB v0.9.18 crashes with segmentation fault in mdb.c line 6590 when compiled using these compilers: * gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) * x86_64-w64-mingw32-gcc (GCC) 5.2.0 20150716 (Fedora MinGW 5.2.0-1.fc23) The crash happens afterrititing the 12'th item (with the same key but different value using flags MDB_NODUPDATA and MDB_DUPSORT). The problem goes away when compiling mdb.c with the -fno-strict-aliasing flag.

1 0

(ITS#8393) LMDB - MDB_GET_BOTH broken on non-dup value
by hyc＠openldap.org 28 Mar '16

28 Mar '16

Full_Name: Howard Chu Version: 0.9.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.228.110) Submitted by: hyc Using mdb_cursor_get(MDB_GET_BOTH) doesn't return the data item if the record is not a dup (i.e., there's only a single value under the key) even though it matches. This doesn't affect slapd because (1) when we use this command, the key always has more than 1 value and (2) when we use it, the data item we passed in is exactly the same as what we would get returned, on a match. This affects other apps where both (1) and (2) are not true, e.g. a compare function is used that only compares a subset of the data, in order to retrieve the full record.

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by matthew＠wellquite.org 27 Mar '16

27 Mar '16

Fixed. The short version is it's definitely a problem of my own making, though it's not related to threading. It's an oversight in the design of my own bindings which only causes an issue when you open multiple databases at the same time. I shall be able to fix without a problem in my bindings. Thank you for your help, and sorry for wasting your time. Kind regards, Matthew

1 0

Re: (ITS#8392) Opening multiple databases from the same process
by hyc＠symas.com 27 Mar '16

27 Mar '16

Nothing immediately obvious jumps out. You might try adding some mdb_page_list() calls in here, maybe at each point where it pushes a new page onto the cursor. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs