chore: add Rocky Linux vars files

[xeluior]

Enhancement: Adds support for Rocky Linux 8/9

Reason: I use Rocky Linux in my environment

Result: Vars files added for Rocky Linux 8/9

Issue Tracker Tickets (Jira or BZ if any): N/A

[spetrosi]

Why use >? You can type __nbde_client_initramfs_update_cmd: dracut -fv --regenerate-all

[xeluior]

I literally just copied the RedHat_8.yml file, renamed it and reworded the comment at the top so that the vars would get pulled in when running against a Rocky Linux system. The Alma and CentOS vars files are also identical (outside the comment) to the RedHat ones, so it may even make sense to add a check in set_vars.yml for {{ ansible_facts['os_family'] }}_{{ ansible_facts['distribution_major_version'] }}.yml and do away with the seperate files for each EL flavor. Not sure which would be prefered.

[richm]

{{ ansible_facts['os_family'] }}_{{ ansible_facts['distribution_major_version'] }}.yml

There are several problems with using os_family like this

• How to distinguish between RedHat the distribution vs. RedHat the os_family?
• Fedora is part of the RedHat os_family but has a very different versioning scheme
• There may be other members of RedHat family that do not follow the versioning scheme followed by RedHat, CentOS, Rocky, Alma, and Oracle

It would be great if there were an Ansible category somewhere between os_family and distribution - os_clone_alikes? - that were version sync compatible - that way you could say RedHatClones_8 and be very sure that you mean RedHat and very close version clones, and not things like Fedora, ScientificLinux, etc. which are part of RedHat family.

Of course, in practice, these roles will almost never be used on anything except Fedora and strict clones of RedHat.

[xeluior]

Good points, I wasn't aware some of those other OSes still fell under the RedHat os family. Back to the original comment then, would it be better to move those to the single line as you suggested, or keep as is for consistency with the other RedHat-derived vars files?

[spetrosi]

same

[richm]

@xeluior I think symlinks would be best - that is - the Rocky_N.yml files should just be symlinks to the corresponding RedHat_N.yml file. We have other roles using symlinks like this - https://github.com/linux-system-roles/ssh/tree/main/vars - which uses CentOS_N.yml as a symlink to the corresponding RedHat_N.yml - wdyt?

[richm]

@xeluior I have what I think is a more elegant solution, for all system roles - linux-system-roles/.github#74

[richm]

@xeluior I have what I think is a more elegant solution, for all system roles - linux-system-roles/.github#74

and it looks like nbde_client is one of the "lucky" roles, that does not have tasks or vars based on conditionals such as ansible_distribution in ['CentOS', 'RedHat'] - this is a problem with Rocky/Alma support in several roles.

[xeluior]

@xeluior I have what I think is a more elegant solution, for all system roles - linux-system-roles/.github#74

Not sure I fully understand the linked PR, but if it adds Rocky support without needing these vars files we can probably close this PR.

[richm]

@xeluior I have what I think is a more elegant solution, for all system roles - linux-system-roles/.github#74

Not sure I fully understand the linked PR, but if it adds Rocky support without needing these vars files we can probably close this PR.

ok - the role now has support for Rocky due to #181 - please try this.