Archlinux OS Family issue

Archives Ansible Project
1

I’m testing Ansible roles with Archlinux and one of them uses ansible_os_family to include variables or tasks. So I have:

`

  • name: include OS vars
    include_vars: “{{ ansible_os_family }}.yml”
    when: ansible_os_family == ‘Archlinux’

`

Problem is that ansible_os_family gets ‘Arch Linux’ as value, so ansible looks for ‘Arch Linux.yml’ but filename is actually ‘Archlinux.yml’, just capital A and no spaces. I know this is not a fancy bug or anything, I’ve been looking at ansible code and GitHub issues but only found OS_FAMILY_MAP (Code here) and Arch seems to be defined as ‘Archlinux’ but never ‘Arch Linux’.

Could anyone guide me because I do not know if something changed with /etc/os-release in Archlinux or maybe a bug needs to be reported to update variables like OS_FAMILY_MAP.

Thanks in advance.

2

Using ansible 2.3.1.0 and the following playbook:

  • hosts: localhost
    tasks:
  • debug: msg={{ vars }}

I get, amongst others: “ansible_os_family”: “Archlinux”, and “ansible_distribution”: “Archlinux”,

What version are you using?

3

Thank you so much for your reply Mathias.

Version:

me@host ~> ansible --version 2 ansible 2.4.0 config file = /etc/ansible/ansible.cfg configured module search path = [u'/home/me/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /usr/lib/python2.7/site-packages/ansible executable location = /usr/bin/ansible python version = 2.7.13 (default, Feb 11 2017, 12:22:40) [GCC 6.3.1 20170109]

I just tried your example playbook in my computer and got:

`
me@host ~/Ansible> cat /etc/os-release
NAME=“Arch Linux”
PRETTY_NAME=“Arch Linux”
ID=arch
ID_LIKE=archlinux
ANSI_COLOR=“0;36”
HOME_URL=“https://www.archlinux.org/”
SUPPORT_URL=“https://bbs.archlinux.org/”
BUG_REPORT_URL=“https://bugs.archlinux.org/”

me@host ~/Ansible> ansible-playbook arch-test.yml | grep ansible_os
“ansible_os_family”: “Arch Linux”,
“ansible_os_family”: “Arch Linux”,
“ansible_os_family”: “Arch Linux”,
“ansible_os_family”: “Arch Linux”,
`

Is version 2.4.0 to blame here?

4

Got the same output using ansible 2.4:
“ansible_distribution”: “Arch Linux”,
“ansible_distribution_file_parsed”: true,
“ansible_distribution_file_path”: “/etc/os-release”,
“ansible_distribution_file_variety”: “NA”,
“ansible_distribution_major_version”: “NA”,
“ansible_distribution_release”: “NA”,
“ansible_distribution_version”: “NA”,

the “ansible_distribution_file_path” is new from 2.3 and may be the source of the infos instead of hardcoded ones, hence “Arch Linux”

5

I saw this issue at GitHub where people requested to get Archlinux detection from /etc/os-release. It seems to be related to this. What’s the best way to address this with the Ansible team? It’s not a big issue but having no spaces in distribution or family name is a good practice.

Thanks for your help, it’s nice to know the root of the ‘problem’.

6

I compared the source codes between 2.3 and 2.4, it seems to me that the check at https://github.com/ansible/ansible/blob/stable-2.3/lib/ansible/module_utils/facts.py#L729-L731 is not present something like here https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/distribution.py#L171 and since no “parse_distribution_file_Archlinux” method is present, it goes all the way down to “parse_distribution_file_NA” which just plain reads /etc/os-release.

Maybe it’s time to implement such method for custom logic, or stick to the ‘allowempty’ trick.

I also tryed manually applying the fix provided in #15675 and got the desired output:
“ansible_distribution”: “Archlinux”,
“ansible_distribution_file_parsed”: true,
“ansible_distribution_file_path”: “/etc/os-release”,
“ansible_distribution_file_variety”: “Archlinux”,
“ansible_distribution_major_version”: “NA”,
“ansible_distribution_release”: “NA”,
“ansible_distribution_version”: “NA”,

so maybe just update this PR instead (or #22949) to modify the right file?

7

Analysis sounds correct to me, but would like to clarify the expected result:

For a system with /etc/os-release of:

NAME=“Arch Linux”
PRETTY_NAME=“Arch Linux”
ID=arch
ID_LIKE=archlinux
ANSI_COLOR=“0;36”
HOME_URL=“https://www.archlinux.org/”
SUPPORT_URL=“https://bbs.archlinux.org/”
BUG_REPORT_URL=“https://bugs.archlinux.org/”

The desired value for ‘ansible_os_family’ is ‘Archlinux’ ?

And for the other distro facts:

“ansible_distribution”: “Archlinux”,
“ansible_distribution_file_parsed”: true,
“ansible_distribution_file_path”: “/etc/os-release”,
“ansible_distribution_file_variety”: “Archlinux”,
“ansible_distribution_major_version”: “NA”,
“ansible_distribution_release”: “NA”,
“ansible_distribution_version”: “NA”,

What is the background for the values in /etc/os-release being different than the desired values (‘Arch Linux’ vs ‘Archlinux’) ?

The description at https://github.com/ansible/ansible/pull/15675#issue-151988680 claims:

“systemd is a first class citizen in Arch Linux variants and thus /etc/os-release will always have the right info [1]. We don’t need to rely on /etc/arch-release and allowempty workaround.”

Is that correct?

If so, sounds like just need to rebase https://github.com/ansible/ansible/pull/15675 or https://github.com/ansible/ansible/pull/22949 again.

8

      "systemd is a first class citizen in Arch Linux variants and thus /etc/os-release will always have the right info [1]. We don't need to rely on /etc/arch-release and allowempty workaround."

Is that correct?

No, we have encountered systems that did not conform to that
statement. They might be old, but not everyone can update/upgrade at
same pace (even with rolling release distros).

9

Thanks for your replies and for taking the time.

Adrian, I did not understand what you meant for background when it comes to values being different, I’m sorry.
I’m asking now you and Mathias as I’m in the dark here: should I update #22949 with a report of what’s been discussed in this thread or should I rebase following ansible guide? I’m no developer but I understand the changes stated in PR #22949. I really don’t want to screw something up or do something dumb due my lack of experience.