Extended Update Support (EUS) Standard Operating Environment (SOE) Guide

Updated -

What Is Extended Update Support (EUS)?

Extended Update Support (EUS) is an optional offering for Red Hat Enterprise Linux subscribers. With EUS, Red Hat commits to providing backports of Critical-impact security updates and urgent-priority bug fixes for minor releases of Red Hat Enterprise Linux, even for systems that are still one or two minor releases behind the current one. EUS enables customers to remain with the same minor release of Red Hat Enterprise Linux for up to approximately 24 months, allowing for extremely stable production environments for mission-critical applications.

With the introduction of the Red Hat Enterprise Linux 2013 Packaging Model, EUS is provided with Premium subscriptions and is available as an add-on for many others. Please contact your Red Hat Sales Representative if you unsure if you have access to EUS.

Incorporating EUS Into Your Standard Operating Environment (SOE)

The key benefits of EUS are that it:

  • Helps to mitigate risk by providing a more restrictive selection of errata.
  • Has an independent and more rigid release cadence than the standard Red Hat Enterprise Linux release cycle.

As a benefit of the independent release cycle of EUS releases, customers get the capability to skip specific Red Hat Enterprise Linux minor releases. Instead of having systems running every permutation of a major version of Red Hat Enterprise Linux in the environment (such as 6.1, 6.2, 6.3, et al), an organization can choose to release only specific minor releases of Red Hat Enterprise Linux. Depending on preference and scheduling of testing/validation resources, an organization can deploy every other minor release of Red Hat Enterprise Linux such as an "all-evens" or "all-odds" approach. The diagram below shows an example deployment use-case of EUS.

eus2.png
Click here for larger version of graphic

In this example, the organization wanted to deploy every third EUS release starting with 6.0.z (i.e., 6.0.z, 6.3.z, 6.6.z, et al). Additionally, they have an internal validation process that runs every one to six months that needs to be completed prior to releasing a minor release being delivered to their customers. In this example, by selecting every third EUS release, overlap between subsequent releases is allowed.

Recommended Practices

To obtain the maximum benefits from a Red Hat Enterprise Linux subscription, it is still the recommended practice for customers to upgrade to each minor release as we release it (e.g., 6.0 --> 6.1 --> 6.2).

This becomes an issue if:

  • Customers have a policy of re-certifying application stacks when they move to new minor releases of Red Hat Enterprise Linux.
  • Customers have sensitive workloads that they want to minimally disturb.
  • Hardware vendors do not certify Red Hat Enterprise Linux minor releases as aggressively as needed by certain customers.

Solution

EUS provides a set of maintenance streams that:

  • Last for 24 months instead of the normal six months (or 18 months, as in Red Hat Enterprise Linux 5 EUS).
  • Minimize churn by being limited to Critical-impact security fixes and urgent-priority bug fixes.

Benefits

EUS benefits IT organizations in that it:

  • Reduces costs for running large Red Hat Enterprise Linux deployments.
  • Reduces the amount of testing and re-validation customers need to do annually.
  • Reduces the amount of change introduced into a customer's environment.
  • Prevents an IT organization from having to support every minor release of Red Hat Enterprise Linux, which provides the flexibility to deploy every second or third Red Hat Enterprise Linux minor release as the basis of a Standard Operating Environment (SOE).
  • Maintains continuity if an organization has applications that are only supported on a particular minor release.
  • Optimizes the productive life of a deployed release if an organization has lengthy internal validation and certification processes that make it difficult to keep up with each minor release. This is common in many large organizations with shared IT departments that serve multiple business units. For example, EUS provides a means to put out an SOE based on Red Hat Enterprise Linux 6.2.z that moves 24 months later to an SOE based upon 6.6.z and then moves 24 months later to an SOE based upon the next appropriate .z release.

Base Channels and EUS Channels

Like all Red Hat Enterprise Linux maintenance, EUS is delivered via Red Hat Network, where it is implemented as a mirror channel hierarchy (separate base channels, one for each minor release, along with the relevant set of child channels). EUS can be activated for individual systems by subscribing them to the matching base channel.

The channel-naming scheme is derived from the main Red Hat Enterprise Linux channel hierarchy. Each minor release of a major Red Hat Enterprise Linux version has an associated EUS channel, and EUS channel version numbers always end with a z. In Red Hat Network, for example, the EUS channel associated with the release of Red Hat Enterprise Linux Server 6.5 (for the AMD64 architecture) is referred to as Red Hat Enterprise Linux EUS Server (v. 6.5.z for 64 -bit x86_64).

NOTE: The standard base channel (such as the Red Hat Enterprise Linux 6 channel) is mutually exclusive with any EUS channels (i.e., an individual system may only be subscribed to the standard base channel or to an EUS channel, but not to both simultaneously). Once a system has been subscribed to an EUS channel, it will receive only EUS errata updates. Refer to What Is Included in and Excluded from EUS for more information about EUS channel content.

Visit the Red Hat Network for more information regarding Red Hat Enterprise Linux subscriptions and base and child channels.

How to Access EUS

Customers with an active EUS subscription will see EUS channels in addition to the standard base channels in their Red Hat Network account. Only valid EUS channels are shown in Red Hat Network, meaning customers will only see the channels based on their particular system's hardware architecture and the major version of Red Hat Enterprise Linux that is installed. A system can be moved to an EUS channel by changing the base channel in that system's Channels menu to an EUS channel.

NOTE: Starting with Red Hat Enterprise Linux 5.1, customers can register systems directly to EUS channels. For system registration details, refer to the Red Hat Network documentation.

Upgrade Restrictions for EUS Channels

Customers who have systems subscribed to EUS channels should be aware that there are upgrade restrictions when upgrading between minor releases (i.e., systems subscribed to a certain EUS channel should always be upgraded to either a later, more recent EUS channel or to the base channel for that version of Red Hat Enterprise Linux). For example, if a system is currently subscribed to the EUS 6.1.z channel, at any time its subscription could be upgraded to:

  • The 6.2.z EUS channel after the release of 6.2.
  • The 6.3.z EUS channel after the release of 6.3.
  • Any 6.y.z EUS channel where y is greater than 1.
  • The standard base channel for Red Hat Enterprise Linux 6, which is the most recent minor release.

WARNING: It is unsafe to downgrade from a more recent minor release with a higher version number to an earlier minor release or an earlier EUS channel. For example, it would be unsafe to downgrade from Red Hat Enterprise Linux 6.5 to 6.4.z.

EUS Channel Deactivation

The 6.1.z channel, like all EUS channels, will be retired 24 months after it is created and becomes available on RHN. When an EUS channel reaches retirement, no new errata are released to the channels. However, all previously released errata remain available to customers with an active subscription. It is imperative to migrate to a later EUS release to continue receiving errata updates like security and bug-fix errata. You can check to see which EUS channels have been retired and are no longer receiving updates by looking at the Retired Channels page on RHN.

Automated reminder emails are sent 1-year, 6-months, 3-months, 1-month before, and the day of channel retirement. For an archive of all emails, refer to enterprise-watch-list mailing list.

What Is Included/Excluded from EUS

For approximately the first six months of its lifetime (until the next minor release), an EUS channel receives the same updates that the base channel receives. These include Critical, Important, and Moderate-impact security updates and urgent-priority bug fixes. Following the next minor release, an EUS channel is practically restricted to Critical-impact security advisories and selected urgent-priority bug fixes. For EUS subscribers, Red Hat will generally continue to proactively provide Critical-impact RHSAs independent of customer requests if and when available.

Not included in EUS updates are new features, hardware-enabling updates, or updated device drivers as EUS is intended to provide customers with a stable, long-term, secure environment. A list of EUS Inclusions is published here.

More information on EUS and the Red Hat Enterprise Linux Life Cycle can be found here on the Red Hat Customer Portal.

Additional Reading

While EUS provides a more restrictive selection of errata, it does not provide an operational framework or discipline as to how a user of EUS can implement an errata management solution to support a rigid life cycle for their Red Hat Enterprise Linux systems. This is covered in the Red Hat Satellite Errata Management Guide.

10 Comments

"Following the next minor release, an EUS channel is practically restricted to Critical-impact security advisories and urgent-priority bug fixes."

In other words, the security updates are provided at Red Hat's discretion, much like the policy for the Production 3 Phase found in the Life Cycle article. Wonder if the statement "provide secure environment" still holds true in these cases.

Greetings Akemi,

Your statement, "In other words, the security updates are provided at Red Hat's discretion" is not accurate. You may have overlooked the reference in the Life Cycle document that takes you to the Issue Severity Classification reference which clearly explains how Red Hat determines its Impact rating based on the well respected and independent vulnerability entities MITRE and NVD. So the decision is based on solid evaluation and input from outside resources. I suspect your own security team regularly refers to those industry sources for security information as well. Another good resource is Backporting Security Fixes.

The bottom line is that in order to keep up with the rapid innovation provided by the Open Source development models, Red Hat must continually move forward. Upstream develops on upstream. It is a tremendous amount of work to take a security fix to new upstream code, and modify that to work on a 3 year old code base. Therefore, Red Hat is a balance between the rapid upstream and the predictable update models needed by enterprise and businesses.

It is advised not to think of the minor releases, but rather patch bundles. Do not hesitate to update with a regularly scheduled update cycle. True, it is not always perfect as occasionally there is a regression or compatibility issue between new drivers and firmware. However, these same issues are eventually experienced anyway by those customers who do not update regularly and are compounded by minor release version jumping (i.e. 6.2 -> 6.6).

Extended Update Support (EUS), along with Extended Lifecycle Support (ELS) are both meant to be a stop-gap option, providing a bridge until the minor release update can take place.

Our customers who succeed best have regular patching schedules and make a planned effort to stay as current as possible. This discussion is rarely an issue for them and they maintain a very stable and secure platform. I work with many accounts, including financial and embedded telecom. I speak from experience when I say that those customers who struggle the most do not patch regularly and remain on non-current minor releases for long periods of time.

I hope this is helpful to you in understanding our Life Cycle and our security ratings. Please post any followup questions.

-Terry

Thanks for your detailed note. There is one thing I'd like to add about the wording. The "at Red Hat's discretion" part is not my creation. I copied it from the 'Life Cycle' document, note number 11:

  1. All errata provided at Red Hat's discretion.

So my understanding is this:

  • EUS comes as either an add-on subscription (so the customer would require two subs) or as an individual subscription.

  • EUS subs grant you access to both the regular repositories and the EUS repositories, but only one should be used. I.E a machine in Satellite 6 could be given access to the following repositories through a content view: RHEL 7 Common RPS and RHEL 7 Common EUS RPMS but they should only subscribe to one of them.

EUS is provided as either:

  • An add-on sub.
  • A component of an existing sub.

Let's take a look a the EUS add-on for example:

rct cat-manifest manifest.zip
Subscription:
        Name: Extended Update Support
        Quantity: 100
        Created: 2015-08-06T16:51:49.000+0000
        Start Date: 2015-08-05T04:00:00.000+0000
        End Date: 2016-08-05T03:59:59.000+0000
        Service Level: Layered
        Service Type: L1-L3
        Architectures: x86_64,ppc64,ia64,ppc,x86
        SKU: RH00030
        Contract: [REDACTED]
        Order: [REDACTED]
        Account: [REDACTED]
        Virt Limit: 
        Requires Virt-who: False
        Entitlement File: export/entitlements/8a99f98a4efa4ef4014f03ed07ca4560.json
        Certificate File: export/entitlement_certificates/5838778616511924647.pem
        Certificate Version: 3.2
        Provided Products:
                70: Red Hat Enterprise Linux Server - Extended Update Support
                84: Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support
                86: Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
                91: Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support
                93: Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
                127: Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
                133: Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
                182: Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
                246: Oracle Java (for RHEL Server) - Extended Update Support

