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@xxxxxxxxxxx> 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@xxxxxxxxxx?subjectunsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
