> All the sample implementation I have seen uses organization name and > organization unit name for containers of persons, in our case we have: > dn: o=Real Softservice,dc=xxx,dc=xx > dn: ou=Customer Service,o=Real Softservice,dc=xxx,dc=xx > I know these DNs will not be able to change:
Why not? > as LDAP non-leaf entry > cannot change their DN. I wasn't a concern for me in the begining > because I thought company name and department names are not going to > change frequently. But even it's changed once, it's difficult enough for > the admin: I have to do slapcat (in my case I use openldap) and use an > awk script to rename all these dns and add them back; also a restart of > ldap server is not avoidable. Eh? I think every current DSA supports subtree renames. If you need to make large changes online nearly every scripting language provides an LDAP binding. The Directory Services available in .NET are quite nice. > Things become worse when our LDAP server is used as a business > directory: we have many, many organization and departments and sometimes > organization name does change! It's become so frequently now (once > several days) that one of the company in this directory change their > name. Sure they do; we've had an LDAP "business directory" (whatever that means) for years and years. And I've yet to have to do a subtree rename - because we don't use hierarchy when hierarchy provides no benefit and you can accomplish the same thing with filters. > In this case people might suggest I shouldn't have organized > organization and organization units in a tree style, Yes. > But 1) then I would have created an LDAP structure very strangely No. > 2) it's not always easy to foresee future requirements. Yes, which is why hierarchy, when hierarchy provides no function or benefit, is bad. > In this case people might also suggest we should start from a relational > database but 1) our data is truly mostly read: ratio of read and write > is close to 1000/1 and I think this qualify LDAP definition; 2) our data > should be used by a lot of difficult situation (scripts to generate > report lists, web application, client PIM software, variable data > publication etc) and using standard interface like LDAP can greatly help > ease the implementations. I don't see the point or what you mean by #2 at all. SQL isn't a standard? > People might also suggest we use a non-changing value for non-leaf > entries, e.g. > objectClass ( 1.3.6.1.4.1.25640.2.100 > NAME 'entryWithId' > DESC 'this add an ID attribute for any entry that needs to be > non-leaf and need to have an attribute name that does not change' > AUXILIARY > MUST (id) > ) Ok, you can do that. It is non-standard, and you'll loose allot of what I think you are talking about in #2 above. > actually this is what I am having in mind. If truly changing DN for > non-leaf entry is difficult or should not happen, I'll take this > approach. DNs shouldn't change often; no one said they can never change. --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
