[PATCH] Move machine-id to /var

[Havoc Pennington]

Alp Toker wrote:
> 
> I think Robert is onto something here. If the machine ID feature makes 
> it into the D-Bus specification, it'll be the first feature that I've 
> seen in the spec that requires non-obvious platform-specific code.
>

What do you mean concretely? It's a file with 16 characters and a 
newline in it. How is this "non-obvious" more so than anything else in dbus?

There's no working win32 port yet, so on Windows we don't know where 
this uuid will live. Windows will work differently because the way I 
want Windows dbus to go is that it does something sensible on Windows, 
rather than bizarrely emulate what we do on Linux. For example, we don't 
want to try and do something with a unix: address on Windows, instead we 
treat those addresses as unknown.

Presumably on Windows the uuid is as simple as a registry key in 
HKEY_LOCAL_MACHINE, or a file in an appropriate place on Windows, or 
whatever makes sense.

Though, since Windows lacks autolaunch (or will implement it 
differently), it could just ignore the machine id for now and nothing 
would break.

> Right now, managed D-Bus assemblies can be copied across Linux, FreeBSD, 
> Windows and various .NET runtimes without needing to be rebuilt or 
> configured at install time.

There's no reason that won't continue to be true afaik.

> I have already started work on a managed uuidgen utility and an 
> implementation of the relevant interface, but all the time I've been 
> writing this code I've been getting seriously bad vibes.

You'll have to be more concrete what the practical problem is.

If you want to reimplement all of dbus, it isn't going to be trivial, 
and you'll have to figure it out in detail. But users of your library 
need not be impacted.

> I don't see any good reason or means to reliably persist a "machine" 
> uuid since there is no such thing as a "machine" -- CPUs get hotswapped, 
> block devices get network mounted, disk images get copied, MAC addresses 
> change. This appears to be at best a misnomer, quite possibly a misfeature.

As it says in the documentation,
  "two processes with the same machine ID should be able to use shared 
memory, UNIX domain sockets, process IDs, and other features of the OS 
that require both processes to be running on the same OS kernel instance."

In other words, one ID per kernel. Also required is that the ID not 
change until the next reboot.

CPU hotswap / block devices / MAC addresses are *very deliberately* not 
involved in this UUID, because we aren't looking for a checksum of 
installed hardware. We're looking for a tag on the kernel.

It looks like this could be crisper in the spec (I see how a couple 
sentences there could be misunderstood) so we can clean up that 
language. It's not like the spec is crisp anywhere else though ;-)

But I don't see how this is hard to implement?

When the spec is unclear by all means raise questions on the list and 
let's get it clarified.

> As an implementer of the D-Bus spec, I have concerns about supporting 
> it, as a former packager I would be uncertain how to provide the 
> semantics you expect and as a system administrator who has deployed 
> large networked installations, the last thing I want is another 
> non-standard "machine" identifier, especially from what's meant to be a 
> simple IPC mechanism package.

Most apps avoid introducing a machine id like this because it requires 
adding an init script and/or %post scripts on Linux. However, since dbus 
already has an init script and we know we can get this set up right, 
there's no big issue.

If dbus solves this once, apps can all use that solution. No more 
"dammit, my desktop stopped working when I set the hostname" (KDE used 
to have some weird hack for this - I think it was a program called 
"kdontchangemyhostname" or something)

On Windows, at least when not running in reduced-privileges mode, the 
library/app itself can just do the uuid generation if the uuid is missing.

D-Bus is not meant to be a simple IPC mechanism package, btw. The spec 
(and FAQ) spell out what it's meant to be:

> D-Bus is designed for two specific use cases:
> 
> A "system bus" for notifications from the system to user sessions,
> and to allow the system to request input from user sessions.
> 
> A "session bus" used to implement desktop environments such as GNOME
> and KDE.
> 
> D-Bus is not intended to be a generic IPC system for any possible
> application, and intentionally omits many features found in other IPC
> systems for this reason. D-Bus may turn out to be useful in
> unanticipated applications, but future versions of this spec and the
> reference implementation probably will not incorporate features that
> interfere with the core use cases.
> 

In fact, the _primary_ purpose of dbus for the desktop in my mind isn't 
IPC at all, but all the policy around it - activation, lifecycle 
tracking, session scoping, security policy, and yes the machine id. 
These things provide fixed context and semantics that otherwise don't 
exist. IPC is easy; open a socket and dump stuff into it, there are a 
thousand protocols and libs for this, dbus offers nothing new.

Robert may be right that /var/lib causes issues vs. /var/run but this is 
an implementation point that can be adjusted if necessary. I think 
unless we have evidence /var/lib will break we should go with what the 
FHS says, and if in practice it causes a lot of issues we can move to 
/var/run with a compat symlink or something. Or just tell people to fix 
their stuff and follow the FHS, depending on who/how-many-people it breaks.

Havoc