Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Red Hat Software

EOL For Red Hat 7 and CentOS 7 In 1 Year and a Week (redhat.com) 53

Posted by EditorDavid from the final-countdown dept.
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.
This discussion has been archived. No new comments can be posted.

EOL For Red Hat 7 and CentOS 7 In 1 Year and a Week More

EOL For Red Hat 7 and CentOS 7 In 1 Year and a Week

Comments Filter:

  • We're done with RedHat. (Score:1)

    by Anonymous Coward

    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.

  • Can someone explain the complexity here? (Score:3)

    by thegarbz ( 1787294 ) on Sunday June 25, 2023 @12:39PM (#63631206)

    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?

    • Going from Upstart to Systemd (6 to 7) was not an inplace upgrade. Its was as systemic of a change as a.out -> elf -> glibc 6. Centos8 went EOL before 7, in favor of a constant revolving door of prototype packages reminiscent of Fedora. However Oracle decided to keep maintaining patches for packages past the EOL. So admins did have the option to keep running 6 via Oracle Linux update repositories.

      • 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.

      • 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

        • To some extent. All the upstart scripts in init.d would fail to launch on boot in systemd. So if your server was a specific role (like say your phone system) you would also have to recompile from source to install the correct startup scripts. RHEL (and by proxy centos) had no upgrade path that did not involve really a fresh install and migration. For a phone system security patches are all you really need to concern yourself with. Most distribution services are disabled or blocked with iptables rules. New

    • 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)

        by Bretski ( 312912 )
        True. Enterprises many times want to focus their resources on their business instead of hiring hackers to run the infrastructure. For a one-time upgrade, I could see paying for this instead of hiring smarter, harder-to-find, more expensive people.

    • Re:Can someone explain the complexity here? (Score:5, Informative)

      by quantaman ( 517394 ) on Sunday June 25, 2023 @02:23PM (#63631402)

      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)

      by zeeky boogy doog ( 8381659 ) on Sunday June 25, 2023 @02:37PM (#63631426)
      There's a difference between "it pretty much works when I run 'do-release-upgrade'" and "it's guaranteed that this system will work after we upgrade it." The difference is more apparent when you depend on the system to earn millions or billions of dollars a year.

      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.

    • 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

    • Comment removed based on user account deletion

      • 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

      • 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)

      by jythie ( 914043 )
      In all honestly, upgrading RHEL is not generally, but any enterprise upgrade fits the '95% boredom and 5% sheer terror' saying pretty well. Most of it goes really well, but along with the OS upgrade a lot of tools and applications also upgrade, which means there are always little differences that could impact mission critical functionality.

      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
    • I'm Jasper Nuyens, CEO of Linux Belgium who create this Project78 Upgrade-as-a-Service.

      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

      • Thankyou. Is rare to see an authoritative answer on Slashdot these days. Thanks for explaining it so clearly.

        Groetjes.

  • You should always have a backup plan. Will IBM/Red Hat turn off the faucet of open source software? Could happen. Oh, it did happen. Either pay up or plan B.

    • Did it?
      https://gitlab.com/redhat/cent... [gitlab.com]
      Now you can even contribute to RHEL development (which was unimaginable before)

      • CentOS Stream is useless garbage nobody cares about. It's whole purpose was to alienate CentOS for good and it's succeeded wonderfully. They wanted to make sure folks didn't have a quick and easy actually-free alternative to specific RHEL major releases (like CentOS 6 was for RHEL6). So, folks realized that Oracle Enterprise Linux has pretty much taken that role along with others like Rocky Linux. Neither of those two require licenses for every installation. Instead, you pay for what you want support on. Re
  • So does anyone have actual experience with Project78? Beyond using LEAPP?
    • Hi Felix, aside from our pre-release customers, there is no independent review yet. There is the technical presentation [youtube.com] and some dry course material, but if you want to make an independent review, please do so. PM me at: jnuyens@linuxbe.com
  • The company I work for uses CentOs7 right now. We are forced to use RHEL or CentOs because of the specialized software we are paying top dollar for. So it is a big deal for us. We went from physical workstations using RHEL6 to virtualized machines using CentOs7, and the migration was not great from the user point of view. Licensing under virtual machines may have been a factor here, or maybe it is a cost saving measure - I am not part of IT after all.

    In any case, I have no clue what our future OS version is

    • 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]

      • Right on. We had a similar situation where we'd already switched 100% of our infrastructure machines from RHEL6 to FreeBSD. The rolling updates in FreeBSD have worked great and we've stalked from four major rev, quite easily since the Systemd coup in 2015. By the time IBM bought Red Hat and turned the screws on CentOS, we'd ghosted them for FreeBSD completely. A few systems that needed to be Linux for some reason we converted to Oracle's OEL. Red Hat was pissed. They threatened a license audit and we wrote

    • 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.

      • 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

  • Not professionally (very large tech company), personally, and in community (open source projects, makerspace, etc). I have seen what I can only describe as an exodus from Red Hat. Canonical has been the aire apparent. When you abandon your free open source roots - bad things happen.

    • >"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

      • 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

  • I only got through:

    EOL For Red Hat 7

    ... and my first thought was "did someone forget to do this a decade ago?" [redhat.com]

    • The standard way to upgrade, used by many big companies, is to manually create new VMs, transfer all data, reinstall applications, reconfigure the applications and verify everything. This can be very challenging in large complex environments where servers have been set up years ago and where application maintainers or sysadmins just aren't aware anymore about whats running and what potential implications are.

      Typically environments with thousands of these servers.

      For these complex situations, it can take y

      • I'm not really sure what post you read, but I was referring to the fact that the title of the post just says "Red Hat 7", which can be confused with the Red Hat Linux 7 that was released in 2000, as opposed to Red Hat Enterprise Linux 7, which was released in 2014. Hence the link to Red Hat's guide for Red Hat Linux 7, which again is not the release this story is about.

        I hope this resolves any confusion.
        • Hehe, I often remind these new Linux children that Red Hat has done their version progression TWICE. Few remember it. You are quite correct that Red Hat Linux 7 is not the same as Red Hat Enterprise Linux 7. It's not pedantic, either, it's history.
          • Red Hat 5.0 (I think) was the first Linux distro I tried out. I think I still have the book it came with, buried in a box somewhere. It was the first meaningful exposure I had to a non-MS operating system. Red Hat may be a Big Blue abomination now, but it will always be a pleasant memory to me.

  • My company is in the process migrating from RHEL6 to RHEL7 ...

    • Re: (Score:2)

      by jmccue ( 834797 )

      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)

    by rklrkl ( 554527 ) on Monday June 26, 2023 @01:33AM (#63632632) Homepage

    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)

      by internet-redstar ( 552612 ) on Monday June 26, 2023 @05:29AM (#63632946) Homepage
      Thanks for your feedback. We as Linux Belgium are very much committed to the opensource ecosystem - obviously. And in one of the 2 upgrade methods we provide, we integrate ELevate as one of the many components to upgrade CentOS7 to Rocky Linux 8. We are in contact with Alma Linux too and plan to become a sponsor of the project, as we already contribute to other Free and OpenSource projects.

      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.

Slashdot Top Deals

If all else fails, lower your standards.

Close