[PATCH] Move machine-id to /var

Havoc Pennington hp at redhat.com
Tue Oct 24 11:31:28 PDT 2006

Robert McQueen wrote:
> Not just whether it's writable or not, but whether it's shared between
> systems. There's a big difference for something in /var/run is expected
> to exist only for the lifetime of that boot, and something in /var/lib
> should be made at install-time and persist indefinitely. If the latter,
> and it's supposed to be machine-unique, it makes it harder to roll
> out/clone in large deployments because you need to go back and
> change/remove something in /var/lib.

Do you know whether any common deployment setups use a shared /var/lib? 
According to FHS it is supposed to be host-specific and writable, which 
is exactly what we want. FHS says /var/run has to get nuked on each boot 
which is the big difference from /var/lib, but /var/run sounds otherwise 
the same FHS-wise.

> I wasn't aware this was part of the purpose of the ID, just that it was
> for clients (and particularly autostarting) to know whether they were
> connected to the same systems' bus. If it's only *necessary* for the
> autostarting stuff, we should only provide the semantics that are
> required for that to work.

I'd also like to just solve the problem that Linux systems don't have a 
convenient machine id. It seems like a solution to that would be pretty 
much the same as our machine id, so why shouldn't we just solve it?

> It's not of huge importance, but I still think it's worth changing,
> because the inconvenience to giving people an additional
> post-image-creation step before cloning or burning systems (or risk
> confusing the applications who have decided to use the ID...), etc, is
> something they won't thank us for.

On the other hand, if a low-level system component like dbus solves 
this, then it's just solved and only has to be addressed once when 
creating a deployment setup - apps above dbus don't need to worry about 
it or hand-roll their own approach.


More information about the dbus mailing list