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

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

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.

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

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