Closed rwxrob closed 5 years ago
On linux, I think HostID is defined as follows.
/sys/class/dmi/id/product_uuid
if availablekernel.random.boot_id
I think product_uuid
is not changed after reboot, so use this as much as possible. But, if not available, use random.boot_id anyway.
And on darwin, we use sysctl kern.uuid
https://github.com/shirou/gopsutil/blob/master/host/host_darwin.go#L67 to get system UUID. I think it is not changed after the reboot.
@shirou the method of using kern.uuid
comes with some pretty nasty side effect any hosts that image off of a blessed osx image will share a kern.uuid
. We run a few hundred OSX nodes and imaging them is the only sane way of managing OS versions. Once imaged, kern.uuid
is immutable as we understand it.
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 notifications@github.com 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 https://github.com/shirou/gopsutil/issues/350#issuecomment-307981076, or mute the thread https://github.com/notifications/unsubscribe-auth/AAY4M4bAQ6PNUbZd53Q_zaRq9gA_FR8yks5sDedvgaJpZM4M6zsH .
We aim to HostID
as a fixed, non-duplicated, host-specific value. If @davidbirdsong send a good approach, I will appreciate it.
But my concern is, this will affect consul and other systems that performed HostID
is not changing. Hosts may be duplicated after this update. Of course gopsutil is a library and such a changing is not a part of gopsutil, but I want to hear how consul people thinking.
(However, I don't know how many consul people viewing this conversation...)
@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.
1. Turn off VM
2. In machine folder, change uuid.bios section (f e.g. uuid.bios = "aa aa ...").
3. In machine folder delete .nvram file
4. Boot VM
@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).