openldap-bugs February 2007

openldap-bugs@openldap.org

32 participants
125 discussions

Re: (ITS#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 08 Feb '07

08 Feb '07

Howard Chu writes: > That's a good idea but would require more work to define indexer > functions for each matching rule before we could do anything further. I was thinking to only support it for existing indexer functions. Would 'index cn :caseExactMatch' require a new indexer function? > My reason for posting this ITS is that we already have the index > available for the DN relativeMatch rules, so we should be taking > advantage of them. Fair enough. -- Regards, Hallvard

1 0

Re: (ITS#4836) dynamic configuration support for ppolicy
by hyc＠symas.com 08 Feb '07

08 Feb '07

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.25.211.20) > > > Dynamic configuration would remove the need for restarting slapd in many > situations (add a schema, add an index), however sites requiring ppolicy on any > database in running in the same slapd cannot use dynamic configuration since > ppolicy in REL_ENG_2_3 does not have dynamic configuration support. > > ppolicy in HEAD does have such support, but the version from head does not > compile on REL_ENG_2_3, and various bugfixes since it was originally added > depend on features in HEAD. > It would be useful to have dynamic configuration support for ppolicy in > REL_ENG_2_3. "Would be useful" doesn't sound like a bug report to me, and RE23 really shouldn't be receiving enhancements at this stage of its cycle. I've added the necessary patches to RE23, but understand that requests of this sort are much less likely to be honored going forward. New code will be in RE24. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4836) dynamic configuration support for ppolicy
by bgmilne＠staff.telkomsa.net 08 Feb '07

08 Feb '07

Full_Name: Buchan Milne Version: OPENLDAP_REL_ENG_2_3 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.211.20) Dynamic configuration would remove the need for restarting slapd in many situations (add a schema, add an index), however sites requiring ppolicy on any database in running in the same slapd cannot use dynamic configuration since ppolicy in REL_ENG_2_3 does not have dynamic configuration support. ppolicy in HEAD does have such support, but the version from head does not compile on REL_ENG_2_3, and various bugfixes since it was originally added depend on features in HEAD. It would be useful to have dynamic configuration support for ppolicy in REL_ENG_2_3.

1 0

Re: (ITS#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

kurt(a)OpenLDAP.org wrote: > On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > >> h.b.furuseth(a)usit.uio.no wrote: >>> Suggestion: Generalize a bit and support the slapd.conf statement >>> >>> index attr :matchingRule >>> >>> Can be used with the extended filter (attr:matchingRule:=foo), >>> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >>> >> That's a good idea but would require more work to define indexer >> functions >> for each matching rule before we could do anything further. My >> reason for >> posting this ITS is that we already have the index available for >> the DN >> relativeMatch rules, so we should be taking advantage of them. > > I note that dn2id is only useful for entryDN matching. For > matching of arbitrary DN attributes, additional indexing would > be needed. True. For the examples I've seen, this is good enough, and it's trivial to support it. > It may be possible/reasonable to integrate indexing > for this with component matching indexing... which, of course, > needs work. Yes, and time... -- -- Howard Chu Chief Architect, 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#4834) DN matching rules should be indexed
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 8, 2007, at 2:51 AM, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Suggestion: Generalize a bit and support the slapd.conf statement >> >> index attr :matchingRule >> >> Can be used with the extended filter (attr:matchingRule:=foo), >> or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. >> > That's a good idea but would require more work to define indexer > functions > for each matching rule before we could do anything further. My > reason for > posting this ITS is that we already have the index available for > the DN > relativeMatch rules, so we should be taking advantage of them. I note that dn2id is only useful for entryDN matching. For matching of arbitrary DN attributes, additional indexing would be needed. It may be possible/reasonable to integrate indexing for this with component matching indexing... which, of course, needs work. -- Kurt > > -- > -- Howard Chu > Chief Architect, 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#4556 ditStructureRules
by kurt＠OpenLDAP.org 07 Feb '07

07 Feb '07

On Feb 7, 2007, at 11:22 PM, hyc(a)symas.com wrote: > I've often thought about adding support here, but it looks like an > all-or-nothing proposition. I.e., when you have a server that uses > ditStructureRules, you must actually define a full set of rules > otherwise you > cannot add any user entries to the directory at all. This would be > a pretty > drastic change for people accustomed to the current behavior, where > you can > put any entry you like anywhere you like. Beginners have a hard > enough time > just getting their first two entries into the directory; requiring > the use of > ditStructureRules would seem to just make a bad situation worse. It may be possible to do something similar to what was done for ditContentRules, which are also all or none in X.500 (no rules defined means no use of aux objectcleasses in X.500). In OpenLDAP, no rules means any use of auxiliary classes is okay. But if you add a rule, any rule, then these defined rules must be followed. -- Kurt > > Possibly we could make it a configurable option - enable them with a > per-database setting, defaulting to off to preserve the current > behavior. > Fully aligning with X.500 practices would have to wait for a new > generation > of server. E.g., we currently support the use of subdatabases using > subordinate/glue. These provide some of the notion of X.500 > Administrative > Areas, except their definitions reside in the cn=config tree, not as > subentries of the main DIT. Providing full subentry-based > administration > would be a major change in how the server is operated and how the > DIT is > administered. Something for OpenLDAP 3.0. > -- > -- Howard Chu > Chief Architect, 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#4834) DN matching rules should be indexed
by hyc＠symas.com 07 Feb '07

07 Feb '07

h.b.furuseth(a)usit.uio.no wrote: > Suggestion: Generalize a bit and support the slapd.conf statement > > index attr :matchingRule > > Can be used with the extended filter (attr:matchingRule:=foo), > or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. > That's a good idea but would require more work to define indexer functions for each matching rule before we could do anything further. My reason for posting this ITS is that we already have the index available for the DN relativeMatch rules, so we should be taking advantage of them. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4835) dyngroup.schema needs clarification
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Our current schema definition defines groupOfURLs as a structural objectclass. This matches the definition used by Netscape, where this schema originates. However, the published documentation describes it as an auxiliary objectclass, and indeed the Netscape/iPlanet/Sun/FDS/RHDS servers use it as if it were an auxiliary. http://www.redhat.com/docs/manuals/dir-server/schema/6.1/oc_dir.htm#1316814 This ambiguity arises because Netscape/iPlanet/Sun/FDS/RHDS don't actually implement the LDAP/X.500 data model correctly. There are many areas where they fail to implement the model, but in this specific case they simply don't enforce schema definitions. http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636 And it appears that their developers didn't consider this a problem worthy of attention. But it's creating confusion for other users. http://www.openldap.org/lists/openldap-software/200609/msg00121.html I think the right thing to do here is change our definition to AUXILIARY since that matches its actual usage. It won't match the published definitions, but those definitions are demonstrably wrong.

1 0

ITS#4556 ditStructureRules
by hyc＠symas.com 07 Feb '07

07 Feb '07

I've often thought about adding support here, but it looks like an all-or-nothing proposition. I.e., when you have a server that uses ditStructureRules, you must actually define a full set of rules otherwise you cannot add any user entries to the directory at all. This would be a pretty drastic change for people accustomed to the current behavior, where you can put any entry you like anywhere you like. Beginners have a hard enough time just getting their first two entries into the directory; requiring the use of ditStructureRules would seem to just make a bad situation worse. Possibly we could make it a configurable option - enable them with a per-database setting, defaulting to off to preserve the current behavior. Fully aligning with X.500 practices would have to wait for a new generation of server. E.g., we currently support the use of subdatabases using subordinate/glue. These provide some of the notion of X.500 Administrative Areas, except their definitions reside in the cn=config tree, not as subentries of the main DIT. Providing full subentry-based administration would be a major change in how the server is operated and how the DIT is administered. Something for OpenLDAP 3.0. -- -- Howard Chu Chief Architect, 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#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Tested, seems to work correctly now. Thanks. On Wednesday 07 February 2007 16:18, Howard Chu wrote: > Thanks, fixed. -- Ralf

1 0

← Newer
1
...
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2007