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.

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