3:43 a.m.
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
8:12 a.m.
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
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3:09 a.m.
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.
4:18 a.m.
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/
5455
days inactive
5459
days old
openldap-software@openldap.org
3 comments
3 participants
participants (3)
-
Howard Chu -
Michael Ströder -
Suhel Momin