Their 'support' largely consists of
a) giving ridiculously small and unchangeable /home and /usr partition sizes,
b) randomly logging in at unannounced times to add more logging and monitoring tools in to /home and /usr (then rebooting, also unannounced),
c) sending sporadic emails telling us to clean up our system because we are dangerously low on drive space in /home and /usr.
Got a message the other day stating that they power down our machine in 2 days unless we freed up drive space because 'low drive space can impact system availability and security'. Powering it down also impacts availability, but that point seemed lost on them.
EDIT: Realizing now that ... our RHEL 7 will expire at end of month. We've had 0 communication from them about this. Annoyed because when I'd requested this machine back in 2021, asking for RHEL 8, I was told "we don't officially support that", and now we're going in to EOL territory because of RHEL 7. I'm expecting an "hair on fire" email in early July indicating our machines will be shut down shortly without an immediate upgrade, that we will be forced to do ourselves (because upgrades fall outside 'support').
possible good news is that we'd been forced to use more machines a few years ago due to some IT policy about databases not being colocated on the same physical instance as the application(s) accessing it, which forced multiple servers when fewer were needed. I was told that's not a hard requirement any longer, which may allow us to consolidate some pieces during a rebuild.
A change like this for thousands of bare metal machines, is not inconsequential. The complete inverse is true, in fact.
I'm saying this as someone who fought tooth and nail to migrate to Debian instead of Scientific in 2010 because you can't ever trust a for profit company.
But that was too hard, and what would a grad student know about the real world anyway, so here we are.
Centos 7 was released in 2014 and the support ends next week.
Debian 10 was released in 2019 and the support also ends next week.
However this is where we're now and what we have to go through.
> they deserve what they get.
Why the anger though?
Containers have been a big help.
Upgrading the OS is easy. Initial work is a couple of days, rest of the deployment is an hour or so, but the software we need to run doesn't support CentOS 7+. Containerization might help or not, but most software is distributed as RPM packages and some of them are written with things like Python2.7.
Aside from that, Rocky Linux also seems like a great choice for many: https://rockylinux.org/
Some also say that AlmaLinux is pretty good: https://almalinux.org/
Personally, I found RPM distros to be quite stable but have largely moved over to Ubuntu LTS for servers (technically Debian also has a LTS release, but it’s not as mainstream) and Linux Mint locally (largely Ubuntu without focus on snaps and the Cinnamon desktop is pleasant), it’s been working pretty well so far.
Then again, I run most software in Docker containers, so thankfully underlying OS changes usually aren’t too bad for me to deal with.
Jup for enterprise, OracleLinux it is. I don't like Oracle as any normal person would, but they never did some shady stuff with their Linux, it even works perfectly on a Raspberry PI.
Alma independently manage their updates though, started by Cloudlinux, who are also experts in maintaining EL distros
And the logs. I think it's every 30 minutes or so that "buy Ubuntu advantage" gets logged, you have to disable a systemd timer to get rid of it.
Current job doesn't give me many chances to use linux rn so I'm a bit out of touch. Recently took a look at rocky and it felt like a centos. also tried ubuntu but I recall I had to remove some ads package yeah.
If they don't change their mind, i would not build my business on a promise made by IBM ;)
For people who don't want CentOS Stream, i.e. basically the nightly RHEL builds, the lack of having a versioned CentOS mirroring RHEL versions coming out of Red Hat (for about the last 10 years) puts them in somewhat uncharted waters even if they could pick one of the RHEL alternatives and "probably" be fine.
At first, I thought it was just to reduce the complexity of managing hardening rules for several OS and OS versions.
We'll find a way, though.
8.6 and 9.2 kernels are released more frequently than other streams, if you want more frequent updates for compliance reasons, these are the streams to use.
Not that I am not saying it wasn't a clusterfuck of epic proportions in general.
And IIRC CentOS8 FIPS certificate was taken out by Red Hat (wouldn't have had to implement our own FIPS handling on CentOS7 if not for that move).
https://techstrongitsm.com/itsm-news/suse-offers-lifeline-to...
All they need to do, SUSE’s GM of the Business Critical Linux
team, Rick Spencer, said, is simply change their CentOS 7
update repository to SUSE’s, avoiding any disruptive migrations
or upgrades.
Why would you put your business at the mercy of Oracle?
You don't, if Oracle does something fishy you go to your bank take at least 2500$ and above that, 25$/y/instance and switch to "Liberty" Linux ;)
But comparing the reliability and not giving up on their "Free Enterprise Linux" Oracle (since 2006) [1] is funnily by far the best.
SUSE: openSUSE Leap is dead
RH: Centos (not stream) is dead
Alma: We are Centos-Stream
Rocky: Too early to say anything about longstanding promises
EuroLinux: Pfff
I wish they would add ZFS to it.
This has been a huge problem for me and I only have just about 75 boxes. Only about 15 or so have been converted successfully to RHEL 7.9 since March, none (successfully) to 8.x after that.
1. Convert2rhel has been a nightmare, only a few have worked properly the first time. I've had 8 tickets opened with Redhat. Once I get one working, the next one will fail with different problems.
2. LEAPP from 7.9 to 8.9 hasn't worked successfully yet. When it does it breaks absolutely everything from PHP to mail sending to databases.
3. I thought Alma might solve the problem, nope. Similar issues as point number 2. Or I get Python errors, or any variety of anything else.
I'm not sure what our path is going to be (maybe Tuxcare or Suse or something), but I'm concerned about my job now since I was in charge of this and it's been a disaster. The anxiety is high.
Your boss should understand this, if you are a medium sized company with highly configured boxes (pet style) and have to change major versions, crazy stuff always happens, I can tell you story's (especially firmware and blob related but also cronjobs, "optimized"-shell scripts, to really old php stuff and so on) about upgrades that will drive you to the church before you touch any "dnf upgrade", however that's why i tend for much shorter upgrade times (within 3-5 years).
Customer had highly customized RHEL7 boxes, upgrade to 8 was "terror inducing", and went so far to rebuild nearly the whole infra (about 20 boxes but with really excellent documentation). You are not alone.
This week, the analysis blows up completely, despite nothing changing on the box. And that's just dev systems, I have zero confidence to move any prod systems.
Alternatively maybe they were hitting different mirrors. But in either case, that's not an issue with the distribution.
Now I could have made a mistake, and according to the article text CentOS 7 "isn't EOL yet" so if someone has a mirror that does work I'd be interested to see evidence that kernel updates are even available. I'm not checking myself though, I don't trust Oracle enough to risk spending time standing up a CentOS 7 machine.
IMO, the versioning should follow a pattern of 2024.01, 2025.03, etc.. and updates should be seamless.
As such, the answer to your question is "pretty much everything". Wildly different kernel, libraries, etc.
In theory it would be nice to roll upgrades like you suggest, but there are huge swathes of industry for which it's not a practical solution.
IMO, Stream is just there for testing and no one cares if it works or not.
The leapp-upgrade program had a reproducible bug as late as last week where after every upgrade it inserted net.ifnames=0 into the kernel cmdline. So when the new RHEL 8 system booted up it was using the wrong interface names (eth).
The fix was simply grubby --remove-args="net.ifnames=0" --update-kernel ALL but felt stupid since RH emphasize the interface name change and then they themselves sabotage it for us.
https://linux.slashdot.org/story/24/05/10/2256230/red-hat-an...