[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.
Havoc
More information about the dbus
mailing list