Hi, everytime I log to my Forge server, I am greeted with the message like: 150 packages can be updated ,1 update is a security update, so I am wondering how to address this.
On Digital Ocean, they recommend quite complex procedure with shutting the server down, making a snapshot while switched off, then switch back on and do sudo apt-update and sudo apt-upgrade.
I've been reading how often people usually do this and seems like often they do it even several times a week, which would be quite annoying if done always this way. Plus we also have production data there, so we obviously don't want to have outages that often. So what I am generally wondering is:
How often shall I update server packages to have some compromise between security and downtime?
Is it generally safe to avoid the Digital Ocean recommended switch off & snapshot before each update? I reckon Ubuntu must be pretty solid here and must run its updates even on hosts where this snapshots feature doesn't exist, so I think it is mostly DO covering themselves and recommending the most secure way, while it is not really necessary?
Is it safe to let CRON do this, eg. once a week at 2am? Or shall I rather do it manually? Perhaps make an alias to to call apt-update && apt-upgrade && reboot , and call it myself?
Make it predictable for users. Schedule it to minimize downtime. Eg. don’t do first day of month if that’s when they all do their reporting... Do it manually, so you can decide if it’s really needed if something could break. Have a staging environment where you upgrade first. Keep backups but IMO you don’t need to power off to take a snapshot. Instead verify regularly that in case of a complete disaster during upgrade you can get up and running quickly. Ubuntu has Livepatch for kernel upgrades without reboot.
@AUDUNRU - Hey Aundru, thanks, I am just wondering - at the bottom of the info text when I login it says *** System restart required ***. I always thought it is related to the updates, if not, than what can be the reason for this restart?
Ok, thanks.. is there anyone else who could give their opinion? I was a bit hoping I could just pass this to CRON, set it once per week to some early morning hour and just not worry about it.. but I see all the benefits of doing it manually.
I have several servers to worry about, so I am looking for some efficient way so I don't kill half of my day doing this. Also, we usually have the staging environment on the same server, seemed like a good idea to make sure both envs run on same version of nginx, mysql etc.. So testing on staging server unfortunately isn't an option here.
System auto updates aren't usually a good thing imho. It will only take you one time for you to get an unwanted update that totally breaks your server, spending hours troubleshooting it while your angry users are hitting the phone and contact emails asking why they can't reach your server to see what I mean. I like to let others suffer from that before I risk my users.
Just like updating your php packages, you don't really want to do that on a live server without testing how they affect your app in a test environment.
I do system update tests on the testing server (which is a separate server only used for testing) before updating the live servers, and then run my unit and integration tests against that. All servers run the same os/version, so if it works on the testing server I know it will work on the live servers.
@cronix - thanks a lot for explanation, that indeed makes sense and I like the idea of having one server specifically for testing updates. But the problem is, that I set up the servers through a quite long timespan of about maybe two years.. so some servers are Ubuntu 16, some Ubuntu 18, not sure if I have some on 14 as well..
So syncing them now to all run the same environment, that I could mirror into a test server looks pretty difficult.. or do you reckon it is something a user with just overall server knowledge can do?
