all lists on lists.proxmox.com
 help / color / mirror / Atom feed
* Re: [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
       [not found] <99022DEC-C3F5-48FE-9F81-A262118D27F7@credativ.de>
@ 2025-09-12  9:22 ` Thomas Lamprecht
  2025-09-17 10:26   ` Florian Paul Azim Hoberg via pve-devel
  0 siblings, 1 reply; 3+ messages in thread
From: Thomas Lamprecht @ 2025-09-12  9:22 UTC (permalink / raw)
  To: Florian Paul Azim Hoberg, pve-devel

Am 12.09.25 um 08:34 schrieb Florian Paul Azim Hoberg:
> Extend the PVE API by a new 'upgrade' path in the
> apt path to perform 'apt-get -y dist-upgrade' on

Blindly upgrading can be dangerous and result in broken system, that's
why the Proxmox VE API only supports the interactive upgrade through
API using a html5 based shell to keep a (human) admin in the loop.

If your org evaluated the risk of doing this and is fine with that,
then I'd recommend using a lower level automation to frequently do
upgrades this way or setup unattended upgrades [0]. Adding this to the
PVE API signals to lesser experienced users that it's safe and stable,
which in our opinion it cannot really be (for those lesser experienced
ones).

So thanks for submitting a contribution, but we cannot accept this.

[0]: https://manpages.debian.org/trixie/unattended-upgrades/unattended-upgrades.8.en.html

Still some comments inline.
> the node in a noninteractive way to avoid blocking
> the upgrade process.
> 
> Signed-off-by: Florian Paul Azim Hoberg @gyptazy <florian.hoberg@credativ.de>
> ---
> 
> PVE/API2/APT.pm | 78 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
> 
> diff --git a/PVE/API2/APT.pm b/PVE/API2/APT.pm
> index 0d07cf38..3f2d7807 100644
> --- a/PVE/API2/APT.pm
> +++ b/PVE/API2/APT.pm
> @@ -417,6 +417,84 @@ __PACKAGE__->register_method({
>     },
> });
> 
> +__PACKAGE__->register_method({
> +    name => 'upgrade_packages',
> +    path => 'upgrade',
> +    method => 'POST',
> +    description =>
> +        "This is used to upgrade the system to the latest packages (apt-get -y dist-upgrade).",
> +    permissions => {
> +        check => ['perm', '/nodes/{node}', ['Sys.Modify']],

If, this would IMO need dedicated permissions, sys.modify is rather overused
already and doing a system upgrade is certainly one of the most privileged
operations.

> +    },
> +    protected => 1,
> +    proxyto => 'node',
> +    parameters => {
> +        additionalProperties => 0,
> +        properties => {
> +            node => get_standard_option('pve-node'),
> +            command => {
> +                description => "Specify the command.",
> +                type => 'string',
> +                enum => [qw(upgrade)],

useless parameter, can always get added in the future if there would be the
need for such a property.
> +            },
> +            quiet => {
> +                type => 'boolean',
> +                description =>
> +                    "Only produces output suitable for logging, omitting progress indicators.",
> +                optional => 1,
> +                default => 0,
> +            },
> +        },
> +    },
> +    returns => {
> +        type => 'string',
> +        description => 'The task UPID.',
> +    },
> +    code => sub {
> +        my ($param) = @_;
> +
> +        my $rpcenv = PVE::RPCEnvironment::get();
> +        my $dcconf = PVE::Cluster::cfs_read_file('datacenter.cfg');
> +
> +        my $authuser = $rpcenv->get_user();
> +
> +        my $realcmd = sub {
> +            my $upid = shift;
> +
> +            # setup proxy for apt
> +
> +            my $aptconf = "// no proxy configured\n";
> +            if ($dcconf->{http_proxy}) {
> +                $aptconf = "Acquire::http::Proxy \"$dcconf->{http_proxy}\";\n";
> +            }
> +            my $aptcfn = "/etc/apt/apt.conf.d/76pveproxy";
> +            PVE::Tools::file_set_contents($aptcfn, $aptconf);
> +
> +            # Run apt as noninteractive
> +            my $cmd = [
> +                'env', 'DEBIAN_FRONTEND=noninteractive',
> +                'apt-get', '-q', '-y',

making this be quiet can make debugging errors after the fact much
harder.

> +                '-o', 'Dpkg::Options::=--force-confdef',
> +                '-o', 'Dpkg::Options::=--force-confold',

This is not always guaranteed to be safe.

> +                'dist-upgrade'
> +            ];
> +
> +            print "starting apt-get -y dist-upgrade\n" if !$param->{quiet};
> +
> +            if ($param->{quiet}) {

It happens in a worker task, what benefit has one silencing even more
output?

> +                PVE::Tools::run_command($cmd, outfunc => sub { }, errfunc => sub { });
> +            } else {
> +                PVE::Tools::run_command($cmd);
> +            }
> +
> +            return;
> +        };
> +
> +        return $rpcenv->fork_worker('aptupgrade', undef, $authuser, $realcmd);
> +
> +    },
> +});
> +
> __PACKAGE__->register_method({
>     name => 'changelog',
>     path => 'changelog',
> --
> 2.50.1



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
  2025-09-12  9:22 ` [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API Thomas Lamprecht
@ 2025-09-17 10:26   ` Florian Paul Azim Hoberg via pve-devel
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Paul Azim Hoberg via pve-devel @ 2025-09-17 10:26 UTC (permalink / raw)
  To: pve-devel; +Cc: Florian Paul Azim Hoberg

[-- Attachment #1: Type: message/rfc822, Size: 17664 bytes --]

From: Florian Paul Azim Hoberg <florian.hoberg@credativ.de>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
Date: Wed, 17 Sep 2025 10:26:34 +0000
Message-ID: <D1CC1A00-8AEB-4F67-AAFD-15363FC60A59@credativ.de>

Hey Thomas!


Thanks for the feedback and for taking the time to explain the reasoning.

Am 12.09.2025 um 11:22 schrieb Thomas Lamprecht <t.lamprecht@proxmox.com>:

Blindly upgrading can be dangerous and result in broken system, that's
why the Proxmox VE API only supports the interactive upgrade through
API using a html5 based shell to keep a (human) admin in the loop.

I do understand the concern about less experienced users and the potential risk of breaking a system through unattended upgrades. At the same time, I have a bit of a hard time fully seeing the reasoning here: the API already exposes very powerful and potentially destructive operations (like deleting a VM, removing storage, shutting down node(s)), which can also cause serious issues if used without proper understanding.

From my perspective, providing an API path for upgrades would simply allow those who know what they’re doing to automate their workflows in a cleaner way, without having to fall back to less direct methods (e.g. scripting around apt, HTML5 consoles, automating with Ansible or other lower-level tools). The responsibility for using such an API safely would still rest with the admin, just like with the other API endpoints and also doesn’t deprecate the current workflow. Instead, it would just add another option. Beside this, I honestly don’t really get the differences between:



Current / Console:
A user sees the pending packages that can be upgraded and clicks on upgrade. The HMTL5 console opens up including the upgrade command. At this point, the user sees the full package list and needs to confirm the upgrade process.

API:
An operator can fetch the list of pending packages that can be upgraded by the API and can decide on his own or by automated validations (white/blacklist, timing, dependencies etc.) to perform upgrades, which can be automatically called afterwards for each node without any further user/operator interaction.

Outcome:
In both ways, if an upgrade fails, a lesser experienced user runs into a problem which probably cannot be solved immediately. I don’t see huge differences, if those potential errors are now directly shown on a console or in a log file. Beside this, service related restarts, network changes (or even network card renaming [at least before pve9]) and many other reasons may cause additional issues and might detach a user from the html5 console.

In general, I think we can gain more benefits by adding such an API path where even third-party tools and automation stacks can simply use this to upgrade nodes in clusters based on their own abstracted logic without requiring any ssh access. Also, the Datacenter Manager could highly benefit from this: Right now, an Operator is required to have a direct connection to all (at least to the targeted) node(s) and clusters when being kicked to the node’s HMTL5 console for upgrading, while the Datacenter Manager already might have a network connectivity. For local clusters, this might still be easily solvable, but for clusters in different locations or even countries this might become a pain (where you especially want to separate the infrastructure and admin facing parts as much as possible).

So thanks for submitting a contribution, but we cannot accept this.

That said, I respect your position and appreciate the clarity of your response, and I hope you may reconsider this, independent of specific technical implementation details. Also, thank you for taking the time and efforts for the review!

Thanks,
Florian


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
@ 2025-09-12  6:34 Florian Paul Azim Hoberg via pve-devel
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Paul Azim Hoberg via pve-devel @ 2025-09-12  6:34 UTC (permalink / raw)
  To: pve-devel; +Cc: Florian Paul Azim Hoberg

[-- Attachment #1: Type: message/rfc822, Size: 13856 bytes --]

From: Florian Paul Azim Hoberg <florian.hoberg@credativ.de>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
Date: Fri, 12 Sep 2025 06:34:52 +0000
Message-ID: <99022DEC-C3F5-48FE-9F81-A262118D27F7@credativ.de>

Extend the PVE API by a new 'upgrade' path in the
apt path to perform 'apt-get -y dist-upgrade' on
the node in a noninteractive way to avoid blocking
the upgrade process.

Signed-off-by: Florian Paul Azim Hoberg @gyptazy <florian.hoberg@credativ.de>
---

PVE/API2/APT.pm | 78 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)

diff --git a/PVE/API2/APT.pm b/PVE/API2/APT.pm
index 0d07cf38..3f2d7807 100644
--- a/PVE/API2/APT.pm
+++ b/PVE/API2/APT.pm
@@ -417,6 +417,84 @@ __PACKAGE__->register_method({
    },
});

+__PACKAGE__->register_method({
+    name => 'upgrade_packages',
+    path => 'upgrade',
+    method => 'POST',
+    description =>
+        "This is used to upgrade the system to the latest packages (apt-get -y dist-upgrade).",
+    permissions => {
+        check => ['perm', '/nodes/{node}', ['Sys.Modify']],
+    },
+    protected => 1,
+    proxyto => 'node',
+    parameters => {
+        additionalProperties => 0,
+        properties => {
+            node => get_standard_option('pve-node'),
+            command => {
+                description => "Specify the command.",
+                type => 'string',
+                enum => [qw(upgrade)],
+            },
+            quiet => {
+                type => 'boolean',
+                description =>
+                    "Only produces output suitable for logging, omitting progress indicators.",
+                optional => 1,
+                default => 0,
+            },
+        },
+    },
+    returns => {
+        type => 'string',
+        description => 'The task UPID.',
+    },
+    code => sub {
+        my ($param) = @_;
+
+        my $rpcenv = PVE::RPCEnvironment::get();
+        my $dcconf = PVE::Cluster::cfs_read_file('datacenter.cfg');
+
+        my $authuser = $rpcenv->get_user();
+
+        my $realcmd = sub {
+            my $upid = shift;
+
+            # setup proxy for apt
+
+            my $aptconf = "// no proxy configured\n";
+            if ($dcconf->{http_proxy}) {
+                $aptconf = "Acquire::http::Proxy \"$dcconf->{http_proxy}\";\n";
+            }
+            my $aptcfn = "/etc/apt/apt.conf.d/76pveproxy";
+            PVE::Tools::file_set_contents($aptcfn, $aptconf);
+
+            # Run apt as noninteractive
+            my $cmd = [
+                'env', 'DEBIAN_FRONTEND=noninteractive',
+                'apt-get', '-q', '-y',
+                '-o', 'Dpkg::Options::=--force-confdef',
+                '-o', 'Dpkg::Options::=--force-confold',
+                'dist-upgrade'
+            ];
+
+            print "starting apt-get -y dist-upgrade\n" if !$param->{quiet};
+
+            if ($param->{quiet}) {
+                PVE::Tools::run_command($cmd, outfunc => sub { }, errfunc => sub { });
+            } else {
+                PVE::Tools::run_command($cmd);
+            }
+
+            return;
+        };
+
+        return $rpcenv->fork_worker('aptupgrade', undef, $authuser, $realcmd);
+
+    },
+});
+
__PACKAGE__->register_method({
    name => 'changelog',
    path => 'changelog',
--
2.50.1

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-09-17 13:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <99022DEC-C3F5-48FE-9F81-A262118D27F7@credativ.de>
2025-09-12  9:22 ` [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API Thomas Lamprecht
2025-09-17 10:26   ` Florian Paul Azim Hoberg via pve-devel
2025-09-12  6:34 Florian Paul Azim Hoberg via pve-devel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal