On Thu, Sep 29, 2016 at 12:30:39AM +0200, Aurelien Jarno wrote:
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?
One of the many ambiguities of gethostid. :) Is it a unique ID (no) or is it something that reflects the hardware (no)? Picking one will annoy the people who think it's the other, even though both are currently wrong.
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.
That's my vote, except that hostid(1) probably shouldn't change except to say that nobody should use it.
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.
Yes, changing it will likely be bad in the off chance that someone is actually using the value. If you want to "fix" it (that is, define semantics) it would be better to create a new system call than to change the return value of a system call whose only semantic is that it returns a stable value in some (not fully defined) case. Or just explain to people how to use the options that already exist.
Mike Stone