openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

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 11 Jan '16

11 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 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) 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs