Bug 23679

The patch changes existing behaviour.

We recommend that D-Bus installations over network simply create /var/lib/dbus/machine-id on boot. You can cat the contents of the unique boot ID into the file yourself, or you can run dbus-uuidgen --ensure in a boot script.

(In reply to comment #1)
> The patch changes existing behaviour.
> 
> We recommend that D-Bus installations over network simply create
> /var/lib/dbus/machine-id on boot. You can cat the contents of the unique boot
> ID into the file yourself, or you can run dbus-uuidgen --ensure in a boot
> script.

Hi Thiago

This D-Bus installation is into a prefix, as a 'stack' of software provided so we can use recent versions of all the libraries even on ancient Linux distributions (eg. RHEL 3/4). At the moment D-Bus tries to read $PREFIX/var/lib/dbus/machine-id; in our case that's some file in eg. /opt/package/

It'd be nice to avoid the need to install a system-wide init script to get this software working. I've had an idea though; what if I changed D-Bus to optionally take the UUID from a file named by an environment variable; maybe DBUS_UUID_FILE. If the environment variable is not set, the default file is read.

Then I could make the UUID reading code ignore '-' characters in the file contents, so that you can specify the Linux /proc file via that environment variable. Existing behaviour doesn't change, but it's suddenly easier to use D-Bus for software like this on a cluster.

Thanks for the feedback on the patch!

You should install software properly. Set D-Bus to search /var/lib/dbus/machine-id, not $PREFIX/var/lib/..... When configuring it:

./configure --localstatedir=/var

The default-supplied init script already runs dbus-uuidgen --ensure. All you need to do is configure it properly before installing.

The main problem with this is that we actually need the uuid to be persistent across restarts.

The machine uuid allows, for example, saving user per-machine preferences (think e.g. per-user monitor state).

You may not care about breaking this kind of thing if your home directories are also fixed to a machine, but rather than generating a random one from each boot, you could write a script to generate a predictable one from e.g. the machine MAC address.  The UUID doesn't need to be secret, just available and persistent.

Actually, I don't mind using the boot ID as the D-Bus machine ID. I even suggested a way for the the reporter do exactly that.

What I disagree with is making this the fix for improper installation. Therefore, I don't see the need to accept this patch.

Colin: the D-Bus machine ID is not guaranteed to be persistent across reboots. Some machines generate it on boot already, such as terminal clients or network boots.

(In reply to comment #5)
>
> Colin: the D-Bus machine ID is not guaranteed to be persistent across reboots.
> Some machines generate it on boot already, such as terminal clients or network
> boots.

Of course, anyone can do anything by hacking arbitrary changes into custom network boot scripts.

The point though is that the machine UUID is presently a good thing to use for software that wants, well, a machine-specific arbitrary unique key.  Useful for implementing something equivalent to HKEY_LOCAL_MACHINE if you're familiar with the Windows registry for example.

Concretely, say in GNOME we wanted to save the per-user monitor configuration (sizing, rotation).  It's very convenient to key this off of the machine UUID, so it works even in shared home directory scenarios.

People doing network boots could, for whatever their deployment is, generate a *stable* uuid from some machine characteristic (ethernet MAC e.g.).

If we add a configure or runtime option to make it random, this important characteristic of the DBus UUID is lost.

Sorry, I just repeated comment 4 without realizing I'd posted it here earlier.

It's funny how similar my new and old comments are...anyways =)

The UUID is guaranteed to remain stable within one boot session. But we've never promised it remains stable across them. Therefore, it must never be committed to permanent storage.

It has never had that characteristic.

We may want to add it, but we haven't yet.

Bug #42531 (Android support) has a related patch.

(In reply to comment #8)
> Therefore, it must never be committed to permanent storage.

From context, I think Thiago meant: it is not guaranteed to be committed to permanent storage.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/20.