[Kolab-devel] Kolab administrative web interface: why not using horde?

[Matt Douhan]

On Thu March 3 2005 19:33, Bernhard Reiter wrote:
> Hi Fabio,
>
> On Thursday 03 March 2005 18:16, Fabio Pietrosanti wrote:
> > i have to say that kolab administrative interface is quite uggly even if
> > it have the basic functionality (groups management could be a great
> > addition!).
>
> I am assuming that you refer to handling and funcationality?

I think the kolab webinterface is easy to work with and powerful but yet 
simple, works very well for us on some very large installations. 

>
> > Horde is the webgui of kolab and the dev effort for the "web" component
> > will be done on horde.

Sure Horde is nice, all the way until it selfdestructs your server, Been There 
Done That I don't know how many times now, that is also why I am heavily 
invlved in trying to fix it and progress has been made to incorporate Horde 
more and more into working with Kolab, and in the long run I do not see any 
issues with using Horde to manage the Kolab server, but I do NOT think it is 
a replacement of the kolab webinterface itself, the server itself must have a 
management interface that is not an optional component, and Horde for sure is 
an optional component.

>
> We hope so, the main problem to solve as I was informed
> is the speed problem that mainly arises from the direct imap use
> without extra cache on horde.

This I also see as a development in the future, and work has already started 
to speed it up, Stuart has already made changes on speeding up the access by 
reducing the nr of hook calls per synch and so on.

>
> > Kolab web administration if i understand correctly do two basic stuff:
> > - read and write ldap directory
> > - create mailbox, create shared folder, set permission on cyrus server.
>
> Most of that stuff is done by the kolabd components.
> And it makes sense to move even more configuration in there
> and let it do more stuff to make the server completely independent
> of the ldap client used.
>
> > Horde right now work well for ldap administration and theorically could
> > already add users to kolab server.
>
> I haven't checked how good horde's ldap client is.

IT is pretty nifty, but as I said above, it does not make any sense to me to 
bring in the Horde framework as a requirement for the already nice Kolab 
interface.

>
> > Horde support the cyrus administration within the "composite" driver.
>
> What is the permission situation here?
> Most webbased administration interfaces will have huge portions of code run
> as root. Kolab tries to avoid this for security reasons.
> I don't think that the major design that the kolabd reacts when the ldap
> changes shouldn't be changed for the administration of cyrus and other
> parts.


I could not agree more on this one, and I think everyone that has tested 
Horde+Kolab will agree that the ACL handling in Horde is a bit wobbly, again 
this is why I am devoted to aid in the financing of fixing it and Stuart is 
working and getting closer to finally nailing that issue that I and others 
involved in our testing call "The Horde Selfdestruct" (tm).


>
> > Horde will have within months completed the ldap datatree (my company
> > will sponsor it) so it will work completelly without the need of a SQL
> > backend.

Great to see that others are also stepping up to the plate here :)

>
> It is good news that Horde gets independend of an SQL RDBMS,
> but will it use ldap as database then? This would be a major design
> difference as other kolab clients do you their local cache
> and the ldap in the kolab server is mostly for read operations.
>
> > Horde in future will probably become part of the kolab distribution,
> > packaged along with cyrus, postfix, openldap, apache, etc, etc.
>
> Currently the plan is to keep it seperately as extension,
> because we expect Horde to hit performace in setting with more users.

This is interesting, when it works, it works very well, how many users are you 
talking about when you are expecting to see problems?

We have done some large scaling testings on an IBM 360 DUAL XEON with 4 GB RAM 
and a large RAID10 disk system and as long as HOrde does not selfdestruct I 
do not foresee any real issues as the nr of clients reaches other limits.

It will need a caching function for IMAP and it needs to stop its 
selfdestructing behaviour.


>
> > My question/proposal is:
> >
> > Why the need to rediscover the hot water when someone already did it and
> > we could just need to put the "lemon" to have lemonade (Kolab server +
> > Horde Web Administration)?
> >
> > I'm sure that there are a lot of good motivation to use an indipendent
> > web administration interfaces but i think that horde administration
> > could be easily extended to do all "user" administration stuff of Kolab.
>
> Well, why not have another possibility for a ldap client
> that can administer kolab?
> For the reasons above it seems good that the bare bones kolab webadmin
> exists as some people do not need a web client at all
> (most  users have a better GUI experience with native clients,
> that can even be used offline.)

I totally agree and this is the important point, lets not force the Horde 
framework onto the kolab server, the server needs its independant management 
interface.

>
> > We could also think to keep the kolab administration interface for all
> > the "infrastructure" settings, leaving on horde all other "user
> > administration" stuff like "add users, add group, add alias, add
> > addressbook, add administrator, set permission", etc, etc
>
> Well you can add "groups" in the kolab webadmin, they are called:
> distribution lists and end up being a groupOfNames LDAP object.
> They can be used to set the automatic invitation handling for instance
> or to give our permissions, because the are mapped to imap groups.
>
> If we had a real multidomain feature we probably wanted to handle
> those groups of users in different ldap subtrees. This is a major
> operation. It would be cool it somebody would fund or do that step for
> Kolab.

After the Horde framework is reaching usable state, and only support is 
needed, my sponsorship will be put towards multidomain and HA support.

Currently my primary concern is a usable web client, but if someoone steps up 
to aid in the multidomain part I will definatly help out, I just cannot take 
such a task on myself.

-- 
Matt Douhan
www.fruitsalad.org
kolab2 + kontact + toltec == success
Now lets get Horde into shape mmkay