openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by hguo＠suse.com 10 Nov '16

10 Nov '16

Full_Name: Howard Guo Version: Latest at commit 227e02ec2049c6df5df44333980e3b529289a5c7 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/howard-guo-161110.patch Submission from: (NULL) (195.135.221.2) The TLS configuration deliberately hid the error in case that user specified CA locations cannot be read, by loading CAs from default locations; and when user does not specify CA locations, the CAs from default locations are not read at all. This patch corrects the behaviour so that CAs from default location are used if user does not specify a CA location, and user is informed of the error if CAs cannot be loaded from the user specified location.

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Nov '16

07 Nov '16

--On Monday, November 07, 2016 10:47 AM +0000 Mark.Bannister(a)morganstanley.com wrote: Decoded version of Mark's mail: 'Dear Steffen, Apologies for the delay in replying. No I didn't encounter the problem again, at least, I haven't spotted any hanging slapadd processes. But I'm not looking for them either. I think it is a rare race condition. From your de scription you may well have found a new way to trigger a similar deadlock. I provided a patch, and another suggested way of fixing the issue I encountered, and as you can see from the openldap-technical archive, I had one short reply from Howard on the subject and nothing thereafter. Likewise ITS#8436 has sat in Incoming since it was raised in June without comment. My feeling is that the OpenLDAP code base is now too big for the number of active developers, pushing rare issues like this right to the bottom of their queue. I doubt it'll get fixed. Best regards, Mark.' (irrelevant parts removed) --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#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 07 Nov '16

07 Nov '16

77u/RGVhciBTdGVmZmVuLA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXBseWluZy4N Cg0KTm8gSSBkaWRuJ3QgZW5jb3VudGVyIHRoZSBwcm9ibGVtIGFnYWluLCBhdCBsZWFzdCwgSSBo YXZlbid0IHNwb3R0ZWQgYW55IGhhbmdpbmcgc2xhcGFkZCBwcm9jZXNzZXMuICBCdXQgSSdtIG5v dCBsb29raW5nIGZvciB0aGVtIGVpdGhlci4gIEkgdGhpbmsgaXQgaXMgYSByYXJlIHJhY2UgY29u ZGl0aW9uLiAgRnJvbSB5b3VyIGRlc2NyaXB0aW9uIHlvdSBtYXkgd2VsbCBoYXZlIGZvdW5kIGEg bmV3IHdheSB0byB0cmlnZ2VyIGEgc2ltaWxhciBkZWFkbG9jay4NCg0KSSBwcm92aWRlZCBhIHBh dGNoLCBhbmQgYW5vdGhlciBzdWdnZXN0ZWQgd2F5IG9mIGZpeGluZyB0aGUgaXNzdWUgSSBlbmNv dW50ZXJlZCwgYW5kIGFzIHlvdSBjYW4gc2VlIGZyb20gdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBh cmNoaXZlLCBJIGhhZCBvbmUgc2hvcnQgcmVwbHkgZnJvbSBIb3dhcmQgb24gdGhlIHN1YmplY3Qg YW5kIG5vdGhpbmcgdGhlcmVhZnRlci4gIExpa2V3aXNlIElUUyM4NDM2IGhhcyBzYXQgaW4gSW5j b21pbmcgc2luY2UgaXQgd2FzIHJhaXNlZCBpbiBKdW5lIHdpdGhvdXQgY29tbWVudC4NCg0KTXkg ZmVlbGluZyBpcyB0aGF0IHRoZSBPcGVuTERBUCBjb2RlIGJhc2UgaXMgbm93IHRvbyBiaWcgZm9y IHRoZSBudW1iZXIgb2YgYWN0aXZlIGRldmVsb3BlcnMsIHB1c2hpbmcgcmFyZSBpc3N1ZXMgbGlr ZSB0aGlzIHJpZ2h0IHRvIHRoZSBib3R0b20gb2YgdGhlaXIgcXVldWUuICBJIGRvdWJ0IGl0J2xs IGdldCBmaXhlZC4NCg0KQmVzdCByZWdhcmRzLA0KTWFyay4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFN0ZWZmZW4gTW9zZXIgW21haWx0bzpsaXN0c0BzdGVmZmVuLW1vc2Vy LmRlXSANClNlbnQ6IDIzIE9jdG9iZXIgMjAxNiAwMjo0Mg0KVG86IEJhbm5pc3RlciwgTWFyayAo RW50ZXJwcmlzZSBJbmZyYXN0cnVjdHVyZSkNCkNjOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3Jn DQpTdWJqZWN0OiBSZTogKElUUyM4NDM2KSBzbGFwYWRkIGhhbmcgaW4gYmRiX3Rvb2xfZW50cnlf Y2xvc2UgLyBsZGFwX3B2dF90aHJlYWRfY29uZF93YWl0DQoNCkRlYXIgTWFyaywNCg0KT24gMDUv MjUvMTYgMjozOCBQTSwgTWFyayBCYW5uaXN0ZXIgd3JvdGU6DQo+IENhbiBhbnlvbmUgc2hlZCBs aWdodCBvbiB3aHkgbXkgc2xhcGFkZCBwcm9jZXNzIG9uIFNvbGFyaXMgMTEgd2FzIA0KPiBoYW5n aW5nIChzbGFwZCAyLjQuMzApPyAgSSB3YXMgcGlwaW5nIOKAmGd1bnppcCAtY+KAmSB0aHJvdWdo IHRvIHNsYXBhZGQgDQo+IChmcm9tIGFuIG92ZXJuaWdodCBjcm9uIGpvYikuICBUaGlzIHVzdWFs bHkgd29ya3MgZmluZS4gIEnigJltIGd1ZXNzaW5nIA0KPiBwZXJoYXBzIHRoZSBndW56aXAgcHJv Y2VzcyBlbmNvdW50ZXJlZCBhbiBlcnJvciwgbWF5YmUgYW4gRVBJUEUgd2FzIA0KPiBzZW50LCBi dXQgdGhlIHN0YWNrIHRyYWNlIG1hbnkgZGF5cyBsYXRlciBmcm9tIHNsYXBhZGQgZG9lc27igJl0 IGxvb2sgDQo+IHJpZ2h0LiAgT25seSAyIHRocmVhZHMsIGFuZCBib3RoIG9mIHRoZW0gaW4gDQo+ IGxkYXBfcHZ0X3RocmVhZF9jb25kX3dhaXQoKSwgYnV0IG5vIG90aGVyIHRocmVhZHMgc28gd2hh dCBhcmUgdGhleSANCj4gd2FpdGluZyBmb3IgZXhhY3RseT8NCg0KSSd2ZSBqdXN0IGNvbWUgYWNy b3NzIHlvdXIgcHJvYmxlbSByZXBvcnQgd2hpY2ggeW91IHBvc3RlZCB0byB0aGUgIm9wZW5sZGFw LWl0cyIgbWFpbGluZyBsaXN0IGluIHRoaXMgeWVhcidzIE1heToNCg0KICBodHRwOi8vd3d3Lm9w ZW5sZGFwLm9yZy9saXN0cy9vcGVubGRhcC10ZWNobmljYWwvMjAxNjA1L3RocmVhZHMuaHRtbCMw MDA3OQ0KDQpUb2RheSwgSSBlbmNvdW50ZXJlZCBhIHNpbWlsYXIgaGFuZyBvZiBvdXIgT3BlbkxE QVAgMi40LjMwIHNlcnZlciBvbiBhIFNvbGFyaXMgMTEuMyguMTEuNi4wKSBob3N0Lg0KDQpJdCBp cyBxdWl0ZSBpbnRlcmVzdGluZyB0aGF0IHRoZSBmdW5jdGlvbiAiYmRiX3Rvb2xfZW50cnlfY2xv c2UiIGRvZXNuJ3Qgc2VlbSB0byBwbGF5IGEgcm9sZSBpbiBteSBjYXNlLCBidXQgImxkYXBfcHZ0 X3RocmVhZF9jb25kX3dhaXQiIGFuZCAibGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciIgZG8g c2VlbSB0by4NCg0KTXkgcXVlc3Rpb25zIHRvIHlvdXIgYWRkcmVzcyBhbmQgdG8gdGhlIG1haWxp bmcgbGlzdCBhcmU6IEhhcyB0aGUgYnVnL3Byb2JsZW0gYmVlbiBmdWxseSBhbmFseXplZCBhbmQg aGFzIGl0IGJlZW4gZml4ZWQgaW4gdGhlIG1lYW50aW1lPw0KTWFyaywgZGlkIHlvdSBoYXZlIGFu b3RoZXIgaGFuZyBvZiB0aGlzIGtpbmQgb3IgYW55IHNpbWlsYXIgcHJvYmxlbXMgd2l0aCB5b3Vy IE9wZW5MREFQIGluc3RhbGxhdGlvbj8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNl IGZvciBhbnkgaGVscGZ1bCBoaW50cyENCg0KS2luZCByZWdhcmRzLA0KU3RlZmZlbg0KDQoNCi0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkRpcGwuLUluZi4gU3RlZmZlbiBNb3Nlcg0KU2Nob29sIG9mIEFk dmFuY2VkIFByb2Zlc3Npb25hbCBTdHVkaWVzICAgICAgICAgICAgUm9vbTogNDUuMy4xMTANClVs bSBVbml2ZXJzaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlbDogKzQ5 LjczMS41MC0zMjQwNw0KQWxiZXJ0LUVpbnN0ZWluLUFsbGVlIDQ1ICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmF4OiArNDkuNzMxLjUwLTMyNDA5DQo4OTA4MSBVbG0sIEdlcm1hbnkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3NhcHMudW5pLXVsbS5kZS8NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOT1RJQ0U6IE1vcmdhbiBTdGFubGV5IGlzIG5vdCBhY3Rp bmcgYXMgYSBtdW5pY2lwYWwgYWR2aXNvciBhbmQgdGhlIG9waW5pb25zIG9yIHZpZXdzIGNvbnRh aW5lZCBoZXJlaW4gYXJlIG5vdCBpbnRlbmRlZCB0byBiZSwgYW5kIGRvIG5vdCBjb25zdGl0dXRl LCBhZHZpY2Ugd2l0aGluIHRoZSBtZWFuaW5nIG9mIFNlY3Rpb24gOTc1IG9mIHRoZSBEb2RkLUZy YW5rIFdhbGwgU3RyZWV0IFJlZm9ybSBhbmQgQ29uc3VtZXIgUHJvdGVjdGlvbiBBY3QuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGRlc3Ry b3kgYWxsIGVsZWN0cm9uaWMgYW5kIHBhcGVyIGNvcGllcyBhbmQgbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkuIE1pc3RyYW5zbWlzc2lvbiBpcyBub3QgaW50ZW5kZWQgdG8gd2FpdmUgY29u ZmlkZW50aWFsaXR5IG9yIHByaXZpbGVnZS4gTW9yZ2FuIFN0YW5sZXkgcmVzZXJ2ZXMgdGhlIHJp Z2h0LCB0byB0aGUgZXh0ZW50IHBlcm1pdHRlZCB1bmRlciBhcHBsaWNhYmxlIGxhdywgdG8gbW9u aXRvciBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zLiBUaGlzIG1lc3NhZ2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2luZyBsaW5rOiBodHRwOi8vd3d3Lm1vcmdh bnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzICBJZiB5b3UgY2Fubm90IGFjY2VzcyB0aGVzZSBsaW5r cywgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBtZXNzYWdlIGFuZCB3ZSB3aWxsIHNlbmQgdGhl IGNvbnRlbnRzIHRvIHlvdS4gQnkgY29tbXVuaWNhdGluZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlv dSBjb25zZW50IHRvIHRoZSBmb3JlZ29pbmcgYW5kIHRvIHRoZSB2b2ljZSByZWNvcmRpbmcgb2Yg Y29udmVyc2F0aW9ucyB3aXRoIHBlcnNvbm5lbCBvZiBNb3JnYW4gU3RhbmxleS4=

