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.N/A
N/A
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
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
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:
osfullnameos_familyoscodenamegrains 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.
(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)
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.
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.
Keep open
Thank you for updating this issue. It is no longer marked as stale.
Most helpful comment
Keep open