[pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
Thomas Lamprecht
t.lamprecht at proxmox.com
Fri Sep 12 11:22:30 CEST 2025
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 at 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
More information about the pve-devel
mailing list