[Richard Laager]
> For example, if you want to use the low 32-bits of /etc/machine-id,
> that would work too. It'd mean carrying a patch on Debian, but if the
> pain of a patch and different behavior is less than the benefits of
> the change, go for it.
I guess we would have to verify that
On 09/29/2016 05:19 AM, Michael Stone wrote:
> On Wed, Sep 28, 2016 at 09:03:38PM -0700, Richard Laager wrote:
>> Getting back to ZFS and /etc/hostid... I would think that a
>> randomly-generated /etc/hostid is probably sufficient. Whether that's
>> done in the libc, spl, or zfs package makes no
On Wed, Sep 28, 2016 at 09:03:38PM -0700, Richard Laager wrote:
Getting back to ZFS and /etc/hostid... I would think that a
randomly-generated /etc/hostid is probably sufficient. Whether that's
done in the libc, spl, or zfs package makes no difference to me.
You still haven't explained why zfs
* Richard Laager:
> Getting back to ZFS and /etc/hostid... I would think that a
> randomly-generated /etc/hostid is probably sufficient. Whether that's
> done in the libc, spl, or zfs package makes no difference to me.
As I tried to explain, the risks of collisions without central
coordination
[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
>
On 09/28/2016 04:41 AM, Petter Reinholdtsen wrote:
> I did not quite understand what you mean here. Do you mean the DMI
> value in your experience isn't unique?
Absolutely, yes. I found this out because, for some reason that I don't
know, libvirtd wants a unique identifier. It defaults to
* Michael Stone:
> Other platforms have deprecated gethostid, that's the best way forward
> for linux, IMO.
I agree. It's the most likely outcome if this issue was reported to
glibc upstream.
On 2016-09-28 09:33, Petter Reinholdtsen wrote:
> Control: reassign -1 libc6
> Control: found -1 2.19-18
> Control: The value from gethostid() should be more unique and not change when
> the host IP changes
>
> Reassigning to glibc as that is the source of gethostid() where the
> problem with
On Wed, Sep 28, 2016 at 11:11:21PM +0200, Petter Reinholdtsen wrote:
[Michael Stone]
Other platforms have deprecated gethostid, that's the best way forward for
linux, IMO.
Which platforms is this? I find FreeBSD recommend to use sysctl and
KERN_HOSTID to get the hostid integer directly from
* Petter Reinholdtsen:
> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention. I was not aware of it.
>
> I agree that it seem very similar in purpose and implementation. Will
> it be
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)
else
dd
* 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)
>else
> dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>
I'd suggest an application-specific UUID incorporating the hostname.
I expect that ZoL will remove or disable the hostid check when Illumos
implements the Multi Reader Protection feature, or something like it
for HA configurations. The behavior in question is a nonessential
holdover from
13 matches
Mail list logo
