- openldap-bugs - openldap.org

Re: (ITS#8349) fix ppolicy issue
by hamano＠osstech.co.jp 13 Jan '16

13 Jan '16

Hi, On Tue, 12 Jan 2016 17:46:23 +0900, Michael Ströder wrote: > > > 1) reduce pwdInHistory > > If set pwdInHistory to 5 then reduce pwdInHistory to 3, > > I try to rephrase: > If attribute 'pwdHistory' in the user entry has 5 values and attribute > 'pwdInHistory' in the policy entry is 3 then ignore (and remove?) the 2 oldest > 'pwdHistory' values. > Exactly! Thanks for your rephrase. > Are values in 'pwdInHistory' sorted by timestamp in this part of the code? > Ya, parsed pwdInHistory(pw_hist *tl) are sorted by ascending time order. So, In this case, we need ignore first 2 attributes then check 3 attributes. > > We expect to check password with three history, but ppolicy check > > password with all pwdHistory attribute. > > > > 2) reduce pwdInHistory to zero > > If set pwdInHistory to 5 then reduce pwdInHistory to 0, > > I try to rephrase: > If attribute 'pwdHistory' in the user entry is set and attribute 'pwdInHistory' > in the policy entry is 0 then ignore (and remove?) 'pwdHistory' completely. > > > We expect that ppolicy password checking will be disbale. but the > > pwdHistory attribute are remains, so password checking is still > > enabled. > > We need to remove pwdHistory attribute. > > I'm not sure whether removing 'pwdHistory' attribute (values) is the right thing > to do. If you want to increase 'pwdInHistory' later then the old values are lost. > Currently, pwdHistory attributes will truncate when to reduce 'pwdInHistory'. But this process is simply skipping when pwdInHistory: 0. this behavior is unnatural. I know how you feel. I'm sure root of issue is that 'pwdInHistory' attribute have both role "number of record pwdHistory" and "number of check pwdHistory". Thay are desirable to split same as 'pwdMaxFailure' and 'pwdMaxRecordedFailure'. Thank you. > Ciao, Michael. > -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 3747 AB70 7B98 7882 46F5 87E1 BF91 A2C1 7DC1 5E3D

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by Johannes.Kanefendt＠krzn.de 13 Jan '16

13 Jan '16

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002C2E33C1257F39_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Michael Str=F6der <michael(a)stroeder.com> schrieb am 12.01.2016 20:13:15: > The whole purpose of using the Assertion Control is that it should match = the > modified entry. When I construct a filter deliberately not matching=20 > the entry I > can simply omit the Assertion Control completely. The logical outcome of the assertion doesn't change as the actual=20 assertion filter is or-ed with a rule that will never match the targeted=20 entry. However, when (wrongly) passed to unique=5Fsearch, it will prevent a= =20 failure as all other entries than the target match. >=20 > Maybe I didn't get your idea though. >=20 > The use-case: My web2ldap sends Assertion Control along with a modify=20 request > with a filter constructed from all attributes considered to be not=20 modified by > another user: >=20 > (&(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000) > (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder > \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\2d3= 441 > \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3 > \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder > \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest > \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121831= 04Z)) >=20 Try to enclose the assertion by=20 (|(...)(!(entryDN=3Dou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde))) or=20 (|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee))) --=_alternative 002C2E33C1257F39_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <tt>Michael Str=F6der <michael(a)stroeder.com> schrieb am 12.01.2016 20:13:15: > The whole purpose of using the Assertion Control is that it should match the > modified entry. When I construct a filter deliberately not matching > the entry I > can simply omit the Assertion Control completely.</tt> <tt>The logical outcome of the assertion doesn't change as the actual assertion filter is or-ed with a rule that will never match the targeted entry. However, when (wrongly) passed to unique=5Fsearch, it will prevent a failure as all other entries than the target match.</= tt> <tt> > > Maybe I didn't get your idea though. > > The use-case: My web2ldap sends Assertion Control along with a modify request > with a filter constructed from all attributes considered to be not modified by > another user: > > (&(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000) > (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder<= br> > \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\= 2d3441 > \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3<b= r> > \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder<= br> > \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest > \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121= 83104Z)) > </tt> <tt>Try to enclose the assertion by (|(...)(!(entryDN=3D= ou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde))) or (|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee))) </tt> --=_alternative 002C2E33C1257F39_=--

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 12 Jan '16

12 Jan '16

Johannes.Kanefendt(a)krzn.de wrote: > A workaround is to extend the assertion filter to match all other entries > except the one to be modified: > > (|(cn=*)(!(entryDN=cn=Anna\20Blume,ou=Users,ou=schulung,dc=stroeder,dc=local))) The whole purpose of using the Assertion Control is that it should match the modified entry. When I construct a filter deliberately not matching the entry I can simply omit the Assertion Control completely. Maybe I didn't get your idea though. The use-case: My web2ldap sends Assertion Control along with a modify request with a filter constructed from all attributes considered to be not modified by another user: (&(entryCSN=20160112183104\2e449732Z\23000000\23000\23000000)(creatorsName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(entryUUID=1c66859e\2d3441\2d1034\2d93db\2d751297a711ee)(modifiersName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(createTimestamp=20150119160811Z)(entryDN=ou=test\2cou=Testing\2cdc=stroeder\2cdc=de)(modifyTimestamp=20160112183104Z)) This is done to really ensure that the entry was *not* changed after being read into the input form the user edits. Ciao, Michael.

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by Johannes.Kanefendt＠krzn.de 12 Jan '16

12 Jan '16

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0057F226C1257F38_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A workaround is to extend the assertion filter to match all other entries=20 except the one to be modified: (|(cn=3D*)(!(entryDN=3Dcn=3DAnna=20 Blume,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal))) -- Mit freundlichem Gru=DF Im Auftrag Johannes Kanefendt Kommunales Rechenzentrum Niederrhein Der Verbandsvorsteher Abteilung 2.3.2 - Schulen Online Friedrich-Heinrich-Allee 130 47475 Kamp-Lintfort -Germany- Telefon: +49 (0)2842 90 70 125 Web: www.krzn.de Email: Johannes.Kanefendt(a)krzn.de --=_alternative 0057F226C1257F38_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A workaround is to extend the assertion filter to match all other entries except the one to be modified: (|(cn=3D*)(!(entryDN=3Dcn=3DAnna Blu= me,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal))) -- Mit freundlichem Gru=DF Im Auftrag Johannes Kanefendt Kommunales Rechenzentrum Niederrhein= Der Verbandsvorsteher Abteilung 2.3.2 - Schulen Online</fo= nt> Friedrich-Heinrich-Allee 130 47475 Kamp-Lintfort -Germany- Telefon: +49 (0)2842 90 70 125 Web: <a href=3Dwww.krzn.de><f= ont size=3D2 color=3Dblue face=3D"sans-serif">www.krzn.de</a> Email: Johannes.Kanefendt(a)krzn.de --=_alternative 0057F226C1257F38_=--

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 12 Jan '16

12 Jan '16

Hello Quanah, only for information, were you able to reproduce this issue? Thanks for the feedback 2015-11-02 10:57 GMT+01:00 Maurizio Lattuada <maurizio.lattuada(a)gmail.com>: > Hello Quanah, > > unfortunately I cannot send here the complete and precise schema, is > used by our internal proprietary applications. > Anyway, it can be described as: > * dc=directory > ** ou=person > ** ou=organization > ** ou=relationship > > "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, > clearly other fields like first name, last name, isActive, phone > number, address and so on) > "ou=organization" has an identifier plus the other "common" fields > (name, address...) > "ou=relationship" has "objectClass=groupOfNames" and is used to describe: > * relationships between persons and organizations ("a person belongs > to one or more organization", that is an "organization has these > persons as members") > * relationships between organizations (e.g. "org_1_a is a > sub-organization of the main organization org_1", that is "org_1 has > org_1_a as member"). > > So, considering the schema I described in my previous email: > > Test-bench_application --> spring_http_invoker --> Server_side_app > ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> > App_in_syncprov_with_ldap > > the "Server_side_app" creates in sequence: > * one unique organization (let me call it simply "org_p", it has no > sub-organization) > * about 19500 persons by doing a loop as: > ** create one person > ** create the related entry in "ou=relationship" to describe "person > x belongs to org_p" > > Meanwhile this procedure is done, the synchronization via syncprov is > running to keep in sync the LDAP database 2 and > "App_in_syncprov_with_ldap". > > Hope it helps. > > thanks for the feedback. > > > > 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: >> --On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada >> <maurizio.lattuada(a)gmail.com> wrote: >> >>> Hello Quanah, >>> >>> I added the syncprov overlay to the 1st database, but is neither used >>> by our application (rather than by another off-the-shelf application) >>> nor replicated as is for the 2nd database. >>> For your 2nd request, unfortunately I'm not able to test it, since >>> between the LDAP and my test-bench application there is another server >>> side application: >> >> >> Ok. Is it possible to provide the custom schema you are using, and an >> example of a user entry you are loading, so I can template it? I'd like to >> see if I can reproduce the problem. >> >> Thanks. >> >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Platform Architect >> Zimbra, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration > > > > -- > Maurizio Lattuada -- Maurizio Lattuada

1 0

Re: (ITS#8349) fix ppolicy issue
by michael＠stroeder.com 12 Jan '16

12 Jan '16

This is a cryptographically signed message in MIME format. --------------ms020403050300060907090405 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Frankly I don't understand your text. hamano(a)osstech.co.jp wrote: > We fixed several issue around ppolicy. >=20 > 1) reduce pwdInHistory > If set pwdInHistory to 5 then reduce pwdInHistory to 3, I try to rephrase: If attribute 'pwdHistory' in the user entry has 5 values and attribute 'pwdInHistory' in the policy entry is 3 then ignore (and remove?) the 2 o= ldest 'pwdHistory' values. Are values in 'pwdInHistory' sorted by timestamp in this part of the code= ? > We expect to check password with three history, but ppolicy check > password with all pwdHistory attribute. >=20 > 2) reduce pwdInHistory to zero > If set pwdInHistory to 5 then reduce pwdInHistory to 0, I try to rephrase: If attribute 'pwdHistory' in the user entry is set and attribute 'pwdInHi= story' in the policy entry is 0 then ignore (and remove?) 'pwdHistory' completel= y. > We expect that ppolicy password checking will be disbale. but the > pwdHistory attribute are remains, so password checking is still > enabled. > We need to remove pwdHistory attribute. I'm not sure whether removing 'pwdHistory' attribute (values) is the righ= t thing to do. If you want to increase 'pwdInHistory' later then the old values a= re lost. Ciao, Michael. --------------ms020403050300060907090405 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 DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2 MDExMjA4NDYyM1owLwYJKoZIhvcNAQkEMSIEILl7VIW7hBM9B4GYZ7Uyl+XMeUJC0AIM+vIl mEhibpBVMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQAT4Ma6E7Ln+2anKcDh prgMxupVAa0wcHggWiSTvY9Zmb9PNt/5/FSD7lJfCWB2kyEGhBoKidjMAUaLoGoyXpp6fVfH iaKfW3cXIhv/bFJfkzxvrlqpygsHaQThytk/pU0c9AtyqDqv9emKZ6UlxvaCnX/367J1rW52 8wdluY8M95Ez67psCs59xrTtXrXZD7QIa+Y33xB53cMWR6kVcfT+d3NsFb0W6Yo1JPywekbs F1TlK4Ro1ggE78C7Kx1ifxhVZxQmcg7sTbx8PEjJsSl6vYmTJpCtJofTcV5NF0+onn6XD3mj xCNNyIzvQDTnFbcrJODyo0OX4pFj9Sjdmo7xAAAAAAAA --------------ms020403050300060907090405--

1 0

(ITS#8349) fix ppolicy issue
by hamano＠osstech.co.jp 12 Jan '16

12 Jan '16

Full_Name: HAMANO Tsukasa Version: 2.4.43 OS: Linux URL: https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHistory… Submission from: (NULL) (240b:10:2640:bf0:290:4cff:fe0d:f43e) We fixed several issue around ppolicy. 1) reduce pwdInHistory If set pwdInHistory to 5 then reduce pwdInHistory to 3, We expect to check password with three history, but ppolicy check password with all pwdHistory attribute. 2) reduce pwdInHistory to zero If set pwdInHistory to 5 then reduce pwdInHistory to 0, We expect that ppolicy password checking will be disbale. but the pwdHistory attribute are remains, so password checking is still enabled. We need to remove pwdHistory attribute. Please apply the patch. Thank you.

1 0

(ITS#8348) lmdb MDB_VL32 typeo in null check for txn0
by jeremiah.morrill＠econnect.tv 12 Jan '16

12 Jan '16

Full_Name: Jeremiah Morrill Version: lmdb 0.9.70 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.120.130.199) In the latest git repo, in mdb_env_close0, the null check on env->me_txn0 is pointing to env->me_txn: This: #ifdef MDB_VL32 if (env->me_txn0 && env->me_txn->mt_rpages) vs. #ifdef MDB_VL32 if (env->me_txn0 && env->me_txn0->mt_rpages)

1 0

Re: (ITS#8340) test022-ppolicy failed
by hyc＠symas.com 11 Jan '16

11 Jan '16

dieter(a)dkluenter.de wrote: > Hi, > I forgot to mention that the issue aroused after patching the code > with Nadezhda-Ivanova-151105.patch That patch is known to be unstable. Ignoring 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#8347) lmdb VL32 sometimes not unmapping pages
by jeremiah.morrill＠econnect.tv 11 Jan '16

11 Jan '16

Full_Name: Jeremiah Morrill Version: lmdb 0.9.70 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.120.130.199) I changed the value of MDB_ERPAGE_SIZE to 256(16384/64) to try and tweak high virtual-memory usage in 32bit. I believe this exposed a bug not hit in my testing. Sometimes mmap'd sections(usually one or two) were not being munmapped when the environment was closed. This was only evident after checking the process with the Windows utility VMMap. I observed that when this happened, in mdb_env_close0, the dangling mmap'd sections were always at env->me_rpages[(MDB_ERPAGE_SIZE - 1) / 2], which in the case of MDB_ERPAGE_SIZE of 256, would be at index 127. This seemed like a possible off-by-one error. Below is a diff that seems to fix the issue, but I do not stand by its correctness. --- a/src/libraries/lmdb/mdb.c +++ b/src/libraeses/lmdb/mdb.c @@ -1404,7 +1404,7 @@ struct MDB_env { #ifdef MDB_VL32 MDB_ID3L me_rpages; /**< like #mt_rpages, but global to env */ pthread_mutex_t me_rpmutex; /**< control access to #me_rpages */ -#define MDB_ERPAGE_SIZE 16384 +#define MDB_ERPAGE_SIZE (16384/64) #define MDB_ERPAGE_MAX (MDB_ERPAGE_SIZE-1) unsigned int me_rpcheck; #endif @@ -5851,7 +5851,7 @@ retry: if (el[0].mid >= MDB_ERPAGE_MAX - env->me_rpcheck) { /* purge unref'd pages */ unsigned i, y = 0;D%D - for (i=1; i<el[0].mid; i++) { + for (i=1; i<=el[0].mid; i++) { if (!el[i].mref) { if (!y) y = i; munmap(el[i].mptr, env->me_psize * el[i].mcnt);

1 0

(ITS#8318)
by lkrispen＠redhat.com 11 Jan '16

11 Jan '16

Hi, has there been an evaluation if this request would be accepted and implemented ? When could it be available ? Thanks, Ludwig

1 0

(ITS#8346) lmdb memory leak with MDB_VL32
by jeremiah.morrill＠econnect.tv 09 Jan '16

09 Jan '16

Full_Name: Jeremiah Morrill Version: lmdb 0.9.70 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.120.130.199) With MDB_VL32, I believe lmdb is leaking memory in env->txn0->mt_rpages. Here is quick diff of what may fix this issue. Not sure if I have redundant null checks. diff --git a/src/libraries/lmdb/mdb.c b/src/libraries/lmdb/mdb.cAiAindex 11832ab..1f00a66 100644 --- a/src/libraries/lmdb/mdb.c +++ b/src/libraries/lmdb/mdb.c @@ -5255,14 +5255,20 @@ mdb_env_close0(MDB_env *env, int excl) free(env->me_dbflags); free(env->me_path); free(env->me_dirty_list); - free(env->me_txn0); #ifdef MDB_VL32 + if(env->me_txn0){ + if(env->me_txn0->mt_rpages) { + free(env->me_txn0->mt_rpages); + } + } { unsigned int x; for (x=1; x<=env->me_rpages[0].mid; x++) munmap(env->me_rpages[x].mptr, env->me_rpages%5%5].mcnt * env->me_psize); } free(env->me_rpages); #endif + free(env->me_txn0); + mdb_midl_free(env->me_free_pgs); if (env->me_flags & MDB_ENV_TXKEY) {

1 0

Re: (ITS#8340) test022-ppolicy failed
by dieter＠dkluenter.de 03 Jan '16

03 Jan '16

Hi, I forgot to mention that the issue aroused after patching the code with Nadezhda-Ivanova-151105.patch -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53=C2=B037'09,95"N 10=C2=B008'02,42"E

1 0

(ITS#8345) inconsistencies regarding LDIF line length
by ryan＠openldap.org 31 Dec '15

31 Dec '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan This is sort of a follow-up to ITS#7871. ldif_sput gained an LDIF_KLUDGE, but ldif_put did not, so the latter now wraps at 76 columns instead of 78. (IMO ldif_sput and ldif_put could both just pass 0 for wrap instead of a specific number, and let ldif_sput_wrap set the default.) LDIF_SIZE_NEEDED still assumes wrapping to LDIF_LINE_WIDTH columns, so code that does LDIF_SIZE_NEEDED and then ldif_sput is now allocating (slightly) more memory than it actually needs. 389-ds does this, for example. (And actually, couldn't LDIF_SIZE_NEEDED just be a thinner wrapper around LDIF_SIZE_NEEDED_WRAP?) Not sure exactly what the policies are around API changes in exposed headers, but for 2.5, maybe LDIF_LINE_WIDTH could change to 78 and LDIF_KLUDGE could go away entirely? Should I take this part to -devel? BTW, is it still necessary for ldif.c to re-implement base64 instead of using the lutil functions?

1 0

Re: (ITS#8344) doc clarification: accesslog database should not be replicated
by jephte.clain＠univ-reunion.fr 31 Dec '15

31 Dec '15

This is a multi-part message in MIME format. --------------090104080006050907050407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The patch is attached --------------090104080006050907050407 Content-Type: text/x-diff; name="0001-accesslog-database-should-not-be-replicated.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-accesslog-database-should-not-be-replicated.patch" >From 351f3080b6fcf02dd67d4923e3c4e6fd99491b0a Mon Sep 17 00:00:00 2001 From: Jephte CLAIN <Jephte.Clain(a)univ-reunion.fr> Date: Thu, 31 Dec 2015 12:03:56 +0400 Subject: [PATCH] accesslog database should not be replicated --- doc/guide/admin/overlays.sdf | 4 ++++ doc/guide/admin/replication.sdf | 3 +++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/doc/guide/admin/overlays.sdf b/doc/guide/admin/overlays.sdf index fbf417b..026a35e 100644 --- a/doc/guide/admin/overlays.sdf +++ b/doc/guide/admin/overlays.sdf @@ -79,6 +79,10 @@ or in raw form. It is also used for {{SECT:delta-syncrepl replication}} +Note: an accesslog database is unique to a given master. Even though it may have +a syncprov overlay (e.g. when used for delta-syncrepl replication), it should +NOT be replicated. + H3: Access Logging Configuration The following is a basic example that implements Access Logging: diff --git a/doc/guide/admin/replication.sdf b/doc/guide/admin/replication.sdf index 54dabc0..7a3ebfc 100644 --- a/doc/guide/admin/replication.sdf +++ b/doc/guide/admin/replication.sdf @@ -743,6 +743,9 @@ all of the databases (primary, replica, and the accesslog storage database) should also have properly tuned {{DB_CONFIG}} files that meet your needs. +Note: an accesslog database is unique to a given master. Even though the +syncprov overlay is configured for delta-syncrepl replication, it should NOT be +replicated on the client. H3: N-Way Multi-Master -- 1.7.2.5 --------------090104080006050907050407--

1 0

(ITS#8344) doc clarification: accesslog database should not be replicated
by Jephte.Clain＠univ-reunion.fr 31 Dec '15

31 Dec '15

Full_Name: Jephte CLAIN Version: 2.4.43 OS: Linux URL: https://github.com/gdrsi/openldap/commit/351f3080b6fcf02dd67d4923e3c4e6fd99… Submission from: (NULL) (194.199.72.141) The admin guide does not stat clearly that the accesslog database should not be replicated. I attach a patch to clarify the documentation

1 0

Re: (ITS#8343) MDB database corrupted after one run
by hyc＠symas.com 29 Dec '15

29 Dec '15

gate03(a)landcroft.com wrote: > Full_Name: Michael Mounteney > Version: 2.4.43 > OS: OmniOS > URL: http://pastebin.com/aV1yFt7g > Submission from: (NULL) (122.108.201.32) > This appears to be a dup of ITS#8339. Closing. > > 0. rm /var/openldap-data/* > 1. Install attached slapd.conf in /opt/openldap/etc/openldap > 2. Save attached l1.ldif > 3. Run your LDAP server thus: /opt/openldap/libexec/slapd -f > /opt/openldap/etc/openldap/slapd.conf -h "ldap:/// ldaps:///" -d -1 > 4. Import the LDIF data thus: ldapadd -D "cn=manager,dc=mounteney,dc=me" -a -W > -f l1.ldif > 5. The password is: suomi > 6. The data import/add/load will crash on the last entry. > 7. Stop the server with ctrl-C. > 8. Restart the server with the same command as at step 3. > 9. The server reports: mdb_db_open: database "dc=mounteney,dc=me" cannot be > opened: Device busy (16). Restore from backup! > > The error is that at step 9, the OpenLDAP should have opened the existing > database and run normally, waiting for client requests. > > slapd.conf at http://pastebin.com/aV1yFt7g > l1.ldif at http://pastebin.com/tHc5ye1W > > -- -- 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#8343) MDB database corrupted after one run
by gate03＠landcroft.com 29 Dec '15

29 Dec '15

Full_Name: Michael Mounteney Version: 2.4.43 OS: OmniOS URL: http://pastebin.com/aV1yFt7g Submission from: (NULL) (122.108.201.32) 0. rm /var/openldap-data/* 1. Install attached slapd.conf in /opt/openldap/etc/openldap 2. Save attached l1.ldif 3. Run your LDAP server thus: /opt/openldap/libexec/slapd -f /opt/openldap/etc/openldap/slapd.conf -h "ldap:/// ldaps:///" -d -1 4. Import the LDIF data thus: ldapadd -D "cn=manager,dc=mounteney,dc=me" -a -W -f l1.ldif 5. The password is: suomi 6. The data import/add/load will crash on the last entry. 7. Stop the server with ctrl-C. 8. Restart the server with the same command as at step 3. 9. The server reports: mdb_db_open: database "dc=mounteney,dc=me" cannot be opened: Device busy (16). Restore from backup! The error is that at step 9, the OpenLDAP should have opened the existing database and run normally, waiting for client requests. slapd.conf at http://pastebin.com/aV1yFt7g l1.ldif at http://pastebin.com/tHc5ye1W

1 0

(ITS#8342) lmdb Handle Leak with VL32 on Windows
by jeremiah.morrill＠econnect.tv 28 Dec '15

28 Dec '15

Full_Name: Jeremiah Morrill Version: lmdb 0.9.70 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.120.130.199) I noticed what I believe may be a handle leak against the latest (commit 7b9928c) on github, with the MDB_VL32 on Windows. After some poking around, it seems to be the file mapping handle, env->me_fmh. I threw it to a CloseHandle in the env_close0() and it seemed to resolve it. Heres a quick diff: diff --git a/src/lmdb.c b/src/mdb.c index a564d40..190c860 100644 --- a/src/mdb.c +++ b/src/mdb.c @@ -5350,6 +5350,7 @@ mdb_env_close0(MDB_env *env, int excl) } #ifdef MDB_VL32 #ifdef _WIN32 + if (env->me_fmh) CloseHandle(env->me_fmh); if (env->me_rpmutex) CloseHandle(env->me_rpmutex); #else pthread_mutex_destroy(&env->me_rpmutex);

1 0

Re: (ITS#8341) Matching rules for 'namingContexts'
by michael＠stroeder.com 22 Dec '15

22 Dec '15

This is a multi-part message in MIME format. --------------090808030207050404060004 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Find attached the very trivial patch applied to git master for adding the EQUALITY matching rule to attribute type description for 'namingContexts'. Successfully tested. --------------090808030207050404060004 Content-Type: text/x-patch; name="openldap-patch-its8341.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-patch-its8341.diff" diff --git a/servers/slapd/schema_prep.c b/servers/slapd/schema_prep.c index 5630a95..b583e3d 100644 --- a/servers/slapd/schema_prep.c +++ b/servers/slapd/schema_prep.c @@ -633,6 +633,7 @@ static struct slap_schema_ad_map { { "namingContexts", "( 1.3.6.1.4.1.1466.101.120.5 " "NAME 'namingContexts' " "DESC 'RFC4512: naming contexts' " + "EQUALITY distinguishedNameMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )", rootDseAttribute, 0, NULL, NULL, --------------090808030207050404060004--

1 0

(ITS#8341) Matching rules for 'namingContexts'
by michael＠stroeder.com 22 Dec '15

22 Dec '15

Full_Name: Michael Str.der Version: HEAD OS: Linux URL: Submission from: (NULL) (213.240.180.113) For finding the monitoring entry for a given suffix matching rules for attribute 'namingContexts' have to be added.

1 0

(ITS#8340) test022-ppolicy failed
by dieter＠dkluenter.de 21 Dec '15

21 Dec '15

Full_Name: Dieter Kl.nter Version: OPENLDAP_REL_ENG_2_5 OS: openSUSE-42.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.220.31.155) this is git 8bbbaea0b4ec58ad51b9fb1b09e7b6e996ee0361 as the subject mentions, test022-ppolicy fails, this are the last 30 lines of slapd.1.log 56786874 <<< dnPrettyNormal: <uid=nd,ou=People,dc=example,dc=com>, <uid=nd,ou=peopleCdCdc=example,dc=com> 56786874 conn=1005 op=0 BIND dn="uid=nd,ou=People,dc=example,dc=com" method=128 56786874 do_bind: version=3 dn="uid=nd,ou=People,dc=example,dc=com" method=128 56786874 => mdb_entry_get: ndn: "uid=nd,ou=people,dc=example,dc=com" 56786874 => mdb_entry_get% o oc: "(null)", at: "(null)" 56786874 mdb_dn2entry("uid=nd,ou=people,dc=example,dc=com") 56786874 => mdb_dn2id("uid=nd,ou=people,dc=example,dc=com") 56786874 <= mdb_dn2id: got id=0x5 56786874 => mdb_entry_decode: 56786874 <= mdb_entry_decode 56786874 mdb_entry_get: rc=0 56786874 => mdb_entry_get: ndn: "cn=standard policy,ou=policies,dc=example,dc=com" 56786874 => mdb_entry_get: oc: "(null)", at: "(null)" 56786874 mdb_dn2entry("cn=standard policy,ou=policies,dc=example,dc=com") 56786874 => mdb_dn2id("cn=standard policy,ou=policies,dc=example,dc=com") 56786874 <= mdb_dn2id: got id=0x4 56786874 => mdb_entry_decode: 56786874 <= mdb_entry_decode 56786874 mdb_entry_get: rc=0 56786874 send_ldap_result: conn=1005 op=0 p=3 56786874 send_ldap_result: err=49 matched="" text="" 56786874 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 52 bytes to sd 12 56786874 conn=1005 op=0 RESULT tag=97 err=49 etime=0.000460 text= slapd: ppolicy.c:914: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. -Dieter

1 0

(ITS#8339) LMDB robust mutex fix
by openldap＠gulag.ch 20 Dec '15

20 Dec '15

Full_Name: Rolf Stalder Version: 2.4.43 OS: Solaris 11.2 URL: https://www.gulag.ch/www/download/0001-Solaris-robust-mutex-fix.patch Submission from: (NULL) (217.162.126.5) The provided patch (against 2.4.43) might solve a problem with the new robust POSIX mutex implementation of LMDB 0.9.17 on Solaris 10/11.x. On Solaris 11 slapd fails to open the database: -- mdb_db_open: database "x": dbenv_open(y). mdb_db_open: database "x" cannot be opened: z (N). Restore from backup! backend_startup_one (type=mdb, suffix="x"): bi_db_open failed! (N) slapd shutdown: initiated -- Values of 16 (EBUSY) and 22 (EINVAL) have been observed for N. The following notes can be found in pthread_mutexattr_setrobust(3C) ( https://docs.oracle.com/cd/E36784_01/html/E36874/pthread-mutexattr-setrobus…. html ): -- The mutex memory must be zeroed before first initialization of a mutex with the PTHREAD_MUTEX_ROBUST attribute. Any thread in any process interested in the robust lock can call pthread_mutex_init() to potentially initialize it, provided that all such callers of pthread_mutex_init() specify the same set of attributes in their attribute structures. In this situation, if pthread_mutex_init() is called on a pre- viously initialized robust mutex, it will not reinitialize the mutex and will return the error value EBUSY. If pthread_mutex_init() is called on a previously initialized robust mutex, and if the caller specifies a different set of attributes from those already in effect for the mutex, it will not reinitialize the mutex and will return the error value EINVAL. -- Solaris 10 only provides the *_np functions (2.4.43 build/compilation fails altogether) but the above meaning of EBUSY/EINVAL applies as well. This patch has only be tested on Solaris 10/11.2 with Solaris Studio 12.3.

1 0

Re: (ITS#8338) LMDB build fail by using MinGW
by hyc＠symas.com 17 Dec '15

17 Dec '15

ray2501(a)gmail.com wrote: > Full_Name: Danilo Chang > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.66.209.161) > > > ITS#8324 "incremental DB file growth for Windows add APIs" add APIs defined in > <wdm.h> and <ntifs.h> but not define NTSTATUS type in LMDB mdb.c, result in > build fail by using MinGW or MinGW-w64. > > Please add NTSTATUS type definition in LMDB mdb.c. > > Below is a quick fix: > typedef LONG NTSTATUS; > > Seems you have a very old version of MinGW. Builds fine for me using MSYS2 as well as MSYS. -- -- 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#8338) LMDB build fail by using MinGW
by ray2501＠gmail.com 17 Dec '15

17 Dec '15

Full_Name: Danilo Chang Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.66.209.161) ITS#8324 "incremental DB file growth for Windows add APIs" add APIs defined in <wdm.h> and <ntifs.h> but not define NTSTATUS type in LMDB mdb.c, result in build fail by using MinGW or MinGW-w64. Please add NTSTATUS type definition in LMDB mdb.c. Below is a quick fix: typedef LONG NTSTATUS;

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 16 Dec '15

16 Dec '15

This is a cryptographically signed message in MIME format. --------------ms070404020000010803010601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ondra(a)mistotebe.net wrote: > when watching the entries, they seem to be updating in real time for me= > as expected, do you have a cache of some sort between you and the serve= r? Ah, sorry! web2ldap has a short-time cache and I have to investiate why the URL argu= ment read_nocache=3D1 currently doesn't have any effect. :-/ Ok, your fix seems perfectly right. Ciao, Michael. --------------ms070404020000010803010601 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 DGYwggYqMIIFEqADAgECAgMPVg4wDQYJKoZIhvcNAQELBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA5MTAxNjMwMTdaFw0xNjA5MTAxNDA3NTBaMEQxHTAb BgNVBAMMFG1pY2hhZWxAc3Ryb2VkZXIuY29tMSMwIQYJKoZIhvcNAQkBFhRtaWNoYWVsQHN0 cm9lZGVyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ3ulgRkFW/ozuAX 8HwDmP7ifGF09KbLcAEVVjS013fTAlEzq0TJVcMXx/57LqdWtelCi35YvCzXHURuZl6hpUlR +yOR1sev9xP2NfEJHQKUfs435wN6xFmdg/LI+ydlJ/exc3XxZVnb994vtJOlQh1HgXJvCORp 9d359fQQMY5N71TiQs0rcn8SNUBLZYHom1U2g2oEHN/QFNf2noxfXdPxTWeeeR0EuhH1Yy/0 AE2JZk2VmFW6VZYjEPoXUOfRizEzSM6HjyG347RnFd5Zh5vquxN609Z2iSg1Txuvd/eLSSuu 9sxLfw/5Qq4Xd/vhNVTrvG8d4M9L54orRVdFwmsCAwEAAaOCAtowggLWMAkGA1UdEwQCMAAw CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU ubJgGvVtleGfzm7tjClKT2uUcB4wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wggFMBgNVHSAEggFDMIIBPzCCATsG CysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20v cG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcg dG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4g Y29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYB BQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9j bGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9j ZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAv5aQr1I7ZAg4VJJtaPIi61v/v0v9j Hs/Gl695n7shMeZx/H5F6EAwma0MWIWv1H9mtFcGhXiwr55SR1xMffy+C2Q5byyVcVKmrC+E vP1Ke+VnJ6v/l3JV5zPQf38XdCvYQACHFIODnVmD5JI59TWzS5ReudfTf60kQeNoRTZH15el 8hORNOzkoGiV70Kuuw7pCOf0ncjshttJE3NetXa2f4rTsCC5UNrMqhF8Y6NALa3m/zzCK1+i nvukFQPBU3+NFeNcrpp2nroEutsl3ftkcw6jAvQvTGEIw6AO13fgujtge+kxyoF2RuCSsEmT jmyZ7QweLwfmuU70umVTM8HUMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESi p7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9f tTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsW oTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/ 43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IB rTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQw UjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcB AgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0 BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjAN BgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHb WNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4 OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0 KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL0 4qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0 IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzxd2tC8Ga6 fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulcNJ8tKmVt jYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapSn+k3Lxm4 8ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9dvX2Y6BI XRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPtMIID6QIB ATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29t IENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMPVg4wDQYJYIZIAWUD BAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MTIxNjE1MTczMVowLwYJKoZIhvcNAQkEMSIEIC6fWNjcqiPmnbSv0ZBciEkxY7yK5wypFDoy 5rFc29yQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMPVg4wgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAw9WDjANBgkqhkiG9w0BAQEFAASCAQCVWQT/K8Pu5yMaLZVS tAseReEGBO1o1hu/1MHsup+WHyzyv20GdHickBH8E8dNo9pWLN37Zx/8akxd0ose2tFMdnJE /VH3HdTItKFQdcjR7/iUsELefikY1GhfDF4stCCIrmzMDai8bgrnsZwiGbs/EN5rPakAvxKI b8OKvbjLD2cXGHitZ/t5J4bOk7we5cHyaynbIj3AwOzTroGCrF9PUlfvqR9MPdjRiCreUvju w9a8h3SQIhMpwpDMaYbO4v/Udqf2ytBrN8Gi4SX+u67BzIkA7sPZ+3c688X+90NCay525lMp h1OLWeW6TJhbaaqBoTJ6zJNKcIBExIA91RIMAAAAAAAA --------------ms070404020000010803010601--

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 16 Dec '15

16 Dec '15

michael(a)stroeder.com wrote: > But ./run -b mdb test062 fails with: > ldapsearch should have failed with Critical extension is unavailable (12)! > ./scripts/test062-config-delete: line 164: kill: (18467) - No such process > > Likely the latter is unrelated. test062 fails *sometimes* also with upstream git master (see ITS#8151). So your solution for test007 seems to be ok. Ciao, Michael.

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 16 Dec '15

16 Dec '15

ondra(a)mistotebe.net wrote: > looks like an issue similar to the one fixed in > ITS#7256, this time it is only BerkeleyDB 4.8 that seems to complain > (have not tested with 4.7). > > Can you test with the latest commit at branch ITS8291 in my github repo > (https://github.com/mistotebe/openldap)? I've tested your branch ITS8291 with this commit: commit 47b7a1e29586793e87cacfa10fc50e2fc9d44b5f Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Wed Dec 16 13:47:17 2015 +0100 ITS#8291 Reopen cursor after delete ./run -b hdb test007 works perfectly now. But ./run -b mdb test062 fails with: ldapsearch should have failed with Critical extension is unavailable (12)! ./scripts/test062-config-delete: line 164: kill: (18467) - No such process Likely the latter is unrelated. Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by ondra＠mistotebe.net 16 Dec '15

16 Dec '15

On Sat, Dec 12, 2015 at 06:50:12PM +0000, michael(a)stroeder.com wrote: > ondra(a)mistotebe.net wrote: >> On Tue, Jul 22, 2014 at 07:38:26PM +0000, michael(a)stroeder.com wrote: >>> Would be nice if this gets ever fixed to match the RFC. >> >> Hi, can you test the changes in branch ITS7100 at >> https://github.com/mistotebe/openldap? > > Sorry for following up so late. > > I've tested your branch. > > 2. entryTTL seems now to be decreased > > It seems that when re-reading an entry the entryTTL is not always computed on > the fly. Rather the value is decreased every ~6 seconds (not matching dds-interval). Hi, when watching the entries, they seem to be updating in real time for me as expected, do you have a cache of some sort between you and the server? Cheers, Ondrej

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by ondra＠mistotebe.net 16 Dec '15

16 Dec '15

On Sat, Dec 12, 2015 at 07:11:43PM +0000, michael(a)stroeder.com wrote: > ondra(a)mistotebe.net wrote: > > On Tue, Oct 27, 2015 at 09:50:10AM +0000, michael(a)stroeder.com wrote: > >> Strange: testrun/test.out has zero bytes. :-/ > >> But the DB files are created. > >> > >> Other tests with -b hdb seem to work ok. > >> Maybe it's just the test script? > > > > I've let slapmodify honour logging settings in branch ITS8291 at > > https://github.com/mistotebe/openldap, could you paste the output of > > test.out with that enabled and possibly loglevel set to -1? > > See test.out here: > > http://www.stroeder.com/temp/openldap-its8291-test_out.gz Hi, thanks for the logs, looks like an issue similar to the one fixed in ITS#7256, this time it is only BerkeleyDB 4.8 that seems to complain (have not tested with 4.7). Can you test with the latest commit at branch ITS8291 in my github repo (https://github.com/mistotebe/openldap)? Thanks, Ondrej

1 0

RE: (ITS#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbConfig
by kenneth.penza＠gov.mt 15 Dec '15

15 Dec '15

>From: Howard Chu [mailto:hyc@symas.com]=20 >Sent: Saturday, 12 December 2015 17:15 >To: Penza Kenneth at MITA; openldap-its(a)OpenLDAP.org >Subject: Re: (ITS#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbCo= nfig > >kenneth.penza(a)gov.mt wrote: >> Full_Name: Kenneth Penza >> Version: 2.4.43 >> OS: CentOS 7.1 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (46.11.36.84) >> >> >> olcDbChecksum is not accepted for BDB and HDB backends (whilst its=20 >> documented in the manual pages). Below please find files and steps to re= produce. > >Thanks for the report, fixed now in git master. >> >> File attached: >> >> configbdb.ldif - ldif file to create config database with BDB backend=20 >> and checksum enabled. Uploaded in=20 >> ftp://ftp.openldap.org/incoming/kenneth-penza-151212-configbdb.ldif >> >> confighdb.ldif - ldif file to create config database with HDB backend=20 >> and checksum enabled. Uploaded in=20 >> ftp://ftp.openldap.org/incoming/kenneth-penza-151212-confighdb.ldif >> >> Test case: >> >> mkdir -p /tmp/dummyconfig/slapd.d.{b,h}db cd /tmp/dummyconfig >> >> slapadd -v -F slapd.d.bdb -n 0 -l configbdb.ldif slapadd -v -F=20 >> slapd.d.hdb -n 0 -l confighdb.ldif >> >> >> For BDB it reports: >> >> 566c3f04 Entry (olcDatabase=3D{2}bdb,cn=3Dconfig), attribute=20 >> 'olcDbChecksum' not allowed >> slapadd: dn=3D"olcDatabase=3D{2}bdb,cn=3Dconfig" (line=3D1070): (65) att= ribute=20 >> 'olcDbChecksum' not allowed >> >> For HDB it reports: >> >> 566c41e2 Entry (olcDatabase=3D{2}hdb,cn=3Dconfig), attribute=20 >> 'olcDbChecksum' not allowed >> slapadd: dn=3D"olcDatabase=3D{2}hdb,cn=3Dconfig" (line=3D1070): (65) att= ribute=20 >> 'olcDbChecksum' not allowed >> >> Kenneth >> >> > > >--=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/ I have pulled the sources that had the fix from the git repository and reco= mpiled openldap. Following the patch, config creation worked fine. To verify that it is working as expected, I tested with the olcDbChecksum s= et to true/false and verified the checksum flag of the database created as = per below output. For both BDB/HDB backends, olcDbChecksum set to true, removed all files und= er /var/lib/ldap/* and started server to re-create database. [root@host01 ldap]# db_dump /var/lib/ldap/dn2id.bdb=20 VERSION=3D3 format=3Dbytevalue type=3Dbtree chksum=3D1 duplicates=3D1 dupsort=3D1 db_pagesize=3D4096 HEADER=3DEND DATA=3DEND [root@host01 ldap]#=20 For both BDB/HDB backends, olcDbChecksum set to false, removed all files un= der /var/lib/ldap/* and started server to re-create database. [root@host01 ldap]# db_dump /var/lib/ldap/dn2id.bdb=20 VERSION=3D3 format=3Dbytevalue type=3Dbtree duplicates=3D1 dupsort=3D1 db_pagesize=3D4096 HEADER=3DEND DATA=3DEND [root@host01 ldap]#=20 >From the output above, it is working as expected. Thanks for your prompt su= pport and patch. Regards Kenneth

1 0

Re: (ITS#7992) lmdb: Windows: assume file paths are UTF-8, encode to UTF-16 for WinAPI and enable compiling when UNICODE is defined
by h.b.furuseth＠usit.uio.no 14 Dec '15

14 Dec '15

On 20/11/15 02:16, hyc(a)symas.com wrote: >> Also use CreateFileW to open files so that one can use exotic characters in >> paths. The library interface is not modified, but the code makes an assumption >> that paths passed to lmdb functions are encoded as UTF-8. The UTF-8 encoded >> paths are encoded to UTF-16 which is then passed to CreateFileW. > > This patch is now in git mdb.master. Needs cleanup: utf8_to_utf16() ignores errors in malloc/MultiByteToWideChar(). utf8_to_utf16()'s callers ignore error returns. utf8_to_utf16() can return EILSEQ, an errno code not listed in mdb_strerror(). It should return a Windows error code or a new MDB_<SOMETHING> code. (LMDB returns LDMB codes or system error codes. The latter are errno codes on Unix and Windows codes on Windows - except mdb_strerror's hardcoded errno codes which we plan to get rid of.)

1 0

Re: (ITS#8291) ./run -b hdb test007 fails
by michael＠stroeder.com 12 Dec '15

12 Dec '15

ondra(a)mistotebe.net wrote: > On Tue, Oct 27, 2015 at 09:50:10AM +0000, michael(a)stroeder.com wrote: >> Strange: testrun/test.out has zero bytes. :-/ >> But the DB files are created. >> >> Other tests with -b hdb seem to work ok. >> Maybe it's just the test script? > > I've let slapmodify honour logging settings in branch ITS8291 at > https://github.com/mistotebe/openldap, could you paste the output of > test.out with that enabled and possibly loglevel set to -1? See test.out here: http://www.stroeder.com/temp/openldap-its8291-test_out.gz Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 12 Dec '15

12 Dec '15

Michael Ströder wrote: > 1. make test fails (maybe unrelated): > >>>>> Starting test007-slapmodify for hdb... Ah, forgot ITS#8291. I will follow-up there after testing your branch ITS8291. Ciao, Michael.

1 0

Re: (ITS#7100) slapo-dds: entryTTL not decreasing
by michael＠stroeder.com 12 Dec '15

12 Dec '15

ondra(a)mistotebe.net wrote: > On Tue, Jul 22, 2014 at 07:38:26PM +0000, michael(a)stroeder.com wrote: >> Would be nice if this gets ever fixed to match the RFC. > > Hi, can you test the changes in branch ITS7100 at > https://github.com/mistotebe/openldap? Sorry for following up so late. I've tested your branch. 1. make test fails (maybe unrelated): >>>> Starting test007-slapmodify for hdb... running defines.sh Running slapadd to build slapd database... Testing modify, add, and delete using slapmodify... slapmodify failed (1)! >>>>> test007-slapmodify failed for hdb (exit 1) Makefile:302: recipe for target 'hdb-mod' failed make[2]: *** [hdb-mod] Error 1 make[2]: Leaving directory '/home/michael/src/openldap-git/mistotebe/openldap/tests' Makefile:280: recipe for target 'test' failed make[1]: *** [test] Error 2 make[1]: Leaving directory '/home/michael/src/openldap-git/mistotebe/openldap/tests' Makefile:292: recipe for target 'test' failed make: *** [test] Error 2 2. entryTTL seems now to be decreased It seems that when re-reading an entry the entryTTL is not always computed on the fly. Rather the value is decreased every ~6 seconds (not matching dds-interval). Ciao, Michael.

1 0

Re: (ITS#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbConfig
by hyc＠symas.com 12 Dec '15

12 Dec '15

kenneth.penza(a)gov.mt wrote: > Full_Name: Kenneth Penza > Version: 2.4.43 > OS: CentOS 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (46.11.36.84) > > > olcDbChecksum is not accepted for BDB and HDB backends (whilst its documented in > the manual pages). Below please find files and steps to reproduce. Thanks for the report, fixed now in git master. > > File attached: > > configbdb.ldif - ldif file to create config database with BDB backend and > checksum enabled. Uploaded in > ftp://ftp.openldap.org/incoming/kenneth-penza-151212-configbdb.ldif > > confighdb.ldif - ldif file to create config database with HDB backend and > checksum enabled. Uploaded in > ftp://ftp.openldap.org/incoming/kenneth-penza-151212-confighdb.ldif > > Test case: > > mkdir -p /tmp/dummyconfig/slapd.d.{b,h}db > cd /tmp/dummyconfig > > slapadd -v -F slapd.d.bdb -n 0 -l configbdb.ldif > slapadd -v -F slapd.d.hdb -n 0 -l confighdb.ldif > > > For BDB it reports: > > 566c3f04 Entry (olcDatabase={2}bdb,cn=config), attribute 'olcDbChecksum' not > allowed > slapadd: dn="olcDatabase={2}bdb,cn=config" (line=1070): (65) attribute > 'olcDbChecksum' not allowed > > For HDB it reports: > > 566c41e2 Entry (olcDatabase={2}hdb,cn=config), attribute 'olcDbChecksum' not > allowed > slapadd: dn="olcDatabase={2}hdb,cn=config" (line=1070): (65) attribute > 'olcDbChecksum' not allowed > > Kenneth > > -- -- 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#8337) olcDbChecksum not allowed in olcHdbConfig/olcBdbConfig
by kenneth.penza＠gov.mt 12 Dec '15

12 Dec '15

Full_Name: Kenneth Penza Version: 2.4.43 OS: CentOS 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.11.36.84) olcDbChecksum is not accepted for BDB and HDB backends (whilst its documented in the manual pages). Below please find files and steps to reproduce. File attached: configbdb.ldif - ldif file to create config database with BDB backend and checksum enabled. Uploaded in ftp://ftp.openldap.org/incoming/kenneth-penza-151212-configbdb.ldif confighdb.ldif - ldif file to create config database with HDB backend and checksum enabled. Uploaded in ftp://ftp.openldap.org/incoming/kenneth-penza-151212-confighdb.ldif Test case: mkdir -p /tmp/dummyconfig/slapd.d.{b,h}db cd /tmp/dummyconfig slapadd -v -F slapd.d.bdb -n 0 -l configbdb.ldif slapadd -v -F slapd.d.hdb -n 0 -l confighdb.ldif For BDB it reports: 566c3f04 Entry (olcDatabase={2}bdb,cn=config), attribute 'olcDbChecksum' not allowed slapadd: dn="olcDatabase={2}bdb,cn=config" (line=1070): (65) attribute 'olcDbChecksum' not allowed For HDB it reports: 566c41e2 Entry (olcDatabase={2}hdb,cn=config), attribute 'olcDbChecksum' not allowed slapadd: dn="olcDatabase={2}hdb,cn=config" (line=1070): (65) attribute 'olcDbChecksum' not allowed Kenneth

1 0

Re: (ITS#8327) The mod->sm_numvals values is checked and not seen as valid in mods.c
by clement.oudot＠savoirfairelinux.com 09 Dec '15

09 Dec '15

I would like to mention that I just faced this problem in OpenLDAP 2.4.43 w= ith the ppolicy overlay. The bug only occurs if a default ppolicy is defined in overlay configuratio= n, but no corresponding entry in LDAP server is found. There is no bug if t= he configuration entry is found, so this is not a big deal. <=3D ldap_dn2bv(uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom)=3D0 56682739 <<< dnPrettyNormal: <uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom= >, <uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom> 56682739 conn=3D1000 op=3D0 BIND dn=3D"uid=3Dcoudot,ou=3Dusers,dc=3Dexample= ,dc=3Dcom" method=3D128 56682739 do_bind: version=3D3 dn=3D"uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" method=3D128 56682739 =3D> mdb_entry_get: ndn: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> mdb_entry_get: found entry: "uid=3Dcoudot,ou=3Dusers,dc=3Dexa= mple,dc=3Dcom" 56682739 mdb_entry_get: rc=3D0 56682739 =3D> mdb_entry_get: ndn: "ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3D= com" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pai= r found (-30798) 56682739 =3D> mdb_entry_get: cannot find entry: "ou=3Dbug,ou=3Dppolicy,dc= =3Dexample,dc=3Dcom" 56682739 mdb_entry_get: rc=3D32 56682739 ppolicy_get: using default policy 56682739 =3D=3D> mdb_bind: dn: uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dco= m 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> access_allowed: result not in cache (userPassword) 56682739 =3D> access_allowed: auth access to "uid=3Dcoudot,ou=3Dusers,dc=3D= example,dc=3Dcom" "userPassword" requested 56682739 =3D> dn: [1] ou=3Dusers,dc=3Dexample,dc=3Dcom 56682739 =3D> acl_get: [1] matched 56682739 =3D> acl_get: [1] attr userPassword 56682739 =3D> acl_mask: access to entry "uid=3Dcoudot,ou=3Dusers,dc=3Dexamp= le,dc=3Dcom", attr "userPassword" requested 56682739 =3D> acl_mask: to value by "", (=3D0) 56682739 <=3D check a_dn_pat: uid=3Dwebsso,ou=3Dapplications,dc=3Dexample,d= c=3Dcom 56682739 <=3D check a_dn_pat: uid=3Dsyncrepl,ou=3Dapplications,dc=3Dexample= ,dc=3Dcom 56682739 <=3D check a_dn_pat: self 56682739 <=3D check a_dn_pat: * 56682739 <=3D acl_mask: [4] applying auth(=3Dxd) (stop) 56682739 <=3D acl_mask: [4] mask: auth(=3Dxd) 56682739 =3D> slap_access_allowed: auth access granted by auth(=3Dxd) 56682739 =3D> access_allowed: auth access granted by auth(=3Dxd) 56682739 send_ldap_result: conn=3D1000 op=3D0 p=3D3 56682739 send_ldap_result: err=3D49 matched=3D"" text=3D"" 56682739 =3D> mdb_entry_get: ndn: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> mdb_entry_get: found entry: "uid=3Dcoudot,ou=3Dusers,dc=3Dexa= mple,dc=3Dcom" 56682739 mdb_entry_get: rc=3D0 56682739 =3D> mdb_entry_get: ndn: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> mdb_entry_get: found entry: "uid=3Dcoudot,ou=3Dusers,dc=3Dexa= mple,dc=3Dcom" 56682739 mdb_entry_get: rc=3D0 56682739 =3D> mdb_search 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> access_allowed: search access to "uid=3Dcoudot,ou=3Dusers,dc= =3Dexample,dc=3Dcom" "entry" requested 56682739 <=3D root access granted 56682739 =3D> access_allowed: search access granted by manage(=3Dmwrscxd) 56682739 base_candidates: base: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3D= com" (0x00000007) 56682739 =3D> test_filter 56682739 EQUALITY 56682739 =3D> access_allowed: search access to "uid=3Dcoudot,ou=3Dusers,dc= =3Dexample,dc=3Dcom" "objectClass" requested 56682739 <=3D root access granted 56682739 =3D> access_allowed: search access granted by manage(=3Dmwrscxd) 56682739 <=3D test_filter 5 56682739 mdb_search: 7 does not match filter 56682739 send_ldap_result: conn=3D1000 op=3D0 p=3D3 56682739 send_ldap_result: err=3D0 matched=3D"" text=3D"" 56682739 constraint_update() 56682739 =3D> mdb_entry_get: ndn: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> mdb_entry_get: found entry: "uid=3Dcoudot,ou=3Dusers,dc=3Dexa= mple,dc=3Dcom" 56682739 mdb_entry_get: rc=3D0 56682739 =3D> mdb_entry_get: ndn: "uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc= =3Dcom" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 =3D> mdb_entry_get: found entry: "uid=3Dcoudot,ou=3Dusers,dc=3Dexa= mple,dc=3Dcom" 56682739 mdb_entry_get: rc=3D0 56682739 =3D> mdb_entry_get: ndn: "ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3D= com" 56682739 =3D> mdb_entry_get: oc: "(null)", at: "(null)" 56682739 mdb_dn2entry("ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("ou=3Dbug,ou=3Dppolicy,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pai= r found (-30798) 56682739 =3D> mdb_entry_get: cannot find entry: "ou=3Dbug,ou=3Dppolicy,dc= =3Dexample,dc=3Dcom" 56682739 mdb_entry_get: rc=3D32 56682739 ppolicy_get: using default policy 56682739 mdb_modify: uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom 56682739 slap_queue_csn: queueing 0x7fb05c104370 20151209130601.318371Z#000= 000#001#000000 56682739 mdb_dn2entry("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 =3D> mdb_dn2id("uid=3Dcoudot,ou=3Dusers,dc=3Dexample,dc=3Dcom") 56682739 <=3D mdb_dn2id: got id=3D0x7 56682739 =3D> mdb_entry_decode: 56682739 <=3D mdb_entry_decode 56682739 mdb_modify_internal: 0x00000007: uid=3Dcoudot,ou=3Dusers,dc=3Dexam= ple,dc=3Dcom 56682739 <=3D acl_access_allowed: granted to database root 56682739 mdb_modify_internal: replace pwdFailureTime slapd: mods.c:64: modify_add_values: Assertion `mod->sm_numvals =3D=3D i' f= ailed. Aborted (core dumped) Should be fixed by the patch done for this ITS, but I have not yet tested i= t. --=20 Cl=C3=A9ment OUDOT Consultant en logiciels libres, Expert infrastructure et s=C3=A9curit=C3=A9 Savoir-faire Linux

1 0

Re: (ITS#8336) assert(NUMKEYS(mp) > 1) in mdb_page_search_root()
by hyc＠symas.com 08 Dec '15

08 Dec '15

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: LMDB 0.9.17 > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.203.186) > Submitted by: hallvard > > > $ mtest_rand -c0 -i10000 -p0x100 -r562822527.3 -w > // Options for replay: [-v] -c0 -i10000 -p0x100 -r562822527.3 -w > ../mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() > Aborte%2(core dumped) > > Broken by 4b01cb3 "ITS#8221 don't merge branch pages needlessly" > according to git bisect. The assert occurs during txn_commit while updating the freeDB. During rebalance, a branch page in the freeDB has been reduced to only 1 key. This page is operated on by another (recursive) rebalance. During page_touch, a new page is needed, which calls page_alloc, which needs to acquire a free page from the freeDB. The resulting search trips this assert because it walks down thru the branch page that is currently being rebalanced. We could simply remove the assert; if we let things progress then eventually the rebalance will succeed and the branch page will be correct. We could also conditionalize the assert so that it ignores the freeDB. Or we can just ignore the problem entirely, because it only occurs on tiny 256 byte pages. -- -- 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#8336) assert(NUMKEYS(mp) > 1) in mdb_page_search_root()
by h.b.furuseth＠usit.uio.no 08 Dec '15

08 Dec '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.17 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard $ mtest_rand -c0 -i10000 -p0x100 -r562822527.3 -w // Options for replay: [-v] -c0 -i10000 -p0x100 -r562822527.3 -w ../mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() Aborte%2(core dumped) Broken by 4b01cb3 "ITS#8221 don't merge branch pages needlessly" according to git bisect.

1 0

(ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 07 Dec '15

07 Dec '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.17 OS: Linux x86_64 URL: Submission from: (NULL) (2001:700:100:202::105) Submitted by: hallvard Put(0 data items, MDB_MULTIPLE) stores 1 item. The doc does not warn against 0 items. I suggest supporting 0 items, it is a commonly supported convenience elsewhere (e.g. memcpy). Why does MDB_MULTIPLE require a cursor? mdb_put() rejects it.

1 0

Re: (ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by Sergio.Gelato＠astro.su.se 06 Dec '15

06 Dec '15

--tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry for the delay in submitting the patch. I wanted to double-check that no third party would lay a credible claim to it. For good measure, I have split the patch in two: the first only addresses the primary issue, and is obviously too simple to be copyrightable. The second addresses the need for falling back to straight Fisher-Yates in the middle of the shuffle, and may or may not be copyrightable so I'll say this: The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented therein were developed by me, Sergio Gelato. I have not assigned rights and/or interest in this work to any party. The modifications are subject to the following notice: Copyright 2015 Sergio Gelato Redistribution and use in source and binary forms, with or without modification, are permitted according to the terms of the OpenLDAP Public License. --tThc/1wpZn/ma/RB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Remove-bias-towards-the-first-record-in-RFC2782-shuf.patch" >From adb64c957308e5aee08a2f8aa893992a262d3243 Mon Sep 17 00:00:00 2001 From: Sergio Gelato <Sergio.Gelato(a)astro.su.se> Date: Sun, 6 Dec 2015 12:57:46 +0100 Subject: [PATCH 1/2] Remove bias towards the first record in RFC2782 shuffle implementation. Prior to this change, given two records of weight 1 the algorithm would return them in the order (0,1) with 100% probability instead of the desired 50%. This was due to an off-by-one error in the range test. srv_rand() returns a float in the range [0.0, 1.0[, so r is an integer in the range [0, total[. The correct probability for record 0 to be chosen is a[0].weight/total, not (a[0].weight+1)/total. --- libraries/libldap/dnssrv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libraries/libldap/dnssrv.c b/libraries/libldap/dnssrv.c index da89b4a..8d30552 100644 --- a/libraries/libldap/dnssrv.c +++ b/libraries/libldap/dnssrv.c @@ -234,7 +234,7 @@ static void srv_shuffle(srv_record *a, int n) { r = srv_rand() * total; for (j=0; j<p; j++) { r -= a[j].weight; - if (r <= 0) { + if (r < 0) { if (j) { srv_record t = a[0]; a[0] = a[j]; -- 2.1.4 --tThc/1wpZn/ma/RB Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-Improved-RFC2782-shuffle-when-several-but-not-all-re.patch" >From 6a03d17188964db50a1e8fa4b1a4f24b9db7d33e Mon Sep 17 00:00:00 2001 From: Sergio Gelato <Sergio.Gelato(a)astro.su.se> Date: Sun, 6 Dec 2015 13:33:17 +0100 Subject: [PATCH 2/2] Improved RFC2782 shuffle when several, but not all, records have weight 0. The fallback to a straight Fisher-Yates shuffle needs to occur whenever the sum of the *remaining* weights is zero, or else the remaining records will not be reordered. Testing only once at the beginning covers the case when all weights are zero, and obviously no shuffling is needed when only one weight is zero; but other weight combinations are possible, such as (1, 0, 0). --- libraries/libldap/dnssrv.c | 43 +++++++++++++++++-------------------------- 1 file changed, 17 insertions(+), 26 deletions(-) diff --git a/libraries/libldap/dnssrv.c b/libraries/libldap/dnssrv.c index 8d30552..63a920c 100644 --- a/libraries/libldap/dnssrv.c +++ b/libraries/libldap/dnssrv.c @@ -216,36 +216,27 @@ static void srv_shuffle(srv_record *a, int n) { for (i=0; i<n; i++) total += a[i].weight; - /* all weights are zero, do a straight Fisher-Yates shuffle */ - if (!total) { - while (n) { - srv_record t; - i = srv_rand() * n--; - t = a[n]; - a[n] = a[i]; - a[i] = t; - } - return; - } - /* Do a shuffle per RFC2782 Page 4 */ - p = n; - for (i=0; i<n-1; i++) { - r = srv_rand() * total; - for (j=0; j<p; j++) { - r -= a[j].weight; - if (r < 0) { - if (j) { - srv_record t = a[0]; - a[0] = a[j]; - a[j] = t; + for (p=n; p>1; a++, p--) { + if (!total) { + /* all remaining weights are zero, + do a straight Fisher-Yates shuffle */ + j = srv_rand() * p; + } else { + r = srv_rand() * total; + for (j=0; j<p; j++) { + r -= a[j].weight; + if (r < 0) { + total -= a[j].weight; + break; } - total -= a[0].weight; - a++; - p--; - break; } } + if (j && j<p) { + srv_record t = a[0]; + a[0] = a[j]; + a[j] = t; + } } } #endif /* HAVE_RES_QUERY */ -- 2.1.4 --tThc/1wpZn/ma/RB--

1 0

(ITS#8334) MDB_APPENDDUP does not catch overwrite(single item)
by h.b.furuseth＠usit.uio.no 06 Dec '15

06 Dec '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.17 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard mdb_put(,, key of non-F_DUPDATA node, old data, MDB_APPENDDUP) succeeds in an MDB_DUPSORT database. It should return MDB_KEYEXIST: It should not matter whether a lone item is inside a sub-DB/sub-page. Fix: diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 96c859e..2b7cd6b 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -6483,3 +6483,3 @@ more: if (!dcmp(data, &olddata)) { - if (flags & MDB_NODUPDATA) + if (flags & (MDB_NODUPDATA|MDB_APPENDDUP)) return MDB_KEYEXIST; Demo program: #include "lmdb.h" #include <stdio.h> #include <stdlib.h> #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(void) { int rc; MDB_env *env; B_txtxn *txn; MDB_dbi dbi; MDB_val key = {2, "k"}, data = {2, "d"}; E(mdb_env_create(&env)); E(mdb_env_open(env, "./testdb", 0, 0664)); E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_dbi_open(txn, NULL, MDB_DUPSORT, &dbi));%%0 E(mdb_drop(txn, dbi, 0)); E(mdb_put(txn, dbi, &key, &data, 0)); rc = mdb_put(txn, dbi, &key, &data, MDB_APPENDDUP); CHECK(rc == MDB_KEYEXIST, "MDB_APPENDDUP expected MDB_KEYEXIST"); mdb_txn_abort(txn); mdb_env_close(env); return 0; }

1 0

Re: (ITS#8333) NAME 'internationalISDNNumber' (RFC 4519)
by michael＠stroeder.com 05 Dec '15

05 Dec '15

Just in case the attachement gets messed up by ITS: ftp://ftp.openldap.org/incoming/openldap-its-8333.patch

1 0

Re: (ITS#8333) NAME 'internationalISDNNumber' (RFC 4519)
by michael＠stroeder.com 05 Dec '15

05 Dec '15

This is a multi-part message in MIME format. --------------080406050505060905010701 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit The attached patch (git master) fixes this. --------------080406050505060905010701 Content-Type: text/x-patch; name="openldap-its-8333.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="openldap-its-8333.patch" diff --git a/servers/slapd/schema/core.ldif b/servers/slapd/schema/core.ldif index aed7349..5abb7f0 100644 --- a/servers/slapd/schema/core.ldif +++ b/servers/slapd/schema/core.ldif @@ -193,7 +193,7 @@ olcAttributeTypes: ( 2.5.4.24 NAME 'x121Address' SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) # -olcAttributeTypes: ( 2.5.4.25 NAME 'internationaliSDNNumber' +olcAttributeTypes: ( 2.5.4.25 NAME 'internationalISDNNumber' DESC 'RFC2256: international ISDN number' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch @@ -377,7 +377,7 @@ olcObjectClasses: ( 2.5.6.4 NAME 'organization' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) # @@ -388,7 +388,7 @@ olcObjectClasses: ( 2.5.6.5 NAME 'organizationalUnit' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) # @@ -403,7 +403,7 @@ olcObjectClasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) # @@ -413,7 +413,7 @@ olcObjectClasses: ( 2.5.6.8 NAME 'organizationalRole' MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) @@ -430,7 +430,7 @@ olcObjectClasses: ( 2.5.6.10 NAME 'residentialPerson' MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ + teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) @@ -497,7 +497,7 @@ olcObjectClasses: ( 2.5.6.20 NAME 'dmd' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) # diff --git a/servers/slapd/schema/core.schema b/servers/slapd/schema/core.schema index 0257cff..3e44488 100644 --- a/servers/slapd/schema/core.schema +++ b/servers/slapd/schema/core.schema @@ -195,7 +195,7 @@ attributetype ( 2.5.4.24 NAME 'x121Address' SUBSTR numericStringSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} ) -attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber' +attributetype ( 2.5.4.25 NAME 'internationalISDNNumber' DESC 'RFC2256: international ISDN number' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch @@ -385,7 +385,7 @@ objectclass ( 2.5.6.4 NAME 'organization' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) @@ -396,7 +396,7 @@ objectclass ( 2.5.6.5 NAME 'organizationalUnit' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) @@ -411,7 +411,7 @@ objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) @@ -421,7 +421,7 @@ objectclass ( 2.5.6.8 NAME 'organizationalRole' MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) @@ -438,7 +438,7 @@ objectclass ( 2.5.6.10 NAME 'residentialPerson' MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ - teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ + teletexTerminalIdentifier $ telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) @@ -505,7 +505,7 @@ objectclass ( 2.5.6.20 NAME 'dmd' MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ - telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ + telephoneNumber $ internationalISDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) --------------080406050505060905010701--

1 0

Re: (ITS#8333) NAME 'internationalISDNNumber' (RFC 4519)
by hyc＠symas.com 05 Dec '15

05 Dec '15

michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: HEAD > OS: > URL: > Submission from: (NULL) (213.240.180.113) > > > Very minor nit-pick: > > It seems the attribute type description for 'internationalISDNNumber' is still > taken from: > > https://tools.ietf.org/html/rfc2256#section-5.26 > this has NAME 'internationaliSDNNumber' > > Instead of: > https://tools.ietf.org/html/rfc4519#section-2.15 > > There are several items in core.schema that need to be updated to RFC 45xx. Patches welcome. -- -- 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#8333) NAME 'internationalISDNNumber' (RFC 4519)
by michael＠stroeder.com 05 Dec '15

05 Dec '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (213.240.180.113) Very minor nit-pick: It seems the attribute type description for 'internationalISDNNumber' is still taken from: https://tools.ietf.org/html/rfc2256#section-5.26 this has NAME 'internationaliSDNNumber' Instead of: https://tools.ietf.org/html/rfc4519#section-2.15

1 0

Re: (ITS#8332) [LMDB][PATCH] Fix creating mandir
by hyc＠symas.com 04 Dec '15

04 Dec '15

timo.gurr(a)gmail.com wrote: > Full_Name: Timo Gurr > Version: > OS: Linux > URL: http://dpaste.com/19XBCGN.txt > Submission from: (NULL) (217.7.202.108) > > > Now that lmdb-0.9.17 creates the destination directories it fails with: Already fixed in git. 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#8332) [LMDB][PATCH] Fix creating mandir
by timo.gurr＠gmail.com 04 Dec '15

04 Dec '15

Full_Name: Timo Gurr Version: OS: Linux URL: http://dpaste.com/19XBCGN.txt Submission from: (NULL) (217.7.202.108) Now that lmdb-0.9.17 creates the destination directories it fails with: for f in mdb_stat.1 mdb_copy.1 mdb_dump.1 mdb_load.1; do cp $f /var/tmp/paludis/build/dev-db-lmdb-0.9.17/image//usr/share/man/man1; done Makefile:42: recipe for target 'install' failed%mamake -j5 -j1 DESTDIR=/var/tmp/paludis/build/dev-db-lmdb-0.9.17/image/ prefix=/usr/x86_64-pc-linux-gnu mandir=/usr/share/man install cp: cannot create regular file '/var/tmp/paludis/build/dev-db-lmdb-0.9.17/image//r%r/share/man/man1': No such file or directory cp: cannot create regular file '/var/tmp/paludis/build/dev-db-lmdb-0.9.17/image//usr/share/man/man1': No such file or directory cp: cannot create regular file '/var/tmp/paludis/build/dev-db-lmdb-0.9.17/image//usr/share/man/man1': No such file d directory cp: cannot create regular file '/var/tmp/paludis/build/dev-db-lmdb-0.9.17/image//usr/share/man/man1': No such file or directory make: *** [install] Error 1 due to not respecting the path from the newly introduced mandir variable, the patch in URL fixes the issue.

1 0

(ITS#8331) Download mirror list needs updating
by andrew.findlay＠skills-1st.co.uk 04 Dec '15

04 Dec '15

Full_Name: Andrew Findlay Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:8b0:8d0:f7e1::94) The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve in DNS.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs