Re: name space design

["Corisen" <csyap@starnet.gov.sg>]

Thanks for your advice.

I'm thinking of the following design:

dn: uid=username, dc=company, dc=com
objectclass: .....
....
o: departmentName

dn: o=departmentName, dc=company, dc=com
objectclasss: organization
o: departmentName

Any comments on this design would be greatly appreciated.

I'm having another question: what is the best way to search the ldap
database for the next uidnumber to be assigned to a new user.

Thanks.


----- Original Message -----
From: Karl O. Pinc <kpinc@artic.edu>
To: Corisen <csyap@starnet.gov.sg>
Cc: <openldap-software@OpenLDAP.org>
Sent: Tuesday, November 28, 2000 1:55 AM
Subject: Re: name space design


> >hi, i'm designing an web-based registration. there will be a drop down
list
> >on this web-based form to select the user's department. i've thought of 2
> >ways of dynamically populating the department drop-down list:
> >
> >1. design the ldap name space to contain department name and limit the
ldap
> >query to one level (from root: dc=mycompany, dc=com) to retrieve all the
> >departments:
> >i.e. uid=username, o=departmentname, dc=mycompany, dc=com
> >
> >2. store the department name in a mysql database and dynamically populate
> >the drop-down list by querying mysql.
> >
> >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?
> >2. if a user change department, how can i update his dn to uid=username,
> >o=newdept, dc=mycompany, dc=com?
> >3. how can i delete a department and all the entries under it's tree?
> >4. is including the o=department in the dn a good design? or should i
just
> >use "uid=username, dc=mycompany,dc=com"?
> >5. what are the pros and cons of using "o" in the dn?
> >
> >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.
> >
> >would really apprecaite some insight/advice from the experienced and
> >knowledgeable ldap users in this mail list.
>
> I've no real ldap experience, but lots of database experience.  The
classic
> solution would be to have two hierarchies, one for the users uid=username,
> ou=People, dc=mycompany, dc=com, and one for the departments
> deptnumber=departmentnumber,ou=Departments, dc=mycompany, dc=com.  The
> number of the department would be stored as an attribute of the person.
>
> The only reason I can think of for not doing it this way is that ldap
> dosen't seem to have an SQL like front end available so joining the users
> and the departments to obtain the spelled out department name may require
> some extra coding.
>
> Note that the name I've chosen for the user portion of the hierarchy is
> based on an rfc (see /usr/doc/openldap...) for the storage of unix
> authentication info (/etc/passwd) in ldap.  I made up the department
> portion; I was careful to adhere to the cardnal design rule of never
> putting meaningful information into keys.  So, because the department name
> is not in the key, it's easy to change the name of any department.
>
> Karl
>
> May the Legos (TM) always be swept from your path in the night.
>