dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id

[Jason Gerard DeRose]

If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id.

If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id.

Minor issue, but still a weird inconsistency between Ubuntu desktop and server.

Thanks!

[Jason Gerard DeRose (jderose)]

Side note: when /var/lib/dbus/machine-id is a symlink to /etc/machine-id, a related issue issue is that systemd fails to create the later when missing:

https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697

[Sebastien Bacher (seb128)]

your reference to the other issue is that bug itself, is that right?

[Jason Gerard DeRose (jderose)]

@seb128: yes.

The two are related in that when /var/lib/dbus/machine-id is a symlink, the act of starting the system dbus instance can't (or wont, I guess) generate a machine-id (as the path in question is there, just the symlink target is missing).

And because of lp:1508697, systemd doesn't inself create /etc/machine-id when missing, which it should.

This is an obscure issue in the end, but it's caused problems with the System76 imaging system. I've put a lot of effort into making sure things that should be unique between machines, things that are unique when you do a manual Ubuntu install, are actually unique when we image a system. I used to just delete /var/lib/dbus/machine-id when building our golden image tarballs and let dbus generate the machine-id with dbus-uuid upon first boot. Now I have to generate /etc/machine-id during imaging, before we boot into the installed OS.

[Martin Pitt (pitti)]

@Jason: What seb128 was asking is that you said "related issue is bug 1508697", but 1508697 is *this* bug. I. e comment #1 refers to itself.

I haven't investigated this much yet, but it seems two things are competing here:

  * /usr/lib/tmpfiles.d/dbus.conf will create the /var/lib/dbus/machine-id symlink to /etc/machine-id. I. e. this would happen on "first boot" *if* /var/lib/dbus/machine-id does not exist yet. This is what happens if you install from a desktop CD: livecd-rootfs removes machine-id from the image, so the first boot goes through that tmpfiles.d snippet and creates the symlink.

 * If you install server, that actually apt-get installs stuff including dbus. dbus.postinst calls "dbus-uuidgen --ensure" which according to NEWS

     • in "dbus-uuidgen --ensure", try to copy systemd's /etc/machine-id
       to /var/lib/dbus/machine-id instead of generating an entirely new ID
       (fd.o #77941, Simon McVittie)

So I think this fully explains the behaviour. I think what's right here is to change dbus-uuidgen --ensure to symlink /etc/machine-id instead of copying it. Simon, WDYT? After all, tools must already get along with a symlink due to the tmpfiles.d, and we are moving towards directly reading /etc/machine-id anyway, right?

[Simon McVittie (smcv)]

> systemd doesn't inself create /etc/machine-id when missing, which it should.

I think the solution to "my system-imaging setup isn't working" is to get that bug (presumably a systemd bug?) fixed - this one is rather minor by comparison. Do you have a correct bug# for it?

> I've put a lot of effort into making sure things that should be unique between machines, things that are unique when you do a manual Ubuntu install, are actually unique when we image a system.

Yeah, the list of things that should be unique has changed over time, unfortunately. I hope that future software needing a unique machine ID will just use /etc/machine-id, but D-Bus is older than systemd, so we didn't have that option at the time. Now /var/lib/dbus/machine-id needs to continue to exist, because some third party software depends on it, but libdbus doesn't actually rely on it any more - it will try reading both locations.

> After all, tools must already get along with a symlink due to the tmpfiles.d

Be a bit careful here... things must cope with /var/lib/dbus/machine-id being a symlink to /etc/machine-id *if we are booting with systemd*. If the init system is sysvinit or Upstart (still supported in Debian) then nothing guarantees there will ever be a /etc/machine-id.

However, systemd doesn't delete /etc/machine-id on purge, so after one has been created, I think it's guaranteed to stay.

I'd be happy to review a patch upstream that made _dbus_read_local_machine_uuid() with create_if_not_found=TRUE (i.e. the implementation of dbus-uuidgen --ensure) symlink the machine ID rather than copying it.

Alternatively, the postinst could create the symlink if /etc/machine-id exists and has syntactically valid contents, or run dbus-uuidgen --ensure if not.

[Martin Pitt (pitti)]

Simon McVittie [2015-10-29 11:55 -0000]:
> > systemd doesn't inself create /etc/machine-id when missing, which it
> should.
>
> I think the solution to "my system-imaging setup isn't working" is to
> get that bug (presumably a systemd bug?) fixed - this one is rather
> minor by comparison. Do you have a correct bug# for it?

Indeed, that would interest me as well.

> I'd be happy to review a patch upstream that made
> _dbus_read_local_machine_uuid() with create_if_not_found=TRUE (i.e. the
> implementation of dbus-uuidgen --ensure) symlink the machine ID rather
> than copying it.
>
> Alternatively, the postinst could create the symlink if /etc/machine-id
> exists and has syntactically valid contents, or run dbus-uuidgen
> --ensure if not.

Either approach sounds fine to me. Changing dbus-uuidgen seems a bit
more universal as then distros don't need to all do the same postinst
change and /etc/machine-id validity check (which dbus-uuidgen already
does), but either way it should be simple enough.

Thanks!

[Jason Gerard DeRose (jderose)]

Oops, sorry for the confusion, haven't been sleeping enough lately :P

I meant to refer to lp:1508766 which I filed about systemd not creating /etc/machine-id if it's missing:

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766

Now that /var/lib/dbus/machine-id is a symlink to /etc/machine-id (on Wily desktop), lp:1508766 has consequences for dbus in that it can no longer itself create the machine-id if "missing". Or at least dbus wont (and arguably it shouldn't... seems to me systemd should be doing this).

[Simon McVittie (smcv)]

> Or at least dbus wont (and arguably it shouldn't... seems to me systemd should be doing this)

I agree with that reasoning. It's fine for D-Bus to be responsible for creating its own older machine ID file if necessary, but it shouldn't be responsible for creating the one that belongs to systemd - that's systemd's job.

[Jason Gerard DeRose (jderose)]

Which I guess raises another question... when booting with sysvinit or Upstart, what should dbus do when /var/lib/dbus/machine-id is a symlink to /etc/machine-id and the latter doesn't exist?

[Simon McVittie (smcv)]

That situation should never arise, because if the symlink exists, then it was created by a successful boot with systemd sometime in the past; systemd's API is that it guarantees to create /etc/machine-id before running third-party code; and systemd never deletes the machine ID after it has created one.

The ideal behaviour would be for dbus-uuidgen to replace the symlink with a newly generated plain file, I think. I'd be happy to review a patch (on freedesktop.org Bugzilla please) if that isn't already what it does.