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))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id AEA6274D2D
for <pve-devel@lists.proxmox.com>; Tue, 22 Jun 2021 17:23:47 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A05452A0D7
for <pve-devel@lists.proxmox.com>; Tue, 22 Jun 2021 17:23: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 id ED55D2A0CC
for <pve-devel@lists.proxmox.com>; Tue, 22 Jun 2021 17:23: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 B526846456
for <pve-devel@lists.proxmox.com>; Tue, 22 Jun 2021 17:23:46 +0200 (CEST)
Message-ID: <937cb49b-2b78-a565-ba0e-ceb9ba600689@proxmox.com>
Date: Tue, 22 Jun 2021 17:23:36 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101
Thunderbird/90.0
Content-Language: en-US
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
=?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= <f.gruenbichler@proxmox.com>
References: <20210622101657.2344347-1-f.gruenbichler@proxmox.com>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <20210622101657.2344347-1-f.gruenbichler@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.691 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -0.001 Looks like a legit reply (A)
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 1/2] postinst: set custom LVM
settings
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: Tue, 22 Jun 2021 15:23:47 -0000
On 22.06.21 12:16, Fabian Gr=C3=BCnbichler wrote:
> now that we no longer ship our own LVM packages, set the relevant
> filtering options here if they are missing.
>=20
> for an upgrade from PVE 6.x, the following two scenarios are likely:
>=20
> A: user edited config provided by our old lvm2 package. it likely
> contains our (or a modified) global_filter, but the old scan_lvs
> default. in this case we ignore global_filter as long as it contains ou=
r
> 'don't scan zvols' entry, and set scan_lvs to false.
>=20
> B: config provided by our old lvm2 package was taken over by default
> config from stock lvm2 package. scan_lvs defaults to false already, but=
> global_filter is unset (scan everything), so we need to set our own
> global_filter excluding zvols.
>=20
> other combinations should be handled fine as well.
>=20
> for new installs (installer, install on top of Debian Bullseye) we are
> always in scenario B.
>=20
> Signed-off-by: Fabian Gr=C3=BCnbichler <f.gruenbichler@proxmox.com>
> ---
>=20
> Notes:
> once other difference between our old config and the stock one is t=
hat we had
> 'issue_discards' enabled. we could either put this in the release n=
otes, or
> also enable it here automatically - but it is less straight-forward=
since the
> default is not "almost certainly wrong" like for the filtering opti=
ons..
> =20
> we could drop the "check for marker" and just do this once on initi=
al install
> and upgrades from 6.x, but since the fallout from not having these =
in place can
> be data corruption (activating multiple VGs with same name, using o=
ne from a
> guest on the host!) I'd rather play it safe..
>=20
> debian/postinst | 55 +++++++++++++++++++++++++++++++++++++++++++++++++=
> 1 file changed, 55 insertions(+)
>=20
> diff --git a/debian/postinst b/debian/postinst
> index dcf77d24..241aac08 100755
> --- a/debian/postinst
> +++ b/debian/postinst
> @@ -8,6 +8,58 @@ set -e
> # done its automatic conffile handling, and all the packages we depend=
> # of are already fully installed and configured.
> =20
> +LVM_CONF_MARKER=3D"# added by pve-manager to avoid scanning"
> +
> +set_lvm_conf() {
I'd maybe set the "don't whine about open FDs other than 0, 1, 2" flag he=
re (weird thing
to check for anyway):
export LVM_SUPPRESS_FD_WARNINGS=3D1
> + OLD_VALUE=3D"$(lvmconfig --typeconfig full devices/global_filter)"=
> + NEW_VALUE=3D'global_filter=3D["r|/dev/zd.*|"]'
> +
> + # only do these changes once
> + # keep user changes afterwards provided marker is still there..
> + if grep -qv "$LVM_CONF_MARKER" /etc/lvm/lvm.conf; then
the FD leak notice was always shown twice to me, so I checked more closel=
y and
even though my lvm.conf has the marker intact and a manual call of the gr=
ep
exits as expected the code still takes this branch, quite weird IMO & sur=
ely
something stupid on my side, but did not yet found the cause..
> + # check global_filter
> + # keep previous setting from our custom packaging if it is still ther=
e
> + if echo "$OLD_VALUE" | grep -qvF 'r|/dev/zd.*|'; then
> + SET_FILTER=3D1
> + BACKUP=3D1
> + fi
> + # should be the default since bullseye
> + if lvmconfig --typeconfig full devices/scan_lvs | grep -qv 'scan_lvs=3D=
0'; then
> + SET_SCAN_LVS=3D1
> + BACKUP=3D1
> + fi
> + if test -n "$BACKUP"; then
> + echo "Backing up lvm.conf before setting pve-manager specific set=
tings.."
> + 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 zvo=
ls from being scanned:"
> + echo "$OLD_VALUE =3D> $NEW_VALUE"
> + # comment out existing setting
> + sed -i -e 's/^\([[:space:]]*global_filter[[:space:]]*=3D\)/#\1/' =
/etc/lvm/lvm.conf
> + # add new section with our setting
> + cat >> /etc/lvm/lvm.conf <<EOF
> +devices {
> + $LVM_CONF_MARKER ZFS zvols
> + global_filter=3D$NEW_VALUE
> +}
> +EOF
> + fi
> + if test -n "$SET_SCAN_LVS"; then
> + echo "Adding scan_lvs=3D0 setting to /etc/lvm/lvm.conf to prevent=
LVs from being scanned."
> + # comment out existing setting
> + sed -i -e 's/^\([[:space:]]*scan_lvs[[:space:]]*=3D\)/#\1/' /etc/=
lvm/lvm.conf
> + # add new section with our setting
> + cat >> /etc/lvm/lvm.conf <<EOF
> +devices {
> + $LVM_CONF_MARKER LVM volumes
> + scan_lvs=3D0
> +}
> +EOF
> + fi
> + fi
> +}
> +
> case "$1" in
> triggered)
> # We don't print a status message here, as dpkg already said
> @@ -86,6 +138,9 @@ case "$1" in
> newaliases || true
> fi
> fi
> +
> + set_lvm_conf
> +
> ;;
> =20
> abort-upgrade|abort-remove|abort-deconfigure)
>=20