-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
When I started with ldap I was totally NOT understanding the concept of a tree
(in ldap).
I started out with the example, which at that time was something like
o=Princeton,c=US
I understood that in the greater scheme of things, the last part
c=US
was of some importance - X.500 directories, where LDAP is a 'lite' form of,
where meant to connect directories world wide and so I figured if I would
ever want to fit in, I'd better use
c=NL
since I was based in the netherlands.
But soon I found out, that there was no real central registry as with domain
names, so no one prevented me from using
o=VU,c=NL
which could well be used for the University in Amsterdam.
Anyway, I was using
o= Ace Suares,c=NL
which was very unlikely to give conflicts.
Then my application was to manage email in qmail-ldap, and that is pretty much
domain-based, so I proceeded with
cn=suares.nl,o= Ace Suares,c=NL
cn=suares.com,o= Ace Suares,c=NL
cn=suares.net,o= Ace Suares,c=NL
and so on. It worked, so far so good.
After a couple of years, the 'dc' (domain component) stuff came flying at me
throught the various mailinglists.
dc=example,dc=com
is probably the most seen suffix.
But I had one problem. I wanted the domain *as a whole* in the DN, so I could
do lot's of funny stuff.
Consider:
<? $domain = $_SERVER['HTTP_HOST']
$dn = 'foo=bar,domain=$domain,c=NL' ?>
(This is sort of PHP code, using the built-in variable that denotes the
hostname this webpage has been requested with).
With rewrite rules (interesting apache technique) I could have just one php
script file, that would serve all virtual hosts!
So, the dc=,dc=,dc= stuff didn't work for me.
Especially with subdomains, consider:
ou=users,dc=suares,dc=com
ou=users,dc=intranet,dc=suares,dc=com
is very hard to write generic ACL's for !
So, then I started thinking another way:
1. the c=NL 'toplevel' has no significance for me.
2. the dc model has no benefit for me.
Then, I named my application 'qwido'.
I requested an OID (see earlier discussion on this list), and started
inventing my own schema.
So, now my tree looks like:
qApp=qwido
qRole=qwidoManager,qApp=qwido
qwidoManager=Ace Suares,qRole=qwidoManager,qApp=qwido
qwidoManager=Brian Bruce,qRole=qwidoManager,qApp=qwido
qRole=qISP,qApp=qwido
qISP=XS4ALL,qRole=qISP,qApp=qwido
qISP=XS4SOME,qRole=qISP,qApp=qwido
qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=BabsJensen@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=JensJensen@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
qUser=Kurt@suares.com,qRole=qUser,qService=qMail,qDomain=suares.com,qRole=qDomain,qISP=XS4NOTHING,qRole=qISP,qApp=qwido
I agree these are very long dn's, and I am not sure if all those 'qRole'
containers are really needed, but when 'browsing' with GQ it does look much
nicer. Also, writing ACL's is quite a daunting task, but once the structure
is clear, the qRole's simplify ACL management considerably.
Also, later I might write another application, which 'toplevel' is
qApp=qwiText
or
qApp=qwikZite
and then later I still might integrate all these trees in something bigger,
maybe sufficing everything with
o=Ace Suares,c=NL
(just a joke).
Which is to say, don't let yourself get dragged into the 'dc' scheme, the
'c=XX' scheme, or any scheme that uses ou, o, cn, uid, and such.
Just make something up that really translates what YOU want to achieve.
If you have some branch that handles addressbooks, and some other branch that
handles boomarks, and you think of these branches as 'utilities', then simply
name them
utility=bookmarks,whateversuffix
utility=addressbooks,whateversuffix
You might have to twiddle with YOUR OWN SCHEMA to make this possible!
Unless you want compatibility or interoperability with a specific existing
tree/aplication, you can use anything that fits.
The longer names like 'utility' instead of 'o' or 'ispManDomain' instead of
'ou' might have some speed penalties, but that shouldn't have to be like
that. It might be that you notice this on a P4 2 Ghz, but then again, on a
Dual Xeon 3.7 Ghz machine the difference might be too small to measure. I
don't know.
This is what I think - it might be wrong, I'd like to hear from someone who
has good arguments to think elsewise!
Cheers,
ace
--On Friday, November 14, 2003 3:35 PM -0500 Raj Balasubramanian
<r0x61j@comcast.net> wrote:
Hello All
Wanted to get an idea of what is the thought process out there in
deciding on a DN? I am specifically curious about DN of format
uid=<id>,ou=users,o=abc (flater) vs. uid=<id>,ou=<mydept>,o=abc (with one
or more flexible OUs).
I have seen the flatter kind more so than the latter, as there are less
dependcies on keeping DN sync with various application storing the DN for
authorization. I also like the idea of having atleast one OU specific to
a grouping of users (division/.dept etc.) so the ACL can be generically
set (if apps support wildcards..
What are some of the common working DN implementations out there?
Thanks in advance and please accept my apoloies if this is a repeat
question.
In relation to this, I'm curious about ou/o vs. dc. We use uid=x,
cn=accounts,dc=stanford,dc=edu for example, rather than uid=x,
??=accounts,ou=stanford,o=edu. What are the pros/cons? Is there a
particular reason to use one syntax over the other?
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
- --
Ace Suares' Internet Consultancy
NIEUW ADRES: Postbus 2599, 4800 CN Breda
telefoon: 06-244 33 608
fax en voicemail: 0848-707 705
website: http://www.suares.nl * http://www.qwikzite.nl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQE/tWhTy7boE8xtIjURAvdgAJ4/VdYQGVQmBxBIYC3hAj8DNbqTOwCgigZZ
R93Yl+vZXR+GCSmy0kCzioc=
=SMbX
-----END PGP SIGNATURE-----