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
