CentOS - Sep 2011 - Installing yesterday's CentOS (or how to install the patch/package set from 3 weeks ago)

Hello,

Let's say your operating policy is "no patch updates without testing
first in the test environment".   Let's say it takes you 3 weeks to
test.  Over the course of the 3 weeks, the repo changes (new
packages added, old removed).

Is there a way to "freeze" a set of packages so that when I
run "yum update" on a Prod server it'll get the same package
and patch set as the Test server did 3 weeks ago?

It's been suggested to maintain a local mirror, and take rsync
snapshots of it daily, so then you can point the end node to a
particular repository.

What other solutions are there?

Best,
-at

I think a local mirror is really your best option.  Or possibly two repos.
One for testing, which you sync when you want to test updates and point all
test systems at it.  Then a production repo for production systems that
pulls from the frozen test repo.  One addition to your idea would be to use
git.  That way all you have to do is a 'git push' when you want to
update
your production repo.  Could then use other features in git for tracking
changes, possible reverts and such.

- Trey
On Sep 21, 2011 10:14 PM, "Aleksey Tsalolikhin" <atsaloli.tech at
gmail.com>
wrote:
> Hello,
>
> Let's say your operating policy is "no patch updates without
testing
> first in the test environment". Let's say it takes you 3 weeks to
> test. Over the course of the 3 weeks, the repo changes (new
> packages added, old removed).
>
> Is there a way to "freeze" a set of packages so that when I
> run "yum update" on a Prod server it'll get the same package
> and patch set as the Test server did 3 weeks ago?
>
> It's been suggested to maintain a local mirror, and take rsync
> snapshots of it daily, so then you can point the end node to a
> particular repository.
>
> What other solutions are there?
>
> Best,
> -at
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110922/4516c341/attachment-0002.html>

From: Aleksey Tsalolikhin <atsaloli.tech at gmail.com>
> Let's say your operating policy is "no patch updates without
testing
> first in the test environment".?  Let's say it takes you 3 weeks
to
> test.? Over the course of the 3 weeks, the repo changes (new
> packages added, old removed).
> Is there a way to "freeze" a set of packages so that when I
> run "yum update" on a Prod server it'll get the same package
> and patch set as the Test server did 3 weeks ago?
> It's been suggested to maintain a local mirror, and take rsync
> snapshots of it daily, so then you can point the end node to a
> particular repository.
> What other solutions are there?
What about:
1. Update the test server and yumdownloader the updated packages somewhere.
2. Three weeks later, yum localinstall these packages on the prod server.

JD

On 09/21/2011 10:13 PM, Aleksey Tsalolikhin wrote:
> Hello,
> 
> Let's say your operating policy is "no patch updates without
testing
> first in the test environment".   Let's say it takes you 3 weeks
to
> test.  Over the course of the 3 weeks, the repo changes (new
> packages added, old removed).
> 
> Is there a way to "freeze" a set of packages so that when I
> run "yum update" on a Prod server it'll get the same package
> and patch set as the Test server did 3 weeks ago?
> 
> It's been suggested to maintain a local mirror, and take rsync
> snapshots of it daily, so then you can point the end node to a
> particular repository.
> 
> What other solutions are there?
There is no solution to do updates that are different than the mainline
tree, except to maintain your own repo.

You have to publish the tree of tested RPMS, then you need to make sure
that those packages all work together (run a repoclosure), then you run
createrepo and update from your repo (that only contains tested packages
which are verified by you).

You could do some kind of find command with time in it to populate your
test repo ... but I personally populate mine with RPMs after I test them.

Of course, this puts the burden of testing and maintaining that repo on
you ... but you are the only one who can decide how much testing is
enough and what needs to be tested before you move a new RPM (or set of
RPMS) into production.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110923/bd52fdc4/attachment-0002.sig>