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 4127372CA9 for ; Wed, 26 May 2021 11:40:27 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 347DEFFA5 for ; Wed, 26 May 2021 11:40:27 +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 45A3EFF9A for ; Wed, 26 May 2021 11:40:26 +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 0F6B04665F for ; Wed, 26 May 2021 11:40:26 +0200 (CEST) Date: Wed, 26 May 2021 11:40:23 +0200 From: Oguz Bektas To: Thomas Lamprecht Cc: Proxmox VE development discussion Message-ID: <20210526094023.GB14375@gaia.proxmox.com> Mail-Followup-To: Oguz Bektas , Thomas Lamprecht , Proxmox VE development discussion References: <20210525131711.1007675-1-o.bektas@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SPAM-LEVEL: Spam detection results: 1 AWL 1.169 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2021 09:40:27 -0000 hi, thanks for checking On Tue, May 25, 2021 at 03:45:53PM +0200, Thomas Lamprecht wrote: > On 25.05.21 15:17, Oguz Bektas wrote: > > this way when new containers are created the will have a unique > > /etc/machine-id > > > > why the dbus then? systemd talks explicitly only about /etc/machine-id > in the docs and also in their CT interface [0], the thematic is only touched > there though. > > The dbus one is most often a symlink to /etc/machine-id, removing that can > break things... in our ubuntu templates it exists as a regular file (not symlinked). so if that's not removed before first boot, it's copied to /etc/machine-id from there when the container boots. `man machine-id` tells me: When a machine is booted with systemd(1) the ID of the machine will be established. If systemd.machine_id= or --machine-id= options (see first section) are specified, this value will be used. Otherwise, the value in /etc/machine-id will be used. If this file is empty or missing, systemd will attempt to use the D-Bus machine ID from /var/lib/dbus/machine-id, the value of the kernel command line option container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a randomly generated UUID. 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 > > [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 > > [1]: https://forum.proxmox.com/threads/bug-machine-id-etc-machine-id-not-unique-in-lxc-containers.89708/post-392258 > > > @@ -491,6 +503,7 @@ sub pre_start_hook { > > sub post_create_hook { > > my ($self, $conf, $root_password, $ssh_keys) = @_; > > > > + $self->clear_machine_id($conf); > > only relevant for systemd envs. so it should be only called then, if we must call this > in such a general place. > > Either called in in the respective distro setup or check if any of "/lib/systemd/systemd" > or "/usr/lib/systemd/system" is executable for a heuristic to find out if the CT is > systemd managed. okay that makes sense i'll add that > > > $self->template_fixup($conf); > > > > $self->randomize_crontab($conf); > > > > this now depends on the patch which changed the private randomize_crontab helper > to a plugin method as the change is visible in the context, but that isn't mentioned > anywhere... guess i'll also remove this part based on your other email