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 1C2461FF0AE for ; Tue, 13 Oct 2026 09:58:32 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A1EE321321; Tue, 13 Oct 2026 09:58:30 +0200 (CEST) Message-ID: <0a0cc579-80d3-4b81-8823-61bfe9d109e4@proxmox.com> Date: Tue, 13 Oct 2026 09:58:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH pve-mamager v4 2/3] api: apt: move proxy config to pmxcfs and symlink to it To: Thomas Lamprecht , pve-devel@lists.proxmox.com References: <20261012145712.296002-1-j.theisen@proxmox.com> <20261012145712.296002-3-j.theisen@proxmox.com> <21c83162-6324-4602-8ed8-282701020df1@proxmox.com> Content-Language: en-US From: Jonas Theisen In-Reply-To: <21c83162-6324-4602-8ed8-282701020df1@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791878306376 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.133 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) 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 Message-ID-Hash: LZMKVVXI252IG5QYYCEOFAK3F2CZPLLP X-Message-ID-Hash: LZMKVVXI252IG5QYYCEOFAK3F2CZPLLP X-MailFrom: j.theisen@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: On 10/12/26 18:33, Thomas Lamprecht wrote: > Am 12.10.26 um 16:57 schrieb Jonas Theisen: >> The APT proxy config was written to /etc/apt/apt.conf.d/76pveproxy >> only if a database update was triggered through the PVE tooling. > But your change here still needs such a refresh (or after the next > patch a change in proyy value) at least once per node, this is not > activated immediately automatically. After this patch would be applied only one more update through the PVE tooling would be necessary, since after that the symlink would be in place on all nodes. With the symlink the patched update call to the datacenter options would be enough since this also triggers an update of trhe proxy config in the pmxcfs. > typo: s/existance/existence/ > > > typo: s/unncessarry/unnecessary/ > typo: s/Updateing/Updating/ Will fix the typos, thanks! >> still works and only issues a warning. > But not if pmxcfs fails to start, which can make disaster recovery > harder. I mean, sure if pmxcfs fails to start completely it's gonna > be annoying either way, but still not a good excuse to add more > coupling to core system configs here. Alright then i'll rework this without relying on pmxcfs. >> Note that files in /etc/pve are not readable for users outside the >> www-data group, so APT invoked by such users will fail to read the >> proxy config. > But that's breaking existing unprivileged apt use cases then. Also > cases where some nodes use a different proxy than others, bit of an > odd edge case, but not nice to break, at least not as normal update > during a stable release series. Afaik, we currently do not support different proxies on different nodes as the http_proxy config is on the datacenter level and the daily database update job rewrites this config every time. If we want to do that we would need to move this option to the node level. > I'd rather skip this approach, at least in current form. A hook for > apt that checks configured and setup proxy and warns on mismatch > might be nicer here? If we really want to auto-apply it - which can > be probably OK, I just did not got around to think it fully through > - that hook could also do that and print a nice visible log line for > when something was changed, making the admin updating aware of it. I have already looked into the appropriate hook and will try to rework this to make use of that in v5.