[Kroupware] test server: ldap design

[Andreas Jellinghaus]

Hi.

thanks for the test account.

I downloaded the ldap directory and the schema, 
and i am worried about the design.

the main root is "k=kolab" and most data is stored
in the subtree "dc=max,dc=kde,dc=org,k=kolab".

May i suggest to make the normal root
"dc=max,dc=kde,dc=org" and put people data
into "O=People,dc=max,dc=kde,dc=org" ?

Kolab server internal data could be stored in
"k=kolab,dc=max,dc=kde,dc=org".

If two companies merge and both used the same
ip range, for example 192.168.0.*, it will
be some work to merge that. ("pain in the ***")

Same is true for ldap. If both used the same
namespace, mergin server is difficult (e.g.
k=kolab). But keeping that seperate is no
cost at all: unlike ip addresses ldap namespaces
are nor limited. using dc=company1,dc=de and
dc=company2,dc=de will will not cause trouble
and allow e.g. to merge the ldap servers to one
server without any trouble.

Foe example these accounts are not mergeable:
# admin, kolab
# maintainer, kolab
# test, kolab
# kroupware, kolab
# postfix, kolab
# php, kolab
# manager, kolab
# erfrakon, kroupware, kolab
# ugly, kolab
# TEST Admin, kolab
# new_folder, kolab
# bo admin, kolab
# Jan admin, kolab
# p, kolab
# dadada, kolab
# lalelu, kolab

if they exist in several databases.
why not add ",dc=max,dc=kde,dc=org" to the dn?

what is the idea with:
# external, max, kde, org, kolab
dn: cn=external,dc=max,dc=kde,dc=org,k=kolab
objectClass: namedObject
cn: external

I see some objects in that namespace. If this is meant
for external contacts, wouldn't it be nice to seperate
the local accounts from extrnal contacts?

For example with
local accounts	O=People,dc=max,dc=kde,dc=org
remote contatcs	O=Contacts,dc=max,dc=kde,dc=org

that way the mailserver for example could search
with base O=People,dc=max,dc=kde,dc=org for mail
objects, because it does not care about the external
contacts.

For those who want to look at the ldap structure themself,
may i suggest the excelent gnome ldap tool "gq"?
(ok, it does not sort which is a bit annoying, but usefull
 otherwise).

Command line fetishists can use these commands, if you have the
ldap-utils package installed:

Find out where the schema are stored:
ldapsearch -h max.kde.org -x -L -s base "" subschemasubEntry

Get the schema data:
ldapsearch -h max.kde.org -x -L -s base -b "cn=Subschema" \
        objectClasses attributeTypes matchingRules ldapSyntaxes

Regards, Andreas