Grab baseboard info

[nsemikov]

Need some baseboard info, like in dmidecode --type baseboard output:

	...
	Manufacturer: ASUSTeK COMPUTER INC.
	Product Name: B150M-C
	Version: Rev X.0x
	Serial Number: 160368165300404
	Asset Tag: Default string
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Default string
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0
	...

[jaypipes]

Hi @stdatiks,

The issue with dmidecode --type baseboard is that it requires root privileges, which ghw tries very hard to avoid needing.

Can you tell me what specifically you are trying to determine about the motherboard? Is there a particular piece of the information listed above that you are looking for? Perhaps the vendor/product information only?

Or is your application simply trying to inventory as much detailed information as possible about the systems under your control? Or something entirely different?

If you don't mind requiring execution as root, I think it would be relatively simple to have your application do an exec.Command("dmidecode", "--type", "baseboard").Run() and parse the output from above?

[jaypipes]

ping. @stdatiks did you have any more information for me? Wondered what your thoughts are on my questions above?

[nsemikov]

Ok, I see.

I need something like Serial Number, Manufacturer and Product Name in dmidecode output. But direct using call of exec.Command("dmidecode", "--type", "baseboard").Run() is not too good.

I thought your library was using something like https://github.com/digitalocean/go-smbios (see at https://blog.gopheracademy.com/advent-2017/accessing-smbios-information-with-go/). But I looked at the source and realized that I was wrong.

[jaypipes]

From the digitalocean/go-smbios library README, you'll note the following:

"Note that retrieving SMBIOS information is a privileged operation. On Linux, you may invoke the binary as root directly, or apply the CAP_DAC_OVERRIDE capability to enable reading the information without superuser access."

At this time, ghw tries very hard to do things without needing superuser privileges, and that means we don't attempt to access filesystem locations like /sys/firmware/dmi/tables/DMI on Linux (which is what smbios library is doing as well as the dmidecode binary) since you cannot do that as an unprivileged user.

If in the future I decide to relax that architectural design constraint in ghw, I'll certainly consider grabbing baseboard information and other privileged information. I've been considering relaxing that design constraint and allowing ghw to function in a "safe mode" (unprivileged user) that will not attempt to access privileged filesystem information if the user context is an unprivileged user.

For now, though, I'm afraid you'll need to have your application use the go-smbios library directly as a complement to what you might be using ghw for in your application.