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 087DE820B8 for ; Fri, 26 Nov 2021 17:45:19 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F332A1B254 for ; Fri, 26 Nov 2021 17:44:48 +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 id B34C61B245 for ; Fri, 26 Nov 2021 17:44:47 +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 8E0BC45F8A for ; Fri, 26 Nov 2021 17:44:47 +0100 (CET) From: Aaron Lauterer To: pve-devel@lists.proxmox.com Date: Fri, 26 Nov 2021 17:44:45 +0100 Message-Id: <20211126164446.2558368-2-a.lauterer@proxmox.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211126164446.2558368-1-a.lauterer@proxmox.com> References: <20211126164446.2558368-1-a.lauterer@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.069 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 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 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. [asciidoctor.org] Subject: [pve-devel] [PATCH docs 2/3] storage: rbd: cephs: update authentication section 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: Fri, 26 Nov 2021 16:45:19 -0000 It is not needed anymore to place the keyring/secret file manually in the correct location as it can be done with pvesm and the GUI/API now. Signed-off-by: Aaron Lauterer --- Since both sectons share the same footnote, I tried to get them to share the same with footnote:[here some text] and footnote:[] to reference it as explained in the asciidoc documentation [0]. Unfortunately I did not get it to work, most likely because they are both in separate files? I rather err on having the same footnote twice than missing it in one place. [0] https://docs.asciidoctor.org/asciidoc/latest/macros/footnote/ pve-storage-cephfs.adoc | 31 ++++++++++++++++++------------- pve-storage-rbd.adoc | 28 +++++++++++++++++++--------- 2 files changed, 37 insertions(+), 22 deletions(-) diff --git a/pve-storage-cephfs.adoc b/pve-storage-cephfs.adoc index c67f089..2437859 100644 --- a/pve-storage-cephfs.adoc +++ b/pve-storage-cephfs.adoc @@ -71,31 +71,36 @@ disabled. Authentication ~~~~~~~~~~~~~~ -If you use `cephx` authentication, which is enabled by default, you need to copy -the secret from your external Ceph cluster to a Proxmox VE host. +If you use `cephx` authentication, which is enabled by default, you need to provide +the secret from the external Ceph cluster. -Create the directory `/etc/pve/priv/ceph` with +The secret file is expected to be located at - mkdir /etc/pve/priv/ceph + /etc/pve/priv/ceph/.secret -Then copy the secret +You can copy the secret with - scp cephfs.secret :/etc/pve/priv/ceph/.secret + scp :/etc/ceph/cephfs.secret /local/path/to/.secret -The secret must be renamed to match your ``. Copying the -secret generally requires root privileges. The file must only contain the -secret key itself, as opposed to the `rbd` backend which also contains a -`[client.userid]` section. +If you use the `pvesm` CLI tool to configure the external RBD storage, use the +`--keyring` parameter, which needs to be a path to the secret file that you +copied. + +When configuring an external RBD storage via the GUI, you can copy and paste +the secret into the appropriate field. + +The secret is only the key itself, as opposed to the `rbd` backend which also +contains a `[client.userid]` section. A secret can be received from the Ceph cluster (as Ceph admin) by issuing the command below, where `userid` is the client ID that has been configured to access the cluster. For further information on Ceph user management, see the -Ceph docs footnote:[Ceph user management -{cephdocs-url}/rados/operations/user-management/]. +Ceph docs.footnote:[Ceph user management +{cephdocs-url}/rados/operations/user-management/] ceph auth get-key client.userid > cephfs.secret -If Ceph is installed locally on the PVE cluster, that is, it was set up using +If Ceph is installed locally on the {pve} cluster, that is, it was set up using `pveceph`, this is done automatically. Storage Features diff --git a/pve-storage-rbd.adoc b/pve-storage-rbd.adoc index bbc80e2..1f14b7c 100644 --- a/pve-storage-rbd.adoc +++ b/pve-storage-rbd.adoc @@ -69,23 +69,33 @@ TIP: You can use the `rbd` utility to do low-level management tasks. Authentication ~~~~~~~~~~~~~~ -If you use `cephx` authentication, you need to copy the keyfile from your -external Ceph cluster to a Proxmox VE host. +If you use `cephx` authentication, which is enabled by default, you need to +provide the keyring from the external Ceph cluster. -Create the directory `/etc/pve/priv/ceph` with +The keyring file is expected to be at - mkdir /etc/pve/priv/ceph + /etc/pve/priv/ceph/.keyring -Then copy the keyring +You can copy the keyring with - scp :/etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/.keyring + scp :/etc/ceph/ceph.client.admin.keyring /local/path/to/.keyring -The keyring must be named to match your ``. Copying the -keyring generally requires root privileges. +If you use the `pvesm` CLI tool to configure the external RBD storage, use the +`--keyring` parameter, which needs to be a path to the keyring file that you +copied. -If Ceph is installed locally on the PVE cluster, this is done automatically by +When configuring an external RBD storage via the GUI, you can copy and paste the +keyring into the appropriate field. + +If Ceph is installed locally on the {pve} cluster, this is done automatically by 'pveceph' or in the GUI. +TIP: Creating a keyring with only the needed capabilities is recommend when +connecting to an external cluster. For further information on Ceph user +management, see the Ceph docs.footnote:[Ceph user management +{cephdocs-url}/rados/operations/user-management/] + + Storage Features ~~~~~~~~~~~~~~~~ -- 2.30.2