On Wednesday, May 30, 2012 22:53:01, Eric Myers wrote:
> On Wed, 30 May 2012, Chris Knadle wrote:
> > The main thing I have not liked about Red Hat / Fedora are issues
> > concerning how RPMs deal with upgraing config files that are part of
> > packages. Traditionally if there's a newer config file, the new file is
> > silently dropped next to the old one and the service is restarted using
> > the /old/ config file, IIRC.
>
> Yes, and I think that's the right thing to do. If you have edited that
> file then you don't want your changes wiped out. And you don't
> necessarily want to have to go through all the changes right now during
> the install. So the new file is put in place with .rpmnew added on, and
> you then have to go through and resolve the differences manually.
The problem I commonly run into is restarting a /new/ version of a service
using an /outdated/ config file. A specific instance I've had is a mail
daemon (or sub-parts of it like SpamAssassin, ClamAV, etc) being restarted
using the old config file that misses new critical options, such that now all
new mail gets rejected. So for important services such as email, I'd much
rather have the service /down/ than for it to be up and misconfigured. [It
depends on the specific service and what kind of misconfiguration it is.]
I'd rather have a prompt to to be told about this and to have an opportunity
to examine the configuration file difference. [Note: opportunity, not
obligation.] The DEB package management system defaults to a similar behavior
as RPM upgrades if the upgrade is automated and there is no terminal to talk
to, or if the 'debconf' package has been configured not to prompt for the
severity level of the package upgrade in question. [This difference in
behavior is something I believe the package maintainer has to take into
account, and thus one of the many reasons why Debian package creation can more
complicated than for RPMs.]
Some Debian packages (not many) can use the 'ucf' package [Update
Configuration File] to allow the user to have the option to a three-way merge
on the config file differences during the upgrade. When this has come up I
usually have not used the option as it's confusing, and it seems increasingly
rare for packages to include this. [Just checked: out of the 3160 packages I
have installed on my laptop right now, 15 depend on the ucf package.]
> > Occasionally there are major changes to the program the config file is
> > for which mandates changes to the config to get the program to work, so
> > restarting the service with the old config fails or the service starts
> > and ends up being misconfigured.
>
> Yes, but it would be equally bad to just plop in a new config file and
> disregard your previous customizations.
Usually nobody wants this, but there are now some interesting exceptions of
where you get it and don't even know it.
There's been a lot of discussion about configs recently on [debian-devel].
The udev package currently uses default config files in /lib/udev/rules.d
which can be /overridden/ by config files in /etc/udev and /etc/udev/rules.d.
Thus /etc isn't the only place to be concerned about for config files these
days, yet /etc is typically the only config files to ask the /user/ about
during the upgrade. [Nor is /lib/<package>/ the only other place to look for
configs now, either.] So this issue of config file handling has become a bit
more complicated.
My understanding is that this same "location-split" configuration is now
commonplace across many distributions, including Fedora.
> > Distributions based on .deb packages /ask/ concerning what to do with
> > major config file changes /before/ restarting the service, and that
> > gives an admin an opportunity to break out to a shell to merge required
> > changes.
>
> It would be nice if rpm could flag a config file as major/minor changes,
> but you'd still need to merge the newer version with your old
> configuration. And major format changes are less frequent than upgrading
> a package to a version that still knows the old format.
All of that depends on how heavy development has been on the service in
question, and how long it has been since the last upgrade. For Debian,
"stable" gets major upgrades once every two years, "testing" gets upgrades
about once a week (except during the "freeze" every two years prior to the
next "stable" release), and "unstable" gets upgrades about every 4 hours.
For a service that's under active development, the chance for configuration
file changes are more than fair after a period of two years.
But regardless of how often it happens, the issue of config file changes being
necessary is simply an eventuality. [Put it this way -- there has yet to be a
major "dist-upgrade" every two years in which I have not had to deal with it.]
So I prefer to use some kind of system that helps me in dealing with it when
it happens.
> And each config file has a different format, so you really have to
> know what you are doing for each to get it right. (Often you just move
> the .rpmnew file into place over the old one, maybe after editing a couple
> of lines, but not always.)
>
> It would also be nice to have a tool to help you resolve all the .rpmnew
> changes, but it's not clear what it would do. You need to find
> them, with something like:
>
> find /etc -name "*.rpmnew" -print
Although I said the config file gets dropped "silently", in fairness that's
not /quite/ accurate -- I believe the text output of the upgrade mentions an
.rpmnew file been created. However this information is not terribly useful,
because the config file for most services is going to differ from the default,
so the fact that an .rpmnew file exists doesn't inform the user that the new
default config file has /changed/ from what it had been, or that there are
/new/ differences. The result is that you can end up doing a diff and finding
out you didn't need to, you may thus be lulled into the habit of not bothering
to check, and when you do check you have to be able to figure out on your own
if any of the differences you see are new compared to the differences that
were there during the last upgrade -- which you've most likely forgotten.
This is likely where Git might be able to help, but to do it might require
committing the .rpmnew files along with the main configs, which is a bit odd.
> Then you may want to diff the .rpmnew version with the existing file.
> If the differences are small it's easy to merge them. If not, you have to
> spend some time figuring it out. Is there something for .deb packages
> that makes this part easier?
For the actual merge, mostly no (except for packages using ucf). However dpkg
is very good of letting you know when you actually need to do the work.
If the new default config file differs from the default config file from the
/previous/ version of the package, /then/ you get a prompt. In other words,
dpkg is smarter than simply noting that the default config file that comes
with the package is different than your local changes. You may have seen this
but I'll mention it anyway -- when the prompt comes up, it looks like this:
Configuration file `/etc/bash.bashrc'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] ?
The "D" option outputs a 'diff -u' between the "old modified" and "new
default" config files, then comes back to this prompt. Answering "Y" renames
the old config file and puts the new one in place. Answering "N" drops a
.dpkg-new config file next to the old one. Using the "Z" option starts a new
shell to let you work, then after exiting the shell brings you back to this
prompt.
Usually I use "D" to look at the differences, then most often I can choose "Y"
or "N" and be done with it. In cases where I need to make changes manually I
use two terminal windows, one in which I do a 'colordiff -u' on the configs,
and in the 2nd window I make changes to the "old" config file. Then usually I
commit the changes into a local Git repository of configs. 'git diff' can
sometimes also help.
-- Chris
--
Chris Knadle
[email protected]
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) Vassar College
Jun 6 - Why the Web Needs HTML5
Jul 11 - Mad Science Fair - Open Hardware Expo
Aug 1 - Pimp My Network
