Red Hat Enterprise Linux 5.5 patching

[urgrue]

On 08/03/2011 17:29, Matty Sarro wrote:
> In my situation we needed to develop a baseline based off of the
> current errata and updates. From this point forward we have to use
> this as a baseline for all certification testing to ensure that the
> production servers are kept identical to our lab servers that we've
> done certification testing on.

I've been doing exactly this for a long time with (mostly) mrepo, which 
is the easiest (free) solution I know for hosting your own internal 
kickstart repo. It's then trivial to create "frozen" channels. What I do 
is have the standard OS media channels (like RPMS.os) and the standard 
red hat OS updates  (RPMS.updates). Then if you want to create a point 
in time "standard distribution" just hardlink the contents into a new 
channel such as RPMS.2011-03-11. Your servers can then all have their 
yum configured to use this channel only, guaranteeing they all remain 
identical.
http://www.brandonhutchinson.com/mrepo_configuration.html

> Our lab architecture cannot talk to the production, and vice versa due
> to security. I had manually downloaded all updates after running a yum
> update and copying the list of all downloaded packages. I then went to
> red hat's site, downloaded all of them manually. I copied them to

Sounds painful. Just set up one mrepo somewhere as the "master" and 
replicate that with any old tool like rsync.

> This was done on a secure network, so there was no way for me to get
> the key. Is there a simple way to get it? Is it its own RPM?

It's just a text file you import to rpm. It's on the install media for 
example. Personally I just include the gpg keys as part of our standard 
build.
Or, just disable gpg checks if you're ok with that.

> We do have RHN satellites in both lab and prod, but those networks are
> inaccessible from our staging/build area, again due to to security

So you can't have your build servers in the build network? Sounds just 
like the place I work at :)
Either use mrepo to host a copy in the build area or get creative with 
ssh tunnels...

I love yum, I think it's the best built-in package/update management 
product out there of any OS. Various other products may seem better if 
that's what you're used to but having used nim, jumpstart, kickstart, 
and various others, I think yum takes the cake in simplicity and ease of 
use especially if you take the time to set your repos up nice and 
manageable.