Hi,
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?
Or, If I have to make changes in the existing openldap code how should I go about it? I have observed that attributetype, objectclass etc are stored in AVL. do I need to maintain different AVL for my schemas to work?
Any help regarding how I should proceed is appreciated.
If I am on wrong mailing list please redirect me.
Thanks and Regards, Suhel
Suhel Momin wrote:
Hi,
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.
Or, If I have to make changes in the existing openldap code how should I go about it? I have observed that attributetype, objectclass etc are stored in AVL. do I need to maintain different AVL for my schemas to work?
Use multiple slapd instances. Use proxies and subordinate to glue them together if necessary.
Any help regarding how I should proceed is appreciated.
If I am on wrong mailing list please redirect me.
Thanks and Regards, Suhel
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.)
Ciao, Michael.
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.
openldap-software@openldap.org
-
Howard Chu -
Michael Ströder -
Suhel Momin