[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

[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

Reply to: