apt-get upgrade might break Proxmox install

[free-pmx]

Hi, I was just made aware of your interesting project and instantly glanced at what it plugs in via API and what it potentially modifies.

I noticed you added an upgrade option to node_cmd.

This might break PVE install as them tracking all dependencies correctly is not guaranteed - it happened before. It needs to be full-upgrade (formerly dist-upgrade) instead.

---

On a separate note, if you were planning to keep rolling your patched backend Perl module forward, you might like my PoC (split off another project) which can do this for you, i.e. you could just define new node_cmd, provide old and new blocks of code and unless Proxmox change that very lines, it will keep preserving your change on Proxmox upgrades (where a regular patch would fail).

Enough self-promotion, if you were interested in using it as dependency, feel free to file me an issue there - I am leaving it experimental for now (for the person who first requested it), but the approach has been well tested by now in patching front-end. You are, of course, also free to fork it, license is AGPL though.

Cheers and all the best with this nice project!

[gyptazy]

Hey @free-pmx,

thanks for your inputs. The fragment you found was just a test and has never been used or published. Also, the automated node patching takes place with future versions (#216) - the target release is 1.2.0. The patched API will not be shipped with ProxLB to avoid upgrade issues with Proxmox which ships that file via the PVE-manager package. Instead, I will provide a repackaged and patched version of it. The patch can be found here: https://cdn.gyptazy.com/proxmox/patches/6799_add_apt-get-dist-upgrade_to_api/ which of course also uses dist-upgrade.

Unfortunately, this got rejected at upstream Proxmox where automated upgrades are considered as unsafe. So, I need to patch the file for each iteration within my pipeline and make it as an optional package available which can (but not must) used via the repository of ProxLB. This way, people can still decide if they want to have a modified package or not.

In addition to the patched Proxmox API, it also requires the full logic in ProxLb which takes place in release 1.2.0 with this PR (still WIP): #321

Hope this helps!

Cheers,
gyptazy

[free-pmx]

thanks for your inputs. The fragment you found was just a test and has never been used or published. Also, the automated node patching takes place with future versions (#216) - the target release is 1.2.0.

Apologies for the noise, I did not realise this.

The patched API will not be shipped with ProxLB to avoid upgrade issues with Proxmox which ships that file via the PVE-manager package.

This is where my suggestion came from, but I think this is literally the only little piece of theirs you are patching, so might not find that so meaningful (the mechanism).

Instead, I will provide a repackaged and patched version of it. The patch can be found here: https://cdn.gyptazy.com/proxmox/patches/6799_add_apt-get-dist-upgrade_to_api/ which of course also uses dist-upgrade.

I understand, I did not realise you are rolling own APT, that solves a lot. It is still a maintenance burden, but I see where you are coming from.

Unfortunately, this got rejected at upstream Proxmox where automated upgrades are considered as unsafe.

FWIW I do not believe that was a candid answer - if that's what they stated (pve-devel?). Consider that the API is perfect candidate to allow even arbitrary command to be executed. Even today, many do automated upgrades, e.g. Ansible/SSH, so it's a non-issue.

So, I need to patch the file for each iteration within my pipeline and make it as an optional package available which can (but not must) used via the repository of ProxLB. This way, people can still decide if they want to have a modified package or not.

For those running of APT repos, this is a non-issue, or rather - your issue (maintenance whenever Proxmox touch that .pm). For those doing one-off .deb, the approach with my patching has the benefit that it auto-applies (on Proxmox upgrades) even if they have no "third party" APT repo in the system.

In addition to the patched Proxmox API, it also requires the full logic in ProxLb which takes place in release 1.2.0 with this PR (still WIP): #321

So this basically ensures your tailored package overrides the one from Proxmox, correct? May I know how you are (re)building the package, did you get it into own CI/CD or plan to? (Just curious.)

Hope this helps!

It's a nice project, I discovered your web (only now), and well - see you have it under control, I believe. I was first looking who is patching any of Proxmox they did not take in and wanted to reach out. Someone pointed me to your piece, but I am glad I discovered it.

Cheers, gyptazy

Likewise, keep it up!

PS I never mess with maintainer's issue status, but I suppose this is essentially completed then.

[gyptazy]

Hey @free-pmx,

thanks for your inputs. The fragment you found was just a test and has never been used or published. Also, the automated node patching takes place with future versions (#216) - the target release is 1.2.0.

Apologies for the noise, I did not realise this.

No worries, this is why we have open discussions to improvise things - and I’m always happy about feedback, especially because ProxLB is a one-man show and I’m sometimes missing some feedback :)

Instead, I will provide a repackaged and patched version of it. The patch can be found here: https://cdn.gyptazy.com/proxmox/patches/6799_add_apt-get-dist-upgrade_to_api/ which of course also uses dist-upgrade.

I understand, I did not realise you are rolling own APT, that solves a lot. It is still a maintenance burden, but I see where you are coming from.

Unfortunately, this got rejected at upstream Proxmox where automated upgrades are considered as unsafe.

FWIW I do not believe that was a candid answer - if that's what they stated (pve-devel?). Consider that the API is perfect candidate to allow even arbitrary command to be executed. Even today, many do automated upgrades, e.g. Ansible/SSH, so it's a non-issue.

You can find the discussions on the PVE-devel list here: https://lists.proxmox.com/pipermail/pve-devel/2025-September/075184.html

Even I cannot fully understand this, even many ones do unattended upgrades for minor versions for years by using Spacewalk, simple cronjobs or systemd timers, Ansible, etc., I also never had any issues (I’m using the patched API approach since the beginnings of PVE8 internally). But in the end, it’s of course up to upstream/maintainer what they want to implement (and support).

So, I need to patch the file for each iteration within my pipeline and make it as an optional package available which can (but not must) used via the repository of ProxLB. This way, people can still decide if they want to have a modified package or not.

For those running of APT repos, this is a non-issue, or rather - your issue (maintenance whenever Proxmox touch that .pm). For those doing one-off .deb, the approach with my patching has the benefit that it auto-applies (on Proxmox upgrades) even if they have no "third party" APT repo in the system.

In addition to the patched Proxmox API, it also requires the full logic in ProxLb which takes place in release 1.2.0 with this PR (still WIP): #321

So this basically ensures your tailored package overrides the one from Proxmox, correct? May I know how you are (re)building the package, did you get it into own CI/CD or plan to? (Just curious.)

Right, it gets built on my own CI/CD. As soon as this feature takes place, the repo will be public available to verify the changes, checksums and to be able to compare it with the repo shipped package. The version will just be defined as an appendix to make sure it’s preferred over the original package, but also doesn’t increments the minor version for upcoming updates from upstream which looks abstracted like:

1.2.3-1            <  1.2.3-1+proxlb1   <  1.2.3-2   <   1.2.4-1

It's a nice project, I discovered your web (only now), and well - see you have it under control, I believe. I was first looking who is patching any of Proxmox they did not take in and wanted to reach out. Someone pointed me to your piece, but I am glad I discovered it.

Thanks a lot! Hope to have everything in place soon for the automated node patching :)

Have a nice Sunday!

Cheers,
gyptazy

[free-pmx]

You can find the discussions on the PVE-devel list here: https://lists.proxmox.com/pipermail/pve-devel/2025-September/075184.html

Just to spell it out - translation by myself: "We have looked at your project and realised this shows us what we have neglected in our own HA stack. Now instead of gifting us your entire codebase - which we would not take in due to ideological reasons (Python) anyways, you are attempting to sneak in a patch to enable it to be even more capable. This is not what we would like our API to be used for."

Saying that an API call "signals to lesser experienced users" anything can only fly with those, well "lesser experienced ones."

But in the end, it’s of course up to upstream/maintainer what they want to implement (and support).

Aside: There's nothing in that snippet that needs maintenance. Perhaps the eyesore was Acquire::http::Proxy.

Cheers, gyptazy

I will leave it at that not to pollute your issue tracker, but I just felt like expressing this openly. Cheers!

PS The person who replied to you is the sole author of the HA stack.