Comment by cyberpunk | Hacker News Reader

Comment by cyberpunk | Hacker News Reader

I genuinely don't understand why anyone is using rhel or rhel-derived distros anymore.

'we' (and by 'we' -- I can only speak for the small slice of uk/eu companies I've worked at for the last ~18 or so years) were /forced/ to use redhat when running stuff like SAP, IBM WebSphere, Oracle, various terrible BI systems, ERP stuff, and so on for 'support'.

Then the cloud happened, and rhel/centos came along initally as we knew the tools, and we were running mostly the same stuff but on other peoples gear.

Slowly the application estate exploded and now I think it's fair to say we target k8s instead of 'rhel' as the place where our software is running, and rhel and it's brothers go absolutely nowhere near my k8s estate or any I've worked on (typically, ubuntu server nodes if I have to build my own, and alpine for contiainers).

So; people who are upset by the recent developments (and lets be honest, did you expect a thriving community around an IBM product?) -- why? What's rhel got that debian doesn't? Or ubuntu?

I'm not even a user of rhel but the difference is: security patches. Enterprise uses rhel because they fix or triage nearly every vuln, every time. If you work for a company with extremely stringent security requirements, or sell to government entities, rhel and its derivatives (CentOS/Amazon Linux 2, etc) are basically the only way you can clear their requirements.

Debian (and by extension, Ubuntu) chooses to not fix a significant amount of security issues. This makes sense given their business models, but is an unworkable position for a huge number of enterprises that depend on Linux. Example: https://ubuntu.com/security/CVE-2021-45464

I work for a eu government with extremely high security requirements (in the national identity / IDP / health space).

We actually _CANNOT_ use redhat for compliance reasons.

(We're using ubuntu LTS as it goes)

Why? What compliance reasons make Ubuntu LTS work and RHEL not work?

Stupid auditors/pentesters really. Explained a bit in another comment, but essentially we had to explain the concept of backporting cve fixes to the same 'version' of random libs to the auditors and to get certified we would have to demonstrate, with actual source, that each of ~200 or so cve's were fixed in various system parts (individually).

In the end, we just went with ubuntu for those nodes, and they all passed the certification. Shrug.

Since then, we don't even need the OS to be certified, since we are using confidential computing, and we stuck with ubuntu for our k8s nodes etc -- but we are forbidden from using rhel anywhere by our legal / compliance people now.

The issue here is with your auditors. I mean if RH tells you a CVE has been fixed with a backport, sure you can challenge that fact but at the same time and with the same standards, it'd mean your auditor would also have to check the actual source of your patched Ubuntu packages to make sure the new versions fixed the security bugs.

The bottom line really is plenty of auditors I've seen don't know how to check for vulnerabilities other than by checking a version... That's it.. Their tools or reporting only know package must have a version greater than x.y.z.

What about SUSE/OpenSUSE? Surely that would've gotten the green light?

That, and if you need to run some COTS (commercial off-the-shelf) software package chances are the vendor will only support it on RHEL (or CentOS). However, many of these vendors also support Ubuntu LTS or Suse Enterprise now so there are (usually) a couple of Linux-based alternatives.

>What's rhel got that debian doesn't? Or ubuntu?

Short version:

https://access.redhat.com/support/policy/updates/errata

https://catalog.redhat.com/hardware/search?type=Server

So LTS support and ... runs on everything the linux kernel does? I don't understand your answer, that is nothing you can't get elsewhere ?

The Linux kernel is not the point. The point is that RHEL has what you need to make sure that the P440ar Smart Array Controller in your HPE DL360 G9 still works properly and that the package from HPE that supplies the runtime tools for it works, along with the utilities that allow you to upgrade your iLO firmware etc. and will qualify that configuration across OS versions and releases.

Ah fair point, random(ish) vendor crapware utilities like that surely work better on rhel. Client libs for HSMs spring to mind too. Fortunately, not many of us are running bare metal anymore. Do you think it make any sense to use in 'the cloud' though?

I know why they use RHEL - support is apparently good and not every corpo wants to keep some linux experts on payroll to fix the rare issues that need a bit more expertise. And they keep old versiond of Red Hat updated for longer so you old crusty enterprise garbage can stay garbage few years longer and claim "but OS is updated" in audit.

I have no idea who in their right mind would use derivative, it has zero benefits and is just build worse than vanilla Debian.

Funny; our RHEL systems were a nightmare for compliance actually. Most of the tools the auditor/pentester type people use only search for, (completely fake example) libfoo 1.x.2 having a security hole, and redhat's libfoo 1.x.2-wibble13 even though it has a backported fix, is flagged as vulnerable.

For each one of these packages, it's a crazy process to prove that the CVE they reported isn't actually there, and it delays our accreditation to the point where it was easier for us to change distro than go thorough hundreds of these..

t.b.h. all this tells me is that your pentesters are bad.

Bingo. We don't get to choose them, though, and they hold the strings on the certifications that our business needs. Sometimes it's easier to bend.

If they make a claim that some package has CVE and you can demonstrate that to be false as per official distro changelogs etc they can go hike.

The problem is that if they don't fix the tool, you'll get to tell them that every week (or however often they scan).

Dealing with bad security audits isn't fun.

You used to pay Red Hat, did you try passing them the hot potato?

Pretty much but that's my experience as well, I made the same comment above...

Perhaps auditing tools should do something better than just comparing version numbers as released by upstream?

Maybe Ubuntu LTS does less security backports than RHEL, but that doesn't make it better per se (saying this as an Ubuntu user).

In the web hosting world, RHEL and its downstreams like CentOS (7 is still in use... just had to spin up a server for a customer with it a few days ago) Alma, Rocky, etc. are still king. Especially with software like cPanel, which exclusively works with Alma (previously, exclusively CentOS). Getting people to even upgrade to Alma 8 is enough of a pain, I don't see why any of these folks would move away from cPanel/Alma now.

Canonical is a shit company, way shittier than RedHat. Use Tumbleweed and be done with it :)

Red hat does have a k8s product, right? It seems to be used by many cloud companies to offer kubernetes service.

https://www.redhat.com/en/technologies/cloud-computing/opens...

I honestly thought distro wars were a thing of the past and settled a decade ago.

And by settled I mean "who cares as long as it's not Windows?".

Reply on news.ycombinator.com