I've got a CentOS 7 server, and it's pretty much EOL now. So I've got to move to a new server in the next few months. I'm thinking that I'll get Rocky Linux, I like what I'm hearing about the way they are going to be managing their kernels, using upstream instead of 87 million patch levels. That vendor approach of patching the Hell out of old kernels isn't ideal either, it can have bugs and run like shit when they keep sewing arms onto that old octopus.
RHEL stays fresh with 9.4 while CentOS 7 gets a Rocky retirement plan
Good news for users of RHEL versions old and new – and for the freebie CentOS Linux 7, which is approaching its end of life next month. Red Hat Enterprise Linux 9.4 is out, and the IBM subsidiary is also offering an extension of support for the aging RHEL 7 released way back in 2014. Alma Linux 9.4 is still in beta, but if …
COMMENTS
-
-
Saturday 4th May 2024 10:42 GMT Bebu
Have a look at AL8.9
I've got a CentOS 7 server, and it's pretty much EOL now. So I've got to move to a new server in the next few months. I'm thinking that I'll get Rocky Linux, I like what I'm hearing about the way they are going to be managing their kernels, using upstream instead of 87 million patch levels. That vendor approach of patching the Hell out of old kernels isn't ideal either, it can have bugs and run like shit when they keep sewing arms onto that old octopus.
I moved my collection of Centos 7, RHEL7 &c machines (& VMs) to Almalinux 8.8 (now 8.9) a while ago and the migration was fairly painless. Apart from recently unsupported devices (LSI SAS HBAs mp3sas) which was fairly easily remedied, rather unremarkable.
My guess is that Alma might start offering more recent stable kernels as an optional stream.
The kernel shipped with aarch64 AL8.9 is 6.1.x which works an RPI 4 (not 5), but also works with the 6.6.x kernel (and modules etc) from Raspberry Pi OS on a RPi 5 - a Frankenkernel Debian bookworm/EL8 Chimera.
So I would imagine that within reason substituting later kernels isn't that problematic - as long as the glibc and runtime loader is compatible with the kernel, I suspect the worst you might get is an ENOSYS.
The main loss is that the hardware that RH has certified their kernel against won't be certified with a newer kernel.
Not that very different from running a EL8 application in a Podman container on an EL9 host.
Springdale (formerly Princeton) Linux offers EL8 and EL9 network install ISOs and pxe images but its not obvious to me what their upstream distro is.
Their repositories of EL compatible scientific software can be a real timesaver for the overworked BOFH. :)
-
Saturday 4th May 2024 16:15 GMT Grogan
Re: Have a look at AL8.9
I used to build my own kernels on servers, but things got more complex and it wasn't worth the risk of having to coach some datacenter flunky at 4AM on how to go to the machine, hit the down arrow twice and hit enter to avoid having to connect a display etc. You might get a pass for that a few times, but they don't have a lot of patience for it. Distro kernels are silly now, with what they do in the initramfs and all. I could actually get back to doing that again though, as I've got VPN+IPMI console access with this host in case of any fuckery. I remember the first server kernel I messed up, it was Redhat 7.0 (not RHEL, which didn't exist yet). The way the init scripts worked back then was that network initialization was tied to loading the NIC module. I'm a "build everything important right in" kind of guy, and the network didn't come up. I had to call to get the previous kernel rebooted and rebuild with the NIC as a module.
I don't care about certification and my hardware won't be anything exotic, Xeon CPU, Intel chipset, AHCI SATA etc. standard fare.
The main role of that server is a mail server, web site for a self-employment type business, and a forum.
Alma would be an option too. I'm also considering Ubuntu (don't like it, but I could work with that on a server). I'm a bit limited by what the datacenter will put on there. I also probably intend to use Cpanel, because I'm getting old and lazy.
-
Saturday 4th May 2024 18:19 GMT Steve Davies 3
Re: Building your own kernel
Back in the day... a long, long time ago, the RHCE exam included building the kernel. Those were fun days.
I've used both Alma and Rocky Linux on my servers and have not found much difference between them. There were bigger issues at play when I was trialing them... SNAP [boo hiss]
Thankfully, the certbot people now provide and RPM in one of the optional repos.
BTW, my servers are Intel NUC sizes boxes with an i3 or i5 (or AMD equivalent). Quiet and does not drink power like its going out of fashion.
-
-
Sunday 5th May 2024 06:43 GMT Richard Lloyd
Re: Have a look at AL8.9
ELrepo have a "kernel-ml" repo containing the latest stable kernel.org kernel for RHEL family distros. I wouldn't recommend it for production servers simply because it will have had far less user testing in an RHEL-based distro than that distro's own kernel. I did use it when I ran CentOS and AlmaLinux on my home desktop, but that was so I could get the latest kernel advances for gaming. Nowadays, I'm using Fedora 40 (with KDE Plasma 6/Wayland) on my desktop, which has a recent kernel and a lot more desktop users while still being in the Red Hat family and it's great for gaming.
-
-
Monday 6th May 2024 15:43 GMT chasil
Oracle Linux 7 - support until 12/2024
With the proviso "Expect no new version/functionality upgrades, only critical and security related fixes," Oracle will provide another six months of critical RPMs.
https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf
Oracle's UEK has much of the the hardware support that is removed from RHEL kernels, plus btrfs.
Login required for this link:
https://community.oracle.com/mosc/discussion/4546696/announcement-oracle-linux-7-premier-support-extended-from-jul-2024-to-dec-2024
-
-
Saturday 4th May 2024 15:47 GMT Anonymous Coward
If your pesky liveware has proved fond of working from home and doesn't want to return to the unpleasantly expensive office buildings you rent, why not jettison the humans and replace them with server farms full of LLM bots?
That appears to be on the roadmap for at least one large PC manufacturer. They've got a pile of buildings from a previous acquisition and no clue what to do with them. Their mandated return-to-office is falling over like a kicked anthill, so they're pushing "Artificial Intelligence" for all it's worth. Support's already getting trimmed and Engineering's doubtless next, as the bots work their occasionally correct and often useless magic. But AI's the flavor of the month, so it's gotta be right.
-
Tuesday 7th May 2024 05:14 GMT Mike Pellatt
Maybe it's time to look at the RHL family again
Before containerisation in all its flavours took the world over, RH's abandonment of in-place version upgrades, along with the more-bleeding-edge-but-still-supported approach of Ubuntu, was the tipping point that drove me from the RedHat family (where I'd been since RedHat version 2, or maybe even 1) over into Debian land.
Recent dallying in the world of fibre telco OSS/BSS pushed me back into the RHL world and now that ELevate tool may make me look even more closely.
But..... GPL purity keeps me thinking Debian (and the decades have demonstrated that GPL purity IS a good thing - and at least in the Debian world, with Ubuntu you can dip in and out :-) )
-
Saturday 11th May 2024 17:50 GMT Henry Wertz 1
No in place upgrades
The lack of in place upgrades sounds shocking to me?
But, on the other hand, the release pace of Red Hat Enterprise Linux versions is SO slow, the included software is SO old that every CentOS 7 setup I saw (I must admit I haven't seen any actually running RHEL) would have like non-standard PHP, Python, etc. installed since the included ones were far too old to run whatever workload they were actually wanting to run on them. I'll not some distros do "rolling release" so it's continuous updates; and the likes of Ubuntu it's a release every 2 years -- they DO NOT support a direct upgrade from like 14.04 (2014 release) to 24.04 (current), you would be expected to upgrade to 16.04, 18.04, 20.04, 22.04, then 22.04. (The various packages include scripts to try to deal with config file changes etc. going back 1 major release, but not necessarily any further.) RHEL could "probably" have done something like that to deal with upgrades from one RHEL version to the next on a totally stock config, although updating to a 5-10 year newer version there'd be a lot more to fix up. When you've had someone installing add-on packages from outside the main repo, customizing things however they wish. AND you have this expectation from the Enterprise distros of never having any rude surprises? I can see them saying they just don't support it.
After all, if the stuff YOU installed is fairly cleanly seperated, it's fairly cleanly seperated, you could back it up, install current RHEL, put your stuff back and get it to run on startup, If it's all intertwined then it's HIGHLY likely something would break and require manual intervention anyway when you're upgrading to like 10 year newer versions of the software.