Dear list
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: 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.
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.
So, is it possible to 'break the rule' and ask LDAP servers to do modrdn
anyway for non-leaf entry? How do you suggest what I should do?
Thanks in advance!
P.S.
In this case people might suggest I shouldn't have organized
organization and organization units in a tree style, I should have used
a flat structure that all organization and organization units are leaf
nodes. But 1) then I would have created an LDAP structure very strangely
and 2) it's not always easy to foresee future requirements.
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.
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)
)
dn: id=organization123,dc=xxx,dc=xx
structuralObjectClass: organization
objectClass: entryWithId
o: Real Softservice
id: organization123
...
dn: id=department2,id=organization123,dc=xxx,dc=xx
structuralObjectClass: organizationalUnit
objectClass: entryWithId
ou: Customer Service
id: department2
...
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.
--
Zhang Weiwu
Real Softservice
http://www.realss.com
+86 592 2091112
---
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.
