[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 /etc/ma
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 di
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 lo
[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
> one
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 looking
* 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 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
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 the
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 t
[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 the kernel instead
of using gethostid(), which isn't really depricati
* 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 availab
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 if=/
[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 available on non-linux Debian architectures
* 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
>
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 the missing unique identifier originates. Using the
version numb
> 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 Solari
On Thu, Feb 21, 2013 at 01:08:00AM +0100, Carlos Alberto Lopez Perez wrote:
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
refu
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 reas
19 matches
Mail list logo
