From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <t.lamprecht@proxmox.com>
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) server-digest SHA256)
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id D3340BB647
for <pve-devel@lists.proxmox.com>; Mon, 25 Mar 2024 10:01:28 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id B967A2B6
for <pve-devel@lists.proxmox.com>; Mon, 25 Mar 2024 10:01:28 +0100 (CET)
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) server-digest SHA256)
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Mon, 25 Mar 2024 10:01:24 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 9046641A3C
for <pve-devel@lists.proxmox.com>; Mon, 25 Mar 2024 10:01:24 +0100 (CET)
Message-ID: <8e717554-e3d8-4c97-8728-e8e8dc4885f4@proxmox.com>
Date: Mon, 25 Mar 2024 10:00:36 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Alexander Zeidler <a.zeidler@proxmox.com>
References: <20240322135933.164404-1-a.zeidler@proxmox.com>
<20240322135933.164404-9-a.zeidler@proxmox.com>
Content-Language: en-GB
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20240322135933.164404-9-a.zeidler@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL -0.059 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
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [report.pm]
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2024 09:01:28 -0000
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',
> ],
> },