[Kolab-devel] Anybody currently working on the kolab web interface?

[Stephan Buys]

Hi Martin,

On Tuesday 23 March 2004 12:19, Martin Konold wrote:
> > 2) The kolab.conf file stays the same. (Just with a lot more options)
> 
> Can you provide me with a list of intended new options?
>
Please consult the kolab.globals...
Also, http://intevation.de/pipermail/kolab-devel/2004-March/000903.html has a bit of
information about it...
 
> > The effect of this is that whenever you change _anything_ on the Kolab
> > server object in LDAP that the kolab.conf file is modified directly. The
> > net effect is that the Daemon only has one place to look for information
> > and that is kolab.conf.
> 
> If I understand correctly than this means the the current kolab.conf is only 
> written during bootstrap but that the future kolab.conf is configurable via 
> LDAP?
Actually, kolab.conf becomes the database for the kolab server object in OpenLDAP.
More details later in the mail. So in answer of your question, yes. We write it during
bootstrap and it becomes configurable via LDAP during operation.
 
> > This way we sidestep any synchronization issues between the Kolab LDAP
> > object and kolab.conf
> 
> I don't understand this. 
Ok, this is following on my mail http://intevation.de/pipermail/kolab-devel/2004-March/000903.html

The problem with Kolab at the moment is that there are two places to get configuration information
from. The Daemon first loads kolab.conf (to get the binds and passwords) and then loads the LDAP
attributes of the object into the same hash (this is the case for Erfrakon's as well as Code Fusion's
version). 

We have actually run into problems where LDAP refuses to start, so you cannot rewrite the
configuration files (using the templates). Chicken and egg problem.

With this proposal there is only one place to configure Kolab and that is kolab.conf

The power we get from this is that admins can add their own fields to kolab.conf, then update
the template files with their @@@new-attribute@@@, and suddenly Kolab starts to be aware
of that configuration value.

> Hmm, sofar the LDAP directory was the only authorative source of information. 
> What do you can with kolab.conf in between? Why do you think it solves 
> synchronization issues?
>
And in a sense it will still be. We are adding an LDAP interface to kolab.conf
 
> > You can still point the Daemon to use LDAP (instead of 
> > kolab.conf for everything) as it used to be.
> 
> I still prefer the old behaviour as long I dont understand the advantages of 
> the new behaviour.
> 
Refer to the chicken and egg problem, also the ability to extend the templates. 

> > - Templates are not rewritten upon _every_ LDAP modification. (Although
> > this is still possible)
> 
> Templates never got rewritten but for simplicity we regenerated all 
> configuration files (based on templates + LDAP data) every time a change 
> happened. 
>
My bad. I meant configuration files. (using the templates)
 
> With the old scheme it is of course possible to avoid this and optimize to 
> only write those files which are actually affected by a change in the LDAP 
> directory.
> 
I am fully aware of this. It gets even better with the new OpenLDAP which now
supports the ldaprepl method of synchronization.

> > Architectural Changes:
> > - When you change something on the Kolab server LDAP object, the template
> > rewrite mechanism gets triggerred by the OpenLDAP backend (and not by the
> > slurpd replication monitor).
> 
> What is your OpenLDAP backend. This terminology is confusing to me as the 
> OpenLDAP people define the OpenLDAP backend very differently. (meaning the 
> actual storage machanism e.g. gdbm, SQL,...)
> 
kolab.conf becomes the database for the Kolab server object instead of bdb or ldbm.
We use perl to accomplish this. Please refer to: man (5) slapd-perl

> http://www.openldap.org/lists/openldap-devel/200306/msg00076.html
> 
> How does the your backend know that something changed in the directory. 
> 
> Please note that we only use the slurpd replication monitor in order to notice 
> that something changed we dont use it to transfer data.
>
Fully aware of this. The fact that we _are_ the database now allows us to act more
intelligently.

> > Horde Web Frontend
> > -----------------------
> >
> > - This will be a drop-in replacement for the current Admin interface and
> > will only operate on objects in LDAP.
> 
> Good!
> 
> > We have no intention of breaking this 
> > design. (With the possible exception of Postfix Queue management)
> 
> How do you intend to make web based queue management?
>
This was hypothetical... We could write a perl OpenLDAP backend for it ;-) 
No plans yet...
 
> Which user/permissions does the web interface have? 
> 
It runs under apache...

> Does it have root permissions?
>
Depends on how you configure apache.


Regards,
Stephan