+++ This bug was initially created as a clone of Bug #2105162 +++

Description of problem:
On a RHEL 9 server/minimal installation without non-RHEL Ansible bits installed it seems not possible to run SCAP playbooks locally in an offline (non-RH connected) environment:

1. rm -rf ~/.ansible
2. dnf install -y ansible-core scap-security-guide
3. cd /usr/share/scap-security-guide/ansible
4. ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.yml
   ERROR! couldn't resolve module/action 'ini_file'. This often indicates a
   misspelling, missing collection, or incorrect module path.
   ...

Version-Release number of selected component (if applicable):
ansible-core-2.12.2-1.el9.x86_64
openscap-1.3.6-3.el9.x86_64
openscap-scanner-1.3.6-3.el9.x86_64
scap-security-guide-0.1.60-6.el9_0.noarch

— Additional comment from Marko Myllynen on 2022-07-08 07:20:53 UTC —

[internal]

Please note that I will be back online Aug 1 so before that I can't respond to any needinfo requests. However, the steps to reproduce should be trivial to allow anyone to confirm and test this locally. Thanks.

— Additional comment from Marko Myllynen on 2022-07-08 09:36:45 UTC —

[internal]

This was initially discussed in this internal tech-list@ thread:

https://lists.corp.redhat.com/archives/tech-list/2022-July/001044.html

— Additional comment from Rich Megginson on 2022-07-08 15:10:53 UTC —

I think the RHEL openscap package is going to have to vendor in the ansible.posix and community.general collections, or at least, the plugins required. We have to do the same thing for the RHEL system roles package.

declared as Sources - http://pkgs.devel.redhat.com/cgit/rpms/rhel-system-roles/tree/linux-system-roles.spec?h=rhel-9-main#n233

extraction and packaging of only the code needed http://pkgs.devel.redhat.com/cgit/rpms/rhel-system-roles/tree/linux-system-roles.spec?h=rhel-9-main#n360

This way, upsstream can still use the unsupported collections in Galaxy, and downstream users can have a fully supported package, including all of the dependencies

— Additional comment from Brian Smith on 2022-07-08 18:10:02 UTC —

There are two different use cases regarding OpenSCAP and RHEL:

Use case 1) standalone / offline use of OpenSCAP on RHEL. This was identified early on as a known issue with Ansible Core and was discussed, however a decision was made that the OpenSCAP team would not update their content or vender in collections to work with Ansible Core. In my opinion, we need to find a solution for this, or we need to remove the Ansible SCAP content from RHEL, as the current situation of providing Ansible content that doesn't work creates a poor customer experience.

Use case 2) Insights Compliance with Insights remediation via the Red Hat connector. This was intended to be a supported workaround for the previous use case, and the ansible.posix and community.general collections were vendered in to the rhc-worker-playbook RPM package. However, it sounds like there is some issue that prevents the playbooks from finding these vendered collections which results in this use case also not working.

Instead of vendering the collections in a RHC specific package (rhc-worker-playbook), could we instead vender them in a common package that both "use case 1" and "use case 2" could both utilize?

— Additional comment from Rich Megginson on 2022-07-08 18:42:21 UTC —

(In reply to Brian Smith from comment #4)
> There are two different use cases regarding OpenSCAP and RHEL:
>
> Use case 1) standalone / offline use of OpenSCAP on RHEL. This was
> identified early on as a known issue with Ansible Core and was discussed,
> however a decision was made that the OpenSCAP team would not update their
> content or vender in collections to work with Ansible Core. In my opinion,
> we need to find a solution for this, or we need to remove the Ansible SCAP
> content from RHEL, as the current situation of providing Ansible content
> that doesn't work creates a poor customer experience.
>

If the vendoring is done in the same way that the system roles does vendoring, then the plugin is only available in the role that uses it. For example, when the tlog role vendors in the ini_file module, it does it in such a way that "ini_file" works, but "community.general.ini_file" does not (which is why system roles still does not use the fully qualified collection name for plugins). You could use "redhat.rhel_system_roles.ini_file" from an external role, but that is not supported. So I'm assuming that is what is happening here - rhc-worker-playbook vendors in the plugins like system roles does, so you can use them from insights compliance.

> Use case 2) Insights Compliance with Insights remediation via the Red Hat
> connector. This was intended to be a supported workaround for the previous
> use case, and the ansible.posix and community.general collections were
> vendered in to the rhc-worker-playbook RPM package. However, it sounds like
> there is some issue that prevents the playbooks from finding these vendered
> collections which results in this use case also not working.

See above.

>
> Instead of vendering the collections in a RHC specific package
> (rhc-worker-playbook), could we instead vender them in a common package that
> both "use case 1" and "use case 2" could both utilize?

. . . and system roles, and ansible pcp, and freeipa, and satellite, and rhel_mgmt, etc. etc.

Yes, this is one of the options we discussed when we were doing the initial ansible-core planning. One issue is that we would need to coordinate with the teams providing this content in Automation Hub - since ansible.posix is also in Automation Hub, we would need to keep the versions similar (however, the Automation Hub version would probably be ahead of the RHEL version due to the RHEL cycle being much longer - and EUS, etc.) This would also mean that there would be a supported community.general collection in RHEL for RHEL customers, but not in Automation Hub for Ansible subscribers. Another issue is RHEL7 support - would we be able to add these into RHEL7?

So, it is doable, but has some trickiness to it. If this is the direction we want to go, we should start with the Fedora packages for ansible.posix and community.general, and coordinate with those maintainers, and start the new package process for importing these into RHEL.

— Additional comment from Brian Smith on 2022-07-08 20:10:01 UTC —

