Re: Multiple Schema

[Howard Chu <hyc@symas.com>]

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/