Michael Ströder wrote:
Howard Chu wrote:
> Suhel Momin wrote:
>> I am planning to have multiple DIT's.
>> These DIT's may use different customised Schema.
>> Now my problem is to store these schema such that DIT's will use their
>> respective schema definition.
>> This is because the attributetype or objectclass in these different
>> schemas
>> might overlap.
>> Hence I want to keep them seperate and use them for a particular
>> DIT. Is
>> this possible?
> Not in the current versions.
> [..]
> Use multiple slapd instances. Use proxies and subordinate to glue them
> together if necessary.
Note that in such a scenario with back-ldap/meta and glue a schema-aware
LDAPv3 client does not have a chance to do the right thing. (And yes,
web2ldap asks for the relevant subschema subentry for each part of the
DIT all the time.)
Eh? With appropriate rewrite rules a set of glued slapds would be totally
equivalent to multiple schemas within a single slapd.
E.g, you have 3 administrative domains, each with their own schema
dc=com
dc=foo,dc=com
dc=bar,dc=com
You set up 3 slapds, each with separate databases, and their own schema:
database hdb
suffix "" (the dc=foo server)
...
database hdb
suffix "" (the dc=bar server)
...
In the top level slapd you set up the glue:
database meta
suffix dc=foo,dc=com
suffix dc=bar,dc=com
subordinate
database hdb
suffix dc=com
You set the meta rewrite rules so that all queries that affect the
"dc=foo,dc=com" branch are targeted at the first server, and
"dc=foo,dc=com" is
appended to all DNs returned from that server. So that server's
"cn=subschema"
becomes "cn=subschema,dc=foo,dc=com" and so on. Likewise for the other branch.
Any schema-aware LDAP client will work properly and will not be able to
distinguish this from a single-server installation.
Back in the OpenLDAP 2.0 days we (Symas) had a module that did this sort of
gluing. The extra trick that it did, that is missing here, is to allow a stub
entry for the glue points (e.g., the "dc=foo,dc=com" entry must exist in the
parent) and merged it with the target, so you could still maintain it as a real
entry and also see the operational attributes of the rootDSE of the target if
you needed 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/