Versioned or even host specific repositories are not that hard (so to
speak).
You need 3 or 4 or 5 things.
1) A big fat ugly collect everything under the sun repo...the BFR for
short.
2) Some modicum of control over the machines to be updated.. say type1,
type2, type3
3) A group of test machines that are representative of type[1-3]
4) Some scripting and database skills.
5) Lots of political clout.
So pick your favorite method (rsync, curl, wget, carrier pigeon) for
populating the BFR and let er rip.
As part of defining your types, create a complete list of the names of
the rpms (including the versions) that is installed or that is ok to
install for this type. Place this list under version
control (cvs, subversion or maybe git...). Create a script to read the
list, and create a link farm pointing into the BFR. Run createrepo on
this link farm and give it a meaningful name (type1-versiony maybe).
As part of the install process create a record (database, ldap, flat
file, stone hieroglyphics) containing the hostname, the type and the
version of the rpm list (actually the repo version).
Wait a few days for new stuff to trickle or gush into the BFR and for
your customers to find out that their stuff is out of date, or included
in a CSIRT, or that version latest is absolutely required to be able
to implement company saving project z on time and bombard your
manage..never mind.
Take one of your test machines, and build the type(s) that could be
effected at their original revision level. Create a new repo list with
the new version of the rpms. Test with all of your automated test
harness (covered elsewhere :-) ). Pronounce it good (preferrably after
a multiple of 6 time periods) and commit it to your version control
system and create a record saying that typex is now at version y.
Perform the requisite sacrifices and rituals to get the change controls in
place for some, all or one of the typex machines. While waiting for the
change control approval, repeat the test and creation phase at least
twice, or as often as time allows. (Having something to do will keep
you out of trouble.)
Now use your remote management tools (cfengine, Tivoli, ssh, whatever)
to invoke yum with something like
yum -c http://updateserver.lan/yum.php?host=fred&type=type1 -y update
Oh I forgot to mention that you need to create a php,perl,cgi script to
look up the host name and or the type and return an appropriate
yum.conf. This script can do many interesting things, like forcing all
typex's to be at rev k, or only hosts that match regex j and type d,
or even allowing certain hosts to have direct access to the entire BFR,
etc, etc, etc....
there, that didn't hurt much.....
Of course you can go as deep as you want here. You could probably tie
the change control system together with the management tools and the
testing tools and a Kerberos ticket server if you really wanted to
control stuff. And you could wrap the yum invocation with a check of
what is installed against what is supposed to be installed, backup
config files, etc, etc, etc. But I digress.
------------------------------------------------------------------------
Jim Wildman, CISSP, RHCE jim@xxxxxxxxxxxxx http://www.rossberry.com
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine
