openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

22 Apr '10

masarati(a)aero.polimi.it wrote: > 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) Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be best. > 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. File nesting has some implications in cn=config, which is why I made the above suggestion. -- -- 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#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >>=20 >> The latter context the term is defined as follows: The OBSOLETE = field, if >> present, indicates the element is not active. >=20 > I agree that OBSOLETE should not be set in this case. >=20 >> For user application attribute types, whether the type is active or = not is, >> I think, best left to the schema administrator. >=20 > Who is the schema administrator? Generally speaking, the OpenLDAP admin administrates which schema = elements to load into the schema and whether each such element is active = and inactive. While in some cases a schema admin might design schema elements, I = consider schema admin and schema element designer to be two separate = roles. > I'm nitpicking here because on the OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the = standard schema > at all. We often advise admins to load various schema elements into their = schemas. We generally assume admins run have only active elements in = the their schema as the need for inactive elements can generally be = avoided. When at I say "don't mess with standard schema elements", what I mean is = don't change aspects of schema specifications which are consider per the = technical specifications to be immutable on published in a technical = specification (or otherwise broadly published). There certainly are = other changes one can make to standard schema elements without violating = the technical specifications (e.g., changing the DESC value), and if = such case were to arise more generally, I might be more precise in my = general advice. That is, I rather only raise exceptions in advice when = it's actually applicable to the situation raised by the admin. -- Kurt=

1 0

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 22 Apr '10

22 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 22 Apr '10

22 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 22 Apr '10

22 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 22 Apr '10

22 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

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