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

[Aurelien Jarno <aurelien@aurel32.net>]

On 2016-09-28 09:33, Petter Reinholdtsen wrote:
> Control: reassign -1 libc6
> Control: found -1 2.19-18
> Control: The value from gethostid() should be more unique and not change when the host IP changes
> 
> Reassigning to glibc as that is the source of gethostid() where the
> problem with the missing unique identifier originates.  Using the
> version number in stable, but the issue have been around before that.
> 
> In my work as a system administrator for tens of thousand of machines, I
> have often had the need to get some semi-unique identifier out of the
> operating system.  On all other Unix like operating systems, hostid and
> gethostid() will provide this, but not on Linux.  I find this rather sad,
> and have had to spend time generating our own solution to the problem
> because gethostid() is useless on Linux.
> 
> Because of this, and to spare future system administrators to share that
> pain, I fully support the request from Martin Kraft to extend Debian to
> make sure the gethostid() value return something sensible.
> 
> The described approach from FreeBSD, using /etc/hostid,
> /sys/class/dmi/id/product_uuid or a random value (in that order) seem
> like a sensible one.  It might make sense to use other sources too, but
> the goal should be to pick a value that will stay the same until the hardware
> is replaced, and pick a value that will stay the same as long as the operating
> system isn't reinstalled if such hardware dependent value do not exist.
> 
> To avoid changing the ID on running systems I believe it should only be done
> when libc6 is installed for the first time.  Those willing to change their
> hostid at runtime should be provided a simple script to do so instead of doing
> it automatically.  It will fix the issue for future installations.  I am not
> sure how to sensibly fix it for existing installations without ending up with
> a lot of machines with the same hostid as 7f0100 is a very common hostid on
> Linux already, and everyone with a private IP address like those on 192.168.*
> will have collisions.  But then again a 32 bit number can only provide
> 4.294.967.296 unique IDs and with the amount of Linux machines in the world
> there are going to be collisions anyway.  We just should reduce the chance to
> a more sensible number.
> 
> Something like this should work, I guess:
> 
> if [ ! -f /etc/hostid ]; then
>    if [ -e /sys/class/dmi/id/product_uuid ]; then
>        sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>    else
>    	dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>    fi
> fi
> 
> We need to figure out how to transform the UUID to a 32 bit integer, of course.

Hmm DMI is something quite x86/aarch64 specific, so it means we will
always use the /dev/urandom fallback on other architectures.

Another question is about chroots. The above methods means we might
end-up with the same machine-id in chroots id the DMI UUID is available.
Is it something really wanted?

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?

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.

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.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net