[Kolab-devel] Horde Based Web Admin Interface

Tue Mar 9 11:23:33 CET 2004

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. 

I am having a bit of a hard time getting arguments for putting the server configuration
into LDAP as well... If you look at something like MS-Exchange, only some of the
functions (mostly things that make sense to be shared) are put in LDAP/AD. 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.)

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

What kind of information should we have in LDAP, and what not? To give you an
idea of what I am talking about, here is the possible configuration values of the
Code Fusion kolab daemon (you can get this output by running kolabconf -d)

#Critical, always in kolab.conf:
base_dn : 
bind_dn : 
bind_pw : 
ldap_uri : ldap://127.0.0.1:389
php_dn : 
php_pw : 

#Enabling and disabling of services:
apache-http : TRUE
cyrus-imap : TRUE
cyrus-imaps : TRUE
cyrus-pop3 : TRUE
cyrus-pop3s : TRUE
cyrus-sieve : TRUE
proftpd-ftp : TRUE

#Daemon management
cyrus-admins : manager
cyrus-autocreatequota : 100000
cyrus_admin : manager 
cyrus_admin_pw : 
gyard_deletion_period : 10080
kolab_dn : k=kolab,dc=host,dc=kolabtest,dc=co,dc=za
kolab_gid : 1001
kolab_uid : 1001
log_level : 2

#Daemon directory integration
directory_mode : slurpd
slurpd_port : 9999

#Active Directory Integration (and fine tuning)
conn_refresh_period : 60

#Directory replication settings
dirserv_home_server : host.echo.codefusion.co.za
dirserv_mailbox_password :
dirserv_mailbox_server :
dirserv_mailbox_user :
dirserv_poll_period : 120

#Mail deferral service
maildefer_header :
maildefer_listen : 127.0.0.1:10024
maildefer_size :
maildefer_talk : 127.0.0.1:10025

#Other/misc - used by other services
fqdn : host.echo.codefusion.co.za
fqhostname : host.kolabtest.co.za
legacy-mode : Include "/kolab/etc/apache/legacy.conf"
postfix-mydestination : $mydomain
postfix-mydomain : kolabtest.co.za
postfix-mynetworks : 127.0.0.0/8, 192.168.0.0/24, 172.16.74.0/24, 192.168.252.0/24
proftpd-userPassword :
uid : freebusy
userPassword : freebusy

#Shared folders location/configuration
sf_bind_dn : 
sf_bind_pw : 
sf_directory_mode : slurpd
sf_dn_list : dc=host,dc=kolabtest,dc=co,dc=za
sf_field_deleted : deleteflag
sf_field_guid : entryUUID
sf_field_modified : modifytimestamp
sf_field_quota : userquota
sf_ldap_ip : 127.0.0.1
sf_ldap_port : 389
sf_ldap_uri : ldap://127.0.0.1:389
sf_object_class : sharedfolder

#User objects location/configuration
user_bind_dn : 
user_bind_pw : 
user_directory_mode : slurpd
user_dn_list : dc=host,dc=kolabtest,dc=co,dc=za
user_field_deleted : deleteflag
user_field_guid : entryUUID
user_field_modified : modifytimestamp
user_field_quota : userquota
user_ldap_ip : 127.0.0.1
user_ldap_port : 389
user_ldap_uri : ldap://127.0.0.1:389
user_object_class : inetOrgPerson

One could argue that it is better to have everything in kolab.conf, thus having only
one place to edit, 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.

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

At the moment you can actually add _any_ value in the kolab.conf file and then
add the appropriate @@@config-key@@@ into a template file and voila, the
daemon is now managing your _config_key_...

Please send your feedback so that we can do this as well as possible...

Kind regards,
Stephan

On Monday 08 March 2004 20:24, Martin Konold wrote:
> Am Monday 08 March 2004 16:36 schrieb Stephan Buys:
> 
> Hi,
> 
> > We are currently evaluating doing a rewrite of the Web Admin interface
> > using the Horde framework. The reasons being:
> >
> > 1) It is a well supported, widely used, php-based framework.
> > 2) We know it quite well, from our Webclient work.
> > 3) We get theme support, session management, etc. free.
> > 4) It has a lot of supporting libraries.
> > 5) Getting the functionality that we need would mean tweaking existing
> > projects, so not a lot of re-invention would be needed.
> >
> > Any comments/feedback?
> 
> In general we also already planned a rewrite of the web admin interface as the 
> current code was done under extreme time pressure and used a lot of c&p. The 
> crude way of how LDAP is itegrated into php also did not help to write clean 
> code.
> 
> We planned an OO php rewrite within the Proko2 projekt.
> 
> > There are a lot of quirks with the current Admin interface, which would be
> > viable to fix, but is it really worth-it creating a whole new framework,
> > when using well-established projects seem more in line with the Kolab
> > philosophy...
> 
> Please elaborate if you want to keep the following strict seperation
> 
> Web UI - LDAP - kolabd - configuration files
> 
> or if you intend to go the webadmin way (directly modifying configuration 
> files...)
> 
> Yours,
> -- 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
> 
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at intevation.org
> https://kroupware.org/mailman/listinfo/kolab-devel
> 
> 
> 

-- 
Stephan  Buys
Code Fusion cc.
Tel: +27 11 391 1412
Mobile: +27 83 294 1876
Email: s.buys at codefusion.co.za

E-mail Solutions, Kolab Specialists.
http://www.codefusion.co.za