I’m sorry but answer to you is probably out of my league; I don’t know which are your needs and what you might find good enough for your choices.
CentOS 6 and 7 were considered good for server environment because were considered stable, reliable, with good support and “fast enough” vulnerability patch. In the trade, older version of packages were considered “necessary” to give better server-side experience and reduce issues.
The opinion is not shared by the whole crowd of users, IPfire dev team pitched quite hard against CentOS 7 stability and reliability.
In my opinion and without due/deep info research, currently CentOS 7 is still popular and used in the world.
But… snap back to reality, here goes gravity, RedHat changed the CentOS/RHEL approach quite hard, nuking out CentOS v8 and shifting the perspective of the distro. Two years passed since.
In my opinion mode On
This shifted completely the approach for CentOS 7 from “keep adopters happy, they will adopt CentOS8” to “no making money here, gonna take a with pinch of salt the changes”. To the point that one of the co-founders of CentOS, Mr Kurtzer, founded Rocky Enterprise Software Foundation and started Rocky Linux project.
Any big or scary enough vulnerability found in any of packages now involv bigger evaluation effort on RedHat side:
- how many RHEL 7 subscribers are affected from this problem?
- How deep enough?
- How’s gonna cost us not patch this one?
- how many RHEL 7 subscribers are gonna migrate to RHEL 9 for this?
Kernel itself is stale to say the least. Patched, backported, with interesting modules baked in to start also in way newer devices than June 2013, but with Sapphire Rapids (Intel Xeon on launchpod) and Genoa (4th gen AMD Epyc released november 2022) I’m confident enough that no one will install CentOS 7 on metal for the deep loss of computational power and safety tricks because the kernel is too old to take fully advantage if every architechtural step happened since 9 years. In fact, install Nethserver 7 on new bare metal is something I stopped to do two years ago (was not the only reason but contributed).
So… for RedHat, any big flaw not patched from the “mother project” is good for decrease the barking and noisy codegrabbers (CentOS 7 adopters) and increase the good drones meaningful of a smears of attention (RHEL 9 subscribers). This is why i don’t feel confident for fast patch backporting or fast package upgrade to long term support from SAMBA.
In my opinion mode Off
I might be completely wrong either!
My evaluation of development team for RHEL7/CentOS7 might too darkly shifted and the size of RHEL 7 might still be large enough to make sense for dev team to be reactive and focused, for avoding a fast and buggy release (log4j 2 style) and provide update package.
(fun fact: the extent of the flaws is not that big as Log4j, but at the end of the year some big hole keeps emerging from the code…)
On the side line, Uwe: are you sure about the “so low” security level of Windows Server?
Doing things “the Redmond way” is not cheap nor perfect, but it’s way safer than it was in 2009 or 2013 (Windows 2008 R2, Windows 2012 R2). In my opinion, lots of Windows sysadmins don’t like to do differently from what “worked in the past” and don’t want to learn new safer ways to do the same things, or do newer and safer things. So they cut out restrictive settings (like change the service user from “limited user” to “system”) and take “out of the way” the restrictive ACLs. The very same thing can be done in Linux if the sysadmin is pissed and skilled enough to deep tweak the way that the distro is built and which can be do in way deeper ways than Windows.
You don’t like Redmond way and prices? It’s fine, your opinion deserve respect. On the other end, for assess the safety of a product IMVHO a nicer level of knowledge should earned. Windows Server images allow still 6 months of evaulation at no cost.