We maintain several usage hints, which we have compiled over time using
yum as an enabling technology in our systems administration
practice. The home yum
site is at the Duke LUG, and
its lead maintainer is seth vidal. The yum Bugzilla is
here. As these are
a mouthful to
remember and type (as when using lynx, w3m, or another
textish web browser to go find a download, we maintain a 'convenience'
shortcut URL at: http://www.owlriver.com/yum/
We have documented using yum as a
tool
to build a 'chroot'
filesystem instance, in which to build packages.
A 'chroot' instance is very useful for porting purposes, and indeed for
day-to-day maintenance work, as it permits having a pristine 'sandbox' in a
known state, clean of any unknown packages in the
build
environment.
Using yum as a build requirement dependency resolution and
installation tool
We have documented using yum as a
tool
to assist getting the build environment complete, within a build 'chroot'
filesystem instance (and indeed to do non-root, chroot based building).
This code provided the basis of the cAos project build
engine as that project began work.
Using yum as a server side 'up2date' management analogue
We published a generalized yum.conf web based CGI provider, back
in February 2003, and released it to the community under the GPL. That
was described here.
Red Hat has not released under an open source license, the code, or a full
API for their 'up2date' tool. This is an approach to replicating some
of that functionality.
For the cAos project, and its
commercial adjunct CentOS (for each of which, we offer
commercial
support in our wings product family at:
http://www.owlriver.com/wings/),
we recently wrote a variant to handle
load balancing in a mixed constellation of HTTP and FTP mirrors. A GPL
subset stub is available as: yum-redirect.php here.
The approach of yum-redirect.php is somewhat sub-optimal, because
yum does not remotely update its pointer of the archive to use; that is,
it keeps re-querying the dispatcher. A change in yum as to archive redirect
detection would be needed to make this more userful in a heavy load
circumstance; there are. however, security concerns as to so-called
Man in the Middle (also called "MitM", or even Monkey in
the Middle after Dug Song's work with dsniff).
Alternately at the provisioning site, putting the central
redirector behind a load balancing tool would work, but all slave units
behind the load balancer would need to access the same dispatch decision
code results (which is currently a hardcoded set of variables in this
demonstration stub.)
The release code points (as of January 2004) to an adjunct 'yum ready'
archive for a cAos-1 pre-release variant. We offer support use of a
larger and more complex variant of this code,
with keying to our commercial support resources in production on our server
side. We gratefully acknowledge the comments and testing assistance of
Jacob Wilkins ('Bacon' on the cAos IRC at irc.freenode.net,
channel #caos).
