Re: Smarter handling of generated configuration files
On Mon, Jul 23, 2001 at 12:43:59AM -0400, Matt Zimmerman wrote:
> - In config, at whatever point it makes sense to ask the question (debconf
> should already be loaded):
> config_conffile_ask <priority> <package>/<question> "Package Name" /etc/package.conf
> This call will look up the hash saved by a previous configuration
> run (above) and compare it to the hash of the current config file.
> If they are equal, no action is taken. If they differ (indicating
> that the file has been hand-edited), the user will be prompted via
> debconf as to whether or not it is OK to overwrite the existing
> configuration. A stock template is used, and the package name
> and configuration file are substituted into it. The resulting
> answer is saved in <package>/<question> for use in the postinst. It
> might be better to always ask this question at a fixed priority; I
> haven't decided.
i do something like this in my vhosting system (not yet packaged for
it generates config file fragments for apache virtual hosts, in
when the fragment is generated, it also creates an
/etc/virtuals/apache/DOMAIN.md5sum file. the next time the generator
script is run, it checks the md5sum of the .conf file again. if it
matches the .md5sum file then it just overwrites the .conf. if it
doesn't match then the conf file has been hand-edited and it generates
the new conf file as /etc/virtuals/apache/DOMAIN.new. it's then up to
the sysadmin to hand-merge any changes as required.
on my systems, 99% of vhosts never get hand-edited, so there's only a
handful of .new files which need to be checked by hand.
the reason for doing it this way was so that i could make changes to
individual virtual hosts (e.g. adding new features such custom cgi-bin
directory, ssi support, etc) by editing the config file and running
"make". and also so that i could make global changes to all vhosts (e.g.
change the logging pathnames or document root directory tree) by editing
the config generator script and running make.
it's important to be able to improve the system and get those
improvements into old vhosts, but not at the price of blowing away
hand-edited changes (doing that is evil, there is never any excuse for
anyway, this is another way of doing it which doesn't require asking yet
another bloody question at install/upgrade time.
craig sanders <firstname.lastname@example.org>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch