How RPM handles configuration files, both technically and socially

March 14, 2016

In comments on my entry on Ubuntu packages playing 'hide the configuration file', James asked how RPM handles user editable configuration files (and then guaq gave a good answer). This is an important enough thing to talk about that I'm going to write an entry about it, because RPM's approach is both technical and social.

On the technical side, the first thing is that if the file hasn't changed between the old package and the new package update, RPM knows this and doesn't need to do anything; it doesn't touch the installed file and doesn't bother putting the stock version anywhere. If the configuration file has changed between the old and the new package and you've also edited the configuration file, most of the time the package will write out the new configuration file as <file>.rpmnew (for exact details of what happens when, see Jon Warbrick's writeup; while it's from some time ago, I don't believe RPM's behavior has changed since).

If this isn't enough, RPM packages can also do arbitrary things on package upgrades in their postinstall scripts. I believe that this has occasionally been used to do things like edit installed configuration files to modify or comment out configuration directives that have unavoidably changed or disappeared between software versions. However, this is where we shade into the social side of things.

Because RPM packages can't really try to do sophisticated things with configuration files, they have a strong social pressure to not need them. As a packager, part of your job is to make sure that the package's configuration files work right even within these restrictions. Generally you must keep existing configuration files working correctly even over package updates; resorting to pushing installed configuration files aside as .rpmsave files is strongly discouraged (as far as I know; it's certainly uncommon). This requires more up front work, is harder, and inevitably requires some tradeoffs (where people with edited configuration files don't magically get the benefit of new configuration options), but in my opinion it produces better long term benefits for sysadmins.

(It also encourages schemes to split configuration files up in various ways, because then it's more likely that most of the split configuration files will be unedited. RPM based systems are not alone in this, of course, and sometimes they don't do it as well as other systems.)

As a result, while you can do crazy things in RPM postinstall scripts, it's effectively discouraged. I would be surprised if Fedora packaging review was very receptive to mangling configuration files in postinstall scripts, for example (although it's not covered explicitly in the Fedora packaging guidelines). And of course the technical restriction that you can't ask the user any questions in your postinstall script limits the amount of things it's sensible to even try to have an ultra-smart script do.

This also affects what sort of default configuration it's sensible to set up in your package's stock files. Generally it's going to be better to create something minimal but stable instead of a complicated setup with lots of options that has to be managed by hand. Sure, many sysadmins will have to change your minimal setup, but on the other hand your package itself hopefully won't have to change and revise the setup from version to version. This keeps all of the changes, customizations, and updates in the hands of sysadmins, instead of making some of them your responsibility.

RPM's technical approach could not work without the social approach (although of course its technical limitations combined with sane people create the social approach). As a result, any RPM based system is going to have a terrible time with a program that needs configuration file customization and also changes its configuration files around in incompatible ways (either as for what's allowed in them or as to how they're organized). Fortunately there are not many programs like this, because they're unpopular with sysadmins even without RPM packaging issues.


Comments on this page:

I think the best solution to that issue (ie, how to handle configuration file changes between different package versions) is the use of "config.d" directories containing configuration file "fragments" which get included/catted into the main configuration file, as exemplified by /etc/yum.repos.d and /etc/httpd/conf.d.

By Ewen McNeill at 2016-03-14 05:18:31:

FWIW, dpkg will also create dpkg-old, dpkg-new, dpkg-dist files for most packages on config upgrades, depending on whether the config file was changed and wither you choose to replace the existing config. Off hand I'm not certain if those conffiles are easily extracted from the .deb with dpkg extract, but I'd guess so; generating the config in postinit does not seem like the most common pattern on Debian, but possibly some packages which are entirely debconf answer driven might do that (in which case you want to know the default answers to get debconf questions).

Also FWIW, Debian were (one of?) the first to start using .d directories to handle fragments of config files being added/replaced separately. Sometimes with application extensions to understand it, and sometimes with a config pre-compiler. Most of these work fairly well. (The packaging of AIDE being one of the weird exceptions which has been kludgy for years.)

I suspect that RPM and .deb package formats have learnt a lot from each other over the years. And that many of the remaining differences are only in specific packages. It possibly doesn't help that Debian has had several conventions for handling mixing site config and distribution config over the years... Some of which are easier to deal with than others. (.d directories seem to be one of the better ones, especially if there's a good convention for local override that avoids changing the packaged shipped files.). Possibly having just one convention makes life easier, especially if there is a social convention to use it conservatively.

Ewen

Written on 14 March 2016.
« I've started using the Firefox addon Self-Destructing Cookies for some stuff
An additional small detail of how writes work on ZFS raidzN pools »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Mar 14 02:02:39 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.