EOL For Red Hat 7 and CentOS 7 In 1 Year and a Week (redhat.com) 53
Long-time Slashdot reader internet-redstar writes:
In little longer than 1 year, RHEL7 and CentOS 7 will go EOL. Large enterprises with thousands of these servers are struggling to meet that deadline. Now they also have the option to use Project78 from Linux Belgium which offers a Cloud and OnPrem version to aid in the transition to RHEL 8 or Rocky Linux 8. It promises a 100% success rate for in-place OS upgrading and a 95% success rate for application migrations in a Upgrade-as-a-Service package.
In April Red Hat's senior technical marketing manager shared their thoughts about next year's end of life for CentOS Linux and the End-of-Maintenance for Red Hat Enterprise Linux 7 (along with some tips): The good news is that these events won't require a complete infrastructure overhaul. Tools are available to move from your current configuration to a place where you'll have years of support. While June of '24 may sound a ways off, do not delay. It will be here faster than you think. Start planning now. Start moving soon. Give yourself plenty of runway, and don't forget that we aren't just your software vendor at Red Hat. We are your partners and are here to help you with these transitions.
UPDATE (7/3): 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.
In April Red Hat's senior technical marketing manager shared their thoughts about next year's end of life for CentOS Linux and the End-of-Maintenance for Red Hat Enterprise Linux 7 (along with some tips): The good news is that these events won't require a complete infrastructure overhaul. Tools are available to move from your current configuration to a place where you'll have years of support. While June of '24 may sound a ways off, do not delay. It will be here faster than you think. Start planning now. Start moving soon. Give yourself plenty of runway, and don't forget that we aren't just your software vendor at Red Hat. We are your partners and are here to help you with these transitions.
UPDATE (7/3): 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.
We're done with RedHat. (Score:1)
Honestly? We're a super large tech company with a server install base in the half a million nodes range and we're done with RedHat. Good riddance.
Re: (Score:2)
Re: We're done with RedHat. (Score:2)
I switched to debian in the 90s, it just works.
Can someone explain the complexity here? (Score:3)
Linux at least in my experience and based on what people have raved about it online is typically rock solid for upgrades, save for a few small experimental distributions, and ... Ubuntu which is more and more Windows like every day.
Why exactly is RHEL constantly in the news in terms of upgrading problems, and questions about binary compatibility and the likes? And why the heck is there now a whole separate category of "Upgrade as a Service" from a third party for this?
Re: Can someone explain the complexity here? (Score:2)
Re: (Score:2)
RHEL never supported in-place upgrades until EL8. So need to make clean setup from the ground up during migration to new major release wasn't something new.
Re: (Score:1)
Maybe your definition of in-place upgrade differs from mine. But my experience was upgrading from an Upstart based system to Systemd was transparent. Running the upgrade process involved a release where one init process basically shimmed off to another. Not even my horrendously poorly coded scripts which relied on upstart failed after the switch to systemd. Did RHEL not provide compatibility for the transition during the major version change?
Is that the fundamental issue here, that RHEL breaks between major
Re: Can someone explain the complexity here? (Score:2)
Re: Can someone explain the complexity here? (Score:2)
It's because Linux is hard and fairly hacker friendly. And RHEL has mainly enterprise customers rather than hackers. So they feel the pain of Linux more acutely. There is no easy solution for them, such as switching distros. "Git gud" and "lern 2 Linux" is the only way to navigate Linux. Even modern windows-like Linux.
Re: (Score:1)
Re:Can someone explain the complexity here? (Score:5, Informative)
Linux at least in my experience and based on what people have raved about it online is typically rock solid for upgrades, save for a few small experimental distributions, and ... Ubuntu which is more and more Windows like every day.
Why exactly is RHEL constantly in the news in terms of upgrading problems, and questions about binary compatibility and the likes? And why the heck is there now a whole separate category of "Upgrade as a Service" from a third party for this?
It's not a shortcoming of RHEL, it's a nature of the workload.
Not many years ago I worked on control systems, the kinda stuff where code can sit mostly unchanged for 20+ years and the uptime is expected to have multiple 9s since downtime can mean entire companies taking unscheduled time off.
The newer stuff ran on Solaris 10, older on Solaris 8 (I might have seen 7?), and some really new fancy stuff was going onto RHEL 7.
Those kinds of systems sit running happily and doing their thing for years at a time, routine updates are often deferred since they've air-gapped and firewalled and it's quite a bit of prep making sure you have a rollback plan incase something goes wrong.
Now, consider an OS upgrade.
1) Much harder rollback than installing patches, especially if you're pre-cloud.
2) Libraries have changed, meaning you need to go through those tens, hundreds, or even thousands of compiler errors and fix everything.
3) Ok, it builds. Now test everything. Not just the bits you changed, but every single piece of functionality since the underlying libraries have changed as well. And don't imagine that 20+ year code base is comprehensively unit tested.
4) Ok, now you've got your ducks in a row, now start trying to tell the customer they need to do this massive and time consuming upgrade on their perfectly functional system. And do their own retesting of every bit of functionality they care about. And if they don't want to (no duh) prepare yourself for the fact you now have two versions of your software, the RHEL 7 version and the RHEL 8/9 version.
5) Remember, this system might have been in place since 2015, do they even have a nice test environment where they can verify everything is happy before going live?
6) In five years be ready to dust off that playbook for when the customer does want to upgrade.
Are there organizations that run Windows with these workloads and have the same problems? Sure, but they're the exception, not the rule.
When you're dealing with organizations who are willing to pay for RHEL subscriptions they're doing it because they absolutely do not want bugs, downtime, or terrifying system upgrades. So yeah, for some of them, if they want things to go smoothly and ensure they always have a supported system they really do need a year or more to plan.
Re:Can someone explain the complexity here? (Score:4, Informative)
The problem isn't the OSS packages that come with the system. Those can be and, generally speaking, are all tested by the distro to work with the upgrade. It's the closed-source enterprise software that was built for e.g. RHEL-7, which assumes you have RHEL7's ABI, and all the fundamental choices that went into RHEL7 that may change going to 8.
Among the most obvious changes: rhel-8 is kernel 4.x, not 3.x, and preferring firewalld over iptables. Two of the most important less obvious changes: quantum leap in GCC version (4.9 to 8.x) and therefore ABI especially w.r.t. C++ and changes in network interface naming.
Some proprietary packages - *cough*Matlab - deal with this by basically bringing their own fixed versions of everything they need with them. Matlab for Linux brings everything - its own QT graphical libraries, its own Java, its own BLAS, and yes, its own C/C++ standard libraries even.
Re: (Score:1)
Thanks, that makes perfect sense.
Re: (Score:2)
Slashdot, a place where basic politeness and decency gets modded down. There are some real low-lifes getting mod-points these days.
Re: (Score:2)
There are several reasons for that:
* RH didn't support upgrades between major releases until EL8 (ergo same was for centos). So this feature is relatively new and limited.
* Binary compatibility (being ABI-compatible) with rhel is main feature for derived distros (centos, alma, rocky, oracle, amazon etc). So this is important checklist item during migration.
* Every recent centos-related publications from RH were PR disasters. Every time it looked for community like world ends tomorrow while in reality it alw
Re: (Score:3)
Re: (Score:2)
Very true. Even though I'm just a guy and not an IT organization... all the reasons you listed, are the reason why I finally switched to FreeBSD. I used to *love* RH (prior to Fedora) but they started losing me when they started rolling all the kernel patches into one big file. SystemD was the final nail in the coffin. Much as I love linux and GNU, I really loathe the incessant disruption that comes with forever being in beta. My time is worth more than that nowadays. If that makes me "just a user" then so
Re: (Score:1)
Because ideally there should be no actual reason to upgrade a back-end operating system with a stable application running under it.
There usually isn't a good reason. Continuous iterative improvement serves sysadmins much better, but is rejected by suit-weasels on the vendor side, because that would preclude coming up with idiotic counterproductive synthetic deadlines for "upgrades" that drive their sales numbers. The problem for these assholes is that things like FreeBSD exist, where they do things like major-rev to major-rev updates and actually keep the system stable.
We really need operating system vendors to have a different approach. I mentioned I wouldn't pay for RHEL just because CentOS went away in the previous CentOS article, but never really went into why.
Funny how sticky folks were on RHEL6 (last pre-systemd release with
Re: (Score:2)
Though one thing that can be frustrating about Linux upgrades in general is open source projects really like 'next gening' things between versions, so new or changed AP
Re: (Score:2)
To fully answer your question, one needs to look back to ancient history and certain fixed decisions by Red Hat.
Back in the days there were sometimes Linux kernel releases which were 'good quality' and others with 'poor quality', so Red Hat decided to remain on a certain kernel release an backport drivers and functionality to these old kernels for years and years. The kernel programming mantra is however that it should
Re: (Score:2)
Thankyou. Is rare to see an authoritative answer on Slashdot these days. Thanks for explaining it so clearly.
Groetjes.
And today's lesson is (Score:2)
Re: (Score:1)
Did it?
https://gitlab.com/redhat/cent... [gitlab.com]
Now you can even contribute to RHEL development (which was unimaginable before)
Re: (Score:2)
They do for now, up to 9.2 I think.
The problem is that most likely there won't be any more.
Maybe time to port server software to OCI containers, and GUI software to Flatpaks or AppImages, or, where appropriate, to Web technologies. To minimize dependencies on specific OS versions, at least on the software side. That's kind of what I'm hoping my organization will do. This doesn't solve every problem, but it at least buys those of us on the software development side of things a fighting chance.
Re: (Score:1)
There takes place ongoing development, and RH just recently migrated it on public gitlab. So I see no reason to do this given that they were speaking about closing git.centos.org in favor of gitlab repos and that they gonna make centos development an open process.
Re: (Score:2)
It's no longer a matter of whether I can get source that's close to being compatible with RHEL. I'm 90% confident that Rocky and/or Alma Linux will find a way forward.
It's more a matter that I no longer trust this organization (IBM/Red Hat), and therefore will not knowingly put myself or my employers or clients in the position of having to depend on it.
Re: (Score:2)
Any actual Project78 experience? (Score:2)
Re: (Score:2)
I will see next year (Score:2)
In any case, I have no clue what our future OS version is
Re: (Score:2)
We were in the process of moving from RHEL 6 to CentOS 8 when the IBM-driven disaster of CentOS being destroyed occurred. Not wanting to be trapped, we quickly reconfigured and rolled with AlmaLinux 8 instead.
https://almalinux.org/ [almalinux.org]
Re: (Score:2)
Re: (Score:2)
Like so many others, I'd done some Centos 7 upgrades and got burned by IBM's utterly shambolic handling of Centos. We've switched to Rocky Linux now. Elsewhere I tend to spec Ubuntu if people have nothing at all - although I can't say it's clearly better or worse.
Re: (Score:2)
This is not a problem exclusive to IBM or Red Hat.
It is a problem with big companies being in charge of large portions of the Linux ecosystem.
You risk having Ubuntu pull something similar, especially if IBM/Red Hat get away with this, which seems likely.
But Debian is really the only genuinely noncommercial Linux-based OS with enough mindshare to potentially attract the interest of commercial hardware and software vendors.
I wish we had more alternatives. To be clear, I'm well aware of many of them that work
Adios Red Hat (Score:2)
Re: (Score:2)
>"I have seen what I can only describe as an exodus from Red Hat. Canonical has been the aire apparent. Canonical has been the aire apparent. When you abandon your free open source roots - bad things happen."
And the same signs have been there with Canonical. Perhaps it is better to go straight down to Debian. I use LinuxMint on my desktop precisely because of the nonsense crap Ubuntu does. And Mint is already working on preventing dependence on Canonical's games by creating a new version of LinuxMint
Re: (Score:2)
LMDE isn't exactly new, and you need to remember that basic Mint is Ubuntu with some custom defaults (which with MATE are much better than the normal defaults from Debian/Ubuntu)
What I've settled on for desktops/laptops is pure Debian with the MATE desktop environment, and I boot a Mint Live DVD and export the dconf configuration for MATE and import it into the new system.
Gives me the best of both worlds - good stable OS, decent default desktop configuration/environment
Am I the only one (Score:2)
EOL For Red Hat 7
Re: (Score:2)
Typically environments with thousands of these servers.
For these complex situations, it can take y
Re: (Score:3)
I hope this resolves any confusion.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
The clock is ticking... (Score:2)
My company is in the process migrating from RHEL6 to RHEL7 ...
Re: (Score:2)
My company is in the process migrating from RHEL6 to RHEL7 ...
And I am sure there are many other companies in the same situation. Once done I think your company should look start look elsewhere. I know people are panicking over Rocky/Alma, but I really think they will work out their issues. Maybe even help each other out a bit.
No mention of ELevate? (Score:4, Informative)
This reads a bit like an infomercial for Project78, which is an expensive ($549 per server) presumably closed source software as a service. AlmaLinux's ELevate has existed for longer, is free and open source and can convert to more RHEL clones than Project78 can.
Yes, Project78 probably does a better job than ELevate does, but it's still disappointing that Linux Belgium didn't use their expertise to improve ELevate. Users run RHEL clones to avoid expensive fees, so you feel that Project78 really isn't a feasible option at the high price point they've chosen.
The other downer about the high fee is that it doesn't make it easy to do trial runs like you can with ELevate e.g. take a backup of a CentOS 7 VM image and repeatedly run the original backup through ELevate (maybe writing some pre-upgrade/post-upgrade scripts to handle fixing any non-standard stuff Elevate couldn't handle - I do suspect Project78 might not handle everything, especially if any closed source packages are installed) until you've got the upgrade process smoothly working for your typical customisations (which will mainly revolve around third party software/repos) and you can then apply them to other VMs you need to upgrade.
Re:No mention of ELevate? (Score:4, Informative)
Our Project78 software has a much broader perspective than ELevate. We automatically address issues instead of reporting them. We support third party software and repositories and ensure previous installed non-standard processes and services will be there after the upgrade. We preserve SE Linux state, migrate network settings across multiple reboots, support NFS, CIFS and filesystem encryption aside from working around bugs.
Our dashboard is designed from the perspective of massive enterprise upgrading and aims at large organisations. Our Upgrade-as-a-Service price VM of $259.99 is less than half the price Red Hat Exteneded support will cost yearly after 30th of 2024. And it really provides a high level of value; the cost savings for application teams, infrastructure and sysadmins teamf for these environments is gigantic.
Our fee is not duplicated in the rare case a customer would seek to roll back and upgrade the same machine again later.
Hope that clarifies some of your questions.
Here you can find a technical presentation [youtube.com] giving more insight into how it works.