openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> > --=-hLLTpGMzur3nD+xeX+/o > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Using these instructions, the issue remains with current CVS: Should be (re-)fixed in HEAD (pull out libraries/librewrite/Makefile.in). The issue emerged when ldifutil.c (who pulls in ldif_* from liblutil) was also added to libldap_r; this broke librewrite. It happened after ITS#6517 was closed. Please test. Thanks, p. > I have had it sometimes build from an old tree, but this from scratch > does not: > > =3D=3DGetting OpenLDAP=3D=3D > This guide presumes you are running OpenLDAP CVS HEAD from after 22 > April 2010 (or a release after that date) > > You need the 'deref' and 'rdnval' overlay. This may be in your packaged > version, but if not your must rebuild. > > To get OpenLDAP from CVS run: > > CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP > export CVSROOT > cvs login > > You will need to enter at the prompt: > Password: (enter OpenLDAP) > > Then check out the tree > cvs -z3 checkout -P openldap > > Then change to the newly created 'openldap' directory: > cd openldap > > To update your OpenLDAP checkout (discarding local conflicts) from CVS > run: > > cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm > cvs -z9 update -dP > > To build it run: > > CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure > --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1 > make clean all AC_CFLAGS=3D-g > > --=20 > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > > > --=-hLLTpGMzur3nD+xeX+/o > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2 > FxErm+tMjQUnb0y7Hmgs9n8= > =zuyi > -----END PGP SIGNATURE----- > > --=-hLLTpGMzur3nD+xeX+/o-- > > > >

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> Kurt Zeilenga wrote: >> obsoletes != OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >> >> The latter context the term is defined as follows: The OBSOLETE field, >> if >> present, indicates the element is not active. > > I agree that OBSOLETE should not be set in this case. > >> For user application attribute types, whether the type is active or not >> is, >> I think, best left to the schema administrator. > > Who is the schema administrator? I'm nitpicking here because on the > OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the standard > schema > at all. IMO this includes setting OBSOLETE. I Think there's a misunderstanding. My understanding (and intention) is 1) You said you pulled in revisited cosine.schema also elements that were dropped in RFC4524. 2) I was asking whether the fact they were dropped implied they were OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition) 3) Kurt replied that they MUST NOT be marked as OBSOLETE. Whether they are loaded or not in a DSA's schema is at the DSA schema administrator's choice 4) This, IMHO, implies that we need to provide two separate files, to allow DSA admins to either load strict RFC4524 schema (no obsolete items) or loose RFC4524 (entire RFC1274 schema). Now, we have different options to arrange the resulting schema files (names used below are only an example, the final name can be discussed when there's consensus on the approach): a) cosine.schema (== RFC1274) cosine4524.schema (== RFC4524) mutually exclusive (Kurt does not like this) b) cosine4524.schema (== RFC4524) cosine.schema (== RFC1274 - RFC4524) the latter includes the former c) cosine4524.schema (== RFC4524) cosine1274.schema (== RFC1274 - RFC4524) (there might be more) Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 schema, thus existing configurations surely do not break. I concur case (a) would cause a lot of complaints from people loading all available schema files and having conflicts. Case (c) needs to modify configuration, but avoids file nesting, if that's a problem at all. p.

1 0

(ITS#6517) undefined references to ldif_*
by abartlet＠samba.org 22 Apr '10

22 Apr '10

--=-hLLTpGMzur3nD+xeX+/o Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using these instructions, the issue remains with current CVS: I have had it sometimes build from an old tree, but this from scratch does not: =3D=3DGetting OpenLDAP=3D=3D This guide presumes you are running OpenLDAP CVS HEAD from after 22 April 2010 (or a release after that date) You need the 'deref' and 'rdnval' overlay. This may be in your packaged version, but if not your must rebuild. To get OpenLDAP from CVS run: CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP export CVSROOT cvs login You will need to enter at the prompt: Password: (enter OpenLDAP) Then check out the tree cvs -z3 checkout -P openldap Then change to the newly created 'openldap' directory: cd openldap To update your OpenLDAP checkout (discarding local conflicts) from CVS run: cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm cvs -z9 update -dP To build it run: CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1 make clean all AC_CFLAGS=3D-g --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-hLLTpGMzur3nD+xeX+/o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2 FxErm+tMjQUnb0y7Hmgs9n8= =zuyi -----END PGP SIGNATURE----- --=-hLLTpGMzur3nD+xeX+/o--

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > obsoletes != OBSOLETE, so no. That is, the meaning of the term > 'obsolete' is quite different in these two contexts. > > The latter context the term is defined as follows: The OBSOLETE field, if > present, indicates the element is not active. I agree that OBSOLETE should not be set in this case. > For user application attribute types, whether the type is active or not is, > I think, best left to the schema administrator. Who is the schema administrator? I'm nitpicking here because on the OpenLDAP lists we all keep telling OpenLDAP admins not to mess with the standard schema at all. IMO this includes setting OBSOLETE. Ciao, Michael.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by kurt＠OpenLDAP.org 21 Apr '10

21 Apr '10

On Apr 21, 2010, at 6:03 PM, masarati(a)aero.polimi.it wrote: >> Kurt Zeilenga wrote: >>>=20 >>> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>>> Updated schema file cosine-update.schema attached. >>>=20 >>> I note that differs are generally preferred, even where the file is >>> mostly changed. This helps ensure changes that others might make to = the >>> file you started with are not lost. >>=20 >> I thought about sending a diff but the file in this form is more >> readable for easy review. Could someone please look at it whether = that's >> ok? >=20 >> Another approach would be to have two schema files, one which only >> contains the schema descriptions from RFC 4524 and one with the = missing >> schema descriptions from RFC 1274 with the latter obviously being >> dependent on the former. >=20 > I have one preliminary question for Kurt: since rfc4524 obsoletes = rfc1274, > should those schema items that were not brought forward be marked as > OBSOLETE? obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term = 'obsolete' is quite different in these two contexts. The latter context the term is defined as follows: The OBSOLETE field, if present, indicates the element is not active. For user application attribute types, whether the type is active or not = is, I think, best left to the schema administrator. (Update operations = upon an inactive element is limited to removal of the element.) > If yes, then all schema could fit in one file. I'd like a > clear way to separate valid from obsolete schema. The obsolete items > should be available for backwards compatibility. As an alternative, = I'd > like to have a "slim" (without obsolete) and a complete version of the > file. I rather no element be specified in multiple files. > Could you please upload the file? Through the ITS attachments > don't work too well. >=20 >>>> IPR notice: >>>> This patch file is derived from OpenLDAP Software and RFC 4524 and = RFC >>>> 1274. All of the modifications to OpenLDAP Software represented in = the >>>> attached file were developed by Michael Str=F6der = <michael(a)stroeder.com>. >>>> I have not assigned rights and/or interest in this work to any = party. >>>=20 >>> While this notice of origin is fine, you did not include a rights >>> statement. >>=20 >> I, Michael Str=F6der, hereby place the modified schema file = cosine.schema >> attached to ITS#6151 (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. >=20 > Am I right in assuming this IPR is fine? Thanks, p. Yes. - Kurt

1 0

ITS#6250
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

Why is this ITS in software development, and open? Anyone intends to develop that feature, despite the discussion? p.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Kurt Zeilenga wrote: >> >> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>> Updated schema file cosine-update.schema attached. >> >> I note that differs are generally preferred, even where the file is >> mostly changed. This helps ensure changes that others might make to the >> file you started with are not lost. > > I thought about sending a diff but the file in this form is more > readable for easy review. Could someone please look at it whether that's > ok? > Another approach would be to have two schema files, one which only > contains the schema descriptions from RFC 4524 and one with the missing > schema descriptions from RFC 1274 with the latter obviously being > dependent on the former. I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, should those schema items that were not brought forward be marked as OBSOLETE? If yes, then all schema could fit in one file. I'd like a clear way to separate valid from obsolete schema. The obsolete items should be available for backwards compatibility. As an alternative, I'd like to have a "slim" (without obsolete) and a complete version of the file. Could you please upload the file? Through the ITS attachments don't work too well. >>> IPR notice: >>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>> 1274. All of the modifications to OpenLDAP Software represented in the >>> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >>> I have not assigned rights and/or interest in this work to any party. >> >> While this notice of origin is fine, you did not include a rights >> statement. > > I, Michael Ströder, hereby place the modified schema file cosine.schema > attached to ITS#6151 (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. Am I right in assuming this IPR is fine? Thanks, p.

1 0

Re: (ITS#6529) slapcat: bad configuration file!
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Full_Name: SLava > Version: 2.4.21 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.120.255.22) > > > My aim is to regularly backup openldap database, so I created a special > backup-user to do that. But while doing this command: "slapcat -f > /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I > get this > error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied > slapcat: bad configuration file!". I watched my conf file and there is > "directory /var/lib/openldap-data/my-domain-com" string in line 77. I > looked for > permission rights and all seems to be properly. Don't know what to do... > > By the way, the same command under "root" works perfectly. Your file permissions are obviously inappropriate for the operation you're trying to perform. There is no evidence of an OpenLDAP bug; there is not even an evidence of an LDAP-related issue. This ITS will be closed. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

This is a known issue. That patch is now obsoleted by the code that has been committed to HEAD and ported to re24 for release. Please test re24 out of the CVS, or apply the corresponding modifications to slapd/syncrepl.c to 2.4.21, and test. Please note that test018 has been modified to reproduce and test the problem you highlighted. If you run the new test18 with 2.4.21 it should consistently fail, while it passes with the new code. p. > Hello, > > Le 17/04/2010 22:00, > masarati(a)aero.polimi.it (par Internet) a écrit : >> A fix is in HEAD, please test > > I have tried the compilaltion of the source 2.4.21 with your patch, > "make test" failed on "test020-proxycache for bdb" with this error : > > >>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > ./scripts/test020-proxycache: line 173: 16714 Erreur de segmentation > $SLAPD -f $CONF2 -h $URI2 -d $LVL -d pcache > $LOG2 2>&1 > ldapsearch failed (255)! > ./scripts/test020-proxycache: line 177: kill: (16714) - Aucun processus > de ce type > >>>>> ./scripts/test020-proxycache failed for bdb (exit 255) > make[2]: *** [bdb-mod] Erreur 255 > make[2]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make[1]: *** [test] Erreur 2 > make[1]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make: *** [test] Erreur 2 > > I have used this compilation steps : > tar -zxvf openldap-2.4.21.tgz > > cd openldap-2.4.21 > > patch -p0 < ../pierangelo-masarati-2010-04-17-sync-rename.1.patch > patching file servers/slapd/syncrepl.c > Hunk #2 succeeded at 2554 (offset -10 lines). > Hunk #3 succeeded at 2891 (offset -10 lines). > Hunk #4 succeeded at 3026 (offset -10 lines). > > ./configure --enable-debug --enable-dynamic --enable-syslog > --enable-proctitle --enable-ipv6 --enable-local --enable-slapd > --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd > --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups > --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod > --enable-ldbm=no --disable-ndb --enable-overlays=mod --with-subdir=ldap > --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc > > make depend > > make > > make test > > regards, > Julien > >

1 0

(ITS#6529) slapcat: bad configuration file!
by slava.kargaltsev＠gmail.com 21 Apr '10

21 Apr '10

Full_Name: SLava Version: 2.4.21 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.120.255.22) My aim is to regularly backup openldap database, so I created a special backup-user to do that. But while doing this command: "slapcat -f /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I get this error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied slapcat: bad configuration file!". I watched my conf file and there is "directory /var/lib/openldap-data/my-domain-com" string in line 77. I looked for permission rights and all seems to be properly. Don't know what to do... By the way, the same command under "root" works perfectly.

1 0

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010