Think this is an excellent idea! And for ease of administration it could well be combined with a minimal, standard kickstart configuration which brings the box to life. Then "packagelist" takes care of the individual configuration. This would save time since packagelist is useful after the installation whereas kc.cfg is not. /jon Robert G. Brown wrote: >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 > > >
