- openldap-bugs - openldap.org

(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 01 Mar '13

01 Mar '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 20 Feb '13

20 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 20 Feb '13

20 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 20 Feb '13

20 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 20 Feb '13

20 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 20 Feb '13

20 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 19 Feb '13

19 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 17 Feb '13

17 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 14 Feb '13

14 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 14 Feb '13

14 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs