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

Thu Feb 21 00:08:00 UTC 2013

On 21/02/13 00:14, Michael Stone wrote:
> Short version:
> 
> My inclination is to simply better document that hostid is an interface
> without clear semantics which exists for compatability with legacy
> systems and should not be used in new applications.
> 
> Longer version:
> 
> What is the reason for wanting to use hostid? Historically this sort of
> interface was most often used for software licensing and other such
> applications which wanted to tie something to a particular piece of
> hardware. On the proprietary hardware, the vendors would encode a serial
> number which was nicely suited to that purpose. On linux, we don't have
> such a hardware serial because we don't control the hardware, and we
> don't have a real strong desire to facilitate software licensing
> schemes. (If someone wants to cobble one together, fine, but we're not
> going to do the work for it.) Intel tried to implement cpuids for this
> purpose, and it flopped; we're unlikely to get further than they did.
> Any scheme that relies on a cookie isn't going to provide that "tied to
> the hardware" guarantee (a guarantee which is increasingly meaningless
> in a VM world, anyway). And, dbus already went and reinvented that
> wheel--does it make any sense to try to re-reinvent that wheel? You
> still won't be able to rely on hostid having a useful value, because it
> will be installation-dependent (unlike dbus, which got to define the
> semantics from the ground up). You'll basically have an interface which
> on some systems has a great semantic, and on others does not, so the
> documentation will have to say exactly what it should say now: "use
> something else".
> 
> So should we just get rid of it? Doing so would probably break some
> ancient stupid script somewhere, to save 40k. And it's within the realm
> of possibility that someone, within a particular environment, is
> actually managing the hostids to do something useful, so we shouldn't
> break that.
> Mike Stone
> 

When you create a ZFS pool the value of the hostid is stored inside it.
When the system is going to import a pool it checks if the hostid stored
inside the pool matches the current host hostid. If it don't matches it
refuses to import the pool.

In this case you have to manually force an import, which in turns
overwrites the old value for the hostid stored on the pool.

This was meant (I'm guessing) when you have a big SAN/NAS cluster with
many ZFS pools and many hosts accessing them at the same time. With this
feature each one of the hosts can automatically import it's own pools
just by looking at the hostid value without interfering on the others.

http://distfiles.scode.org/tmp/zfs-handbook/zfs-hostid.html

We are working on packaging ZoL (ZFS on Linux native with DKMS) [1] for
Debian and we are checking how we can solve this issue.

The solution that I have in mind is just create /etc/hostid on the
postinst of the ZoL package [2]. But it would be much better if this
could be done by coreutils (ideally at install time)

Writing 4 random bytes on /etc/hostid is not perfect, but is much better
than what we currently have now.

I was looking closer to what FreeBSD does [3]:

First they check if the file /etc/hostid exists. If it exists they set
the hostid to that value. They have a sysctl variable in their kernel
for setting the hostid.

If this file is not available then they check if the system has
smbios.system.uuid defined (in Linux this is
/sys/class/dmi/id/product_uuid). If the system has this value then they
just assign the hostid to that value (via sysctl).

If this value is not available, then they just generate a random value
and write it on /etc/hostid so it is preserved across reboots, and
finally they set the value.

Regards!
--------

[1] http://bugs.debian.org/686447
[2]
http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/2013-February/000005.html
[3] https://gitorious.org/freebsd/freebsd/blobs/HEAD/etc/rc.d/hostid

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/attachments/20130221/2703d8df/attachment.pgp>