Red Hat Linux 6 End of Maintenance support II has expired (November 2020), Time to migrate to a supported version of RHEL
This post was updated on December 3, 2020
Updated with comments from Red Hatter Jamie Bainbridge
Thanks Jamie
During the Extended Life Phase, technical support is limited. We make a few limitations clear, such as assistance on existing installs only (not new installs), and no investigation of the root cause for unknown issues (so we help with already-known issues only).
To get the level of technical support back to "unlimited" (new installs allowed, new issues allowed) then ELS is required. Even then, we are generally focused on issues that affect production, not low-severity minor things or faults with workarounds.
During the ELP, development support is effectively gone. There are no more errata released.
If ELS is purchased, then we do consider and release errata for very critical issues that are considered on a case-by-case basis. One requires the ELS entitlement to request an errata and to get access to any errata released during the ELS phase.
The minor version doesn't really enter into it. One can call up with a RHEL 6.0 installed on GA day and ask "how do I do this thing?" or report a known problem, and we will assist with it.
Of course, we aren't releasing any fixes for 6.0 anymore. So if a package update is required to solve a problem and that updated package was released during the Full/Maintenance phase, then the package is available. However, if that problem is not fixed yet, then one needs ELS to get any updated ELS package, and one needs ELS to request a problem be fixed.
Generally, we don't want customers to buy ELS under the expectation they will receive anything beyond access to the ELS channel. Definitely don't buy ELS expecting every little problem to be fixed or updates to continue as in the Full/Maint phase. Even with ELS, we may not fix a problem due to technical or other reasons.
I suggest holding off buying ELS until it is needed, and you definitely know your problem will be resolved by the purchase of ELS.
Red Hat Article-Migration and Maintenance Options for Red Hat Enterprise Linux 6 Customers
NOTE: RHEL 6.10 Maintenance Support II expired on Nov 30, 2020
- BE AWARE that **you CAN still buy Extended Lifecycle support, however, why not go to a supported version? But if you have to, it is there.
- Please see relevant comments from both Thomas Jones and also Red Hatter Jamie Bainbridge
See this link by Jamie Bainbridge of Red Hat:
- See this documented on the RHEL lifecycle page.
Red-Hat-Linux-VERSION-6.10 Maintenance Support II has expired (Nov 30, 2020.)
A Red Hat solution article on major upgrade for RHEL 5-to-6 and RHEL 6-to-7 is at https://access.redhat.com/solutions/21964
ABOVE this line is on the topic of Red Hat Linux
BELOW this line is IS FOR CENTOS ONLY.
This reminder is a shameless borrow of this post from the CentOS forums
Don't delay, get migrating today
Please note that CentOS 6 now has less than one year of the end of Maintenance Support II left before Maintenance Support II ends, and the only way to acquire updates after November 2020 is through extended support. The countdown has begun and you should plan to either upgrade/replace your systems with a supported Operating System, or buy extended support or decommission your CentOS 6 machines before that date.
It should be noted that, unlike RHEL, there is no extended support option for CentOS. Once RHEL 6 exceeds Maintenance Support II at the end of November 2020, there will be no further updates for CentOS 6 at all.
IMPORTANT QUOTE
"Any subscriber to ELS is entitled to the source code for the packages which are distributed to them. The SRPMs are available via the Customer Portal, via the yum package manager, or via Satellite/Proxy/etc download of the ELS channel. Theoretically, someone could get the RHEL ELS package source and rebuild it without branding just like CentOS do, with the aim of providing an "even longer life" repo for CentOS. However, nobody in the EL community has done this afaik."
Those using CentOS 6 and requiring more than 1 year of the end of Maintenance Support II are encouraged to investigate the RH extended support program although that will require a migration to RHEL 6 as it does not apply to CentOS 6.
ADDED Oct 28, 2020 There is a very unsupported method with much risk to go from RHEL 5 to RHEL 7 at this link
Also ADDED Oct 28, 2020 This link here shows a method to go from RHEL 7 to RHEL 8. See that link for specifics.
Regards,
RJ
Attachments
Responses
Guru
23293 points
Evaluate the server's role. Prepare a plan to migrate services off of RHEL 6 to a current supported version of RHEL.
- This also applies of course to other non-supported versions of RHEL such as RHEL 5 which reached end of life a while back.
- Evaluate the following: Storage, services, data, databases, users, configurations, SSL certificates AND KEYS.
- Evaluate SAN storage, Raid Arrays, Third Party Software migration
- Evaluate how to instantiate the product of your research in the above steps in a currently supported version of Red Hat
- Acquire funding, additional developers, make a plan present it to your leadership if required, include timeline, an action plan, a timeframe for downtime and plan it soundly
- Execute the plan.
- HIGHLY RECOMMEND building a separate system and migrate to the new one. At minimum, do a clean fresh install. We do not recommend doing an in-place upgrade from one major release to another, even if it is considered possible.
- If someone does use the method to upgrade an existing server from one major release to another, have a solid action plan to test it with "P to V" (physical to virtual, i.e. VMware or other virtualization) FIRST. --- Recommend having an action plan if this form of upgrade fails so you are not left with a service failure. PLEASE PLAN AHEAD.
Regards,
RJ
Guru
35365 points
Hi RJ,
Thank you very much for posting this important information. Very good idea to raise these concerns, hope it helps customers
to accelerate their preparations to move to RHEL 7, or even better, to RHEL 8 as soon as possible - the earlier, the better ... :)
Regards,
Christian
Guru
35365 points
Oh RJ, one thing : You say "Red Hat Linux ..." You sure ? I thought Red Hat Linux was replaced by RHEL "some time" ago. :D :D :D
Hope you don't mind the joke ... :)
To offer a clarification here, our RHEL product is on a different lifecycle to the CentOS open source project. Just because CentOS 6 is End Of Life does not mean RHEL6 is EOL. Quite the opposite actually. Even RHEL4 is not EOL yet :)
RHEL6 ends its "Maintenance Support" development phase on Nov 30 2020, and enters what we call the "Extended Life Phase" (ELP).
During the extended life phase, security and bugfix errata are no longer provided, and technical support is "limited" to usage/config questions and to existing installs where we already know the problem. If a customer encounters a problem we haven't seen before, then we invite them to reproduce on a newer RHEL major version which is not in the ELP such as RHEL8.
There is also a paid add-on product called "Extended Lifecycle Support" (ELS) which adds back a few features during the ELP, such as security and bugfix errata meeting a (very) limited criteria, and troubleshooting of production-affecting issues which we haven't seen before.
As provided above, these are documented on the RHEL lifecycle page: https://access.redhat.com/support/policy/updates/errata
Whilst RHEL6 isn't "End of Life", it definitely isn't getting a high level of support or software repairs so definitely should be evaluated for replacement to a newer RHEL version wherever feasible.
Guru
Community Member
4214 points
All of that is fine and good ...but doesn't help you if you've previously been deploying RHEL via a cloud-subscription (e.g. RHUI on AWS or Azure).
Ah, I'm not familiar with the details of those. Is the RHEL supported by the cloud vendor who has a separate support lifecycle?
Guru
Community Member
4214 points
Red Hat partners with CSPs to provide a VM template. Each of those templates are bound to a CSP-specific repository-service that uses Red Hat's Red Hat Update Infrastructure service. While I suppose it's possible that Red Hat could provide an EUS channel, I have my doubts that Red Hat would bother with providing an EUS channel. Generally speaking, RHUI's available channels are pretty freaking spare (e.g., can't subscribe to the RHN channel that contains gluster).
Ah I see. That's not my strength area at all, but I guess the solution would be to roll ones own image which contains the ELS updates and subscribes to the RHN channels, which does then negate some of the advantage of a cloud-provided RHEL image. Though it's not like an ELS release gets many updates anyway.
Guru
Community Member
4214 points
One uses RHUI for a couple reasons:
- Saves the cost and effort of dealing with licensing, as the entitlements are baked in and paid on an hourly-basis as part of your CSP billing
- Saves the cost an effort of running your own Satellite type service
- Saves having to manage entitlements associated with use of RHN or Satellite (and, especially, entitlement recoveries when replacing instances)
- Saves on the over-buying problem when you implement a demand-scaled architecture (why pay for 24/7/365 worth of entitlements across two dozen systems when you might only run five systems on that term with the rest being "on demand")
That said, I imagine most entities running RHEL in the cloud (vice CentOS or even wholly-different distributions) and using RHUI to support it are less effected by EOL dates since they're probably deployed a dynamic enough solution that ability to (relatively easily) move from one OS-version to the next is sort of "baked in" to their design.
...I just happen to interact with entities that wanted the ease of a RHUI-type solution, even if they're not really well-oriented to making that jump from RHEL6 to RHEL7 or RHEL8.
This isn't really accurate. The EUS and ELS repos are available to be provided by partners using RHUI to deliver content to customers. The question is more: does the partner want to deliver the content or can they modify their billing systems on a per-VM basis to offer the content when the customer requests it. EUS is a thing which is part of all RHEL subscriptions and I think you're rather talking to ELS where a partner would need to charge extra for that "feature" and most cloud providers cannot change billing codes on a per-VM basis on a whim.
Guru
Community Member
4214 points
Thank you for the clarification. None of our RHUI providers had published any indication that they would be providing such extension (at least, not in a way that either directly notified us or that any of our CSP-vendors' project-teams seem to have awareness of).
At any rate, we'd mostly opted to use it as a cudgel towards getting our user-base off of EL6: we stopped making any new, RHUI-bound RHEL 6 (etc.) AMIs or templates last October to encourage people to start making the move off.
Guru
Community Member
4214 points
And I still have AWS tenants that are whining at our team (and AWS support) about things like RHEL6 not working properly on Nitro.
Guru
23293 points
Jamie, Thomas,
I altered the original post. I added clarification for Red Hat's end of Maintenance I and suggested that people read both of your inputs above.
I feel obligated to state here, while I'm a member of the Red Hat Accelerator's group, I am not an employee of Red Hat, and the views are my own. See the official link I placed (just now) in the original post that leads to Red Hat regarding Red Hat's Maintenance Support and so forth. Visit CentOS for CentOS.
REGARDLESS, BE PREPARED AND HAVE AN ACTION PLAN AND ATTEMPT TO PLAN TO TRANSITION SERVERS TO SOMETHING SUPPORTED
Regards,
RJ
Guru
23293 points
Jamie, Thomas,
Let me know if I missed something or need to edit this further. I'll revisit it tomorrow when I'm not in a rush.
Regards,
RJ
All good, the more people who are considering the RHEL lifecycle, the better we all are :)
This comment is incorrect though:
Red Hat will no longer publish source packages for RHEL 6 at this time so CentOS is forced to stop updates.
Any subscriber to ELS is entitled to the source code for the packages which are distributed to them. The SRPMs are available via the Customer Portal, via the yum package manager, or via Satellite/Proxy/etc download of the ELS channel.
Theoretically, someone could get the RHEL ELS package source and rebuild it without branding just like CentOS do, with the aim of providing an "even longer life" repo for CentOS. However, nobody in the EL community has done this afaik.
Guru
23293 points
Jamie, thanks
I made the edit.
Regards,
RJ
Guru
23293 points
Jeffrey Warne,
For the bit you mentioned in the middle of this discussion, is there an article or something I can include? Or is there some specifics you'd like me to add to the original post I started here?
Let me know, I'll make edits as needed,
RJ
Guru
23293 points
Anyone landing at this post... Please do consider some method if at all possible to create a replacement server for anything that is on an older version of RHEL. Consider creative methods to transition a service you've had running on an old system to something that is current. While you can entertain EUS/ELS possibilities, for real survivability, it is better to somehow build a new server to transition the services you care about dearly to a current-day edition of Red Hat Enterprise Linux.
It may take some careful thoughtful transition, but it beats being chained to ancient hardware or older operating systems.
Where possible consider migrating to something new.
Regards,
RJ
You may have seen our recent blog post about several lifecycle changes across Red Hat products.
Just to confirm the above does not change the transition of RHEL6 to its Extended Life Phase on Nov 30 2020.
RHEL6 will continue as planned.
The Extended Lifecycle Support (ELS) Add-On will be available for customers who need it, as discussed in the post and threads above.
Guru
23293 points
Thanks for all the updates you make here and in other places here in the customer forum Jamie.
Regards
RJ
RJ, apologies, another line we noticed:
If you are running RHEL 6.9 or below, that is not even supported unless you purchase Extended Lifecycle Support.
This one needs some clarification too :)
During the Extended Life Phase, technical support is limited. We make a few limitations clear, such as assistance on existing installs only (not new installs), and no investigation of root cause for unknown issues (so we help with already-known issues only).
To get the level of technical support back to "unlimited" (new installs allowed, new issues allowed) then ELS is required. Even then, we are generally focused on issues which affect production, not low-severity minor things or faults with workarounds.
During the ELP, development support is effectively gone. There are no more errata released.
If ELS is purchased, then we do consider and release errata for very critical issues which are considered on a case-by-case basis. One requires the ELS entitlement to request an errata, and to get access to any errata released during the ELS phase.
The minor version doesn't really enter into it. One can call up with a RHEL 6.0 installed on GA day and ask "how do I do this thing?" or report a known problem, and we will assist with it.
Of course, we aren't releasing any fixes for 6.0 anymore. So if a package update is required to solve a problem and that updated package was released during Full/Maintenance phase, then the package is available. However if that problem is not fixed yet, then one needs ELS to get any updated ELS package, and one needs ELS to request a problem be fixed.
Generally we don't want customers to buy ELS under the expectation they will receive anything beyond access to the ELS channel. Definitely don't buy ELS expecting every little problem to be fixed or updates to continue as in the Full/Maint phase. Even with ELS, we may not fix a problem due to technical or other reasons.
I suggest to hold off buying ELS until it is needed, and you definitely know your problem will be resolved by purchase of ELS.
The last thing we want is customers buying ELS then being dissatisfied at the result.