1 0

Re: (ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠symas.com 03 Nov '16

03 Nov '16

--On Friday, November 04, 2016 12:41 AM +0000 openldap-its(a)OpenLDAP.org wrote: Here's the full text, since the web form apparently ate it: When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none However, when the unordered replaced is done, an incorrect result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=7" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=3" by * none olcAccess: {6}to dn.exact="cn=5" by * none olcAccess: {7}to dn.exact="cn=6" by * none Since we are doing a replace of all values, it should not be trying to reweight the operation. Instead, the values should just be numeric sorted and then written out accordingly, so one ends up with the same result as in the ordered case. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠openldap.org 03 Nov '16

03 Nov '16

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) When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7"yby * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: %7%7}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs:D%D olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none

1 0

Re: (ITS#8527) Improve logging for CSN issues
by quanah＠symas.com 02 Nov '16

02 Nov '16

--On Wednesday, November 02, 2016 10:37 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: > Does your patch require that every replica, even read-only consumer > replicas, have a serverID set? > No. --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#8527) Improve logging for CSN issues
by michael＠stroeder.com 02 Nov '16

02 Nov '16

This is a cryptographically signed message in MIME format. --------------ms080201070801050700040509 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Does your patch require that every replica, even read-only consumer repli= cas, have a serverID set? --------------ms080201070801050700040509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMjAzNzAxWjAvBgkq hkiG9w0BCQQxIgQgqjN8bhn2a5YoqT6i5ci/+E4Vh+WtF79GeKkm3krvAOgwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEATWiAjxefKHltpvMoNa7+5NSsae6EFG15s0nt5IbTWofgpjJLg70mH+TWm0tvJDIUrIYe L8Fu7DyLp64zDk3IpEzdWtqD3EOERZgrybkSs0ksMLml+hy+XEuJKIK/Gd+pH5v95ZKs1Mdp zbrnlGwZSLP9ZRJlQkuMHlEYwNVemakU+Hg+38UPOwPDR9piK+V+Y+nnhgqH/5Dswoo0MRyk F4ZBi33tFFQZT9qJfUV6RYfCRLlAMa8lA8koPJOBRsydlzhln1KVYVRTXE6oCEDhyinl5U3r rUYrYf4cFw70mXDIm+a0FEu+q+GHRUbKAJHPCE0jjIdYfvR9+VKtAsVPsgAAAAAAAA== --------------ms080201070801050700040509--

1 0

(ITS#8527) Improve logging for CSN issues
by quanah＠openldap.org 02 Nov '16

02 Nov '16

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) Unfortunately, it frequently is the case that a consumer CSN ends up ahead of the provider CSN. This can occur for a variety of reasons, but in the case of databases holding multiple CSNs from the same serverID (delta-syncrepl and subordinate databases are two examples of where this can be the case), the info spit out is somewhat lacking: Oct 28 15:49:55 XXXXXXX slapd[6463]: conn=1819162 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! It would be exceedingly useful to have better detail than this, so we can see the consumer CSN and the server CSN that are being compared. Something like: diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index f7e422d..c6ef4df 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -2654,6 +2654,11 @@ syncprov_op_search( Operation *op, SlapReply *rs ) /* our state is older, complain to consumer */ rs->sr_err = LDAP_UNWILLING_TO_PERFORM; rs->sr_text = "consumer state is newer than provider!"; + + Log4( LDAP_DEBUG_SYNC, LDAP_LEVEL_INFO, + "consumer %d state %s is newer than provider %d state %s\n", + sids[i], srs->sr_state.ctxcsn[i].bv_val, sids[j], /* == slap_serverID */ + ctxcsn[j].bv_val); bailout: if ( sop ) { syncops **sp = &si->si_ops;

1 0

Re: (ITS#8526) Slapd dies when subjected to heavy load
by michael＠stroeder.com 02 Nov '16

02 Nov '16

kwetlesen(a)mac.com wrote: > Full_Name: Kai M Wetlesen > Version: 2.4.40 > OS: RHEL 7.2 Maipo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.4.83.52) > > For some reason slapd crashes with a segmentation fault when subjected to a TLS > heavy connection load. It looks like the segmentation fault originates in > libnss3.so, It seems you're using the binary RPMs provided by RHEL. Those are linked to libnss and are furthermore heavily patched by Red Hat. Assuming you have a RHEL support contract you better file a RHEL bug report first. Ciao, Michael.

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠symas.com 01 Nov '16

01 Nov '16

--On Friday, May 15, 2015 7:53 PM +0000 quanah(a)zimbra.com wrote: Capturing what was discussed of this issue in IRC at the time: <hyc> too bad. yes, there is a case where a refresh can delete entries that shouldn't have been deleted <hyc> we discussed it here a month or so ago <hyc> but if all servers were in persist phase with delta, that shouldn't happen <JoBbZ> hm.. should have been out of refresh <JoBbZ> it did a refresh @ zimbra.log.30:May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> but that was hours before <hyc> and it was also behind by 1.5 hours <hyc> ... <JoBbZ> is there a message logged when refresh mode ends? <hyc> that's the message. <hyc> at least, that is the message from the provider that it's done sending refresh messages <hyc> then the consumer runs syncrepl_del_nonpresent based on the provider messages <JoBbZ> zimbra.log.30:May 1 18:37:33 zm-mmr01 slapd[43243]: syncrepl_del_nonpresent: rid=102 be_delete uid=skoelzer,ou=people,dc=unitedfiber,dc=email (0) <JoBbZ> to <JoBbZ> zimbra.log.30:May 1 18:37:35 zm-mmr01 slapd[43243]: syncrepl_del_nonpresent: rid=101 be_delete uid=fsodell2,ou=people,dc=ntin,dc=net (32) <JoBbZ> why would refresh mode end @ 14:146, and then 4 hours later, it does del_nonpresent? <hyc> it might have had a lot of refresh messages to parse <hyc> but 4 hours seems excessive, yeah <JoBbZ> but it was replicating during that time too <JoBbZ> May 1 15:00:00 zm-mmr01 slapd[43243]: syncrepl_message_to_op: rid=102 be_modify uid=gibbonsj,ou=people,dc=bevcomm,dc=net (0) <JoBbZ> for example <JoBbZ> but thousands and thousands <hyc> that's rid=102 <hyc> you were looking at rid=101 <JoBbZ> May 1 18:42:18 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:42:20 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> they both finished around the same time <hyc> this is 4way so where's the 3rd rid <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> hm <JoBbZ> this is interesting.. <JoBbZ> May 1 14:18:45 zm-mmr01 slapd[36133]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:19:59 zm-mmr01 slapd[36133]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:19:59 zm-mmr01 slapd[36133]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> so it did one sync then <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> another sync then <JoBbZ> a sync here <JoBbZ> May 1 18:37:34 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:37:35 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> and one at <JoBbZ> May 1 18:42:18 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:42:20 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> ugh <hyc> no rid=100 from the last 2? <JoBbZ> nope <JoBbZ> let me go look at the rid assignments rq <hyc> that's suspicious <JoBbZ> hm.. i bet it is losing connections <JoBbZ> 101/102 are in nashville <JoBbZ> 100 is in greenville, along with this server <JoBbZ> yeah, full fallback triggered at 18:37:04 <JoBbZ> sigh <JoBbZ> but this was a modrdn and an account add <JoBbZ> no deletes <hyc> was the Add the missing entry? <JoBbZ> yeah <hyc> yeah, that's the known issue then <JoBbZ> ok, what about the modrdn? <hyc> which isn't in an ITS so we should probably use the one you just filed <hyc> haven't thought about the modrdn but it's probably the same thing. <JoBbZ> ok <hyc> in refresh without syncprov sessionlog, the provider has to send the consumer a list of entryUUIDs of every entry that exists on the provider <hyc> the consumer then searches every entry in the consumer, compares to the list of entryUUIDs from the provider, and deletes any entry that's not in the provider's list <hyc> the problem is that an entry can be missing from this particular provider's list because its update was coming from a different provider <hyc> so it gets deleted even though it was properly received from the other provider <JoBbZ> ok, makes sense <hyc> if you have a syncprov sessionlog that's large enough to cover the span of disconnected time <hyc> then the provider sends a list of deleted entryUUIDs instead of present UUIDs <hyc> and this bug can't happen then --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