July 2010 - openldap-bugs

Re: (ITS#6489) Incomplete Master/Slave Replication

by frank.offermanns＠caseris.de

Hello Quanah, thanks for your info. I compiled OpenLDAP 2.4.23 and BDB 4.8.30, but unfortunately the problem still persists. I added 10000 Users added and: with RefreshAndPersist in 136 users at least one attribute was missing. with RefreshOnly in 34 users at least one attribute was missing. In my post in March I said, that with accesslog I do not have this problem. This is not completely true. Meanwhile (also with 2.4.21) I found out that with accesslog I also have this problem, but less frequentely. So with about 40000 users added I had only about 1 or 2 attributes missing. With the new version I added 10000, 20000 and 80000 users without a single problem. So I am not sure, if this problem still persist with accesslog, but with RefreshAndPersist and RefreshOnly there is definitely still a problem. Due to the fact that no one else complains about this, maybe this problem is Windows only? Or is there someone else who also has this problem? If you are interested I could provide you my windows test-application. With this the problem can be reproduced in a few minutes. Let me know if I should send you this program. Thanks a lot so far. Best regards, Frank Offermanns > > > Full_Name: Frank Offermanns > > Version: 2.4.21 > > OS: Windwos > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (217.6.189.242) > > > > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > > testing master/slave replication while adding 10000 users with 10 filled > > attributes. I am not using a specific time synchronization. Standard > > windows time synchronization in domains is active. But as far as I > > understood, a microsecond time synchronisation is only needed for > > master-master, which I am not testing. > > BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP > 2.4.23, and report back if you still have issues. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

1
0
0 / 0

Re: (ITS#6489) Incomplete Master/Slave Replication

by quanah＠zimbra.com

--On Tuesday, March 09, 2010 12:23 PM +0000 Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.21 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > testing master/slave replication while adding 10000 users with 10 filled > attributes. I am not using a specific time synchronization. Standard > windows time synchronization in domains is active. But as far as I > understood, a microsecond time synchronisation is only needed for > master-master, which I am not testing. BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP 2.4.23, and report back if you still have issues. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

1
0
0 / 0

Re: (ITS#6476) Failure to delete entry with multi-master replication

by quanah＠zimbra.com

--On Wednesday, February 17, 2010 1:05 PM +0000 worganc(a)avaya.com wrote: > Full_Name: Craig Worgan > Version: 2.4.21 > OS: RedHat Enterprise Linux 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.11.182.86) Hi Craig, Are you able to reproduce this with OpenLDAP 2.4.23? There have been some fixes around deletes since 2.4.21, and an issue that was introduced in 2.4.21 specific to cached objects as well. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

1
0
0 / 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil

by quanah＠zimbra.com

--On Tuesday, May 25, 2010 6:37 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> quanah(a)zimbra.com writes: >>> Actually, the issue seems to be name changes in the header files under >>> BSD. This causes TIOCNOTTY to end up being undefined. >> >> That would not give the error message shown in >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021. >> html>: >> >> build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr >> aries/liblutil/detach.c:131:7: error: missing binary operator before >> token "long" >> >> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >> somewhere is defined to expand to an expression involving a (long) cast. > > Apprently so. > > <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. > html> Fixed by debian. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

1
0
0 / 0

Fwd: Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config

by daniel＠pluta.biz

Hi Howard, > ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my > HEAD). ;-) This ITS can be closed - the bug was in my head rather than in CVS head (background information: unresolved cvs update conflicts). I'm sorry for the inconveniences! Best regards, Daniel

12 years, 8 months

1
0
0 / 0

Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config

by daniel＠pluta.biz

On 07/21/2010 10:53 PM, Howard Chu wrote: > daniel(a)pluta.biz wrote: >> Full_Name: Daniel Pluta >> Version: HEAD >> OS: Lnx >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) >> >> >> slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig >> settings. >> >> Steps to reproduce: >> >> 1.) cat> slapd.conf<<EOF >> include /tmp/openldap/etc/openldap/schema/core.schema >> pidfile /tmp/openldap/var/run/slapd.pid >> argsfile /tmp/openldap/var/run/slapd.args >> database hdb >> dbconfig set_cachesize 0 1048576 0 >> dbconfig set_lg_bsize 2097152 >> suffix "dc=my-domain,dc=com" >> rootdn "cn=Manager,dc=my-domain,dc=com" >> rootpw secret >> directory /tmp/openldap/var/openldap-data >> index objectClass eq >> EOF >> >> 2.) convert slapd.conf into cn=config: >> mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d >> >> 3.) search slapd.d directory for "olcdbconfig" attribute values: >> grep -R -i olcDbConfig slapd.d/ >> >> the string "olcDbConfig" cannot be found (only in schema definition)... >> > I'm unable to reproduce this issue; the conversion works for me: > > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f > testrun/slapd.1.conf -F testrun/slapd.d -d -1 > violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d > -n0 | less > > dn: olcDatabase={1}bdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcBdbConfig > olcDatabase: {1}bdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a > olcDbCacheSize: 1000 > olcDbCheckpoint: 1024 5 > olcDbConfig: {0}set_lg_bsize 2097152 > olcDbNoSync: FALSE > olcDbDirtyRead: FALSE > olcDbIDLcacheSize: 0 > olcDbIndex: objectClass eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbLinearIndex: FALSE > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbShmKey: 0 > olcDbCacheFree: 1 > olcDbDNcacheSize: 0 > structuralObjectClass: olcBdbConfig > entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 > creatorsName: cn=config > createTimestamp: 20100721204954Z > entryCSN: 20100721204954.041390Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20100721204954Z > Many thanks Howard for your reply. hmmm, sounds like some kind of deadlock to me: you cannot reproduce my and I cannot re-reproduce your results. All differences I can currently see: I'm using "hdb" and I use "grep -r -i 'olcDbConfig' slapd.d/" to test whether olcDbConfig does exist in any file below slapd.d. As the contents of an existing DB_CONFIG file (within the database-dir) will be converted correctly into olcDbConfig here, are you sure you had no "DB_CONFIG" file in your database directory? Could you please provide me the (original) slapd.conf you've used above? Than I would like to reproduce your exact test procedure here. ==> I'm pretty sure there is a bug in HEAD (either in CVS or in my HEAD). ;-)

12 years, 8 months

1
0
0 / 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1

by hyc＠symas.com

asifiqbal.desai(a)gmail.com wrote: > Full_Name: Asif Iqbal Desai > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.214.64.6) > > > This is a consulation bug for clarification on close() being called from > ldap_unbind_s with fd = 1. > > The application uses ldap client apis for user authentication. > We recently upgraded to use OpenLDAP version 2.4.16 and are getting an > unexpected AIO error issue when ldap user authentication is enabled. > > Investigating further revealed that from ldap_unbind_s ( close(-1) is getting > called. However the close function of solaris libaio does a special handling > when fd< 0 which causes AIO errors. > > The application needs solaris aio support and hence cannot link libc before > libaio. > > Is there any specific reason for close being called with fd = -1 from > ldap_unbind_s. > This issue didnot exist with OpenLDAP 2.3.27. I've checked 2.3.43 and 2.4.23; in both cases ber_int_sb_close() is being called twice on the same sockbuf. I suppose that might be considered a bug, but certainly the behavior has not changed between 2.3 and 2.4. > Following is the stacktrace: > [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), > at 0xffffffff7f406a64 > [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21eafc > [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at > 0xffffffff7d21e160 > [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, > 0xd), at 0xffffffff7d21cebc > [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at > 0xffffffff7d26a4bc > [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, > 0x100121a00), at 0xffffffff7d26a048 > [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, > 0x0, 0x100117728), at 0xffffffff7d26a55c > ... > ... > > Thanks in Advance, > Asif Iqbal Desai > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 months

1
0
0 / 0

Re: (ITS#6595) Patch - Mozilla NSS - delay token auth until needed

by hyc＠symas.com

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-initauthtoken.patch > Submission from: (NULL) (76.113.111.209) > > > The code was doing all of the authentications to all of the tokens during the > init phase. This was causing problems with NSS cert/key clients, prompting for > the cert/key db password, when it isn't needed, since it is only needed to get > private key information. The patch is to just remove the token authentication > during init. The code already authenticates to the token when private key > information is needed e.g. running in TLS/SSL server mode, or using client cert > auth. > > This patch 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, Rich Megginson 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. > > Committed to HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 months

1
0
0 / 0

Re: (ITS#6590) slaptest ignores slapd.conf's dbconfig statement during conversion into cn=config

by hyc＠symas.com

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Lnx > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4ca0:0:f000:4877:9270:3ab1:2849) > > > slaptest -f -F ignores slapd.conf (bdb/hdb convenience) dbconfig settings. > > Steps to reproduce: > > 1.) cat> slapd.conf<<EOF > include /tmp/openldap/etc/openldap/schema/core.schema > pidfile /tmp/openldap/var/run/slapd.pid > argsfile /tmp/openldap/var/run/slapd.args > database hdb > dbconfig set_cachesize 0 1048576 0 > dbconfig set_lg_bsize 2097152 > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > rootpw secret > directory /tmp/openldap/var/openldap-data > index objectClass eq > EOF > > 2.) convert slapd.conf into cn=config: > mkdir slapd.d&& slaptest -f slapd.conf -F slapd.d > > 3.) search slapd.d directory for "olcdbconfig" attribute values: > grep -R -i olcDbConfig slapd.d/ > > the string "olcDbConfig" cannot be found (only in schema definition)... > I'm unable to reproduce this issue; the conversion works for me: violino:~/OD/hobj/tests> ../servers/slapd/slapd -Ttest -f testrun/slapd.1.conf -F testrun/slapd.d -d -1 violino:~/OD/hobj/tests> ../servers/slapd/slapd -Tc -F testrun/slapd.d -n0 | less dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcSuffix: dc=example,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=example,dc=com olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /home/hyc/OD/hobj/tests/testrun/db.1.a olcDbCacheSize: 1000 olcDbCheckpoint: 1024 5 olcDbConfig: {0}set_lg_bsize 2097152 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 8a31068c-449d-491c-9ddf-4fb817dad065 creatorsName: cn=config createTimestamp: 20100721204954Z entryCSN: 20100721204954.041390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721204954Z -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 months

1
0
0 / 0

Re: (ITS#6598) EXOP to return number of children of a (sub)tree

by hyc＠symas.com

masarati(a)aero.polimi.it wrote: >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: NA >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> It would be extremely useful to have an extended operation that allows >>> querying >>> the number of children of a given (sub)tree, so that one can avoid >>> iterating >>> through the entire subtree to determine this number. >>> >> Might as well ask for the numSubordinates operational attribute to be >> implemented instead, this doesn't seem to merit a new exop. And for >> numSubordinates, see the -devel archives for why we chose not to implement >> it. >> >> In either case, the server still needs to iterate over all entries >> internally, >> and the result has to take ACLs and entry disclosure into account. > > An exop would allow to easily discriminate between intentional and > "catchall" requests, like "+". Moreover, it might make sense to > discriminate at least between subtree and onelevel number of subordinates; > this would require two distinct operational attributes, or a parameter in > the exop. > > I'm not endorsing either solution, I'm just pointing out possible pros and > cons. If you want to be able to distinguish results based on scope then it makes more sense to just define a Search control. Like No-op - count the entries that would be returned, instead of returning them. (And bypassing the sizelimit too, but probably not bypassing timelimit.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 8 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 July 2010