[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Tree layout / functionality confusion

Neil Streeter wrote: 
As I understand it, the generally wise way to setup a tree is to have a
branch for people and a branch for groups... I can do that no problem...
and have.. Within the unit people, I then have a few test entries with
an RDN of:
 uid=user,ou=people,dc=mydomain,dc=edu
Each of these 'people' entries are entitled to attributes in...
inetOrgPerson, organizationalPerson, person, posixAccount, eduPerson,
and of course top...
... 
Then I have a userPassword in three different locations... and that's
not what I want...

No it isn't. You should put the accounts in one spot (e.g. ou=people,dc=mydomain,dc=edu), and use an unused attribute from any of the numerous object classes your account entries participate in to store the second path. Another option would be to put related objects elsewhere in the directory as you outline, but don't make them full accounts. Instead, just use a dn attribute to point back to the account entry and put the path in another field. Unfortunately, this option will probably force you into doing two searches to get the info you want.

Another thought that I haven't played around with much is extending down
below the uid=somebody,ou=people,dc=domain,dc=edu tree for each ftp
box... which to me, seems like it would have some advantages in that
when the entry was removed it would remove everything below it...

Not always, it depends on the client, but frequently you have to delete leaf entries before superior parents.

Jon Roberts
www.mentata.com