I lived under impression that timely updates were very important. Even a home user wouldn't like their computer to demand ransom for their data. However, the less home and the more corporate our setting is, security only becomes more, not less important. A big company that has a lot to lose needs to apply all security updates the second they are available, which hopefully but not necessarily means 'sooner than a bad guy exploits the vulnerabilities'. There is simply no time for an administrator to wake up in the morning, go to work and apply them manually. And because of this, corporate systems must be set to update automatically.

And apparently this is not exclusively true for corporations: IIRC this is precisely one of the arguments I heard why home people are recommended to use cloud services to run their websites instead of running their own dedicated servers in their homes. The cloud updates their systems immediatelly; but if a home user runs their own server, they have to sleep sometimes, so the updates are at best applied each morning, so each night is a vulnerability window.

However, it seems I was wrong? Quoting competent people from Linux Mint forums: https://forums.linuxmint.com/viewtopic.php?t=311756

As a rule, updates should always be done consciously. So that they won't ever interrupt or damage your work. So I think automatic updates are generally a bad thing. A corporate system administrator who enables them, should be fired on the spot.

(...) What I mean is that a corporate system administrator should be the one who determines when updates to the machines of his company should be rolled out. He should first properly test them himself, on a test rig, and then roll them out at a time that no one is using those machines. After normal working hours.

Such a system administrator should not, under any circumstance, enable automatic updates and therefore leave everything to the OS maker. Because that could disrupt work flows and could even create major havoc and damage in a company.

So, under my reasoning, this is a recipe for getting the systems compromised while the sysadmin properly tests the updates himself, on a test rig, and then rolls them out at a time that no one is using those machines? And then to see, for example, all corporate data, including the data of all company's customers, put for sale on dark web?

People seem to be worried that automatic updates introduce regressions that break systems. Which risks is, therefore, considered more dire by sysadmins: that an update introduces unexpected regressions or that reluctance to apply updates immediately creates a security vulnerability?

Do sysadmins apply updates immediately, or do they wait and test them carefully and only apply them outside of working hours?


There are two type of cases:

1. Vendor Released an Update A bug/vulnerability may be discovered or vendor has just added new features and released a new update, at this point I exactly recommend you to update your services automatically. Generally it doesn't cause any serious problem. Also, you can undo updates in popular softwares or services.

2. Vendor Hasn't Released an Update A bug/vulnerability may be disclosed or you may want to add new patches, but there is no official update. So, you have to intervene and make everything yourself. Sometimes you have to do it, because some vendors may not release an update for critical vulnerabilities, for days, like Microsoft! I recommend you https://vullnerability.com website to track vulnerabilities real-time. So, you will be alerted when a vulnerability discovered and take an action as soon as possible before vendor. Its generally more dangerous and not recommended.

For both situations: You should create backup for possible problems. I prefer to host my services in two different servers, the first server is real and the second one is backup, if I have a problem in first server, I immediately redirect my services to second server to don't lose data and customer.

| improve this answer | |
  • Update servers automatically? In the middle of the day? When the server is part of a stack? When there are dependencies? It's not nearly that simple. It doesn't cause serious problems? I've seen Microsoft patches brick servers. I've seen OS patches break services. You have hot-standby resilient servers? That's fine. But that's not true for everyone. And then if something goes wrong, how long do you run the unpatched and vulnerable server? – schroeder Apr 26 at 22:05
  • And you are advocating that a sys admin write an OS patch themselves for a disclosed vulnerability that the vendor hasn't released a patch for yet? You want to trust the coding and testing skills of your local people compared to the vendor? There are far more mitigatons to consider than just patching... – schroeder Apr 26 at 22:07
  • I haven't experienced it before. It means you did somethings wrong, see misconfigurations in your servers and fix them. – Numan OZDEMIR Apr 26 at 22:10
  • 1
    No, my team did not do something wrong. There have been Windows Server patches that brick the server. These are known. That's why companies put in full test rigs for patches before rollout. – schroeder Apr 26 at 22:34
  • 1
    Servers, software, and stacks are insanely complex beasts. You cannot make blanket statements for how everyone is supposed to patch. That's why there is a whole field called "patch management". – schroeder Apr 26 at 22:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.