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 <[email protected]> > --- > > 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 [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
