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

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

On Wed, Sep 28, 2016 at 12:32:04PM +0200, Florian Weimer wrote:
* Petter Reinholdtsen:
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)
   	dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null

That's not very different from /etc/machine-id, isn't it?

We need to figure out how to transform the UUID to a 32 bit integer,
of course.

And I think this is the crux of the problem.  Whatever we do, with
today's cluster sizes it's just not reliably unique.

You could use /etc/machine-id instead.  Some effort goes into that to
make it actually unique.

DMI data seems risky because it depends on firmware, and there are so
many firmware bugs out there.  It would also not address the matter of
changing host IDs as the result of host migrations.

Yes, this seems a quixotic quest. In historic terms, this was mostly used on systems that actually had some kind of serial number burned onto the mainboard; it's fairly useless in the absence of that kind of controlled environment. Many systems these days actually do have that sort of ID, e.g., via dmi/smbios, but 1) it's not guaranteed to be there 2) it's unlikely to fit in a 32 bit int.

Other platforms have deprecated gethostid, that's the best way forward for linux, IMO. This proposal doesn't fix the problem generally and actually changes the semantics of the call. (It was originally expected that the value would remain constant independent of a particular OS installation, which is not a property of a value stored on disk.) The main users of hostid (that I'm aware of) tended to be commercial software vendors locking licenses to systems--and they typically didn't use gethostid on linux because it was useless for the purpose. So I'm not aware of a userbase for this call on linux, and nobody should be using it for new development. If you need a stable unique id then you should be using something like the dmi uuid *and you need to have hardware from a vendor that sets such a property*. If you want something tied to the OS instance rather than the machine, then use /etc/machine-id (and gnash your teeth at the misnomer) rather than reinventing it.

Mike Stone

Reply to: