- openldap-bugs - openldap.org

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

(ITS#7532) File descriptor needed before sending a request
by npmccallum＠redhat.com 27 Feb '13

27 Feb '13

Full_Name: Nathaniel McCallum Version: git master OS: fedora rawhide URL: https://github.com/npmccallum/openldap/commit/4e12a8ca31bcc6ad91f036b9200d7… Submission from: (NULL) (76.177.249.65) For asynchronous usage, it is common to create a "write" callback and perform all request sending in this callback from an internal queue. However, since ldap_open() was deprecated, there is no way to ensure a connection is established before the request is sent. This patch adds a function: int ldap_connect(LDAP *ld). You can call this function immediately after ldap_initialize() to ensure that a file descriptor is created for polling. No default behaviour changes, so applications that don't call ldap_connect() will always get the default lazy connection. 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, Nathaniel McCallum am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby places 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.

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 27 Feb '13

27 Feb '13

MDB can act on P_DIRTY without checking whether the page is dirty in this txn's dirty_list, or only some ancestor txn's: * mdb_cursor_put() line 5094, overwriting an F_BIGDATA node: Let a nested txn replace a big item whose page is dirty only in an ancestor txn. The parent will see the new value if the old page had room for it, even if the child aborted. Test program enclosed. Proposed fix: No need to search dirty_list, mdb_page_get() just did. Make it return where the page was found instead of an error code: <0 not found, 0 in map, >0 txn nesting level of the dirty_list with the page. Branch mdb/its7515 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git>, except the commit message may need tweaks. * mdb_xcursor_init1(): Sets DB_DIRTY if mc_top has P_DIRTY. Seems to cancel some MDB_PS_MODIFY activity. Is that OK? #include <lmdb.h> #include <stdio.h> int main(void) { static char pTxt[9999] = "parent", cTxt[9999] = "child"; MDB_val key = {1,""}, pVal = {9999,pTxt}, cVal = {9999,cTxt}, val; MDB_env *env; MDB_txn *txn, *ctxn; MDB_dbi dbi; mdb_env_create(&env); mdb_env_open(env, "test.mdb", MDB_NOSUBDIR, 0666); mdb_txn_begin(env, 0, 0, &txn); mdb_dbi_open(txn, 0, 0, &dbi); mdb_put(txn, dbi, &key, &pVal, 0); /* put "parent" */ mdb_txn_begin(env, txn, 0, &ctxn); mdb_put(ctxn, dbi, &key, &cVal, 0); /* overwrite with "child" */ mdb_txn_abort(ctxn); mdb_get(txn, dbi, &key, &val); /* should get "parent" */ puts(val.mv_data); /* ...but got "child" */ mdb_txn_commit(txn); mdb_env_close(env); return 0; } -- Hallvard

1 0

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

27 Feb '13

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. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

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

27 Feb '13

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.

1 0

(ITS#7530) gethostbyname_r fails if initial buffer size is too small
by ujvari＠microsec.hu 26 Feb '13

26 Feb '13

Full_Name: Aron Ujvari Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.163.11.62) OpenLDAP 2.4.33 (and before) does not handle properly when in function ldap_pvt_gethostbyname_a the 6-args version of gethostname_r returns ERANGE(34) error code because of too small buffer size. Although there is a loop in the function to increment the buffer size, but there is no check for ERANGE(34) result in the "r" variable, so no use of the loop. Relevant code is in libraries/libldap/util-int.c, lines 336-368. The gethostbyname man page clearly states at GNU Extensions section that gethostbyname_r can return non-zero value on failure, and return ERANGE if "buf" is too small, and the call should be retried with a larger buffer in this case.

1 0

Re: (ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 19 Feb '13

19 Feb '13

> If a thread modifies a named MDB database and closes it before > committing, the changes are lost. Documented "don't do that". mdb_dbi_close() could defer fully closing the DBI to the current write transaction if one exists. But that would require a mutex locked by [I think] mdb_env_commit(write txn), mdb_dbi_open, and mdb_dbi_close. > Test case (no nested txns): Bogus test program. The mdb_dbi_open() should use a named database: > E(mdb_dbi_open(txn, NULL, rdonly ? 0 : MDB_CREATE, &dbi)); E(mdb_dbi_open(txn, "db", rdonly ? 0 : MDB_CREATE, &dbi)); -- Hallvard

1 0

Re: (ITS#7529) mdb.c missing #if MDB_DEBUG at line 3514
by mark＠ibiblio.org 19 Feb '13

19 Feb '13

Thanks for the follow up Howard. I'm busy cranking out a number of dependent packages to compile some software, OpenLDAP being one of many. We have an aversion to the use of GCC here so situations like this compilation fail are somewhat common. It's nice though when code is kept simple and portable as it makes life easier. I don't normally spend much time debugging code and shipping fixes in a nice box with a pretty bow on it, I've just cut and pasted the two lines I used to allow compilation, part of the compile recipe used to crank out this 2.4.33 release. Hopefully that's enough to update your git archives. ta, Mark. On Wed, Feb 20, 2013 at 3:20 PM, Howard Chu <hyc(a)symas.com> wrote: > mark(a)ibiblio.org wrote: >> >> Full_Name: Mark >> Version: 2.4.33 >> OS: Solaris 10 & 11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (203.63.89.15) >> >> >> The stock 2.4.33 fails to compile mdb with this error: >> >> cc -I/usr/local/include -L/usr/local/lib -I../../../include >> -I../../../include >> -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include >> -L/usr/local/lib >> -c ./../../../libraries/libmdb/mdb.c -o mdb.o >> "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top >> "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must >> be >> pointer to struct/union >> cc: acomp failed for ./../../../libraries/libmdb/mdb.c >> >> The problem is top is defined inside #if MDB_DEBUG but used without the >> same #if >> qualifier. > > > Normally the DPRINTF macro would just expand to ((void) 0) if MDB_DEBUG is > not defined, so no, top is not being used without MDB_DEBUG. But looking > closer, I see this requires a C preprocessor that supports vararg macros. > Don't you have a C99-compatible toolchain on Solaris? > >> The fix is: >> /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i >> libraries/libmdb/mdb.c >> /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i >> libraries/libmdb/mdb.c > > > In the future, please use unified diff format. Preferably just use "git > format-patch" like it says on > http://www.openldap.org/devel/contributing.html > > We don't make changes in already released code, and line numbers alone are a > poor reference in development code. > > -- > -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by hyc＠symas.com 19 Feb '13

19 Feb '13

mark(a)ibiblio.org wrote: > Full_Name: Mark > Version: 2.4.33 > OS: Solaris 10 & 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.63.89.15) > > > The stock 2.4.33 fails to compile mdb with this error: Fixed in git rev 0108327c274a4b260b5b355d2a7c3ffc3a85f4c1 2012-10-25, closing this ITS. > > cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include > -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib > -c ./../../../libraries/libmdb/mdb.c -o mdb.o > "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top > "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be > pointer to struct/union > cc: acomp failed for ./../../../libraries/libmdb/mdb.c > > The problem is top is defined inside #if MDB_DEBUG but used without the same #if > qualifier. > > The fix is: > /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i > libraries/libmdb/mdb.c > /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c > > -- -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by hyc＠symas.com 19 Feb '13

19 Feb '13

mark(a)ibiblio.org wrote: > Full_Name: Mark > Version: 2.4.33 > OS: Solaris 10 & 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.63.89.15) > > > The stock 2.4.33 fails to compile mdb with this error: > > cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include > -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib > -c ./../../../libraries/libmdb/mdb.c -o mdb.o > "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top > "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be > pointer to struct/union > cc: acomp failed for ./../../../libraries/libmdb/mdb.c > > The problem is top is defined inside #if MDB_DEBUG but used without the same #if > qualifier. Normally the DPRINTF macro would just expand to ((void) 0) if MDB_DEBUG is not defined, so no, top is not being used without MDB_DEBUG. But looking closer, I see this requires a C preprocessor that supports vararg macros. Don't you have a C99-compatible toolchain on Solaris? > The fix is: > /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i > libraries/libmdb/mdb.c > /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c In the future, please use unified diff format. Preferably just use "git format-patch" like it says on http://www.openldap.org/devel/contributing.html We don't make changes in already released code, and line numbers alone are a poor reference in development code. -- -- 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#7529) mdb.c missing #if MDB_DEBUG at line 3514
by mark＠ibiblio.org 19 Feb '13

19 Feb '13

Full_Name: Mark Version: 2.4.33 OS: Solaris 10 & 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.63.89.15) The stock 2.4.33 fails to compile mdb with this error: cc -I/usr/local/include -L/usr/local/lib -I../../../include -I../../../include -I.. -I./.. -I./../../../libraries/libmdb -I/usr/local/include -L/usr/local/lib -c ./../../../libraries/libmdb/mdb.c -o mdb.o "./../../../libraries/libmdb/mdb.c", line 3514: undefined symbol: top "./../../../libraries/libmdb/mdb.c", line 3514: left operand of "->" must be pointer to struct/union cc: acomp failed for ./../../../libraries/libmdb/mdb.c The problem is top is defined inside #if MDB_DEBUG but used without the same #if qualifier. The fix is: /bin/perl -pe '($. == 3514) && s%^%#if MDB_DEBUG\n%' -i libraries/libmdb/mdb.c /bin/perl -pe '($. == 3517) && s%^%#endif\n%' -i libraries/libmdb/mdb.c

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 19 Feb '13

19 Feb '13

mdb_txn_commit(nested transaction) has more problems: - If the commit fails, it may modify the parent txn anyway. - The code to merge dirty_list into the parent is strange. I think it assumes that the dirty pages are either dirty in the parent, or have a higher page numbers than the parent's dirty pages parent. That can be wrong if a new freelist entry was used, or a "multi-page page". Branch mdb/tweaks2 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> includes a suggested fix, but could use some review - and testing by someone who actually uses nested txns. -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - another issue
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_mixed 0029F46EC1257B17_= Content-Type: multipart/alternative; boundary="=_alternative 0029F470C1257B17_=" --=_alternative 0029F470C1257B17_= Content-Type: text/plain; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 (openldap-648d28f.tar.gz) Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_= Content-Type: text/html; charset="US-ASCII" Hi, I am going on with my configuration and I realized that the subtree-include directives I use in my meta backend are not converted at all to cn=config. I cannot find them in cn=config tree. I don't know if you decide to open a new ITS or not. My slapd.conf is attached below. The slapd version is 2.4.33 as patched after ITS#7525 ( <form action=http://www.openldap.org/its/index.cgi/Software%20Bugs method=post>openldap-648d28f.tar.gz</form>)   Did anyone use subtrees with cn=config? Francesco Policastro --=_alternative 0029F470C1257B17_=-- --=_mixed 0029F46EC1257B17_= Content-Type: application/octet-stream; name="slapd.conf" Content-Disposition: attachment; filename="slapd.conf" Content-Transfer-Encoding: base64 IwojIFNlZSBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzIG9uIGNvbmZpZ3VyYXRpb24gb3B0aW9u cy4KIyBUaGlzIGZpbGUgc2hvdWxkIE5PVCBiZSB3b3JsZCByZWFkYWJsZS4KIwppbmNsdWRlCQkv dXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvY29yZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9s b2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL2Nvc2luZS5zY2hlbWEKaW5jbHVkZQkJL3Vzci9sb2Nh bC9ldGMvb3BlbmxkYXAvc2NoZW1hL2luZXRvcmdwZXJzb24uc2NoZW1hCmluY2x1ZGUJCS91c3Iv bG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9keW5ncm91cC5zY2hlbWEKCmF0dHJpYnV0ZXR5cGUg KCAxLjIuODQwLjExMzU1Ni4xLjQuMjIxIE5BTUUgJ3NBTUFjY291bnROYW1lJyAKCUVRVUFMSVRZ IGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScg U0lOR0xFLVZBTFVFICkKCmF0dHJpYnV0ZXR5cGUgKCAxLjIuODQwLjExMzU1Ni4xLjQuMzUgTkFN RSAnZW1wbG95ZWVJRCcgCglFUVVBTElUWSBjYXNlRXhhY3RNYXRjaCAKCVNZTlRBWCAnMS4zLjYu MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMTUnIFNJTkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICgg MS4yLjg0MC4xMTM1NTYuMS40LjggTkFNRSAndXNlckFjY291bnRDb250cm9sJyAKCUVRVUFMSVRZ IGludGVnZXJNYXRjaCAKCVNZTlRBWCAnMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcnIFNJ TkdMRS1WQUxVRSApCgphdHRyaWJ1dGV0eXBlICggMS4yLjg0MC4xMTM1NTYuMS40LjY1NiBOQU1F ICd1c2VyUHJpbmNpcGFsTmFtZScKCUVRVUFMSVRZIGNhc2VFeGFjdE1hdGNoIAoJU1lOVEFYICcx LjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4xNScgU0lOR0xFLVZBTFVFICkKCgojIEFsbG93IExE QVB2MiBjbGllbnQgY29ubmVjdGlvbnMuICBUaGlzIGlzIE5PVCB0aGUgZGVmYXVsdC4KYWxsb3cg YmluZF92MgoKcGlkZmlsZQkJL3Zhci9ydW4vc2xhcGQucGlkCgojIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0KYmFja2VuZAkJbWV0YQpiYWNrZW5kCQloZGIKIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJbWV0YQojIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0Kc3VmZml4CQkiZGM9bmV3Y28sZGM9Y29tIgpyZWFkb25seQlvbgpyb290ZG4JCSJj bj1MZGFwQmluZFVzZXIsZGM9bmV3Y28sZGM9Y29tIgpyb290cHcJCXNlY3JldDEKCiMgbm8gYW5v bnltb3VzIGJpbmQKcmVxdWlyZSBhdXRoYwpjb25uLXR0bCAyNW0KCmRuY2FjaGUtdHRsIGRpc2Fi bGVkCgphY2Nlc3MgdG8gKgogYnkgKiBub25lCgojIGZpcnN0IGRvbWFpbgoKdXJpICJsZGFwOi8v c2VydmVyMS5pdC5kb21haW4xLmNvbS9kYz1maXJzdCxkYz1uZXdjbyxkYz1jb20iCmlkYXNzZXJ0 LWJpbmQgYmluZG1ldGhvZD1zaW1wbGUgYmluZGRuPSJjbj1MREFQIFVzZXIsb3U9SVRTdGFmZixk Yz1pdCxkYz1kb21haW4xLGRjPWNvbSIgY3JlZGVudGlhbHM9c2VjcmV0MgpjaGFzZS1yZWZlcnJh bHMgbm8KcmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoK bWFwIG9iamVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPWZpcnN0LGRjPW5ld2Nv LGRjPWNvbSIgImRjPWl0LGRjPWRvbWFpbjEsZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PUFw cGxpY2F0aW9ucyxvdT1Hcm91cHMgU2hhcmVkLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKc3Vi dHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3QtbG9jYXRpb24sZGM9Zmlyc3QsZGM9bmV3Y28s ZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVVzZXJzLG91PTJuZC1sb2NhdGlvbixkYz1maXJz dCxkYz1uZXdjbyxkYz1jb20iCnN1YnRyZWUtaW5jbHVkZSAib3U9VXNlcnMsb3U9M3JkLWxvY2F0 aW9uLGRjPWZpcnN0LGRjPW5ld2NvLGRjPWNvbSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0 byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJhY2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlz aGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlw dGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgptYXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0 ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1BY2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNl ckFjY291bnRDb250cm9sICoKbWFwIGF0dHJpYnV0ZSBlbXBsb3llZUlEICoKbWFwIGF0dHJpYnV0 ZSB1c2VyUHJpbmNpcGFsTmFtZSAqCgojIG1hcCBldmVyeXRoaW5nIGVsc2UgdG8gbnVsbAptYXAg YXR0cmlidXRlICoKCiMgc2Vjb25kIGRvbWFpbgoKdXJpICJsZGFwOi8vc2VydmVyMi5kb21haW4y Lm5ldC9vdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNvbSIKaWRh c3NlcnQtYmluZCBiaW5kbWV0aG9kPXNpbXBsZSBiaW5kZG49ImNuPWxkYXAtMixjbj1Vc2Vycyxk Yz1kb21haW4yLGRjPW5ldCIgY3JlZGVudGlhbHM9c2VjcmV0MwpjaGFzZS1yZWZlcnJhbHMgbm8K cmViaW5kLWFzLXVzZXIgdHJ1ZQptYXAgb2JqZWN0Y2xhc3MgZ3JvdXBPZk5hbWVzICoKbWFwIG9i amVjdGNsYXNzIHBlcnNvbiAqCnN1ZmZpeG1hc3NhZ2UgImRjPXNlY29uZCxkYz1uZXdjbyxkYz1j b20iICJkYz1kb21haW4yLGRjPW5ldCIKc3VidHJlZS1pbmNsdWRlICJvdT1Vc2VycyxvdT0xc3Qt bG9jYXRpb24sb3U9b3JnYW5pemF0aW9uYWxVbml0LGRjPXNlY29uZCxkYz1uZXdjbyxkYz1jb20i CnN1YnRyZWUtaW5jbHVkZSAib3U9TXktb3Usb3U9MXN0LWxvY2F0aW9uLG91PW9yZ2FuaXphdGlv bmFsVW5pdCxkYz1zZWNvbmQsZGM9bmV3Y28sZGM9Y29tIgpzdWJ0cmVlLWluY2x1ZGUgIm91PVJl bW90ZSBTaXRlcyxvdT1vcmdhbml6YXRpb25hbFVuaXQsZGM9c2Vjb25kLGRjPW5ld2NvLGRjPWNv bSIKCiMgbWFwIHZpc2libGUgYXR0cmlidXRlcyB0byBtYXRjaGluZyBhdHRyaWJ1dGVzIG9uIGJh Y2tlbmQKbWFwIGF0dHJpYnV0ZSBkaXN0aW5ndWlzaGVkTmFtZSAqCm1hcCBhdHRyaWJ1dGUgZ2l2 ZW5OYW1lICoKbWFwIGF0dHJpYnV0ZSBkZXNjcmlwdGlvbiAqCm1hcCBhdHRyaWJ1dGUgc24gKgpt YXAgYXR0cmlidXRlIGNuICoKbWFwIGF0dHJpYnV0ZSBtYWlsICoKbWFwIGF0dHJpYnV0ZSBzYW1B Y2NvdW50TmFtZSAqCm1hcCBhdHRyaWJ1dGUgdXNlckFjY291bnRDb250cm9sICoKbWFwIGF0dHJp YnV0ZSBlbXBsb3llZUlEIHBhZ2VyCm1hcCBhdHRyaWJ1dGUgdXNlclByaW5jaXBhbE5hbWUgKgoK IyBtYXAgZXZlcnl0aGluZyBlbHNlIHRvIG51bGwKbWFwIGF0dHJpYnV0ZSAqCgojIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KZGF0YWJhc2UJaGRiCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpzdWZm aXgJCWRjPWRvbWFpbi1ncm91cHMsZGM9Y29tIgpyb290ZG4JCSJjbj1ncm91cHNSb290LGRjPWRv bWFpbi1ncm91cHMsZGM9Y29tIgpyb290cHcJCXNlY3JldDQKb3ZlcmxheQkJZHlubGlzdAoKZHlu bGlzdC1hdHRyc2V0IGdyb3VwT2ZVUkxzIG1lbWJlclVSTCBtZW1iZXIKZGlyZWN0b3J5CS91c3Iv bG9jYWwvdmFyL29wZW5sZGFwLWRhdGEKCg== --=_mixed 0029F46EC1257B17_=--

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: >> Can't use a DBI from an aborted child txn, unlike aborted main txn: > (...) > Well, closing the DBI in mdb_txn_abort() caused problems. A fix > in the opposite direction is easy, if we want DBIs to work that > way: mdb_env_open() can open the DBI in any parent txns too. To get more consistent behavior, if that wasn't clear: Any parent txn will receive the DBI independently of commit/abort, just like the MDB_env. Future children of a preexisting txn still differ, which is probably for the best. Changing that would take locking. -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 18 Feb '13

