[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: a question about ou's
"Jankok, Lucio" wrote:
> Hi,
>
> I have a master domain with a lot of subdomains which I would like
> to setup in a slapd.conf file. do I need to use separate databases
> for each domain or is there a better/more elegant method for
> accomplising such a segmentation ?.
What does it mean "a lot"? If you have one domain and you want to
store "flat" information regardless of the domain but you still want
to be able to access such info with different naming contexts, you
can do it, if it is worth; otherwise, if the info can, or must, be
separate,
you can add as many backends as your domains are.
1st case:
1 naming context with aliases, e.g. you have flat info which should be
accessible with different naming contexts:
# main dc: "dc=main, dc=org"
# secondary dc's: "dc=sub1, dc=org"
# secondary dc's: "dc=sub2, dc=org"
database ldbm
suffixAlias "dc=sub1, dc=org" "dc=main, dc=org"
suffixAlias "dc=sub2, dc=org" "dc=main, dc=org"
suffix "dc=main, dc=org"
suffix "dc=sub1, dc=org"
suffix "dc=sub2, dc=org"
in this case you can use any naming context, the sub-naming
contexts will be transparently rewritten to the main one. Note
that, after a search with base "dc=sub2, dc=org", you'll see
the result as
dn: "cn=whatever, dc=main, dc=org",
i.e. there is no memory of the naming context used when
requesting an op.
2nd case:
# main dc
database ldbm
suffix "dc=main, dc=org"
# secondary dc's
database ldbm
suffix "dc=sub1, dc=org"
# secondary dc's
database ldbm
suffix "dc=sub2, dc=org"
all the naming contexts are now independent.
Note that, as the search for the backend appropriate to the dn
of the request is a linear search of normalized strings, if you
use A LOT of backends BOTH solutions are likely to reduce
the performances of the system.
3rd you are simply storing other parties info in your backend,
say, for administrative purposes. In this case all you need to do is:
- create a branch for such stuff under YOUR N.C.'s tree:
dn: ou=Other Domains, dc=main, dc=org
- create a branch for each domain
dn: cn=sub1.org, ou=Other Domains, dc=main, dc=org
dn: cn=sub2.org, ou=Other Domains, dc=main, dc=org
...
- add to each branch the stuff related to each domain
dn: ou=People, cn=sub1.org, ou=Other Domains, dc=main, dc=org
dn: ou=Groups, cn=sub1.org, ou=Other Domains, dc=main, dc=org
...
If other parties need to access their own branch as if it were an
independent ldap server, you can still use aliasing:
database ldbm
suffixAlias "dc=sub1, dc=org" "cn=sub1.org, ou=Other Domains, dc=main,
dc=org"
suffixAlias "dc=sub2, dc=org" "cn=sub2.org, ou=Other Domains, dc=main,
dc=org"
suffix "dc=main, dc=org"
suffix "dc=sub1, dc=org"
suffix "dc=sub2, dc=org"
or you can add a ldap backend for each secondary domain to exploit
the massaging facility (HEAD branch only, at present, pending the
rewrite capability that might obsolete it ;-)
# for each subdomain
database ldap
uri ldap://server.main.org
suffix "dc=sub1, dc=org"
suffixMassage "dc=sub1, dc=org" "cn=sub1.org, ou=Other Domains, dc=main,
dc=org"
In this case, you operate transparently on the ldap backend with the
"dc=sub1, dc=org" naming context without any evidence of stuff
being stored as a branch of another naming context. The ldap backend
may be on the same server of your naming context data, or it could
be on a separate server for each subdomain, so that each subdomain
appears to have an independent server.
Pierangelo.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8365
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati