use /etc/os-release in Rex::Hardware::Host

[djzort]

As

me

I would like to

suggestion

so I can

identify more linux distros more accurately

Additional context

No response

Describe the solution you would like

The /etc/os-release file now seems to have wide support, my suggestion is to use it to identify more distributions.

https://www.linux.org/docs/man5/os-release.html

Describe alternatives you have considered

No response

[ferki]

I could not determine any immediately actionable items from the original request on #1557 easily, so I decided to convert it into an idea discussion for now. I'd like to better understand what exactly is hoped to be achieved with this before deciding on todos.

First thoughts

Currently get_operating_system() attempts the following in this order while trying to determine the target operating system:

• if already cached, use that info
• use lsb_release
• use heuristics based on presence and/or content of various files
• return uname -s

/etc/os-release is currently only used by get_operating_system_version() on SuSE, but I can imagine reading one or more entries from this file could fit somewhere into the above heuristics step (or even elsewhere during discovery).

At some place(s) Rex might also need to normalize one or more variations of these values to correctly map them into OS-specific modules (mainly for package and/or service manipulation).

I wonder where we could collect all the possible content variations from different distros? Is there a good information source about which distro uses what strings? Or even better, examples of some other software handling /etc/os-release?

(It might be possible to get around that question by decoupling the package/service provider choosing logic from distro information discovery, for example by detecting package/service managers directly, but that feels like a larger rework at this point.)

[ferki]

Did some extra research about os-release files, and wanted to answer some of my own questions from above for the person wanting to hack around this topic:

I wonder where we could collect all the possible content variations from different distros? Is there a good information source about which distro uses what strings?

There are a couple of repos collecting file samples from various distros, for example:

• chef/os-release
• zygoon/os-release-zoo

edit: one of them also note that "The fields in /etc/os-release are standardized, but the values are not."

Or even better, examples of some other software handling /etc/os-release?

There's Sys::OsRelease on CPAN for getting some ideas. This module doesn't seem to accept raw os-release content as input for parsing (yet?), and doesn't seem to be packaged for many distros (yet?), which limits its immediate usability as a local or remote dependency of Rex.

Some further notes to consider:

1. The NAME, ID, ID_LIKE and VERSION fields are probably the most interesting to use, but since the content is formatted as "a newline-separated list of environment-like shell-compatible variable assignments", it's probably fine to just parse them all.
2. There are multiple possible locations for os-release files, not just /etc/os-release.

[ferki]

@djzort: thanks for the interesting suggestion! 👍

The idea to parse os-release files is an internal implementation detail. It is certainly worth considering for future development, but I don't yet see what exactly we wish to solve by working on this.

Some of my questions so far:

1. What are you trying achieve after such a logic is implemented inside Rex?
2. How/where would you like to use or access the values from an os-release file exactly? Perhaps some (code) examples would help to sync the details of your expectations.

[djzort]

I came upon this when automating development environment creation across a range of distros including centos, rocky, alma, debian, ubuntu, opensuse etc in lxc containers on proxmox.

I found that until lsb_release was installed on the opensuse environment rex was unable to determine what os it is. Which led me to poke around in the guts of both proxmox and rex to see what was going on.

Proxmox is using os-release as its first way to detect the OS and then falls back to lsb-release then many of the ways that rex does. https://github.com/proxmox/pve-container/blob/master/src/PVE/LXC/Setup.pm

also in inxi you can observe os-release being examined https://github.com/smxi/inxi

What is particularly interesting about os-release is the "ID_LIKE" field which helps with distros that are derived from "mainstream" distros. For example here is one from Rocky

NAME="Rocky Linux"
VERSION="9.1 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.1"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.1 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.1"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.1"

and similarly on Alma

[root@alma08 ~]# cat /etc/os-release 
NAME="AlmaLinux"
VERSION="8.7 (Stone Smilodon)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.7 (Stone Smilodon)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"

In both cases they are redhat clones and function like centos prior to it becoming centos stream. Both respond to Rex's is_redhat() probe but that's not very subtle.

There are other examples in the chef repo you have linked. For example raspbian is like Debian. Elementary is like ubuntu and so is linux mint.

So checking os-releases first would be a quick and deterministic first check. It would also allow implementing like_xyz() functions in addition to is_xyz() which would be more subtle

[ferki]

I found that until lsb_release was installed on the opensuse environment rex was unable to determine what os it is.

Hmm, I also stumbled upon the deprecation notice of /etc/SuSE-release. If this and the above means "rex used to be able to recognize openSUSE without lsb_release binary, but not anymore", then that sounds like a bug to fix to me!

(And the fix may certainly choose to parse /etc/os-release files, but I also wouldn't rule out any other viable options just yet.)

Proxmox is using os-release as its first way to detect the OS and then falls back to lsb-release then many of the ways that rex does. https://github.com/proxmox/pve-container/blob/master/src/PVE/LXC/Setup.pm

also in inxi you can observe os-release being examined https://github.com/smxi/inxi

Thanks for the additional pointers to similar use cases!

Notably, these seem to rely on the /etc/lsb-release file instead of the lsb_release binary. I find this to be a good addition to think about the "what options are there?" and "in what order to try them?" perspectives.

What is particularly interesting about os-release is the "ID_LIKE" field which helps with distros that are derived from "mainstream" distros.

I agree that ID_LIKE is interesting to ask the distro itself about what does it think about its own ancestry 👍

For example here is one from Rocky

NAME="Rocky Linux"
VERSION="9.1 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.1"
[...]

and similarly on Alma

[...]
NAME="AlmaLinux"
VERSION="8.7 (Stone Smilodon)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
[...]

In both cases they are redhat clones and function like centos prior to it becoming centos stream. Both respond to Rex's is_redhat() probe but that's not very subtle.

There are other examples in the chef repo you have linked. For example raspbian is like Debian. Elementary is like ubuntu and so is linux mint.

Yes, Rex has its own idea about the list of clones for calls like is_redhat() or is_debian() to provide similar results.

The above is currently used for example when choosing the matching Rex::Pkg::* and Rex::Service::* module for package and service management on the given operating system. This mechanism might need some attention if the similarity info comes from the distro itself via ID_LIKE instead of from Rex. Based on the first few examples, that might still be OK, though.

So checking os-releases first would be a quick and deterministic first check.

Yes, it sounds like a good candidate to try fairly early in the order of available alternatives.

It would also allow implementing like_xyz() functions in addition to is_xyz() which would be more subtle

Now that idea sounds more like a step towards a potential new feature request (regardless of being implemented by parsing /etc/os-release files or not) 👍

Based on the mappings above, it feels like the current is_redhat() already provides the answer the question of "is it like a Red Hat?" about the target OS. I think I need more input to sync all the details about it 🤔

How do you expect the proposed like_xyz() would behave? How it would be different from is_xyz()?