[Kolab-devel] Horde Based Web Admin Interface

[Martin Konold]

Am Tuesday 09 March 2004 11:23 schrieb Stephan Buys:

Hi,

> To me the seperation is also of exteme importance and I would like to
> retain it.
>
> LDAP -> kolabd -> configuration files/functions
>
> This makes the most sense for things like Users, Groups, etc.

Yes but not limited to these.

> I am having a bit of a hard time getting arguments for putting the server
> configuration into LDAP as well...

Simply think about seperation. The Admin GUI might run on a different machine 
than the Kolab server. The Admin GUI has _no_ root permissions! 

Imagine a _large_ multi-location, multi-domain cluster. Using LDAP allows to 
have a scalable and secure administration seperated from the actually running 
machines (might be hundreds across continents).

In the future LDAP also allows for good global logging, reporting and even 
roll back and nice backup and recovery.

> If you look at something like 
> MS-Exchange

MS-Exchange is _not_ a model to gain a secure and scalable groupware solution.

> , only some of the functions (mostly things that make sense to 
> be shared) are put in LDAP/AD.

If you look closely at AD you will notice that AD is actually a distributed 
domain/enterprise wide global registry. MS puts everything into AD they used 
to put in the registry. AD is cryptic as hell with all the GUIDS....

> The rest of the server configuration is done 
> through the Exchange Administrator which makes a direct RPC connection to
> the server (for managing mailstores, etc.)

Doing it this way is a _very_ bad idea.

> Then there is the Novell model for having _everything_ in LDAP/NDS...

If it is done right it is ok. Novell unfortunately is not really doing LDAP 
because NDS is more a directory server which happens to have a partial LDAP 
interface.

> One could argue that it is better to have everything in kolab.conf, thus
> having only one place to edit

Yes, everything shall stay in LDAP.

> , we could project kolab.conf into LDAP using 
> the shell-backend (see
> http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/13.html) for OpenLDAP.

Why a bourne shell script? Sofar we used perl. Perl is imho better suited than 
shell.

> Alternatively we could synchronize kolab.conf with OpenLDAP or have
> everything, except the critical parts, in OpenLDAP. One advantage of having
> everything in LDAP would be that _all_ options would need to be added to
> the Schema and thus appropriately managed. We lose a lot of flexibility
> this way though...

By going the LDAP way we avoid dirty quick hacks with even more dirty side 
effects.

Regards,
-- martin

Dipl.-Phys. Martin Konold

e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Nobelstrasse 15, 70569 Stuttgart, Germany
fon: 0711 67400963, fax: 0711 67400959
email: martin.konold at erfrakon.de