- openldap-bugs - openldap.org

(ITS#8376)
by michael＠stroeder.com 15 Apr '17

15 Apr '17

FWIW: The patch is still available here in openSUSE's package openldap2: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009-Fi…

1 0

Re: (ITS#8640) its#8376
by michael＠stroeder.com 15 Apr '17

15 Apr '17

Please close this misdirected ITS.

1 0

(ITS#8640) its#8376
by michael＠stroeder.com 15 Apr '17

15 Apr '17

This is a cryptographically signed message in MIME format. --------------ms030807090208090401070408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW: The patch is still available here in openSUSE's package openldap2: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009-= Fix-ldap-host-lookup-ipv6.patch?expand=3D1 --------------ms030807090208090401070408 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE1MTQyNDU3WjAvBgkq hkiG9w0BCQQxIgQgFhRhx9iESA/YCDrgJ8dfKmO1eXAhqmcC8/bqIucwChgwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAKh2NgTtieB7Vq00RQDGuWJk2AK0WOYIhyWWLmOn9kbmyL7ep0B+Qq5BIvtuW3LDPn96G Umg1RJWPW/rrcot2FTScqFjeYRRWdx7Pf4ow5+ukeyS67fn7x53bqaaRRd/baRjt2bHbaSZB zAvmFXQI5xgfNz2+m+bFacVkoQ7L7radHFrFe4DOWrDWlU6v4cn1nJGiMTd5a6mzusFLnSqW 3S8BBFbE3DlhJ3d8XF4blhwvDG69eF5kf4DCNB3QYAZ3xliWljlKWnf5DHIGz+CasJiH4D2h 898W9jStRcZE9R8tRAw7isKG9H2XdDoW0okuT6Aw2GYV4Xw24KStnbEr7AAAAAAAAA== --------------ms030807090208090401070408--

1 0

Re: (ITS#7585) LDAPI with GSSAPI does not work if SASL_NOCANON=on
by quanah＠symas.com 14 Apr '17

14 Apr '17

Hello, Thanks for the report. Unfortunately, your submission does not follow the ITS guidelines, meaning we can't really move forward with it at this time. Please read over <http://www.openldap.org/devel/contributing.html>, particularly the IPR notice requirements as well as patch submission requirements. If you can correct these issues, then the project can move forward with including your work in the project. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8639) Remove support for LANMAN
by quanah＠openldap.org 14 Apr '17

14 Apr '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) We should remove support for LANMAN hashes from OpenLDAP starting with the 2.5 release series.

1 0

Re: (ITS#8636) Invalid DESC for deltaCRL schema definition
by quanah＠symas.com 14 Apr '17

14 Apr '17

--On Thursday, April 13, 2017 9:58 AM +0000 james(a)turnersoft.co.uk wrote: > A more appropriate definition would be something like: > > DESC 'RFC2587: delta CRL' Technically RFC2587 has been obsoleted by RFC4523. It looks like the core schema file has never been appropriately updated to reflect this, however. RFC4523 has an explicit DESC field for deltaCRL that's probably better to use. Will discuss with the team to see what we want to do. --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#8638) Recursive mutex in libldap_r
by hyc＠symas.com 14 Apr '17

14 Apr '17

Ond=C5=99ej Kuzn=C3=ADk wrote: > On Fri, Apr 14, 2017 at 01:14:08PM +0000, hyc(a)symas.com wrote: >> okuznik(a)symas.com wrote: >>> Integrating with libevent, I would find it useful if libldap_r provid= ed a >>> recursive mutex as well, since this is what libevent uses. >> >> You mean libldap_r/rmutex.c ? > > Hmm, I see that now, but is quite heavy weight if this already exists i= n > many implementations natively, often at no cost at all. What if I > renamed the current ldap_pvt_*_rmutex_* functions to ldap_int_* and > deferred to them in the two implementations that can't do recursive > mutexes only? > > This would be an ABI break for rmutex users, other than that, there > seems to be no expectation that two versions of libldap_r compiled > against a different thread implementation should be ABI compatible > already. IMO using recursive mutexes means your code is broken. We introduced thes= e for=20 accesslog.c but in fact we could avoid them at zero cost. Also I don't se= e the=20 relevance of libevent to this discussion. We use our own event mechanism = and=20 it is more efficient than libevent. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by ondra＠mistotebe.net 14 Apr '17

14 Apr '17

On Fri, Apr 14, 2017 at 01:14:08PM +0000, hyc(a)symas.com wrote: > okuznik(a)symas.com wrote: >> Integrating with libevent, I would find it useful if libldap_r provided a >> recursive mutex as well, since this is what libevent uses. > > You mean libldap_r/rmutex.c ? Hmm, I see that now, but is quite heavy weight if this already exists in many implementations natively, often at no cost at all. What if I renamed the current ldap_pvt_*_rmutex_* functions to ldap_int_* and deferred to them in the two implementations that can't do recursive mutexes only? This would be an ABI break for rmutex users, other than that, there seems to be no expectation that two versions of libldap_r compiled against a different thread implementation should be ABI compatible already. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by hyc＠symas.com 14 Apr '17

14 Apr '17

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170414-libldap_r-recursive-… > Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) > > > Integrating with libevent, I would find it useful if libldap_r provided a > recursive mutex as well, since this is what libevent uses. You mean libldap_r/rmutex.c ? -- -- 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#8638) Recursive mutex in libldap_r
by okuznik＠symas.com 14 Apr '17

14 Apr '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170414-libldap_r-recursive-… Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) Integrating with libevent, I would find it useful if libldap_r provided a recursive mutex as well, since this is what libevent uses. Attached is an implementation. Platforms included: - POSIX (the only one I could test properly) - Win NT (regular mutexes, since they're recursive already, according to the docs) - GNU pth (same as NT, documentation says that all mutexes are recursive) - stub (noop) Not included: - thr_thr.c - not sure what that is - thr_cthreads.c - does not seem to support a recursive thread implementation I'm not sure who still uses the older platforms, I suppose only POSIX and Win NT are being used in the wild? Not that any users should be impacted by this since it's not referenced anywhere in the project yet.

1 0

Re: (ITS#8637) OpenLDAP crashing when defining multiple olcDbURI for chaining
by apgriffiths79＠gmail.com 13 Apr '17

13 Apr '17

--001a113cdaccc819cb054d0ea3dd Content-Type: text/plain; charset=UTF-8 Apologies, I'll avoid pastebin in future. Configuration is as follows: - dn: cn=module,cn=config changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: back_ldap.la dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDBURI: "ldap://aws-mldap-01.aws/,ldap://aws-mldap-02.aws/" olcDbIDAssertBind: bindmethod=simple binddn="cn=proxy,dc=abu,dc=inmarsat,dc=com" credentials=XXXXX mode=self dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcUpdateRef olcUpdateRef: ldap://aws-mldap-01.aws/ olcUpdateRef: ldap://aws-mldap-02.aws/ On 13 April 2017 at 16:01, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, April 13, 2017 1:06 PM +0000 apgriffiths79(a)gmail.com wrote: > > Full_Name: Alan Griffiths >> Version: 2.4.44 >> OS: Centos 7.3 >> URL: https://pastebin.com/CaVGpfKj >> Submission from: (NULL) (86.22.17.96) >> > > Pastebin's expire. Next time, please provide the information directly in > the ITS. > > I'd also suggest providing the slapd configuration etc that generated the > error. > > --Quanah > > 58ef6698 connection_get(16): got connid=1000 > 58ef6698 connection_read(16): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 588 contents: > 58ef6698 op tag 0x63, time 1492084376 > ber_get_next > 58ef6698 conn=1000 op=7 do_search > ber_scanf fmt ({miiiib) ber: > 58ef6698 >>> dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com> > 58ef6698 <<< dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com>, > <dc=abu,dc=inmarsat,dc=com> > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({mm}) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt ({mm}) ber: > ber_scanf fmt ({M}}) ber: > 58ef6698 ==> limits_get: conn=1000 op=7 self="[anonymous]" > this="dc=abu,dc=inmarsat,dc=com" > 58ef6698 => mdb_search > 58ef6698 mdb_dn2entry("dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x1 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 search_candidates: base="dc=abu,dc=inmarsat,dc=com" (0x00000001) > scope=2 > 58ef6698 => mdb_equality_candidates (objectClass) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read: failed (-30798) > 58ef6698 <= mdb_equality_candidates: id=0, first=0, last=0 > 58ef6698 => mdb_equality_candidates (uid) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read 1 candidates > 58ef6698 <= mdb_equality_candidates: id=1, first=17, last=17 > 58ef6698 => mdb_equality_candidates (objectClass) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read 1 candidates > 58ef6698 <= mdb_equality_candidates: id=1, first=17, last=17 > 58ef6698 => mdb_presence_candidates (uidNumber) > 58ef6698 <= mdb_presence_candidates: (uidNumber) not indexed > 58ef6698 mdb_search_candidates: id=1 first=17 last=17 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 => send_search_entry: conn 1000 dn="uid=test1,ou=people,dc=abu > ,dc=inmarsat,dc=com" > ber_flush2: 374 bytes to sd 16 > 58ef6698 <= send_search_entry: conn 1000 exit. > 58ef6698 send_ldap_result: conn=1000 op=7 p=3 > 58ef6698 send_ldap_response: msgid=8 tag=101 err=0 > ber_flush2: 14 bytes to sd 16 > 58ef6698 connection_get(16): got connid=1000 > 58ef6698 connection_read(16): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 254 contents: > 58ef6698 op tag 0x63, time 1492084376 > ber_get_next > 58ef6698 conn=1000 op=8 do_search > ber_scanf fmt ({miiiib) ber: > 58ef6698 >>> dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com> > 58ef6698 <<< dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com>, > <dc=abu,dc=inmarsat,dc=com> > ber_scanf fmt ({mm}) ber: > 58ef6698 >>> dnPretty: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > 58ef6698 <<< dnPretty: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > 58ef6698 >>> dnNormalize: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > 58ef6698 <<< dnNormalize: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > ber_scanf fmt ({mm}) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > 58ef6698 => get_ctrls > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > 58ef6698 => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) > ber_scanf fmt ({im}) ber: > 58ef6698 <= get_ctrls: n=1 rc=0 err="" > 58ef6698 ==> limits_get: conn=1000 op=8 self="[anonymous]" > this="dc=abu,dc=inmarsat,dc=com" > 58ef6698 => mdb_search > 58ef6698 mdb_dn2entry("dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x1 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 search_candidates: base="dc=abu,dc=inmarsat,dc=com" (0x00000001) > scope=2 > 58ef6698 => mdb_equality_candidates (objectClass) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read: failed (-30798) > 58ef6698 <= mdb_equality_candidates: id=0, first=0, last=0 > 58ef6698 => mdb_equality_candidates (member) > 58ef6698 <= mdb_equality_candidates: (member) not indexed > 58ef6698 => mdb_equality_candidates (objectClass) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read 1 candidates > 58ef6698 <= mdb_equality_candidates: id=1, first=16, last=16 > 58ef6698 => mdb_presence_candidates (cn) > 58ef6698 => key_read > 58ef6698 <= mdb_index_read 12 candidates > 58ef6698 <= mdb_presence_candidates: id=12 first=2 last=20 > 58ef6698 mdb_search_candidates: id=1 first=16 last=16 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 mdb_search: 16 does not match filter > 58ef6698 send_ldap_result: conn=1000 op=8 p=3 > 58ef6698 send_ldap_response: msgid=9 tag=101 err=0 > ber_flush2: 51 bytes to sd 16 > 58ef6698 slap_listener_activate(7): > 58ef6698 >>> slap_listener(ldap:///) > 58ef6698 connection_get(17): got connid=1002 > 58ef6698 connection_read(17): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 29 contents: > 58ef6698 op tag 0x77, time 1492084376 > ber_get_next > 58ef6698 conn=1002 op=0 do_extended > ber_scanf fmt ({m) ber: > 58ef6698 send_ldap_extended: err=0 oid= len=0 > 58ef6698 send_ldap_response: msgid=1 tag=120 err=0 > ber_flush2: 14 bytes to sd 17 > 58ef6698 connection_get(17): got connid=1002 > 58ef6698 connection_read(17): checking for input on id=1002 > 58ef6698 connection_get(17): got connid=1002 > 58ef6698 connection_read(17): checking for input on id=1002 > TLS certificate verification: subject: no certificate, issuer: no > certificate, cipher: AES-256, security level: high, secret key bits: 256, > total key bits: 256, cache hits: 0, cache misses: 3, cache not reusable: 0 > 58ef6698 connection_read(17): unable to get TLS client DN, error=49 id=1002 > 58ef6698 connection_get(17): got connid=1002 > 58ef6698 connection_read(17): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 93 contents: > 58ef6698 op tag 0x60, time 1492084376 > ber_get_next > 58ef6698 conn=1002 op=1 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > 58ef6698 => get_ctrls > ber_scanf fmt ({m) ber: > 58ef6698 => get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) > 58ef6698 <= get_ctrls: n=1 rc=0 err="" > 58ef6698 >>> dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc > =inmarsat,dc=com> > 58ef6698 <<< dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com>, > <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > 58ef6698 do_bind: version=3 dn="uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com" > method=128 > 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x11 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 mdb_entry_get: rc=0 > 58ef6698 mdb_dn2entry("cn=test,dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("cn=test,dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x12 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 mdb_entry_get: rc=0 > 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x11 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 send_ldap_result: conn=1002 op=1 p=3 > 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") > 58ef6698 <= mdb_dn2id: got id=0x11 > 58ef6698 => mdb_entry_decode: > 58ef6698 <= mdb_entry_decode > 58ef6698 mdb_entry_get: rc=0 > ldap_url_parse_ext(ldap://aws-mldap-01.aws/) > ldap_url_parse_ext(ldap://aws-mldap-02.aws/) > 58ef6698 send_ldap_result: conn=1002 op=1 p=3 > ldap_url_parse_ext(ldap://aws-mldap-01.aws/uid=test1,ou=peop > le,dc=abu,dc=inmarsat,dc=com) > 58ef6698 >>> dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc > =inmarsat,dc=com> > 58ef6698 <<< dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com>, > <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> > 58ef6698 conn=1002 op=1 ldap_chain_op: ref="ldap://aws-mldap-01.aws/u > id=test1,ou=people,dc=abu,dc=inmarsat,dc=com" -> "ldap://aws-mldap-01.aws" > slapd: chain.c:227: ldap_chain_uri_cmp: Assertion `((&li2->li_bvuri[ 1 > ])->bv_val == ((void *)0))' failed. > Aborted > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --001a113cdaccc819cb054d0ea3dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Apologies, I'll avoid pastebin in future. = </div>Configuration is as follows: - dn: cn=3Dmodule,cn=3Dconfig changetype: add objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: <a href=3D"http://back_ldap.la">back_ldap.la</a> dn: olcOverlay=3D{0}chain,olcDatabase=3D{-1}frontend,cn=3Dconfi= g changetype: add objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain =C2=A0 dn: olcDatabase=3Dldap,olcOverlay=3D{0}chain,olcDatabase= =3D{-1}frontend,cn=3Dconfig changetype: add objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDBURI: "ldap://aws-mldap-01.aws/,ldap://aws-mldap-02.aws/" olcDbIDAssertBind: bindmethod=3Dsimple =C2=A0 binddn=3D"cn=3Dproxy,dc=3Dabu,dc=3Dinmarsat,dc=3Dcom" =C2=A0 credentials=3DXXXXX =C2=A0 mode=3Dself dn: olcDatabase=3D{2}mdb,cn=3Dconfig changetype: modify replace: olcUpdateRef olcUpdateRef: ldap://aws-mldap-01.aws/ olcUpdateRef: ldap://aws-mldap-02.aws/ </div><div class=3D"gmail_ext= ra"> <div class=3D"gmail_quote">On 13 April 2017 at 16:01, Quanah Gibson= -Mount <<a href=3D"mailto:quanah@symas.com" target=3D"= _blank">quanah(a)symas.com</a>> wrote: <blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex">--On Thursday, April 13, 2017 1:06 PM +0000 <a href=3D"mailto:apgriff= iths79(a)gmail.com" target=3D"_blank">apgriffiths79(a)gmail.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Alan Griffiths Version: 2.4.44 OS: Centos 7.3 URL: <a href=3D"https://pastebin.com/CaVGpfKj" rel=3D"noreferrer" target=3D= "_blank">https://pastebin.com/CaVGpfKj</a> Submission from: (NULL) (86.22.17.96) </blockquote> Pastebin's expire.=C2=A0 Next time, please provide the information dire= ctly in the ITS. I'd also suggest providing the slapd configuration etc that generated t= he error. --Quanah 58ef6698 connection_get(16): got connid=3D1000 58ef6698 connection_read(16): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 588 contents: 58ef6698 op tag 0x63, time 1492084376 ber_get_next 58ef6698 conn=3D1000 op=3D7 do_search ber_scanf fmt ({miiiib) ber: 58ef6698 >>> dnPrettyNormal: <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom&g= t; 58ef6698 <<< dnPrettyNormal: <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom&g= t;, <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: 58ef6698 =3D=3D> limits_get: conn=3D1000 op=3D7 self=3D"[anonymous]= " this=3D"dc=3Dabu,dc=3Dinmarsat,dc=3Dcom" 58ef6698 =3D> mdb_search 58ef6698 mdb_dn2entry("dc=3Dabu,dc=3Dinmarsat,dc=3Dcom") 58ef6698 =3D> mdb_dn2id("dc=3Dabu,dc=3Dinmarsat,dc=3Dcom"= ) 58ef6698 <=3D mdb_dn2id: got id=3D0x1 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 search_candidates: base=3D"dc=3Dabu,dc=3Dinmarsat,dc=3Dco<wbr= >m" (0x00000001) scope=3D2 58ef6698 =3D> mdb_equality_candidates (objectClass) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read: failed (-30798) 58ef6698 <=3D mdb_equality_candidates: id=3D0, first=3D0, last=3D0 58ef6698 =3D> mdb_equality_candidates (uid) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read 1 candidates 58ef6698 <=3D mdb_equality_candidates: id=3D1, first=3D17, last=3D17 58ef6698 =3D> mdb_equality_candidates (objectClass) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read 1 candidates 58ef6698 <=3D mdb_equality_candidates: id=3D1, first=3D17, last=3D17 58ef6698 =3D> mdb_presence_candidates (uidNumber) 58ef6698 <=3D mdb_presence_candidates: (uidNumber) not indexed 58ef6698 mdb_search_candidates: id=3D1 first=3D17 last=3D17 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 =3D> send_search_entry: conn 1000 dn=3D"uid=3Dtest1,ou=3Dp= eople,dc=3Dabu,dc=3Dinmarsat,dc=3Dcom" ber_flush2: 374 bytes to sd 16 58ef6698 <=3D send_search_entry: conn 1000 exit. 58ef6698 send_ldap_result: conn=3D1000 op=3D7 p=3D3 58ef6698 send_ldap_response: msgid=3D8 tag=3D101 err=3D0 ber_flush2: 14 bytes to sd 16 58ef6698 connection_get(16): got connid=3D1000 58ef6698 connection_read(16): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 254 contents: 58ef6698 op tag 0x63, time 1492084376 ber_get_next 58ef6698 conn=3D1000 op=3D8 do_search ber_scanf fmt ({miiiib) ber: 58ef6698 >>> dnPrettyNormal: <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom&g= t; 58ef6698 <<< dnPrettyNormal: <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom&g= t;, <dc=3Dabu,dc=3Dinmarsat,dc=3Dcom> ber_scanf fmt ({mm}) ber: 58ef6698 >>> dnPretty: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<wbr= >=3Dinmarsat,dc=3Dcom> 58ef6698 <<< dnPretty: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<wbr= >=3Dinmarsat,dc=3Dcom> 58ef6698 >>> dnNormalize: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<= wbr>=3Dinmarsat,dc=3Dcom> 58ef6698 <<< dnNormalize: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<= wbr>=3Dinmarsat,dc=3Dcom> ber_scanf fmt ({mm}) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 58ef6698 =3D> get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: 58ef6698 =3D> get_ctrls: oid=3D"1.2.840.113556.1.4.319" (noncr= itical) ber_scanf fmt ({im}) ber: 58ef6698 <=3D get_ctrls: n=3D1 rc=3D0 err=3D"" 58ef6698 =3D=3D> limits_get: conn=3D1000 op=3D8 self=3D"[anonymous]= " this=3D"dc=3Dabu,dc=3Dinmarsat,dc=3Dcom" 58ef6698 =3D> mdb_search 58ef6698 mdb_dn2entry("dc=3Dabu,dc=3Dinmarsat,dc=3Dcom") 58ef6698 =3D> mdb_dn2id("dc=3Dabu,dc=3Dinmarsat,dc=3Dcom"= ) 58ef6698 <=3D mdb_dn2id: got id=3D0x1 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 search_candidates: base=3D"dc=3Dabu,dc=3Dinmarsat,dc=3Dco<wbr= >m" (0x00000001) scope=3D2 58ef6698 =3D> mdb_equality_candidates (objectClass) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read: failed (-30798) 58ef6698 <=3D mdb_equality_candidates: id=3D0, first=3D0, last=3D0 58ef6698 =3D> mdb_equality_candidates (member) 58ef6698 <=3D mdb_equality_candidates: (member) not indexed 58ef6698 =3D> mdb_equality_candidates (objectClass) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read 1 candidates 58ef6698 <=3D mdb_equality_candidates: id=3D1, first=3D16, last=3D16 58ef6698 =3D> mdb_presence_candidates (cn) 58ef6698 =3D> key_read 58ef6698 <=3D mdb_index_read 12 candidates 58ef6698 <=3D mdb_presence_candidates: id=3D12 first=3D2 last=3D20 58ef6698 mdb_search_candidates: id=3D1 first=3D16 last=3D16 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 mdb_search: 16 does not match filter 58ef6698 send_ldap_result: conn=3D1000 op=3D8 p=3D3 58ef6698 send_ldap_response: msgid=3D9 tag=3D101 err=3D0 ber_flush2: 51 bytes to sd 16 58ef6698 slap_listener_activate(7): 58ef6698 >>> slap_listener(ldap:///) 58ef6698 connection_get(17): got connid=3D1002 58ef6698 connection_read(17): checking for input on id=3D1002 ber_get_next ber_get_next: tag 0x30 len 29 contents: 58ef6698 op tag 0x77, time 1492084376 ber_get_next 58ef6698 conn=3D1002 op=3D0 do_extended ber_scanf fmt ({m) ber: 58ef6698 send_ldap_extended: err=3D0 oid=3D len=3D0 58ef6698 send_ldap_response: msgid=3D1 tag=3D120 err=3D0 ber_flush2: 14 bytes to sd 17 58ef6698 connection_get(17): got connid=3D1002 58ef6698 connection_read(17): checking for input on id=3D1002 58ef6698 connection_get(17): got connid=3D1002 58ef6698 connection_read(17): checking for input on id=3D1002 TLS certificate verification: subject: no certificate, issuer: no certifica= te, cipher: AES-256, security level: high, secret key bits: 256, total key = bits: 256, cache hits: 0, cache misses: 3, cache not reusable: 0 58ef6698 connection_read(17): unable to get TLS client DN, error=3D49 id=3D= 1002 58ef6698 connection_get(17): got connid=3D1002 58ef6698 connection_read(17): checking for input on id=3D1002 ber_get_next ber_get_next: tag 0x30 len 93 contents: 58ef6698 op tag 0x60, time 1492084376 ber_get_next 58ef6698 conn=3D1002 op=3D1 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: 58ef6698 =3D> get_ctrls ber_scanf fmt ({m) ber: 58ef6698 =3D> get_ctrls: oid=3D"1.3.6.1.4.1.42.2.27.8.5.1&quot= ; (noncritical) 58ef6698 <=3D get_ctrls: n=3D1 rc=3D0 err=3D"" 58ef6698 >>> dnPrettyNormal: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,= dc=3Dinmarsat,dc=3Dcom> 58ef6698 <<< dnPrettyNormal: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,= dc=3Dinmarsat,dc=3Dcom>, <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<wb= r>=3Dinmarsat,dc=3Dcom> 58ef6698 do_bind: version=3D3 dn=3D"uid=3Dtest1,ou=3Dpeople,dc=3Dabu<w= br>,dc=3Dinmarsat,dc=3Dcom" method=3D128 58ef6698 mdb_dn2entry("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc=3Dinma= rsat,dc=3Dcom") 58ef6698 =3D> mdb_dn2id("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc= =3Dinmarsat,dc=3Dcom") 58ef6698 <=3D mdb_dn2id: got id=3D0x11 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 mdb_entry_get: rc=3D0 58ef6698 mdb_dn2entry("cn=3Dtest,dc=3Dabu,dc=3Dinmarsat,dc=3Dcom&= quot;) 58ef6698 =3D> mdb_dn2id("cn=3Dtest,dc=3Dabu,dc=3Dinmarsat,dc= =3Dcom") 58ef6698 <=3D mdb_dn2id: got id=3D0x12 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 mdb_entry_get: rc=3D0 58ef6698 mdb_dn2entry("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc=3Dinma= rsat,dc=3Dcom") 58ef6698 =3D> mdb_dn2id("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc= =3Dinmarsat,dc=3Dcom") 58ef6698 <=3D mdb_dn2id: got id=3D0x11 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 send_ldap_result: conn=3D1002 op=3D1 p=3D3 58ef6698 mdb_dn2entry("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc=3Dinma= rsat,dc=3Dcom") 58ef6698 =3D> mdb_dn2id("uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc= =3Dinmarsat,dc=3Dcom") 58ef6698 <=3D mdb_dn2id: got id=3D0x11 58ef6698 =3D> mdb_entry_decode: 58ef6698 <=3D mdb_entry_decode 58ef6698 mdb_entry_get: rc=3D0 ldap_url_parse_ext(ldap://aws-mldap-01.aws/) ldap_url_parse_ext(ldap://aws-mldap-02.aws/) 58ef6698 send_ldap_result: conn=3D1002 op=3D1 p=3D3 ldap_url_parse_ext(ldap://aws-mldap-01.aws/uid=3Dtest1,ou=3Dpeopl= e,dc=3Dabu,dc=3Dinmarsat,dc=3Dcom) 58ef6698 >>> dnPrettyNormal: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,= dc=3Dinmarsat,dc=3Dcom> 58ef6698 <<< dnPrettyNormal: <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,= dc=3Dinmarsat,dc=3Dcom>, <uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc<wb= r>=3Dinmarsat,dc=3Dcom> 58ef6698 conn=3D1002 op=3D1 ldap_chain_op: ref=3D"ldap://aws-mldap-01.= aws/uid=3Dtest1,ou=3Dpeople,dc=3Dabu,dc=3Dinmarsat,dc=3Dcom"= -> "ldap://aws-mldap-01.aws" slapd: chain.c:227: ldap_chain_uri_cmp: Assertion `((&li2->li_bvuri[= 1 ])->bv_val =3D=3D ((void *)0))' failed. Aborted -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>> </blockquote></div> </div> --001a113cdaccc819cb054d0ea3dd--

1 0

Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by quanah＠symas.com 13 Apr '17

13 Apr '17

Hello Venkatesh, There's been no follow up since 2012, so I will be closing this ITS. I assume the issue was resolved by downgrading BDB. If you still encounter this issue with the current OpenLDAP release, feel free to follow up and I will reopen the ITS. Regards, 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#8637) OpenLDAP crashing when defining multiple olcDbURI for chaining
by quanah＠symas.com 13 Apr '17

13 Apr '17

--On Thursday, April 13, 2017 1:06 PM +0000 apgriffiths79(a)gmail.com wrote: > Full_Name: Alan Griffiths > Version: 2.4.44 > OS: Centos 7.3 > URL: https://pastebin.com/CaVGpfKj > Submission from: (NULL) (86.22.17.96) Pastebin's expire. Next time, please provide the information directly in the ITS. I'd also suggest providing the slapd configuration etc that generated the error. --Quanah 58ef6698 connection_get(16): got connid=1000 58ef6698 connection_read(16): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 588 contents: 58ef6698 op tag 0x63, time 1492084376 ber_get_next 58ef6698 conn=1000 op=7 do_search ber_scanf fmt ({miiiib) ber: 58ef6698 >>> dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com>, <dc=abu,dc=inmarsat,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({mm}) ber: ber_scanf fmt ({M}}) ber: 58ef6698 ==> limits_get: conn=1000 op=7 self="[anonymous]" this="dc=abu,dc=inmarsat,dc=com" 58ef6698 => mdb_search 58ef6698 mdb_dn2entry("dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x1 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 search_candidates: base="dc=abu,dc=inmarsat,dc=com" (0x00000001) scope=2 58ef6698 => mdb_equality_candidates (objectClass) 58ef6698 => key_read 58ef6698 <= mdb_index_read: failed (-30798) 58ef6698 <= mdb_equality_candidates: id=0, first=0, last=0 58ef6698 => mdb_equality_candidates (uid) 58ef6698 => key_read 58ef6698 <= mdb_index_read 1 candidates 58ef6698 <= mdb_equality_candidates: id=1, first=17, last=17 58ef6698 => mdb_equality_candidates (objectClass) 58ef6698 => key_read 58ef6698 <= mdb_index_read 1 candidates 58ef6698 <= mdb_equality_candidates: id=1, first=17, last=17 58ef6698 => mdb_presence_candidates (uidNumber) 58ef6698 <= mdb_presence_candidates: (uidNumber) not indexed 58ef6698 mdb_search_candidates: id=1 first=17 last=17 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 => send_search_entry: conn 1000 dn="uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com" ber_flush2: 374 bytes to sd 16 58ef6698 <= send_search_entry: conn 1000 exit. 58ef6698 send_ldap_result: conn=1000 op=7 p=3 58ef6698 send_ldap_response: msgid=8 tag=101 err=0 ber_flush2: 14 bytes to sd 16 58ef6698 connection_get(16): got connid=1000 58ef6698 connection_read(16): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 254 contents: 58ef6698 op tag 0x63, time 1492084376 ber_get_next 58ef6698 conn=1000 op=8 do_search ber_scanf fmt ({miiiib) ber: 58ef6698 >>> dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnPrettyNormal: <dc=abu,dc=inmarsat,dc=com>, <dc=abu,dc=inmarsat,dc=com> ber_scanf fmt ({mm}) ber: 58ef6698 >>> dnPretty: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnPretty: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 >>> dnNormalize: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnNormalize: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> ber_scanf fmt ({mm}) ber: ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: 58ef6698 => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: 58ef6698 => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: 58ef6698 <= get_ctrls: n=1 rc=0 err="" 58ef6698 ==> limits_get: conn=1000 op=8 self="[anonymous]" this="dc=abu,dc=inmarsat,dc=com" 58ef6698 => mdb_search 58ef6698 mdb_dn2entry("dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x1 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 search_candidates: base="dc=abu,dc=inmarsat,dc=com" (0x00000001) scope=2 58ef6698 => mdb_equality_candidates (objectClass) 58ef6698 => key_read 58ef6698 <= mdb_index_read: failed (-30798) 58ef6698 <= mdb_equality_candidates: id=0, first=0, last=0 58ef6698 => mdb_equality_candidates (member) 58ef6698 <= mdb_equality_candidates: (member) not indexed 58ef6698 => mdb_equality_candidates (objectClass) 58ef6698 => key_read 58ef6698 <= mdb_index_read 1 candidates 58ef6698 <= mdb_equality_candidates: id=1, first=16, last=16 58ef6698 => mdb_presence_candidates (cn) 58ef6698 => key_read 58ef6698 <= mdb_index_read 12 candidates 58ef6698 <= mdb_presence_candidates: id=12 first=2 last=20 58ef6698 mdb_search_candidates: id=1 first=16 last=16 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 mdb_search: 16 does not match filter 58ef6698 send_ldap_result: conn=1000 op=8 p=3 58ef6698 send_ldap_response: msgid=9 tag=101 err=0 ber_flush2: 51 bytes to sd 16 58ef6698 slap_listener_activate(7): 58ef6698 >>> slap_listener(ldap:///) 58ef6698 connection_get(17): got connid=1002 58ef6698 connection_read(17): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 29 contents: 58ef6698 op tag 0x77, time 1492084376 ber_get_next 58ef6698 conn=1002 op=0 do_extended ber_scanf fmt ({m) ber: 58ef6698 send_ldap_extended: err=0 oid= len=0 58ef6698 send_ldap_response: msgid=1 tag=120 err=0 ber_flush2: 14 bytes to sd 17 58ef6698 connection_get(17): got connid=1002 58ef6698 connection_read(17): checking for input on id=1002 58ef6698 connection_get(17): got connid=1002 58ef6698 connection_read(17): checking for input on id=1002 TLS certificate verification: subject: no certificate, issuer: no certificate, cipher: AES-256, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 3, cache not reusable: 0 58ef6698 connection_read(17): unable to get TLS client DN, error=49 id=1002 58ef6698 connection_get(17): got connid=1002 58ef6698 connection_read(17): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 93 contents: 58ef6698 op tag 0x60, time 1492084376 ber_get_next 58ef6698 conn=1002 op=1 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: 58ef6698 => get_ctrls ber_scanf fmt ({m) ber: 58ef6698 => get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) 58ef6698 <= get_ctrls: n=1 rc=0 err="" 58ef6698 >>> dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com>, <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 do_bind: version=3 dn="uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com" method=128 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x11 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 mdb_entry_get: rc=0 58ef6698 mdb_dn2entry("cn=test,dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("cn=test,dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x12 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 mdb_entry_get: rc=0 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x11 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 send_ldap_result: conn=1002 op=1 p=3 58ef6698 mdb_dn2entry("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 => mdb_dn2id("uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com") 58ef6698 <= mdb_dn2id: got id=0x11 58ef6698 => mdb_entry_decode: 58ef6698 <= mdb_entry_decode 58ef6698 mdb_entry_get: rc=0 ldap_url_parse_ext(ldap://aws-mldap-01.aws/) ldap_url_parse_ext(ldap://aws-mldap-02.aws/) 58ef6698 send_ldap_result: conn=1002 op=1 p=3 ldap_url_parse_ext(ldap://aws-mldap-01.aws/uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com) 58ef6698 >>> dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 <<< dnPrettyNormal: <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com>, <uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com> 58ef6698 conn=1002 op=1 ldap_chain_op: ref="ldap://aws-mldap-01.aws/uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com" -> "ldap://aws-mldap-01.aws" slapd: chain.c:227: ldap_chain_uri_cmp: Assertion `((&li2->li_bvuri[ 1 ])->bv_val == ((void *)0))' failed. Aborted -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8637) OpenLDAP crashing when defining multiple olcDbURI for chaining
by apgriffiths79＠gmail.com 13 Apr '17

13 Apr '17

Full_Name: Alan Griffiths Version: 2.4.44 OS: Centos 7.3 URL: https://pastebin.com/CaVGpfKj Submission from: (NULL) (86.22.17.96) Adding multiple entries to olcDbURI causes slapd to crash when the ref is first followed with: - 8ef6698 conn=1002 op=1 ldap_chain_op: ref="ldap://aws-mldap-01.aws/uid=test1,ou=people,dc=abu,dc=inmarsat,dc=com" -> "ldap://aws-mldap-01.aws" slapd: chain.c:227: ldap_chain_uri_cmp: Assertion `((&li2->li_bvuri[ 1 ])->bv_val == ((void *)0))' failed. Aborted This appears to be the same issue as reported here http://www.openldap.org/lists/openldap-technical/201409/msg00056.html but in a more recent version. I can re-create in 2.4.40 and 2.4.44. Link to full debug output is provided.

1 0

(ITS#8636) Invalid DESC for deltaCRL schema definition
by james＠turnersoft.co.uk 13 Apr '17

13 Apr '17

Full_Name: James Turner Version: 2.4.42 OS: Ubuntu 16.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.86.27.193) The schema definition for 'deltaCRL' includes: DESC 'RFC2587: PKI user' This class does not represent a user - the text may have been copied/pasted from pkiUser (which appears a few definitions above it in the same files). A more appropriate definition would be something like: DESC 'RFC2587: delta CRL' Affected files: servers/slapd/schema/core.ldif servers/slapd/schema/core.schema

1 0

Re: (ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by quanah＠symas.com 12 Apr '17

12 Apr '17

Hi Michael, I'm going to assume this issue was fixed in 2.4.29 with the fix for ITS#7113. If that's not the case, please follow up. I will close this ITS in the meantime. Regards, 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#6919) "Weekly" crashes of OpenLDAP 2.4.22 using syncrepl master/master
by quanah＠symas.com 12 Apr '17

12 Apr '17

Hi Jarl, Apologies for the delay in response. Do you still experience this issue in curent OpenLDAP releases? Numerous fixes have been made to MMR since your report was originally filed. I will close the ITS for now, but if you still are encountering this issue, feel free to follow up so it can be correcty triaged this time. Thanks, 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#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by quanah＠symas.com 12 Apr '17

12 Apr '17

--On Monday, April 10, 2017 9:36 AM +0000 daniel(a)pluta.biz wrote: > Although I know that I'm highly probable not directly addressed by the > question "For 2.5?" (see this its's notes), my answer/comment would be > "Yes", even "Yes, of course.": Hi Daniel, It's just a note to myself to discuss with Howard for possible inclusion in 2.5. ;) I'm going through all the incoming ITSes and sorting them out and setting priority, etc, as that's been neglected for a while. --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#7010) Deadlock in Producer/Consumer Nodes
by quanah＠symas.com 12 Apr '17

12 Apr '17

Hello, Sorry for the delay in response. I believe this issue has been resolved since the 2.4.25 release. If you can reproduce this issue with the current OpenLDAP release, please follow up. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8635) serverID doc updates (0 is single master only)
by quanah＠openldap.org 11 Apr '17

11 Apr '17

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) The man page for serverID says: serverID <integer> [<URL>] Specify an integer ID from 0 to 4095 for this server (limited to 3 hexadecimal digits). The ID may also be specified as a hexadecimal ID by prefixing the value with "0x". These IDs are required when using multimaster replication and each master must have a unique ID. Note that this requirement also applies to separate masters contributing to a glued set of databases. If the URL is provided, this directive may be specified multiple times, providing a complete list of participating servers and their IDs. The fully qualified hostname of each server should be used in the supplied URLs. The IDs are used in the "replica id" field of all CSNs generated by the specified server. The default value is zero. Example: serverID 1 However, it does not specifically note that serverID 0 is reserved for single master only, and that in MMR & Mirror mode configurations, serverIDs must be 1 and higher. The admin guide likely needs similar updating.

1 0

Re: (ITS#8553) LMDB Windows UWP Patch
by smlu＠siol.net 11 Apr '17

11 Apr '17

--Apple-Mail-8F7C74A8-5883-40EA-8779-CC1CBCA62884 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The patch was uploaded to ftp.openldap.org/incoming. However it was also upl= oaded to github: https://github.com/ZeroPass/lmdb/blob/mdb.master/mdb_uwp_pa= tch.diff On 10. apr. 2017, at 15:40, Howard Chu <openldap-its(a)OpenLDAP.org> wrote: > I see no patch filename or URL in this ticket. >=20 >=20 --Apple-Mail-8F7C74A8-5883-40EA-8779-CC1CBCA62884 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>The patch was uploaded to <a href="http://ftp.openldap.org/incoming">ftp.openldap.org/incoming</a>. However it was also uploaded to github: <a href="https://github.com/ZeroPass/lmdb/blob/mdb.master/mdb_uwp_patch.diff">https://github.com/ZeroPass/lmdb/blob/mdb.master/mdb_uwp_patch.diff</a></div><div> On 10. apr. 2017, at 15:40, Howard Chu <<a href="mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a>> wrote: </div><blockquote type="cite"><div>I see no patch filename or URL in this ticket. </div></blockquote></body></html> --Apple-Mail-8F7C74A8-5883-40EA-8779-CC1CBCA62884--

1 0

Re: (ITS#8634) OpenLDAP fails to build against OpenSSL 1.1
by michael＠stroeder.com 10 Apr '17

10 Apr '17

quanah(a)symas.com wrote: > Perhaps we should use this ITS to track removal of this code entirely from OpenLDAP. +1 Ciao, Michael.

1 0

Re: (ITS#8634) OpenLDAP fails to build against OpenSSL 1.1
by quanah＠symas.com 10 Apr '17

10 Apr '17

Perhaps we should use this ITS to track removal of this code entirely from O= penLDAP.=20 > On Apr 10, 2017, at 12:54 PM, hyc(a)symas.com wrote: >=20 > hristo(a)venev.name wrote: >> Full_Name: Hristo Venev >> Version: Unreleased Release Candidate 2.4.45 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (95.111.59.55) >>=20 >>=20 >> Another user of the old DES API. Here's a patch (compiles, not tested): >=20 > Thanks. Looks like you're compiling the old NT/LANMAN password hash suppor= t.=20 > Nobody should still be using that code, LANMAN hashes are trivially cracka= ble=20 > on modern GPUs. >>=20 >> diff --git a/libraries/liblutil/passwd.c b/libraries/liblutil/passwd.c >> index 7aab344..c481326 100644 >> --- a/libraries/liblutil/passwd.c >> +++ b/libraries/liblutil/passwd.c >> @@ -38,9 +38,9 @@ >> # include <openssl/des.h> >>=20 >>=20 >> -typedef des_cblock des_key; >> -typedef des_cblock des_data_block; >> -typedef des_key_schedule des_context; >> +typedef DES_cblock des_key; >> +typedef DES_cblock des_data_block; >> +typedef DES_key_schedule des_context[1]; >> #define des_failed(encrypted) 0 >> #define des_finish(key, schedule) >>=20 >> @@ -667,7 +667,7 @@ static void >> des_set_key_and_parity( des_key *key, unsigned char *keyData) >> { >> memcpy(key, keyData, 8); >> - des_set_odd_parity( key ); >> + DES_set_odd_parity( key ); >> } >>=20 >>=20 >> @@ -699,7 +699,7 @@ des_set_key_and_parity( des_key *key, unsigned char >> *keyData) >> } >>=20 >> static void >> -des_set_key_unchecked( des_key *key, des_context ctxt ) >> +DES_set_key_unchecked( des_key *key, des_context ctxt ) >> { >> ctxt[0] =3D NULL; >>=20 >> @@ -712,7 +712,7 @@ des_set_key_unchecked( des_key *key, des_context ctxt= ) >> } >>=20 >> static void >> -des_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, >> +DES_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, >> des_context ctxt, int op) >> { >> SECStatus rv; >> @@ -864,16 +864,16 @@ static int chk_lanman( >> ldap_pvt_str2upper( UcasePassword ); >> =20 >> lmPasswd_to_key( UcasePassword, &key ); >> - des_set_key_unchecked( &key, schedule ); >> - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT );= >> + DES_set_key_unchecked( &key, schedule ); >> + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT );= >>=20 >> if (des_failed(&PasswordHash1)) { >> return LUTIL_PASSWD_ERR; >> } >> =20 >> lmPasswd_to_key( &UcasePassword[7], &key ); >> - des_set_key_unchecked( &key, schedule ); >> - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT );= >> + DES_set_key_unchecked( &key, schedule ); >> + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT );= >> if (des_failed(&PasswordHash2)) { >> return LUTIL_PASSWD_ERR; >> } >> @@ -1160,12 +1160,12 @@ static int hash_lanman( >> ldap_pvt_str2upper( UcasePassword ); >> =20 >> lmPasswd_to_key( UcasePassword, &key ); >> - des_set_key_unchecked( &key, schedule ); >> - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT );= >> + DES_set_key_unchecked( &key, schedule ); >> + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT );= >> =20 >> lmPasswd_to_key( &UcasePassword[7], &key ); >> - des_set_key_unchecked( &key, schedule ); >> - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT );= >> + DES_set_key_unchecked( &key, schedule ); >> + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT );= >> =20 >> sprintf( PasswordHash, >> "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x", >> PasswordHash1[0],PasswordHash1[1],PasswordHash1[2],PasswordHash1[3= ], >>=20 >>=20 >>=20 >=20 >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20 >=20

1 0

(ITS#8634)
by hristo＠venev.name 10 Apr '17

10 Apr '17

--=-n5oNLAt610/+F66WtjjW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I know. I'm trying to create a package for Fedora and there lmhash is enabled. --=-n5oNLAt610/+F66WtjjW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEETdMrh1lhmLmNEKGzzwXo0E3DKboFAljr5DYACgkQzwXo0E3D KbpI2BAAjEu5s3DHLz++h2v2BJL5hpSdSJw32hyHbEgIVx6m/ZDmvJ5NFqF4sBSr /NiBmxWepEkjvHS4Reqywg5nnE6s0fpc6OhBkI9mFG2fQ+s9DEoyxhUEcGMJiFKw GOM0lupyZ39slu3mwnBwwq37gDEqV96iPtXFIJayWfIkOw1yzZ/AXYLIElwXfhV0 69D4nIwgRoA93Twe3NFfxPu5BhBDTWzgA36arXRG36AE1MN6DFgNSLsFAstz1DbQ 8OpaSn0vFSy4RAuKrQtmc8JO5EdzTZij2HJkT7h1IAvLoDVWIF+QmC4fAtGzP1Hx Nbx/4LvnNC2ZoIAK3C6DX5yYdAgdQXSlXtyjMy9EWws68AIfEZIbAMHCHODNu4FQ IIV5LZl9btfZXD9b6E/9kH6MR3YO8jvUsyGcQ6EKuoBUiEtbuEEq6uQ5WRDQjrci y4zT86+HyW6sIXqg5BytA+RPjQDIujMzeD94xoViNqH5Zt0/VG/9isg2vfQSYWcV ZXleLsZkXlp4GyNHLDiWzZZxxpnlimN26qaMyl+Sf5f8/cufZUDxSkQl8de6ERC9 oUGV4o9p56iCzr+oHbSfz3CfBP4dIi+ajE7mWLVC10YQfzw+bgsE8uuo2JBnhzTB NW/CBlLnDR0bV7Agnr+Qy8Arg+oMpT51JI4/wbUsmNThYJT2DM4= =ahmP -----END PGP SIGNATURE----- --=-n5oNLAt610/+F66WtjjW--

1 0

Re: (ITS#8634) OpenLDAP fails to build against OpenSSL 1.1
by hyc＠symas.com 10 Apr '17

10 Apr '17

hristo(a)venev.name wrote: > Full_Name: Hristo Venev > Version: Unreleased Release Candidate 2.4.45 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.111.59.55) > > > Another user of the old DES API. Here's a patch (compiles, not tested): Thanks. Looks like you're compiling the old NT/LANMAN password hash support. Nobody should still be using that code, LANMAN hashes are trivially crackable on modern GPUs. > > diff --git a/libraries/liblutil/passwd.c b/libraries/liblutil/passwd.c > index 7aab344..c481326 100644 > --- a/libraries/liblutil/passwd.c > +++ b/libraries/liblutil/passwd.c > @@ -38,9 +38,9 @@ > # include <openssl/des.h> > > > -typedef des_cblock des_key; > -typedef des_cblock des_data_block; > -typedef des_key_schedule des_context; > +typedef DES_cblock des_key; > +typedef DES_cblock des_data_block; > +typedef DES_key_schedule des_context[1]; > #define des_failed(encrypted) 0 > #define des_finish(key, schedule) > > @@ -667,7 +667,7 @@ static void > des_set_key_and_parity( des_key *key, unsigned char *keyData) > { > memcpy(key, keyData, 8); > - des_set_odd_parity( key ); > + DES_set_odd_parity( key ); > } > > > @@ -699,7 +699,7 @@ des_set_key_and_parity( des_key *key, unsigned char > *keyData) > } > > static void > -des_set_key_unchecked( des_key *key, des_context ctxt ) > +DES_set_key_unchecked( des_key *key, des_context ctxt ) > { > ctxt[0] = NULL; > > @@ -712,7 +712,7 @@ des_set_key_unchecked( des_key *key, des_context ctxt ) > } > > static void > -des_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, > +DES_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, > des_context ctxt, int op) > { > SECStatus rv; > @@ -864,16 +864,16 @@ static int chk_lanman( > ldap_pvt_str2upper( UcasePassword ); > > lmPasswd_to_key( UcasePassword, &key ); > - des_set_key_unchecked( &key, schedule ); > - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); > + DES_set_key_unchecked( &key, schedule ); > + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); > > if (des_failed(&PasswordHash1)) { > return LUTIL_PASSWD_ERR; > } > > lmPasswd_to_key( &UcasePassword[7], &key ); > - des_set_key_unchecked( &key, schedule ); > - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); > + DES_set_key_unchecked( &key, schedule ); > + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); > if (des_failed(&PasswordHash2)) { > return LUTIL_PASSWD_ERR; > } > @@ -1160,12 +1160,12 @@ static int hash_lanman( > ldap_pvt_str2upper( UcasePassword ); > > lmPasswd_to_key( UcasePassword, &key ); > - des_set_key_unchecked( &key, schedule ); > - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); > + DES_set_key_unchecked( &key, schedule ); > + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); > > lmPasswd_to_key( &UcasePassword[7], &key ); > - des_set_key_unchecked( &key, schedule ); > - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); > + DES_set_key_unchecked( &key, schedule ); > + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); > > sprintf( PasswordHash, > "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x", > PasswordHash1[0],PasswordHash1[1],PasswordHash1[2],PasswordHash1[3], > > > -- -- 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#8634) OpenLDAP fails to build against OpenSSL 1.1
by hristo＠venev.name 10 Apr '17

10 Apr '17

Full_Name: Hristo Venev Version: Unreleased Release Candidate 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.111.59.55) Another user of the old DES API. Here's a patch (compiles, not tested): diff --git a/libraries/liblutil/passwd.c b/libraries/liblutil/passwd.c index 7aab344..c481326 100644 --- a/libraries/liblutil/passwd.c +++ b/libraries/liblutil/passwd.c @@ -38,9 +38,9 @@ # include <openssl/des.h> -typedef des_cblock des_key; -typedef des_cblock des_data_block; -typedef des_key_schedule des_context; +typedef DES_cblock des_key; +typedef DES_cblock des_data_block; +typedef DES_key_schedule des_context[1]; #define des_failed(encrypted) 0 #define des_finish(key, schedule) @@ -667,7 +667,7 @@ static void des_set_key_and_parity( des_key *key, unsigned char *keyData) { memcpy(key, keyData, 8); - des_set_odd_parity( key ); + DES_set_odd_parity( key ); } @@ -699,7 +699,7 @@ des_set_key_and_parity( des_key *key, unsigned char *keyData) } static void -des_set_key_unchecked( des_key *key, des_context ctxt ) +DES_set_key_unchecked( des_key *key, des_context ctxt ) { ctxt[0] = NULL; @@ -712,7 +712,7 @@ des_set_key_unchecked( des_key *key, des_context ctxt ) } static void -des_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, +DES_ecb_encrypt( des_data_block *plain, des_data_block *encrypted, des_context ctxt, int op) { SECStatus rv; @@ -864,16 +864,16 @@ static int chk_lanman( ldap_pvt_str2upper( UcasePassword ); lmPasswd_to_key( UcasePassword, &key ); - des_set_key_unchecked( &key, schedule ); - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); + DES_set_key_unchecked( &key, schedule ); + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); if (des_failed(&PasswordHash1)) { return LUTIL_PASSWD_ERR; } lmPasswd_to_key( &UcasePassword[7], &key ); - des_set_key_unchecked( &key, schedule ); - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); + DES_set_key_unchecked( &key, schedule ); + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); if (des_failed(&PasswordHash2)) { return LUTIL_PASSWD_ERR; } @@ -1160,12 +1160,12 @@ static int hash_lanman( ldap_pvt_str2upper( UcasePassword ); lmPasswd_to_key( UcasePassword, &key ); - des_set_key_unchecked( &key, schedule ); - des_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); + DES_set_key_unchecked( &key, schedule ); + DES_ecb_encrypt( &StdText, &PasswordHash1, schedule , DES_ENCRYPT ); lmPasswd_to_key( &UcasePassword[7], &key ); - des_set_key_unchecked( &key, schedule ); - des_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); + DES_set_key_unchecked( &key, schedule ); + DES_ecb_encrypt( &StdText, &PasswordHash2, schedule , DES_ENCRYPT ); sprintf( PasswordHash, "%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x", PasswordHash1[0],PasswordHash1[1],PasswordHash1[2],PasswordHash1[3],

1 0

Re: (ITS#8633) No released version of OpenLDAP supports OpenSSL 1.1.0
by hyc＠symas.com 10 Apr '17

10 Apr '17

hristo(a)venev.name wrote: > Full_Name: Hristo Venev > Version: 2.4.44 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.111.59.55) > > > No version of OpenLDAP that builds and works against OpenSSL 1.1.0 has been > released yet. Support for OpenSSL 1.1.0 is in the 2.4.45 release candidate. 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#8633) No released version of OpenLDAP supports OpenSSL 1.1.0
by hristo＠venev.name 10 Apr '17

10 Apr '17

Full_Name: Hristo Venev Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.111.59.55) No version of OpenLDAP that builds and works against OpenSSL 1.1.0 has been released yet.

1 0

Re: (ITS#8553) LMDB Windows UWP Patch
by Howard Chu 10 Apr '17

10 Apr '17

I see no patch filename or URL in this ticket.

1 0

Re: (ITS#8509) LMDB make targets for automake
by hyc＠symas.com 10 Apr '17

10 Apr '17

phantom+lmdb(a)live.ie wrote: > Full_Name: Aido > Version: 2.4.44 > OS: Ubuntu Trusty > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.239.90.19) > > > The current liblmdb Makefile does not make it easy to use liblmdb as a > submodule > to other projects that utilize automake e.g. automake uses a 'check' directive > instead of 'test'. > > Adding the following to the Makefile would make liblmdb more automake > friendly: > > EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags distcheck > .PHONY: $(EMPTY_AUTOMAKE_TARGETS) > $(EMPTY_AUTOMAKE_TARGETS): > check: test > > See: > https://www.gnu.org/software/automake/manual/html_node/Third_002dParty-Make… > > The OpenLDAP Project doesn't use automake, and as a policy we don't include support for tools we don't use. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8632) VC parsing error
by hyc＠symas.com 10 Apr '17

10 Apr '17

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170410-ITS-8632-request-the… > Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) > > > When extracting a SASL mechanism, VC overlay requests a string from ber_scanf, > where it should be an in-place BerValue *. > > Patch attached. > > Thanks, applied to git master -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8631) OpenLDAP segfault on startup
by hyc＠symas.com 10 Apr '17

10 Apr '17

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master/re24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170410-ITS-8631-Initialize-… > Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) > > > When playing around with ldapi, a typo uncovered a bug in the startup routines: > if the hostname cannot be resolved, an unitialised pointer would be referenced. > > Try running: > slapd -h ldap://does.not.exist -d -1 -f /dev/null > > Attached patch fixes this. > > Thanks, applied to git master -- -- 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#8632) VC parsing error
by okuznik＠symas.com 10 Apr '17

10 Apr '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170410-ITS-8632-request-the… Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) When extracting a SASL mechanism, VC overlay requests a string from ber_scanf, where it should be an in-place BerValue *. Patch attached.

1 0

(ITS#8631) OpenLDAP segfault on startup
by okuznik＠symas.com 10 Apr '17

10 Apr '17

Full_Name: Ondrej Kuznik Version: master/re24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170410-ITS-8631-Initialize-… Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) When playing around with ldapi, a typo uncovered a bug in the startup routines: if the hostname cannot be resolved, an unitialised pointer would be referenced. Try running: slapd -h ldap://does.not.exist -d -1 -f /dev/null Attached patch fixes this.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 10 Apr '17

10 Apr '17

Although I know that I'm highly probable not directly addressed by the question "For 2.5?" (see this its's notes), my answer/comment would be "Yes", even "Yes, of course.": As I think, introducing this feature into a later 2.5.x release seems to be as problematic as its introduction into running 2.4.x, I think it is a good or perhaps the best opportunity to introduce this feature into the first 2.5, or 2.6, ... or 3.0 release. Disclaimer (again): I do not mean applying my patch, which represents just a workaround for demonstration/testing purposes. Sorry, I don't know how to code the "the bitmask-separation" - but I could and would help testing it. By the way: Thank you very much for taking care of the its' incoming queue!

1 0

Re: (ITS#6897) segfault in lber on close
by quanah＠symas.com 08 Apr '17

08 Apr '17

Hello, Due to a lack of response to the necessary information required to pursue this report, this ITS will be closed. If you still encounter the issue with a current OpenLDAP release, please follow up with the information requested. Regards, 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#6874) slapd crashes while modifying a database
by quanah＠symas.com 08 Apr '17

08 Apr '17

Hello Dieter, Unfortunately your configuration for this ITS has been lost as it was stuck in a pastebin instead of supplied directly in the ITS itself. It does appear there was some question as to whether or not your configuration was valid, as well. If you still have this configuration and you still experience a crash with the current OpenLDAP release, please follow up with the full configuration information, debug backtrace, etc. In the meantime, this ITS will be closed. Regards, 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#6695) syncrepl end retrying and stop thread
by quanah＠symas.com 08 Apr '17

08 Apr '17

Hello, The information provided in the ITS is not actionable. The log appears to show syncrepl operating in REFRESH mode. However, the information as to why it is in REFRESH mode was not provided. At this point, numerous fixes to syncrepl have since been made. If you are able to reproduce the issue with the current OpenLDAP release, please respond to the ITS. In the meantime, this ITS will be closed. Regards, 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#6667) memberof infinite recursion on node rename
by quanah＠symas.com 08 Apr '17

08 Apr '17

Hello, Due to lack of response, this ITS will be closed. If you continue to encounter the issue with the current OpenLDAP release, please follow up with the information that was requested. Regards, 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#6648) Syncrepl cold refresh fails with mirrormode supplier
by quanah＠symas.com 08 Apr '17

08 Apr '17

Hi Andrew, Sorry for the delay in response to this issue report. I believe I actually encountered this same problem at a later point, and it is fixed in current OpenLDAP. Would you be able to confirm? Thanks, 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#8629) slapauth segfault with GSSAPI + olcAuthzRegexp using internal LDAP search + ppolicy overlay
by quanah＠symas.com 08 Apr '17

08 Apr '17

--On Thursday, April 06, 2017 3:22 PM +0000 clement.oudot(a)savoirfairelinux.com wrote: > Hello, > > I would like to know if some of you have an idea on how to fix this bug? > > I am able to test a patch if you can provide one. Hi Clement, Ondrej will be looking at this on Monday. --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#6545) delta-syncrepl rejects modification master accepted
by quanah＠symas.com 07 Apr '17

07 Apr '17

--On Friday, April 07, 2017 7:59 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Today at 1:36pm, Frank.Swasey(a)uvm.edu wrote: > >> Today at 7:59am, ondra(a)mistotebe.net wrote: >> >>> Would you be able to confirm the patch in my previous email does the >>> right thing for you? >> >> I am building it now, I'll test and report back. > > Yes, it has worked with every nasty test I have been able to dream up to > throw at it. Thanks for the confirmation. This fix will be included in OpenLDAP 2.4.45. --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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 07 Apr '17

07 Apr '17

Today at 1:36pm, Frank.Swasey(a)uvm.edu wrote: > Today at 7:59am, ondra(a)mistotebe.net wrote: > >> Would you be able to confirm the patch in my previous email does the >> right thing for you? > > I am building it now, I'll test and report back. Yes, it has worked with every nasty test I have been able to dream up to throw at it. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6631) back-sql attribute order incorrect
by quanah＠symas.com 07 Apr '17

07 Apr '17

Hello, This ITS is being closed due to a lack of feedback. If you continue to encounter this issue with a current release of OpenLDAP, please file a new issue report, providing the additional details that were requested in this ITS. Regards, 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#6448) BUS Error on Multi Master Mode
by quanah＠symas.com 07 Apr '17

07 Apr '17

Hello, Thanks for the report, and I apologize for the delay in responding. I would note that 2.4.21 (at this point) is ancient, and there have been numerous fixes to Multimaster replication since that time. I would note in the future, if you choose to file a report, your exact configurations would also need to be supplied for a report such as this one. There was nothing particularly actionable based on this report. This ITS will be closed. If you can reproduce this issue with a current build of OpenLDAP, please file a new issue. Regards, 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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 07 Apr '17

07 Apr '17

Today at 7:59am, ondra(a)mistotebe.net wrote: > Would you be able to confirm the patch in my previous email does the > right thing for you? I am building it now, I'll test and report back. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#7032) LDAP Server not answering a request
by quanah＠symas.com 07 Apr '17

07 Apr '17

Hello, Due to lack of response, this ITS will be closed. If you continue to encounter the issue with a current build of OpenLDAP, please file a new ITS. Regards, 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#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 07 Apr '17

07 Apr '17

On Thu, Apr 06, 2017 at 02:48:45PM +0000, Frank.Swasey(a)uvm.edu wrote: > On Wed, 5 Apr 2017 at 8:18am, ondra(a)mistotebe.net wrote: > >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Well, then that means that the current behavior is a bug in either the > syncrepl implementation or the accesslog recording. Since the MASTER > gets updated correctly and the REPLICAs (and other MMR members) all fall > down when attempting to process the accesslog entry. Yes, they might reject the log entry and fall back to regular syncrepl in the way they would in case of a conflict (which is mostly fine), or the interpretation might seem to fit and a chance is that it's different that the actual modification, causing the servers to silently get out of sync. >> It does need a fair bit of attention, the problem is it's something that >> would require a format change and there are already existing consumers >> that would be affected. >> >> I'm going to try with a patch to record something like this: >> regMod: sn:= George >> regMod: : >> regMod: sn:= George >> >> Together with the relevant syncrepl updates. >> >> While consumers would still be affected, this should be quite rare and >> the current handling of that case would have been incorrect anyway. The >> change would then only make the silent failure a noisy one. > > Noisy in that the replica/mmr falls over dead or just logs more stuff? In case of delta-syncrepl, it should reject it and fall back to regular syncrepl. I can't vouch for anything else that consumes accesslog data obviously. > To be honest, my goal is consistency. I want the replicas (and > MMR mates) to all wind up with the same values the master has. Would you be able to confirm the patch in my previous email does the right thing for you? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 06 Apr '17

06 Apr '17

On Thu, Apr 06, 2017 at 04:41:19PM +0100, Howard Chu wrote: > ondra(a)mistotebe.net wrote: >> Well, the clients are allowed to request a lot of strange things, some >> of which border on a DoS: e.g. right now slapd can't disallow a modify >> request like: (pumping up an attribute to extreme size) > > Nor should we disallow any such thing. "Be liberal in what you accept." Yes, not disallow in principle, it was meant as focusing on an option to define some resource/processing limits before we even thought about the other example that is relatively benign. BTW, the patch is now available here. The empty attribute should have replicas fall back to regular syncrepl, where the ones that understand it will interpret it correctly. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170406-ITS-6545-accesslog-f… -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by hyc＠symas.com 06 Apr '17

06 Apr '17

ondra(a)mistotebe.net wrote: > On Thu, Apr 06, 2017 at 05:14:15PM +0200, Michael Str=C3=83=C2=B6der wr= ote: >> ondra(a)mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Str=C3=84=E2=80=9A=C3= =85=E2=80=BAder wrote: >>>> =3D> There could be a slapd per-backend configuation directive to di= sallow it with a >>>> strong hint in the docs recommending to disallow it when using delta= -syncrepl. >>>> >>>> Suggestion: >>>> disallow mod_attr_repeated >>> >>> In my view, that's more pain than it's worth. >> >> Hmm, I think slapd should be able to disallow a crazy modify request l= ike this: >> >> dn: cn=3Dfoobar,dc=3Dexample,dc=3Dcom >> changetype: modify >> replace: description >> description: foobar1 >> - >> replace: description >> description: foobar2 >> - >> .. >> replace: description >> description: foobar1000 >> - > > Well, the clients are allowed to request a lot of strange things, some > of which border on a DoS: e.g. right now slapd can't disallow a modify > request like: Nor should we disallow any such thing. "Be liberal in what you accept." > > dn: cn=3Dfoobar,dc=3Dexample,dc=3Dcom > changetype: modify > replace: description > description: foobar1 > description: foobar2 > ... > description: foobar1000 > > So there. If we can agree on a way to handle that, we might see whether > it could be repurposed. > > I should have a patch for the accesslog issue soon. > --=20 -- 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