Conffiles and configuration management systems

[Soren Hansen]

-= Note: There is a session devoted to this at UDS. The primary purpose
-= of this e-mail is to draw attention to this session so that the right
-= people will attend it. There's a link to the blueprint near the
-= bottom, so if you're going to UDS and want in on this discussion,
-= please subscribe to the blueprint so that scheduling gnomes can do
-= their thing.

The problem at hand is the frustrating combination of conffiles and
configuration management systems. Since Karmic, Puppet has been in main,
so I think the time is quite ripe for us to grab this problem by its
roots and deal with it.

A short recap for the uninitiated:

dpkg has a concept of "conffiles". This is not to be confused with the
general term "config file". "conffiles" are a type of files that are
handled specially by dpkg: dpkg installs some version of a package
containing a conffile. Upon upgrading this package, dpkg checks if the
new version of the package has changed the particular conffile. If it
hasn't, nothing further happens. If it has indeed been changed in the
new package version, it checks if the user has changed it as well. If
so, you get the familiar dpkg prompt about whether you want to keep this
or that version or drop to a shell and fiddle with things or whatnot. If
you haven't touched it, dpkg just overwrites the old version with the
new one.

Debian policy basically says that no package is allowed to alter
conffiles programmatically (see section 10.7 for the gory details). This
is to prevent users from being asked about changes to conffiles that
they did not make (because some program did it on their behalf). There
may be other sound reasons for this bit of policy, but to my knowledge,
this is the core of it. Feel free to correct me.

dpkg's conffile handling is convenient when you're actually manually
changing your configuration files. When the package changes its
defaults, you may want to follow suit or maybe not. It's up to you and
dpkg lets you make that decision interactively.

Where this falls short is when you want to use a configuration
management tool like Puppet. Puppet is a very flexible tool. You can use
it to configure pretty much anything. This means that you can use it to
change conffiles, and in turn this means that your upgrade experience is
going to be very annoying: It will be riddled with questions about
conffiles that you allegedly changed. Except, of course, you didn't.
Puppet did it for you. Not only that, it often does it based on
declarations of various sorts rather than just a straight copy of a file
from a central store, so the exact changes may look foreign, even to the
person who made the change in Puppet.

Lots of people want to use configuration management tools, and I find it
unlikely that they by chance never need to change anything that happens
to be in a conffile. A few packages have various mechanics for letting
other people override their configuration. dhcpd, for instance, knows to
read an alternate configuration file if it exists, but in general this
is not the case. Also, it's perfectly reasonable for a user to want to
use configuration management tools to touch config files that happen to
be conffiles and not jump through hoops like using an alternate config
file.

So, our mission, should we choose to accept it, is to let people use
Puppet (or similar tools) to fiddle with conffiles while still having
smooth upgrades.

Enter the strawman:

Add a capability to dpkg to let tools like puppet take over this conffile
merging process. Or, the poor man's alternative: add a capability to
dpkg to ignore specific conffiles.

Either way, this presents a way for Puppet to tell dpkg that it is
managing said conffile and that dpkg should just pretend it isn't there.
The responsibility of making sure this works smoothly lies with the
Puppet master (the person, not the tool).

There's a blueprint scheduled for UDS to talk about this:

   https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-conffiles-and-puppet

What I'd like to get out of this session is feedback on the general
idea, and if it turns out well, a bunch of notes about how this (or
whatever we come up with) could be implemented, after which we can take
it up on the Debian and dpkg-devel mailing lists.

-- 
Soren Hansen
Ubuntu Developer
http://www.ubuntu.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100504/eb30925d/attachment.pgp