Wandering Thoughts archives

Another aphorism of system administration

If a piece of information doesn't have to be correct for the system to work, sooner or later it won't be.

(Yanked out of my spam by ASN summary, where a version of it got a mention in passing.)

It's easy to see this aphorism in action. For example, if your host/domain name to IP address mapping information is wrong you notice right away. But nothing common breaks if the information to map from an IP address to a hostname is missing, and lo, it is missing all over the place.

And of course comments in source code are the classical case. Nothing breaks if the comment doesn't describe what the code is actually doing, so often the comment doesn't.

Corollary:

Attempting to validate a non-essential piece of information will inevitably turn up lots of perfectly valid systems that have the information wrong.

This most often comes up in antispam efforts, where people desperately starts attempting to insist on correct information in previously non-essential bits and discover that lots of people have it wrong or broken, often people that they still wanted to talk to. For example, for years almost no one cared what a SMTP HELO or EHLO greeting said, so real mail servers have all sorts of broken greetings.

There are two fundamental reasons for this:

• People are lazy; they don't like doing things that seem to just be make-work. (This is one big reason why security is a pain, too.)
• It's hard to notice incorrect information that nothing depends on.

Corollary: if you want to insure that some piece of information is correct, you must make something important check it and depend on it. The more important the better, because otherwise people may just ignore the fact that your checker is either screaming or broken.

Completely using an alternate yum configuration

As part of automatic installs of Fedora Core, our customization step installs of the current Red Hat updates from a local mirror. We use yum for this, because it both handles dependencies and uses compact metadata files instead of having to read all of the update and base OS RPMs themselves. (We have 100 megabit networks, but it still adds up and slows down installs.)

We do this by feeding yum a custom configuration file; basically we take the standard /etc/yum.conf file and add some bits to point to our on-disk repositories. (In turn, this means I get to explore the many charms and wonders of building yum metadata. Which deserves an entry itself.)

This mostly works, but with Fedora Core 4 this step started bitching about 'ignoring duplicate entry for <repository type>'. Since it worked, I ignored it. As part of diagnosing the install failure yesterday, this escalated to a fatal problem: yum died with that ever-helpful message:

Cannot find a valid baseurl for repo: extras

This was mysterious, because our yum configuration doesn't have an 'extras' repository, only 'base' (base Fedora Core 4 RPMs) and 'updates-released' (the updates themselves).

The cause is a new feature in yum, where it will look in a list of directories for files that describe additional repositories. (In Fedora Core 4, Red Hat sets up all of the repositories this way for reasons having to with how RPM operates.)

This new features, reposdir, does not have to be explicitly specified in your yum configuration file; yum uses a default directory search path. Fedora Core 4 uses both the feature and one of the default directories, so no reposdir entry is in /etc/yum.conf.

Since our one started as a copy of that, we hadn't set a reposdir either, so yum was seeing our explicitly specified repository locations and then also reading the normal system ones. This resulted in the duplicates of 'base' and 'updates-released' that yum had been warning about, and when the install-time nameservice was broken a complete inability to get information on the contents of 'extras', a fatal error.

So: to completely use an alternate yum configuration file, you need to set an explicit reposdir. Yum is happy with the directory not existing (assuming you specify the necessary repositories explicitly in your configuration file), but you have to override the default with something.