Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)
On Tue, 13 Aug 2019 at 11:50:27 +0200, Marc Haber wrote:
> On Thu, 8 Aug 2019 22:44:19 +0100, Simon McVittie <smcv@debian.org>
> wrote:
> >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.
>
> And what will systemd do when it encounters a zero-sized
> /etc/machine-id on a writable filesystem?
Replace it with a new machine ID, the same as if it didn't exist at all:
After the machine ID is established, systemd(1) will attempt to save it
to /etc/machine-id. If this fails, it will attempt to bind-mount a
temporary file over /etc/machine-id. It is an error if the file system
is read-only and does not contain a (possibly empty) /etc/machine-id
file.
— machine-id(5)
(systemd cannot create a mount point that doesn't exist yet on a read-only
file system, which is why a zero-byte file is preferred.)
> >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
>
> Interesting, I see this on a number of my test systems without having
> been active in this regard myself.
If you use systemd as init, install dbus, delete or empty /etc/machine-id,
delete /var/lib/dbus/machine-id and reboot, then systemd will recreate
/etc/machine-id very early in the boot process. Less early but still early
in the boot process (before units with DefaultDependencies=yes, analogous
to rcS in sysvinit), systemd-tmpfiles will make /var/lib/dbus/machine-id
a symlink as directed by /usr/lib/tmpfiles.d/dbus.conf. By the time
ordinary system services start, it is already a symlink. Might this be
what happened on your test systems?
I'm fairly sure that dbus-uuidgen (which is run in dbus.postinst,
and from /etc/init.d/dbus on non-systemd systems) always makes
/var/lib/dbus/machine-id a regular file rather than a symlink, but if
you already had dbus installed before you reset the machine ID, and you
did not subsequently boot with a non-systemd init, then dbus-uuidgen
wouldn't have been run. If /var/lib/dbus/machine-id is already a symlink
to a file with contents in the right format, dbus-uuidgen won't replace it.
> >Maybe /etc/machine-id should be part of the "API" of a Debian system in
> >general (systemd or not)?
>
> please elaborate on that.
There are some properties that we guarantee every Debian system will have,
even though they cannot be guaranteed on every GNU or Linux system. For
example, Policy guarantees that /var/run is always a symlink to /run on
Debian systems (even though they are distinct directories on e.g.
Slackware[1], and as a result upstream projects like dbus can't rely on
/var/run being equivalent to /run). Similarly, we guarantee that all
Debian systems will have the base-passwd users and groups, with their
canonical numeric values.
Some of those properties either originated in systemd and were adopted in
Debian for even non-systemd systems (for example /usr/lib/os-release in
base-files, which originated in systemd as a replacement for lsb_release
and distro-specific facilities like /etc/debian_version), or originated in
Debian or some other distro and have been adopted by systemd as one of its
"API" guarantees on all distros that use it (for example systemd picked
up Debian's /etc/hostname, /etc/timezone and /etc/sysctl.d). In both
cases this is done on the basis that regardless of origin, they are good
ideas that should be spread further, and giving application and library
maintainers more "API" guarantees from the OS makes their jobs easier.
What I'm suggesting is that maybe a systemd-style /etc/machine-id should
be one of those properties that we guarantee, instead of relying on dbus
(which is an IPC system that has very little to do with uniquely
identifying a machine) to provide the closest thing that is guaranteed on
non-systemd-booted machines.
Because systemd does not delete /etc/machine-id even when purged (that
would be counterproductive for its intended purpose, and would break
stored state that refers to it), it is present on all systems that either
boot with systemd or have switched from systemd to sysvinit. The only
Debian systems that will not already have /etc/machine-id are those that
were installed before systemd became the default (wheezy or older) or
as a minimal debootstrap with no init system at all (jessie or newer),
may have subsequently been upgraded to newer suites, but have never run
systemd.postinst or booted with systemd.
smcv
[1] I think this is an unwise design decision, and with my dbus upstream
hat on I tried to get it changed, but I was not successful.
Reply to: