Update strategies

Today I’m setting up automatic updates on all of my Fedora machines.

There are several schools of thought regarding keeping your systems up to date. In the cloud space recently the buzzword has been “immutable infrastructure” - the idea that your (virtual) server’s operating system is fixed - effectively read-only - and you perform system updates by deploying new virtual machines and deleting the old ones. I can’t recycle my laptop every time there’s a new kernel version out, so this doesn’t work for me!

A more traditional update policy is that the system updates should be frozen until the proposed updates are approved, and then there is a period of downtime when just those approved updates are applied. This is a typical risk-averse enterprise datacenter approach - only apply critical security updates, and apply those manually after a lengthy approval and test process.

These approaches are both good for reliability and compatibility - your servers are running the same thing they’ve been running forever so it’s unlikely they will suddenly present issues. If you replace the whole virtual instance instead of upgrading in-place then you can test your application on the new instances before destroying the old ones. And if you’re applying critical security patches on bare-metal, at least you have a very short list of exactly what’s being changed in case something weird does happen.

Then there is the typical desktop update cycle - you check regularly or get notified that updates are available, and invoke the updater (i.e. dnf upgrade, apt upgrade, etc) at your leisure. You can be as picky or not about the packages that are updated by doing things like package pinning or specifying full version names at install.

There are more opinions about this stuff than I can list, obviously, but you get the idea. There’s a full spectrum of update tolerances from “un-updateable” to “bleeding-edge” with arguments to be made for them all.

On personal equipment, I like my systems to stay up to date. I also don’t like manually sshing around to update them. And in the unlikely event that an update breaks something…well, it’s not prod, it’s just a homelab :)

Automatic updates with DNF Automatic

dnf-automatic is a useful utility on Fedora for partially or fully automating package updates. I’m going to set it to apply all updates automatically so that I don’t ever have to run dnf upgrade by hand again.

To get started, we’ll install it:

$ sudo dnf install dnf-automatic

The configuration file is located in /etc/dnf/automatic.conf. The file is well commented, so have a read through to see what can be tuned. I like that there are options for upgrade_type - if you only wanted security upgrades to be applied automatically, just set it to that.

I’m going to set these options:

apply_updates = yes
emit_via = email_command,motd,stdio
[email_command]
email_from = dnf-automatic<root@host>
email_to = [email protected]

The [email_command] options being set enable dnf-automatic to post emails to me via the setup that I detailed in my post on setting up Postfix with Gmail. I don’t have to do any additional config with the emailer and will get a summary of the updates applied to this server from dnf-automatic in my inbox!

I’m happy with the default scheduling that comes with dnf-automatic, but if you wanted to check for updates more or less frequently, the timer unit /usr/lib/systemd/system/dnf-automatic.timer has the crontab:

...
[Timer]
OnCalendar=*-*-* 6:00
...

Adjust that to suit your update schedule if you need to.

And finally we can enable that timer to regularly check for and apply updates:

$ sudo systemctl enable --now dnf-automatic.timer

Now relax and let your system keep itself up to date!