[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)



On Thu, 08 Aug 2019 at 13:39:54 +0200, Marc Haber wrote:
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.

For historical reasons (dbus originated the concept and
systemd generalized it into a non-D-Bus-specific "API"), each of
systemd-machine-id-setup and dbus-uuidgen tries to copy the other's
machine ID, to avoid problems where processes that read the two files
in opposite orders disagree on what the machine's unique ID is.
If you delete or empty /etc/machine-id you should also delete
/var/lib/dbus/machine-id.

Making /etc/machine-id a 0-byte file is considered to be the canonical
way to clear it, rather than actually deleting it, because if systemd is
running on a completely read-only root filesystem, it has code to create
a machine ID on a tmpfs and bind-mount it over the top of the empty file.

If you are doing cloning, stateless systems or similar activities,
and you know you will have a valid /etc/machine-id (you either use
systemd or have taken other steps to have one), then you can make
/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a
systemd-tmpfiles file to do this). This is not done by default in Debian,
or by `dbus-uuidgen --ensure`, for historical reasons; maybe it should be,
but to be confident that it was a correct change I'd have to think about
the ways in which it might go wrong on non-systemd systems (with either
a non-systemd init like sysvinit, or no init at all like minimal chroots).

Maybe /etc/machine-id should be part of the "API" of a Debian system in
general (systemd or not)?

    smcv


Reply to: