31 lines
3.7 KiB
Markdown
31 lines
3.7 KiB
Markdown
# Upgrade Cadence For OS And Services
|
|
|
|
The overall policy for software upgrades is to keep up with the most recent stable release of any operating system or service running on any of our devices. When a new major version of a service is released, we can upgrade right away (especially if the project or vendor has earned a reputation for stability); or it is acceptable to wait for a point release (or simply the passage of a month or so) to avoid breakage.
|
|
|
|
For operating systems, we rely on the update facility of the OS vendor to provide timely updates, especially for security vulnerabilities.
|
|
|
|
## Notes for specific software
|
|
|
|
### Operating Systems
|
|
|
|
* **Microsoft Windows**. Microsoft doesn't allow much leeway here. To ensure security and full support on our Windows client devices, we let Windows Update handle this according to the normal Microsoft schedule.
|
|
* **Ubuntu**. All Unbuntu servers are currently on version 24.04 LTS. When Canonical provides an update (particularly for security issues) it should be applied in a reasonably timely fashion. When a major LTS version is available (e.g. 26.04), we will wait for a point release before upgrading to the next point release.
|
|
* **Fedora**. Fedora is currently running only on a client device. When a major release is available, we will wait for a point release in the interest of stability, and then upgrade at our leisure. We should not, however, allow Fedora to be more than one major version behind. Check Fedora release status quarterly.
|
|
* **Raspbian**. Currently only one device (raspberrygrove) is running Raspbian (Buster). Rather than upgrade to Raspberry Pi OS Trixie, we will install Ubuntu on this device, probably after Ubuntu 26.04 LTS is available has been installed on our other Ubuntu servers. From then on, raspberrygrove will follow the same upgrade cadence as other Ubuntu servers.
|
|
* **Android and iOS**. Like Microsoft, Google and Apple keep a tight rein on this. We will let the OS vendors drive the upgrade cadence for mobile clients.
|
|
|
|
### Local Services
|
|
|
|
For Docker-based services (and anything else that is installed to our ZFS pool), take a ZFS snapshot of the relevant dataset(s) before doing the upgrade. For Docker containers specifically, first bring the service down before taking the snapshot. Don't rely on the regular snapshots scheduled by Sanoid; snapshots taken while a Docker instance is running may not be consistent, if a database is involved.
|
|
* **caddy**. Upgrade to major releases only.
|
|
* **gitea**. Upgrade to major releases only.
|
|
* **immich**. Immich have a history of rapid development and breaking changes. Even though the project has now released a "stable" version, we will continue to be cautious. Experience with Immich has shown that upgrading each minor release one by one, with a ZFS snapshot to roll back to, is the best practice.
|
|
* **jellyfin**. Upgrade to major releases only.
|
|
* **nextcloud**. Upgrade to major releases only.
|
|
* **portainer**. Upgrade to major releases only.
|
|
* **sanoid**. Upgrade to major releases only.
|
|
* **tailscale**. As a key part of the "network operating system", it's worth keeping Tailscale continuously up to date. Tailscale have earned a reputation for quality and stability. Therefore we will monitor the Tailscale admin console and ensure that all devices are up to date at least monthly.
|
|
* **unbound**. Upgrade to major releases only.
|
|
* **vaultwarden**. Upgrade for both major and minor releases. Password managers are a high-value target, so being up to date with security fixes is particularly important.
|
|
* **zfs**. ZFS is provided by Canonical and is effectively part of the OS. We will upgrade ZFS as part of the OS upgrade process for Ubuntu. (Subject to change, of course, if ZFS is installed on a non-Ubuntu device.)
|