openldap-bugs December 2009

openldap-bugs@openldap.org

28 participants
133 discussions

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 22 Dec '09

22 Dec '09

Kurt Zeilenga wrote: > On Dec 21, 2009, at 12:35 PM, Michael Ströder wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Yes, it has long been our practice not to publish schema elements which = >>> are not yet well standardized. This would include any element which = >>> carries a OpenLDAP.666 OID. >>> >>> The idea being that use of such attributes should be limited to early = >>> adopters and such. >> Sorry, but this practice is inconsequent. > > That's your opinion. My opinion is that we should avoid publishing > ''works in progress'' in production systems. Works in progress, by their > very nature, are subject to change without notice. If you'd really like to avoid issues with attributes being falsely handled by the client because the semantics changed you would especially also have to change the attribute type's NAME. Because that's what regular naive LDAP clients look for. A fully schema-aware client like web2ldap discovers OID changes and handles things correctly. E.g. in web2ldap plugins are preferrably registered by OID (besides some exceptions in case of missing schema descriptions). If the semantics changes and you assign a new OID web2ldap would not naively just treat it the same way. One has to explicitly register a plugin class for the new OID, off course after checking that semantics are the same then. Opposite to that if e.g. the semantics of entryCSN changes and you assign a new OID of a hidden schema description there's no chance to discover that. That's simply bad and therefore I won't follow your arguments at all. BTW: OpenLDAP also prefers NAME handling over OIDs. So with an OpenLDAP deployment changing the OID of a schema descriptions has no effect. But changing the NAME does. That's what I think is inconsequent: The current practice does not avoid issues. It only makes things worse. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 12:35 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> Yes, it has long been our practice not to publish schema elements = which =3D >> are not yet well standardized. This would include any element which = =3D >> carries a OpenLDAP.666 OID. >>=20 >> The idea being that use of such attributes should be limited to early = =3D >> adopters and such. >=20 > Sorry, but this practice is inconsequent. That's your opinion. My opinion is that we should avoid publishing = ''works in progress'' in production systems. Works in progress, by = their very nature, are subject to change without notice. > The attributes are returned in LDAP > responses Generally because the client asked for more than it should have. = Clients really shouldn't generally be asking for * and/or +. The two exceptions are clients which are servers attempting to = server-to-server replication and clients operated by directory = administrators. Clients which are intended to support various user applications really = should ask only for what they designed to consume. > and therefore a client should be able to look up the attribute type > description in the schema e.g. to determine the syntax. I disagree. Schema may not be made available to the client for any = number of reasons. The X.500 and LDAP specifications allow for this. >=20 > Some of the OIDs are now with .666 for years. Each time this topic is = raised > nothing happens... That's because (in general) the ''works in progress'' have not be = finalized. If something hasn't changed in years, then maybe it's time = to finalize it and, in doing so, assign it final OID. -- Kurt=

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

Kurt(a)OpenLDAP.org wrote: > Yes, it has long been our practice not to publish schema elements which = > are not yet well standardized. This would include any element which = > carries a OpenLDAP.666 OID. > > The idea being that use of such attributes should be limited to early = > adopters and such. Sorry, but this practice is inconsequent. The attributes are returned in LDAP responses and therefore a client should be able to look up the attribute type description in the schema e.g. to determine the syntax. Some of the OIDs are now with .666 for years. Each time this topic is raised nothing happens... Ciao, Michael.

1 0

Re: (ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

masarati(a)aero.polimi.it wrote: > olcRwmMap modification via back-config is not atomic; direct insert/delete not > allowed. A patch that implements support for this is proposed. p. The patch makes modification of this attribute consistent (all changes succeeed, or none); if modifications to olcRwmMap are followed by modifications to other attrs within the same write operation, the whole operation is not atomic. This less than ideal behavior is common to many operations allowed by back-config, though. Please test. p.

1 0

(ITS#6436) olcRwmMap atomic modification
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando olcRwmMap modification via back-config is not atomic; direct insert/delete not allowed. A patch that implements support for this is proposed. p.

1 0

Re: (ITS#6435) Hidden schema elements
by michael＠stroeder.com 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL: > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein > > Some of the operational attributes defined in the slapd source are hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of > these elements are used in the database (as in the authz* and monitor related > attributes). Yes, see also: http://www.openldap.org/its/index.cgi?findid=5573 http://www.openldap.org/its/index.cgi?findid=5574 http://www.openldap.org/its/index.cgi?findid=5576 IIRC also a bunch of attribute types used in back-config which makes back-config almost unusable with a stock schema aware client. The standard answer by Kurt and others is that as along as an experimental OID with .666 is used a schema description should be hidden. I strongly disagree with that though. > This causes my schema-aware application to complain when it sees > (or worse tries to modify) these attributes. (Sigh!) I also had to add several work-arounds to web2ldap regarding this. > A patch that adds a new optional define that can be used to disable the schema > hiding without enabling LDAP_DEVEL is coming. Looking forward to this being committed. > A better fix would be to not hide those schema elements that is actually > being used.. Amen. Ciao, Michael.

1 0

Re: (ITS#6435) Hidden schema elements
by Kurt＠OpenLDAP.org 21 Dec '09

21 Dec '09

On Dec 21, 2009, at 8:09 AM, rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: Irrelevant > URL:=20 > Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) > Submitted by: rein >=20 >=20 > Some of the operational attributes defined in the slapd source are = hidden from > the clients unless slapd is compiled with LDAP_DEVEL enabled. Yes, it has long been our practice not to publish schema elements which = are not yet well standardized. This would include any element which = carries a OpenLDAP.666 OID. The idea being that use of such attributes should be limited to early = adopters and such. > Still, some of > these elements are used in the database (as in the authz* and monitor = related > attributes). This causes my schema-aware application to complain when = it sees > (or worse tries to modify) these attributes. >=20 > A patch that adds a new optional define that can be used to disable = the schema > hiding without enabling LDAP_DEVEL is coming. A better fix would be = to not hide > those schema elements that is actually being used.. It may be that the particular schema elements simply shouldn't be behind = LDAP_DEVEL any longer, possibly because a permanent OID has yet to be = assigned to now production code. >=20 > Rein >=20

1 0

Re: Re : ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

KISTER RAPHAEL wrote: > Hello, > > I make a test with servers/slapd/overlays/rwm.c version 1.124. It works fine. Thank you very much for your help. I've re-fixed the problem in a different way; please re-test. Thanks, p.

1 0

Re: (ITS#6435) Hidden schema elements
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

rein(a)OpenLDAP.org wrote: > A better fix would be to not hide > those schema elements that is actually being used.. As far as I can tell, OpenLDAP's policy with respect to hiding schema definitions consists in un-hiding only those that are documented in standards track documents, or are for internal use and thus documented internally (e.g. back-config related). So the "right" fix would be to work at formalizing and submitting documents to stardards track. p.

1 0

(ITS#6435) Hidden schema elements
by rein＠OpenLDAP.org 21 Dec '09

21 Dec '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Some of the operational attributes defined in the slapd source are hidden from the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of these elements are used in the database (as in the authz* and monitor related attributes). This causes my schema-aware application to complain when it sees (or worse tries to modify) these attributes. A patch that adds a new optional define that can be used to disable the schema hiding without enabling LDAP_DEVEL is coming. A better fix would be to not hide those schema elements that is actually being used.. Rein

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2009