openldap-bugs May 2010

openldap-bugs@openldap.org

28 participants
84 discussions

(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 25 May '10

25 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 24 May '10

24 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

Re: (ITS#6553) Test043 oddities under Windows
by mhardin＠symas.com 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=3Da,hdb=3Da). Yes, Thanks. Here is a patch: Index: test043-delta-syncrepl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=3Da,hdb=3Da < $MASTEROUT | grep -iv = "^auditcontext:" > $MASTERF LT 344c344 < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT --- > $LDIFFILTER -s bdb=3Da,hdb=3Da < $SLAVEOUT | grep -iv "^auditcontext:" = > $SLAVEFLT >=20 > p. >=20 >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >>=20 >>=20 >> test043 fails under Windows because the contextCSN attribute for the = entry >> dc=3Dexample,dc=3Dcom are returned in different places within the = entry for >> the >> producer and consumer. To wit: >>=20 >> server1.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> 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=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> hasSubordinates: TRUE >>=20 >>=20 >>=20 >> server2.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> 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=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> hasSubordinates: TRUE >>=20 >>=20 >> 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. >>=20 >> 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!). >>=20 >>=20 >>=20 >>=20 >=20 >=20

1 0

Re: (ITS#6560) Samba4 OpenLDAP backend
by masarati＠aero.polimi.it 24 May '10

24 May '10

> Full_Name: Nitin Bhadauria > Version: OpenLDAP 2.X-Devel > OS: Ubuntu 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (119.82.72.226) > > > I am try to configure Samba4 with OpenLDAP and while setup provision... > > Using Following doc: > > http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP > > I got this error in messages logs. > > May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at > 7ffffffb > ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000] > May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0 Please read this <http://www.openldap.org/faq/data/cache/56.html> and act accordingly. p.

1 0

Re: (ITS#6559) About Referrals and BIND
by quanah＠zimbra.com 24 May '10

24 May '10

--On Monday, May 24, 2010 3:39 AM +0000 jet(a)hf.webex.com wrote: > Full_Name: Jet Du > Version: openldap-2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.191.27.34) > > > Because there are some typo in some description of (ITS#6558). So, I > submit a new ITS as below. > > There are two openLDAP Directory. > > 10.224.39.165 openLDAP has suffix dc=cisco,dc=com > 10.224.39.172 openLDAP has suffix dc=webex,dc=com > > In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: > referral ldap://10.224.39.165:389/ > > Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like > following: > lc.connect("10.224.39.172", 389); > lc.bind(LDAPConnection.LDAP_V3, > "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", > "pass".getBytes("UTF8")); > > But, I can not BIND successfully. Exception like below: > Connect ERRORLDAPException: Invalid Credentials (49) Invalid > Credentials LDAPException: Matched DN: ...... > > How to do BIND based on Referral? Thanks ... Two things: (a) Don't submit a new ITS because you typoed on the previous one. Just follow up to it. (b) Don't submit ITSes for software usage questions. Use the openldap-technical(a)openldap.org software list. The ITS system is for reporting bugs found in the software. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2010