Skip to content
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

Closed
rwxrob opened this issue Apr 12, 2017 · 9 comments
Closed

HostID or HardwareID? #350

rwxrob opened this issue Apr 12, 2017 · 9 comments

Comments

@rwxrob
Copy link

rwxrob commented Apr 12, 2017

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
Copy link
Owner

shirou commented Apr 14, 2017

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
Copy link

@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-
Copy link
Contributor

sean- commented Jun 13, 2017

@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
Copy link

davidbirdsong commented Jun 13, 2017 via email

@shirou
Copy link
Owner

shirou commented Jun 13, 2017

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
Copy link

@slackpad mind weighing in on this?

@sean-
Copy link
Contributor

sean- commented Jun 13, 2017

@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 added a commit to pierresouchay/gopsutil that referenced this issue Nov 6, 2018
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
@pierresouchay
Copy link
Contributor

@shirou you might now close this issue right?

@shirou
Copy link
Owner

shirou commented Nov 9, 2018

Sure. Thank you everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants