openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6531) Modify updateref to generate referrals on the backend
by ryans＠aweber.com 23 Apr '10

23 Apr '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) Per conversation on the #openldap IRC channel on Freenode with Howard Chu, it has been deemed appropriate to modify the behavior of updateref to answer referrals on the backend. This would allow one to use updateref to automatically chase referrals for individual backends, instead of it being all or nothing. Here is the tail end of the channel conversation: <hyc> when you configure an updateref on a backend, that referral is only generated in the frontend so putting the overlay on the database, misses it... <rgsteele> Well, I am intending to set an updateref on that backend <hyc> then you have a problem <rgsteele> Hm, so you can't do automatic referrals on individual backends then? <rgsteele> That was my original question, or at least the intent of it. <hyc> not using updateref, no <rgsteele> Does your response imply there's another way? <hyc> probably we should fix updateref to be generated at the backend level <rgsteele> That would be good - I'd be happy to write tests or something to help with that. <hyc> the "other way" is the normal referral mechanism - using referral entries inside a database <hyc> but like I said, updateref is a relic, we've carried it forward without really adapting it <hyc> probably should file an ITS about this <rgsteele> Interesting, I wasn't aware of that method. I'll have to do some research on that - thanks! Also, is there anything I can do to help get the process of fixing updateref to generate referrals on the backend? <rgsteele> I can file the ITS if you like? <hyc> go ahead

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 23 Apr '10

23 Apr '10

sorry... the last update was broken. I've uploaded a new version to: <ftp://ftp.openldap.org/incoming/rieger-changelog-2.4.21-pkg-100423.tgz> this version compiles and runs smoothly with 2.4.21. Also I fixed a minor memory leak. Any feedback is welcome ;)

1 0

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

23 Apr '10

On Apr 22, 2010, at 2:58 PM, Michael Str=F6der wrote: > Kurt Zeilenga wrote: >> One additional note, I generally would advise that a schema-aware = client >> not alter it's update behavior of elements based upon whether said = elements >> are active or inactive (OBSOLETE) in the schema.=20 >=20 > I disagree especially for cases when new data is added. I think you're trying to make the client far smarter than it really = ought to be. If the clients configured to place say place element of data in = attribute x, it shouldn't try to put it elsewhere. It should fail. While certainly one could design a client such as it could be configured = with fallbacks for attributes, and fallback for fallbacks, etc., this is = an unnecessarily complication IMO. Also, note that were a client to attempt the above, it could still fail = due to an element being marked inactive between the time it read the = schema and the time it tried the DIT update. Of course, one could = complicate the client further by trying to handle this as well. >=20 >> Instead, they should just >> try the update and, if it fails, report it as they normally would. >=20 > Modifying existing data I first have to think about... >=20 >> Handling the inactive condition locally hides the error from the = directory=20 >> administrator, who is likely relying on directory server logs to find=20= >> applications which using inactive schema. >=20 > Hmm, that's not the case with a schema-aware client anyway which = guides the > user *not* to use OBSOLETE schema elements. I generally assume the user is not selecting which attribute to store = some piece of information into. I assume the client been programmed to = collect a piece of information and configured (or programmed) where to = store it. The client you refer to is what I would call an application-neutral LDAP = directory administration tool. For such a tool, it might be reasonable = to warn the user (whose generally an "administrator" of some sort as = opposed to a "normal" user). =20 > You're likely talking about > detecting pre-configured applications with hard-coded use of OBSOLETE = object > classes and attribute types. > Most times these are not schema-aware at all. Well, pre-configured applications may be schema-aware but maybe not as = fully as an LDAP directory administration tool might be. They might = check that the element they were configured to use is appropriate for = that use by examining its specification in the subschema. -- Kurt=

1 0

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

22 Apr '10

Kurt Zeilenga wrote: > One additional note, I generally would advise that a schema-aware client > not alter it's update behavior of elements based upon whether said elements > are active or inactive (OBSOLETE) in the schema. I disagree especially for cases when new data is added. > Instead, they should just > try the update and, if it fails, report it as they normally would. Modifying existing data I first have to think about... > Handling the inactive condition locally hides the error from the directory > administrator, who is likely relying on directory server logs to find > applications which using inactive schema. Hmm, that's not the case with a schema-aware client anyway which guides the user *not* to use OBSOLETE schema elements. You're likely talking about detecting pre-configured applications with hard-coded use of OBSOLETE object classes and attribute types. Most times these are not schema-aware at all. Ciao, Michael.

1 0

Re: (ITS#6530) Controls in successful bind response are discarded by proxy backends
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> --On Thursday, April 22, 2010 3:57 PM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.72.165.211) >> Submitted by: ando >> >> >> Related to ITS#6166; in the meanwhile, a specific fix is coming. > > ITS#6166 is marked RE25/RE30. Is this fix appropriate for RE24? As soon as ITS#6166 is fixed in re25, ITS#5630 is a re24-only issue. If successful bind response were returned by backends/overlays instead of the frontend, this issue wouldn'd have appeared. This does not mean we need to rush it into 2.4.22. It passed all tests for me, and showed no leaks or so when proxying binds with password policy control, but I'd like it to be reviewed. p.

1 0

Re: (ITS#6530) Controls in successful bind response are discarded by proxy backends
by quanah＠zimbra.com 22 Apr '10

22 Apr '10

--On Thursday, April 22, 2010 3:57 PM +0000 masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.165.211) > Submitted by: ando > > > Related to ITS#6166; in the meanwhile, a specific fix is coming. ITS#6166 is marked RE25/RE30. Is this fix appropriate for RE24? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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 10:20 AM, Kurt Zeilenga wrote: > The purpose of the OBSOLETE (inactive) flag is to support transition = away from a particular schema element. Basically, if one no longer = wants to use the attribute type 'x' in their directory, they should 1) = mark x as inactive in the subschema, 2) then remove all uses of x, 3) = then remove x from the subschema. One additional note, I generally would advise that a schema-aware client = not alter it's update behavior of elements based upon whether said = elements are active or inactive (OBSOLETE) in the schema. Instead, they = should just try the update and, if it fails, report it as they normally = would. Handling the inactive condition locally hides the error from the = directory administrator, who is likely relying on directory server logs = to find applications which using inactive schema. He may well not have = access to all the clients' logs. -- Kurt=

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 9:58 AM, Michael Str=F6der wrote: > Kurt Zeilenga wrote: >>=20 >> On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: >>=20 >>> 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? >>=20 >> Generally speaking, the OpenLDAP admin administrates which schema = elements >> to load into the schema and whether each such element is active and >> inactive. >=20 > What does "active and inactive" mean exactly? Does that include = changing the > OBSOLETE keyword in schema files? I hope not... The purpose of the OBSOLETE (inactive) flag is to support transition = away from a particular schema element. Basically, if one no longer = wants to use the attribute type 'x' in their directory, they should 1) = mark x as inactive in the subschema, 2) then remove all uses of x, 3) = then remove x from the subschema. The directory prevents all non-removal updates to inactive elements, = allowing 2 to be well performed. >=20 >> While in some cases a schema admin might design schema elements, I = consider >> schema admin and schema element designer to be two separate roles. >=20 > Agreed. >=20 >>> I'm nitpicking here because on the OpenLDAP >>> lists we all keep telling OpenLDAP admins not to mess with the = standard schema >>> at all. >>=20 >> We often advise admins to load various schema elements into their = schemas. >=20 > The role for loading the shipped schema files is not the question = here. >=20 >> 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). >=20 > Does "immutable" include OBSOLETE? I hope so... OBSOLETE is one of the mutable properties of a schema element (because = otherwise it couldn't support local movements away from arbitrary schema = elements). -- Kurt >=20 > Ciao, Michael.

1 0

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

22 Apr '10

Kurt Zeilenga wrote: > > On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: > >> 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? > > Generally speaking, the OpenLDAP admin administrates which schema elements > to load into the schema and whether each such element is active and > inactive. What does "active and inactive" mean exactly? Does that include changing the OBSOLETE keyword in schema files? I hope not... > While in some cases a schema admin might design schema elements, I consider > schema admin and schema element designer to be two separate roles. Agreed. >> 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. The role for loading the shipped schema files is not the question here. > 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). Does "immutable" include OBSOLETE? I hope so... Ciao, Michael.

1 0

(ITS#6530) Controls in successful bind response are discarded by proxy backends
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.211) Submitted by: ando Related to ITS#6166; in the meanwhile, a specific fix is coming. 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