Linux system administration methodology or best practice

[Kenneth Holter]

Regarding migrating from sandbox to production: The way we've implemented
this on our Satellite server is like this:

   1. A (security) update is automatically downloaded from RHN to our
   Satellite server
   2. We decide wether this update is relevant to our systems. If yes, we
   clone it into our "cloned channel" (i.e. "private channel", see below) for
   systems in the test environment.
   3. If the update is approved we clone it to the cloned channel for qass
   systems.
   4. If approved, we clone it to the cloned channel for production systems

A cloned channel may contain anything you want it to, but in our case we
have simply cloned (i.e. copied) all the packages for RHEL 5 into another
channel. Let's call this "RHEL5-sandbox-channel". Since we manually have to
clone updates into this channel, we gain full control over its contents.
When updates are approved we clone it to "RHEL5-preprod", and so forth.

You really don't _need_ the Satellite server to do this, although we find it
very useful for this sort of things.



On 8/27/09, Shaughnessy, Kevin <kshaughnessy at carrols.com> wrote:

> I am also looking for hands-on advice for Red Hat administration,
> specifically regarding updates:
> -  I'd like a sandbox system to apply them, and test them.  Do I have
> to buy the same level of support for this "trash able" system? (I've
> already ruled out Fedora and CentOS, as I need to maintain compatibility
> with EMC PowerPath and Oracle.)
> -  By the time I've evaluated a set of updates, there are new ones, and
> yum always pulls the newest.  How do I migrate my 'approved' set from
> sandbox to development to production?
> -  How often do you apply updates to your production servers?  Security
> updates?
>
> Thanks,
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subjectunsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>