[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: backing up/replacing files from another package

Matthias Urlichs wrote:
> > As packages are normally upgraded through the life of a system I train
> > people to always say 'Y' to the replace a conffile question.  Sure
> > this may leave the system in a generic and locally unworkable state.
> So why not "N"? That may leave the package, at worst, in a "I can't find
> a necessary setting and am going to crash" state, but the following call
> to your sysconf program will wake it up right away.

Most of the time that would be completely true.  Especially for tiny
files like /etc/auto.master.  But for other files with more
documentation in them I prefer to get the new file with the new
comments in them.  Thinking of files for apache, postfix, bind, and
other packages with complex conffiles.  But you are right that if my
script is written well it would work either way.  If my script is not
well enough written then I might have a bug.  :-)

> On the other hand, "Y" will replace that file with a generic version. At
> best the package does nothing, but at worst it'll have inconsistent
> configuration and do some random things which aren't expected.

The package should not do anything unexpected.  It should work as if
you had just installed the package on a new machine and had not yet
done any configuration to it.  Debian packages should "just work" out
of the box.  If a package needs some configuration then it should
behave reasonably until further configured.  Since my system
configuration scripts will be launched and run after the update things
will be configured again in just a moment.  Mail is the only package
which I think has any time where it won't work right on my site with
the default configuration.  But it should be back working again right
away after our scripts run.  Other things may be confused for a while
but for the time we are talking about it is not significant.

Basically I can't give good arguments strongly for either Y or N once
we have a script in place to automatically set the package
configuration for our site.  You have asked a good question and I
could see people debating it either way.  I just prefer to have the
latest commentary in the files.  That way new machines and old
machines both look very similar.  Then by looking at the conffiles you
won't be able to tell that it was a potato machine updated to woody
updated to sarge.  It will just look like a sarge machine.

When I write a script to configure a package I normally have two
choices.  1) I can replace the entire file with my own configured copy
of the file.  2) I can read-modify-write the file to only change what
I need to change.  This preserves other changes that may have been
made in the file.  For the /etc/auto.master case I just replace the
file whole.  For the case of /etc/postfix/main.cf I only modify things
like the transport map, which we use on our site, and leave other
things alone since there are many options that could be host locally
configured there.

Getting back on topic for d-m let me suggest that package authors try
to set up files such that they can be mechanically updated whenever
possible without the need to read-modify-write.  Directories of
configuration files are great because then a single file can be copied
into place and everything else left untouched around it.  And this can
be undone with a simple removal of that file.

Of course /etc/cron.d/* is a classic example of directories of files.
And /etc/apt/apt.conf.d/* is another.  I can place a file with our web
proxy configuration there easily.  And /etc/spamassassin/*.cf also
allows easy, automated configuration.  But ssh is the opposite case.
It has only a single file /etc/ssh/sshd_config and so that is a
read-modify-write case.

Most of these issues are forced upon the maintainer by the upstream
architecture.  But sometimes you can make it work.  The latest bind9 I
see uses 'include /etc/bind/named.conf.local' which simplifies the
local configuration section.  The main file I can leave unchanged and
just completely replace the local section.  This is a nice way to
organize the files.


Attachment: pgp_KYDlrEl6q.pgp
Description: PGP signature

Reply to: