Rich Megginson
1b526b93ea
We have a lot of requests to support Rocky and Alma in various system roles. The first part of adding support is adding `vars/` files for these platforms. In almost every case, for a given major version N, the vars file RedHat_N.yml can be used for CentOS, Rocky, and Alma. Rather than making a copy of the RedHat_N.yml file, just use a symlink to reduce size and maintenance burden, and standardize this across all system roles for consistency. NOTE: There is no Alma or Rocky version 7 or less. NOTE: OracleLinux is not a strict clone, so we are not going to do this for OracleLinux at this time. Support for OracleLinux will need to be done in separate PRs. For more information, see https://github.com/linux-system-roles/cockpit/issues/130 **Question**: Why not just use `ansible_facts["os_family"] == "RedHat"`? **Answer**: This is what Ansible uses as the RedHat os_family: https://github.com/ansible/ansible/blob/1e6ffc1d02559a26def6c9c3b07baf27032865a2/lib/ansible/module_utils/facts/system/distribution.py#L511 There are a lot of distributions in there. I know that Fedora is not a clone of RHEL, but it is very closely related. Most of the others are not clones, and it would generally not work to replace ansible_distribution in ['CentOS', 'Fedora', 'RedHat'] with ansible_facts['os_family'] == 'RedHat' (but it would probably work in specific cases with specific distributions). For example, OracleLinux is in there, and we know that doesn't generally work. The only ones we can be pretty sure about are `RedHat`, `CentOS`, `Fedora`, `AlmaLinux`, and `Rocky`. **Question**: Does my role really need this because it should already work on RHEL clones? **Answer**: Maybe not - but: * it doesn't hurt anything * it's there if we need it in the future * the role will be inconsistent with the other system roles if we don't have this **Question**: Why do I need the `tests/vars/rh_distros_vars.yml` file? Doesn't the test load the vars from the role? **Answer**: No, the test does not load the vars from the role until the role is included, and many tests use version and distribution before including the role. **Question**: Do we need to change the code now to use the new variables? **Answer**: No, not now, in subsequent PRs, hopefully by Alma and Rocky users. Note that there may be more work to be done to the role to fully support Rocky and Alma. Many roles have conditionals like this: ```yaml some_var: "{{ 'some value' if ansible_distribution in ['CentOS', 'RedHat'] else 'other value' }}" another_var: "{{ 'some value' if ansible_distribution in ['CentOS', 'Fedora', 'RedHat'] else 'other value' }}" ... - name: Do something when: ansible_distribution in ['CentOS', 'RedHat'] ... - name: Do something else when: ansible_distribution in ['CentOS', 'Fedora', 'RedHat'] ... ``` Adding Rocky and AlmaLinux to these conditionals will have to be done separately. In order to simplify the task, some new variables are being introduced: ```yaml __$rolename_rh_distros: - AlmaLinux - CentOS - RedHat - Rocky __$rolename_rh_distros_fedora: "{{ __$rolename_rh_distros + ['Fedora'] }}" __$rolename_is_rh_distro: "{{ ansible_distribution in __$rolename_rh_distros }}" __$rolename_is_rh_distro_fedora: "{{ ansible_distribution in __$rolename_rh_distros_fedora }}" ``` Then the conditionals can be rewritten as: ```yaml some_var: "{{ 'some value' if __$rolename_is_rh_distro else 'other value' }}" another_var: "{{ 'some value' if __$rolename_is_rh_distro_fedora else 'other value' }}" ... - name: Do something when: __$rolename_is_rh_distro | bool ... - name: Do something else when: __$rolename_is_rh_distro_fedora | bool ... ``` For tests - tests that use such conditionals will need to use `vars_files` or `include_vars` to load the variables that are defined in `tests/vars/rh_distros_vars.yml`: ```yaml vars_files: - vars/rh_distros_vars.yml ``` We don't currently have CI testing for Rocky or Alma, so someone wanting to run tests on those platforms would need to change the test code to use these. Signed-off-by: Rich Megginson <rmeggins@redhat.com>
Role Name
Ansible role for managing Advanced Intrusion Detection Environment (AIDE).
Requirements
Any prerequisites that may not be covered by Ansible itself or the role should be mentioned here. This includes platform dependencies not managed by the role, hardware requirements, external collections, etc. There should be a distinction between control node requirements (like collections) and managed node requirements (like special hardware, platform provisioning).
Collection requirements
For instance, if the role depends on some collections and has a
meta/collection-requirements.yml file for installing those dependencies, and
in order to manage rpm-ostree systems, it should be mentioned here that the
user should run
ansible-galaxy collection install -vv -r meta/collection-requirements.yml
on the control node before using the role.
Role Variables
A description of all input variables (i.e. variables that are defined in
defaults/main.yml) for the role should go here as these form an API of the
role. Each variable should have its own section e.g.
aide_foo
This variable is required. It is a string that lists the foo of the role. There is no default value.
aide_bar
This variable is optional. It is a boolean that tells the role to disable bar.
The default value is true.
Variables that are not intended as input, like variables defined in
vars/main.yml, variables that are read from other roles and/or the global
scope (ie. hostvars, group vars, etc.) can be also mentioned here but keep in
mind that as these are probably not part of the role API they may change during
the lifetime.
Example of setting the variables:
aide_foo: "oof"
aide_bar: false
Variables Exported by the Role
This section is optional. Some roles may export variables for playbooks to
use later. These are analogous to "return values" in Ansible modules. For
example, if a role performs some action that will require a system reboot, but
the user wants to defer the reboot, the role might set a variable like
aide_reboot_needed: true that the playbook can use to reboot at a more
convenient time.
Example:
aide_reboot_needed
Default false - if true, this means a reboot is needed to apply the changes
made by the role
Example Playbook
Including an example of how to use your role (for instance, with variables passed in as parameters) is always nice for users too:
- name: Manage the aide subsystem
hosts: all
vars:
aide_foo: "foo foo!"
aide_bar: false
roles:
- linux-system-roles.aide
More examples can be provided in the examples/ directory. These
can be useful, especially for documentation.
rpm-ostree
See README-ostree.md
License
Whenever possible, please prefer MIT.
Author Information
An optional section for the role authors to include contact information, or a website (HTML is not allowed).