From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <o.bektas@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 28B7572D2E for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:04:07 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1737110704 for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:03:37 +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 57976106F9 for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:03:36 +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 291CC46667 for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:03:36 +0200 (CEST) Date: Wed, 26 May 2021 12:03:34 +0200 From: Oguz Bektas <o.bektas@proxmox.com> To: Thomas Lamprecht <t.lamprecht@proxmox.com> Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Message-ID: <20210526100334.GD14375@gaia.proxmox.com> Mail-Followup-To: Oguz Bektas <o.bektas@proxmox.com>, Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20210525131711.1007675-1-o.bektas@proxmox.com> <bc3cd68f-8780-04ce-2fa3-8b6bef19f787@proxmox.com> <20210526094023.GB14375@gaia.proxmox.com> <f3ee367a-4aba-f025-9d78-3364db34315e@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <f3ee367a-4aba-f025-9d78-3364db34315e@proxmox.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-SPAM-LEVEL: Spam detection results: 1 AWL 1.119 Adjusted score from AWL reputation of From: address 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 Subject: Re: [pve-devel] [PATCH container] fix #3443: setup: clear /etc/machine-id in post-create hook 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: Wed, 26 May 2021 10:04:07 -0000 On Wed, May 26, 2021 at 12:00:13PM +0200, Thomas Lamprecht wrote: > On 26.05.21 11:40, Oguz Bektas wrote: > > so without removing the dbus file we don't get a unique machine-id on container > > creation, since the templates seem to have a hardcoded id in the dbus path by > > default. we can also remove that but then we will have to make sure to do that > > for all the relevant templates > > Yes, but you must check if the dbus one is a symlinlk and if that's the case you > must not remove it. > > > > >> > >> [0] https://systemd.io/CONTAINER_INTERFACE/ > >> > >>> note that post_create_hook doesn't run for cloned containers so that > >>> will need to be handled separately > >>> > >> > >> If you read my post you also read that we must not remove the file in the > >> clone case. > > > > > > yes this hook doesn't run at clone so that's fine. > > > > > >> > >> We currently always generate a new random MAC-address for all netX devies of > >> a CT on clone, that suggests that we always want to truncate in the clone case, > >> to ensure that IPv6 SLAAC, among other things, can work OK. > >> > >> We could add a "unique" param to the clone call, but until now this was never > >> requested to be configurable. > > > > looking at the clone_vm api call i wasn't sure where to modify the file during > > clone. > > > > would it make sense to add this as a config option? we could set this to > > "uninitialized" in the container config by default. the "unique" param can then > > decide if the machine-id would be copied or truncated at clone. > > > > i'm open to ideas > > > > no, this would never be a config option as it's a flag for a one time action on > clone, not a permanent configuration relevant for the CT. sorry i meant here the machine-id as a container config option, and that the "unique" param could decide the action taken at clone > > The unique flag, if added, would be a basically a copy of the restore "unique" > flag we already have, but it would default to true for the clone case as we > basically have that assumption already (for the MAC regeneration). > > But as said, this is optional, the assumption is now already to make relevant > characteristics like MAC unique on clone, so we could default to that.