I'm writing an article on yum (part of which will be absorbed into the
draft HOWTO and will form the long awaited section on yum's actual
commands:-). This is marvelously stimulating to the imagination.
I can't remember if precisely this feature has been requested already --
we've certainly been working all around it with discussions of using yum
as a primary/restartable installation tool.
If I get the package/group extraction agent written (that converts
installed lists into an efficient Group+package compression that fully
describes the installed state of a system, this compression can serve as
a "system fingerprint" or "system configuration description" for the
system in question, fully compatible as a design goal with its kickstart
description.
In that case, if the description can be directly generated by yum (and
yes, I just bought a book on python and learned the basic elements of
the language yesterday so I can write the agent directly in with the yum
package instead of in perl and separately. Sigh.) then it can become
part of the following command sequence:
yum configuration > /etc/packagelist
(generates the package list)
yum configurate /etc/packagelist
(or even just)
yum configurate
The configurate command could act like cruise control on a car --
>>ADD<< any packages missing from packagelist and update the rest as
usual and >>REMOVE<< any packages that are intalled that aren't in the
list (or associated dependencies). This could be used to strictly
regulate "drift" from a kickstart image in a network environment; in
fact, if run against packagelist in a directory exported from a
configuration server or kept on a repository and indexed by e.g.
hostname, it could be used to trivially lock an entire network of
systems into a single package image. Want to add a package to all
hosts? Add it to their packagelist (symlinked to hostname on a toplevel
yum repository or NFS exported to the host) and wait overnight.
In fact, it might be possible to add some primary checking to the
configurate command that would let it be run in a cron hourly, instead
of nightly, to permit an even more timely distribution of a new package.
Waiting overnight can be a hassle or a security risk; waiting a time
that is modulus an hour is a lot better for some things.
I think that there will be plenty of sites that want to maintain this
kind of complete to-the-package "class" control over system images. Yum
currently permits this only indirectly -- sysadmins have to just not
install things that make a system "different" from e.g. its primary
kickstart description without also changing that kickstart description
as well, and maybe installing it on all other hosts in its class.
Anyway, just an idea for future reference.
rgb
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