(In reply to Rich Megginson from comment #5)
> So, it is doable, but has some trickiness to it. If this is the direction
> we want to go, we should start with the Fedora packages for ansible.posix
> and community.general, and coordinate with those maintainers, and start the
> new package process for importing these into RHEL.

Rich, just to clarify, I am not proposing a ansible.posix and community.general package that would be shared by all RHEL components (System Roles, PCP, IPA, Satellite etc.).

OpenSCAP Ansible playbooks require these collections no matter how it is run (i.e. either OpenSCAP standalone or OpenSCAP as part of Insights/RHC). Instead of vendering them in for only one specific OpenSCAP use case (Insights/RHC), I'm suggesting that we should consider vendering them in to OpenSCAP so that they work for any OpenSCAP use case (i.e. standalone or as part of RHC/Insights).

So just like System Roles venders in what we need, I'm suggesting that OpenSCAP vender in what they need in a method that works for either OpenSCAP use case.

— Additional comment from Rich Megginson on 2022-07-08 20:15:58 UTC —

(In reply to Brian Smith from comment #6)
> (In reply to Rich Megginson from comment #5)
> > So, it is doable, but has some trickiness to it. If this is the direction
> > we want to go, we should start with the Fedora packages for ansible.posix
> > and community.general, and coordinate with those maintainers, and start the
> > new package process for importing these into RHEL.
>
> Rich, just to clarify, I am not proposing a ansible.posix and
> community.general package that would be shared by all RHEL components
> (System Roles, PCP, IPA, Satellite etc.).
>
> OpenSCAP Ansible playbooks require these collections no matter how it is run
> (i.e. either OpenSCAP standalone or OpenSCAP as part of Insights/RHC).
> Instead of vendering them in for only one specific OpenSCAP use case
> (Insights/RHC), I'm suggesting that we should consider vendering them in to
> OpenSCAP so that they work for any OpenSCAP use case (i.e. standalone or as
> part of RHC/Insights).
>
> So just like System Roles venders in what we need, I'm suggesting that
> OpenSCAP vender in what they need in a method that works for either OpenSCAP
> use case.

Ok, I see. That should work, but there may be a difference in how the module is used in upstream code (i.e. "ini_file:" or "community.general.ini_file:") vs in downstream RHEL packaged code (i.e. "rhc.collection_name.ini_file:")

— Additional comment from Marek Haicman on 2022-07-15 20:13:02 UTC —

Hello, just to chime in and to duplicate what I wrote to the tech-list thread linked in Comment 2:

I consider the whole role of Ansible in the security compliance story a bit complicated, so I would like to ask for some time before we process it on the high level and then let engineers go through the implications and technical details. (Mid August we should have some answers, the source of truth is in https://issues.redhat.com/browse/RHELBU-744) (beware - it's broader problem, so finding answer for this specific BZ there might be tricky)

For the issue itself, it'd like to explicitly highlight a workaround, utilizing resources made specifically for Red Hat Insights workflows. (i.e. the use of `rhc-worker-playbook` package as described here is NOT SUPPORTED):

1. dnf install -y ansible-core scap-security-guide rhc-worker-playbook
2. cd /usr/share/scap-security-guide/ansible
3. ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.yml

— Additional comment from Jan Fiala on 2022-07-22 12:38:48 UTC —

Thanks for the doc text and clarifications. Please check my draft if it is still accurate.

— Additional comment from Marek Haicman on 2022-07-26 11:30:54 UTC —

The wording of the doc draft is imho correct. Thank you! (We might try to write a KB article which can be then linked, but this in RN would also suffice)

— Additional comment from Benjamin Blasco on 2022-08-03 11:46:10 UTC —

Hello, I have just tested this on a fully updated RHEL 9 system (deployed from qcow) and it does not work unless you export the ANSIBLE_COLLECTIONS PATH:

[root@rhel90 ansible]# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/

[root@rhel90 ansible]# ansible-playbook -i localhost -c local rhel9-playbook-cis_server_l1.yml
[WARNING]: Unable to parse /usr/share/scap-security-guide/ansible/localhost as an inventory source
[WARNING]: No inventory was parsed, only implicit localhost is available
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match
'all'
ERROR! couldn't resolve module/action 'ini_file'. This often indicates a misspelling, missing collection, or incorrect module path.

The error appears to be in '/usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml': line 340, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

• name: Ensure GPG check is globally activated
  ^ here
  [root@rhel90 ansible]#

All that needs to change from the above is the following line to include "export"
[root@rhel90 ansible]# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/

Package versions:
openscap-1.3.6-3.el9.x86_64
openscap-scanner-1.3.6-3.el9.x86_64
scap-security-guide-0.1.60-6.el9_0.noarch
ansible-core-2.12.2-1.el9.x86_64
rhc-worker-playbook-0.1.8-1.el9.x86_64

After the correction I have encountered an issue that appears to be with the playbook or my deployment, rather than Ansible module inclusions:

TASK [Check the integrity of the current authselect profile] ************************************************************
fatal: [localhost]: FAILED! =>

{"changed": false, "cmd": ["authselect", "check"], "delta": "0:00:00.012932", "end": "2022-08-03 21:44:42.908747", "msg": "non-zero return code", "rc": 2, "start": "2022-08-03 21:44:42.895815", "stderr": "", "stderr_lines": [], "stdout": "System was not configured with authselect.", "stdout_lines": ["System was not configured with authselect."]}

...ignoring

TASK [Informative message based on the authselect integrity check result] ***********************************************
fatal: [localhost]: FAILED! => {
"assertion": "result_authselect_check_cmd is success",
"changed": false,
"evaluated_to": false,
"msg": [
"authselect integrity check failed. Remediation aborted!",
"This remediation could not be applied because the authselect profile is not intact.",
"It is not recommended to manually edit the PAM files when authselect is available.",
"In cases where the default authselect profile does not cover a specific demand, a custom authselect profile is recommended."
]
}

Happy to collect more info as needed.

— Additional comment from Benjamin Blasco on 2022-08-03 12:25:23 UTC —

Please note that later error with authselect in the previous comment was due to an issue with my authselect configuration, which has nothing to do with this BZ.

— Additional comment from Rich Megginson on 2022-08-03 13:57:29 UTC —

You don't have to use the environment variable. You can also use an ansible config setting https://docs.ansible.com/ansible/latest/reference_appendices/config.html#collections-paths in various places: https://docs.ansible.com/ansible/latest/reference_appendices/config.html#the-configuration-file