Every host runs a daily systemd timer (OnCalendar=09:00, deliberately outside the 01:00–07:30 backup window).
| Variant | Hosts | Behavior |
|---|---|---|
| Full auto-upgrade | Gateway, sn-infra, sn-web, sn-monitor, sn-security, hot-pn, hot-erp-nl | apt-get update && apt-get -y upgrade daily, fully unattended |
| Check-only, manual approval | hot-bm-nl only | Lists upgradable packages via Ntfy, never applies automatically. Run apt-approve-upgrade by hand to review and apply — this host runs all 4 production VMs, so a bad kernel/qemu-server bump or unattended reboot here would take the whole fleet down at once |
Failures and reboot-required events notify via the shared Ntfy token at priority=high — below the SMS-triggering threshold, so a routine patch failure doesn't page Mr. Byrne's phone, just shows up in the logs. See Backups & Alerting for the full severity matrix.
A stale grub-pc/install_devices debconf list (containing LVM PV/LV device entries alongside the raw disk) makes grub-install fail against those entries every time, permanently wedging grub-pc in a "not fully installed" state and aborting every subsequent apt-get upgrade on that host — silently, until someone checks systemctl --failed/dpkg --audit. This has already happened on hot-pn. Applies to any single-disk-LVM cloud VPS in the fleet (hot-pn, hot-erp-nl specifically). Fix: debconf-set-selections the device list down to just the raw disk, then dpkg --configure -a.