openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#7537) ppolicy hangs slapd on 64bit version debian
by marek.platta＠blstream.com 06 Mar '13

06 Mar '13

Full_Name: Marek Platta Version: 2.4.23-7.2 OS: Debian6 URL: ldap.zumbai.pl Submission from: (NULL) (83.168.110.42) Hi!, I got problem implementing ppolicy on slapd 64bit version Tested on debian6 2.6.32-5-xen-amd64 with slapd 2.4.23-7.2 debian6 2.6.32-5-amd64 with slapd 2.4.23-7.2 and debian7 3.2.0-4-amd64 with slapd 2.4.31-1 Problem occours when i try to change parameters of ppolicy (using phpldapadmin, luma, etc.) for example: pwdMaxFailure: 6 to 5 Slapd process hangs and you can only stop it by "kill -9" On Debian 32bit works fine

1 0

(ITS#7536) mdb assert when cleaning up accesslog
by quanah＠OpenLDAP.org 05 Mar '13

05 Mar '13

Full_Name: Quanah Gibson-Mount Version: 2.4.34 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) When deleting entries from the accesslog, slapd dies after hitting an assert: 5136a59f => access_allowed: delete access to "cn=accesslog" "children" requested 5136a59f <= root access granted 5136a59f => access_allowed: delete access granted by manage(=mwrscxd) 5136a59f => access_allowed: delete access to "reqStart=20130227005207.000010Z,cn=accesslog" "entry" requested 5136a59f <= root access granted 5136a59f => access_allowed: delete access granted by manage(=mwrscxd) 5136a59f => mdb_dn2id_delete 0x5bd1e slapd: ./../../../libraries/liblmdb/mdb.c:4017: mdb_page_search_root: Assertion `(((mp)->mp_pb.pb.pb_lower - ((unsigned) __builtin_offsetof (MDB_page, mp_ptrs))) >> 1) > 1' failed.

1 0

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by hyc＠symas.com 01 Mar '13

01 Mar '13

jsynacek(a)redhat.com wrote: > On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote: >> On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: RE24 (7b03a58) >>> OS: Linux - Fedora 18 >>> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz >>> Submission from: (NULL) (209.132.186.34) >>> >>> >>> The setup is a master with an ldap backend and a slave consumer. If the master >>> is running and slave is not, delete operation results in the master being >>> stuck. >>> >>> Steps to reproduce: >>> 1. Start master. >>> 2. Add the example ldif. >>> 3. Delete one of the test org units. >>> 4. Observe the error. >>> >>> I would expect the master to honor the retry setting. >>> >> >> During the reproduction, it may be necessary to first have both master and slave >> running, delete a testing test org unit (so the first replication is >> successful), stop the slave and then continue to step 3. >> > > URL: > ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch This patch is clearly unacceptable. Your goto obviously skips over two _free() invocations, thus introducing a memory leak. -- -- 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#7535) MDB_PREV on a cursor which was at EOF
by hyc＠symas.com 01 Mar '13

01 Mar '13

claude(a)renegat.net wrote: > Full_Name: Claude Brisson > Version: 2.4.33 > OS: debian > URL: > Submission from: (NULL) (86.76.238.166) > > > When calling mdb_cursor_get with operation MDB_PREV on a cursor which was at > EOF, the last key is fetched as expected, but the cursor state is left > uninitialized. > > It looks like there is a missing "mc->mc_flags |= C_INITIALIZED" somewhere in > this case. This was fixed in git rev 5c1ee7f7ba9580d5ff29e74cbb02eee335c33d94 2012-10-22. The fix will be in 2.4.34. Bug reports should only be reported against latest source. 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

Re: (ITS#7531) Syncrepl push delete operation does not recover when slave is unavailable
by jsynacek＠redhat.com 01 Mar '13

01 Mar '13

On 02/27/2013 02:48 PM, jsynacek(a)redhat.com wrote: > On 02/27/2013 12:25 PM, jsynacek(a)redhat.com wrote: >> Full_Name: Jan Synacek >> Version: RE24 (7b03a58) >> OS: Linux - Fedora 18 >> URL: ftp://ftp.openldap.org/incoming/jsynacek-reproducer.tar.gz >> Submission from: (NULL) (209.132.186.34) >> >> >> The setup is a master with an ldap backend and a slave consumer. If the master >> is running and slave is not, delete operation results in the master being >> stuck. >> >> Steps to reproduce: >> 1. Start master. >> 2. Add the example ldif. >> 3. Delete one of the test org units. >> 4. Observe the error. >> >> I would expect the master to honor the retry setting. >> > > During the reproduction, it may be necessary to first have both master and slave > running, delete a testing test org unit (so the first replication is > successful), stop the slave and then continue to step 3. > URL: ftp://ftp.openldap.org/incoming/jsynacek-20130103-syncrepl-retry.patch The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Synacek am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7535) MDB_PREV on a cursor which was at EOF
by claude＠renegat.net 01 Mar '13

01 Mar '13

Full_Name: Claude Brisson Version: 2.4.33 OS: debian URL: Submission from: (NULL) (86.76.238.166) When calling mdb_cursor_get with operation MDB_PREV on a cursor which was at EOF, the last key is fetched as expected, but the cursor state is left uninitialized. It looks like there is a missing "mc->mc_flags |= C_INITIALIZED" somewhere in this case.

1 0

Re: (ITS#7534) slapschema: Error in man page
by masarati＠aero.polimi.it 01 Mar '13

01 Mar '13

On 03/01/2013 08:14 AM, marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.11.209.11) > > > Hi, I compiled RE24 as of 3rd testing call for 2.4.24. > By looking at the man page of the *slapschema* tool, I see this paragraph: > > ------------------ > EXAMPLES > To check the schema compliance of your SLAPD database blabla... > > /opt/openldap/sbin/*slapcat* -l errors.ldif > ------------------ > > I figure out this is an error. Fixed, thanks. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7412) check_password contrib module
by Guillaume.Rousse＠inria.fr 01 Mar '13

01 Mar '13

Ceci est un message signC) cryptographiquement au format MIME. --------------ms020304070209000508090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Any feedback in this request ? --=20 Guillaume Rousse INRIA, Direction des syst=E8mes d'information Domaine de Voluceau Rocquencourt - BP 105 78153 Le Chesnay Tel: 01 39 63 58 31 --------------ms020304070209000508090902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJYDCC BJUwggN9oAMCAQICECu5mlkLgTFbaSg8Mgwue0kwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UE BhMCTkwxDzANBgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMB4X DTExMDExMTAwMDAwMFoXDTE0MDExMDIzNTk1OVowWDELMAkGA1UEBhMCRlIxDjAMBgNVBAoT BUlOUklBMRkwFwYDVQQDExBHdWlsbGF1bWUgUk9VU1NFMR4wHAYJKoZIhvcNAQkCFg9yb3Vz c2VAaW5yaWEuZnIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDU9hkZ4j+MxXqQ 310Pah2QqpshhbJ8T9bACuYEcIdsZuxCYDUgJUVZJmHZK6IZbX4xiVr85pSHPJYG8z0nXXh4 ZXN0iPGVd2/YFpcqt2rB+KDydyrioXfLNiS6JZeKWEaPhKh/5C6/E898XwxB7VzV4meEDOpJ 4si8pNkCnPFFLMXfH/IG4lFvMj9qwfTIMGymB5/hLnZBm5/pK0Bm6wUESvN6YWFRjZ0ctd5p bvDG/vZpjQiavHC+r4YSLBgeFUb4W5N6XGXNsxZvUCRc4mC6XaiDaId75klRxFTdDmtynnLl 44mm6KJws158b3YC1kGACTYJaT+01R+D08PsVy2bAgMBAAGjggF2MIIBcjAfBgNVHSMEGDAW gBRjTUNaGUg/xEbBArq/7g7lgrdmpjAdBgNVHQ4EFgQUT8X4ighZJ1th5zEgoWZwKTXpQcIw DgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsG AQUFBwMCMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wPwYDVR0fBDgwNjA0oDKgMIYuaHR0 cDovL2NybC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNybDByBggrBgEFBQcB AQRmMGQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9jcnQudGNzLnRlcmVuYS5vcmcvVEVSRU5BUGVy c29uYWxDQS5jcnQwJgYIKwYBBQUHMAGGGmh0dHA6Ly9vY3NwLnRjcy50ZXJlbmEub3JnMCQG A1UdEQQdMBuBGUd1aWxsYXVtZS5Sb3Vzc2VAaW5yaWEuZnIwDQYJKoZIhvcNAQEFBQADggEB AEItBMmkv3DtWrx5KhZDlYV+ZLht8pFJTiK84GtnZ0dh+8pUSCzk8QS8Hly9gyiTfmTyZXiy UpnVXLLatBp3kgOw9ZCbdGj3TB6iOvHzHKaUHq/jdVf/S2CVlkU1ekRa5UnbsxFObZnZRu0G 2Lb4DbbwZYmS9OgGDzueBQ5B64X5yZXUueXnrgJMBa2JCT9QGvs6Px9src1ZyCArWTLGUmu2 NsaOI+WJMXdByLHOPJZp5A52dPPsnwDoyYrNrXPXngXXL0Pz3JPsKCA3lvb52oQkXDjqgm5o rYdHKhbxJvHG9WozyCppVBgSYve0IVyVfBWXLiCtTWnpY//DA23Hd2cwggTDMIIDq6ADAgEC AhBz/lf637jFCIF7Zrlr8C3vMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTA5 MDUxODAwMDAwMFoXDTI4MTIzMTIzNTk1OVowOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRF UkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyBXZ9TNqI6GQDc+7BUTDqx9KNYUaIYWgT/jwQOJKQ5v+W7Gwv7RX3HWA QUtkGvbbT2+P0CVFNfnqy0r6+9rT7UWIEZQ25MyoDe/FPTftFnvjwpWeWDN/Ivv4/+zmvtuu CmUlIofab4SLRuhAhig/v1YI4krpg6LpIvst+rYoH5HBw3H7U8ArTqQMoW6dVe3s4SSHOgji DRzkxE3Qyyf6hGTm0ZedViRbk7spLkPiQWo94kpl/JpfWoaHvIfHeYCWmVHGkA9kkZl9EN2s LAMq4Xhk/s49TvQrUBFL0VjUmwPwf/U7U7BTQ/vFL8QEKRo6rNdV6dEOldE7MX94T64pLQID AQABo4IBTTCCAUkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYE FGNNQ1oZSD/ERsECur/uDuWCt2amMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMBgGA1UdIAQRMA8wDQYLKwYBBAGyMQECAh0wWAYDVR0fBFEwTzBNoEugSYZHaHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25h bmRFbWFpbC5jcmwwbwYIKwYBBQUHAQEEYzBhMDgGCCsGAQUFBzAChixodHRwOi8vY3J0LnVz ZXJ0cnVzdC5jb20vVVROQUFBQ2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29j c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEABiupUy8T3Fw5FsyGn15Me3L7 7I1Vil6aCv9TTHb0Bj1Qz1fwos+vmYyq/qAZdj6ZAzL6dYM4irtrmqUME7LUG3bmlC5nmFnj kWwCkJqcyGBLVavKiFqNK+VplQMH0dQO/CQiLlmxY6Rf7dkjcuSczjpcbB9PqQDJHf76f0Ut ti6E3Q8noFkYTtV2JUX0mSZ522+fI/dDuysPBKOBJiy3ezX5PXdfQCHmfx2lllq90MsWOmy7 YYuK/QQ5RArLLOHLzi4QmBrb4JPtSWRkCCCft6NQ8KLdyrTGfAw9514V3CeG5Do7UloXq6kG UyudCXNkHAHD/TDShwNv5BUDejlfaDGCAwcwggMDAgEBME8wOzELMAkGA1UEBhMCTkwxDzAN BgNVBAoTBlRFUkVOQTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2ko PDIMLntJMAkGBSsOAwIaBQCgggGNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDMwMTA5MDAyMVowIwYJKoZIhvcNAQkEMRYEFKsRrZoC++nZcGWOqCBY Nzrw/GXBMF4GCSsGAQQBgjcQBDFRME8wOzELMAkGA1UEBhMCTkwxDzANBgNVBAoTBlRFUkVO QTEbMBkGA1UEAxMSVEVSRU5BIFBlcnNvbmFsIENBAhAruZpZC4ExW2koPDIMLntJMGAGCyqG SIb3DQEJEAILMVGgTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQD ExJURVJFTkEgUGVyc29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwbAYJKoZIhvcNAQkPMV8w XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEF AASCAQB/WC7RrTuKMWKftyMhcowMWi1CXlQcszruvqw/uemWKVjaylr67h7mNbejMwyVsDmm wus+XF62g/aqSbWwoqok/bslvwgg5sqv6pt4u7FSu7boRcRC0YPpCOH7sjMTYjmlUmAE9bW4 b4XKk8fZ06CMaSaLzYZn3KeVDl5xoXcjg42MbZXF3qqdXgQBgHeZr97puwvOg9sB52nDFPoM aorxsI4D7F0YcjNwZtksC5m5YAVcvZ/dlxdQLuIbxM+N9RWKhbZlFVb3B3FXzLmP191L4xtr 0N2xNSE4zONs/o9V0Xgl83d2XeBfeZEdwURmLFMS1gytFjnSHJmU95dU/9r8AAAAAAAA --------------ms020304070209000508090902--

1 0

(ITS#7534) slapschema: Error in man page
by marco.pizzoli＠gmail.com 28 Feb '13

28 Feb '13

Full_Name: Marco Pizzoli Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) Hi, I compiled RE24 as of 3rd testing call for 2.4.24. By looking at the man page of the *slapschema* tool, I see this paragraph: ------------------ EXAMPLES To check the schema compliance of your SLAPD database blabla... /opt/openldap/sbin/*slapcat* -l errors.ldif ------------------ I figure out this is an error. Marco

1 0

(ITS#7533) Don't install DB_CONFIG.example if built w/o back-hdb or back-bdb
by quanah＠OpenLDAP.org 27 Feb '13

27 Feb '13

Full_Name: Quanah Gibson-Mount Version: 2.4.33 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) When building without BDB support, DB_CONFIG.example is still copied to the state directory. Given a lack of BDB support, this seems pointless. installing slapd.ldif in /opt/zimbra/openldap-2.4.33.4z/etc/openldap ../../build/shtool install -c -m 600 slapd.ldif.tmp /opt/zimbra/openldap-2.4.33.4z/etc/openldap/slapd.ldif ../../build/shtool install -c -m 600 ./DB_CONFIG \ /opt/zimbra/openldap-2.4.33.4z/var/openldap-data/DB_CONFIG.example ../../build/shtool install -c -m 600 ./DB_CONFIG \ /opt/zimbra/openldap-2.4.33.4z/etc/openldap/DB_CONFIG.example ../../build/shtool mkdir -p /opt/zimbra/openldap-2.4.33.4z/etc/openldap/schema

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