Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) Overview
- What Is Extended Update Support (EUS)?
- What Customer Use Cases Benefit from Using EUS?
- How are updates to the EUS repository made?
- Recommended Red Hat Enterprise Linux Maintenance Practices
- How to Access EUS
- EUS Timing and Planning Considerations
- Upgrade Restrictions for EUS repositories
- Additional Reading
What Is Extended Update Support (EUS)?
Extended Update Support (EUS) is an optional offering for Red Hat Enterprise Linux subscribers. With EUS, Red Hat provides backports of Critical and Important impact1 security updates and urgent-priority bug fixes for a predefined set of minor releases of Red Hat Enterprise Linux. EUS enables customers to remain with the same minor release of Red Hat Enterprise Linux for 24 months, allowing for stable production environments for mission-critical applications.
EUS is provided with x86-64 Red Hat Enterprise Linux Server Premium subscriptions and is available as an Add-on to Red Hat Enterprise Linux Server standard subscriptions, Red Hat Enterprise Linux for IBM Power LE, and Red Hat Enterprise Linux for IBM z Systems subscriptions. EUS is now available for Red Hat Enterprise Linux Workstation standard and premium subscriptions as an Add-on for version 9 only. Please contact your Red Hat Sales Representative if you are unsure if you have access to EUS and to help decide if it is appropriate for your environment.
What Customer Use Cases Benefit from Using EUS?
- Customers who have a policy of re-certifying application stacks when they move to new minor releases of Red Hat Enterprise Linux
- Customers who have sensitive workloads that require minimal change
- Customers using third party applications from ISVs who certify on specific Red Hat Enterprise Linux minor releases
How are updates to the EUS repository made?
The inclusion criteria for fixes in the Extended Update Support repository will follow two general rules during its 24-month life cycle:
- 0-6 months: Includes generally the same errata released for the corresponding minor version with the exception of driver updates.
- 7-24 months: Only Critical and Important impact security updates and urgent-priority bug fixes. At Red Hat’s discretion, in limited, new features or hardware enablement may be added to the EUS maintenance streams.
These criteria were selected to reduce change to an environment and promote stability.
Recommended Red Hat Enterprise Linux Maintenance Practices
To obtain the maximum maintenance benefits from a Red Hat Enterprise Linux subscription, it is recommended practice for customers to upgrade to each minor release as they are released (e.g., 9.0 --> 9.1 --> 9.2).
How to Access EUS
Like all Red Hat Enterprise Linux maintenance, EUS is delivered via Red Hat Subscription Manager, where it is implemented as a mirror repository hierarchy (separate repository(s), for each minor release, along with the relevant set of child repositories).
With the introduction of Red Hat Enterprise Linux 8, content is distributed through the two main repositories: BaseOS and AppStream.
BaseOS
Content in the BaseOS repository is intended to provide the core set of the underlying OS functionality that provides the foundation for all installations. This content is available in the RPM format and is subject to support terms similar to those in previous releases of Red Hat Enterprise Linux.
AppStream
Content in the AppStream repository includes additional user space applications, runtime languages, and databases in support of the varied workloads and use cases. Content in AppStream is available in one of two formats - the familiar RPM format and an extension to the RPM format called modules.
RHEL EUS Example using x86-64 Architecture
Red Hat Enterprise Linux 7 Minor Release Main Repository
- Red Hat Enterprise Linux 7 Server
rhel-7-server-rpms
Red Hat Enterprise Linux 7 EUS Main Repository
- Red Hat Enterprise Linux 7 Server - Extended Update Support
rhel-7-server-eus-rpms
Red Hat Enterprise Linux 8 Minor Release Repositories
- Red Hat Enterprise Linux 8 for x86_64 - BaseOS
rhel-8-for-x86_64-baseos-rpms
- Red Hat Enterprise Linux 8 for x86_64 - AppStream
rhel-8-for-x86_64-appstream-rpms
Red Hat Enterprise Linux 8 EUS Repositories
- Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support
rhel-8-for-x86_64-appstream-eus-rpms
- Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support
rhel-8-for-x86_64-baseos-eus-rpms
Red Hat Enterprise Linux 9 Minor Release Repositories
- Red Hat Enterprise Linux 9 for x86_64 - BaseOS
rhel-9-for-x86_64-baseos-rpms
- Red Hat Enterprise Linux 9 for x86_64 - AppStream
rhel-9-for-x86_64-appstream-rpms
Red Hat Enterprise Linux 9 EUS Repositories
- Red Hat Enterprise Linux 9 for x86_64 - AppStream - Extended Update Support
rhel-9-for-x86_64-appstream-eus-rpms
- Red Hat Enterprise Linux 9 for x86_64 - BaseOS - Extended Update Support
rhel-9-for-x86_64-baseos-eus-rpms
EUS can be activated for individual systems by subscribing them to the matching EUS repository(s) and executing
subscription-manager release --set=x.y
where "x.y" is the supported RHEL major and minor version that one desires. (Executesubscription-manager release --list
for the available list, and see the "Extended Update Support Add-on" section of the RHEL life cycle document for the list of active EUS versions.)Customers with an active EUS subscription will see EUS repositories in addition to the standard repositories via Red Hat Subscription Manager (RHSM). RHSM provides status, inventory, organization, and reporting on Red Hat subscriptions via:
- A hosted service on the Red Hat Customer Portal
- On-premise access through Red Hat Satellite
- Using Subscription Manager from a Red Hat Enterprise Linux system
A robust supported and documented API for RHSMWhen you purchase a subscription to a product, RHSM tracks which system(s) in your inventory are registered to the subscription. Registered systems are entitled to support services, as well as errata, patches, and upgrades from the Content Delivery Network (CDN).
EUS repositories are shown in RHSM, meaning customers will only see the repositories 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 repository(s) by changing the base repository in that system's repositories menu to an EUS repository(s).
EUS Timing and Planning Considerations
Please see the Red Hat Enterprise Linux Life Cycle document for the list of minor versions and their end dates.
Red Hat Enterprise Linux 8 minor releases that include EUS are planned for release based on the below planning schedule. Customers requiring longer maintenance should plan based on the below schedule per the RHEL Life Cycle Policy.
Click here for larger version of graphic
Red Hat Enterprise Linux 9 minor releases that include EUS are planned for release based on the below planning schedule. Customers requiring longer maintenance should plan based on the below schedule per the RHEL Life Cycle Policy.
Click here for larger version of graphic
The RHEL EUS release repository receives all ALL security, bug fix, and enhancement errata (per the full maintenance RHEL life cycle policy) until the next minor release is released. Afterwards, it only receives the selected backports as per the EUS inclusion policy.
NOTE: The standard base repository (such as the Red Hat Enterprise Linux 9 for x86_64 - BaseOS) is mutually exclusive with any EUS repositories (i.e., an individual system may only be subscribed to the standard base repository or to an EUS repository, but not to both simultaneously). Once a system has been subscribed to an EUS repository, it will receive only EUS errata updates.
Upgrade Restrictions for EUS repositories
Customers who have systems subscribed to EUS repositories should be aware that there are upgrade restrictions when upgrading between minor releases (i.e., systems subscribed to a certain EUS repository should always be upgraded to either a later, more recent EUS repository or to the base repository for that version of Red Hat Enterprise Linux). For example, if a system is currently subscribed to the EUS 9.1 repository, at any time its subscription could be upgraded to:
- The RHEL 9.2 EUS repository after the release of 9.2
- The RHEL 9.4 EUS repository after the release of RHEL 9.4
- Any RHEL 9.y EUS repository where y is an even number
- The standard base repository for Red Hat Enterprise Linux 9, 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 repository. For example, it would be unsafe to downgrade from Red Hat Enterprise Linux 9.2 to 9.1.
EUS repository Deactivation
For a given RHEL minor release, EUS repository (for example RHEL 9.0), like all EUS repositories, will be retired 24 months after it is created and becomes available via Red Hat Subscription Manager. When an EUS repository reaches retirement, no new errata are released to the repositories. 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 repositories have been retired and are no longer receiving updates by looking at the Red Hat Enterprise Linux Retired Life Cycle Dates page.
More information on EUS and the Red Hat Enterprise Linux Life Cycle can be found on the Red Hat Customer Portal.
EUS Maintenance Policies
Please visit the Red Hat Enterprise Linux LIfe Cycle page for information on EUS maintenance policies.
Visit the Red Hat Customer Portal for more information regarding Red Hat Enterprise Linux subscriptions and base and child repositories.
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 Content Management Guide.
Red Hat Enterprise Linux 8 EUS Frequently Asked Questions
Red Hat Enterprise Linux 9 EUS Frequently Asked Questions
-
Applies to Important CVEs that occur on or after October 1, 2019 ↩︎
25 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:
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:
Let's take a look a the EUS add-on for example:
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.
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
Hi guys, a little late to the party, would like to know if we have something on a red hat documentation that state this portion "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."
A customer of mine is looking at having both the repos into a single Content View on Satellite and i am trying to convince them why it wouldn't be recommended to do so.
In the past, I've looked for such documentation, myself, and could not find it. Since, to my knowledge, everything in the non-EUS repository (for example,
rhel-8-for-x86_64-baseos-rpms
) is also present in the EUS repository (rhel-8-for-x86_64-baseos-eus-rpms
), I think the desire is really just for efficiency in keeping the system from needlessly downloading the non-EUS repository metadata and duplicating package dependencies, etc.I should also note that having both non-EUS and EUS repositories in a content view is not, in and of itself, an undesired state. One can have that, yet have hosts that use that content view disable the non-EUS repositories (or the EUS ones) depending upon the system administrator's desire.
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?
Yes, optional repositories are included in the EUS.
The end date for RHEL 7.7 EUS appears to be incorrect on the following page:
https://access.redhat.com/support/policy/updates/errata
This puts 7.7 EUS end date only 3 months after 7.6 EUS.
Is the correct 7.7 EUS end date August 30 2022?
The dates are correct. The "7.6 (ends May 31, 2021)" date was extended to "...ease the migration pressures." due to the impacts of COVID-19. Please read the blog post [1] to learn more.
[1] https://www.redhat.com/en/blog/red-hat-announces-product-life-cycle-changes
Exactly the information I was after.
Thanks for the quick response Julio!
Hi, As I understand correctly EUS 7.7 will be final EUS for RHEL 7. Support of it ends August 30, 2021, but RHEL 7 Maintenance ends at June 30, 2024. What possibilities do we have then to have EUS functionality (to stay at minor level for 24 months since release) for remaining 3 years of RHEL 7 support?
Adam, we have also announced via the Life-cycle Dates section [1] of that RHEL Life Cycle page that RHEL 7.9 will be the last minor release of RHEL 7. So your option is to stay on RHEL 7.7 EUS until RHEL 7.9 is released and then updated to RHEL 7.9 and you will be able to stay on it until RHEL 7 reaches its end of Maintenance Support 2 phase on June 30, 2024.
[1] https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates
There is a minor typo in the document under "Recommended Red Hat Enterprise Linux Maintenance Practices"
Thank you, pixdrift, for pointing this out. I have fixed it.
Hi, just want to clarify. can Red Hat still provide maintenance support for RHEL 7.7 and below even if the EUS already ended? I am not sure if my understanding is correct. Does EUS only provide update support? how about maintenance/ticketing for expired minor version?
Hello! I believe the term "maintenance support" in this document refers to the availability of software packages built specifically for a particular minor version. For example,
kernel-3.10.0-1062.51.1.el7.x86_64
is a version that came specifically with RHEL 7.7. (See Red Hat Enterprise Linux Release Dates for the kernel versions for other RHEL minor releases.)With that definition in mind, there are 2 answers to your question of whether Red Hat can still provide such packages for RHEL 7.7. The 1st answer is "no", Red Hat cannot provide that under Extended Update Support (EUS), as the EUS period for RHEL 7.7 has expired.
However, the 2nd answer would be to inform you that Red Hat offers an add-on subscription called "Update Services For SAP Solutions" (E4S). Whereas EUS provides qualified updated packages for ~24 months after a minor version release, E4S provides qualified updated packages for ~48 months. We are offering E4S on RHEL 7.7 until August 30, 2023.
You ask if EUS only provides update support and what relation it has in being able to submit support cases. The main benefit of EUS is getting qualified, updated software packages specifically meant & tested for a particular RHEL minor version.
The ability to submit support cases comes with the regular RHEL subscription. Under it, you can submit a support case for any minor version of any RHEL major version within that major version's 10-year life cycle. (Please see Red Hat Enterprise Linux Life Cycle for details about the 10-year life cycle.)
So yes, until the end of RHEL 7's 10-year life cycle, you can open a support case for a RHEL 7.7 machine if you need help configuring something or troubleshooting an issue. But please know that outside of EUS and E4S, if the problem you face is discovered to be a bug with the RHEL 7.7 software, you'll be directed to update to a newer minor version. (If that same situation happens and you have the E4S add-on subscription for RHEL 7.7, and the bug is determined by Red Hat to be a qualified urgent priority bug, then it would be worked on with the goal of delivering an updated package specifically targeted for RHEL 7.7.)
I hope that I've made things more clear for you.
Thank you very much for your elaborate answer. This is really helpfull.
I do have a question for EUS for SAP, Does this mean the base subscription should be RHEL for SAP Solution as well? i only see the following SKU for EUS below and nothing specific for SAP Solution.
RH00030 Extended Update Support
RH00038 Extended Update Support (Disaster Recovery)
RH00754 Extended Update Support for Power, LE for Unlimited Guests
RH00506 Extended Update Support for Red Hat Enterprise Linux for Power, BE, (IFL, up to 4 LPARs)
RH00508 Extended Update Support for Red Hat Enterprise Linux for Power, LE (4 Cores, Up to 4 LPARs)
RH00518 Extended Update Support for Red Hat Enterprise Linux for Power, BE, (IFL, up to 4 LPARs) (disaster recovery)
RH00519 Extended Update Support for Red Hat Enterprise Linux for Power, LE, (IFL, up to 4 LPARs) (disaster recovery)
RH01934 Extended Update Support for Red Hat Enterprise Linux for Power, LE (Physical or Virtual Nodes)
RH00061 Extended Update Support for Unlimited Guests
RH00064 Extended Update Support for Unlimited Guests (Disaster Recovery)
Yes. Update Services For SAP Solutions (E4S) is not part of Extended Update Support (EUS).
EUS content is provided either through:
I think I misspoke when, in my previous comment, I referred to E4S as an add-on subscription. I now believe that E4S content is only provided as part of our "Red Hat Enterprise Linux For SAP Solutions" subscription. (2 examples: RH00763 for a "premium" one and RH00764 for a "standard" one.) A RHEL server using one of those subscriptions would have access to repositories like
rhel-7-server-e4s-rpms
,rhel-8-for-x86_64-baseos-e4s-rpms
andrhel-8-for-x86_64-appstream-e4s-rpms
.I am not aware of a way to purchase E4S as an add-on. However, there is much about our offerings that I do not know. I suggest reaching out to your sales representative for an authoritative answer. (Or use this sales form if you do not have a representative.)
I forgot that we also have this document that might help explain: How am I supported on a specific RHEL release?