Are you auto-deploying OS updates for Windows and Linux servers?
Posted by FatBook-Air@reddit | sysadmin | View on Reddit | 14 comments
Back in 2019, we enabled automatic updates for Windows Servers. It has a 14-day deferral, and we update once per week. We have an update ring that automatically updates with a 3-day deferral for test machines and low-risk production machines. To my knowledge, we have run into only one significant issue that was a direct result of OS updates and was not caught in the 3-day deferral ring.
Last year, we deployed automatic updates for Linux servers (most are Rocky Linux and RHEL, and all are minimal installs with no GUI). It updates weekly. It prunes all kernels except the current one plus two older ones.
We do *not* currently auto-update most app software running on top of the OS. (There are a few we do, but we actually *have* been burned here.)
-
Are you automatically updating your server operating systems?
-
Is anyone aware of an official way to defer Linux updates? Is it even worth doing?
TerrificVixen5693@reddit
I don’t know how you’re living without patching rings in 2026. If you aren’t doing that it must be stuck in 2006.
FatBook-Air@reddit (OP)
Be honest. Did you bother reading the OP at all?
TerrificVixen5693@reddit
What about my comment confused you exactly?
FatBook-Air@reddit (OP)
So you didn't. Got it.
TerrificVixen5693@reddit
My man, I read it and understood that you are doing patching rings but do not auto update dependencies.
I’m saying I can’t imagine enterprise wouldn’t be doing this in 2026.
What’s with the attitude?
FatBook-Air@reddit (OP)
You started by making a snarky ass comment without reading the OP, and you're asking me what's with the attitude? I'm just gonna block you.
spyingwind@reddit
The package
dnf-automatichandles applying updates.RHEL 9 Documentation for dnf-automatic
FatBook-Air@reddit (OP)
That Red Hat document is mainly about automating updates with dnf-automatic and controlling when they run, not delaying specific updates for a deferral period.
Ssakaa@reddit
Satellite. And depends on your risk appetite. If you can take prod catching a patch that's been out 30 minutes and has barely been tested in the real world, go for it...
kilkenny99@reddit
Was talking to someone after the big splash Mythos made & he was saying the approach may need to change. Waiting on patches to prove themselves or "bake in" on test systems before deploying them may need to become a thing of the past. The costs of patching right away and having some go wrong may be lower than the cost of waiting too long to patch now, if the speed that exploits spread become that fast and the waiting/testing period shrinks to basically not waiting.
cpz_77@reddit
We basically do, yes. Monthly, patches get pushed out. In theory we have a “validation ring” (small group of test servers we push to first, week of patch Tuesday) and could hold back updates from prod if needed (those go out the week following) but it’s really a facade tbh. Because for one we don’t even have a test instance of all our critical servers, for two nobody is actually validating anything on these that I’m aware of - they just push updates to that group, and as long as nothing major blows up that people notice in the next week then they move forward with pushing them to prod. Nobody is actually checking the full functionality of the key apps on those servers, testing common scenarios to make sure there isn’t something less obvious that’s broken, etc. So it’s more just a CYA thing at this point tbh, so they can “say they have a validation process”.
Originally this was just windows updates but over time that has morphed into updates for “all MS products” including dependencies like redistributes and such, plus some third party apps. Plus feature (build) upgrades on workstations.
And yes we’ve had numerous issues in various areas since this process was implemented - updates to dependencies that breaks some functionality in an app, ungraceful reboots on servers that lead to something getting into a bad state (although I think that’s more a shortcoming of our update management software platform tbh, there’s a lot of stuff it doesn’t really do “gracefully”)….updates to a third party app that aren’t run with the proper options to retain settings and plugins so it wipes out the local config and has to be re configured, etc. And of course, the people pushing the updates aren’t the ones who have to fix shit when it breaks, which is why they aren’t too concerned about it.
In case you can’t tell, I’m not too impressed with our current situation. We need a better process for sure because the current “validation” we’re doing isn’t really validating anything. And it’s on our list of topics to discuss and hammer out in the near future.
But I also have yet to find an update management platform that actually does what it claims and actually makes update deployment simple and straightforward while still allowing the flexibility and control required to handle all our use cases. They all have massive gaps in one area or another from what I’ve seen.
plump-lamp@reddit
Testing rings, let it bake, then approve for a few prod rings. Be able to cancel updates at anytime. Everything is automated by our on-premise closed off patching solution, not a cloud based RMM
InterestTechnical242@reddit
manageengine ? why bother patching when you got that malware running
plump-lamp@reddit
Isolated, ring fenced, no issues going on 10+ years.