Sam Tran wrote:
Jeff, Pete,
So you would definitely go with hierarchical DIT and not flat DIT with views?
Thanks for you comments.
Personally, yes, that is my preference. But... sometimes the apps you
deploy will overrule that. For those apps, views may be the solution
(personally, I've never used views). In some cases, an application
specifies a particular hierarchy, but if you look at what it actually
does in the access logs, there may be flexibility. I.e. the app may not
_really_ care about the DIT, but the app's admin tool does - in these
cases, you may be able to just replace the apps admin tool with
something homegrown. You may have to do that anyway if you are
integrating a lot of apps and want one common admin tool. Designing a
"good" dit can be an art, though, and _can_ have a lot to do with the
apps you are going to use with it.
For a "simple" DIT, have your suffix, then have ou=people, ou=groups,
etc under that to split up different types of entries - that's a simple,
generic DIT, and is the default FDS creates. Definately don't go
completely flat (i.e. _everything_ right under your suffix - I don't
think I've _ever_ seen anyone do it _that_ flat :) ) Define
organizational hierarchy (departments, regions, etc) as attributes in
entries rather than as branches in the tree, if you can.
A lot of the time I see "tall" DIT's because of limitations in the LDAP
implementation (i.e. they have to do that to scale it across many boxes
to handle the number of entries it has to handle), for administrative
reasons (i.e. we have things like o=custdomain,o=isp with ou=people,
ou=groups, etc under it to segregate customers - we can apply aci's and
other administrative limitations based on that), application
requirements (unfortunately), inexperience (people try to define their
entire organizational structure in the LDAP DIT - which is good until
next month when there is a re-org), etc.
Personally, I'd say keep it as flat as possible, but don't be afraid to
create branches where it makes sense (what makes sense is where the
"art" comes in). Basically stay away from creating branches based on
things that are likely to change - i.e. a customers domain probably
don't change very often, but a companies org chart is almost guaranteed to.
Also, remember that these are only guidelines, not hard and fast rules
:) Your specific situation will greatly affect what you do in the end.
Do you have a list of apps you are integrating against LDAP, a list of
requirements for administration, delegation, what can see what, etc?
Maybe throw some of that info on the list and you'll get more concrete
advice that applies to your particular situation :)
- Jeff
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
