My company uses the RedHat Satellite server line to achieve this
functionality. Obviously this tool comes at cost, maybe you could leverage
the SpaceWalk app to provide similar capabilities.  We essentially freeze
the latest RHEL x.y version to three different software channels. The
channels we create consist of AppX-Dev, AppX-QA and AppX-Prod.  These frozen
channels are updated in a dev, qa and prod order to support ample testing in
each environment.  Any new updates to the core RHEL x.y channel have no
impact to our frozen software channels.



On Wed, Sep 21, 2011 at 3:58 PM, Aleksey Tsalolikhin <
atsaloli.t...@gmail.com> wrote:

> Situation:  public Linux package repositories (for example CentOS) are
> constantly getting updated by the distro project (e.g. the CentOS
> developers).  New versions are added, old versions removed.
>
> How do you "freeze" a set of packages so that when you run "yum
> update" on a Prod server it'll get the same package set as your Test
> server did 3 weeks ago?
>
> 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.  Now the source repo has changed (new packages added, old
> removed).
>
> How do you manage that?
>
> I talked to a colleague who mirrors Ubuntu repo, and he rsyncs off the
> local mirror nightly, taking a snapshot of all the packages; and when
> we wants to "go back in time" 3 weeks, he just points his end nodes at
> the "3 weeks ago" copy.  He's got this integrated into his CM setup
> (not CFEngine)  so he can just say "I want these servers up to date on
> patches, and I want them to use repository of date X".
>
> Does anybody have another solution for this?
>
> (And another challenge is that the Linux distro project repos
> sometimes remove old packages, so going back in time 1 year can be
> impossible unless you maintain a local mirror and cache.)
>
> It'd be cumbersome to keep track of individual package versions, so I
> like his method of keeping track of the entire repo by date.
>
> Does anybody have any other clever solutions for this, or CFEngine
> policies or experience to share?
>
> Yours,
> -at
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@cfengine.org
> https://cfengine.org/mailman/listinfo/help-cfengine
>
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to