18 Feb '13

I wrote: > Fixed in mdb.master, except: > >> Can't use a DBI from an aborted child txn, unlike aborted main txn: Yet it may be possible to use the DBI in the parent txn if mdb_dbi_open() reused a closed DBI - but it may have the wrong flags and cmp functions, or also wrong MDB_db if the close happened after txn_begin. > Fixing this caused problems and got reverted. > The DBI is available to next non-nested txn Well, closing the DBI in mdb_txn_abort() caused problems. A fix in the opposite direction is easy, if we want DBIs to work that way: mdb_env_open() can open the DBI in any parent txns too. ldbm.h: "[The database handle] denotes the name and parameters of a database, independently of whether such a database exists. It will not exist if the transaction which created it aborted, nor if another process deleted it. Preexisting transactions, other than the current transaction and any parents, must not use the new handle. Nor must their children." -- Hallvard

1 0

Re: (ITS#7525) Bad conversion to cn=config format - solved
by francesco.policastro＠selex-es.com 18 Feb '13

18 Feb '13

--=_alternative 0039EFE9C1257B16_= Content-Type: text/plain; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_= Content-Type: text/html; charset="US-ASCII" My suggestion is to modify the test suite to include an uri containing spaces, just to avoid regressions. Ciao, Francesco Policastro --=_alternative 0039EFE9C1257B16_=--

1 0

Re: (ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 17 Feb '13

17 Feb '13

Related: If a DB is dropped (and thus the DBI closed) in a txn which has modified it, mdb_txn_commit attempted to save the DB. This could corrupt another DB if mdb_dbi_open() in another thread had reused the DBI. This is now fixed in mdb.master. -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 16 Feb '13

16 Feb '13

> Here are some crashes with nested liblmdb transactions. Fixed in mdb.master, except: > Can't use a DBI from an aborted child txn, unlike aborted main txn: > > $ ./bug R[cp] # Create a named DB and put an item there > $ ./bug [[o}g] # Open that DB in a child, abort, use the DBI > 40: mdb_get(txn, dbi, &key, &rdata): Invalid argument Fixing this caused problems and got reverted. The DBI is available to next non-nested txn: $ ./bug [[o}}[g] # Open DB in child, abort both txns, use DBI in new txn -- Hallvard

1 0

(ITS#7528) ldapadd not working while adding attribute having long list of values
by omkar＠mithi.com 15 Feb '13

15 Feb '13

Full_Name: Omkar Phadke Version: 2.4.30 OS: Red Hat Enterprise Linux Server release 6.0 (Santiago) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.111.211.142) I am trying to add bellow ldif file. Command ldapadd -d -1 -cxv -D "cn=Manager,dc=mithibo" -f /root/TestSmall.ldif -w "$LDAP_ROOT_PASSWD" > /root/log_failed.txt 2>&1 I get error ldap_add: Undefined attribute type (17) additional info: ame: attribute type undefined ldapadd exe is not present separately, in folder /usr/local/openldap/bin/ ldapadd is linked with ldapmodify Actually homecountry attribute's value is list of countries and it is very long bellow i give ldif file. but if i extract ldapmodify file from older version 2.4.23 and copied to /usr/local/openldap/bin/ then above command executes successfully. ---------------------------------------------------------------------------------- Ldif file /root/TestSmall.ldif contents -- dn: cn=homecountry,ou=boproperty,ou=user,cn=template.int,ou=domains,cn=enterprise,o=enterprise, dc=mithibo cn:homecountry objectClass: top objectClass: person objectClass: organizationalPerson objectClass: mithiBO admincompulsary: f admineditable: t allowblankvalue: t compulsary: f default: India record: user description: Home country dircontainer: cd editable: t encodedecode: f inheritsvalue: f label: Home country ldapstorage: homecountry list: Afghanistan:Afghanistan,Albania:Albania,Algeria:Algeria,American:American,Samoa:Samoa,Andorra:Andorra,Angola:Angola,Anguilla:Anguilla,Antarctica:Antarctica,Antigua and Barbuda:Antigua and Barbuda,Argentina:Argentina,Armenia:Armenia,Aruba:Aruba,Australia:Australia,Austria:Austria,Azerbaijan:Azerbaijan,Bahamas:Bahamas,Bahrain:Bahrain,Bangladesh:Bangladesh,Barbados:Barbados,Belarus:Belarus,Belgium:Belgium,Belize:Belize,Benin:Benin,Bermuda:Bermuda,Bhutan:Bhutan,Bolivia:Bolivia,Bosnia and Herzegovina:Bosnia and Herzegovina,Botswana:Botswana,Bouvet Island:Bouvet Island,Brazil:Brazil,British Indian Ocean Territory:British Indian Ocean Territory,British Virgin Islands:British Virgin Islands,Brunei:Brunei,Bulgaria:Bulgaria,Burkina Faso:Burkina Faso,Burundi:Burundi,Cambodia:Cambodia,Cameroon:Cameroon,CanadaCape:CanadaCape,Verde:Verde,Cayman Islands:Cayman Islands,Central:Central,African:African,Republic:Republic,Chad:Chad,Chile:Chile,China:China,Christmas Island:Christmas Island,Cocos Islands:Cocos Islands,Colombia:Colombia,Comoros:Comoros,Congo:Congo,Cook Islands:Cook Islands,Costa Rica:Costa Rica,Croatia:Croatia,Cuba:Cuba,Cyprus:Cyprus,Czech Republic:Czech Republic,Denmark:Denmark,Djibouti:Djibouti,Dominica:Dominica,Dominican Republic:Dominican Republic,East Timor:East Timor,Ecuador:Ecuador,Egypt:Egypt,El Salvador:El Salvador,Equatorial Guinea:Equatorial Guinea,Eritrea:Eritrea,Estonia:Estonia,Ethiopia:Ethiopia,Falkland Islands:Falkland Islands,Faroe Islands:Faroe Islands,Fiji:Fiji,Finland:Finland,France:France,French Guiana:French Guiana,French Polynesia:French Polynesia,French Southern Territories:French Southern Territories,Gabon:Gabon,Gambia:Gambia,Georgia:Georgia,Germany:Germany,Ghana:Ghana,Gibraltar:Gibraltar,Greece:Greece,Greenland:Greenland,Grenada:Grenada,Guadeloupe:Guadeloupe,Guam:Guam,Guatemala:Guatemala,Guinea:Guinea,Guinea-Bissau:Guinea-Bissau,Guyana:Guyana,Haiti:Haiti,Heard and McDonald Islands:Heard and McDonald Islands,Honduras:Honduras,Hong Kong:Hong Kong,Hungary Iceland:Hungary Iceland,India:India,Indonesia:Indonesia,Iran:Iran,Iraq:Iraq,Ireland:Ireland,Israel:Israel,Italy:Italy,Ivory Coast:Ivory Coast,Jamaica:Jamaica,Japan:Japan,Jordan:Jordan,Kazakhstan:Kazakhstan,Kenya:Kenya,Kiribati North:Kiribati North,Korea South:Korea South,Korea:Korea,Kuwait:Kuwait,Kyrgyzstan:Kyrgyzstan,Laos:Laos,Latvia:Latvia,Lesotho:Lesotho,Liberia:Liberia,Libya:Libya,Liechtenstein:Liechtenstein,Lithuania:Lithuania,Luxembourg:Luxembourg,Macau:Macau,Macedonia:Macedonia,Madagascar:Madagascar,Malawi:Malawi,Malaysia:Malaysia,Maldives:Maldives,Mali:Mali,Malta:Malta,Marshall Islands:Marshall Islands,Martinique:Martinique,Mauritania:Mauritania,Mauritius:Mauritius,Mayotte:Mayotte,Mexico:Mexico,Micronesia:Micronesia,Moldova:Moldova,Monaco:Monaco,Mongolia:Mongolia,Montserrat:Montserrat,Morocco:Morocco,Mozambique:Mozambique,Myanmar:Myanmar,Namibia:Namibia,Nauru:Nauru,Nepal:Nepal,Netherlands:Netherlands,Netherlands Antilles:Netherlands Antilles,New Caledonia:New Caledonia,New Zealand:New Zealand,Nicaragua:Nicaragua,Niger:Niger,Nigeria:Nigeria,Niue:Niue,Norfolk Island:Norfolk Island,Northern Mariana Islands:Northern Mariana Islands,Norway:Norway,Oman:Oman,Pakistan:Pakistan,Palau:Palau,Panama:Panama,Papua New Guinea:Papua New Guinea,Paraguay:Paraguay,Peru:Peru,Philippines:Philippines,Pitcairn Island:Pitcairn Island,Poland:Poland,Portugal:Portugal,Puerto Rico:Puerto Rico,Qatar:Qatar,Reunion:Reunion,Romania:Romania,Russia:Russia,RwandaS. Georgia and S. Sandwich Isls.:RwandaS. Georgia and S. Sandwich Isls.,Saint Kitts and Nevis Saint Lucia:Saint Kitts and Nevis Saint Lucia,Saint Vincent and The Grenadines:Saint Vincent and The Grenadines,Samoa:Samoa,San Marino:San Marino,Sao Tome and Principe:Sao Tome and Principe,Saudi Arabia:Saudi Arabia,Senegal:Senegal,Seychelles:Seychelles,Sierra Leone:Sierra Leone,Singapore:Singapore,Slovakia:Slovakia,Slovenia:Slovenia,Solomon Islands:Solomon Islands,Somalia:Somalia,South Africa:South Africa,Spain:Spain,Sri Lanka:Sri Lanka,St. Helena:St. Helena,St. Pierre and Miquelon:St. Pierre and Miquelon,Sudan:Sudan multiline: f multivalue: f property: t readable: t showinusage: t sync: f timestampproperty: whenchanged type: list isregenrequired: f isregencomposite: f hasscope: f allowedonlicenseexpiry: f --------------------------------------------------------------------------------

1 0

Re: (ITS#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu 13 Feb '13

13 Feb '13

--On Thursday, February 14, 2013 02:53:54 AM +0000 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: RE24 pulled 11-Feb-2013 >> OS: debian wheezy (testing) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (67.180.239.194) >> >> >> When attempting to add a new entry to a back-mdb database I am seeing >> the following failure: >> >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" >> ldap_add: Other (e.g., implementation specific) error (80) >> additional info: index generation failed > > Since you pulled RE24 on Feb 11, your code should be producing > additional error info in syslog. Please send the slapd logs > associated with this error. Here is a log entry showing the error. (I should have looked at this sooner.) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 fd=20 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/ slapd/ldapi) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND dn="" method=163 Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=e xternal,cn=auth(a)stanford.edu" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth(a)stanford.edu" Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=0 RESULT tag=97 err=0 text= Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=1 ADD dn="suRegID=uniqueid1,cn=people,dc=stanford,dc=edu " Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: => mdb_idl_insert_keys: c_put lo/hi failed: Invalid argument (22) Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=1 RESULT tag=105 err=80 text=index generation failed Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 op=2 UNBIND Feb 13 15:05:27 ldap-unixdev1 slapd[30667]: conn=1074 fd=20 closed Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University

1 0

Re: (ITS#7527) Problems Adding entries to back-mdb database
by hyc＠symas.com 13 Feb '13

13 Feb '13

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: RE24 pulled 11-Feb-2013 > OS: debian wheezy (testing) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.180.239.194) > > > When attempting to add a new entry to a back-mdb database I am seeing > the following failure: > > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" > ldap_add: Other (e.g., implementation specific) error (80) > additional info: index generation failed Since you pulled RE24 on Feb 11, your code should be producing additional error info in syslog. Please send the slapd logs associated with this error. -- -- 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#7527) Problems Adding entries to back-mdb database
by whm＠stanford.edu 13 Feb '13

13 Feb '13

Full_Name: Bill MacAllister Version: RE24 pulled 11-Feb-2013 OS: debian wheezy (testing) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.180.239.194) When attempting to add a new entry to a back-mdb database I am seeing the following failure: SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "suRegID=uniqueid1,cn=people,dc=stanford,dc=edu" ldap_add: Other (e.g., implementation specific) error (80) additional info: index generation failed The attribute that is causing the failure is suPrivilegeGroup. The schema definition for this attribute is: olcAttributeTypes: ( StanfordLDAPattributeType:19 NAME ( 'suPrivilegeGroup' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) The index defined for this attribute is: olcDbIndex: suPrivilegeGroup eq,sub I have been able to successfully load the entry by either: * Modifying the index definition by removing the substring index, i.e. 'olcDbIndex: suPrivilegeGroup eq,sub'. or * Modifying the data. The value 'suPrivilegeGroup: n:all' succeeds and the value 'suPrivilegeGroup: ne:all' fails. Here is a complete failing entry: dn: suRegID=uniqueid1,cn=people,dc=stanford,dc=edu objectClass: suPerson objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: person displayName: Bill MacAllister suCN: bill macallister suDisplayNameLF: MacAllister, Bill suGeneralID: billmacallister suRegID: uniqueid1 suRegisteredName: William Henry MacAllister suRegisteredNameLF: MacAllister, William Henry suSN: macallister suUniqueIdentifier: unique1 sn: macallister o: University ou: netdocs-access:all uid: whm cn: bill macallister cn: william macallister givenName: william givenName: bill suPrivilegeGroup: ne:all I first started investigating this problem because some entries where not present in the directory after a complete refresh from an ldif dumped from a 2.4.26 server. I used slapadd to load the ldif and there were no error messages during the load, just some entries were missing. I expect that the lack of an error message from slapadd is a separate, but related issue.

1 0

Re: (ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com 13 Feb '13

13 Feb '13

--=_alternative 0036332BC1257B11_= Content-Type: text/plain; charset="US-ASCII" Installed the master revision (openldap-648d28f.tar.gz) Test ok . Many thanks, Francesco Policastro From: Pierangelo Masarati <masarati(a)aero.polimi.it> To: <francesco.policastro(a)selex-es.com> Cc: <openldap-its(a)openldap.org> Date: 12/02/2013 17:23 Subject: Re: (ITS#7525) Bad conversion to cn=config format Fixed in git master, please test. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano --=_alternative 0036332BC1257B11_= Content-Type: text/html; charset="US-ASCII" Installed the master revision (openldap-648d28f.tar.gz) Test ok . Many thanks, Francesco Policastro <table width=100%> <tr valign=top> <td>From: <td>Pierangelo Masarati <masarati(a)aero.polimi.it> <tr valign=top> <td>To: <td><francesco.policastro(a)selex-es.com> <tr> <td valign=top>Cc: <td><openldap-its(a)openldap.org> <tr valign=top> <td>Date: <td>12/02/2013 17:23 <tr valign=top> <td>Subject: <td>Re: (ITS#7525) Bad conversion to cn=config format</table> <hr noshade> <tt>Fixed in git master, please test.  p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano </tt> --=_alternative 0036332BC1257B11_=--

1 0

Re: (ITS#7526) Segfault in slapd-meta during olcDbUri modify
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

> Full_Name: John Madden > Version: 2.4.32 > OS: Linux / RHEL6/64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (168.91.17.188) > > > slapd-meta frontend to another slapd, perform an ldapmodify on the > olcDbUri > (incidentally while troubleshooting incorrect proxy behavior) results in a > segfault. Your backtrace looks useless; however, I could reproduce the problem. A(n almost blind) fix is coming. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7526) Segfault in slapd-meta during olcDbUri modify
by jmadden＠ivytech.edu 12 Feb '13

12 Feb '13

Full_Name: John Madden Version: 2.4.32 OS: Linux / RHEL6/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.91.17.188) slapd-meta frontend to another slapd, perform an ldapmodify on the olcDbUri (incidentally while troubleshooting incorrect proxy behavior) results in a segfault. (gdb) attach 5979 Attaching to process 5979 Reading symbols from /usr/local/libexec/slapd...(no debugging symbols found)...done. Reading symbols from /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/BerkeleyDB.5.1/lib/libdb-5.1.so Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f9dc6485700 (LWP 6928)] [New Thread 0x7f9dc6c86700 (LWP 6927)] [New Thread 0x7f9dc7487700 (LWP 5980)] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libsasl2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /usr/lib64/libssl.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libssl.so.10 Reading symbols from /usr/lib64/libcrypto.so.10...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/libcrypto.so.10 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libgssapi_krb5.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libgssapi_krb5.so.2 Reading symbols from /lib64/libkrb5.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /lib64/libk5crypto.so.3...(no debugging symbols found)...done. Loaded symbols for /lib64/libk5crypto.so.3 Reading symbols from /lib64/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libz.so.1 Reading symbols from /lib64/libfreebl3.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libfreebl3.so Reading symbols from /lib64/libkrb5support.so.0...(no debugging symbols found)...done. Loaded symbols for /lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /usr/lib64/sasl2/libcrammd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libcrammd5.so Reading symbols from /usr/lib64/sasl2/libanonymous.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so Reading symbols from /usr/lib64/sasl2/libplain.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so Reading symbols from /usr/lib64/sasl2/libsasldb.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libsasldb.so Reading symbols from /lib64/libdb-4.7.so...(no debugging symbols found)...done. Loaded symbols for /lib64/libdb-4.7.so Reading symbols from /usr/lib64/sasl2/liblogin.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so Reading symbols from /usr/lib64/sasl2/libdigestmd5.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so Reading symbols from /usr/lib64/sasl2/libgssapiv2.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-md5-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 glibc-2.12-1.80.el6_3.6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 libcom_err-1.41.12-12.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-25.el6_3.1.x86_64 zlib-1.2.3-27.el6.x86_64 (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9dc6c86700 (LWP 6927)] 0x0000000000516517 in ?? () (gdb) backtrace full #0 0x0000000000516517 in ?? () No symbol table info available. #1 0x0000000000412b2c in ?? () No symbol table info available. #2 0x0000000000438a8b in ?? () No symbol table info available. #3 0x00000000004393b6 in ?? () No symbol table info available. #4 0x00000000004212d9 in ?? () No symbol table info available. #5 0x0000000000421ab5 in ?? () No symbol table info available. #6 0x0000000000570da0 in ?? () No symbol table info available. #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) info registers rax 0x19 25 rbx 0x7f9dc6c83340 140315621602112 rcx 0x0 0 rdx 0x19 25 rsi 0x7f9dc6c83340 140315621602112 rdi 0x7f9dc6c83340 140315621602112 rbp 0x1dbaf00 0x1dbaf00 rsp 0x7f9dc6c80bf0 0x7f9dc6c80bf0 r8 0x0 0 r9 0x7f9dc6c830c0 140315621601472 r10 0x84db78 8706936 r11 0x0 0 r12 0x1d55390 30757776 r13 0x7f9dc6c83340 140315621602112 r14 0x7f9db8112be0 140315374726112 r15 0x7f9db8112670 140315374724720 rip 0x516517 0x516517 eflags 0x10283 [ CF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/16i $pc => 0x516517: mov 0x0,%rdi 0x51651f: test %rdi,%rdi 0x516522: je 0x515858 0x516528: callq 0x43b4e0 0x51652d: xor %ebp,%ebp 0x51652f: movq $0x0,0x0 0x51653b: jmpq 0x515745 0x516540: andl $0xfffffe7f,0x8 0x51654b: xor %ebp,%ebp 0x51654d: jmpq 0x515745 0x516552: andl $0xfffdffff,0x8 0x51655d: xor %ebp,%ebp 0x51655f: jmpq 0x515745 0x516564: movq $0x0,0x138(%rbp) 0x51656f: xor %ebp,%ebp 0x516571: jmpq 0x515745 (gdb) thread apply all backtrace Thread 4 (Thread 0x7f9dc7487700 (LWP 5980)): #0 0x0000003310ce8713 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000041e5fa in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f9dc6c86700 (LWP 6927)): #0 0x0000000000516517 in ?? () #1 0x0000000000412b2c in ?? () #2 0x0000000000438a8b in ?? () #3 0x00000000004393b6 in ?? () #4 0x00000000004212d9 in ?? () #5 0x0000000000421ab5 in ?? () #6 0x0000000000570da0 in ?? () #7 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #8 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f9dc6485700 (LWP 6928)): #0 0x000000331140b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x0000000000570df5 in ?? () #2 0x0000003311407851 in start_thread () from /lib64/libpthread.so.0 #3 0x0000003310ce811d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f9dcb64e7c0 (LWP 5979)): #0 0x00000033114080ad in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000041b951 in ?? () #2 0x00000000004081c5 in ?? () #3 0x0000003310c1ecdd in __libc_start_main () from /lib64/libc.so.6 #4 0x0000000000406a69 in ?? () #5 0x00007fffe3969bc8 in ?? () #6 0x000000000000001c in ?? () #7 0x0000000000000005 in ?? () #8 0x00007fffe396bd7a in ?? () #9 0x00007fffe396bd93 in ?? () #10 0x00007fffe396bd96 in ?? () #11 0x00007fffe396bdbe in ?? () #12 0x00007fffe396bdc1 in ?? () #13 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7525) Bad conversion to cn=config format
by masarati＠aero.polimi.it 12 Feb '13

12 Feb '13

Fixed in git master, please test. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7525) Bad conversion to cn=config format
by francesco.policastro＠selex-es.com 12 Feb '13

12 Feb '13

Full_Name: Francesco Policastro Version: 2.4.33 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.127.80.134) A slapd.conf using meta backend can include the following uri definition that is accepted as legal uri "ldap://server2.domain2.net/ou=org Unit,dc=second,dc=newco,dc=com" idassert-bind bindmethod=simple binddn="cn=ldap-2,cn=Users,dc=domain2,dc=net" credentials=secret3 chase-referrals no rebind-as-user true map objectclass groupOfNames * map objectclass person * suffixmassage "dc=second,dc=newco,dc=com" "dc=domain2,dc=net" subtree-include "ou=Users,ou=1stlocation,ou=org Unit,dc=second,dc=newco,dc=com" ... "slaptest -f slapd.conf" returns "config file testing succeeded" "slaptest -f slapd.conf -F slapd.d" converts to cn=config format "slaptest -F slapd.d" issues an error: 511a57ef olcDbURI: value #0: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>". 511a57ef config error processing olcMetaSub={1}uri,olcDatabase={1}meta,cn=config: unable to parse URI #0 in "olcDbURI <protocol>://<server>[:port]/<naming context>" slaptest: bad configuration directory! I know that the offending words are in the "ou=org Unit" directive; in fact "ou=orgUnit" (with no space) works. The uri sintax permits to enclose the string in quotes and one assumes that spaces are legal. They are only in slapd.conf because the cn=config conversion does not accept them.

1 0

(ITS#7524) Seg fault of slapd with back-meta traffic
by jorge.perez.burgos＠ericsson.com 12 Feb '13

12 Feb '13

Full_Name: Jorge Perez Burgos Version: 2.4.32 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) PROBLEM Sending high load traffic to several slapd servers that are proxying the traffic to only one slapd. It can seen that in this situation originating servers crash sporadically. POSSIBLE SOLUTION In back-meta/conn.c in the method meta_back_retry it seems that the binding flag is not set properly in the following situation: /* restore the "binding" flag, in case */ if ( binding ) { LDAP_BACK_CONN_BINDING_SET( msc ); } if ( rc == LDAP_SUCCESS ) { quarantine = 0; rc = meta_back_single_dobind( op, rs, mcp, candidate, sendok, mt->mt_nretries, 0 ); Setting the binding flag before calling meta_back_single_dobind seems to solve the issue (LDAP_BACK_CONN_BINDING_SET( msc );) CORE DUMP TRACE This is the backtrace of the core dumped. Program terminated with signal 6, Aborted. #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00002ad023473f45 in raise () from /lib64/libc.so.6 #1 0x00002ad023475340 in abort () from /lib64/libc.so.6 #2 0x00002ad02346d486 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000051cfe1 in meta_back_bind_op_result (op=0x69d2580, rs=0x2aab95e57c70, mc=0x2aab62a44740, candidate=2, msgid=1, sendok=<value optimized out>, dolock=0) at bind.c:392 #4 0x000000000051d130 in meta_back_proxy_authz_bind (mc=0x2aab62a44740, candidate=2, op=0x69d2580, rs=0x2aab95e57c70, sendok=LDAP_BACK_DONTSEND, dolock=0) at bind.c:1590 #5 0x000000000051d37b in meta_back_single_dobind (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND, nretries=<value optimized out>, dolock=0) at bind.c:605 #6 0x000000000052714d in meta_back_retry (op=0x69d2580, rs=0x2aab95e57c70, mcp=0x2aab95e56920, candidate=2, sendok=LDAP_BACK_DONTSEND) at conn.c:769 #7 0x00000000004db025 in meta_back_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:1154 #8 0x00000000004636d9 in fe_op_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:402 #9 0x00000000004c4e02 in overlay_op_walk (op=0x69d2580, rs=0x2aab95e57c70, which=op_search, oi=0x8088000, on=0x0) at backover.c:671 #10 0x00000000004c5307 in over_op_func (op=0x69d2580, rs=0x2aab95e57c70, which=op_search) at backover.c:723 #11 0x0000000000463ee5 in do_search (op=0x69d2580, rs=0x2aab95e57c70) at search.c:247 #12 0x0000000000460f45 in connection_operation (ctx=0x2aab95e57e50, arg_v=<value optimized out>) at connection.c:1308 #13 0x0000000000461e05 in connection_read_thread (ctx=0x2aab95e57e50, argv=<value optimized out>) at connection.c:1444 #14 0x000000000055cb7c in ldap_int_thread_pool_wrapper (xpool=0x8028000) at tpool.c:688 #15 0x00002ad022ec92a3 in start_thread () from /lib64/libpthread.so.0 #16 0x00002ad02350549d in clone () from /lib64/libc.so.6

1 0

(ITS#7523) ldap valsort control is not documented
by quanah＠OpenLDAP.org 11 Feb '13

11 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) The slapo-valsort(5) man page does not mention the fact that the LDAP_CONTROL_VALSORT (1.3.6.1.4.1.4203.666.5.14 can be specified to allow the returning of the values with weights present.

1 0

(ITS#7522) Admin Guide: bugs in example
by openldap＠laimbock.com 10 Feb '13

10 Feb '13

Full_Name: Patrick Laimbock Version: RE24 OS: CentOS 6.3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.210.175.192) In the OpenLDAP Admin Guide on page 38 it says: 34. olcSuffix: "dc=example,dc=com" 35. olcDbDirectory: /usr/local/var/openldap-data 36. olcRootDN: "cn=Manager,dc=example,dc=com" 37. olcRootPW: secret 38. olcDbIndex: uid pres,eq 39. olcDbIndex: cn,sn,uid pres,eq,approx,sub When I try to slapadd that example config I get the following errors: 5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) 5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax 1.3.6.1.4.1.1466.115.121.1.12) /etc/openldap34/slapd.d: line 1: duplicate index definition for attr "uid" When I remove the quotes from the olcSuffix (line 34) and olcRootDN (line 36) entries and remove the double uid from either line 38 or line 39 then the slapadd action is successful.

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by balint＠balintreczey.hu 07 Feb '13

07 Feb '13

Hi Howard, Thank you! I have updated the Debian bug report [1]. Cheers, Balint [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038 2013/2/7 Howard Chu <hyc(a)symas.com>: > I've committed an alternate fix for this to git master, filed against > ITS#6365. Please test and let us know your results, thanks. > The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 > > -- > -- 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#7503) slapcat: retry a few times when retrieving an entry
by hyc＠symas.com 07 Feb '13

07 Feb '13

I've committed an alternate fix for this to git master, filed against ITS#6365. Please test and let us know your results, thanks. The patch is in commit 853b9d1335d27e280751e9cfb8ca6b5356ffec73 -- -- 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#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by hyc＠symas.com 06 Feb '13

06 Feb '13

quanah(a)zimbra.com wrote: > --On Wednesday, February 06, 2013 6:33 PM +0000 TCera(a)sjrwmd.com wrote: > >> --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ >> Content-Type: text/plain; charset="us-ascii" >> Content-Transfer-Encoding: quoted-printable >> >> xwiki uses jldap. >> >> http://www.openldap.org/jldap/ > > JLDAP is written in java, and does not use the OpenLDAP C libraries. If > you are going to use Java, I highly recommend you look at the unboundID SDK. > > I would also note that PHP's LDAP Support is known to be utterly broken. > There is no indication anywhere here in your report that indicates a bug > with the OpenLDAP software. If he could reproduce the issue using OpenLDAP's command line tools, there would be reason to suspect libldap. But no such problem occurs for me using e.g. ldapsearch. 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#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by quanah＠zimbra.com 06 Feb '13

06 Feb '13

--On Wednesday, February 06, 2013 6:33 PM +0000 TCera(a)sjrwmd.com wrote: > --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xwiki uses jldap. > > http://www.openldap.org/jldap/ JLDAP is written in java, and does not use the OpenLDAP C libraries. If you are going to use Java, I highly recommend you look at the unboundID SDK. I would also note that PHP's LDAP Support is known to be utterly broken. There is no indication anywhere here in your report that indicates a bug with the OpenLDAP software. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by TCera＠sjrwmd.com 06 Feb '13

06 Feb '13

--_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable xwiki uses jldap. http://www.openldap.org/jldap/ Without delving deeper, I don't know whether jldap uses openldap libraries = or not. I thought that it might since it was an openldap project. Though = if jldap and openldap are different enough then this issue points to a prob= lem then with Active Directory. On the other hand, Windows login, email, .= ..etc. were unaffected by the comma and period in the password. Regardless - take the comma and period out of my password, both tikiwiki an= d xwiki work. --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> xwiki uses jldap.<o:p></o:p> <o:p> </o:p> http://www.openldap.org/jldap/<o:p></o:p> <o:p> </o:p> Without delving deeper, I don't know whether jldap u= ses openldap libraries or not.  I thought that it might since it was a= n openldap project.  Though if jldap and openldap are different enough= then this issue points to a problem then with Active Directory.  On the other hand, Windows login, email, …et= c. were unaffected by the comma and period in the password.  <o:p></o:p> <o:p> </o:p> Regardless - take the comma and period out of my pas= sword, both tikiwiki and xwiki work. <o:p></o:p> </div> </body> </html> --_000_EE54DB3B9E0D63489B0845CE62912E8C3BAD846ABY2PRD0511MB441_--

1 0

Re: (ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by quanah＠zimbra.com 06 Feb '13

06 Feb '13

--On Wednesday, February 06, 2013 12:50 PM +0000 tim(a)cerazone.net wrote: > Full_Name: Tim Cera > Version: 2.4.23-26.el6_3.2 > OS: CentOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.252.34.1) > > > Currently using tikiwki (PHP) with LDAP authentication, and began > experimenting with xwiki (Java) also with LDAP authentication. Both > against an Active Directory server. With both systems you cannot > authenticate a password with either a comma or a period, so suspect it is > the underlying OpenLDAP libraries. The test password had both a comma > and period, and the account is locked right now so I can't easily test > which one or both are required to activate the bug. I would suspect you are incorrect if you are having this problem with a Java program, since Java would not be linked to the OpenLDAP C libraries. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7521) Passwords with either a comma or period don't authenticate against AD LDAP
by tim＠cerazone.net 06 Feb '13

06 Feb '13

Full_Name: Tim Cera Version: 2.4.23-26.el6_3.2 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.252.34.1) Currently using tikiwki (PHP) with LDAP authentication, and began experimenting with xwiki (Java) also with LDAP authentication. Both against an Active Directory server. With both systems you cannot authenticate a password with either a comma or a period, so suspect it is the underlying OpenLDAP libraries. The test password had both a comma and period, and the account is locked right now so I can't easily test which one or both are required to activate the bug. I did try looking for this bug suspecting that it would have been reported, and didn't find it. Hope this isn't a duplicate.

1 0

Re: (ITS#7520) back-ldap omit-unknown-schema
by tedcheng＠symas.com 05 Feb '13

05 Feb '13

Please find the patch at: https://dl.dropbox.com/u/94235048/back_ldap_omit_unknown_schema.patch The attached file is derived from OpenLDAP Software. By virtue of my employment agreement with Symas Corporation, I have assigned my rights and interest to Symas Corporation. Symas Corporation has not assigned rights and/or interest to any party. I, Ted C. Cheng, am authorized by Symas Corporation, my employer, to release this work under the following terms. Symas Corporation 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. Ted C. Cheng Symas Corporation

1 0

(ITS#7520) back-ldap omit-unknown-schema
by tedcheng＠symas.com 05 Feb '13

05 Feb '13

Full_Name: Ted C. Cheng Version: HEAD OS: Linux/Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.174.253.197) This patch allows back-ldap to ignore unknown schema defined by a remote (foreign) LDAP server. Clients do not need to handle schema that are not local to the slapd server.

1 0

Re: (ITS#7518) nssov sync'ed up with nss_pam_ldapd.0.8.11
by tedcheng＠symas.com 05 Feb '13

05 Feb '13

The attached file is derived from OpenLDAP Software. By virtue of my employment agreement with Symas Corporation, I have assigned my rights and interest to Symas Corp. Symas Corporation has not assigned rights and/or interest to any party. I, Ted C. Cheng, am authorized by Symas Corporation, my employer, to release this work under the following terms. Symas Corporation 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. Ted C. Cheng Symas Corporation On Feb 4, 2013, at 5:01 PM, openldap-its(a)OpenLDAP.org wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7518. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7518) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7518) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7518 > > Please remember to retain your issue tracking number (ITS#7518) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

Re: (ITS#7519) a suspicious bug about OpenLDAP Software 2.4 Administrator's Guide
by michael＠stroeder.com 05 Feb '13

05 Feb '13

This is a cryptographically signed message in MIME format. --------------ms040601090102040300070904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ouyangguang(a)huawei.com wrote: > But when I browse the functions "ldap_bind" > and "ldap_bind_s", none of LDAP_AUTH_KRBV4, LDAP_AUTH_KRBV41 or LDAP_AU= TH_KRBV42 > mode is supported. So I think it is wrong with the document. > Anybody knows that? This is not a bug. The options you mentioned were for deprecated Krb4 (as= the names show) which you definitely don't want to use. Please post questions about how to use SASL/GSSAPI-Krb5 bind to the openldap-technical mailing list and not into the bug tracker. Ciao, Michael. --------------ms040601090102040300070904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMjA1MTQ0NjI1WjAjBgkq hkiG9w0BCQQxFgQU/uCgt9UJwE1eF6/+PhHEzEpoylkwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEAdrTmfQp7wmG7rRQ65ZLKN1YbhvY2QtL3Qqg9OscNNpJEfVUzvVbycBXl5zgKz8WAIrzq X44MVDRKMAOf2/voXuKVg29pPIJE2gcGHdY+7IrLeLssuLE5tbqY9yX3BM7Utp1IihOIeAeU wYBOZbthOxrb21aQf8pWatOmyHlkdzlomqjX/h8WBcccCtK66zGVjncDFqxPIarq/M0PSIn3 qJmcz5KBWU6wIt7p//D5hbnqHvyW9j9uHi8HrusNPSdssL+FO8cG0A/HIyOu0Mwp39tet6LR AGpWDGJqWJHYWS4TuNlJWOhPq3esTUJkPSSoh3TT/Z6a+9ExohQgpfLOFgAAAAAAAA== --------------ms040601090102040300070904--

1 0

(ITS#7519) a suspicious bug about OpenLDAP Software 2.4 Administrator's Guide
by ouyangguang＠huawei.com 05 Feb '13

05 Feb '13

Full_Name: OuYang Guang Version: openldap-2.4.33 OS: Suse linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (219.133.0.1) I'm trying build a ldap client with OpenLDAP-2.4.33 and I want to use Kerberos authentication services. According to the chapter "4.2.3. Kerberos Authentication Service" of OpenLDAP Software 2.4 Administrator's Guide, OpenLDAP clients and servers support Kerberos authentication services. But when I browse the functions "ldap_bind" and "ldap_bind_s", none of LDAP_AUTH_KRBV4, LDAP_AUTH_KRBV41 or LDAP_AUTH_KRBV42 mode is supported. So I think it is wrong with the document. Anybody knows that? Thank you!

1 0

(ITS#7518) nssov sync'ed up with nss_pam_ldapd.0.8.11
by tedcheng＠symas.com 04 Feb '13

04 Feb '13

Full_Name: Ted C. Cheng Version: HEAD OS: Linux/Solaris URL: https://dl.dropbox.com/u/94235048/nssov_sync_w_nss_pam_ldapd_0_8_11.patch Submission from: (NULL) (76.174.253.197) Please find nssov patch in the link provided: 1. Sync'ed up with nss-pam-ldapd 0.8.11: * added nssov_config support * added password_prohibit_message, similar to PADL * self-pwd-changes are made as user identities; root changing user passwords as nssov-pam-pwdmgr-dn 2. Fixed a bug that connection DN was not constructed correctly. 3. Fixed a service debug crash issue when protocol value is NULL 4. Added more debugging msgs

1 0

(ITS#7517) mdb_dbi_close(dbi updated in existing txn) breaks
by h.b.furuseth＠usit.uio.no 02 Feb '13

02 Feb '13

Full_Name: Hallvard B Furuseth Version: mdb.master 48dc782ea612f85e8356a50bfbafe22e5be121cf OS: Linux x86_64 URL: Submission from: (NULL) (193.69.163.163) Submitted by: hallvard If a thread modifies a named MDB database and closes it before committing, the changes are lost. The mdb_dbi_close() doc only says we must not close DBs which _other_ theads will reference. I expect mdb_dbi_close() could check if the env has an active write txn where the DB is dirty, and mdb_put() it first. And in any parent txns which have it open, dunno if that's doable. If not, in this case maybe _close() could stash away the DB info so mdb_txn_commit()/mdb_txn_reset0() can save the updates. Note that another mdb_dbi_open() can reuse the closed DBI, so carelessness could e.g. save the changes with the wrong DB name. Test case (no nested txns): #include <lmdb.h> #include <stdio.h> #include <stdlib.h> int main(void) { char *dbname = "test.mdb"; MDB_env *env; MDB_txn *txn; MDB_dbi dbi; int rdonly, rc; MDB_val key = {3, "foo"}, data = {3, "abc"}, rdata; # define E(e) { rc = (e); if (rc) { fprintf(stderr, "%s:%d: %s: %s\n", \ __FILE__, __LINE__, #e, mdb_strerror(rc)); abort(); } } remove(dbname); for (rdonly = 0; rdonly <= MDB_RDONLY; rdonly += MDB_RDONLY) { E(mdb_env_create(&env)); E(mdb_env_set_maxdbs(env, 1)); E(mdb_env_open(env, dbname, MDB_NOSYNC|MDB_NOSUBDIR, 0666)); E(mdb_txn_begin(env, NULL, rdonly, &txn)); E(mdb_dbi_open(txn, NULL, rdonly ? 0 : MDB_CREATE, &dbi)); if (!rdonly) { E(mdb_put(txn, dbi, &key, &data, 0)); mdb_dbi_close(env, dbi); } else { E(mdb_get(txn, dbi, &key, &rdata)); } E(mdb_txn_commit(txn)); mdb_env_close(env); } return 0; }

1 0

Re: (ITS#7516) Mysql backend is readonly with included metadata sql files
by masarati＠aero.polimi.it 01 Feb '13

01 Feb '13

On 02/01/2013 01:56 PM, povilas(a)Daukas.lt wrote: > Full_Name: Povilas Daukas > Version: any > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.63.107.40) > > > > Hi, > > While trying to setup mysql as backend to the openldap server i noticed that it > only allowed reading from the database but not updating as the metadata was not > there to handle the updates. > > So I adopted the functions and sql from PostgreSQL to make it read write. the > file to modify is below. Thank you, but please follow guidelines for contributions here <http://www.openldap.org/devel/contributing.html> to ease review and integration. Thanks, p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs