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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E481DBA0C6 for ; Wed, 13 Dec 2023 16:35:41 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C7802C5C7 for ; Wed, 13 Dec 2023 16:35:41 +0100 (CET) Received: from lana.proxmox.com (unknown [94.136.29.99]) by firstgate.proxmox.com (Proxmox) with ESMTP for ; Wed, 13 Dec 2023 16:35:40 +0100 (CET) Received: by lana.proxmox.com (Postfix, from userid 10043) id 9D3392C0C4F; Wed, 13 Dec 2023 16:35:40 +0100 (CET) From: Stefan Hanreich To: pve-devel@lists.proxmox.com Date: Wed, 13 Dec 2023 16:35:38 +0100 Message-Id: <20231213153538.358434-1-s.hanreich@proxmox.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.564 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 KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RDNS_NONE 0.793 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record T_SCC_BODY_TEXT_LINE -0.01 - Subject: [pve-devel] [PATCH pve-manager] postinst: Filter RADOS block devices 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: Wed, 13 Dec 2023 15:35:41 -0000 Since LVM 2.03.15 RBD devices are also scanned by default [1]. This can lead to guest volumes being recognized and displayed on the host when using KRBD for RBD-backed disks. In order to prevent this we add an additional filter to the LVM config to avoid scanning RADOS block devices. This also prevents a bug where LVM created a very high amount of archive entries when there were logical volumes with the same path available. This could happen when two guests with RBD disks had the same LVM layout or a guest and host had the same layout. The following cases can happen where postinst gets executed: Upgrading from < 8.1.4: We force the new global_filter to be set in the LVM config Upgrading from >= 8.1.4: do nothing New Installation: Run the function as before, just with the new global_filter value Signed-off-by: Stefan Hanreich --- I have tested this for all cases by executing the script manually in a VM. Just in the case of upgrading from < 8.1.4 the resulting LVM config is quite ugly: ``` devices { # added by pve-manager to avoid scanning ZFS zvols # global_filter=["r|/dev/zd.*|"] } devices { # added by pve-manager to avoid scanning ZFS zvols and RADOS block devices global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"] } ``` Trying to find and delete the existing, enclosing devices {} part also seemed a bit brittle to me, particularly since users could be adding custom values to this section as well - which we would have to handle then as well. Does anyone maybe have a better idea on how to handle this without generating such an ugly config? debian/postinst | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/debian/postinst b/debian/postinst index 4c9a1f250..59d88105c 100755 --- a/debian/postinst +++ b/debian/postinst @@ -9,21 +9,25 @@ set -e # installed and configured. set_lvm_conf() { + local FORCE="$1" + LVM_CONF_MARKER="# added by pve-manager to avoid scanning" # keep user changes afterwards provided marker is still there.. - if grep -qLF "$LVM_CONF_MARKER" /etc/lvm/lvm.conf; then + if grep -qLF "$LVM_CONF_MARKER" /etc/lvm/lvm.conf && test -z "$FORCE"; then return 0 # only do these changes once fi + FILTER_VALUE='"r|/dev/zd.*|","r|/dev/rbd.*|"' + OLD_VALUE="$(lvmconfig --typeconfig full devices/global_filter)" - NEW_VALUE='global_filter=["r|/dev/zd.*|"]' + NEW_VALUE="global_filter=[$FILTER_VALUE]" export LVM_SUPPRESS_FD_WARNINGS=1 # check global_filter # keep previous setting from our custom packaging if it is still there - if echo "$OLD_VALUE" | grep -qvF 'r|/dev/zd.*|'; then + if echo "$OLD_VALUE" | grep -qvF "$FILTER_VALUE"; then SET_FILTER=1 BACKUP=1 fi @@ -37,14 +41,14 @@ set_lvm_conf() { cp -vb /etc/lvm/lvm.conf /etc/lvm/lvm.conf.bak fi if test -n "$SET_FILTER"; then - echo "Setting 'global_filter' in /etc/lvm/lvm.conf to prevent zvols from being scanned:" + echo "Setting 'global_filter' in /etc/lvm/lvm.conf to prevent zvols and rbds from being scanned:" echo "$OLD_VALUE => $NEW_VALUE" # comment out existing setting sed -i -e 's/^\([[:space:]]*global_filter[[:space:]]*=\)/#\1/' /etc/lvm/lvm.conf # add new section with our setting cat >> /etc/lvm/lvm.conf <