cjones/sysconfig
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add overall policy for software upgrades. Revise upgrade notes for Nextcloud.

Browse Source
This commit is contained in:
Christopher Jones
2026-04-18 15:22:47 -04:00
parent 9f321bd7f8
commit 15ee31660b
2 changed files with 43 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
services/nextcloud/upgrading.md
+9 -21
View File
@@ -1,30 +1,18 @@
Steps to upgrade Nextcloud from one major version to the next.
1. Put the Nextcloud instance into maintenance mode
docker exec --user www-data nextcloud-app-1 php occ maintenance:mode --on
Note that 'docker exec' is used to run commands within the Nextcloud docker container; and '--user www-data' is used to run as the user that owns all of the Nextcloud files.
2. Back up the Nextcloud container's files to a location outside the container's mounted volume. 'rsync' is recommended:
rsync -Aavx /mnt/storage/appdata/nextcloud/www/ <backup-target-dir>/
rsync should be run as root. rsync with these options should preserve file ownership & permissions.
3. Back up MariaDB database:
docker exec nextcloud-db-container-name mysqldump --single-transaction -h localhost -u nextcloud_user -pnextcloud_password nextcloud_db_name > nextcloud-sqlbkp_$(date +"%Y%m%d").bak
4. Alternatively, if the Nextcloud files and database are stored in a ZFS dataset, take a ZFS snapshot of the relevant dataset(s).
5. Bring the Nextcloud instance down:
1. Bring the Nextcloud instance down:
sudo docker compose down
6. Edit the compose.yaml file and change the tag on the Nextcloud image to the next major version number.
7. Pull the next version of the Nextcloud image:
2. Take a ZFS snapshot of the tank/appdata/data/nextcloud-data and tank/appdata/databases/nextcloud-db dataset(s).
3. Edit the compose.yaml file and change the tag on the Nextcloud image to the next major version number.
4. Pull the next version of the Nextcloud image:
sudo docker compose pull
8. Bring up the Nextcloud instance:
5. Bring up the Nextcloud instance:
sudo docker compose up -d
9. Wait a minute or so and bring up the Nextcloud web client in your browser. Open the Administrative Settings Overview page and check for any issues.
10. If the Overview page recommends any occ commands:
6. Wait a minute or so and bring up the Nextcloud web client in your browser. Open the Administrative Settings Overview page and check for any issues.
8. If the Overview page recommends any occ commands:
* Put the instance into maintenance mode : docker exec -u www-data nextcloud-app-1 php occ maintenance:mode --on
* Run the occ commands recommended (for example, docker exec -u www-data nextcloud-app-1 php occ db:add-missing-indices)
* Take the instance out of maintenance mode: docker exec -u www-data nextcloud-app-1 php occ maintenance:mode --off
Note that 'docker exec' is used to run commands within the Nextcloud docker container; and '--user www-data' is used to run as the user that owns all of the Nextcloud files.
services/upgrades.md
+30
View File
@@ -0,0 +1,30 @@
# 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.)