[Kolab-devel] Autofoo Proposal

[Jeroen van Meeuwen (Kolab Systems)]

Gunnar Wrobel wrote:
> Hi Jeroen,

Hi Gunnar,

> > I'm playing around with releasing, in full, the power of autofoo onto some 
of
> > the Kolab packages.
> 
> "Some of the packages"? It would be restricted to kolabd, wouldn't it?  
> At the moment kolab-webadmin is the only other package that still uses  
> the dist_conf approach and that needs to be changed at some point.
> 

Euh, yes, only kolab and kolab-webadmin from the source package point of view. 
I was thinking of the binary fall-out with possible sub-packages and such.

> >
> > I came to this plan through dist_conf/ and OpenPKG, which I believe have a 
1-
> > to-1 relationship.
> >
> > Instead of using static dist_conf/* files, which turn outdated  
> > rather quickly,
> > are volatile and do not allow for any flexibility on the user end, I  
> > wanted to
> > use autoconf.
> >
> > Hence, I whipped up a Wiki page[1] explaining what I want to do and  
> > how I want
> > to get there.
> >
> > [1] https://wiki.kolab.org/index.php/Autoconf_Proposal
> 
> Another build time tool will not change the basic problem though. It  
> will still configure the package while building it. The server  
> configuration can easily be changed during runtime though. Yes, you  
> can rebuild your kolabd package but to me a changed configuration  
> should usually not result in a package rebuild. At least if no change  
> in linking binaries is involved.
> 

The "problem" of configuration is two-fold, I think.

One is the problem of the default configuration files that end up on the 
system by installing the packages. These are provided by the distributor, 
vendor and/or by upstream. In this case, the distributors and the vendor will 
have to go with a single build ending up on many systems as possible, at the 
least administrative effort for all participants in the ecosystem. The default 
configuration files must therefor align with various other aspects of the 
system.

The configuration is difficult enough without an extra paragraph in the 
configuration manual on changing a default setting ;-) Additionally, one could 
argue it's way more efficient to spend the time upstream once, at the 
distributor once, then to have thousands of people run in circles checking 
their default configuration files for error-by-default.

The other side of the problem is what happens when (part of) the configuration 
on the system is changed. Some distributions require /etc/init.d/*, others 
have *ctl commands, and some prefer to have such handled by kolabsrv. 
kolabconf can be used for such (execute the actions to propagate the changed 
settings), but needs to know where to find what, too. We can leave that to the 
user, but we have to start out with sane defaults.

The way that the packages work once deployed is subject to all of these 
conditions (and probably some more). However, each of these aspects is 
(related to what is) injected into the packages during built time.

> I'm also against auto-detecting the server configuration. The Kolab  
> server configuration is quite complex and actually not very flexible  
> when it comes to exchanging one of its components. LDAP has a certain  
> amount of flexibility, the spam filter too, but exchanging apache will  
> already be difficult. Exchanging postfix would seem impossible to me.
> 

By saying "auto-detecting the server configuration", what I meant to say is 
detecting where, for example, php is located (it's used in, for example, the 
master.cf.template, but also the httpd.conf.template), or cyrus.conf, and many 
others. For example, I would like to have an option that allows me to disable 
kolab assuming the LDAP server is local (and thus pulling in the requirement 
by means of packaging). Red Hat Enterprise Linux customers and CentOS users 
don't think that's funny. Yet though, on a standalone Kolab server, requiring 
some ldap server makes perfect sense (think ClarkConnect). I would thus like 
to be able to toggle those options during build time.

> As mentioned I agree with you that the dist_conf approach is  
> problematic for packaging Kolab natively. I have been on a path to  
> remove it step by step from the Kolab server during the last years.  
> I'd just like to continue that path and if its something that hinders  
> you in packaging Kolab natively then it is something we might rather  
> tackle sooner than later.
> 

I'm working on it too, let's see if something like autoconf can help us for 
some part.

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08