RE: Patching Red-Hat to a specific version.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >


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


[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux