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 C88D972D2B for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:00:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BE1B31052A for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:00:15 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id ABA4A1051C for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:00:14 +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 8236D4665D for <pve-devel@lists.proxmox.com>; Wed, 26 May 2021 12:00:14 +0200 (CEST) Message-ID: <f3ee367a-4aba-f025-9d78-3364db34315e@proxmox.com> Date: Wed, 26 May 2021 12:00:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101 Thunderbird/89.0 Content-Language: en-US To: Oguz Bektas <o.bektas@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> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <20210526094023.GB14375@gaia.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.010 Adjusted score from AWL reputation of From: address 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 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:00:45 -0000 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. 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.