On Wed, 19 Mar 2008, Christopher Hunter wrote:
Hi,
We are trying to put together intelligent policy for yum software
updates for workstations and servers. We would appreciate anyone
willing to share how the control yum updates for servers & workstations.
We started looking at the yum plugins; there are lots of options. Not
sure how well different plugins work together.
Does anyone use the yum-downloadonly plugin ? How do you install the yum
updates after they have been downloaded ?
If we use the yum-updateonboot plugin, that could mean long server reboot
times, if there are lots of updates (I remember this happening on my fedora
laptop).
If we use both the yum-downloadonly and yum-updateonboot plugins, would
that mean faster reboots since most of the updates would already be
saved local to the machine ?
What we are doing (on workstations mostly 'cos our main servers havn't
been updated to a setup where we use yum - yet), is to add an extra
(local) yum plugin to implement our local 'policy'.
This plugin reads a config file of updates which need special work. That
may be to delay installing them until some particular date (e.g. a
dedicated or vulnerable period), and/or marking at a reboot will be needed
afterwards (e.g. for kernel updates).
Any updates which don't meet it's criteria for applying now are hidden
from the rest of yum so simply don't get applied. If we apply an update
which requires a reboot it adds a line to a file saying so.
In the script which calls yum we check that file and if a reboot is needed
we schedule one to happen.
This allows us to perform most updates from a nightly cron job as long as
we remember to update the plugin config file to mark any needing to be
delayed or which will need a reboot (*).
Because the updates are performed before reboots those still are pretty
fast, though actually we also perform an update check during the boot to
catch machies which have been powered off etc.
We have been doing this for a few months now and it seems to work well
enough. Our existing servers running sl3/sl4 don't use yum but a bunch of
horrid local scripts for updates to try to achieve much the same effect.
(*) since we can't guarentee that we will have time to add something to
the config between it being added to the sl updates repo and the next
nightly cron we currently have to disable the normal update repos and have
to add each update into a local repo at the same time that we check if it
needs adding to the config.
Sadly this means that without one of us doing this new updates won't get
applied. Of course at the moment we are having to add extra patches to
the kernels and ffox/tbird (TUV's fault not SL's), so I currently seem to
be spending quite a lot of time keeping track of updates... Any
suggestions to avoid the extra steps might make me very happy indeed...
--
Jon Peatfield, Computer Officer, DAMTP, University of Cambridge
Mail: [EMAIL PROTECTED] Web: http://www.damtp.cam.ac.uk/
