From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <d.jaeger@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 CEB256554F for <pve-devel@lists.proxmox.com>; Thu, 23 Jul 2020 09:17:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C1C2325DA4 for <pve-devel@lists.proxmox.com>; Thu, 23 Jul 2020 09:17:17 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 E80AB25D99 for <pve-devel@lists.proxmox.com>; Thu, 23 Jul 2020 09:17:16 +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 AD7374331D for <pve-devel@lists.proxmox.com>; Thu, 23 Jul 2020 09:17:16 +0200 (CEST) Date: Thu, 23 Jul 2020 09:17:11 +0200 From: Dominic =?iso-8859-1?Q?J=E4ger?= <d.jaeger@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com> Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Message-ID: <20200723071711.GA5243@mala.proxmox.com> References: <20200722102052.25546-1-d.jaeger@proxmox.com> <94ed3288-870c-af50-f4a6-c0b03b1b30e8@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94ed3288-870c-af50-f4a6-c0b03b1b30e8@proxmox.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SPAM-LEVEL: Spam detection results: 0 AWL 2.174 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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 docs 1/2] pvecm: Add required -r to rm 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: Thu, 23 Jul 2020 07:17:17 -0000 On Wed, Jul 22, 2020 at 12:31:53PM +0200, Thomas Lamprecht wrote: > On 22.07.20 12:20, Dominic Jäger wrote: > > /etc/corosync/* includes the directory uidgid.d. > > Consequentlly, a correct rm call requires -r. > > Does leaving this directory left-over causes any issues? When I tested this it was empty. It should contain some optional permissions for corosync [0]. We later say "(...) delete all remaining files left from the old cluster. This ensures that the node can be added to another cluster again without problems." Couldn't those permissions then be active in a potential new cluster? > IIRC, I omit the "-r" explicitly as there can be also a directory from > a qdevice or other ones, which we do not want to remove - to level > corosync/* files where all desired to be removed, thus this rm varian. Looking at the quote from before, why do we want some connection to the qdevice to remain? > But, maybe we should rather change it to: > # rm -f /etc/corosync/corosync.conf /etc/corosync/authkey I just tried it without -f: root@pveA:/etc/corosync# ls authkey corosync.conf uidgid.d root@pveA:/etc/corosync# rm /etc/corosync/corosync.conf /etc/corosync/authkey root@pveA:/etc/corosync# ls uidgid.d And the node was removed from the cluster as expected. I can test it with permissions and qdevice, too. Would just have look up how that actually works. [0] https://www.mankier.com/8/pcs (ctrl+f for uidgid)