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 5318D91DAD for ; Wed, 31 Jan 2024 14:15:28 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 340903AB28 for ; Wed, 31 Jan 2024 14:15: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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 31 Jan 2024 14:15:27 +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 3F29D4936D for ; Wed, 31 Jan 2024 14:15:27 +0100 (CET) Date: Wed, 31 Jan 2024 14:15:20 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20240130184041.1125674-1-m.carrara@proxmox.com> <20240130184041.1125674-9-m.carrara@proxmox.com> In-Reply-To: <20240130184041.1125674-9-m.carrara@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1706706610.ib4jz5o98v.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.065 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 T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH pve-manager 8/8] fix #4759: debian/postinst: configure ceph-crash.service and its key 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, 31 Jan 2024 13:15:28 -0000 On January 30, 2024 7:40 pm, Max Carrara wrote: > This commit adds the `set_ceph_crash_conf` function, which dynamically > adapts the host's Ceph configuration in order to allow the Ceph crash > module's daemon to run without elevated privileges. >=20 > This adaptation is only performed if: > * Ceph is installed > * Ceph is configured ('/etc/pve/ceph.conf' exists) > * Connection to RADOS is successful >=20 > If the above conditions are met, the function will ensure that: > * Ceph possesses a key named 'client.crash' > * The key is saved to '/etc/pve/ceph/ceph.client.crash.keyring' > * A section for 'client.crash' exists in '/etc/pve/ceph.conf' > * The 'client.crash' section has a key named 'keyring' which > references '/etc/pve/ceph/ceph.client.crash.keyring' >=20 > Furthermore, if a key named 'client.crash' already exists within the > cluster, it shall be reused and not regenerated. Also, the > configuration is not altered if the conditions above are already met. >=20 > This way the keyring file is available as read-only in > '/etc/pve/ceph/' for the `www-data` group (due to how pmxcfs works). > Because the `ceph` user has been made part of said `www-data` group > [0], it may access the file without requiring any additional > privileges. >=20 > Thus, the configuration for the Ceph crash daemon is safely adapted as > expected by PVE tooling and also shared via pmxcfs across one's > cluster. >=20 > [0]: https://git.proxmox.com/?p=3Dceph.git;a=3Dcommitdiff;h=3Df72c698a559= 05d93e9a0b7b95674616547deba8a >=20 > Signed-off-by: Max Carrara > --- > debian/postinst | 109 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 109 insertions(+) >=20 > diff --git a/debian/postinst b/debian/postinst > index 00d5f2cc..8d2a8c4b 100755 > --- a/debian/postinst > +++ b/debian/postinst > @@ -110,6 +110,114 @@ migrate_apt_auth_conf() { > fi > } > =20 > +set_ceph_crash_conf() { > + PVE_CEPH_CONFFILE=3D'/etc/pve/ceph.conf' > + PVE_CEPH_CONFDIR=3D'/etc/pve/ceph' > + PVE_CEPH_CRASH_KEY=3D"${PVE_CEPH_CONFDIR}/ceph.client.crash.keyring" > + PVE_CEPH_CRASH_KEY_REF=3D"${PVE_CEPH_CONFDIR}/\$cluster.\$name.keyri= ng" > + > + # ceph isn't installed -> nothing to do > + if ! which ceph > /dev/null 2>&1; then > + return 0 > + fi > + > + # ceph isn't configured -> nothing to do > + if test ! -f "${PVE_CEPH_CONFFILE}"; then > + return 0 > + fi > + > + CEPH_AUTH_RES=3D"$(ceph auth get-or-create client.crash mon 'profile= crash' mgr 'profile crash' 2>&1 || true)" > + > + # ceph is installed and possibly configured, but no connection to RA= DOS > + # -> assume no monitor was created, nothing to do > + if echo "${CEPH_AUTH_RES}" | grep -i -q 'RADOS object not found'; th= en > + return 0 > + fi the stuff after this point basically duplicates a lot of things from pveceph in shell.. wouldn't it be easier to have a pveceph reinit or similar command (or a parameter to an existing one) and call that here? or, for even less coupling (and thus chance of things going wrong and interrupting the upgrade), include a check somewhere in the ceph status code path and just add a warning if the key is not configured, with a hint what command to run/button to click to do the setup? > + SECTION_RE=3D'^\[\S+\]$' > + CRASH_SECTION_RE=3D'^\[client\.crash\]$' > + > [..]