CentOS Linux 8 Reaches End-of-Life
phoronix.com
phoronix.com
Then in December 2020, RedHat announced the end-of-life was moved back to December 2021.
Yes: changing the support lifetime of the operating system from 10 years to 1 year.
We've begun the process of switching out from CentOS to Amazon Linux at work, and the jump actually hasn't been difficult - the tooling is largely the same, boot times are vastly improved (I don't really know what Amazon does under the hood to their Linux distro, but it does show), and with minor changes to some Ansible bootstrap code, we're up and running. Besides, most everything is containers nowadays.
My homelab has come full circle - it started out on Debian back in the 2000s (it was the only distro left with a floppy installer, and I had a few Pentium-class laptops). These days it's a shelf full of single-board computers, and I've found the support for Debian types like Raspbian/Armbian to be _much_ improved over CentOS, whose ARM32 special interest group was but a handful of people volunteering their spare time.
What have others been migrating to?
If it's on AWS hardware I assume they've extremely trimmed down any and all kernel gubbins that isn't related to the hardware they run on?
As for our migration plans... Well luckily we're on CentOS 7, so I have a year or so more to figure that one out and see what way the wind blows. Timings good enough to do a hardware refresh at the same time.
Kinda worried for Ansible to be completely honest. I've grown to love it for automating a bunch of sysadmin tasks and managing some stuff at work and my own kit, It's been a nice way to spin up dev boxes w/o going down the whole Kube/Container stack when a VM suffices. Don't really trust RedHat anymore with it if IBM is pushing it's corporate culture down on them.
Unbeknownst to many, you can run AmazonLinux on-prem[0], AWS distributes their image on a public pages (we use this to allow developers to have the same image locally and on the cloud).
Additionally, you can export any AMI to a S3 bucket[1] and download that for local use.
0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
1: https://docs.aws.amazon.com/vm-import/latest/userguide/vmexp...
For on-Prem you may actually use this, so we don’t build it in there.
My home servers only last about a year or two before i need to tinker & change things. I don’t need 5 yrs of lts support in the OS - 2 yrs of fedora is fine.
We use rhel at work & have always paid for the licenses.
I've been using Fedora for years with good success and these days everything runs in a container, so rpm-ostree and a mostly read-only filesystem simplifies maintenance.
If Fedora is too "bleeding edge", but you want to stay in the RHEL ecosystem, you might try CentOS Stream for yourself to decide whether it feels solid enough to rollout, it is the direction Red Hat wants folks to lean toward, though not necessarily the one many are interested in taking.
Your homelab experiences with SBC seems to validate my position.
The only use I have for CentOS is to compile Ventoy
You can also get extended support for CentOS 7 and 8 from CloudLinux.
We tried using Fedora as our main distro, but it just moved too fast. We never got on the Ubuntu wagon, mostly because we were so comfortable in the RedHat world.
To be clear, CentOS Stream won't get any updates that RHEL doesn't get (including kernel updates), it'll just get them a few months sooner.
But the more streamlined and open development process may allow RHEL (+derivatives) to move a little faster, and get bugs fixed sooner. It's still too early to tell though.
The bug level or not of CentOS was not its selling point, but compatibility:
> Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®.
* https://en.wikipedia.org/wiki/Bug_compatibility
If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
Here's an example: about a half year ago the host of linuxunplugged.com (a pretty popular podcast IMO) invited representatives both from Alma Linux and from Rocky Linux. The Alma guy was happy to be on the show and showed up a few hours before it started to chat with community members. The Rocky guy asked if any other distributions will be there, and then sent a passive-aggressive email where he declined to participate because "we're not interested in being compared against other distributions", or something to that extent.
This small example pretty much sums up their entire attitude.
FWIW, I've been using https://almalinux.org for the past few months on a couple of dozen servers and it's been smooth sailing.
(I've also been using Oracle Linux and it too worked fine. If only it were not Oracle…)
I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you.
If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case.
What am I missing?
Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes.
And even these changes may need to be triaged to determine if the updates are even worth risking uptime.
One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.
And I'd probably describe it as less of a "bleeding-edge" rolling release, more a "boring-edge" rolling release. Yes it's a rolling release, but packages are going in as a final shakedown before release into RHEL, so it's really quite far away from experimental.
And I've not really noticed any material difference from pre-stream. I'm still able to use my CentOS boxes in the same way as I did before - in some cases as build boxes for things to be deployed onto RHEL boxes.
(And, to be honest, those example use cases are probably places where I would be seeking to use a commercially supported distribution, rather than a community supported one. Albeit a community supported distribution that copies/replicates a commercially supported distribution.)
From RedHat's announcement blog and Centos website: CentOS Stream "a continuously delivered distribution that tracks just ahead of Red Hat Enterprise Linux".
And indeed, I have read that all packages currently going into Stream 8 follow exactly the same testing and validation procedures than for entering Redhat Proper.
But of course, this holds true only for released RedHat versions. Meaning that Stream 8, is currently just ahead of RedHat 8.5 and will soon start to incorporate changes planned for 8.6 (so nothing like a "bleeding-edge test environment to test new changes" as you put it).
As for Stream 9 which was release recently, it is indeed the stabilisation socle based on fedora 34 that will eventually become RedHat 9. Once RedHat 9 released, Stream 9 branch will be stabilized and once again be "just ahead" of the impending RedHat 9 rpms.
In any case, I am not sure that hospitals should be running/updating self supported OS on surgical equipments without proper testing anyway.
Stream 9 is currently tracking RHEL 9.0, it shifted from the 9.0 Beta back around August. As we approach the ~May release for RHEL 9.0 GA, Stream 9 will start tracking RHEL 9.1 changes.
A key difference between Stream 8 and Stream 9 is the way the distribution is built. Stream 8 is a technically another rebuild project by the CentOS team, but one that rebuilds newer branch packages from RHEL engineering. In Stream 9, RHEL engineers are doing the builds themselves and are directly involved in the entire process.
There's a possibility that Stream 8 may adopt the Stream 9 workflow, but I'm not certain. With an EOL of 2024, it might not be considered a priority.
That was 2014; if this was the original plan, they took their sweet time with it.
Red Hat also offered a conversion procedure the last time I looked, but it replaced every installed RPM with equivalents from its own repositories. This is quite violent, and it would be far from my first choice for a critical system.
The whole point of CentOS was to be 100% compatible with RHEL, right down to the packages and binaries. For literally this kind of scenario. I don't see how that's "violent." I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
The code is the same, yes. The "binaries" are not, necessarily. The build environment isn't exactly the same and there have been bugs experienced in CentOS that weren't in RHEL and vice versa.
So it was never 100% compatible, more like 99.5%. The exceptions are rare edge cases but they do exist.
The thing is, they were almost exactly the same distro, so in any meaningful sense you could switch from one to the other by switching the release files, some yum support stuff, I think the kernel?, and some miscellaneous branding if you cared. But 99% of packages were functionally the same, so yeah I don't see replacement being a problem per se, but it also didn't seem very necessary.
In my experience major updates like this are discussed annually with eval, testing, and milestones set weeks and months apart. The transitions are often pushed a year or more when issues come up. Resources are dedicated to all of this.
It sounds like there are a lot of similar options with relatively easy transitions (away from Red Hat), but you still have to choose who you trust going forward and carryout the transition.
Sorry not sorry, but large outfits expecting to coast on a free offering don’t get sympathy from me.
That's why working at FB or Google is like going back in time as far as monitoring UIs, etc.
Some of the clever large companies took advantage of "site-wide support licenses." For example, Netflix paid MySQL AB $40,000/year for MySQL site support so they didn't have to hire any MySQL DBAs. Just keep filing support tickets. :)