Correctly identify AlmaLinux

ekohl · August 17, 2021, 8:54am

Which version of Facter are you using? I forgot the exact version that added it, but you must ensure that’s new enough as well.

nenominal · August 17, 2021, 9:20am

 rpm -qa | grep facter
facter-3.14.2-4.el8.x86_64

cat /etc/os-release

NAME="AlmaLinux"
VERSION="8.4 (Electric Cheetah)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.4 (Electric Cheetah)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:almalinux:almalinux:8.4:GA"
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.4"

cat  /etc/redhat-release
AlmaLinux release 8.4 (Electric Cheetah)


rpm -qa almalinux-release
almalinux-release-8.4-3.el8.x86_64

Maybe facter is the issue, I’m not really sure how old it is. What version do you have?

ekohl · August 17, 2021, 9:29am

This added support to 3.x
https://github.com/puppetlabs/facter/commit/1237cfae360d233b89e0f1f8d435999479b1d553

$ git tag --contains 1237cfae360d233b89e0f1f8d435999479b1d553
3.14.17
3.14.18

So you really need one of the latest facter versions.

nenominal · August 17, 2021, 9:35am

So the issue in this case is facter? That data that foreman has are from facter?

ekohl · August 17, 2021, 9:57am

At least when you use Puppet. There are other fact sources (subscription-manager can be used with Katello). Those must be up to date as well.

gvde · August 17, 2021, 10:49am

O.K. I always install puppet-agent from puppetlabs (6.24.0) which comes with facter 3.14.19. Never used the one from epel.

mclausen · August 17, 2021, 2:05pm

I double checked and I’m also using Puppet Agent v6.24.0 with facter 3.14.19. Here is how it is reporting on the OS:

facterversion => 3.14.19

os => {
  architecture => "x86_64",
  distro => {
    codename => "ElectricCheetah",
    description => "AlmaLinux release 8.4 (Electric Cheetah)",
    id => "AlmaLinux",
    release => {
      full => "8.4",
      major => "8",
      minor => "4"
    },
    specification => ":core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch"
  },
  family => "RedHat",
  hardware => "x86_64",
  name => "AlmaLinux",
  release => {
    full => "8.4",
    major => "8",
    minor => "4"
  },
  selinux => {
    config_mode => "enforcing",
    config_policy => "targeted",
    current_mode => "enforcing",
    enabled => true,
    enforced => true,
    policy_version => "33"
  }
}

I also checked the /etc/redhat-release file and it’s properly showing as AlmaLinux as well:

AlmaLinux release 8.4 (Electric Cheetah)

Here’s the os-release file, just for completeness:

NAME="AlmaLinux"
VERSION="8.4 (Electric Cheetah)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.4 (Electric Cheetah)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:almalinux:almalinux:8.4:GA"
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.4"

Now I use the bootstrap.py script to register my clients, not sure if that is causing something weird to happen, but I have tried a few permutations where I re-register in place, delete the system then register, etc… but it always comes in as Unknown 8.4.

gvde · August 17, 2021, 2:11pm

Well, I guess to comes down to why you have the facter rpm from epel installed as well. I don’t have that I guess that the client will use a search path to find the facter executable and prefers /usr/bin to /opt/puppetlab/bin which runs the old facter version in your case…

ekohl · August 17, 2021, 2:41pm

Please file a Bugzilla against EPEL8 to update Facter to 3.14.19. That will avoid problems for other users as well.

mclausen · August 17, 2021, 3:02pm

Except I don’t have the EPEL version of facter installed. The only facter I have on this system is the one that comes with the Puppet Agent. Should I have both installed (Puppet and EPEL)?

gvde · August 17, 2021, 3:07pm

You wrote before:

That is the EPEL 8 facter. How did you install it?

Maybe check with dnf history list facter.

mclausen · August 17, 2021, 3:12pm

That was someone else, here’s my RPM output:

[LEBANON][11:02:35 EDT] # rpm -qa | grep facter

nenominal · August 17, 2021, 9:49pm

From the epel repo .Till now I never installed facter on clients but having this issue with correctly identifying the OS I’m trying to find why is that.

Does anyone knows where facter grabs it’s data in this case because /etc/redhat-release, /etc/os-release and almalinux-release looks good.

ekohl · August 17, 2021, 10:03pm

I linked the exact patch that implements it and gave it the version. If you want EPEL8 to support AlmaLinux, this is the place to request it to be updated to 3.14.19 (I already selected product Fedora EPEL and component facter in that URL).

gvde · August 24, 2021, 7:34am

@ekohl It’s actually worse for CentOS: facter will label any CentOS 8 simply with name “CentOS”.

However, actually it’s
NAME=“CentOS Linux”
and
NAME=“CentOS Stream”

Due to that, current CentOS 8.4 hosts are listed as “CentOS 8.4.2105” while CentOS 8 Stream is just “CentOS 8”.

It also complicates things for building hosts, because the operating system to use the synced content is “CentOS_Linux 8” for non-stream version and “CentOS 8” for stream version. Totally confusing…

ekohl · August 24, 2021, 10:50am

While it’s confusing, we should also remember that CentOS Linux 8 is EOL in 4 months. Renaming that is a big functional change and I suspect the ecosystem will align on CentOS 8 = CentOS 8 Stream. While it’s easy to say and I do appreciate the actual implications are very annoying, I do think we should already start with treating it that way.

gvde · August 24, 2021, 11:31am

Well, I see your point that CentOS Linux 8 is EOL, soon. But still, names should match. The name for Stream in the distribution .treeinfo is “CentOS Stream” which creates the operating system “CentOS_Stream-8” in foreman (at least, I have that and I have nevre create an operating system manually in foreman). CentOS Stream 8 server, however, end up as “CentOS 8” due to facter.

I also have “AlmaLinux-8” as operating system but my almalinux host has operating system “Alma Linux 8.4”.

Naming conventions should match. Whether it’s “CentOS_Stream” or “CentOS Stream” or just “CentOS”, ideally this should be a single operating system entry for foreman. But considering, the official name is “CentOS Stream” and that’s also the name in .treeinfo and /etc/os-release, and I think that should be the name officially used and consistently shown. And .treeinfo or os-release seems to be the source for this…

ekohl · August 24, 2021, 12:25pm

I see your point and must admit that at this point it’s been too long since I was an actual sysadmin and I’m starting to be more removed from it. It’s even worse for other developers who have never been a sysadmin or only worked with a single system (RHEL sysadmins may not know CentOS or Debian).

It’s hard to figure out what the right thing to do is. What I think is needed is an overview. Basically a (large) table with each OS/distro version and what each resource reports. This may differ a bit for each OS family (Debian has no .treeinfo but maybe there’s an equivalent). Any thoughts with how we could structure this information as a reference source?

lzap · September 8, 2021, 12:37pm

What will definitely not work is having separate parsing classes for each individual input (Puppet, Ansible, Katello sync, RHSM). We need a central place, perhaps a directory with separate class per operating system (this cannot be in our Operatingsystem model class because that does not differentiate several Redhat variants). Having those detection rules on a single place would ensure that no matter what tool it matches, the result (OS name, major, minor, description) is the same. One huge hash/array is also an option, although that could be unreadable pretty soon.

Let me do a summary of what we have today and then we can talk about what to improve. This page is a wiki, please contribute. When unsure, use ? character. Looks like it’s a mess and I only compare Foreman/Puppet/Katello (Ansible and others only make this worse):

Current status

Real name	Foreman name	Foreman description	Katello description
CentOS 7.9	RedHat	Red Hat 7.9.2009	CentOS-7
CentOS 8.4	RedHat	Red Hat 8.4.2105	CentOS_Linux-8
RHEL 7.9	RedHat	Red Hat 7.9	RedHat-7.9
RHEL 8.0	RedHat	Red Hat 8.0	RedHat-8.0.0
RHEL 8.4	RedHat	Red Hat 78.4	RedHat-8.4
CentOS Stream 8	RedHat	Red Hat 8.0	CentOS_Stream-8

Remarks

Foreman OS name must not contain spaces (as it is used in filenames etc)
Foreman description, however, is an independent text field that can contain anything
Katello description shows how Katello plugin sets the description field (it also sets Name, Minor and Minor version)
I think RedHat-8.0.0 looks like a bug

gawainxl · September 22, 2021, 6:05am

With puppet 6 my almalinux hosts were reporting in as red had, switching to puppet 7 seemed to resolve it and have them properly display as almalinux.