Hacker News Reader

Comment by freshflowers | Hacker News Reader

True. However, since most clients (especially those that don't maintain their servers well) use standard images provided by the hosting provider, I don't understand why those images don't come with automatic security updates configured by default.

I know that many of us that run systems for which availability criteria mean they want full manual control over all updates, but those are the people that either use custom images or know how to turn those automatic updates off.

Security updates are finally pushed hard on desktop users for obvious reasons, with everyone and their mother running cheap VPS's these days the same logic should apply to virtual servers.

View on HN

Automatic updates for server software can be tricky.

Ubuntu, for example, can be configured to run apt-get update && apt-get upgrade automatically every day (using unattended-upgrades), but AFAIK the default configuration only checks for updates, notifies the admin, and waits for approval before actually changing anything.

Even though Ubuntu LTS, Debian Stable, CentOS, etc. are supposed to be stable distributions, it is not unheard of for routine updates to break something mission-critical. For example, the package maintainer might have made some changes to the default configuration. (C'mon, do you really need to make minor changes to nginx.conf all the time?) A daemon might go down and fail to come up again after an update. (apt is particularly annoying in this regard, since it forcibly restarts daemons during an upgrade, and not always in a sensible order. Result: HTTP 502 Bad Gateway.) So unless a human is present to spot any issues immediately after an update, you might be left with a broken system at an inconvenient hour. Which is why the documentation doesn't recommend fully automated updates.

Unfortunately, the set of VPS owners who don't apply updates regularly probably has a large intersection with the set of VPS owners who won't be able to troubleshoot a broken update anyway, so maybe this concern need not apply...

We're working on the auto-update model for servers at CoreOS. If interested, you can read more about our update philosophy here: https://coreos.com/using-coreos/updates/. We think that this is one of the best ways to secure the backend internet, similar to how auto-updating browsers moved the front-end of the internet forward.

(CoreOS employee)

This can be difficult as some updates can break applications. PHP is problematic that way for our customers on servers that we manage for them. Its not as bad as it used to be (e.g. register_globals), but updates can break customer apps. So if you automatically apply them and their web server breaks, who does the clean up ? The web developer who got paid to create the site but not maintain it ? The VPS provider who gets paid to just host the image ? The customer from their POV (and these are not technical people) will often say, "but I didnt do anything to break it. You broke it! You fix it!" Also, as there are (typically) no regression testing, breakage can be silent and undetected for some time.

As I understand it, server updates run counter to the idea of servers as static, externally configured fixtures ala cloud formation or its competitors. To merge the concepts you'd need to have aws or whoever manage your cloud formation templates and automatically re-deploy whenever they make a change to them for security reasons... I think maybe our tooling isn't quite there yet, but I'm sure its coming. Disclaimer: I don't have a very deep knowledge of cloudformation, so I might be talking out of my ass.

True, you can select for example "Ubuntu 14.04 LTS" and not be protected against Shellshock nor Heartbleed by default.

Reply on news.ycombinator.com