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
Attachment:
signature.asc
Description: OpenPGP digital signature