On Thu, 22 Feb 2007, Les Mikesell wrote:
Steve Friedman wrote:
On Thu, 22 Feb 2007, Les Mikesell wrote:
Bruno Wolff III wrote:
On Wed, Feb 21, 2007 at 17:19:34 -0600,
Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
And, you could update a
test machine and after testing, reliably update other boxes to the same
versions that you tested even if new updates had gone in the repository.
That's trivial to compute, so it doesn't need to be part of the
application. What I really want are reliable, repeatable updates once I've
done one and tested on a non-critical box, and I'd also like it to play
nice with a caching web proxy.
The workaround for this feature is trivial. We set up our own local
repository (initially because updating a new config over the internet was
so slow compared with ethernet speeds, but now we do it with installs and
have eliminated swapping CDs). Just push approved updates (instead of
blindly rsync'ing the part of the tree that interests you), and you're
done.
That's always sounded fairly horrible to me as a workaround for something
that should be really simple. My servers are widely distributed and not all
of the same distribution/version so having to build the infrastructure of a
local repository for each with hand-picked rpms doesn't sound like fun. I'd
probably try to automate something that made a list of installed rpm versions
and fed that to another machine's yum as an easier approach. Most of the
servers are Centos, though and I've had pretty good luck with just trusting
the repositories. The 3.x version even does something sensible when you use a
proxy cache so I haven't put much effort into a workaround.
Your initial message said that you wanted to test the updates first. So,
although hand-picking isn't necessary, there will be some required admin
interaction to update the test machine, test it, then approve the updates.
The first and last steps can be one-liners.
Steve Friedman
