openldap-bugs March 2015

openldap-bugs@openldap.org

25 participants
65 discussions

Re: (ITS#8070) test023 failures
by quanah＠zimbra.com 09 Mar '15

09 Mar '15

--On Tuesday, March 03, 2015 9:40 PM -0500 Aaron Richton <richton(a)nbcs.rutgers.edu> wrote: > Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference > from your earlier email)? That one failed after 80 runs. I think the answer is what Howard noted -- This test can fail on any release from 2006 and forward. :P --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 09 Mar '15

09 Mar '15

This is a cryptographically signed message in MIME format. --------------ms090109090403050107010203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hguo(a)suse.com wrote: > After experimenting with monitoring DB myself, I have figured out a=20 > minimal reproducable test case, I am afraid that the issue still shows = > up in 2.4.39 (distributed by SUSE Server 12). >=20 > The 2.4.40 changelog does not seem to suggest any relevant bug fix, but= =20 > I will give it a try anyway. You could easily try with 2.4.40 with my SLES12 packages: http://download.opensuse.org/repositories/home:/stroeder:/branches:/netwo= rk:/ldap/SLE_12/ I hope these will make it into mainstream: https://build.opensuse.org/package/show/home:stroeder:branches:network:ld= ap/openldap2 Ciao, Michael. --------------ms090109090403050107010203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgTCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGRTCCBS2gAwIBAgIDC01QMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIzMjA0NzU1 WhcNMTUwOTI0MjIwNTE4WjBfMRkwFwYDVQQNExA2TTJZN2k5ekR0ZTZqVXcwMR0wGwYDVQQD DBRtaWNoYWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRl ci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKcgfT19Tn3u/h+Di7CoUk M9TFAdX2rGt8z9ze95K0/JiXQmiuooesP6F8I1n5OjLrk031/287bpaecugMX4UTYORCLrWJ OArmNlOvl0kbVZCSTr3xQ1Y7zuVRYFFhiJQzvALd6TYTSvNH32ojETh0b3DCzX0Xcoom803y 0xPKg/DlWTDirHZJbnhYQEzHugJcEhk88MPyi+V53q8NXB5VJphcVRuTFsolHzsyyKHfgFr5 wzlIAdA1DXWNpImMV6ptCdeN/ScRKe+jRchyRz3DbjTDeNyC7pvlIhAEja+/lNoi/u8qo2TS j5wZz02cLDn/EP84AH0CP+oNxro2F4cJAgMBAAGjggLaMIIC1jAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFOPPUGEQ tk7fMQl+ZlDgj5zo0JciMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1Ud EQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEE AYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBw b2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBs aWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAB8HJ30IRnmli5Frde4TnF4mgikOiXbYDWYga 5GrFoEUi6aaYOhiv+1WAWh3/d69Ak75p3xPnCmihjjbYeQc3hrVQju6MIpxT8+tBLGa/bwAC yXgWj8idjWdIWMzLxjCPcQb4R2PVmkKTNNE0ZmMFrpSPtRjtRbvWRhxJ0IF7y9z1mLfo6cca RdE5YiKLfAEosMRmrGSfDQKP1NPLmXKWVjPIeS7hpcsM+GJitPOFaLCBibB5ou9b/KphWwdG lby53Oo6vrG9RVy5GZ8xMQ0ztFKVFlXDb7n4j7OfuOo6utQs7UU/sujlw+KWwylIw7Cgmc8t CA1m9c48U7pVoMI5ujGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwtNUDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0xNTAzMDkxNjQxNTZaMCMGCSqGSIb3DQEJBDEWBBSlbRvJ7H7b /+8N8deY0hKKcwad3DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQIDC01QMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwDQYJKoZIhvcNAQEBBQAEggEAWr95K7P8 t1rTB0VIkTa49cufYLvScGVI4UMDotkkXOm03cm0QnobjS/UDQSTvV7SHbhsv/ZF3kke3mPi 6IviHbHWJV+kGDqb5yGdS/JWQIWf0c62U5b8Mr64qFAc/dvQdGh86SyblEP9G+Ax6wky9gvo ixXHxrXX9x7eWkrNQCIXKP3RHGIqGLJOp5gGcLnXrv9zykgTMxzYYBNAMnqHWUilySyQCw2D rw37osvOxsnmfzW8w51xvs9dcmYeV3jRiTlWaZQA/p5XFs4A5wgUyvYvo+GX/HtPVIx2E7f9 6AcdkPjMR6CjaPTzHe2YJeY2i3EpqHrBF+chdSq+9hSgGQAAAAAAAA== --------------ms090109090403050107010203--

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 09 Mar '15

09 Mar '15

Hello Mr.Chu. After experimenting with monitoring DB myself, I have figured out a minimal reproducable test case, I am afraid that the issue still shows up in 2.4.39 (distributed by SUSE Server 12). The 2.4.40 changelog does not seem to suggest any relevant bug fix, but I will give it a try anyway. May I help by attaching the test case? Which Linux distribution would you like to use for testing? Thanks very much. Kind regards, Howard Guo SUSE LINUX Products GmbH

1 0

Re: (ITS#8073) pwdAccountLockedTime on Master/slave servers using slurp
by quanah＠zimbra.com 06 Mar '15

06 Mar '15

--On Friday, March 06, 2015 9:29 AM +0000 shashikanthbussa(a)gmail.com wrote: > Full_Name: shashikanth.bussa > Version: 2.3 > OS: RHEL 5.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.160.252.10) > > > Hi, > > iam using openldap 2.3. I configured master/slave using slurp. OpenLDAP 2.3 has been unsupported for years. I suggest you use a current, supported version of OpenLDAP. Also, the ITS system is for reporting bugs, not asking questions about how to do things. Your question would best be directed to openldap-technical(a)openldap.org once you're running something supported. I would note the LTB project has OpenLDAP 2.4 RPMs available for RHEL5. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8074) pwdAccountLockedTime on Master/slave servers using slurp
by shashikanthbussa＠gmail.com 06 Mar '15

06 Mar '15

Full_Name: shashikanth.bussa Version: 2.3 OS: RHEL 5.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Hi, iam using openldap 2.3. I configured master/slave using slurp. But, when the user account got locked on master .Still the users able to login using slave ldap server . How do i reflect "pwdAccountLockedTime" attribute on master and slave when the user account locked on master the user account has to be locked on slave as well. Please provide some information to configure in the above way to control the user accounts access.

1 0

(ITS#8073) pwdAccountLockedTime on Master/slave servers using slurp
by shashikanthbussa＠gmail.com 06 Mar '15

06 Mar '15

1 0

Re: (ITS#8072) ERROR- ldap-export unsuccessfully
by hyc＠symas.com 05 Mar '15

05 Mar '15

moinuddin_khan.h(a)alcatel-lucent.com wrote: > Full_Name: Moinuddin Khan > Version: 2.4.38 > OS: RHEL 6.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (135.245.115.244) > > > Hi, > > Ldap backup was working fine but all of sudden backup were unsuccessful. > > Not sure the reason because no changes been done on LDAP and also on machine. > > Following below error is seen while doing the backup > ----- > ------------------------------------------------------------------------------- > DATE: 02/21/15 TIME: 17:07:01: Archiving files > tar: Removing leading `/' from member names > 54e8ad25 mdb_db_open: database "cn=accesslog" cannot be opened, err -30790. Error -30790 is MDB_READERS_FULL - the configured number of concurrent readers has been reached. You need to raise this limit in your configuration, read the slapd-mdb(5) manpage. Also consider upgrading to a current release, which includes the error's message text as well as the error code. Note: the ITS is for actual bug reports - there is nothing in this report that indicates any bug in OpenLDAP software. You should have sent this question to the -technical mailing list. Closing this ITS. > Restore from backup! > 54e8ad25 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open > failed! (-30790) > slap_startup failed > ------------------------------------------------------------------------------- > DATE: 02/21/15 TIME: 17:07:01: ERROR- ldap-export unsuccessfully ! > DATE: 02/21/15 TIME: 17:07:01: Check /opt/openldap/log/backup_restore.log ! > ------- > > We are using > > # The backup/restore mechanism for openldap/server is based on: > # 1. slapcat > # 2. config files archive If you're using cn=config you should just use slapcat for everything. > > Regards > Moinuddin > > -- -- 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#8072) ERROR- ldap-export unsuccessfully
by moinuddin_khan.h＠alcatel-lucent.com 05 Mar '15

05 Mar '15

Full_Name: Moinuddin Khan Version: 2.4.38 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.115.244) Hi, Ldap backup was working fine but all of sudden backup were unsuccessful. Not sure the reason because no changes been done on LDAP and also on machine. Following below error is seen while doing the backup ----- ------------------------------------------------------------------------------- DATE: 02/21/15 TIME: 17:07:01: Archiving files tar: Removing leading `/' from member names 54e8ad25 mdb_db_open: database "cn=accesslog" cannot be opened, err -30790. Restore from backup! 54e8ad25 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open failed! (-30790) slap_startup failed ------------------------------------------------------------------------------- DATE: 02/21/15 TIME: 17:07:01: ERROR- ldap-export unsuccessfully ! DATE: 02/21/15 TIME: 17:07:01: Check /opt/openldap/log/backup_restore.log ! ------- We are using # The backup/restore mechanism for openldap/server is based on: # 1. slapcat # 2. config files archive Regards Moinuddin

1 0

Re: (ITS#8070) test023 failures
by hyc＠symas.com 04 Mar '15

04 Mar '15

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms080008030100090401070303 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > quanah(a)zimbra.com wrote: >> Confirmed with Howard this is a timing dependent script, and it's affec= > ted=20 >> by recent changes to the code base. refint used to do all its work=20 >> inline, but now it uses a separate thread, so on a slow enough machine,= > it=20 >> may not be done by the time the script runs its ldapsearch. > > Hmm, I'm not convinced that it really makes sense to have slapo-refint do= > ing > its job asynchronously. I'm very much concerned about data consistency w= > ith > sync jobs relying on e.g. group membership being immediately updated etc.= > > > I'd rather prefer to have slow write operations than having inconsistent > references. Can this be made configurable? Please...! > > Also how about impact on transaction handling in upcoming 2.5.x? Good questions for 2.5. accesslog reentrancy used to be a problem, back in 2006 but other changes have been made since then to remove that obstacle. Using LDAP txns internally would also fix the backendDB reentrancy issues. What sync jobs are you referring to? LDAP replication only promises eventual consistency; relying on instantaneous/continuous consistency here means you've got a design flaw. > Ciao, Michael. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8070) test023 failures
by hyc＠symas.com 04 Mar '15

04 Mar '15

richton(a)nbcs.rutgers.edu wrote: > On Tue, 3 Mar 2015, Quanah Gibson-Mount wrote: > >>> Seeing occasional failures on test023 using mdb. Takes a few runs (~30 >>> for me, recently) but seems to be more than a one-off... >>> >> >> Confirmed with Howard this is a timing dependent script, and it's >> affected by recent changes to the code base. refint used to do all its >> work inline, but now it uses a separate thread, so on a slow enough >> machine, it may not be done by the time the script runs its ldapsearch. >> >> I.e., doesn't appear to be a code bug. The test needs tweaking at some >> point to add some sleeps to handle this. :P > > Is OPENLDAP_REL_ENG_2_4_40-156-g4129e24 early enough (slight inference > from your earlier email)? That one failed after 80 runs. The refint behavior (using a separate thread) is not a recent change - that was made in 2006. But the test script is even older. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2015