openldap-bugs

openldap-bugs@openldap.org

1 participants
20954 discussions

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

Re: (ITS#4833) Back-config chokes when adding database
by hyc＠symas.com 07 Feb '07

07 Feb '07

Thanks, fixed. rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.144.248) > > > When adding a database without an explicit index set olcDatabase-Attribute slapd > crashes (find stack backtrace below). > > This is the LDIF I tried to add: > > dn: olcDatabase=ldap,cn=config > objectclass: olcDatabaseConfig > objectclass: olcldapconfig > olcDatabase: ldap > olcsuffix: cn=test > olcrootdn: cn=admin,cn=test > olcrootpw: secret > olcdburi: ldap://my.ldap.server > > When using the correct index, '{1}' in my case it works as expected. I suspect > something's wrong the special handling of the {-1} index of frontendDB, but > wasn't able to track it down completely. > > Here's the backtrace: -- -- 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 h.b.furuseth＠usit.uio.no 07 Feb '07

07 Feb '07

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. -- Regards, Hallvard

1 0

(ITS#4834) DN matching rules should be indexed
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 The dnSubtreeMatch, dnOneLevelMatch, dnSubordinateMatch, and dnSuperiorMatch matching rules added in OpenLDAP 2.3 can be used in extended filter clauses to get finer control over the scope of a search. Currently back-bdb/back-hdb don't do any indexing for extended filters, which can make these filters pretty expensive to evaluate. But these specific rules can take advantage of the dn2id index, which already maintains all the necessary index information. If these extensions are going to be used frequently, we should add index support here.

1 0

(ITS#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.144.248) When adding a database without an explicit index set olcDatabase-Attribute slapd crashes (find stack backtrace below). This is the LDIF I tried to add: dn: olcDatabase=ldap,cn=config objectclass: olcDatabaseConfig objectclass: olcldapconfig olcDatabase: ldap olcsuffix: cn=test olcrootdn: cn=admin,cn=test olcrootpw: secret olcdburi: ldap://my.ldap.server When using the correct index, '{1}' in my case it works as expected. I suspect something's wrong the special handling of the {-1} index of frontendDB, but wasn't able to track it down completely. Here's the backtrace: #0 0x0000000000415083 in config_add_internal (cfb=0x7f11c0, e=0x88af68, ca=0x40fff6c0, rs=0x41000cb0, renum=0x41000884, op=0x8ad530) at bconfig.c:4385 #1 0x00000000004156a7 in config_back_add (op=0x8ad530, rs=0x41000cb0) at bconfig.c:4523 #2 0x000000000043057b in fe_op_add (op=0x8ad530, rs=0x41000cb0) at add.c:330 #3 0x000000000042feaf in do_add (op=0x8ad530, rs=0x41000cb0) at add.c:182 #4 0x00000000004276db in connection_operation (ctx=0x41000de0, arg_v=0x8ad530) at connection.c:1129 #5 0x0000000000427bb9 in connection_read_thread (ctx=0x41000de0, argv=0xc) at connection.c:1257 #6 0x000000000053d552 in ldap_int_thread_pool_wrapper (xpool=0x85e630) at tpool.c:704 #7 0x00002b374570309e in start_thread () from /lib64/libpthread.so.0 #8 0x00002b37459d94cd in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

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