Hacker News new | past | comments | ask | show | jobs | submit login

Some of us are forced by edict/policy to RHEL-only. I'm doing work for a client whose IT dept requires it, because it's all they 'support'.

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').




That all sounds like a reason to polish up the resume.


Only 5% of my work - I don't deal with them but a few times per year. I'm constantly confounded by how difficult they make relatively simple things, compared to other clients/projects I work with. But... this is dealing with state government. There are definitely sharp people that work in state govt - not dumping on all of them. But... this dept's incentives don't typically align with most others, and there's generally little that can be done about it. My eyes water when I see what my project is required to pay for this, relative to the 'support' we get.


Sort of does. Can't imagine it's a typical experience and makes me wonder what's so unusual in this case. There are always bad experiences with support but usually systematic tire fires indicate some other issues.


if you are going to stay, don't update to 8. Update to 9. Any 'significant' fixes you need fixed for 8 wont be possible in this stage of life and only 9 fits that requirement.


at this point, it will probably have to be a rebuild of a few machines - i'm not sure we can jump from 7->9 in an automated way (is it possible?) and i'm unsure how we'd recover if there was a hiccup in that process.

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.


I"m not sure how mature the LEAPP program is, but you could always simplify the process by running your apps in an el7 container for the initial migration while you ensure the rest of userspace catches up/adequately tested.


Interesting thought. I may consider that as a fallback approach if we hit any issues. Thanks.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: