One problem with the files-in-directory approach to configuration

December 12, 2010

Over the past while, there's been a definite pattern in Linux software of moving from a single monolithic configuration file (or a control file) to a configuration that is created by scanning a directory and looking for eligible files. From a packaging system and system management perspective, there is a lot to recommend this approach; it makes it much easier for packages and sysadmins to add and remove elements to the configuration.

However there is a drawback to this approach as commonly implemented, which is handily illustrated by Ubuntu 10.04's new superintelligent scheme to automatically update /etc/motd. On 10.04, the motd is created by running scripts in /etc/update-motd.d; each script prints out some portion of the standard motd's contents, and the driver script collects them all together. With some glue, this lets Ubuntu give people various standardized up to the minute reports on things like how many package updates there are and if the system should be rebooted.

This sounds great, except that on our systems we don't want these notes about pending package updates and reboots needed ad so on to be there. Given that we run the systems and apply package updates when we want to, all they do is confuse and perhaps alarm users.

(Right now, we don't disable the entire thing because we do want the current kernel and Ubuntu version to be in the motd.)

The problem is that Ubuntu's magic motd system doesn't give us any way to turn these standard bits off short of deleting the files that create them. Deleting files is a bad approach to controlling things in any environment with a package management system; you run the risk that a deleted file will be restored the next time you upgrade the package, package verification will distract you by reporting the issue, you can no longer look at the file to see what it does (or did), and so on.

(In some package management systems, if the particular package marked a file that you deleted in just the right way, it won't get restored when you apply a package update. In practice this is useless to sysadmins, because it's not something that we can always count on.)

This is a general problem with pretty much all of these schemes. They're very well set up for packages that want to add and remove their own bits of a configuration (and they're a substantial improvement on how things used to be), but they are not at all well set up for sysadmins who want to manage the configuration of packages with confidence.

Sadly I can't think of a great solution to this problem, although there are a number of decent ones (such as the Debian Apache style separation of availability from activation, where module configuration files go in /etc/apache2/mods-available and are then symlinked into /etc/apache2/mods-enabled to actually turn them on).

Comments on this page:

From at 2010-12-12 04:29:57:

With rpm the proper way to disable a configuration file added by a package is to replace it with a file doing nothing (e.g., an empty file, or a script containing just #!/bin/sh, depending on how these files are used). This works only if those files are marked as %config(noreplace) — in this case rpm will just create an *.rpmnew file during package upgrade instead of replacing the existing modified file (but an unmodified file will still be replaced by the version from the new package).

And the original version of the file could be saved, e.g., with the .rpmorig suffix (for reference, and for use in merging after package upgrade).

-- Sergey Vlasov

From at 2010-12-12 08:50:43:

Can't you modify each file in the directory (ie comment everything out) just as you would modify a single file?

By cks at 2010-12-12 11:47:21:

As Sergey Vlasov noted in his comment, modifying the file only works if the package has been careful to note the file as a 'configuration' file so that your changes will be preserved instead of erased in various ways. And that depends on whether or not the packager thought that sysadmins would ever want to disable their whatever it is.

As it happens, the Ubuntu motd stuff provides a perfect illustration of this; not all of the files in /etc/update-motd.d are marked as configuration files.

From at 2010-12-12 22:12:31:

Change permissions? (i.e. make the file unexecutable or unreadable so it is never read)

Package managers do not alter your custom-set permissions.

— Samat Jain

By cks at 2010-12-13 11:25:17:

I don't think that I trust package mangers to never change permissions. I would be surprised if all package managers made that guarantee all the time, especially since it seems contrary to what they do with all of the other aspects of replacing a file with a new version.

From at 2010-12-29 05:16:24:

See dpkg-divert :)

By cks at 2011-01-03 12:22:43:

dpkg-divert looks like a great idea (especially now that this has spurred me into reading the manpage); thanks. I suspect that we'll put it to use in future versions of our Ubuntu setup.

Written on 12 December 2010.
« The danger of having system programmers around, illustrated
A program that I want to write: a 'sink' SMTP server »

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

Last modified: Sun Dec 12 01:50:31 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.