After RHEL 7's EOL, Red Hat Will Offer a 4-Year 'Extended Life Cycle Support' Add-On (redhat.com) 35
End-of-life for Red Hat 7 is scheduled to happen in one year. Thursday Red Hat announced an add-on option for four
more years of "extended support" for RHEL 7:
As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...
For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...
ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.
When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.
CentOS 7 will also hit its end-of-life in one year on June 30 of 2024.
For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...
ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.
When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.
CentOS 7 will also hit its end-of-life in one year on June 30 of 2024.
CentOS 7 (Score:4, Funny)
"CentOS 7 will apparently still hit its end-of-life in one year on June 30 of 2024."
I'm surprised they didn't change it to June 30, 2023.
Re: (Score:2)
There are probably contracts pinning that in place. I think RH picked up CentOS in 2014, and it kind of makes sense that a 10 year support agreement might have been inherited around that same time frame. This is just speculation but the numbers fit in my mind.
CentOS 7 EOL (Score:3)
CentOS 7 will apparently still hit its end-of-life in one year on June 30 of 2024.
If the CentOS team do not get access to the package sources, as RedHat is trying to impose, then it's already EOL.
Re:CentOS 7 EOL (Score:5, Interesting)
CentOS 7 will apparently still hit its end-of-life in one year on June 30 of 2024.
If the CentOS team do not get access to the package sources, as RedHat is trying to impose, then it's already EOL.
Don't you guys get it...the whole point of the earlier package source access removal and now this announcement are as a coordinated effort to encourage (read force) organizations they see as drafting off of free CentOS 7 to move to a paying model.
No one wants to migrate flavours and versions at the same time. This has nothing to do with giving existing RHEL 7 customers time to migrate, and everything to do with giving time to get CentOS 7 users migrated to RHEL 7 first before they then have to upgrade to RHEL 8.
Carrot and the stick. Now what's going to happen is we'll see more of both:
- Carrot: Some extremely special pricing come along soon for existing CentOS users to move to a paying version.
- Stick: More restrictions on CentOS
Re: CentOS 7 EOL (Score:3)
Re: (Score:3)
The ELS (Extended Life Cycle Support), i.e. an extended support subscription (only for security updates) has never had sources available from RedHat from all the ways to the earliest RHEL versions with ELS options.
Microsoft has a similar model for Win 7 support via ESU (Extended Security Updates) for enterprise customers (if you absolutely, positively, cannot upgrade, you can choose to pay for Microsoft to provide some support.
Organizations that fail to plan can now plan to pay....
Re: CentOS 7 EOL (Score:2)
It is, I guess, also similar to Canonical's Expanded Security Maintenance (ESM), now part of what they call Ubuntu Pro. It is available for free for a limited number of personal installations, though, and there are competing services to supply EOL'ed Ubuntu versions with security updates, too (without Canonical too obviously trying to intervene in one way or another, by the way).
The elephant in the room, though, and sometimes my impression is that it must be an invisible elephant in the room as no one likes
Re: (Score:1)
Boat Anchor Linux (Score:3)
We need to cut this thing loose so we can move forward. My group is still stuck with RHEL-7 as a baseline for our binary releases because customers won't get off the obsolete stuff.
Re: (Score:2)
Our industry has a tech debt problem. I wonder what could be the incentives to get that situation under control...
Re: (Score:2)
What is it with this pervasive "old software = bad" mindset?
Imagine you have this antique DOS based app, that happens to do what it's used for, 100% fine. And has been doing so for decades. Running on a mini, silent industrial PC, Raspberry Pi style box or similar, super stable & at lightning speed. Why on earth would you 'upgrade' that?
Sure, if something new does it better by all relevant metrics. Transistors have obsoleted relay based computers. Sure, if requirements change, old system can't
Re: (Score:1)
There's nothing wrong with old software that does what it needs to do. No reason to upgrade unless there's a security vulnerability, or you expect that you'll need to update in the future. It's much easier to upgrade incrementally than trying to upgrade something 3 versions behind the current supported version.
However, for an OS, the situation is a little different. A major purpose of an OS is to run other software, if the OS can't run the software it needs to, then that's a problem.
E.g., RHEL 7 doesn't
Re: (Score:2)
Almost all (excluding certain exotic scenarios) software is expected to need to update in the future. Software today exists in an ecosystem. That ecosystem moves forward. _Something_ will eventually require you to perform an update, and if you are now 10 years behind the rest of the world there won't be a reasonable incremental process and the difficulty ramps up massively. You can either spread that pain out over those 10 years in a relatively predicable / consistent manner, or you can feel that pain in
An "ecosystem"? Pfft. Software isn't a forest. (Score:1)
Almost all (excluding certain exotic scenarios) software is expected to need to update in the future.
"Expected" perhaps by those with a lack of experience or knowledge of how computing and software works, perhaps. Most software works just fine right were it's at at just what it's doing. Software isn't just SSL-related expiring web-garbage. The biggest element driving "upgrades" is sales & marketing wanting a job and security assholes spreading FUD who also want a job and want to remain scared conformist rule-followers. Software that does have a legitimate need to upgrade rarely needs those updates at t
Re: (Score:2)
Extremely wide difference between what you mention -a DOS app running on a small low end system, which can be easily migrated elsewhere as time permits - and the cruft of RedHat.
One big reason to not use RHEL: performance. I've seen numerous companies migrate to -something else- and gain very significant performance improvements to their platform as a result. It doesn't matter if we're talking about "old" CentOS/Rhel or "the latest, greatest" - there are significant differences when comparing to modern dist
One down, two to go (Score:4, Interesting)
Re: (Score:2)
My hunch is that many people who are still on RHEL 7 and CentOS 7 are still there because they no longer have a RedHat supported free alternative that's 100% compatible with RHEL to use in their lower environments for testing. They were probably waiting to see how the alternatives like Rocky Linux and Alma Linux turned out before deciding to either use them to jump to a new Linux distribution entirely.
Maybe IBM should focus more on the demand side of the equation instead of extending RHEL 7 support. By givi
Definition of ELS (Score:2, Informative)
All major releases of RHEL follow a standard 10-year life cycle. During the first 5 years, we provide full support, including bug fixes, security patches, software enhancements, hardware enablement and backports. During the next 5 years, we provide maintenance support with security patches and bug fixes released on an as-needed basis.
After this, RHEL enters the Extended Life Phase (ELP). During this time, you have continued access to previously-released content on the Red Hat Customer Portal and the Red Hat Knowledgebase. Additionally, we may provide limited ongoing technical support and advice for migrating to currently supported RHEL versions.
For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes.
So ELS is an optional add-on that can be purchased for support beyond 10 years.
It's being extended to 4 years for RHEL 7 (2024-2028) and 3 years for RHEL 8 & 9 [redhat.com].
FAQ: Red Hat Enterprise Linux 7 reaches End of Maintenance Phase and transitions to Extended Life Phase [redhat.com]
Re: (Score:1)
Look, a squirrel ... (Score:3)
>"When you're ready to upgrade from RHEL 7 â" or any other version â" Red Hat is here to help."
Sorry, this is NOT going to distract us from the elephant in the room- the violation of the spirit of FOSS and probably the terms of GPL by attempting to destroy Alma/Rocky Linux after you already destroyed CentOS.
IBM: You are attempting to sacrifice the name of your chattel purchase, RedHat, and its past good will, for some increased short-term profit at the expense of absolutely DESTROYING your ability to flourish in the future. Why? Because NOBODY is going to trust RedHat anymore. The CentOS move was bad enough, but the nature of FOSS came in and filled that injury. But now all the people who install the RHEL clones might later choose to use your commercial support are going to go elsewhere. The even sadder part is that you will probably not get the expected short-term profits, because the news and its real meaning are spreading to customers right now.... even the PAYING people who use RHEL are really, REALLY opposed to your recent actions.
If you want to "change your mind" on something meaningful, then stop with this trying to restrict source code, immediately. Admit it was a mistake, and pray that people will forget and it isn't already too late for you. Focus on ACTUAL commercial support- like help lines, support forums, exclusive on-line content, training and education, certification, hosting, and testing, customization, consultation, implementation and installation services.
Big Customer must have just paid their bills. (Score:2)
Damage is already done (Score:3)
There's also Project78 (Score:3)
www.project78.com [project78.com] is created by Linux Belgium [linuxbe.com] with the commitment that a large part of the revenue will flow back to the community.
Re: (Score:2)
We did see this coming. We switched our servers to Ubuntu a few years ago.
Re: (Score:1)
Freeloader here (Score:1)
I want to pay the OS tax to RH, but I see two problems.
1. The price of an RHEL Subscription is too much when converted from dollars to my local currency.
2. Affordable RHEL Subscriptions would mean RHEL would be more popular and, therefore, more prone to attacks.
IBM Bassing (Score:2)
A lot of people rightly bashed IBM for its RHEL decisions. But one thing IBM really gets that many other companies do not. Upgrading is very hard for Businesses and IBM always likes to make this easier.
One good example is IBM DOS 7. That was released around 2000 to get around a Y2k bug. That allowed people on DOS to run their old critical processes that still needed DOS. I hope IBM with RHEL keeps up this practice.
So doing this seems to be in line with what IBM tends to do with upgrades.
Genius (Score:2)
Re: Genius (Score:1)