Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution
At Sat, 02 Aug 2014 14:35:33 +0100,
Simon McVittie wrote:
> On 02/08/14 08:03, Charles Plessy wrote:
> > A straightforward way is exemplified by the case of SSH, where the server keys
> > are regenerated if they are absent. It then only takes to delete the keys when
> > preparing images to avoid the problem of duplicated IDs or privacy leaks.
> D-Bus (/var/lib/dbus/machine-id) also regenerates its machine ID during
> boot if required, although systemd (/etc/machine-id) is not always able
> to do so (because it's pid 1, and our initramfs does not fsck the root
> filesystem, systemd typically starts before the root filesystem is
> read/write, but it wants to be able to have a machine ID immediately).
> As of jessie, each will copy the other's idea of the machine ID if it
> exists, or create a new one if not; in wheezy, systemd would copy the
> D-Bus machine ID, but D-Bus would create a new ID rather than copying
> the one from systemd.
> Some component still needs to know that those specific files should be
> reset when preparing a generic image, and how to reset them - for
> systemd it is actually better to truncate /etc/machine-id than to delete
> it, because if it exists as an empty file, systemd can do tricks with
> bind-mounts to mount a transient machine-id over the top, copying the
> one from dbus if available.
> Perhaps it would be good to define a "reset-machine-state" dpkg trigger
> or something; then tools like live-build could trigger it, and dbus
> could take responsibility for deleting /var/lib/dbus/machine-id when it
> is triggered? live-build etc. would have to keep their current hooks for
I really like the idea proposed by the systemd developers: it should
be possible to just remove /etc and/or /var and the system should boot
and populate /etc and /var with the necessary files: