[Pkg-zfsonlinux-devel] Bug#595790: Bug#595790: hostid: useless unless fixed

[Petter Reinholdtsen]

[Aurelien Jarno]
> In any case it looks to me we should not reinvent the wheel. We
> already ended-up with two implementations of a unique machine ID, one
> in dbus and one for systemd (which fortunately now try to just copy
> the other one if it already exists), I am not sure we want a third
> one. Could we just copy (part) of this ID if it exists, otherwise
> generate a random number? Or even point the current gethostid() to
> /etc/machine-id if it exists?

Peeking at the dbus and systemd UUID (and perhaps preferring them over
the DMI UUID) seem like a good idea, as long as /etc/hostid is updated
once during installation.  Perhaps glibc is the wrong place to do this.
Perhaps a debian-installer udeb is a better place?  It will of course
miss out chroots, which is unfortunate.

We have /etc/machine-id from systemd, /var/lib/dbus/machine-id from dbus
and /sys/class/dmi/id/product_uuid from DMI which all contain 128 bits
coded as hexadecimal numbers.  I guess using the lower 32 bits for
gethostid() is as good as any of the other options.

> I am not even sure it's a good idea to fix this, it might be better to
> just mark this function as deprecated, and encourage existing users of
> this function (including hostid) to use something much longer than
> 32-bit to avoid collisions.

Mentioning alternatives with more bits in the gethostid() manual page
definitely sound like a good idea.

> One thing is sure however, if we change the current behaviour, it will
> change the hostid on many systems, including ones which do not return
> 007f0101.

I agree what it should not be done automatically on existing
installation.  This is why I propose to set a value in /etc/hostid only
on first time installation of libc6, and document in the manual page how
to set it for those that want to modify an existing installation.

-- 
Happy hacking
Petter Reinholdtsen