Patching Red-Hat to a specific version.

Fri Dec 9 13:40:47 UTC 2011

On Fri, Dec 9, 2011 at 8:30 AM, Mertens, Bram <mertensb at mazdaeur.com> wrote:
>> >
>
>
> Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek
> VAT BE 0406.024.281, RPR Mechelen, ING  310-0092504-52, IBAN : BE64 3100 0925 0452, SWIFT : BBRUBEBB
>
> -----Original Message-----
>> > > From: redhat-list-bounces at redhat.com [mailto:redhat-list-
>> > > bounces at redhat.com] On Behalf Of Matty Sarro
>> > > Sent: donderdag 8 december 2011 17:31
>> > > To: General Red Hat Linux discussion list
>> > > Subject: Re: Patching Red-Hat to a specific version.
>> > >
>> > > On Thu, Dec 8, 2011 at 11:18 AM, cliff here <c4ifford at gmail.com> wrote:
>> > > > Hey guys and gals,
>> > > >
>> > > > This might be a simple question but it's in a scenario that I haven't
>> > had
>> > > > to deal with with before. I'm about to enter testing process where all
>> > of
>> > > > my (four) redhat boxes need to be the same version. Well right now I
>> > have
>> > > > three 5.6 hosts and one 5.7 host; now I know those point releases
>> > become
>> > > > less and less important once the hosts are synced up to RHN. I know
>> > that
>> > > > most of the packages are the same version or close enough to it, but
>> > the
>> > > > product testers want to see the same version exactly. So is there a
>> > way to
>> > > > sync to RHN on a specific point release?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > >
>> > -------------------------------------------------------------------------------------------
>> > > ------------------------------------------
>> > > > NOTICE: This message, including all attachments, is intended for the
>> > use of
>> > > > the individual or entity to which it is addressed and may contain
>> > > > information that is privileged, confidential and exempt from disclosure
>> > > > under applicable law. If the reader of this message is not the intended
>> > > > recipient, or the employee or agent responsible for delivering this
>> > message
>> > > > to its intended recipient, you are hereby notified that any
>> > dissemination,
>> > > > distribution or copying of this communication is strictly prohibited.
>> > If
>> > > > you have received this communication in error, please notify the
>> sender
>> > > > immediately by replying "Received in error" and immediately delete
>> this
>> > > > message and all its attachments.
>> > > >
>> > -------------------------------------------------------------------------------------------
>> > > ------------------------------------------
>> > > > --
>> > > > redhat-list mailing list
>> > > > unsubscribe mailto:redhat-list-
>> request at redhat.com?subject=unsubscribe
>> > > > https://www.redhat.com/mailman/listinfo/redhat-list
>> > >
>> > > I ran into a similar problem. What I did was in QA, had one of the
>> > > boxes be my "golden" box. On that box I installed the yum-downloadonly
>> > > plugin, and ran the following command:
>> > > yum update --downloadonly --downloaddir=/var/updaterollup -y
>> > >
>> > > This will pull down all updates to make the box current, and store
>> > > them in the /var/updaterollup directory (you will need to create it).
>> > > Then, you can copy this set of patches across each of your servers and
>> > > install. It guarantees that everything has the same version installed.
>> > > Thus far its worked pretty well, though occasionally RPM will bitch
>> > > that versions don't match. Given that its the same thing yum would
>> > > have run, you can probably safely force the installation.
>> > >
>> > > We have been doing this but utilizing opsware/hp server automation to
>> > > deploy the packages. Usually the first remediation will install any
>> > > kernel updates and libraries, and then the second remediation will
>> > > install all other software.
>> >
>> >
>> > You mentioned the systems are synced to RHN.
>> >
>> > The easiest solution appears to be to use the package profile sync option
>> > to get all boxes aligned.
>> >
>> > Then create a system group for the four boxes and execute any update
>> > command on that group rather than on the individual servers.
>> >
>> > That way you avoid having to download the packages, and especially having
>> > to force any update.
>> >
>> > @Matty: why would "force" ever be required even in the scenario you
>> > propose?
>> > If the boxes start from the same point you would download all required
>> > packages on the first box and if they're not at the same starting point you
>> > need to allow yum to pull in whatever dependencies are missing or risk
>> > breaking packages.
>> -----Original Message-----
>> From: redhat-list-bounces at redhat.com [mailto:redhat-list-
>> bounces at redhat.com] On Behalf Of Matty Sarro
>> Sent: vrijdag 9 december 2011 13:39
>> To: General Red Hat Linux discussion list
>> Subject: RE: Patching Red-Hat to a specific version.
>>
>> @Bram
>> I've found it to mostly happen if you use rpm to install the packages using
>> some command like "rpm -Uvh *.rpm". Rpm will go through in alphabetical
>> order (I think) and occasionally try to install a package who hasn't yet
>> had its required library update installed yet because the library comes
>> later in the alphabet. Now it could just be an issue with using rpm, in
>> which case yum localinstall may fix it, but it does happen. Give it a shot
>> and you'll see what I mean. This goes doubly for kernel updates (not that
>> you should ever run an rpm update with a kernel package).
>> -Matty
>
> I rarely use rpm directly anymore, yum takes care of most of this for you.  But I was under the impression that even rpm would somehow sort rpm packages specified by such glob in the correct way.
>
> As I wrote I would avoid all this manual work by using groups or even channels in RHN.  After all the entire purpose of FLOSS is to avoid reinventing the wheel. :)
>
> Regards
>
> Bram
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list

I really need to pull myself up to date on the finer points of RHN,
I'm so used to not having it that I always forget about using it as
more than just a repository :) I'll have to check it out!