From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id A82851FF0B7 for ; Fri, 02 Oct 2026 12:32:21 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A30D6216CB; Fri, 02 Oct 2026 12:32:18 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 02 Oct 2026 12:32:13 +0200 Message-Id: Subject: Re: [PATCH pve-manager v3 2/2] fix #8031: write APT proxy config on http_proxy change From: "Elias Huhsovitz" To: "Jonas Theisen" , X-Mailer: aerc 0.20.0 References: <20260915091758.85522-1-j.theisen@proxmox.com> <20260915091758.85522-3-j.theisen@proxmox.com> In-Reply-To: <20260915091758.85522-3-j.theisen@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790937133918 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.557 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) NUMERIC_HTTP_ADDR 0.001 Uses a numeric IP address in URL RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record WEIRD_PORT 0.001 Uses non-standard port number for HTTP Message-ID-Hash: AY76BKDYGSVMTBNCV3LKEA43SWJJ6UGO X-Message-ID-Hash: AY76BKDYGSVMTBNCV3LKEA43SWJJ6UGO X-MailFrom: e.huhsovitz@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: I tested this using a the baisc HTTP Proxy docker image ubuntu/squid: https://hub.docker.com/r/ubuntu/squid comments inlide. On Tue Sep 15, 2026 at 11:16 AM CEST, Jonas Theisen wrote: > Writes the necessary file for APT if the http_proxy variable > on the datacenter level is changed. > > This reuses the same function from the APT API for a regular > database update. > > Signed-off-by: Jonas Theisen > --- > PVE/API2/Cluster.pm | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/PVE/API2/Cluster.pm b/PVE/API2/Cluster.pm > index 4e5efbfd..efda3906 100644 > --- a/PVE/API2/Cluster.pm > +++ b/PVE/API2/Cluster.pm > @@ -36,6 +36,7 @@ use PVE::API2::ClusterConfig; > use PVE::API2::Firewall::Cluster; > use PVE::API2::HAConfig; > use PVE::API2::ReplicationConfig; > +use PVE::API2::APT; nit: imports are ordered Lexicographically. So the new import should be after ACMEPlugin, like this: use PVE::API2::ACMEPlugin; use PVE::API2::APT; > =20 > my $have_sdn; > eval { > @@ -842,8 +843,17 @@ __PACKAGE__->register_method({ > code =3D> sub { > my ($param) =3D @_; > =20 > + my $http_proxy_change =3D 0; > + > my $delete =3D extract_param($param, 'delete'); > =20 > + if ( > + defined($param->{http_proxy}) > + || (defined($delete) && $delete =3D~ m/\bhttp_proxy\b/) > + ) { > + $http_proxy_change =3D 1; > + } > + > cfs_lock_file( > 'datacenter.cfg', > undef, > @@ -859,6 +869,10 @@ __PACKAGE__->register_method({ > ); > die $@ if $@; > =20 > + if ($http_proxy_change) { > + PVE::API2::APT::update_apt_proxy_config(); > + } Potential Pitfall ----------------- The subroutine `update_apt_proxy_config` only writes the config to the local node, not the cluster. So we make a HTTP PUT request to the `/cluster/options` endpoint expecting a cluster wide change, but only the node that accepted the request actually updates their `/etc/apt/apt.conf.d/76pveproxy` config file.=20 I verified this behaviour on a 2 node cluster. My take ------- >>From the top of my head 2 solutions come to mind: 1. Create a `update_apt_proxy_config_cluster()` subroutine that applies the changes cluster wide. Then simply call this function, instead of `update_apt_proxy_config()` 2. Create some kind of sync mechanism based on changes to the datacenter.cfg. (also would need some kind of=20 `update_apt_proxy_config_cluster()` subroutine) This could consist of 2 functions: * synch on change: You check diff between the previous datacenter.cfg and the new datacenter.cfg.=20 You apply the changes to all nodes in the cluster. e.g. if the `http_proxy` parameter is changed: update `76pveproxy` for all nodes in the cluster * sync on demand: You go through the datacenter.cfg. For each config that needs additional settings on the host (e.g. `http_proxy`), apply the changes. e.g. I manually edit datacenter.cfg to set=20 `http_proxy: http://192.168.29.70:3128` I run the new subroutine `sync_datacenter_cfg`. All nodes in the cluster now contain: 76pveproxy contents: Acquire::http::Proxy "http://192.168.29.70:3128"; This function has to be idempotent. (Perhaps something like this already exists, I am not 100% sure atm) =20 Let me know if this makes sense, or if you come up with a better solution! > + > return undef; > }, > }); =09