May 2013 - openldap-bugs

(ITS#7612) {CLEARTEXT} password scheme broken

by wferi＠niif.hu

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.

10 years, 3 months

1
0
0 / 0

Re: (ITS#7611) [Patch] Fix loglevel2bvarray

by hyc＠symas.com

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/

10 years, 3 months

1
0
0 / 0

(ITS#7611) [Patch] Fix loglevel2bvarray

by jsynacek＠redhat.com

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

10 years, 3 months

1
0
0 / 0

Re: (ITS#7610) scope index isn't used correctly with the filter index

by meike.stone＠googlemail.com

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

10 years, 3 months

1
0
0 / 0

RE: (ITS#7610) scope index isn't used correctly with the filter index

by ctcard＠hotmail.com

---------------------------------------- > 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

10 years, 3 months

1
0
0 / 0

Re: (ITS#7610) scope index isn't used correctly with the filter index

by hyc＠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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 3 months

1
0
0 / 0

(ITS#7610) scope index isn't used correctly with the filter index

by meike.stone＠googlemail.com

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

10 years, 3 months

1
0
0 / 0

Re: (ITS#7608) cn=config with modifiersdn outside cn=config breaks recovery using slapadd

by ck＠cksoft.de

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

10 years, 3 months

1
0
0 / 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup

by hyc＠symas.com

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/

10 years, 3 months

1
0
0 / 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup

by h.b.furuseth＠usit.uio.no

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? -- Hallvard

10 years, 3 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2013