From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 558B39511C for ; Thu, 11 Apr 2024 19:15:47 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3D39D35854 for ; Thu, 11 Apr 2024 19:15:47 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 11 Apr 2024 19:15:46 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7F09A44C5F for ; Thu, 11 Apr 2024 19:15:46 +0200 (CEST) Message-ID: <54955321e5209dd5dc2222d7b27efc612ac89226.camel@proxmox.com> From: Alexander Zeidler To: Thomas Lamprecht , Proxmox VE development discussion Date: Thu, 11 Apr 2024 19:15:45 +0200 In-Reply-To: <8e717554-e3d8-4c97-8728-e8e8dc4885f4@proxmox.com> References: <20240322135933.164404-1-a.zeidler@proxmox.com> <20240322135933.164404-9-a.zeidler@proxmox.com> <8e717554-e3d8-4c97-8728-e8e8dc4885f4@proxmox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.098 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2024 17:15:47 -0000 On Mon, 2024-03-25 at 10:00 +0100, Thomas Lamprecht wrote: > On 22/03/2024 14:59, Alexander Zeidler wrote: > > * list availability and installation status of `*microcode` packages > > * grep for applied "Early OS Microcode Updates" > > * grep for (un)patched CPU vulnerability messages > >=20 > > Signed-off-by: Alexander Zeidler > > --- > > PVE/Report.pm | 2 ++ > > 1 file changed, 2 insertions(+) > >=20 > > diff --git a/PVE/Report.pm b/PVE/Report.pm > > index fe497b43..18c554ec 100644 > > --- a/PVE/Report.pm > > +++ b/PVE/Report.pm > > @@ -108,6 +108,8 @@ my $init_report_cmds =3D sub { > > 'dmidecode -t bios -q', > > 'dmidecode -t memory | grep -E "Capacity|Devices|Size|Manu|Part" | s= ed -Ez "s/\n\t(M|P)[^:]*: (\S*)/\t\2/g" | sort', > > 'lscpu', > > + 'apt list *microcode 2>/dev/null | column -tL', > > + 'dmesg | grep -i "microcode\|vuln"', >=20 > I'm wondering if instead of having a handful of dmesg + grep instances > it makes more sense to just add the whole dmesg output as separate > file. >=20 > I.e., I would like to have a cluster-wide report collection API that > spawns a task, calls to all nodes to generate a report, saves all of > those reports, including commands or files with very long output as > separate files, and then assembles an archive with all that. Great idea. The implementation of this seems not to be that trivial with our current code base, so I plan to work on this in the near future. And for a perhaps currently installed microcode package version, this can be well included into the pveversion -v output. Whether it has been applied at the current boot, will only later be visible in the dmesg file. So this patch can be dropped. >=20 > On the long run that would provide nicer UX and also avoid that some > to strict filter hides information that might be relevant for a > specific setup. >=20 > I'd much more prefer work time spent on something like that than on > adding the same command a few times with each having some different, > rather a bit brittle looking, pipe chains.. >=20 > > 'lspci -nnk', > > ], > > }, >=20