Re: [pve-devel] [PATCH manager 9/9] report: add microcode info to better assess possible system impacts

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

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
> 
> Signed-off-by: Alexander Zeidler <a.zeidler@proxmox.com>
> ---
>  PVE/Report.pm | 2 ++
>  1 file changed, 2 insertions(+)
> 
> 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 = sub {
>  		'dmidecode -t bios -q',
>  		'dmidecode -t memory | grep -E "Capacity|Devices|Size|Manu|Part" | sed -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"',

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.

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.

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.

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..

>  		'lspci -nnk',
>  	    ],
>  	},