nova-common package tries to update /etc/nova/nova.conf

On 04/11/2011 05:45 PM, Ryan Lane wrote:
> Configuration file `/etc/nova/nova.conf'
> ==> 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 : background this process to examine the situation
> The default action is to keep your current version.
> *** nova.conf (Y/I/N/O/D/Z) [default=N] ?
>
> Since this is a configuration file, this should likely not occur. It
> makes it difficult to handle via puppet and other automated means.

Since this is a configuration file, the package *did not* overwrite your
existing configuration and asked for your attention to look at the
differences, etc.

Although I am not sure what the changes were in the default
configuration files, sometimes it is necessary to update config files to
include new and different environment variables, or new and different
accepted options, etc. While your old configuration file might work
fine with a newer version of the software, sometimes this is not the
case and the system administrator *needs* to review those changes and
take appropriate action.

If you are automating deployments, then you did see this in your staging
environment, right?

For a quickie (I've done this many times after seeing trivial config
prompts like this), echo "N\n" to your run to answer the question.

For how to never get prompted (at your own risk), take a look at the
nice article Raphael Hertzog wrote on the topic - it should give you
good understanding of what is happening and a couple ideas for making
the system do what you want:

http://raphaelhertzog.com/2010/09/21/debian-conffile-configuration-file-managed-by-dpkg/

dpkg did the right thing in your example - it did not hose your
configuration. My suggestion is that this bug be closed - it's the
system administrator's job to understand this dpkg behavior and act
accordingly.

--
Kind regards,
Michael

Puppet does not give you options on how to handle dpkg, as far as I know. This behavior is out of the ordinary for packages, btw. For instance, I've never seen this occur with Apache configuration. It is essentially *never* correct to overwrite a config file. You shouldn't even ask. It should be assumed the administrator has read the upgrade guide before upgrading, and will adjust their configuration file accordingly.

There is no situation in which the distro's default configuration file will ever be correct for my systems.

On 04/11/2011 06:25 PM, Ryan Lane wrote:
> Puppet does not give you options on how to handle dpkg, as far as I
> know. This behavior is out of the ordinary for packages, btw. For
> instance, I've never seen this occur with Apache configuration. It is
> essentially *never* correct to overwrite a config file. You shouldn't
> even ask. It should be assumed the administrator has read the upgrade
> guide before upgrading, and will adjust their configuration file
> accordingly.

Puppet gives you complete control over your systems - that's the point.
 You can run arbitrary commands and manage configuration files.

So what's in your /etc/apt/apt.conf.d/local configuration file? The
article I posted clearly gives you several methods to not see config
file prompts and to continue to use your custom ones.

Those config file prompts are absolutely common, expected, and very
helpful to the system admin humans that see them. In fact, I just got
two of them yesterday for dnsmasq and sudoers on upgrades of those
packages. They *have* to exist per packaging policy to facilitate both
fresh installs and upgrades - here's why:

The 'foo' package provides the following files, and there is a marked
config file:

/usr/bin/foo
/etc/foo.conf

On a fresh install, the system admin has to adjust foo.conf in order for
the software to function. There is zero prompting in this install.
Edit to your needs.

On an upgrade, the package does not overwrite the config and the system
admin gets asked what to do - keep old, use new, see diff, etc...

You, as the system administrator have full control over the system's
behavior of that prompting. Read the article...

> There is no situation in which the distro's default configuration file
> will ever be correct for my systems.

Then learn how to configure your systems to your own needs. This is
absolutely the proper behavior of the package doing precisely what
packaging policy states.

--
Kind regards,
Michael

Meh. It seems puppet does give an option to keep or replace. So it looks like this isn't an issue.

I still feel that it is poor behavior to give a prompt where giving anything other than the default ensures you have a broken system. The behavior I normally see is for packages to automatically write to .dpkg-dist files for configuration files unless the file has been modified.

You can mark this as invalid. I'll use the other methods mentioned to ensure this behavior on my systems.

2011/4/12 Ryan Lane <email address hidden>:
> Public bug reported:
>
> Setting up nova-common (2011.2~gamma2~bzr978-0ubuntu0ppa1~lucid1) ...
>
> Configuration file `/etc/nova/nova.conf'
>  ==> 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     : background this process to examine the situation
>  The default action is to keep your current version.
> *** nova.conf (Y/I/N/O/D/Z) [default=N] ?
>
> Since this is a configuration file, this should likely not occur. It
> makes it difficult to handle via puppet and other automated means.

This happens exactly *because* it's a configuration file.

Just make puppet override it?

2011/4/12 Ryan Lane <email address hidden>:
> Puppet does not give you options on how to handle dpkg, as far as I
> know. This behavior is out of the ordinary for packages, btw.

It most certainly is not. This is how Debian and derivatives handle
configuration files. If and only if a package contains a changed
version of a configuration file (compared to the most recently
installed version) *AND* the local configuration file does not match
what was in the previous version of the package, you will see this
prompt. If you believe that you are being prompted under different
circumstances, I'd be happy to help you debug that.

> For instance, I've never seen this occur with Apache configuration.

If you have changed e.g. /etc/apache2/ports.conf and a new apache
version comes along with an update to that file, you will see an
identical (apart from the file names, of course) prompt. It's standard
dpkg practice.

> It is essentially *never* correct to overwrite a config file.

Indeed. That's why it's prompting rather than just overwriting.

> You shouldn't even ask.

Yes, you should. That's the only way administrators will know that
e.g. defaults have changed or perhaps even that the syntax of the
configuration file has changed since the most recently installed
version.

Occasionally, security updates consist exclusively of a change to a
configuration file. Without this prompt, you'd never know, and you'd
remain vulnerable to the security issue in question.

> It should be assumed the administrator has read the upgrade
> guide before upgrading, and will adjust their configuration file
> accordingly.

The default should be "don't break anything". That (for better or
worse) requires asking a question. The config file you had may not
even be valid anymore.

> There is no situation in which the distro's default configuration file
> will ever be correct for my systems.

I honestly doubt that you have changed every single configuration file
shipped by your distro. Even if you did, you'd be the (very!) special
case.

--
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/