- openldap-bugs - openldap.org

Re: (ITS#8174) mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by hyc＠symas.com 18 Jun '15

18 Jun '15

h.b.furuseth(a)usit.uio.no wrote: > What to do with open DBIs of named databases: > > (A) Fail if there are any. This would be best. -- -- 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#8174) mdb_drop(,MAIN_DBI,) leaks pages of named DBs
by h.b.furuseth＠usit.uio.no 18 Jun '15

18 Jun '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.14 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_drop(,MAIN_DBI,) leaks pages of named DBs It does not drop the pages of named DBs, but it does drop the mainDB pages which refer to these DBs. 3 possible fixes + 1 hybrid (from old IRC chats): (1) Fail if there are named DBs. The minimal fix. (2) Reset both metapages. Reject new write txns while old readers remain. Needs MDB_DATA_{VERSION/FORMAT} > 1. (3) Recursive: Drop named DBs too. (4) Try (3), but fail when that gets complicated. What to do with open DBIs of named databases: (A) Fail if there are any. (B) Close them, like a recursive mdb_drop() would do. The user must likely "stop the world" first. (C) Keep them open but useless, as when another process dropped the DB. All the user can do is close them. API: I think all variants but "fail" can be dangerous and/or possibly surprising, and should all be options - even if we only implement one choice. I.e. fail if there are named DBs/DBIs and no options say what to do about it. Would that be a new mdb_drop2() function? It's unfortunate to change the meaning of mdb_drop() param 'del' > 1. OTOH 'del' > 1 has been an error since 0.9.7, so I'm OK with it. Details: (2) Reset both metapages: mdb_drop() merely sets a txn flag so mdb_txn_commit() will reset the metapages. The flag also prevents most operations, like MDB_TXN_ERROR does. We can include it in MDB_TXN_BLOCKED from my "mdb/safer" branch. An MDB_meta flag then tells mdb_txn_renew0() to re-commit the metapage if Commit failed to write the 2nd metapage, and to reject writers when too old readers exist. mdb_txn_renew0() needs a flags parameter, so it can react to the new txn flags MDB_NO[META]SYNC. The caller cannot set them before mdb_txn_renew0(), since txn == me_txn0. (3) Recursive drop: mdb_drop0() must locate and use the up-to-date mt_dbs[] record when it sees a named DB record in the mainDB. Either: - Search mt_dbxs[]. Then drop is O(n*n) unless we make mt_dbxs[] a tree/hash first. OK for most users, but a few people have said they use lots of DBs. - Or mdb_drop() can first save dirty named DBs, like Commit does. Wasteful, but less new code. To make mdb_drop0() recursive: Factor out the DB-walking code in mdb_env_cwalk(), at least for non-stale DBIs? If searching mdb_dbxs[] for DBIs, it can also call mdb_drop(). Except it should not close any DBIs until everything succeeds. (4) Recursive or fail: Fail if there are dirty named DB (so mdb_drop0 need not searchA0Amt_dbxs), or maybe non-DB_STALE ones (so it need not reset DB records), or if called in a nested txn with DB_NEW DBIs or stuff like that (because it makes my head hurt to try to figure it out). Well, it looks much safer now than before we had mt_dbiseqs[]. Maybe dirty DBs are the only problem. (B) Close DBIs: Simple, but makes drop(MAIN DBI) a "stop the world" operation. (C) Keep DBIs open: Reset mt_dbs[] contents and mark the DBIs as DB_STALE, then attempts to use them will fail. Probably just a TODO item until there is a general "drop DB without closing it" option. Related issues: There is no way to fully reset the main DB (including flags) and close it. I think that should be an option too - someday. Would need the main DBI to not be so special. E.g. currently DB_NEW doesn't apply to it. Until then, that's just something to think about with the API for the rest of this stuff. The cleanest API would be if the main DBI is just like other DBIs, instead of the default "do not close it" being different. IIRC it's possible for the user to overwrite/delete a named DB as plain data and maybe use plain data as a named DB. I have an old branch to catch that, which we were a bit nervious about but should be fine.

1 0

(ITS#8173) back-ldap slapd crash segfault
by adrian.raemy＠vtg.admin.ch 18 Jun '15

18 Jun '15

Full_Name: Adrian Raemy Version: 2.4.40 OS: SLES 11 SP3 URL: Submission from: (NULL) (193.5.216.100) Hi, The Openldap backend "ldap" slapd crashing under heavy load. Tested with 2.4.26 and also 2.4.40. We get an segfault: Jun 18 00:00:36 serverxx1 kernel: [9079587.309374] slapd[6193]: segfault at 40 ip 00007f184cf6b2c6 sp 00007f1838ff85c0 error 4 in slapd[7f184cdda000+26c000] Jun 18 09:40:12 serverxx1 kernel: [9114294.985888] slapd[10309]: segfault at 40 ip 00007f3b31f492c6 sp 00007f3b1f7f55c0 error 4 in slapd[7f3b31db8000+26c000] Jun 18 12:38:29 serverxx1 kernel: [9124971.271300] slapd[15868]: segfault 4 40 ip 00007fc1555512c6 sp 00007fc141ffa5c0 error 4 in slapd[7fc1553c0000+26c000] OpenLdap Proxy Server has: Type = VM Guest mem = 4GB CPU = 2 Cores = 2 We don't get any other errors or warning before, CPU load and MEM etc all is green and OK. Also files open etc is set unlimited. Scenario: Linux/ Unix Clients and Applications via ssl start_tls and ssl over Openldap Proxy using on the Proxy the backend "ldap" to proxing to Openldap Master. When the Proxy gets heavy load due to activity from clients and Applications, the slapd crashes unexpected with the above slapd segfault. This is only happen with the backend-ldap. The Openldap Master doesn't crash and is stable at all. So it must be the backend ldap which has the problem. We perform Search-, Modify and add/remove Operations. So the entire funtionality will be used. Only with lot of searches sent over proxy to master we couldn't reproduce the segfault. It needs realy a heavy load generated (read/itite- modify operations at all) i guess to reproduce this. We don't have this possibility in our very restricted environment. We can't provide a core dump of the slapd due to confidentially restrictions. We would test with the backend "meta" but this backend doesn't support the "extended operations" like "LDAP Password Modify Extended Operation". So we have only two possibilities, the one that ldap backend will be fixed or the extended operations at meta backend will be added. Please, we need help/ a fix asap, e e authentication at all is compromised and the slapd crashes often on the Openldap Proxy. Thanks for your help

1 0

Re: (ITS#8172) RFE: back-sock CONTINUE to get modified parameters
by michael＠stroeder.com 14 Jun '15

14 Jun '15

Another important use-case is rewriting the bind-DN of a simple bind request without using slapo-rwm (because slapo-rwm often seg faults).

1 0

(ITS#8172)
by michael＠stroeder.com 13 Jun '15

13 Jun '15

This is a cryptographically signed message in MIME format. --------------ms000203090009040808090702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To clarify: The listener would only return the parameters with CONTINUE w= hich it wants to modify. --------------ms000203090009040808090702 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 DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDYxMzE0MjcwNFowLwYJKoZIhvcNAQkEMSIE IF/GMLW63vIhNpJPnfnKsX0XJHMHRPEXp4I1Yl+UAcdYMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQB96W6VFDsEY2SNlQe9wdgKdqxerHGIhS/IuXvLhVDajOASd1BbNL0S cRAmV/4VI6cZL1diG85aIWmkXz6aftocbZ6ZE5wMLpGswGGSFShzDTUKten15MvF518rjJXy DtsB/Yq8QkLgoGzQmaKA6Pm5GmI43lR30i3ZeykyeTYd/e52JG06sVFolgTJb/+qrrBF5AxI nNVXKX9/iAlBNiEzs35TBGOAtdvjJB4meHLxsBqGjDlOmx1HfDedb4+//6y4QT6Y3BqR8yWl tdNI53auTjKTBVa0ijdUfZw88BkO9X1kfIpC0MdyNSU44n4veF+/IuoGX+3Ogmo1V96iuS/C AAAAAAAA --------------ms000203090009040808090702--

1 0

(ITS#8172) RFE: back-sock CONTINUE to get modified parameters
by michael＠stroeder.com 13 Jun '15

13 Jun '15

Full_Name: Version: OS: URL: Submission from: (NULL) (84.178.19.235) It would be very nice if back-sock configured as overlay could make use of modified parameters returned with CONTINUE. Example for an incoming search request: SEARCH msgid: 42 suffix: dc=example,dc=com base: dc=example,dc=com scope: 2 [..] filter: (objectClass=*) [..] The external listener could return: CONTINUE msgid: 42 suffix: dc=example,dc=com base: ou=test,dc=example,dc=com scope: 1 [..] filter: (objectClass=account) [..] This would make request rewriting possible without having to use slapo-rwm.

1 0

(ITS#8171) slapd-sock(5): Details for CONTINUE response missing
by michael＠stroeder.com 12 Jun '15

12 Jun '15

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.223.49.129) It's not clear from the description in slapd-sock(5) whether the CONTINUE response in overlay mode should contain the msgid or not. While there's the detailed syntax for RESULT RESULT msgid: <message id> code: <integer> matched: <matched DN> info: <text> <blank line> there is no such syntax for CONTINUE. Is this correct? CONTINUE msgid: <message id> <blank line>

1 0

Re: (ITS#8170) ldapsearch -Z appears not to work
by quanah＠zimbra.com 12 Jun '15

12 Jun '15

--On Thursday, June 11, 2015 11:03 PM +0000 meta(a)pobox.com wrote: > Full_Name: mathew murphy > Version: 2.4.40 > OS: CentOS 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2605:6000:ee08:3200:56ee:75ff:fe4a:3f67) > > > % ldapsearch --help > [...] > -Z Start TLS request (-ZZ to require successful response) > % ldapsearch -x -Z -h localhost -p 636 -b 'dc=mydc' '(objectclass=*)' > ldap_start_tls: Can't contact LDAP server (-1) > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) -Z is for startTLS. LDAPS on port 636 is not startTLS. I.e., they are not compatible things. This ITS is invalid and will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8170) ldapsearch -Z appears not to work
by meta＠pobox.com 12 Jun '15

12 Jun '15

Full_Name: mathew murphy Version: 2.4.40 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2605:6000:ee08:3200:56ee:75ff:fe4a:3f67) % ldapsearch --help [...] -Z Start TLS request (-ZZ to require successful response) % ldapsearch -x -Z -h localhost -p 636 -b 'dc=mydc' '(objectclass=*)' ldap_start_tls: Can't contact LDAP server (-1) ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) However: % ldapsearch -x -H ldaps://localhost:636 -b 'dc=mydc' '(objectclass=*)' [lots of data] So -Z isn't needed if you use -H ldaps://..., and doesn't work if you don't. I realize that the FAQ mentions in passing that you need to use -H, but it's really well hidden compared to the bad advice given by ldapsearch --help.

1 0

(ITS#8169) [LMDB][PATCH] Allow passing manprefix to make install
by heirecka＠exherbo.org 11 Jun '15

11 Jun '15

Full_Name: Heiko Becker Version: OS: URL: http://dev.exherbo.org/~heirecka/0001-Allow-passing-manprefix-to-make-insta… Submission from: (NULL) (79.227.152.52) The motivation for this change is my distribution moving to a multiarch layout. While the architecture specific stuff (binaries, libraries, etc.) is installed under /usr/${host}/{bin,lib,...} architecture-independent data should still be installed to /usr/share/. Patch available through specified URL.

1 0

(ITS#8168) [LMDB][PATCH] Allow passing AR to make
by heirecka＠exherbo.org 11 Jun '15

11 Jun '15

Full_Name: Heiko Becker Version: OS: Linux URL: http://dev.exherbo.org/~heirecka/0001-Allow-passing-AR-to-make.patch Submission from: (NULL) (79.227.152.52) This is helpful when the ar executable is named differently, for example with an arch specific prefix. Patch available through specified URL.

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 10 Jun '15

10 Jun '15

I've now uploaded the patch to the ftp.openldap.org FTP server as "ian-pule= ston-15069.patch". Ian

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 10 Jun '15

10 Jun '15

Since it seems I can't send the patch file as an attachment, here it is inl= ine instead: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Start patch file =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D --- openldap-2.4.40/libraries/libldap/tls2.c 2014-09-18 18:48:50.000000000 = -0700 +++ openldap-2.4.40-new/libraries/libldap/tls2.c 2015-06-08 19:40:30.326927= 300 -0700 @@ -842,7 +842,7 @@ * Use non-blocking io during SSL Handshake when a timeout is configured */ if ( ld->ld_options.ldo_tm_net.tv_sec >=3D 0 ) { - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); tv =3D ld->ld_options.ldo_tm_net; tv0 =3D tv; @@ -877,7 +877,7 @@ break; } else { /* ldap_int_poll called ldap_pvt_ndelay_off */ - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); ret =3D ldap_int_tls_connect( ld, conn ); if ( ret > 0 ) { /* need to call tls_connect once more */ struct timeval curr_time_tv, delta_tv; @@ -925,7 +925,7 @@ } } if ( ld->ld_options.ldo_tm_net.tv_sec >=3D 0 ) { - ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); + ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); } #endif /* LDAP_USE_NON_BLOCKING_TLS */ =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D End patch file =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

1 0

RE: (ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠SonicWALL.com 09 Jun '15

09 Jun '15

--_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached a patch to fix this as outlined above. --_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_ Content-Type: application/octet-stream; name="openldap#8167.patch" Content-Description: openldap#8167.patch Content-Disposition: attachment; filename="openldap#8167.patch"; size=1165; creation-date="Tue, 09 Jun 2015 02:46:08 GMT"; modification-date="Tue, 09 Jun 2015 02:46:08 GMT" Content-Transfer-Encoding: base64 LS0tIG9wZW5sZGFwLTIuNC40MC9saWJyYXJpZXMvbGlibGRhcC90bHMyLmMJMjAxNC0wOS0xOCAx ODo0ODo1MC4wMDAwMDAwMDAgLTA3MDAKKysrIG9wZW5sZGFwLTIuNC40MC1uZXcvbGlicmFyaWVz L2xpYmxkYXAvdGxzMi5jCTIwMTUtMDYtMDggMTk6NDA6MzAuMzI2OTI3MzAwIC0wNzAwCkBAIC04 NDIsNyArODQyLDcgQEAKIAkgKiBVc2Ugbm9uLWJsb2NraW5nIGlvIGR1cmluZyBTU0wgSGFuZHNo YWtlIHdoZW4gYSB0aW1lb3V0IGlzIGNvbmZpZ3VyZWQKIAkgKi8KIAlpZiAoIGxkLT5sZF9vcHRp b25zLmxkb190bV9uZXQudHZfc2VjID49IDAgKSB7Ci0JCWJlcl9zb2NrYnVmX2N0cmwoIGxkLT5s ZF9zYiwgTEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCBzYiApOworCQliZXJfc29ja2J1Zl9jdHJs KCBzYiwgTEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCAodm9pZCopMSApOwogCQliZXJfc29ja2J1 Zl9jdHJsKCBzYiwgTEJFUl9TQl9PUFRfR0VUX0ZELCAmc2QgKTsKIAkJdHYgPSBsZC0+bGRfb3B0 aW9ucy5sZG9fdG1fbmV0OwogCQl0djAgPSB0djsKQEAgLTg3Nyw3ICs4NzcsNyBAQAogCQkJYnJl YWs7CiAJCX0gZWxzZSB7CiAJCQkvKiBsZGFwX2ludF9wb2xsIGNhbGxlZCBsZGFwX3B2dF9uZGVs YXlfb2ZmICovCi0JCQliZXJfc29ja2J1Zl9jdHJsKCBsZC0+bGRfc2IsIExCRVJfU0JfT1BUX1NF VF9OT05CTE9DSywgc2IgKTsKKwkJCWJlcl9zb2NrYnVmX2N0cmwoIHNiLCBMQkVSX1NCX09QVF9T RVRfTk9OQkxPQ0ssICh2b2lkKikxICk7CiAJCQlyZXQgPSBsZGFwX2ludF90bHNfY29ubmVjdCgg bGQsIGNvbm4gKTsKIAkJCWlmICggcmV0ID4gMCApIHsgLyogbmVlZCB0byBjYWxsIHRsc19jb25u ZWN0IG9uY2UgbW9yZSAqLwogCQkJCXN0cnVjdCB0aW1ldmFsIGN1cnJfdGltZV90diwgZGVsdGFf dHY7CkBAIC05MjUsNyArOTI1LDcgQEAKIAkJfQogCX0KIAlpZiAoIGxkLT5sZF9vcHRpb25zLmxk b190bV9uZXQudHZfc2VjID49IDAgKSB7Ci0JCWJlcl9zb2NrYnVmX2N0cmwoIGxkLT5sZF9zYiwg TEJFUl9TQl9PUFRfU0VUX05PTkJMT0NLLCBOVUxMICk7CisJCWJlcl9zb2NrYnVmX2N0cmwoIHNi LCBMQkVSX1NCX09QVF9TRVRfTk9OQkxPQ0ssIE5VTEwgKTsKIAl9CiAjZW5kaWYgLyogTERBUF9V U0VfTk9OX0JMT0NLSU5HX1RMUyAqLwogCg== --_002_BA45574AB547484AAB1B3380E6B1F5712C00E1AA4CUS0SCC00usson_--

1 0

(ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠sonicwall.com 09 Jun '15

09 Jun '15

Full_Name: Ian Puleston Version: 2.4.40 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.118.31.3) I've been using the new non-blocking TLS connect feature added in version 2.4.34 (issue #7428, compiled with LDAP_USE_NON_BLOCKING_TLS) and found a problem that it does not work in a reference/referral. It only works on the default connection, and that can cause a long or permanent hang in SSL_connect as follows, even when a network timeout is set and LDAP_USE_NON_BLOCKING_TLS is on: ldap_result -> ldap_chase_v3referrals ldap_chase_v3referrals -> ldap_send_server_request ldap_send_server_request -> ldap_new_connection ldap_new_connection -> ldap_int_open_connection ldap_int_open_connection -> ldap_int_tls_start ldap_int_tls_start -> ldap_pvt_tls_connect ldap_pvt_tls_connect -> (v0) tlso_session_connect -> SSL_connect The problem is that the calls to ber_sockbuf_ctrl with LBER_SB_OPT_SET_NONBLOCK pass the Sockbuf as ld->ld_sb where they should be passing it as sb, that being the Sockbuf for this connection. The following 3 changes in ldap_int_tls_start fix it: Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL )B3B Note I also changed the 3rd argument there from "sb" to "(void*)1" just because I think passing sb there is a little confusing. Either will work fine. Ian

1 0

(ITS#8166) translucent overlay - compatibility with other overlays that need write access
by thomcz＠gmail.com 08 Jun '15

08 Jun '15

Full_Name: Thomas Keil Version: 2.4.40 OS: Debian 8.0 Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.30.84.202) This is a software enhancement request. I have the following use case at hand: My university provides a central LDAP directory which authenticates users but does not contain group information. For my institute we want to set up our own OpenLDAP server which relays the user authentication to the central directory (via back_ldap) but additionally provides group information. This should be used by a network of linux machines for user authentication, group management and login filtering. For reasons of high availability we want to replicate our local LDAP server using the builtin replication mechanism of OpenLDAP. This seems to be a nice example for the use of the translucent backend. Nevertheless group membership (for login filtering) can only be provided using the memberof overlay which (so it seems) is not compatible with the translucent overlay. Furthermore the syncprov overlay needs to access the lastmod attribute which is disabled for databases using the translucent overlay. Thus a local database combined with the translucent overlay cannot be replicated at all. To me it seems that these problems can be solved by allowing write access to the local database for other overlays when used in combination with the translucent overlay. It would make this overlay much more useful than it is right now since it would allow to use this in large scale deployments as well (where replication is essential). This is valid especially for cases where the local administration has no write access to the central directory.

1 0

(ITS#8165) Add proper versioning to liblmdb
by quanah＠openldap.org 05 Jun '15

05 Jun '15

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) LMDB has matured to the point at which it should be creating a properly versioned library for linking. Currently, only liblmdb.so is created. It would be preferable to see it in libtool format (liblmdb.so.x.y.z). Should be done for the 0.9.15 release.

1 0

Re: (ITS#8164) RFC slapo-unique: set matchedDN
by pierangelo.masarati＠polimi.it 05 Jun '15

05 Jun '15

On 05/06/2015 17:41, michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: HEAD > OS: > URL: > Submission from: (NULL) (212.227.35.94) > > > It would be handy if slapo-unique could set matchedDN along with result code > constraintViolation(19) to a DN of an existing entry causing the constraint to > fail. I think this would violate the purpose and specification of matchedDN. It would be more appropriate to have that piece of info returned within the control value of a specifically designed response control, when the control is explicitly requested. What you're asking for could perhaps be logged, if it isn't yet. My 2c. Ciao, p. > > To avoid information disclosure ACL checking could be performed to determine > whether the bound identity has at least search privilege on the entry pseudo > attr and unique attr. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#8164) RFC slapo-unique: set matchedDN
by michael＠stroeder.com 05 Jun '15

05 Jun '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (212.227.35.94) It would be handy if slapo-unique could set matchedDN along with result code constraintViolation(19) to a DN of an existing entry causing the constraint to fail. To avoid information disclosure ACL checking could be performed to determine whether the bound identity has at least search privilege on the entry pseudo attr and unique attr.

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 05 Jun '15

05 Jun '15

On 05. juni 2015 08:59, goran.hammarback(a)foxt.com wrote: > Yeah, the fallback... I really did not know what to use there. I knew > sizeof(struct sockaddr_storage) would work on Linux but most likely not > on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I > have no way of testing if that really works at all for any platform so I > guess your way is probably better... Aha! Yes, then it should be sockaddr_storage. sockaddr breaks for any address type which is bigger than sizeof(struct sockaddr), which can be small. sockaddr_storage only breaks on an OS which complains when it is too big for the specified address type. -- Hallvard

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com 05 Jun '15

05 Jun '15

On tor, 2015-06-04 at 23:06 +0200, Hallvard Breien Furuseth wrote: > On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote: > > Hmm, my fingers thought it was still february. Now I have uploaded a > > file with the correct name, goran-hammarback-150603.ext. > > The date is probably just for disambiguation anyway. > > Tweaked it a bit, I expect it should look like this: > ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff > > Is there a reason you switched to sizeof(struct sockaddr) from > sockaddr_storage as the fallback? Otherwise sockaddr_storage > seems better, since that has presumably worked on most hosts. > Should only matter if people play tricks like using ldap_init_fd() > to create an unsupported connection type, e.g. "UDP ldapi://". Yeah, the fallback... I really did not know what to use there. I knew sizeof(struct sockaddr_storage) would work on Linux but most likely not on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I have no way of testing if that really works at all for any platform so I guess your way is probably better... > > Anyway, please test (or protest if it should be sockaddr). > The change from your patch may be trivial, but that doesn't > mean I couldn't have managed to break it:-) > > Note that OpenLDAP should be edited with editor tab width = > indentation = 4. Though some code has been written with > tab width = 8, so it looks messy either way. > Your patch looks fine. I will not have time to test it until next week earliest. My patch was meant only as an example, so I did not really think about indentation. Regards, /Göran

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 04 Jun '15

04 Jun '15

On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote: > Hmm, my fingers thought it was still february. Now I have uploaded a > file with the correct name, goran-hammarback-150603.ext. The date is probably just for disambiguation anyway. Tweaked it a bit, I expect it should look like this: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff Is there a reason you switched to sizeof(struct sockaddr) from sockaddr_storage as the fallback? Otherwise sockaddr_storage seems better, since that has presumably worked on most hosts. Should only matter if people play tricks like using ldap_init_fd() to create an unsupported connection type, e.g. "UDP ldapi://". Anyway, please test (or protest if it should be sockaddr). The change from your patch may be trivial, but that doesn't mean I couldn't have managed to break it:-) Note that OpenLDAP should be edited with editor tab width = indentation = 4. Though some code has been written with tab width = 8, so it looks messy either way. -- Hallvard

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com 03 Jun '15

03 Jun '15

pierre(a)reactos.org wrote: > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant. Simply don't use back-sql. And next time please provide exact config information. Ciao, Michael.

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

This is a cryptographically signed message in MIME format. --------------ms010206060101070502000609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/03/2015 03:52 PM, Howard Chu wrote: > pierre(a)reactos.org wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms070202050304000100090907 >> Content-Type: text/plain; charset=3Dwindows-1252 >> Content-Transfer-Encoding: quoted-printable >> >> Finally, some more information thanks to the testing env. >> >> It seems that the SQL backend is indeed responsible for this and >> apparently makes OpenLDAP no longer RFC-compliant. >=20 > back-sql currently has no maintainer and is not recommended for use. > The primary database backends are back-bdb,hdb, and mdb. All of these > are RFC-compliant. Unfortunately, these backends are not matching our use-case... I'll try to see whether I can (hack)fix it, even though, I'm not used to LDAP nor to OpenLDAP. And regarding my previous mail, the failing call is actually the call to structural_class() at line 1057 of entry-id. --=20 Pierre Schweitzer <pierre(a)reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. --------------ms010206060101070502000609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/ dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh 5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+ fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxNDUw MzZaMCMGCSqGSIb3DQEJBDEWBBSRFGOtquxUAEeY2pce3+qkyzZ+mTBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM MA0GCSqGSIb3DQEBAQUABIIBAAQyivx/2JJNvDy+ZH7mOs64BaztLIKVASx0NfEKCSI9oYgC JAhUTCnNAH++THUb8XcF7G9IG7jdqBLXjajuNtbpoCx/sryAGK+Mtjy+IH4hrhICS/U/rSFt mClSvauMWjCQIRSUjBH43Otasl2nYoMKznYHd9geeFfZI2QYN3hNf0q60GEHoYbG/YMDj3Fy iJ9SLbCjCcfYdwdBR+JvJWneuv5fYdViE9bUPbyBLy/6EO/hmN7dvXNyn5DnffiSsIuANyYH 4sScAoXLpfBqVjnWVmb2PjaOJ8l/SxBC1jECdgWZe63oNJN/2eYEdOLFRpEuOIf2/LKDofEQ Mrj/LLsAAAAAAAA= --------------ms010206060101070502000609--

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by hyc＠symas.com 03 Jun '15

03 Jun '15

pierre(a)reactos.org wrote: > This is a cryptographically signed message in MIME format. > > --------------ms070202050304000100090907 > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: quoted-printable > > Finally, some more information thanks to the testing env. > > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant. back-sql currently has no maintainer and is not recommended for use. The primary database backends are back-bdb,hdb, and mdb. All of these are RFC-compliant. > You'll find the log extract from the server here: > https://www3.heisspiter.net/query_uid > https://www3.heisspiter.net/query_javaRemoteLocation > https://www3.heisspiter.net/query_javaCodeBase > > The first one is the query of the uid attribute which exists and returns > fine. > The second one is the query of the javaRemoteLocation attribute which > doesn't exist and thus, doesn't return fine. > The third one is the query of the javaCodeBase attribute which exists in > schema but that we don't use at all but returns fine. > > The guilty function *might* be backsql_get_attr_vals() which is the last > one called, raising the error. > > On 06/03/2015 01:47 PM, Pierre Schweitzer wrote: >> On 06/03/2015 11:47 AM, Michael Str=F6der wrote: >>> On 2015-06-03 11:20, Pierre Schweitzer wrote: >>>> This is not a question, but really a bug report about a broken behavi= > or. >>> >>> Again: >>> I can confirm that requesting an attribute which does not exist in the= > >>> subschema does not affect whether an entry is returned. >>> >>>> I quote them again: "Potentially, OpenLDAP should have a bug raised t= > o >>>> make it impossible to get into a situation where error 65 is returned= > on >>>> a query, as it likely does not conform to the RFC." >>> >>> Again: This statement is right and AFACIS OpenLDAP always worked corre= > ctly. >> =20 >> OK, so you confirm that what we see here is an incorrect behavior. >> =20 >>>> Here is the log extract you're asking for (I just filtered out the >>>> base DN): >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D= > "XXXX" >>>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh= > eis spiter))" >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH >>>> attr=3DjavaRemoteLocation >>>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU= > LT >>>> tag=3D101 err=3D65 nentries=3D0 text=3D >>> >>> Up to now there's absolutely no evidence in the information you provid= > ed >>> that this is a bug. >>> >>> How did you make sure that an entry should be returned for exactly thi= > s >>> search with the bound identity and your configuration? >>> >>> I suspect a configuration or data error on your side. Many things can = > be >>> wrong. >>> Without seeing your config, data and the bound identity nobody can >>> track this down for you. >> =20 >> One technical information that would make sense: we are using the SQL >> backend. I've just checked, there's some attributes management in >> backend code, and the issue *may* come from this. >> The Atlassian support cannot reproduce the error with "out-of-the-box" >> OpenLDAP server not using SQL backend. >> =20 >> I will setup a dedicated test env for this issue so that I can more >> easily track & debug the issue. I'll come back at you when I've more >> information (or even a patch). >> =20 > > > --=20 > Pierre Schweitzer <pierre(a)reactos.org> > System & Network Administrator > Senior Kernel Developer > ReactOS Deutschland e.V. > -- -- 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#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

This is a cryptographically signed message in MIME format. --------------ms070202050304000100090907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Finally, some more information thanks to the testing env. It seems that the SQL backend is indeed responsible for this and apparently makes OpenLDAP no longer RFC-compliant. You'll find the log extract from the server here: https://www3.heisspiter.net/query_uid https://www3.heisspiter.net/query_javaRemoteLocation https://www3.heisspiter.net/query_javaCodeBase The first one is the query of the uid attribute which exists and returns fine. The second one is the query of the javaRemoteLocation attribute which doesn't exist and thus, doesn't return fine. The third one is the query of the javaCodeBase attribute which exists in schema but that we don't use at all but returns fine. The guilty function *might* be backsql_get_attr_vals() which is the last one called, raising the error. On 06/03/2015 01:47 PM, Pierre Schweitzer wrote: > On 06/03/2015 11:47 AM, Michael Str=F6der wrote: >> On 2015-06-03 11:20, Pierre Schweitzer wrote: >>> This is not a question, but really a bug report about a broken behavi= or. >> >> Again: >> I can confirm that requesting an attribute which does not exist in the= >> subschema does not affect whether an entry is returned. >> >>> I quote them again: "Potentially, OpenLDAP should have a bug raised t= o >>> make it impossible to get into a situation where error 65 is returned= on >>> a query, as it likely does not conform to the RFC." >> >> Again: This statement is right and AFACIS OpenLDAP always worked corre= ctly. >=20 > OK, so you confirm that what we see here is an incorrect behavior. >=20 >>> Here is the log extract you're asking for (I just filtered out the >>> base DN): >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D= "XXXX" >>> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dh= eis spiter))" >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH >>> attr=3DjavaRemoteLocation >>> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESU= LT >>> tag=3D101 err=3D65 nentries=3D0 text=3D >> >> Up to now there's absolutely no evidence in the information you provid= ed >> that this is a bug. >> >> How did you make sure that an entry should be returned for exactly thi= s >> search with the bound identity and your configuration? >> >> I suspect a configuration or data error on your side. Many things can = be >> wrong. >> Without seeing your config, data and the bound identity nobody can >> track this down for you. >=20 > One technical information that would make sense: we are using the SQL > backend. I've just checked, there's some attributes management in > backend code, and the issue *may* come from this. > The Atlassian support cannot reproduce the error with "out-of-the-box" > OpenLDAP server not using SQL backend. >=20 > I will setup a dedicated test env for this issue so that I can more > easily track & debug the issue. I'll come back at you when I've more > information (or even a patch). >=20 --=20 Pierre Schweitzer <pierre(a)reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. --------------ms070202050304000100090907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/ dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh 5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+ fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxMzQ2 MDJaMCMGCSqGSIb3DQEJBDEWBBSHoP2De9oU79PXJaHQD9IpiZL8qzBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM MA0GCSqGSIb3DQEBAQUABIIBAFgpMpCiNM/4e08hDdW/oRsHrkANq/2HsHBEuy4TwFiM908q S+MejeopEgKkZwqvRw5nR849PQzw15CFjm3/vwzbFc963Vz76SZlkpvAPsRas+34qH2Xs2r3 IiHs4BWSFxJj/IphDoQpaPcCaKCC8BzI4a1rvSO7g6G8n5WdtgZK/acsj3+ai71iuPE6N3js +ErRqHwvlReJhWED8a0ZrSrJ9ZMf+ULr+D8Jv0WWt1mDnPfUXm8jVATfM82f3q8RHfCsEXfm jjn1laAUkdY+FR0A14PfV9rFjgWOsNS4vhT3smqCELXAcIoqF6h6TIoZi1qgr2kHl/rmsJIz tP/VPb4AAAAAAAA= --------------ms070202050304000100090907--

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

This is a cryptographically signed message in MIME format. --------------ms020405000401010508050306 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/03/2015 11:47 AM, Michael Str=F6der wrote: > On 2015-06-03 11:20, Pierre Schweitzer wrote: >> This is not a question, but really a bug report about a broken behavio= r. >=20 > Again: > I can confirm that requesting an attribute which does not exist in the > subschema does not affect whether an entry is returned. >=20 >> I quote them again: "Potentially, OpenLDAP should have a bug raised to= >> make it impossible to get into a situation where error 65 is returned = on >> a query, as it likely does not conform to the RFC." >=20 > Again: This statement is right and AFACIS OpenLDAP always worked correc= tly. OK, so you confirm that what we see here is an incorrect behavior. >> Here is the log extract you're asking for (I just filtered out the >> base DN): >> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D= "XXXX" >> scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dhe= is spiter))" >> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH >> attr=3DjavaRemoteLocation >> Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESUL= T >> tag=3D101 err=3D65 nentries=3D0 text=3D >=20 > Up to now there's absolutely no evidence in the information you provide= d > that this is a bug. >=20 > How did you make sure that an entry should be returned for exactly this= > search with the bound identity and your configuration? >=20 > I suspect a configuration or data error on your side. Many things can b= e > wrong. > Without seeing your config, data and the bound identity nobody can > track this down for you. One technical information that would make sense: we are using the SQL backend. I've just checked, there's some attributes management in backend code, and the issue *may* come from this. The Atlassian support cannot reproduce the error with "out-of-the-box" OpenLDAP server not using SQL backend. I will setup a dedicated test env for this issue so that I can more easily track & debug the issue. I'll come back at you when I've more information (or even a patch). --=20 Pierre Schweitzer <pierre(a)reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. --------------ms020405000401010508050306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/ dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh 5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+ fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxMTQ3 MzhaMCMGCSqGSIb3DQEJBDEWBBQzjI2ph1YSdmtimunu50JmlPABvTBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM MA0GCSqGSIb3DQEBAQUABIIBABjJHLdvcE2ADkK1Fkr1+UA431l3bLVA7qOJyXcfuBIk5wRd nRwlEeA39IRJc4m8lDO2OV7sZt99aTp5z4LC1Z5mfN0s3I9VBZRDvjFgx+oYAqnuoq19eoM0 Tc9VHtDL8hG1mrohtDtPLe6n5yJrTBugBQN7BHPHJL2c3S8/7CJdfWlJOZRwvnxh73Q8KVUD 3rEGfFa0K4JVBhaolSAXcGX1QSKvbb7utDuw7JbnOjNocFv4zIunJO4z23VJbyQ59Tjb1pbl qEf7b4GFweA6Xkey1TCs6BcscxJEYSvyT0uv9zt/m6fJLkRED88Jxs0wVfyIHDNOhI4HI54/ LPIXytYAAAAAAAA= --------------ms020405000401010508050306--

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com 03 Jun '15

03 Jun '15

On 2015-06-03 11:20, Pierre Schweitzer wrote: > This is not a question, but really a bug report about a broken > behavior. Again: I can confirm that requesting an attribute which does not exist in the subschema does not affect whether an entry is returned. > I quote them again: "Potentially, OpenLDAP should have a bug raised to > make it impossible to get into a situation where error 65 is returned > on > a query, as it likely does not conform to the RFC." Again: This statement is right and AFACIS OpenLDAP always worked correctly. > Here is the log extract you're asking for (I just filtered out the base > DN): > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH base="XXXX" > scope=2 deref=0 filter="(&(objectClass=inetOrgPerson)(uid=heis > spiter))" > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SRCH > attr=javaRemoteLocation > Jun 3 09:17:30 rose-java slapd[6776]: conn=1516 op=1 SEARCH RESULT > tag=101 err=65 nentries=0 text= Up to now there's absolutely no evidence in the information you provided that this is a bug. How did you make sure that an entry should be returned for exactly this search with the bound identity and your configuration? I suspect a configuration or data error on your side. Many things can be wrong. Without seeing your config, data and the bound identity nobody can track this down for you. Ciao, Michael.

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

This is a cryptographically signed message in MIME format. --------------ms070206080505050308030000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is not a question, but really a bug report about a broken behavior. I quote them again: "Potentially, OpenLDAP should have a bug raised to make it impossible to get into a situation where error 65 is returned on a query, as it likely does not conform to the RFC." Here is the log extract you're asking for (I just filtered out the base D= N): Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH base=3D"XX= XX" scope=3D2 deref=3D0 filter=3D"(&(objectClass=3DinetOrgPerson)(uid=3Dheis = spiter))" Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SRCH attr=3DjavaRemoteLocation Jun 3 09:17:30 rose-java slapd[6776]: conn=3D1516 op=3D1 SEARCH RESULT tag=3D101 err=3D65 nentries=3D0 text=3D On 06/03/2015 11:10 AM, Michael Str=F6der wrote: > First, the issue tracker is not for usage questions. Please redirect > your question to openldap-technical mailing list. >=20 > On 2015-06-03 10:47, pierre(a)reactos.org wrote: >> Unfortunately, javaRemoteLocation isn't in java.schema and appears to = be >> deprecated. >> >> OpenLDAP replies with (ldapsearch result): >> # search result >> search: 2 >> result: 65 Object class viatation >> Seen from OpenLDAP logs: >> Apr 22 13:09:27 rose-java slapd[25272]: conn=3D1177 op=3D2 SEARCH RESU= LT >> tag=3D101 >> err=3D65 nentries=3D0 text=3D >> >> According to Jira support, this is an incorrect behavior from >> OpenLDAP, not >> matching the LDAP RFCs. Quoting them: "OpenLDAP should not be >> returning an error >> when querying for javaRemoteLocation, even if it is deprecated." >=20 > I can confirm that OpenLDAP works correctly in this regard. > You did not post the accompanying SEARCH log line with filter and scope= =2E > You should check that. >=20 > Ciao, Michael. >=20 --=20 Pierre Schweitzer <pierre(a)reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. --------------ms070206080505050308030000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/ dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh 5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+ fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMwOTIw MjhaMCMGCSqGSIb3DQEJBDEWBBTFhaO7mcYjpu+GXnROB2MNF4mLfzBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM MA0GCSqGSIb3DQEBAQUABIIBAGI6hgTKBlf8Gwp6s8GlntzWbcLsnW4MJIkZL78xFxsxhH1V epkKWwaHp++rHI56hSFa8M7ZM9+vJyGotoLB4gNBrUIEfb8ZzelD8JxqkAvJvfCALVyJ9DVP hQWaW6i2HU4zjt6Ol4zadY+6GyCjkndjOC9tbnRGNaNIxcaGXjeVPOcZDC+ZMN0OpEVw0AoT JoUZO8imWacPWtx7nH4MbtmhDBDH/4eHplROBHvP+ABvwYoqpGuc+O11hiabvN+hsOSsGdmX BSuCev4YSSCTrBER6gWEaeZlTqN9XfHjmdf7B9onPo5XkclqvTDfNV/ZZSTU4Buj2LmJ4bGe 9gFqkIIAAAAAAAA= --------------ms070206080505050308030000--

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com 03 Jun '15

03 Jun '15

First, the issue tracker is not for usage questions. Please redirect your question to openldap-technical mailing list. On 2015-06-03 10:47, pierre(a)reactos.org wrote: > Unfortunately, javaRemoteLocation isn't in java.schema and appears to > be > deprecated. > > OpenLDAP replies with (ldapsearch result): > # search result > search: 2 > result: 65 Object class viatation > Seen from OpenLDAP logs: > Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT > tag=101 > err=65 nentries=0 text= > > According to Jira support, this is an incorrect behavior from OpenLDAP, > not > matching the LDAP RFCs. Quoting them: "OpenLDAP should not be returning > an error > when querying for javaRemoteLocation, even if it is deprecated." I can confirm that OpenLDAP works correctly in this regard. You did not post the accompanying SEARCH log line with filter and scope. You should check that. Ciao, Michael.

1 0

(ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

Full_Name: Pierre Schweitzer Version: 2.4.40 OS: Ubuntu LTS 12.04.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.55.95.158) Hi, We are currently facing an issue with Jira 6.0.8 while interfacing it with OpenLDAP. When loging in, Jira attempts to query the following attributes: "uid mail sn givenName displayName objectClass javaSerializedData javaClassName javaFactory javaCodeBase javaReferenceAddress javaClassNames javaRemoteLocation" Unfortunately, javaRemoteLocation isn't in java.schema and appears to be deprecated. OpenLDAP replies with (ldapsearch result): # search result search: 2 result: 65 Object class viatation Seen from OpenLDAP logs: Apr 22 13:09:27 rose-java slapd[25272]: conn=1177 op=2 SEARCH RESULT tag=101 err=65 nentries=0 text= According to Jira support, this is an incorrect behavior from OpenLDAP, not matching the LDAP RFCs. Quoting them: "OpenLDAP should not be returning an error when querying for javaRemoteLocation, even if it is deprecated." If required for testing, we can provide more details such as Jira queries. Cheers,

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com 03 Jun '15

03 Jun '15

Hmm, my fingers thought it was still february. Now I have uploaded a file with the correct name, goran-hammarback-150603.ext. Regards, /Göran Hammarbäck On ons, 2015-06-03 at 00:18 +0200, Hallvard Breien Furuseth wrote: > On 29/05/15 14:42, goran.hammarback(a)foxt.com wrote: > > Here is a suggestion to a patch that has been tested on Solaris 11, AIX 7.1 and > > RedHat 6: > > > > *** libraries/liblber/sockbuf.c..org 2015-05-27 09:55:14.001639041 +0200 > > --- libraries/liblber/sockbuf.c > > That patch is empty. You can upload it to > ftp://ftp.openldap.org/incoming/your-name-YYMMDD.ext. > See the guidelines for contributing: > http://www.openldap.org/devel/contributing.html

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com 03 Jun '15

03 Jun '15

Not sure why the patch itself was not included. Anyway, I uploaded the patch (it is trivial) as goran-hammarback-150203.ext. Regards, /Göran Hammarbäck On ons, 2015-06-03 at 00:18 +0200, Hallvard Breien Furuseth wrote: > On 29/05/15 14:42, goran.hammarback(a)foxt.com wrote: > > Here is a suggestion to a patch that has been tested on Solaris 11, AIX 7.1 and > > RedHat 6: > > > > *** libraries/liblber/sockbuf.c..org 2015-05-27 09:55:14.001639041 +0200 > > --- libraries/liblber/sockbuf.c > > That patch is empty. You can upload it to > ftp://ftp.openldap.org/incoming/your-name-YYMMDD.ext. > See the guidelines for contributing: > http://www.openldap.org/devel/contributing.html

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 03 Jun '15

03 Jun '15

On 29/05/15 14:42, goran.hammarback(a)foxt.com wrote: > Here is a suggestion to a patch that has been tested on Solaris 11, AIX 7.1 and > RedHat 6: > > *** libraries/liblber/sockbuf.c..org 2015-05-27 09:55:14.001639041 +0200 > --- libraries/liblber/sockbuf.c That patch is empty. You can upload it to ftp://ftp.openldap.org/incoming/your-name-YYMMDD.ext. See the guidelines for contributing: http://www.openldap.org/devel/contributing.html

1 0

Re: (ITS#8162) Problème parsing bad LDAP URI in slapo-unique uniqueURI parameter
by h.b.furuseth＠usit.uio.no 03 Jun '15

03 Jun '15

On 02/06/15 23:11, bdauvergne(a)entrouvert.com wrote: > I had configured an mdb backend with a unique overlay configured like this: > > add olcOverlay={4}unique,olcDatabase={2}mdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcUniqueConfig > olcOverlay: {4}unique > olcUniqueURI: ldap://?supannAutreMail?sub > > When trying to add the first non root-entry of new DB openldap freeze and takes > 100% CPU. After activating loglevel 255 I saw that it was looping inside > mdb_search() logging 'scope not okay' with an increasing integer value in > front. Looks like a duplicate of ITS#8146, fixed in the OPENLDAP_REL_ENG_2_4 branch. Please test. Tarball: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> We might need a more general description of ITS#8146 in CHANGES.

1 0

(ITS#8162) Probl�me parsing bad LDAP URI in slapo-unique uniqueURI parameter
by bdauvergne＠entrouvert.com 02 Jun '15

02 Jun '15

Full_Name: Benjamin Dauvergne Version: 2.4.40 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.242.47.212) I had configured an mdb backend with a unique overlay configured like this: add olcOverlay={4}unique,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {4}unique olcUniqueURI: ldap://?supannAutreMail?sub When trying to add the first non root-entry of new DB openldap freeze and takes 100% CPU. After activating loglevel 255 I saw that it was looping inside mdb_search() logging 'scope not okay' with an increasing integer value in front. The problem here is that le LDAP URI is missing a third 'slash' which should separate the missing hostname part from the base DN parameter. The RFC 2255 grammar seem to imply that the third slash is mandatory if there are other parameters after it. I think OpenLDAP should have complained about the malformed olcUniqueURI value, not accept it blindly and fail by entering an infinite loop. Overlay configuration that is working: add olcOverlay={4}unique,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {4}unique olcUniqueURI: ldap:///?supannAutreMail?sub

1 0

Re: (ITS#8161) index approx not working
by h.b.furuseth＠usit.uio.no 02 Jun '15

02 Jun '15

On 02/06/15 11:10, bernhard.pfeiffer(a)brz.gv.at wrote: > I configured this index: > > index cn eq,sub,approx > (...) > <= mdb_approx_candidates: (cn) not indexed Does it help to stop slapd, run sbin/slapindex, restart slapd? After inserting an index in slapd.conf, you must do that to index your existing values (if any). If you instead use cn=config and add an index over the LDAP protocol, slapd will index the values automatically.

1 0

(ITS#8161) index approx not working
by bernhard.pfeiffer＠brz.gv.at 02 Jun '15

02 Jun '15

Full_Name: Bernhard Pfeiffer Version: 2.4.40 OS: SUSE Linux 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.158.227.32) Hey! I configured this index: index cn eq,sub,approx sn~=Bern But my search doesn't find anything: If i configure: index cn eq,sub and searching for: sn~=Bern I get some results. But in the logfile is written: <= mdb_approx_candidates: (cn) not indexed Is this a bug?

1 0

Re: (ITS#8160) phonetic searches
by h.b.furuseth＠usit.uio.no 02 Jun '15

02 Jun '15

On 02/06/15 10:00, bernhard.pfeiffer(a)brz.gv.at wrote: > Is there any possibility to configure phontic search specially for Austria? ITS is for bug reports/enhancements. Use the openldap-technical mailinglist for help reqests. Anyway: No, soundex/metaphone is hardcoded in slapd approx match. See <openldap source>/servers/slapd/phonetic.c. Clients can do a little of this "by hand" by inserting many variants of a name (e.g. o instead of ö) as invisible attribute values in the directory, see the x-hidden examples in man slapd.conf. Closing this ITS. Hallvard

1 0

(ITS#8160) phonetic searches
by bernhard.pfeiffer＠brz.gv.at 02 Jun '15

02 Jun '15

Full_Name: Bernhard Pfeiffer Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.158.227.32) Hey! Is there any possibility to configure phontic search specially for Austria? fe.: cn=Jörg Mössmer How i have to configure that to openLDAP, is there anywhere a documentation about this? Greets, Bernhard

1 0

(ITS#8159) Missing parameter in the Configuration man page
by elecharny＠apache.org 01 Jun '15

01 Jun '15

Full_Name: Emmanuel Lecharny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.195.127.200) There is a missing parameter description in the slapd-config man page, on the olcSizeLimit parameter. The doc says : "The syntax size.prtotal={<integer>|unlimited|disabled}..." when the code is also checking for an 'hard' value : } else if ( STRSTART( arg, "prtotal=" ) ) { arg += STRLENOF( "prtotal=" ); ... } else if ( strcasecmp( arg, "hard" ) == 0 ) { limit->lms_s_pr_total = 0;

1 0

(ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com 29 May '15

29 May '15

Full_Name: G.ran Hammarb.ck Version: 2.4.40 OS: Solaris 11, aix 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.71.43.2) In the routine libraries/liblber/sockbuf.s:sb_dgram_write(), the last argument to the sendto() call is sizeof( struct sockaddr_storage ). While this works on Linux, on Solaris 11 and AIX 7.1 (and likely other versions of these OSes) the call returns EINVAL. This causes attempts to use connectionless ldap to fail. Here is a suggestion to a patch that has been tested on Solaris 11, AIX 7.1 and RedHat 6: *** libraries/liblber/sockbuf.c..org 2015-05-27 09:55:14.001639041 +0200 --- libraries/liblber/sockbuf.c

1 0

Re: (ITS#8156) triggering MDB_PAGE_FULL
by sergej.jurecko＠gmail.com 28 May '15

28 May '15

--089e0160aab816893f05171d9e22 Content-Type: text/plain; charset=UTF-8 Thank you for the explanation. Sergej On Wed, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > On 27/05/15 09:00, sergej.jurecko(a)gmail.com wrote: > >> Using a dupsort and writing a large value (which is still bellow >> maxkeysize) >> will result in MDB_PAGE_FULL. >> (...) >> maxkeysize=10000 >> > > Too big MDB_MAXKEYSIZE. Its doc says: > "Keys and MDB_DUPSORT data items must fit on a node in a regular page." > > But the doc should clarify that MDB_MAXKEYSIZE can be set big enough > to break lmdb. > > Or mdb_env_open() can fail if the computed me_maxkey would be smaller. > > Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that, > and then fail if the page size would be unsupported. (MIN_PAGESIZE > can be computed at compile time, with some ugly macros.) > > lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=0. > Some time ago, that was 1/3 of the size you could reasonably use > (to allow 1 key + sub-page with 2 dupsort values), so it could make > sense to define MDB_MAXKEYSIZE above the safe max. Today lmdb > uses a sub-DB at once if a sub-page would be too small, though. > So I don't see much need to support maxkeysize > safe max. > --089e0160aab816893f05171d9e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Thank you for the explanation. <br><br><br></div>Serg= ej<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On We= d, May 27, 2015 at 10:32 AM, Hallvard Breien Furuseth <span dir=3D"ltr">&lt= ;<a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth= @usit.uio.no</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27/= 05/15 09:00, <a href=3D"mailto:sergej.jurecko@gmail.com" target=3D"_blank">= sergej.jurecko(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Using a dupsort and writing a large value (which is still bellow=C2=A0 maxk= eysize)<br> will result in MDB_PAGE_FULL.<br> (...)<br> maxkeysize=3D10000<br> </blockquote> <br> Too big MDB_MAXKEYSIZE.=C2=A0 Its doc says:<br> "Keys and MDB_DUPSORT data items must fit on a node in a regular page.= "<br> <br> But the doc should clarify that MDB_MAXKEYSIZE can be set big enough<br> to break lmdb.<br> <br> Or mdb_env_open() can fail if the computed me_maxkey would be smaller.<br> <br> Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that,<br> and then fail if the page size would be unsupported.=C2=A0 (MIN_PAGESIZE<br= > can be computed at compile time, with some ugly macros.)<br> <br> lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=3D0.<br> Some time ago, that was 1/3 of the size you could reasonably use<br> (to allow 1 key + sub-page with 2 dupsort values), so it could make<br> sense to define MDB_MAXKEYSIZE above the safe max.=C2=A0 Today lmdb<br> uses a sub-DB at once if a sub-page would be too small, though.<br> So I don't see much need to support maxkeysize > safe max.<br> </blockquote></div><br></div> --089e0160aab816893f05171d9e22--

1 0

(ITS#8157) txn can be useless after mdb_txn_renew()
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.14 OS: URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_txn_renew() may initialize txn halfway and then fail. After that, it refuses to work even when it should have succeeded, since the txn looks active (mt_dbxs != NULL). Fixing.

1 0

Re: (ITS#8156) triggering MDB_PAGE_FULL
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

On 27/05/15 10:33, h.b.furuseth(a)usit.uio.no wrote: > (blah...) > So I don't see much need to support maxkeysize > safe max. Sorry, I should I said there's no need to recommend changing MDB_MAXKEYSIZE as anything else than 0, except if you need to make sure old liblmdb versions can use the database. I don't want to restart the discussion about which errors to catch yet again.

1 0

Re: (ITS#8156) triggering MDB_PAGE_FULL
by h.b.furuseth＠usit.uio.no 27 May '15

27 May '15

On 27/05/15 09:00, sergej.jurecko(a)gmail.com wrote: > Using a dupsort and writing a large value (which is still bellow maxkeysize) > will result in MDB_PAGE_FULL. > (...) > maxkeysize=10000 Too big MDB_MAXKEYSIZE. Its doc says: "Keys and MDB_DUPSORT data items must fit on a node in a regular page." But the doc should clarify that MDB_MAXKEYSIZE can be set big enough to break lmdb. Or mdb_env_open() can fail if the computed me_maxkey would be smaller. Or compute a safe MIN_PAGESIZE from MDB_MAXKEYSIZE and use that, and then fail if the page size would be unsupported. (MIN_PAGESIZE can be computed at compile time, with some ugly macros.) lmdb sets the max safe maxkeysize if you define MDB_MAXKEYSIZE=0. Some time ago, that was 1/3 of the size you could reasonably use (to allow 1 key + sub-page with 2 dupsort values), so it could make sense to define MDB_MAXKEYSIZE above the safe max. Today lmdb uses a sub-DB at once if a sub-page would be too small, though. So I don't see much need to support maxkeysize > safe max.

1 0

(ITS#8156) triggering MDB_PAGE_FULL
by sergej.jurecko＠gmail.com 27 May '15

27 May '15

Full_Name: Sergej Jurecko Version: lmdb latest OS: osx 10.9.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.189.172.218) Using a dupsort and writing a large value (which is still bellow maxkeysize) will result in MDB_PAGE_FULL. Program here: http://pastebin.com/Mu6bp1DR Compiling with: gcc pagefull.c mdb.c midl.c -g -DMDB_MAXKEYSIZE=10000 -o pagefull Running ./pagefull maxkeysize=10000 writing keysize=12, datasize=4063 Cursor put eror=-30786

1 0

(ITS#8155) add support for cacertdir with gnutls
by ryan＠openldap.org 27 May '15

27 May '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (142.31.146.2) Submitted by: ryan GnuTLS recently (3.3.6) finally added an API for adding a directory of CA files: http://gnutls.org/manual/html_node/Core-TLS-API.html#gnutls_005fcertificate… https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certif… Haven't actually tried it yet, but I think it should allow us to implement cacertdir. Just filing this for tracking right now, patch to come later.

1 0

(ITS#8154) sizeLimit/timeLimit are described as Multi-value in slapd-config man page
by elecharny＠apache.org 26 May '15

26 May '15

Full_Name: Emmanuel Lecharny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.190.108.22) The slapd-config man page says that we can store the sizeLimit and timeLimit values as multiple values, when they are single value attributes (at least they should be...) : olcTimeLimit: time[.{soft|hard}]=<integer> [...] Specify the maximum number of seconds (in real time) slapd will spend answering a search request. The default time limit is 3600. Use unlimited to specify no limits. The second format allows a fine grain setting of the time limits. Extra args can be added ***in the same value or as additional values***. See olcLimits for an explanation of the different flags.

1 0

(ITS#8153) olcTimeLimit should be Single Value
by elecharny＠apache.org 26 May '15

26 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.190.108.22) The olcTimeLimit is not declared as Single Value : { "timelimit", "limit", 2, 0, 0, ARG_MAY_DB|ARG_MAGIC, &config_timelimit, "( OLcfgGlAt:67 NAME 'olcTimeLimit' " "SYNTAX OMsDirectoryString ) when we have olcSizeLimit declared as : { "sizelimit", "limit", 2, 0, 0, ARG_MAY_DB|ARG_MAGIC, &config_sizelimit, "( OLcfgGlAt:60 NAME 'olcSizeLimit' " "SYNTAX OMsDirectoryString SINGLE-VALUE ) There is a missing "SINGLE-VALUE" in file bconfig.c, on line 660.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs