Documentation for kolab.conf

[Paul Boddie]

On Wednesday 12. March 2014 15.01.58 Daniel Hoffend wrote:
> 
> I one of my previous mails I suggest rename ALL configuration files in
> Git or in the OBS package definition to be named kolab.conf.dist etc.
> After your setup is done you still have the original configuration files
> and can compare them with your current config.

I think this would be useful.

> Same applies to upgrades. You then always have the current .conf and the
> default .conf.dist file laying side-by-side and can compare them. I know
> Redhat/Centos and Debian have different ways how configuration files are
> beeing handled during an update, but the approach of deliver .conf.dist
> files would be distribution independent. This way you don't lose your
> current configuration if you accidentally press "Yes" during an upgrade
> and replace a configuration file without looking at it (applies to
> Debian only of course). But this would be a major design change I guess.

I think that configuration file management could be improved without any major 
design changes. When writing new setup modules, I started to gravitate towards 
writing code that attempts to edit configuration files rather than having a 
template that gets filled in and written over the top of some existing file 
supplied by another package. Doing this means that lightweight editing, which 
probably suits some packages more than others, has a chance of keeping up with 
modified files supplied by later versions of those other packages.

So when configuring ejabberd or Dovecot, for example, I've tried to write code 
that locates the section of the file concerned with, say, plugins and inserts 
directives into that section. It's certainly harder than the "conf.d" approach 
combined with fairly simple and specific configuration files, but one doesn't 
always have the luxury of such things. Besides, performing search-and-replace 
on a file employing Erlang syntax is surely a challenge worth accepting. ;-)

But that still leaves the issue of what happens to any original files. Just 
making a backup when running setup-kolab probably adds a degree of safety. 
Things like dpkg offer ways of reacting to configuration file changes, but a 
simple additional measure would probably only be beneficial.

I did also wonder about completely separate configurations for some packages, 
although I'm not sure how much sense it makes. For example, one could make an 
alternative Dovecot configuration directory (/etc/dovecot-kolab, let's say) 
where the Kolab-enabled Dovecot instance is set up, and then Dovecot would be 
pointed at that instead of at /etc/dovecot, but I can imagine that not 
everything is so easily redirected.

Paul