openldap-bugs September 2014

openldap-bugs@openldap.org

23 participants
58 discussions

Re: (ITS#7943) LMDB fails to process transactions after map resize
by carlopires＠gmail.com 18 Sep '14

18 Sep '14

--001a1135fa9258513c0503605842 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I forgot to attach the error message. Here is it: $ ./mtest7 map size is 10MB new map size is 20MB mtest7.c:69: mdb_put(txn, dbi, &key, &data, 0): MDB_BAD_TXN: Transaction cannot recover - it must be aborted Abortado (imagem do n=C3=BAcleo gravada) 2014-09-18 21:29 GMT-03:00 <openldap-its(a)openldap.org>: > > *** 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#7943. > > 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#7943) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#7943) > > 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=3D7943 > > Please remember to retain your issue tracking number (ITS#7943) > 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. > > --=20 Carlo Pires --001a1135fa9258513c0503605842 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I forgot to attach the error message. Here is it: = </div> $ ./mtest7 <div>map size is 10MB new map size is 20MB mt= est7.c:69: mdb_put(txn, dbi, &key, &data, 0): MDB_BAD_TXN: Transact= ion cannot recover - it must be aborted Abortado (imagem do n=C3=BAcleo = gravada) </div></div><div class=3D"gmail_extra"> <div class=3D"gm= ail_quote">2014-09-18 21:29 GMT-03:00 <<a href=3D"mai= lto:openldap-its@openldap.org" target=3D"_blank">openldap-its(a)openldap.org<= /a>>: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br= > report has been assigned the tracking number ITS#7943. 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.=C2=A0 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.=C2=A0 Note that<br= > any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7943) in the subject will automatically be attached to the issue report. =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.= org">openldap-its(a)openldap.org</a>?subject=3D(ITS#7943) You may follow the progress of this report by loading the following URL in a web browser: =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D794= 3" target=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7943</a= > Please remember to retain your issue tracking number (ITS#7943) on any further messages you send to us regarding this report.=C2=A0 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. =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" ta= rget=3D"_blank">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> -- =C2=A0 Carlo Pires </div> --001a1135fa9258513c0503605842--

1 0

(ITS#7943) LMDB fails to process transactions after map resize
by carlopires＠gmail.com 18 Sep '14

18 Sep '14

Full_Name: Carlo Pires Version: LMDB 0.9.14 OS: Ubuntu Linux 14.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (177.53.184.142) LMDB 0.9.14 is refusing to process new transactions after map resize. The following test case shows the error: /* mtest7.c - memory-mapped database tester/toy */ /* Tests for DB map resize */ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <assert.h> #include "lmdb.h" #define E(expr) CHECK((rc = (expr)) == MDB_SUCCESS, #expr) #define EX(err, expr) CHECK((rc = (expr)) == (err), #expr) #define RES(err, expr) ((rc = expr) == (err) || (CHECK(!rc, #expr), 0)) #define CHECK(test, msg) ((test) ? (void)0 : ((void)fprintf(stderr, \ "%s:%d: %s: %s\n", __FILE__, __LINE__, msg, mdb_strerror(rc)), abort())) int main(int argc,char * argv[]) { int rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; MDB_envinfo minfo; char kval[32]; char* sval = calloc(1, 8*1024*1024); assert(sval); // create database E(mdb_env_create(&env)); E(mdb_env_set_mapsize(env, 10*1024*1024)); E(mdb_env_set_maxdbs(env, 0)); E(mdb_env_open(env, "./testdb", MDB_NORDAHEAD|MDB_NOLOCK|MDB_NOSYNC, 0664)); // starts dbi E(mdb_txn_begin(env, NULL, 0, &txn)); E(mdb_open(txn, NULL, MDB_CREATE, &dbi)); E(mdb_txn_commit(txn)); // check database mapsize E(mdb_env_info(env, &minfo)); printf("map size is %ldMB\n%, C minfo.me_mapsize/1048576); // try to insert data E(mdb_txn_begin(env, NULL, 0, &txn)); key.mv_size = sizeof(kval); key.mv_data = &kval; data.mv_size = 8*1024*1024; data.mv_data = sval; sprintf(kval, "0"); E(mdb_put(txn, dbi, %kekey, &data, 0)); sprintf(kval, "1"); EX(MDB_MAP_FULL, mdb_put(txn, dbi, &key, &data, 0)); // abort transaction and increase map size mdb_txn_abort(txn); mdb_env_set_mapsize(env, 20*1024*1024); // check database mapsize E(mdb_env_info(env, &minfo)); printf("new map size is %ldMB\n", minfo.me_mapsize/1048576); // try to insert data again E(mdb_txn_begin(env, NULL, 0, &txn)); sprintf(kval, "0"); E(mdb_put(txn, dbi, &key, &data, 0)); sprintf(kval, "1"); E(mdb_put(txn, dbi, &key, &data, 0)); E(mdb_txn_commit(txn)); mdb_env_close(env); free(sval); return 0; } The code worked fine until LMDB 0.9.13.

1 0

(ITS#7942) memory leak in control parsing
by hyc＠openldap.org 17 Sep '14

17 Sep '14

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (8.25.222.90) Submitted by: hyc A number of controls allocate additional structures in their parsing, stored in the op->o_controls[] array. Nothing cleans these up at the end of the operation. Usually these don't leak because they're allocated on the thread slab, but if the incoming request is large enough it can force them into regular malloc. Fix coming shortly.

1 0

(ITS#7941) crash in slap_bv2ad using repeated tags
by hyc＠openldap.org 17 Sep '14

17 Sep '14

Full_Name: Howard Chu Version: 2.4.x OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (8.25.222.90) Submitted by: hyc Fix coming shortly

1 0

Re: (ITS#6035) slapd requires restart after modifying olcAuthzRegexp
by ryan＠nardis.ca 16 Sep '14

16 Sep '14

Hi, Following up from <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761407#23>: This limitation seems to still exist (tried RE24 and master). Until it can be fixed, please document it clearly in slapd-config.5 (and maybe the admin guide too), as well as any related attrs if they also require a restart (olcAuthzPolicy?). It's surprising behaviour, since almost every other attribute does support online configuration. Proposed patch follows. thanks, Ryan diff --git a/doc/man/man5/slapd-config.5 b/doc/man/man5/slapd-config.5 index c5bf06f..7c39369 100644 --- a/doc/man/man5/slapd-config.5 +++ b/doc/man/man5/slapd-config.5 @@ -409,6 +409,10 @@ values can be specified to allow for multiple matching and replacement patterns. The matching patterns are checked in the order they appear in the attribute, stopping at the first successful match. +Note that changes to +.B olcAuthzRegexp +take effect the next time the server is started, not immediately upon +changing the configuration. .\".B Caution: .\"Because the plus sign + is a character recognized by the regular expression engine, .\"and it will appear in names that include a REALM, be careful to escape the

1 0

Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by quanah＠zimbra.com 16 Sep '14

16 Sep '14

--On Wednesday, September 17, 2014 3:08 AM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.39 >> OS: Linux 3.11 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> Found this at a customer site. They loaded an LDIF file that had the >> child of an entry, but not the entry itself. slapadd then created a >> glue entry to account for this, however there some significant problems >> with this process >> >> a) The glue entry is not syntactically correct. There is no RDN value. >> >> b) It is impossible to use a filter with ldapsearch to find the entry. >> It appears the objectClass index is utterly broken. > > Works as designed. Closing this ITS. Even with -M, it appears impossible to find a specific glued entry, which is problematic when attempting to find if it indeed exists or not outside of a slapcat, or trying to parse (in this case) the 306 broken glued entries that exist in the DB. It would be useful to be able (with -M) to actually search for and find the specific entry so that the account management client can then proceed accordingly. Right now, a search for the specific entry results in error code 32, so then the account management software attempts to create it, which results in error code 68. The software then has no way to find the entry and decide if it needs modification or deletion. OTOH, it is entirely the clients fault for providing bad input, so I'm not sure how hard we should chase it. :P --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by hyc＠symas.com 16 Sep '14

16 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > Found this at a customer site. They loaded an LDIF file that had the child of > an entry, but not the entry itself. slapadd then created a glue entry to > account for this, however there some significant problems with this process > > a) The glue entry is not syntactically correct. There is no RDN value. > > b) It is impossible to use a filter with ldapsearch to find the entry. It > appears the objectClass index is utterly broken. Works as designed. Closing this ITS. > > Example entry, and the child that created it: > > dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 > creatorsName: cn=config > createTimestamp: 20140731145640Z > entryCSN: 20140731145640.037371Z#000000#002#000000 > modifiersName: cn=config%momodifyTimestamp: 20140731145640Z > objectClass: top > objectClass: glue > structuralObjectClass: glue > > dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy > objectClass: zimbraDataSource > objectClass: zimbraImapDataSource > .... > > As we can see, the glue entry has no RDN attribute at all. It is also > impossible to find this entry via ldapsearch; > > ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url > -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd > [zimbra@ldap01 ~]$ > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" > "(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ > > > > -- -- 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#7939) Unable to filter on "(objectClass=glue)"
by hyc＠symas.com 16 Sep '14

16 Sep '14

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > When trying to find a set of broken entries, I found that it is impossible to > filter on objectClass=glue: > > [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w > $zimbra_ldap_password -H $ldap_url -b > "ou=people,dc=xxx,dc=xxx,dc=xxx%2%2"(objectClass=glue)" 1.1 > [zimbra@ldap01 ~]$ echo $? > 0 > > I am immediately returned to the prompt, and the error result is success (0). > Instead, I expect all the broken glue'd objects returned instead. Use the manageDSAit control. This works as designed, no bug, 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

(ITS#7940) Glue entry creation creates entries that cannot be found via ldapsearch filters
by quanah＠openldap.org 16 Sep '14

16 Sep '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Found this at a customer site. They loaded an LDIF file that had the child of an entry, but not the entry itself. slapadd then created a glue entry to account for this, however there some significant problems with this process a) The glue entry is not syntactically correct. There is no RDN value. b) It is impossible to use a filter with ldapsearch to find the entry. It appears the objectClass index is utterly broken. Example entry, and the child that created it: dn: uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy entryUUID: a326899a-ad0e-1033-8edf-d9cf7a32cf04 creatorsName: cn=config createTimestamp: 20140731145640Z entryCSN: 20140731145640.037371Z#000000#002#000000 modifiersName: cn=config%momodifyTimestamp: 20140731145640Z objectClass: top objectClass: glue structuralObjectClass: glue dn: zimbraDataSourceName=Adinet,uid=abcd,ou=people,dc=xxxx,dc=com,dc=uy objectClass: zimbraDataSource objectClass: zimbraImapDataSource .... As we can see, the glue entry has no RDN attribute at all. It is also impossible to find this entry via ldapsearch; ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" uid=abcd [zimbra@ldap01 ~]$ [zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w $zimbra_ldap_password -H $ldap_url -b "ou=people,dc=xxxx,dc=com,dc=uy" "(objectClass=glue)" 1.1 [zimbra@ldap01 ~]$

1 0

Re: (ITS#7939) Unable to filter on "(objectClass=glue)"
by quanah＠zimbra.com 16 Sep '14

16 Sep '14

--On Wednesday, September 17, 2014 1:11 AM +0000 quanah(a)openldap.org wrote: > When trying to find a set of broken entries, I found that it is > impossible to filter on objectClass=glue: Never mind, the entries aren't even valid ldap entries. Closing this ITS. -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2014