openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 02 Jun '13

02 Jun '13

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> If a cursor is at a clean subDB page, and its current item is deleted >> by another cursor, then MDB_GET_CURRENT returns the deleted item. > > Fixed now in mdb.master. The subcursor on the clean page will be invalidated > when the page is touched. MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the patch below to the test program. One partial fix: Instead return a new error code MDB_BAD_CURSOR or maybe MDB_UNSPECIFIED. Also make mdb_cursor_<next/prev>() less forgiving of errors, otherwise the user gets different success results for the two cursors again. Branch mdb/its7594 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> does this. I did not look at how to get the cursors return the same result. mdb.master output with patched test program: With clean page: Name: Key -> Data (mv_data[mv_len]): m2: a[2] -> x[2] mc/del: a[2] -> [0] a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. Branch mdb/its7594 output: With clean page: Name: Key -> Data (mv_data[mv_len]): m2: a[2] -> x[2] mc/del: a[2] -> [0] its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable That assert is OK since it's the test program asserting success. --- its7594.c +++ its7594a.c @@ -28,4 +28,6 @@ E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); if (argc < 2) { @@ -42,8 +44,8 @@ E(mdb_cursor_del(mc, 0)); - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); - SHOW("m2/del"); /* Should output the same as... */ - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); + SHOW("m2/del"); /* ...and this should output the same. */ mdb_txn_abort(txn); -- Hallvard

1 0

(ITS#7612) {CLEARTEXT} password scheme broken
by wferi＠niif.hu 31 May '13

31 May '13

Full_Name: Ferenc Wágner Version: 2.4.31 OS: Debian GNU/Linux squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.101.52.7) I'm trying to store the hypothetical password "{SSHA}" in cleartext, but slappasswd refuses to help: $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} Password verification failed. On #openldap hbf suggested that I file an ITS ("work" in the following means allowing binding): hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be valid. As I agree with him, here it is.

1 0

Re: (ITS#7611) [Patch] Fix loglevel2bvarray
by hyc＠symas.com 29 May '13

29 May '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch > Submission from: (NULL) (209.132.186.34) > > > When using slaptest to convert a slapd.conf file to the new DIT integrated > configuration (-f and -F options), the directive 'loglevel 0' is not converted > to 'olcLogLevel: 0' in file cn=config.ldif. > > The 'loglevel 0' seems to be a special case, so this patch treats it as such. > > Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637 Thanks for the patch, committed to master. -- -- 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#7611) [Patch] Fix loglevel2bvarray
by jsynacek＠redhat.com 29 May '13

29 May '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch Submission from: (NULL) (209.132.186.34) When using slaptest to convert a slapd.conf file to the new DIT integrated configuration (-f and -F options), the directive 'loglevel 0' is not converted to 'olcLogLevel: 0' in file cn=config.ldif. The 'loglevel 0' seems to be a special case, so this patch treats it as such. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637

1 0

Re: (ITS#7610) scope index isn't used correctly with the filter index
by meike.stone＠googlemail.com 28 May '13

28 May '13

2013/5/28 Howard Chu <hyc(a)symas.com>: > meike.stone(a)googlemail.com wrote: >> >> Full_Name: Meike Stone >> Version: 2.4.33 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.200.138.3) >> >> >> I have a directory with about 2,000,000 objects at all. >> >> In one conteiner (basedn for search) are about 84,000 objects >> but only one of this is a person with objectclass=inetOrgperson. >> I have about 420,000 objectclass=inetOrgperson. >> >> The search with the specified basedn where only the one inetOrgperson >> is located needs about 5 minutes ... >> >> see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html > > > Sorry, digging further into the code I see I was mistaken. The two indices > are being combined correctly and the code works in my own tests. > > The search looks up the scope index (IDs of all the entries in the target > scope) and the filter indices and computes their intersection. Not sure why > this would be so slow in your case. hmm, while search, the one entry with the objectclass is shown immediately, but then, it takes a long time to "recognize" that that is all ... How does the slapd calculate/determine the scope index? Tomorrow I try to check this in test environment .. Are there any special things/hints I can test or see? Thanks Meike

1 0

RE: (ITS#7610) scope index isn't used correctly with the filter index
by ctcard＠hotmail.com 28 May '13

28 May '13

---------------------------------------- > Date: Tue, 28 May 2013 16:13:29 +0000 > From: hyc(a)symas.com > To: openldap-its(a)openldap.org > Subject: Re: (ITS#7610) scope index isn't used correctly with the filter index > > meike.stone(a)googlemail.com wrote: >> Full_Name: Meike Stone >> Version: 2.4.33 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.200.138.3) >> >> >> I have a directory with about 2,000,000 objects at all. >> >> In one conteiner (basedn for search) are about 84,000 objects >> but only one of this is a person with objectclass=inetOrgperson. >> I have about 420,000 objectclass=inetOrgperson. >> >> The search with the specified basedn where only the one inetOrgperson >> is located needs about 5 minutes ... >> >> see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html > > Sorry, digging further into the code I see I was mistaken. The two indices are > being combined correctly and the code works in my own tests. > > The search looks up the scope index (IDs of all the entries in the target > scope) and the filter indices and computes their intersection. Not sure why > this would be so slow in your case. This sounds very similar to problem I was having, and I had to increase BDB_IDL_LOGN to 18 for the (rebuilt) objectclass index to be used. Chris

1 0

Re: (ITS#7610) scope index isn't used correctly with the filter index
by hyc＠symas.com 28 May '13

28 May '13

meike.stone(a)googlemail.com wrote: > Full_Name: Meike Stone > Version: 2.4.33 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.200.138.3) > > > I have a directory with about 2,000,000 objects at all. > > In one conteiner (basedn for search) are about 84,000 objects > but only one of this is a person with objectclass=inetOrgperson. > I have about 420,000 objectclass=inetOrgperson. > > The search with the specified basedn where only the one inetOrgperson > is located needs about 5 minutes ... > > see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html Sorry, digging further into the code I see I was mistaken. The two indices are being combined correctly and the code works in my own tests. The search looks up the scope index (IDs of all the entries in the target scope) and the filter indices and computes their intersection. Not sure why this would be so slow in your case. -- -- 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#7610) scope index isn't used correctly with the filter index
by meike.stone＠googlemail.com 28 May '13

28 May '13

Full_Name: Meike Stone Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.200.138.3) I have a directory with about 2,000,000 objects at all. In one conteiner (basedn for search) are about 84,000 objects but only one of this is a person with objectclass=inetOrgperson. I have about 420,000 objectclass=inetOrgperson. The search with the specified basedn where only the one inetOrgperson is located needs about 5 minutes ... see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html Thanks Meike

1 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd
by ck＠cksoft.de 28 May '13

28 May '13

Hi Howard, On Tue, 28 May 2013, Howard Chu wrote: >> Thanks a lot for the prompt fix. > > You're welcome. Thanks for confirming. could you commit both patches to RE24 so they would end up in 2.4.36 when it gets released. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 28 May '13

28 May '13

Hallvard Breien Furuseth wrote: > On 2013-05-28 15:03, hyc(a)symas.com wrote: >>> It looks like mdb_drop0() should also reset/uninitialize >>> other cursors in the same (sub)database. Currently such >>> cursors keep any references to the deleted pages. >>> >> Just doc this. No cursors should be open on a DB that is being >> dropped. > > Doesn't help mdb_cursor_del's call to mdb_drop0 when F_SUBDATA. > Is that safe? > Probably not but again, it's a doc issue. Someone has to call specifically with the flag mdb_cursor_del(MDB_NODUPDATA) so they must know what they're intending. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs