From: Zhang Weiwu <[EMAIL PROTECTED]>
Date: Thu, 14 Jun 2007 16:09:08 +0800
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.
>[Adam wrote:]
Eh? I think every current DSA supports subtree renames.
Think again. No other UMich-derived DSA does; of that lineage only OpenLDAP
back-hdb does.
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.
Those examples are all deceptive; strict hierarchies are only applicable when
each branch is truly disjoint. But e.g. in a university it's pretty common for
some students to also be staff or faculty at the same time. (Was true for me
and a lot of my colleagues back at UMich...) When "membership" is not strictly
single-inheritance, a hierarchical directory structure definitely doesn't help
you. On the flip side, when you're certain there will never be overlaps, then
it's much more convenient than using tag attributes and filters.
Some sites use simple tags
affiliation: student
affiliation: staff
but I generally recommend that these tags be considered as references. Since in
LDAP every object is identified by a Distinguished Name, it makes most sense to
use DNs for all references. In OpenLDAP this becomes even more convenient
because you can use the refint overlay to automatically maintain these references.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
---
You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
