merge_rpms
This script maintains a "live" Red Hat Linux distribution tree containing original RPMs merged with updated RPMS released to fix security and performance problems in the original distribution CDs. The resulting distribution tree is suitable for hosting NFS, FTP, or HTTP installs (although we just do HTTP these days). A machine installed or upgraded from this server doesn't require a separate "install updates" step; there's no "window of vulnerability" where patches haven't been installed.
All RPM and support files reside under a base directory (/usr/local/misc/ in our case). In this base directory resides a RedHat directory set up from RH's original distribution CDs, as described in their documentation for setting up a network installation server.
We use Lee McLouglin's mirror script to obtain RPM updates for current distributions. This is easy to set up in a crontab. Updates go in the updates directory, which is a subdirectory of the base directory.
[Update 2/9/2004: well, actually, the above link seems defunct. Too bad. Currently we use 'rsync' to mirror the Fedora Core updates.]
(Actually RedHat is a symlink to a directory named distribution (e.g., shrike) and updates is a symlink to a directory named distribution_updates (e.g., shrike_updates.) This makes it easier to maintain directories for other distributions and to switch the "default" distribution from one to another.)
[Another update 2/9/2004: in these days of modern times, the 'RedHat' directory is named 'Fedora']
The script's operation is pretty simple: given the "current" RPM distribution directory, it looks for "current" RPMs for which there exists a newer version in one or more "update" RPM directories. If that happens, the old RPM is unlinked, and replaced with a hard link to the update RPM. (So the distribution and update directories must reside on the same filesystem.)
Deciding on whether an RPM is "newer" than another is (however) surprisingly complex. The perl code is an effort to translate the C code for rpmvercmp() found in the rpm package. It's assumed everything is the same "epoch".
Once all the new hardlinks have been made, the script runs the genhdlist program from the anaconda-runtime package. This sets up the files needed for a network-based installation to proceed.
In practice, we only keep one "merged" RH distribution at a time, and it's the same distribution that runs on the machine on which the merged distribution resides. Why? I'm not confident that the genhdlist program released with a particular RH distribution produces files that are compatible with any other RH release besides its own. (I seem to recall having a problem with this in the past, anyway, and I'm not sure whether the situation has improved.) So we upgrade the distribution server to the new distribution before rolling it out elsewhere.
Last modified: February 9 2004 11:37 EST
Paul A. Sand, pas@unh.edu