As you can see in the above, the EUS add-on provides EUS content only. (Which makes a whole lot of sense)

Certain subscriptions provide access to RHEL content AND EUS content. An example of this are the 2013 RHEL Premium Subscriptions.

rct cat-manifest  manifest.zip 
Subscription:
    Name: Red Hat Enterprise Linux Server, Premium (Physical or Virtual Nodes)
    Quantity: 100
    Created: 2015-08-06T16:51:43.000+0000
    Start Date: 2015-08-05T04:00:00.000+0000
    End Date: 2016-08-05T03:59:59.000+0000
    Service Level: Premium
    Service Type: L1-L3
    Architectures: x86_64,ppc64le,ppc64,ia64,ppc,s390,x86,s390x
    SKU: RH00013
    Contract: [REDACTED]
    Order: [REDACTED]
    Account: [REDACTED]
    Virt Limit: 
    Requires Virt-who: False
    Entitlement File: export/entitlements/8a99f9864efa4a57014f03eced2b40f0.json
    Certificate File: export/entitlement_certificates/1892488221322053305.pem
    Certificate Version: 3.2
    Provided Products:
        69: Red Hat Enterprise Linux Server
        70: Red Hat Enterprise Linux Server - Extended Update Support
        84: Red Hat Enterprise Linux High Availability (for RHEL Server) - Extended Update Support
        86: Red Hat Enterprise Linux Load Balancer (for RHEL Server) - Extended Update Support
        91: Red Hat Enterprise Linux Resilient Storage (for RHEL Server) - Extended Update Support
        93: Red Hat Enterprise Linux Scalable File System (for RHEL Server) - Extended Update Support
        127: Red Hat S-JIS Support (for RHEL Server) - Extended Update Support
        133: Red Hat Enterprise Linux High Performance Networking (for RHEL Server) - Extended Update Support
        176: Red Hat Developer Toolset (for RHEL Server)
        180: Red Hat Beta
        182: Red Hat EUCJP Support (for RHEL Server) - Extended Update Support
        201: Red Hat Software Collections (for RHEL Server)
        205: Red Hat Software Collections Beta (for RHEL Server)
        240: Oracle Java (for RHEL Server)
        246: Oracle Java (for RHEL Server) - Extended Update Support
        271: Red Hat Enterprise Linux Atomic Host
        272: Red Hat Enterprise Linux Atomic Host Beta
        273: Red Hat Container Images
        274: Red Hat Container Images Beta

In this subscription, EUS content AND RHEL content is provided. The only way you'd get access to both EUS and RHEL is either by attaching 2 distinct subs (EUS & RHEL), or one sub, similar to the one above that provides both.

As far as repos are concerned, you are correct in the statement that you should use only one of either the non-EUS version or the EUS version of a repo.

When we buy a Subscription, why can't we get a list of repositories that is included? Just got surprised. We have to use specific repos but they are not included in the EUS addon included in the premium subscription. The recent Spectre and Meltdown revelations certainly provide ample severity.

Can you be more specific on what is missing? Which RHEL subscription do you have? What version are you running?

You totally can. Take a look in the portal under subscriptions -> 'NAME OF YOUR SUB' -> Content. Example here

How do you actually lock your release on a minor version and subscribe to EUS: How to tie a system to a specific update of Red Hat Enterprise Linux? .

Can someone from Red Hat provide clarification on how non-base repositories (eg. optional repository) are handled in the EUS lifecycle? Are the additional repos such as 'optional' covered by EUS, if so, is it all additional repos or just a selection?