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:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/