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).