Enterprise misery
Enterprise misery
30 comments
-
-
Rhel 5? I hope y'all are using microsegmentation and have a good firewall.....JFC
-
IT installed a firewall between the legacy environment and everything else. Devs threw a fit and so the firewall was configured with a default allow rule. Security was last seen crying into their beer.
-
Unsupported versions are unsupported.
-
mission critical, but not enough to warrant a budget for redundancy.
-
Weird how that works...
-
-
You aren't using a EOL system in production right? If you are it better be air gapped. The last thing we need is more zombie machines for the botnets.
-
"What do you mean? That's the clinical best practise!!" - Siemens healthcare/Philips or any other medical vendor
(and I'm not talking about air gaps!)
-
Air gapped but my dad recently upgraded a RHEL 3
Still working on getting the okay to upgrade the XP machines
-
-
It might be time to upgrade
-
Some manufacturers machines still run dos
-
HPC? Fuck we can't change shit in HPC. We tried a few times... Some sites appear manage it, but tend to forget a few dozen systems.
-
I understand how it feels.
-
30 comments
RHEL 7 and RHEL 5 need to be flipped in your meme.
Any large enterprise still running RHEL 5 in Prod (or even, yes, older RHEL versions) has fully accepted the risks and will grumble about supporting it, but go forward with whatever workarounds are necessary to keep the application running on it running. The RHEL 7 folks, however, are modern enough that the answer for any problem is "Upgrade to RHEL 9, because we know you can with some effort, because we don't want to waste time on supporting something you should be able to upgrade away from".
This is the game of chicken in a modern enterprise for app teams. If their application is critical enough to business continuity and they remain on RHEL 7 long enough, they too will join the select few applications in the org that either get a cash injection for an application rewrite to modern RHEL 9 or be enshrined next to the RHEL 5 apps still running with grumbling, but continued support.
In a perfect world these EOL unsupported OSes should be retired and replaced with modern supported version, but we're talking about reality now which is what the modern enterprise is, and which is far far from the perfect world.
What's blowing my mind about this entire thread is the "rewrite application to support RHEL9" thing I keep seeing. What the fuck applications are y'all running that are so tightly bound to the OS that they can't handle library and/or kernel updates?
That's what I'm thinking too but then remember my first corporate job where the application depended on an exact subversion of Java 8, no earlier and no later. This was in 2021. Knowing that company I'd bet they're still rocking the same setup.
Most of the time I've run into this its COTS software and the customer refuses to pay for the cost of the updated version or the company that wrote the original COTS application is long since out of business.
It is more like 'involuntarily end up riding the risks of using unsupported old software'. RHEL 7 and RHEL 5 are in the right order.
RHEL sells an unrealistic expectation that you don't need to worry about the OS for another 10 years, so the enterprise gets designed around it and becomes unable to handle an OS upgrade, ever.
Involuntarily? An org choosing to use an EOL OS to keep running an application is a business choice that accepts the risk of compromise/lack of support of an EOL OS. Any org in this situation has 3 choices:
There's nothing involuntary here.