Unattended-Upgrades for Proxmox Host (Security + PVE-Updates)

Noah0302

Member
Jul 21, 2022
64
15
13
Hello everyone,


I was trying to find the recommended way of configuring Unattended-Upgrades on my Proxmox-Hosts, but was not able to find conclusive Results...

I was trying to get 2 different Configurations to work, installing the following Updates automatically:
  • Test PVE-Node: Debian (Bookworm, Bookworm-Updates, Bookworm-Security), Proxmox (PVE-No-Subscription), Ceph (No-Subscription)
  • Main PVE-Cluster: Debian (Bookworm-Security)
Summary: I want my Test-PVE to install all Updates automatically, the same that would be installed via apt update && apt dist-upgrade. My Main PVE-Cluster Nodes should only install Security-Updates automatically, leaving bigger Updates to be installed manually.

Currently I have this written in my /etc/apt/apt.conf.d/50unattended-upgrades:
Code:
        "origin=Debian,codename=${distro_codename},label=Debian-Security";
        "origin=Debian,codename=${distro_codename}-security,label=Debian-Security";

Could anyone help me with those 2 different Configurations? Maybe someone here already has it configured like I plan on doing.


Thank you for reading!
 
Last edited:
What would I need to add to the unattended upgrades config to install them automatically?
I haven't done it for PVE (and never will), but this is how it should work. The problem is finding out the PVE-specific pattern.

I do only automatic updates with machines, I can live without. If your machines all don't come back online due to a kernel problem, you're automatically in deep trouble. Therefore I manually install only those security updates that'll be exploitable in some way (remote kernel execution, and SSL/SSH-related stuff). Just updating everything may be too much distruption in your service.
 
  • Like
Reactions: Noah0302
If your machines all don't come back online due to a kernel problem, you're automatically in deep trouble.
An example of this - recent userland multipath-tools update to address a security issue. While it addressed the issue, the packaging got broken and missed a critical file for new installs (this has since been addressed in later Debian releases). There is always a risk to software update, doubly so for unattended one.

https://forum.proxmox.com/threads/p...ultipath-attached-storage.128811/#post-563633


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Last edited:
  • Like
Reactions: Noah0302
I haven't done it for PVE (and never will), but this is how it should work. The problem is finding out the PVE-specific pattern.

I do only automatic updates with machines, I can live without. If your machines all don't come back online due to a kernel problem, you're automatically in deep trouble. Therefore I manually install only those security updates that'll be exploitable in some way (remote kernel execution, and SSL/SSH-related stuff). Just updating everything may be too much distruption in your service.
Yeah not easy to balance between
  • effort for manual updates/upgrade
  • security patches as soon as possible
  • potential risk of kernel update failing
in small setup (less than 5 machines) I would do it also manually. In bigger env maybe a staged approach. How I plan it is that a
- bunch of less critical machines will get automatic upgrades & reboot e.g. always week one of the month.
- Medium critical reboot one week later - which can be stopped in case first stage shows issues.
- Critical ones manual.
This assumes that machines are pretty similar regarding hardware and software setup.

But a short question if I get the follwoing after an apt dist-upgrade:
Code:
Seems you installed a kernel update - Please consider rebooting
this node to activate the new kernel.

should there then not a file under /var/run showing that a reboot is required?
Code:
# ls -la /var/run/reboot-required
ls: cannot access '/var/run/reboot-required': No such file or directory

note: now using needrestart tool which works great.
 
Last edited: