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

[Noah0302]

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:

        "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!

 

[LnxBil]

Cluster Nodes should only install Security-Updates automatically, leaving bigger Updates to be installed manually.

This does not include PVE security updates (which are not part of Debian Security).

 

[Noah0302]

This does not include PVE security updates (which are not part of Debian Security).

Thank you, I forgot that.

What would I need to add to the unattended upgrades config to install them automatically?

 

[LnxBil]

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.

 

[bbgeek17]

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

 

[endurance]

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:

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?

# 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.

 

[LnxBil]

should there then not a file under /var/run showing that a reboot is required?

IIRC, this file is only created with installed unattended package.