[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ldap
Subject:    [ldap] Re: Tree Organization Design
From:       Adam Williams <awilliam () whitemice ! org>
Date:       2004-04-26 16:55:56
Message-ID: LYRIS-886202-710849-2004.04.26-12.44.11--ldap#progressive-comp.com () listserver ! itd ! umich ! edu
[Download RAW message or body]

> If it is related to file and print or if accessed by more than LDAP, then it maybe \
> best to do a geographic tree.

We find it optimal to organize based upon subsystems (mail, accounts, nss, 
ils, etc...) This makes it simply to divy up access and administrative 
authority to the correct entities.  

Often it is useful also to create subordinate virtual containers (using 
OpenLDAP's back-meta for instance) that "include" the objects that a given 
application needs to see and/or modify.

> For large trees (ie. <100,000) flat seems to work best.

Flatter is better than crazy-deep, but some organization makes it easier 
to implement access control.

> Going a bit offtopic, are there any organizational-science people doing
> actual research on how organizations lay out their trees, what works and
> what doesn't and why, and attempting to cluster the successes, so that
> at some point we'd have some reasonably complete list of "things to think
> about when designing your tree" backed by more than a handful of
> anecdotes?  Most of what I've read seems to depend more on untested
> hypotheses and personal preferences than on solid theory supported by
> data.

We have the general layout of our Dit available online as an example -
ftp://ftp.kalamazoolinux.org/projects/awilliam,  look for edmanual.pdf if 
your interested.
 
> Meanwhile I'll throw out a method which hasn't been mentioned so far in
> this thread.  You could have a tree deep enough to avoid having CN=mwood
> CN=mwood2 ... CN=mwood25, and also avoid having to shuffle the leaves
> around after every reorg., by subdividing your tree functionally and
> paying no attention to the org. chart of the moment.  Has anybody tried
> that?  Did it work well?

Don't rule out the use of multi-values RDNs.  While they initially they 
look ugly they do solve some problems nicely;  we use cn={legal 
name}+o={organization} in customer containers for instance.

> I'll also observe that "too deep" for an organization of 100 people may be
> "too shallow" for [modest cough] the tenth largest employer in one's
> state.

Yep, it all depends.


---
You are currently subscribed to ldap@umich.edu as: [ldap@progressive-comp.com]
To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the \
SUBJECT of the message.


[prev in list] [next in list] [prev in thread] [next in thread]