Kolab templates (Was: Re: [Kolab-devel] Kolab-CF and Template file handling)

[Stephan Buys]

Regarding the packaging of template files, here are some of our ideas:

One of the ideas that we had was that packages that utilise Kolab could
have a "define 'with_kolab yes'" directive that would install the appropriate
template file within @l_prefix@/etc/kolab/templates/ 

Another idea we had was to create a UPDATE_MECH directive in the Meta
data. One of the mechs would be "shell". The Kolab::Conf mechanism would
then automatically pipe the .template file into an executable and take the
output from STDOUT and write it as the new config file.

You would be able to do any kind of magic you want then, one idea I had
was to have a "stub" template, with no content except 
UPDATE_MECH=shell(/path/to/executable)
KOLAB_END_META

This executable could run mysql or LDAP queries (or do anything you can
imagine) and spit a config file to STDOUT, and that would then be used
as the config file.




On Saturday 24 January 2004 01:31, Martin Konold wrote:
> Am Friday 23 January 2004 11:15 pm schrieb Thomas Lotterer:
>
> Hi Thomas,
>
> I very much agree with your points about security in your other mail.
>
> > Kolab currently throws away the default configuration that comes with
> > the OpenPKG packages.
>
> In order to keep Kolab working across updates of OpenPKG packages we don't
> wanted to be exposed potentialy unexpectedside effects of decisions made by
> the OpenPKG packagers.
>
> > The concept is to deliver own templates, merging
> > in user customizations then deploy the final configuration to the proper
> > destination.
>
> Yes.
>
> > The templates I've seen, as far as they can be still identified, come
> > from ancient versions of OpenPKG v1.1 or v1.2.
>
> Yes.
>
> > Since then, OpenPKG
> > updated many open source applications and with them the default config.
> > Kolab keeping it's own templates continously runs the risk of getting
> > out of sync here.
>
> From a scientific point of view any merging algorithm is doomed to fail
> sooner or later due to the fact that the maintainer of the OpenPKG package
> cannot be expected to always anticipate all requirements of Kolab.
>
> > this behaviour. The best I can think of is that the Kolab install no
> > longer comes with rigid templates but takes the OpenPKG defaults and
> > applies transformations to them.
>
> Sofar I am not convinced.
>
> > The metatemplates Stephan is thinking of are just another
> > transformation.
>
> Well, Stephans metatemplates take a lot of hardcoded stuff out and turn it
> into a more flexible and more transparent solution. In addition the
> information is now stored close to the actual data (config file) and not in
> the transformation code.
>
> > So would be some sort of a INCLUDE to gather
> > configuration data from various sources.
>
> This is the approach of SUSE with their apache config. This is not bad but
> lacks for power users.
>
> 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
>
> _______________________________________________
> 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