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

Re: [rhelv5-list] Staying on a particular RHEL release (eg. 5.4)

On Tue, 2010-03-02 at 14:24 +0100, Tim Edwards wrote:
> We'd like to keep the machines RHN-registered for support and
> management, is there anyway to restrict them to just packages from
> 5.4?

On 02/03/10 15:09, Colin Coe wrote:
> http://press.redhat.com/2008/12/18/red-hat-increases-service-levels-and-reduces-costs-for-customers-with-extended-update-support/

On Tue, 2010-03-02 at 15:55 +0100, Tim Edwards wrote:
> This doesn't really fit us or our use of RHEL. There's no way to do this
> by just changing some yum settings?

First off, with Red Hat Network (RHN) Satellite Server, one can create
clone channels from both RHN (e.g., RHEL) and custom (e.g., internal
RPMs) channels.  This allows an organization to create a set of software
specific to a set of systems, and those systems will only get those
errata/packages that have been added to those clone channels.
Individual RHN and custom errata updates from the feeder RHN and custom
channels can be arbitrarily selected for cloning to the clone channels.

E.g., in common customer workflow, there can be a "test" and "release"
or "Gold" clone channel set, possibly an intermediate "staging" clone
channel set as well.  It allows customers to decide what errata and
updates are important, and what are not.

Secondly, Tim, what you're proposing can be a security or at least a
support issue, one reason why Extended Update Service (EUS) was created,
as I will detail.  I offer this information so everyone can evaluate
their own options for themselves.

To start, I assume everyone here is familiar with Red Hat's Lifecycle:  

And backporting of security fixes:  

Red Hat Errata almost always come in three (3) forms:
- Security (RHSA)
- Bugfix (RHBA)
- Enhancement (RHEA)

In the lifecycle, the latter two are largely limited to the first phase.
Security is done throughout the full seven plus (7+) years of RHEL

Security (RHSA) errata are backported fixes, regularly released after
extensive integration, compatibility and regression testing, to avoid
any issues with IHV/ISV and other products, while resolving CERT and
other vunerabilities.  Everyone should be regularly updating systems
with RHSA errata to mitigate security issues.  The value of the Red Hat
subscription is ensuring that customer systems maintain full ABI/API
compatibility, while addressing security issues as they are discovered.
If there is an integration, compatibility, regression or other issue
with a RHSA, then that is either a fault of Red Hat or your IHV/ISV
(possibly contradictory to the Red Hat IHV/ISV agreement), and customers
should notify the respected support of such situations.  This is the
value customers pay for, which Red Hat expends developer resources on
(as well as working on and syncing with upstream developments, which are
not productized, but the efforts go hand-in-hand -- e.g., Fedora).

Bugfix (RHBA) and, even more so, enhancement (RHEA) errata are left to
the full Updates.  Sometimes bugfixes can change nominal operations, and
that's why they are rolled up with security errata into the full
Updates.  Sometimes enhancement errata are independent, but sometimes
they are a software rebase (e.g., Firefox 1.5 -> 3.0 a few updates back
for both RHEL 4 and 5).

Traditionally Red Hat Engineering and Global Support Services (GSS)
services would refocus errata efforts on the new update after its
released.  This had two considerations.  One, security errata being
based on the latest Update means customers should be on the latest
update (although properly declared and full RPM dependencies address
most of this, but there can be dependency issues at times).  Two,
customers should are running the latest update, so Red Hat can
re-produce an issue, without having to deal with the mixture of old and
new packages, especially old kernels with newer userspace.  I would not
mention this if I have not seen it first hand myself.  ;)

The problem is that some Red Hat customers delay upgrading to the latest
update, because bugfix and enhancements are added to security, whereas
post-Update errata are typically only security.  Red Hat experimented
with "Z-streams", kernel and select userspace packages, with great
success, especially with IHV/ISVs who were slow to release their
software updates for the new, full RHEL Update.  This lead to the
introduction of the Extended Update Service (EUS) offering by late 2008.

EUS allows customers to stay on an update for 12-18 months to plan and
schedule an upgrade to a full, newer Update sometime after the Update is
released.  In the meantime, select "Z-stream" security errata is cut for
the EUS channel.  E.g., the latest security (RHSA) errata for RHEL EUS
5.3.z is RHSA-2010:0053, kernel 2.6.18-128 kernel tree
(2.6.18-128.12.1.el5), even though current development is focused on
RHEL 5.4's 2.6.18-164 kernel tree.
   See:  http://rhn.redhat.com/errata/  
  (always freely browseable, no RHN account required)  

RHN Satellite Server and EUS are really designed for enterprises with
25-50 or more systems.  EUS requires additional resources on Red Hat's
end for the parallel integration, compatibility and regression testing,
as well as GSS' duplication of test environments and other details.  But
it is offered to mitigate such issues when customers need to slip on
their adoption of newer updates for various reasons (again, IHV/ISVs
being a major reason).

-- Bryan
   _Not_ speaking on behalf of Red Hat, but from _peer_ experience

P.S.  For smaller customers, there are other options.  Red Hat
Consulting and Red Hat Solutions Architects are always available to help
discuss these options.  They have a huge pool of expertise for
customers, both large and small.  http://www.redhat.com/consulting  

Bryan J Smith       Senior Consultant       Red Hat, Inc
Professional Consulting http://www.redhat.com/consulting
mailto:bjs redhat com         +1 (407) 489-7013 (Mobile) 
mailto:b j smith ieee org  (Blackberry/Red Hat-External) 
You already know Red Hat as the entity dedicated to 100%  
no-IP-strings-attached, community software development.   
But do you know where CIOs rate Red Hat versus other      
software and services firms for their own, direct needs,
year after year?     http://www.redhat.com/promo/vendor/

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