Issue 3711 - [enhancement] back-meta and overlapping targets
Summary: [enhancement] back-meta and overlapping targets
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-06 08:37 UTC by ando@openldap.org
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ando@openldap.org 2005-05-06 08:37:01 UTC
Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


Back-meta allows to glue together remote hosts that serve overlapping naming
contexts; for instance, one may glue two servers that both serve
"dc=example,dc=com".  Note that in this case, a violation of the LDAP data model
occurs because two different bits of information cannot have the same DN and be
part of the same distributed DSA.  However, there might be need for this feature
whenever the administrator of back-meta can ensure, by different means, that the
data model is otherwise preserved.

Again an example: suppose target 0 serves "dc=example,dc=com" and only provides
the context entry and the "ou=People" tree, while target 1 serves
"dc=example,dc=com" and only provides the context entry and some trees including
"ou=Groups", "ou=Admin" and so.  The back-meta administrator may want to glue
the context entry from target 0 and the forest of target 1, excluding the
context entry from the latter.

Currently, this cannot be done; but there would be a simple way to do it by
providing each target a scope modifier in addition to the currently provided
base modifier.

For instance:

database        meta
suffix          dc=example,dc=com
uri             ldap://target0/dc=example,dc=com
uri             ldap://target1/dc=example,dc=com

would return two instances of the "dc=example,dc=com" entry; the suggested
enhancement would allow

database        meta
suffix          dc=example,dc=com
uri             ldap://target0/dc=example,dc=com
uri             ldap://target1/dc=example,dc=com??subordinate

so target 1 would be serving namingContext "dc=example,dc=com" but only for
requests __below__ it.

The use of the URI directive to specify targets also suggests more enhancements
(that are out of scope for this ITS); e.g. the possibility to limit the
attributes back-meta will be accessing, or the possibility to specify additional
filters and so.

p.

Comment 1 ando@openldap.org 2005-05-06 08:37:29 UTC
moved from Incoming to Development
Comment 2 ando@openldap.org 2005-05-06 08:37:44 UTC
changed notes
Comment 3 ando@openldap.org 2005-05-06 09:22:05 UTC
> The use of the URI directive to specify targets also suggests more
> enhancements
> (that are out of scope for this ITS); e.g. the possibility to limit the
> attributes back-meta will be accessing, or the possibility to specify
> additional
> filters and so.

On a related note, back-meta and back-ldap could benefit from this latter
enhancement: the (optional) filter could be asserted via the assertion
control <draft-zeilenga-ldap-assert>, and/or ANDed to regular search
filters for search operations; the (optional) attrlist could be used to
control what attributes can be read/written.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

Comment 4 ando@openldap.org 2005-08-13 12:48:04 UTC
moved from Development to Software Enhancements
Comment 5 ando@openldap.org 2005-08-17 06:44:13 UTC
changed notes
changed state Open to Test
Comment 6 Kurt Zeilenga 2005-08-19 18:16:00 UTC
changed notes
changed state Test to Release
Comment 7 Kurt Zeilenga 2005-08-20 02:01:47 UTC
changed notes
changed state Release to Closed
Comment 8 ando@openldap.org 2006-01-11 10:48:53 UTC
>> The use of the URI directive to specify targets also suggests more
>> enhancements
>> (that are out of scope for this ITS); e.g. the possibility to limit the
>> attributes back-meta will be accessing, or the possibility to specify
>> additional
>> filters and so.
>
> On a related note, back-meta and back-ldap could benefit from this latter
> enhancement: the (optional) filter could be asserted via the assertion
> control <draft-zeilenga-ldap-assert>, and/or ANDed to regular search
> filters for search operations; the (optional) attrlist could be used to
> control what attributes can be read/written.

Of course, the addition of an assertion control would conflict with
client-requested assertions; in this specific case, the client-requested
assertion could be decoded, augmented by the proxy's:

        sprintf("(&%s%s)", proxy, client)

and re-encoded.

p.



Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------

Comment 9 Howard Chu 2009-02-17 04:53:51 UTC
moved from Software Enhancements to Archive.Software Enhancements
Comment 10 OpenLDAP project 2014-08-01 21:06:58 UTC
back-meta; may be useful in back-ldap
"scope" portion implemented in HEAD/re23