Smarter hostname

[meisenzahl]

Closes #383

[meisenzahl]

Do we want to use only a part of the machine-id for the hostname?

https://www.freedesktop.org/software/systemd/man/machine-id.html

[tintou]

I don't really like relying on dmidecode for this, is there any alternative available (I'm pretty sure that dmidecode don't work in some contexts like VMs)

[meisenzahl]

Dropped usage of dmidecode in favor of /sys/devices/virtual/dmi/id/sys_vendor and /sys/devices/virtual/dmi/id/product_name.

Current schema for hostname creation:

<vendor>-<model>-<machine_id>[0:8]

Fallback:

elementary-os-<chassis>-<machine_id>[0:8]

[meisenzahl]

@cassidyjames Could you test if /sys/devices/virtual/dmi/id/sys_vendor and /sys/devices/virtual/dmi/id/product_name provide usable values on a Pinebook Pro?

[davidmhewitt]

They likely won’t provide usable values since the pinebook pro doesn’t have DMI. But we’re also not using the installer there.

[danirabbit]

Hey thanks for working on this! I think since get_hostname is the only method that is accessed outside of this class, it's probably the only method that should be public. The others should be private

[meisenzahl]

Current schema for hostname creation:

<vendor>-<model>-<machine_id>[0:8]

Fallback:

elementary-os-<chassis>-<machine_id>[0:8]

What do you think about the hostname creation scheme?

I think the scheme of Ubiquity is built as follows:

$USER-<model>

[danirabbit]

So for me, this makes my hostname LENOVO-80MK-ee056906 by default, which is a little long and I'm not sure what the 80MK even is tbh. Machine ID might also be overkill.

/sys/devices/virtual/dmi/id/product_version actually yields Lenovo YOGA 900-13ISK which is still long, but much closer to what I would expect this computer to be called

I'm curious about what other folks are getting when they cat these files and if we can find something meaningful but relatively short

[meisenzahl]

Product name	vendor	model	version
Asus X201E	ASUSTeK COMPUTER INC.	X201EP	1.0
Dell Latitude 7490	Dell Inc.	Latitude 7490
HP 15-bw0xx	HP	HP Laptop 15-bw0xx	Type1ProductConfigId
HP Compaq Presario CQ60	Hewlett-Packard	Compaq Presario CQ60 Notebook PC	F.31
Lenovo ThinPad T14s	LENOVO	20UHCTO1WW	ThinkPad T14s Gen 1
Lenovo ThinkStation S20	LENOVO	4157GH7	ThinkStation XXXX
Raspberry Pi 4
TREKSTOR Primebook P14	TREKSTOR	Primebook P14	Default string

The values in the table were queried on the hardware as follows:

echo "vendor: `cat /sys/devices/virtual/dmi/id/sys_vendor`"
echo "model: `cat /sys/devices/virtual/dmi/id/product_name`"
echo "version: `cat /sys/devices/virtual/dmi/id/product_version`"

The OEMs' implementation is a big mess 🙈

[btkostner]

Product name	vendor	model	version
Custom Built	ASUS	All Series	System Version
System76 Oryx Pro	System76	Oryx Pro	oryp5

[isantop]

Maybe unhelpful given the last response:

Product name	vendor	model	version
System76 Oryx Pro	System76	Oryx Pro	oryp4

[danirabbit]

So it seems like for the data we have here so far that Model is usually better for everything except when vender is LENOVO lol. Would that be absolutely terrible to use version for Lenovo and Model for everyone else?

[cassidyjames]

Throwing my hat in the ring since I have a decent amount of hardware around.

Product name	vendor	model	version
Dell Precision 5530	Dell Inc.	Precision 5530	``
Slimbook Pro X (14")	SLIMBOOK	PROX14	Standard
Pinebook Pro	``	``	``
System76 Meerkat (meer1)	System76, Inc.	Meerkat	meer1

@meisenzahl so to answer, no, Pinebook Pro does not have usable values here. 😄 It fails because the dmi files don't exist; I suspect this is common on ARM, as it looks like it's the case with the Raspberry Pi as well.

[cassidyjames]

@meisenzahl @tintou @danrabbit the dmidecode logic in Ubiquity (and thus originally ported here) already has a bunch of fallbacks for different OEMs and whatnot, including Lenovo and VMs. Is it worth re-inventing the wheel here, or does it make sense to build on that logic? I also wish this logic/special casing was pulled out into some reusable library, but that's a bit beside the point. 😂

[meisenzahl]

@tintou what is your opinion? Should I restore the ported logic from ubiquity without relying on dmidecode and read the values from sys/devices/virtual/dmi/id/...?

[danirabbit]

@meisenzahl if you're using code derived from another work you need to update the copyright header in the file and make sure the license is compatible as well

[meisenzahl]

According to https://launchpad.net/ubiquity, ubiquity is licensed under GPLv2. There are references to GPLv2 and GPLv3 in the code. The references to GPLv2 look like this: "either version 2 of the License, or (at your option) any later version." This means to me that GPLv3 as a later version is compatible with it.

However, I am not a lawyer, so I don't know if we are compatible by using GPLv3.

[davidmhewitt]

Looks good to me, lets give it a try