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 ED7461FF0B2 for ; Mon, 24 Aug 2026 13:01:19 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A95A121589; Mon, 24 Aug 2026 13:01:19 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 24 Aug 2026 13:01:15 +0200 Message-Id: Subject: Re: applied: [PATCH datacenter-manager 1/1] fix #7135: openid auth: improve error logging From: "Lukas Wagner" To: "Thomas Ellmenreich" , "Lukas Wagner" , X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260821102147.220586-1-t.ellmenreich@proxmox.com> <178731214859.187715.588193495057111260.b4-ty@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1787569246088 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.669 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: RGKOYYLGTE6B7427QQOQU5SJH5EYIND5 X-Message-ID-Hash: RGKOYYLGTE6B7427QQOQU5SJH5EYIND5 X-MailFrom: l.wagner@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 Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon Aug 24, 2026 at 12:47 PM CEST, Thomas Ellmenreich wrote: > On Fri Aug 21, 2026 at 1:35 PM CEST, Lukas Wagner wrote: > > [snip] > >> Applied, thanks for the patch! >> >> I think the way you implemented this makes sense. Having the error with = the >> entire context in the system logs should make troubleshooting way easier= . We >> could still consider returning more details in the API response later, i= f we >> desire to, the current change does not limit us from doing so. >> >> It appears that PBS suffers from the same issue, could you maybe send a = patch >> for there as well? (cc @Chris) > > [snip] > > I'm just now looking into this. I decided to also see how PVE handles the > same situation, and it seems that all three products have a different > approach. I would propose changing them all to the approach implemented > with in patch. > > The approaches are as follows: > > PDM: shows a shallow error in the UI and logs the full error. > PBS: shows even less information in the UI and doesn't log anything. > PVE: shows the full error in the UI. > > I would create two patches to standardise the approaches to match PDM's > method. What does everyone else think? @Lukas, @Chris Seems good to me! I guess PVE could stay as is, although of course it probably wouldn't hurt to log to syslog as well. But the important part is that an admin gets *some* idea of what is going wrong, which is already the case if the full error is returned from the API. For PBS it definitely makes sense to use the same approach, especially since it uses the same underlying implementation as PDM.