On Sun, 26 Nov 2000, Corisen wrote:
> my worries about method 1 is as follows:
> 1. if the department changes name, how can i update the dn of all the users
> under this department tree?
Direcories are heirachical. The DN is the directory address of an entry.
You don't need to rename all the children in a tree any more than you
would need to change the names of files or subdirectories when renaming a
parent directory on a filesystem.
> 2. if a user change department, how can i update his dn to uid=username,
> o=newdept, dc=mycompany, dc=com?
The LDAP API has methods to copy, move (rename), and delete entries. There
are also command line tools.
> 3. how can i delete a department and all the entries under it's tree?
OpenLDAP doesn't support recursive deletes, but implementing the code to
loop through a list and delete the entries one by one is relatively
simple, depending on the programming language you are using.
> 4. is including the o=department in the dn a good design? or should i just
> use "uid=username, dc=mycompany,dc=com"?
In my opinion, yes. I like my directory database segmented by organization
and even by organizational unit. I find it useful to bind different
applications to different directory trees for context, but directory
structure is a matter of style and need -- your structure should refelct
your needs and your tastes.
> 5. what are the pros and cons of using "o" in the dn?
It is really a matter of the structure you are hoping to use and the LDAP
policies and applications you intend to implement.
I'd recommend you pick up a good book on directory services, like
_Understanding and Deploying LDAP Directory Services_ [Howes, Smith,
Good].
Keep in mind that the power of a directory is in it's structure and
flexibility, versus the relational databases where the power is in the
relationships between two dimensional tables and its performance.
> using method 2, the name space design is simpler: uid=username,
> dc=mycompany, dc=com. but i have to keep duplicate/two sets of department
> records. one in mysql and one in ldap. and they must be synchronise when any
> department is modified, deleted or added.
>
> i really have no idea what might be the complications for each method and
> which is a better way of designing.
Basically, I would recommend sticking with mysql unless you plan on
leveraging LDAP for other applications and services. A LDAP server can be
a powerful tool, but poorly maintained and with irrelevant or incorrect
data it only serves as a source of disinformation or worse, a security
policy problem.
thornton
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
