-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HostID or HardwareID? #350
Comments
On linux, I think HostID is defined as follows.
I think And on darwin, we use |
@shirou the method of using Newer consul versions use this lib and this tis attribute to generate host-specific id's. When we upgraded consul, we ran into massive failures when it detected duplicate host-id's. There are work-arounds, but the root of the problem would persist and would smack anyone else using this library in the face like it did for us. We can propose a change, but would you accept it? I could see this being problematic for other users of this library that don't have this duplicate problem--having the host id change out from underneath them when they bump this library's version. |
@davidbirdsong That sounds like a bug in the OS image provisioning step. If there is a different attribute that is more appropriate, let me know, but as is, this sounds like a bug in an IT process. Gopsutil is reporting the correct value (and can be worked around in Consul if necessary), which is to say, why should gopsutil report the wrong? |
On Mon, Jun 12, 2017 at 6:35 PM, Sean Chittenden ***@***.***> wrote:
@davidbirdsong <https://github.com/davidbirdsong> That sounds like a bug
in the OS image provisioning step. If there is a different attribute that
is more appropriate, let me know, but as is, this sounds like a bug in an
IT process. Gopsutil is reporting the correct value (and can be worked
around in Consul if necessary), which is to say, why should gopsutil report
the wrong?
It's not really a bug in that there's not really great ways to manage OSX
nodes other than imaging. Imaging causes the kernel.uuid value to be
duplicated and, as far as we've researched, not mutable. So not a bug, but
more of a wart of how fleets of OSX machines are managed. I think the
better way is to use the serial number as a seed for a new UUID. The serial
number would be accessible through cgo:
https://developer.apple.com/library/content/technotes/tn1103/_index.html
Happy to provide a patch if you'll consider it.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#350 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAY4M4bAQ6PNUbZd53Q_zaRq9gA_FR8yks5sDedvgaJpZM4M6zsH>
.
|
We aim to But my concern is, this will affect consul and other systems that performed |
@slackpad mind weighing in on this? |
@davidbirdsong This value can be changed with an EFI editor. See https://ghostlyhaks.com/blog/apple-efi/27-change-apple-macbookair-hardware-uuid Virtualization platforms can also change this value. VMware has documented this in https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2002506 and Virtualbox has a similar solution available to it.
|
On Linux, most golang programs do not run as root (or at least, they should not), by default, the kernels uses strict permissions, so most userland programs cannot read `/sys/class/dmi/id/product_uuid`. However, programs such as Consul are relying on it to get fixed IDs, instead they have a different ID on each boot. We propose to use `/etc/machine-id` as fallback https://www.freedesktop.org/software/systemd/man/machine-id.html In order to fix this, this patch does the following: - if `/sys/class/dmi/id/product_uuid` can be read, use it for HostID - else if `/etc/machine-id` exists and has 32 chars, use it and add '-' to have the same format as product_uuid - finally, if notthing works, use the `kernel.random.boot_id` This will greatly increase the number of programs having correct behaviour when those rely on having a fixed HostID. This will fix the following issues: - shirou#350 - hashicorp/consul#4741
@shirou you might now close this issue right? |
Sure. Thank you everyone! |
Although there is a long running history of figuring out what to name
boot_id
and why it goes in theproc
namespace in the first place, I think this is worth replacing with the HardwareID of the system. Although, since this is a Python port maybe that's how they do it.https://github.com/shirou/gopsutil/blob/master/host/host_linux.go#L79
I am almost certain this number changes every time the system is rebooted.
The number that does not change is the Hardware ID (as I understand it) available from About This Mac and with the following command:
I found this package looking for a faster way to get the HardwareUUID from a syscall instead of the unbearably slow
exec
ing out for the profiler call (which other libraries do).The text was updated successfully, but these errors were encountered: