openldap-bugs July 2012

openldap-bugs@openldap.org

19 participants
47 discussions

(ITS#7323) back-mdb online indexer memory leak
by hyc＠OpenLDAP.org 12 Jul '12

12 Jul '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.226.5.35) Submitted by: hyc The online indexer doesn't free entries that it has reindexed. A patch is coming.

1 0

ITS#6262 regression
by hyc＠symas.com 10 Jul '12

10 Jul '12

While running valgrind --tool=helgrind on test008 I saw some data races that were quite unexpected, in ldap_pvt_gettime(). These functions are supposed to detect duplicate timestamps being returned, as noted in git rev 6cbf65642a9d094feddf820b206c1a3af70d5fd9 . This detection relies on static variables, and as such their invocations must be mutex-protected, as noted in the function comments (added immediately after, in ee2001ea4b26b0957040ca0753a94f26f78e6147). Unfortunately in f3cdcadf89474e7267d9f8f17d2bac46551b2131 the necessary mutex was removed. This means on multi-processor machines it's possible for us to generate non-unique CSNs. -- -- 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#7322) Problem in LDAP Server
by quanah＠zimbra.com 05 Jul '12

05 Jul '12

--On Friday, July 06, 2012 5:20 AM +0000 kashif.hameed(a)vopium.com wrote: > Full_Name: Kashif Hameed > Version: openldap-2.3.43 > OS: Centos 32 Bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.215.176.22) > > > Dear All > please help me its my first job and its my final assignment my job is > totally on this assignment. The ITS system is for reporting bugs. You have not reported a bug, this ITS will be closed. If you want the help you are desperately seeking, I would advise you to use the openldap-technical(a)openldap.org mail list, as advised on the openldap.org website for use when seeking help. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7322) Problem in LDAP Server
by kashif.hameed＠vopium.com 05 Jul '12

05 Jul '12

Full_Name: Kashif Hameed Version: openldap-2.3.43 OS: Centos 32 Bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.215.176.22) Dear All please help me its my first job and its my final assignment my job is totally on this assignment. We have multiple servers of linux, Centos and Ubuntu, Debian my boss want to implement openldap in this situation that user will manage from central location. so i have started work on this and successfull to implement 1 case that is if we will create a simple user its authanticate but when we want to give sudo rights then it will return error here is the eroor please help me how to resolve this issue [root@ldapprod ~]# service ldap restart Stopping slapd: [ OK ] Checking configuration files for slapd: [FAILED] /etc/openldap/schema/sudo.schema: line 1: AttributeType SYNTAX or SUPerior required: "sudoUser" slaptest: bad configuration file! Here is the file for your reference please look into this where syntax is wrong attributetype ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' ) DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) attributetype ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'SUDO' ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoOption $ description ) X-ORIGIN 'SUDO' ) Thanks

1 0

(ITS#7321) Subtree replication: when removing object outside of subtree, contextCSN is not updating!
by kostjnspb＠yandex.ru 05 Jul '12

05 Jul '12

Full_Name: Konstantin Menshikov Version: 2.4.31 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/kmenshikov-120705.ext Submission from: (NULL) (212.116.101.94) I have replication setup, when i replicate not entire tree, but only part of it. Configuration provider and consumer attached. I use openldap-server-2.4.31 and db47-4.7.25.4 While adding object outside of the replicated subtree: e.g. ou=TestBranch1,dc=example,dc=com contextCSN of dn dc=example,dc=com on consumer server updated, ok. But while removing object, contextCSN not updated! Is it expected behavior or not? At first I added object *ou=hosts,ou=TestBranch2,dc=example,dc=com*.1 After I removed object. Provider log: Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SRCH attr=hasSubordinates objectClass Jun 22 06:37:53 ro1 slapd[62268]: conn=1002 op=52 SEARCH RESULT tag=101 err=32 nentries=0 text= Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 ADD dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:37:54 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffe3fb100 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=53 RESULT tag=105 err=0 text= Jun 22 06:37:54 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x80191bfd0 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH base="ou=hosts,ou=TestBranch2,dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SRCH attr=hasSubordinates objectClass Jun 22 06:37:54 ro1 slapd[62268]: conn=1002 op=54 SEARCH RESULT tag=101 err=0 nentries=1 text= Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 DEL dn="ou=hosts,ou=TestBranch2,dc=example,dc=com" Jun 22 06:38:01 ro1 slapd[62268]: slap_queue_csn: queing 0x7ffffebfc590 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:01 ro1 slapd[62268]: conn=1002 op=55 RESULT tag=107 err=0 text= Jun 22 06:38:01 ro1 slapd[62268]: slap_graduate_commit_csn: removing 0x802738970 20120622063801.799710Z#000000#000#000000 Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH base="ou=TestBranch2,dc=example,dc=com" scope=1 deref=3 filter="(objectClass=*)" Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SRCH attr=hasSubordinates objectClass Jun 22 06:38:02 ro1 slapd[62268]: conn=1002 op=56 SEARCH RESULT tag=101 err=0 nentries=2 text= Consumer log: Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 LDAP_RES_INTERMEDIATE - NEW_COOKIE Jun 22 06:37:54 ro2 slapd[62298]: do_syncrep2: rid=111 NEW_COOKIE: rid=111,csn=20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_queue_csn: queing 0x8019eca90 20120622063754.599740Z#000000#000#000000 Jun 22 06:37:54 ro2 slapd[62298]: slap_graduate_commit_csn: removing 0x8019ec2b0 20120622063754.599740Z#000000#000#000000

1 0

Re: (ITS#6339) ldapsearch -V doesn't exist after version info
by Gavin Henry 04 Jul '12

04 Jul '12

Do we want to document this or change behavior?

1 0

Re: ITS#7317
by hyc＠symas.com 03 Jul '12

03 Jul '12

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Hmm, another 100 iterations without a problem. Not sure whether it's related >>> to back-mdb or whether this may happen occasionally with other backends too. >>> Trying more... >> >> Looks like a simple timing dependency in the test script. slapcat of the DB in >> your testrun directory shows that the correct value is present. The refint >> overlay does its work in a separate task, so there's no guarantee it will be >> done by the time the original modrdn request finishes. > > Ok, noted. > >> We could add a SLEEP in the script here but it seems to be such a rare >> occurrence I'm inclined to ignore it. > > Hmm, I'd argue that a SLEEP would be helpful to avoid further questions about > it. A OpenLDAP packager might run "make test" routinely and this issue aborts it. I've replaced the hardcoded "sleep 1" in the script with "sleep $SLEEP0" so it can be overridden along with the other SLEEP1/SLEEP2 values. Packagers running the tests should either ensure they're on an idle enough machine, or set larger values in their environment... -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2012