[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Multiple Schema

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
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

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

  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/