Automatic Updates

[dominichayesferen]

I'm not sure if this has already been done, so sorry if it has...

One of the problems with Windows back in the NHS has always been lack of Updating, and I fear something similar could happen with NHSbuntu, unless, you set up Unattended Upgrades in the distribution. This Can Be Set Up To Work Before The OS Is Made Into An ISO

To set Unattended Upgrades up:
In Terminal, run this:
sudo apt-get install unattended-upgrades -y (-y assumes YES for all possible prompts)
Now, go to '/etc/apt/apt.conf.d' in something that's got Superuser Privileges, and make sure a file that's EXACTLY called '50unattended-upgrades' exists, if not, make a blank document and name it to that, without the quotes.

Open it in your favourite text editor, and configure it something like how I did it in feren OS (below):

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}-security";
	"${distro_id}:${distro_codename}-updates";
	"${distro_id}:${distro_codename}-proposed";
	"${distro_id}:${distro_codename}-backports";
	"Ubuntu:xenial-security";
	"Ubuntu:xenial-updates";
	"Ubuntu:xenial-backports";
	"Ubuntu:xenial-proposed";
};

// List of packages to not update (regexp are supported)
Unattended-Upgrade::Package-Blacklist {
//	"vim";
//	"libc6";
//	"libc6-dev";
//	"libc6-i686";

};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "false";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGUSR1. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
Unattended-Upgrade::MinimalSteps "true";

// Install all unattended-upgrades when the machine is shuting down
// instead of doing it in the background while the machine is running
// This will (obviously) make shutdown slower
//Unattended-Upgrade::InstallOnShutdown "true";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "user@example.com"
//Unattended-Upgrade::Mail "root";

// Set this value to "true" to get emails only on errors. Default
// is to always send a mail if Unattended-Upgrade::Mail is set
//Unattended-Upgrade::MailOnlyOnError "true";

// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";

// Automatically reboot *WITHOUT CONFIRMATION*
//  if the file /var/run/reboot-required is found after the upgrade 
Unattended-Upgrade::Automatic-Reboot "false";

// If automatic reboot is enabled and needed, reboot at the specific
// time instead of immediately
//  Default: "now"
//Unattended-Upgrade::Automatic-Reboot-Time "02:00";

// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";

Hopefully, it should work and it should install updates in the background on the set time to check for updates, you can tell because during it, APT won't be able to unlock because unattended-upgrades would be locking DPKG while it's working in the background (for Package Upgrading)...

[pacharanero]

Thanks for participating @feren, it's great to have input from the community.

The issue of unattended upgrades is an interesting one. In a desktop OS, it's reasonable, as it means that security fixes are immediately applied and you are safe, and if there's a regression you can roll back the change manually.

When managing thousands of machines remotely, however, (as it would be across a single NHS trust's estate) you need to be sure that you aren't rolling out a regressive patch.

Also you want to be able to have control of specifically when the patch is applied, ie the time of day, because machines may need to reboot and this could be inconvenient if for example it's in the middle of a busy clinic.

So we would expect enterprise-wide machine management tools (which are already in use across the NHS) to be used to test any security upgrades in a 'staging' environment, and then when we're sure everything's OK, roll it out at an appropriate time to the organisation.

So: for now, while NHSbuntu is mainly just being evaluated and used for development, yes we will temporarily set unattended upgrades to be on by default.

But as we move to production, no it will be off by default and sysadmins will arrange upgrades and updates according to whatever patch schedule they feel appropriate, at a time that is not going to cause clinical disruption, and following appropriate staging/testing steps.

[dominichayesferen]

@pacharanero I agree with that point. I was thinking myself with feren OS sometime in the future to regulate updates to packages when feren OS got it's own PPAs for Stable (Passed Testing), Romeo (Testing Packages for Stability) and Edge (Newly Submitted Packages that are yet to be checked), so maybe if NHSbuntu follows a similar policy with packages, if NHSbuntu got its own set of repositories for regulating updates with (with the added benefit of being able to completely change packages before systems get the original versions of packages when updated)...

There again, if you know about the packages you don't want updated ever, you can apt-mark hold the package too... (You might even be able to regulate this through a Network if you found a way of doing so)

[Chaz6]

I strongly feel that automatic updates should be on by default, and then those places with the capacity to manage updates manually have the facility to disable it. If it is the other way around, I would think the majority would not do so.

[pacharanero]

@Chaz6 good point actually.

@robdyke what do you think of that approach?

[Mraanderson]

Are there many instances where Ubuntu updates break things to the extent that Windows updates break things?

I'm for on by default with Sysadmin to turn off if they require.

[dominichayesferen]

Also, I'd like to add something extra to this:
If possible, it'd be probably better and have less chance of failing if Upgrades to other Ubuntu Versions were done on shutdown, restart, or on startup, while the user cannot interact and interfere with the process...

Here's what I'm thinking:

1. The user will be prompted as the update package that lets the upgrade begin when they want to do the upgrade

2. On that chosen time, the user will receive a final prompt asking if they want to wait until next time that chosen circumstance happens

3. If they choose to upgrade now, it'd then give them a final prompt, and possibly another prompt if they're using battery power that's not charging

4. You could also leverage the ability to place an image on the top-right of the screen to be used as a majority of things, such as Battery Low Alert, a logo for the OS, or just the title of the Screen...