shirou / gopsutil

psutil for golang
Other
10.54k stars 1.59k forks source link

HostID or HardwareID? #350

Closed rwxrob closed 5 years ago

rwxrob commented 7 years ago

Although there is a long running history of figuring out what to name boot_id and why it goes in the proc 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:

func UUID() string {
        info, err := exec.Command("/usr/sbin/system_profiler", "SPHardwareDataType").Output()
        if err != nil {
                return ""
        }
        x := regexp.MustCompile(`(?m)^\s*Hardware UUID:\s*(\S+)`)
        m := x.FindSubmatch(info)
        if len(m) < 1 {
                return ""
        } else {
                return string(m[1])
        }
}

screen_shot_2017-04-11_at_8_26_08_pm

I found this package looking for a faster way to get the HardwareUUID from a syscall instead of the unbearably slow execing out for the profiler call (which other libraries do).

shirou commented 7 years ago

On linux, I think HostID is defined as follows.

  1. read /sys/class/dmi/id/product_uuid if available
  2. If no, use kernel.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.

davidbirdsong commented 7 years ago

@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.

sean- commented 7 years ago

@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?

davidbirdsong commented 7 years ago

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 .

shirou commented 7 years ago

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...)

davidbirdsong commented 7 years ago

@slackpad mind weighing in on this?

sean- commented 7 years ago

@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
pierresouchay commented 5 years ago

@shirou you might now close this issue right?

shirou commented 5 years ago

Sure. Thank you everyone!