Re: Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution
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
now.
S
Reply to: