[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
