Chris's Wiki :: blog/linux/UbuntuPackageFileAbsence

Why it's irritating when Ubuntu packages don't include their configuration files

March 11, 2016

I'll start with my tweets:

This is my angry face when Ubuntu openssh-server generates a fixed /etc/ssh/sshd_config on the fly in postinst vs making it a config file.
Ubuntu dovecot also does the 'generate static configuration files at install time' thing and now I want to set it on fire.

(Twitter has become my venue of choice for short rants.)

Both of these packages have the same bad idea, although their mechanisms differ somewhat. Specifically, the installed and running software has some configuration files (here /etc/ssh/sshd_config and /etc/dovecot/conf.d/*), but these files are not actually packaged in the .debs; instead they are created at install time when the package is installed from scratch.

(The behavior may be there in the Debian versions as well, but I don't run Debian so I can't easily check.)

Years ago I wrote about wishing to be able to retrieve the stock version of some package file. At the time I gave a recipe for doing this by hand on a Debian based system; you apt-get download the .deb, use dpkg -x to unpack it in a temporary directory, and fish the file out. Naturally this only works if the .deb actually packages the file. If it does not, you have two options. First, you can find, read, and probably simulate by hand the process the .postinst script uses to create the file (the postinst script itself is likely in /var/lib/dpkg/info). Second, you have to install an uncustomized version of the package somehow, either on a test machine or by purging and then reinstalling the package (which is likely to be very disruptive if you have any important local customizations).

This is what I call 'not helpful'. There are all sorts of reasons to want to retrieve the original version of a configuration file that you've altered (or merely may have altered). Even when this is possible, how to do it is package specific, which means that you need package specific knowledge or research. Ubuntu packaging should do better here.

(I don't expect things to ever change, though. I rather expect that this is inherited from Debian and Debian has some intricate reason of their own for doing it this way (and for different packages doing it differently). Debian sometimes makes me angry with their apparent love of robot logic, technical intricacies, and apparent inability to ever do something in a single unified way.)

Comments on this page:

By guaq at 2016-03-12 10:25:31:

I see two possible reasons for not shipping configuration files as files within the package.

First one (one I've had myself in RPM packaging) is related to shipping an executable that can be used to reset the configuration to factory state. I.e. the configuration is recreated/reset to factory state by running a command.

The other reason could be that they (Ubuntu and/or Debian) customize the configuration at installation time depending on the installable system, which basically means there can be no file.

My approach on the first scenario actually did ship the configuration file, but placed it under /usr/... and then copied it under /etc within postinstall. This was useful because I shipped a configuration file for a system daemon, which itself had a default configuration file. I couldn't just put it in a file at the same path because the packages would have conflicted. The package in question is a proprietary system's RPM package, not a Linux distro builtin so I don't think my sin was that serious...

All in all, there are reasons.

By James (trs80) at 2016-03-12 23:43:16:

Part of the reason is to avoid your UbuntuUpdateProcessDislike, in that if it was shipped as part of the package it'd be a conffile, and so prompt you during upgrades if it has changed (either by you or the package maintainer). Config file handling is a hard problem, and Debian's made some choices that have played out over the years. How does RPM handle user-editable configuration files provided by packages?

By guaq at 2016-03-13 06:30:14:

RPM has two possible policies or mechanisms for handling config files.

The default one is to check if the file has changed and replace it if it hasn't. If the file has changed, place a new file by the same name as the config file in question, appending '.rpmnew' to the end of the name.

The alternative policy is to replace the configuration file regardless of whether it was modified by the user. If the file was modified, back up the modified version in a similar way as in the default policy, but with '.rpmsave' suffix.

This functionality is built into RPM and the policy for each file is specified declaratively. Naturally, this only provides you two basic policies, but in the context of RPM, they make sense. RPM specifically prohibits any kind of user input during package operations (any and all, unlike in Debian) so one has to do that after the packages have been installed. For our proprietary packages, we basically do configuration after package installation has been done, not run within RPM installation at itself.

By sixty4k at 2016-03-22 10:51:02:

Redhat also dump example and upstream base config files and READMEs into /usr/share/packagename (don't have faith that I've remembered that path correctly), so that you have a template config should you need or want.

Written on 11 March 2016.

«	I need to use `getopts` sooner (and more often) in Bourne shell scripts

I've started using the Firefox addon Self-Destructing Cookies for some stuff