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