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.
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
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
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
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
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
Since our one started as a copy of that, we hadn't set a
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
So: to completely use an alternate
yum configuration file, you
need to set an explicit
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.