public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Florian Paul Azim Hoberg <florian.hoberg@credativ.de>,
	"pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
Date: Fri, 12 Sep 2025 11:22:30 +0200	[thread overview]
Message-ID: <a8a5c23b-04fd-4de9-8ffe-616013d3a974@proxmox.com> (raw)
In-Reply-To: <99022DEC-C3F5-48FE-9F81-A262118D27F7@credativ.de>

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


       reply	other threads:[~2025-09-12  9:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <99022DEC-C3F5-48FE-9F81-A262118D27F7@credativ.de>
2025-09-12  9:22 ` Thomas Lamprecht [this message]
2025-09-12  6:34 Florian Paul Azim Hoberg via pve-devel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a8a5c23b-04fd-4de9-8ffe-616013d3a974@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=florian.hoberg@credativ.de \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal