Kevin Myer wrote:
Quoting Jeff Clowser <jclowser@xxxxxxxxxxxxxxxxxxx>:
There is really no need to use the dc=k12,dc=pa,dc=us style tree - in
fact, in most cases I've set up, that was actually a bad choice. Sun
uses o=internet as a base under which to put a full dc tree (in their
5.x messaging software), but even they are moving away from that,
because it doesn't work very well in a lot of cases (though it works
a lot better than st=pa,c=us type trees). If you really want to use
a domain based tree, build it under something like o=internet. (i.e.
dc=k12,dc=pa,dc=us,o=internet, etc) so there is a common root.
I should have been more specific and stated that using a domain component
approach to the tree layout was an initial assumption.
One thing I've seen is the following:
1. Create separate trees - i.e. dc-k12,dc=pa,dc=us, etc.
2. Then create another tree, such as o=isp, and under that, create
referals or chains for each of your "real" trees, so that you can search
the "forest" using o=isp, but have each tree stand alone.
Personally, I don't like this approach, because it has implications for
clients (do they follow referals?), aci's, and is just a mess to
maintain. I also prefer to only use referals/chains to split trees
across servers (if that's needed for delegation or scaling of services),
rather than to remap trees (I hate doing a search where the dn that gets
returned isn't under the tree I searched... But that's just me). KISS
is important :)
What are the problems you've encountered using a domain based tree
(dc=iu13,dc=org,o=internet), versus one where the domain is treated as an
organization (o=iu13.org,o=internet), other than having a few more
components
to type? Has thinking on using DC style tree's changed?
I wouldn't say thinking on dc style trees have "changed", so much as
there are different opinions out there :) . As far as I know, rfc2247
is the only rfc that defines a tree structure, but also as far as I
know, it is just saying "here is one way to build a tree", rather than
"here's the best/recommended way to build a tree". It's nice because it
mirrors DNS, another common directory service, but it isn't the best for
all cases. Other tree structures (i.e. o based) are just as valid,
depending on what your needs are. I believe the dc structure is the one
Microsoft uses in Active Directory, so a lot of people will say it's
"best" to use this to be able to interoperate more easily with Active
Directory. The directory server does not _require_ this structure by
any means - it's just the default suffix it offers.
As for the problems I've had - they are very similar to the problems you
are describing - if I have xyz.com and abc.org, how do I put them in a
common tree? I can't, unless I have a stub entry to root them under
(i.e. o=internet, etc). Most ldap enabled services/software (mail,
calendar, dns, etc) expect one tree to look for resources in. If you
create separate trees, you often have to deploy separate
servers/instances of servers for each, which is not efficient. If you
want to handle web or mail services for N domains, do you want to deploy
one server (or server cluster) to handle this, or do you want to have to
deploy/maintain n servers, each separately/differently configured?
Also, if you are hosting a dozen domains with 100 users in each, do you
want one server or a dozen under-utilized servers to maintain? This
just doens't scale well/efficiently using separate trees like this.
In any event, it is unwise to write applications that assume anything
about the data based on the structure of the tree (other than apps that
administer the data in ldap), so the tree structure _shouldn't_ matter
too much (yeah, I know, in an ideal world). A simple example of this:
say you have a mail server that receives mail for user joe@xxxxxxxx It
looks in ldap only under dc=abc,dc=org. Sounds good, but what if the
organization has multiple domains - say abc.com and abc.org. Further,
joe receives email to joe@xxxxxxx and joe@xxxxxxxx Joe's login account
has to be under dc=abc,dc=org or dc=abc,dc=com - he can't be under both,
realistically. Sure, you could create his account under dc=abc,dc=org,
and create an alias under dc=abc,dc=com that redirects things to
joe@xxxxxxxx However, now you have 2 entries that represent joe - if he
quits, you have to remember to clean up all these entries - putting all
this in one entry (say mail and mailalternateaddress if you use Sun's
mail server) means it's all in one place and easy to clean up. Also,
you probably have user accounts for the same organization under both,
maybe with aliases in the other. Also, you have to be careful as to
whether or not joe@xxxxxxx and joe@xxxxxxx are different users, or one
is an alias of the other. Also, if you are delegating administration
(say to multiple customers), segregating administration of domains using
this model gets complex or is limiting (i. no customer can have more
than one domain). All doable, but much more complex to keep track of.
If, on the other hand, you create o=abc.org,o=isp, and associate abc.com
and abc.org with that branch (Sun's messaging, for example, has domain
and associateddomain attributes in this entry to define the primary and
associated domains under this branch), and put all users with either
domain under that, things are nice and clean and organized.
On a similar note - even if the directory server allowed you to search
across all trees with a base of "", I'm guessing there's probably a lot
of client software out there that doesn't allow you to define a search
base of "".
Anyway, this is mostly just my opinion - take that for what it's worth :)
- Jeff
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
