[Kroupware] test server: ldap design

[Tassilo Erlewein]

Am Freitag, 25. Oktober 2002 03:19 schrieb Andreas Jellinghaus:

You make an interesting point. In fact we have already worried about that=
=2E

> the main root is "k=3Dkolab" and most data is stored
> in the subtree "dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab".
>
> May i suggest to make the normal root
> "dc=3Dmax,dc=3Dkde,dc=3Dorg" and put people data
> into "O=3DPeople,dc=3Dmax,dc=3Dkde,dc=3Dorg" ?
>
> Kolab server internal data could be stored in
> "k=3Dkolab,dc=3Dmax,dc=3Dkde,dc=3Dorg".
>
> 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 ***")

First, kolab server config data is thought to be
as less domain specific as possible. We will not use
several instances of services (postfixes etc.etc.) so
the config objects correspond each to one service.
Also, as you know, Cyrus imapd is completely unaware
of such little differences like mail domains ;-)
etc. etc.

So, we need k=3Dkolab to have a well-defined place in the LDAP=20
tree for administrative use. As the administrative tools rely
fully on ldap we simply need this well-defined root. We also have
sort of boot strapping problems when we go without=20
k=3Dkolab.

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

Just to be sure we are talking about the same:=20
you can merge user and address book data quite easily,
this is possible right now.

> Foe example these accounts are not mergeable:
> # admin, kolab=09=09
> # maintainer, kolab
> # manager, kolab
> # ugly, kolab
> # TEST Admin, kolab
> # bo admin, kolab
> # Jan admin, kolab

these are administrative and maintenance accounts
_without_ E-Mail addresses, just for the webinterface.

> # test, kolab

a shared folder (this could be moved under the domain
tree - you're right!)

> # kroupware, kolab
> # erfrakon, kroupware, kolab
this are abandoned o and ou objects which are not used anymore, trash it

> # postfix, kolab
> # php, kolab

kolab server configuration, once needed per server, not domain, as said a=
bove

There are even more of these:
imapd,kolab ; proftpd,kolab ; saslauthd,kolab ; apache,kolab ; even=20
slapd,kolab (although I'm not sure what to put in there)

php you shouldn't see. That's a bug in my access rules.
postfix the users need to see partly because of their domain setting.
That will change in future, as we don't want this.

In principle, if two servers merge one has to
think about the administrative users anyway IMHO.
Also, there are certainly not thousands of them.
Personally I would not say that merging a couple of=20
administrative accounts is a pain in the a**
But yes, you will not be able to click your way through.

Another point is, that administrators and maintainers do not depend=20
on the domains. That might well be discussed when we attack=20
ISP scenarios later, probably. It is thinkable and doable.

> what is the idea with:
> # external, max, kde, org, kolab
> dn: cn=3Dexternal,dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab
> 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?

This is a requirement brought in by the customers. And the more
I think about it (after implementing it ;-)) the more I like it.
Basically there are three types of Mail Users:

1. Regular Users with E-Mail functionality visible by using LDAP anonymou=
sly,=20
under dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab

2. Users with Email Account but invisible for anonymous LDAP users under
cn=3Dinternal,dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab=20
(note that the "internal ..." subtree does not grant read permissions to=20
anyone)

3. Address Book Entries, that only reside in LDAP (no Email-Users, no=20
Webinterface Login). They reside under=20
cn=3Dexternal,dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab.
Think of it as global contacts.

-> only one search base is needed for the outside world:=20
dc=3Dmax,dc=3Dkde,dc=3Dorg,k=3Dkolab

> For example with
> local accounts=09O=3DPeople,dc=3Dmax,dc=3Dkde,dc=3Dorg
> remote contatcs=09O=3DContacts,dc=3Dmax,dc=3Dkde,dc=3Dorg

My view is that the o attribute is meant to hold different data.
But anyway, how we name the internal,external subtree isn't
much to worry about (?) The namedObject as I see it is
ideal in this place because we only need a tree node with
no special information.=20

> that way the mailserver for example could search
> with base O=3DPeople,dc=3Dmax,dc=3Dkde,dc=3Dorg for mail
> objects, because it does not care about the external
> contacts.

Yes I know. But where is the point ?
What's better with prefixing o=3Dpeople instead of just leaving
it away and let LDAP's access rules do the trick ?

> 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).

yeah we also use gq now and then, this is quite a good one

OK:

If you find a solution where our administrative tools still can find
the kolab server config data at a well-defined place, I would
love to hear it. Think about a just-installed server. No domain
yet. Or so. Think you have to get up all services at least
to a reasonable level to start using the webinterface with
ldap and create cyrus users.

Another solution we had thought about was locating the kolab
server stuff in a complete different LDAP tree. However I failed
configuring openldap to serve two databases at the same time ?
Does anybody know how to achieve that ?
If that can be done, I would gladfully look again at not=20
having the k=3Dkolab stuff appended to each entry.

Tassilo