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 > now.
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: http://0pointer.de/blog/projects/stateless.html Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878un6mx6o.wl%jer...@dekkers.ch