Arch Linux has no osfinger

[johnnybubonic]

Description of Issue

So I'm trying to differentiate between CentOS 6, CentOS 7, RHEL 7, and Arch Linux when setting up e.g. package names.

Normally, this'd be a cinch - if issue #51478 wasn't the case. But it is, so cinch it is not. Arch has no osfinger grain, hence my need to use filter_by lists in the first place.

I'd presume osfinger is intended to be a unique identifier across distros/OSes and versions/releases, yes?

So since Arch is rolling release and should always have all packages kept updated:

It is recommended to perform full system upgrades regularly via Pacman#Upgrading packages, to enjoy both the latest bug fixes and security updates, and also to avoid having to deal with too many package upgrades that require manual intervention at once. When requesting support from the community, it will usually be assumed that the system is up to date.

then I propose the following changes:

• osrelease should always be a fixed string for Arch (and other rolling distros, such as Gentoo): latest (or none, etc. - not left blank)
• osfinger for Arch Linux should be ArchLinux, Arch Linux, Arch-Linux, or the like.

Setup

N/A

Steps to Reproduce Issue

N/A

Versions Report

Master:

Salt Version:
           Salt: 2019.2.0
 
Dependency Versions:
           cffi: 1.12.3
       cherrypy: unknown
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: 2.0.5
      gitpython: 2.1.11
          ioflo: Not Installed
         Jinja2: 2.8.1
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.6.8 (default, Apr 25 2019, 21:02:35)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: 2.0.5
        timelib: Not Installed
        Tornado: 4.4.2
            ZMQ: 4.1.4
 
System Versions:
           dist: centos 7.6.1810 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-957.27.2.el7.x86_64
         system: Linux
        version: CentOS Linux 7.6.1810 Core

Minion:

Salt Version:
           Salt: 2019.2.0
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10.1
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.34.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.1
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 3.8.2
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.16 (default, Mar 11 2019, 18:59:25)
   python-gnupg: Not Installed
         PyYAML: 5.1.2
          PyZMQ: 18.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 5.1.1
            ZMQ: 4.3.1
 
System Versions:
           dist:   
         locale: UTF-8
        machine: x86_64
        release: 5.2.10-arch1-1-ARCH
         system: Linux
        version: Not Installed

[Ch3LL]

could do something similar to mac: https://github.com/saltstack/salt/blob/v2019.2.0/salt/grains/core.py#L1968-L1980

since linux_distribution isn't picking up everything correctly. sounds good to me

[johnnybubonic]

hrm. Arch, being Linux, doesn't have sw_vars like macOS. However, it does have systemd (was one of the first adopters, actually!), so you can get some system information via parsing /etc/os-release. BUT! It's worth noting that:

• osfullname
• os_family
• oscodename

grains DO populate correctly (as Arch Linux, Arch, and Arch Linux respectively). So I presume the osfinger (and osrelease, though a standardized e.g. rolling or whatever would depend on keeping a static list of distros that use rolling release) could then be set based on if those are populated with those values.

[johnnybubonic]

(To be clear, I'm basically saying it'd be great if osfinger could be populated as well, because currently until the filter_by list bug is fixed, I can't use it)

[Ch3LL]

I think you are right that we should just set these values statically as you posted in your fist post. I only posted to the macosx portion because we are setting some values there statically for that OS, and we can do the same for arch in the same place for the values that need to be fixed.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[johnnybubonic]

Keep open

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[bdrung]

I worked on cleaning up the OS grain calculation on Linux in #61626. We should address this bug after the pull request got reviewed and merged.

/etc/os-release of the archlinux docker image:

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux-logo

So following that, I would say that osrelease could be left undefined or set to rolling. Then osfinger will become Arch/Arch Linux or Arch-rolling/Arch Linux-rolling respectively.