Do these services require additional payment over the existing Red Hat support.
James Harrison James Harrison -----Original Message----- From: Bryan J Smith <[email protected]> Sender: [email protected] Date: Tue, 27 Jul 2010 09:28:23 To: Red Hat Enterprise Linux 5 \(Tikanga\) discussion mailing-list<[email protected]> Reply-To: "Red Hat Enterprise Linux 5 \(Tikanga\) discussion mailing-list" <[email protected]> Subject: Re: [rhelv5-list] Updating to specific release of redhat On Tue, 2010-07-27 at 07:20 -0700, James Harrison wrote: >The reason we need specific versions, is that 3rd party software vendors don't >move as fast as Red Hat updates they OS. Correct. Which is why I clarified ... "Unless your organization has a known certification and support issue with 3rd party solutions" And then followed with ... "3) Red Hat offers Extended Update Support (EUS) for older release update support #3allows customers with independent software vendor (ISV) or other certification lifecycle issues to remain several releases updates back." Extended Update Support (EUS) is the solution introduced specifically to address this reality with some independent software vendors (ISVs). Take for example IBM's WebSphere MQ and Broker software for Linux. With the Red Hat they still only support up to RHEL 4.5. We cannot upgrade our systems in fear of updating to 5.5. Updating to 5.5 would make any support with IBM pointless. >For newly installed machines with 5.4, we cannot get the latest 5.4 updates, >because we will automatically move to 5.5. >It would be very useful if there was a method of updating without moving to >the >next release. Hence Extended Update Support (EUS). ;) If a system is subscribed to an EUS set of channel, they do not receive any of the feature errata (RHEA) and any bugfix errata (RHBA) are only backported very sparingly, from newer Updates. EUS is largely only security errata (RHSA) backported to the specific releases in the previous update. This is especially in the case of kernels, where the security is addressed on the specific "Z-stream" of the release. EUS 5.3.z: 2.6.18-128 EUS 5.4.z: 2.6.18-164 5.5.z: 2.6.18-194 The only other solutions are to maintain older, forked repositories, which introduces the risk of security vunerabilities for software that may have CVE and other, known issues. Red Hat provides the supported services and facilities (i.e., Red Hat Network Satellite Server "custom" and "clone" channels) and unsupported community software (e.g., Fedora Project various tools) to do such, but it is on the customer to do so, internally. I cannot answer for Red Hat, but I think the reasons why Red Hat would not provide a direct feeds for anything other than A) everything (including latest) or B) EUS (forked with backports from latest) are obvious. EUS is the Red Hat subscription offering that puts engineers on maintaining supported, security patched forks from the latest release update, to address the reality that some ISVs aren't always moving with the latest. Anything else would be risk adverse, something a customer must decide to do explicitly and separate. EUS was the "missing" solution many years ago, but not for the last few. _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
