Re: Bug#224828: Split config file is worrying...
Andreas Metzler wrote:
| I want to allow people to choose between monolithic and split,
Yes.
| and therefore need to safe this informatin in
| /etc/exim4/update-exim4.conf.conf to modify update-exim4.conf's
| behavior accordingly.
No. update-exim4.conf can determine whether the admin wants to use a
monolithic config file by whether or not the admin has edited that
config file. I described a mechanism for doing that below, which is
based on what X uses for choosing between hand-edited and dexconf-generated
configuration.
BTW update-exim4.conf.conf is a really ugly file name - and those magic
DEBCONFfooDEBCONF variables are a bit yucky, too.
| I can either hide the option in the file or make it _also_
| configurable via a debconf question (of yet to be decided priority).
Or simply not require any additional configuration at all.
| > The logic would look something like:
| >
| > - have an /etc/exim4/exim4.conf.template as you described
| > - compare the md5sum of /etc/exim4/exim4.conf.template with an md5sum of
| > the last automatically generated version.
|
| ? I don't have a last generated version of exim4.conf.template - it is
| newly introduced file.
You don't need a copy of the last generated file, just the md5sum. When
exim4 is installed for the first time, generate exim4.conf.template
using find+xargs as you said, and stash its md5sum away for later.
Then, when update-exim4.conf runs, it sees if the md5sum of the file in
/etc has changed from its stored md5sum. If it's changed, the admin
must have edited the file, and you can ignore the split config files.
Otherwise, use the split config files, and ideally also regenerate the
file in /etc and save a copy of the new md5sum.
That way there's always an up-to-date template in /etc/exim4 that the
admin can edit if he wants to use a monolithic configuration, and if the
file /isn't/ edited, you can use the split configuration.
| The whole point of /etc/exim4/exim4.conf.template is that it is _not_ a
| generated file but a dpkg-conffile, update-exim4.conf *may* *not*
| touch it.
Hmm, that's a good point. The way X does it is to have XF86Config-4
/not/ listed as a conffile, but instead create it in the postinst and
provide conffile-like handling for it (i.e. by always preserving user
changes in it).
BTW Anthony DeRobertis mentioned that X uses ucf to do its magic.
Perhaps it would also be useful for exim4? (Although ucf is Priority:
optional so you might have to avoid using it... or alternatively you'd
have to increase its priority to important?)
| The only thing I think of is to run
| find /etc/exim4/conf.d/ -type f -print0 | xargs -0 cat | md5sum
| and compare its results with the known md5sum of the newly introduced
| file and default to monolithic even for upgrades if they match.
| However I don't want to do that because the config script is usually
| run two times and the generated md5sum will differ because the first
| runs before the new conf.d is unpacked while the second one runs
| afterwards.
If you keep a copy of the last md5sum stashed away somewhere, this
shouldn't be a problem.
Cameron.
Reply to: