Re: [Fedora-directory-users] Virtual DIT views vs hierarchical DIT

[Jeff Clowser <jclowser unitedmessaging com>]

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