Thanks a lot for this detail message!
On Wed, 2007-06-13 at 22:25 -0400, Adam Tauno Williams wrote:
> > 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?
[EMAIL PROTECTED]:~/public_html/acd> ldapmodrdn -x -D ... -W
uid=realsstest6,ou=contacts,ou=china,dc=ahk,dc=de uid=test7
Rename Result: Operation not allowed on non-leaf (66)
Additional info: subtree rename not supported
>
> > 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.
Okay, so probably my choice is not so optimal and didn't have a full
picture in mind. I used OpenLDAP since the beginning.
>
> > 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.
Thanks for sharing experience!
Can I know if there is a reason to use any kind of hierarchy structure
at all? Well I already know one, ease of replication (certain subtree
can be on a different server), is there any other?
If there is no good reason or situation where we should prefer hierarchy
structure, I got a good lesson to learn this time. I was a bit "mislead"
because I read no less then 5 reference implementation (googled from
online, some are university implementation for students record etc )
before starting ours and they all use hierarchy structure. Maybe that's
because they considered this first, that a university is unlikely to
rename, but they probably also have other reasons to prefer hierarchy
structure.
>
> > 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?
I just need to explain my situation (scripts to generate report lists,
web application, client PIM software, variable data publication etc) to
a much more detailed example so you get me. SQL is standard, it is
standard to this extent:
I. if we use SQL, after web application is done, next task is to
design a plug-in for Outlook so that they can access the
business directory, for the plug-in to work I need to dig into
MS Office SDK and learn XML-rpc and provide something on the
server end to handle the XML-RPC and convert to SQL statement to
sort out the result.
II. After this is done, next task is to design a plugin that work
with Lotus Notes.
III. And after that, for variable data publication to work, a plugin
for publication design software is needed to fetch data from a
server (probably can handle XML-RPC) which in turn run SQL
statements. Next task is to consider security issues of all
these plug-ins.
IV. Other small cases: e.g. someone need a report that made up out
of the list of 30 most recently updated records. For security
reasons I don't open SQL access directly to this person who I
don't know before, so I have to write a script on SQL server
that give him raw data needed for the report. (in case of LDAP,
he can connect to the LDAP server with any tool he like to use,
and he don't even need to call me to let me know he is working
on a report because he can use the same identity to login as he
login with Outlook)
>
> > 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.
I don't do this if subtree rename is possible or if I started with a
flat structure.
And thanks to inform me that some DSA support subtree rename:) I just
thought it's not possible.
---
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.
