openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6563) slapadd locks up shared memory segments
by quanah＠zimbra.com 27 May '10

27 May '10

--On Wednesday, May 26, 2010 10:45 PM +0000 aravind(a)freeshell.org wrote: > Full_Name: Aravind Gottipati > Version: 2.4.21 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.245.220.240) > > > I have enabled shared memory in my slapd.conf file. With this setup, it > appears that slapadd does not release the shared memory segments once its > done. This prevents the ldap server from starting up after, because it > complains that these shared memory segments are in use. > > To reproduce: > With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. > Try to then start up slapd. > > Work around: > When you slapadd the database, turn off shared memory settings in the > slapd.conf file. Re-enable it after slapadd is done. > > I have tried cleaning up those segments with ipcrm, but ipcrm simply says > that the memory segments are already removed. Its lying to you, those > segments are still there (ipcs lists them). > > Please let me know if I can get any you any more information to help with > the troubleshooting. I am not sure if you'd see the same issues with a > bdb backend (I use hdb, but afaik they are pretty similar). You should use db_recover from the appropriate bdb release to clean them up. Not ipcrm. You also fail to note which version of BDB you are linked against. I've certainly never seen this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 27 May '10

27 May '10

A new patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-26-add-if-not-p…> It includes support for SLAP_MOD_SOFTDEL (see discussion here <http://www.openldap.org/lists/openldap-devel/201005/msg00003.html>). p.

1 0

(ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 26 May '10

26 May '10

Full_Name: Aravind Gottipati Version: 2.4.21 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.245.220.240) I have enabled shared memory in my slapd.conf file. With this setup, it appears that slapadd does not release the shared memory segments once its done. This prevents the ldap server from starting up after, because it complains that these shared memory segments are in use. To reproduce: With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. Try to then start up slapd. Work around: When you slapadd the database, turn off shared memory settings in the slapd.conf file. Re-enable it after slapadd is done. I have tried cleaning up those segments with ipcrm, but ipcrm simply says that the memory segments are already removed. Its lying to you, those segments are still there (ipcs lists them). Please let me know if I can get any you any more information to help with the troubleshooting. I am not sure if you'd see the same issues with a bdb backend (I use hdb, but afaik they are pretty similar).

1 0

(ITS#6562) nssov in OpenLDAP 2.4.22 doesn't build
by fahadsadah＠gmail.com 26 May '10

26 May '10

Full_Name: Fahad Sadah Version: 2.4.22 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.31.135.30) Chris Breneman recently filed a bug (#6488, http://www.openldap.org/its/index.cgi?findid=6488) about nssov, and submitted a patch. The patch was correctly applied in CVS. In release 2.4.22, most of the code has Chris' patch applied, but one file, network.c, isn't patched. This is stopping nssov from building.

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 26 May '10

26 May '10

A patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-25-add-if-not-p…> p.

1 0

(ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 25 May '10

25 May '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando I need to implement a modify operation whose semantics is "add if not present", an add that only takes place if that attribute is not yet present in the entry. I need it as an internal operation, so right now I wouldn't bother formalizing it as an extension of the semantics of the modify operation. Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an attribute value only if that value is not already present. See <http://www.openldap.org/lists/openldap-devel/201005/msg00000.html> for discussion. I have introduced a SLAP_MOD_ADD_IF_NOT_PRESENT flag and added code to support it in back-bdb/hdb. It works as intended. I plan to extend its support to all backends and overlays. p.

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 25 May '10

25 May '10

--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> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6557 published: SECURITY: About Referrals and BIND
by openldap-its＠OpenLDAP.org 25 May '10

25 May '10

Private ITS#6557 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6557

1 0

Re: (ITS#6551) wrapping lines option
by masarati＠aero.polimi.it 25 May '10

25 May '10

> this is a feature request for making wrapping optional. Duplicate of ITS#6149; see related discussion. p.

1 0

Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it 24 May '10

24 May '10

> On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote: > >> Isn't ldif-filter supposed to deal with this? Probably, test043 needs >> to >> sort entries (-s bdb=a,hdb=a). > > Yes, Thanks. > > Here is a patch: Works for me, but I can't check using windows. I'd commit it, pending verification. Thanks, p. > Index: test043-delta-syncrepl > =================================================================== > RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v > retrieving revision 1.1.1.5 > diff -r1.1.1.5 test043-delta-syncrepl > 342c342 > < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $MASTEROUT | grep -iv "^auditcontext:" > >> $MASTERF > LT > 344c344 > < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $SLAVEOUT | grep -iv "^auditcontext:" > >> $SLAVEFLT > > >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Windows 7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> test043 fails under Windows because the contextCSN attribute for the >>> entry >>> dc=example,dc=com are returned in different places within the entry for >>> the >>> producer and consumer. To wit: >>> >>> server1.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> hasSubordinates: TRUE >>> >>> >>> >>> server2.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> hasSubordinates: TRUE >>> >>> >>> While this is not a problem in operation, and is not specifically a bug >>> according to the RFCs, test043 nonetheless fails because it expects an >>> exact >>> match in the ordering between the producer and consumer. It's not clear >>> whether >>> the desired fix is in slapd or in the test itself. >>> >>> This test does not fail on any other platforms with which we are >>> currently >>> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related >>> to >>> ITS#6549, which is now fixed (thanks Ando!). >>> >>> >>> >>> >> >> > > >

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