centOS packages are not installing correctly in E2E Vulnerability detection for python310

[Rebits]

Description

It was detected in an E2E vulnerability detection tests report (by @QU3B1M) that the centOS packages are not installing correctly in case of running these tests with a 3.10.12, instead of the 3.9 used in the automation pipeline.

Report's logs show these errors:

2024-09-04 00:15:59 Error installing package on agent4: expected string or bytes-like object (remote_operations_handler.py:335)
2024-09-04 00:15:59 Error installing package on agent1: expected string or bytes-like object (remote_operations_handler.py:335)

Marking the operation_results check as failed

E         Check operation_successfull_for_all_agents failed. Evidences (['operation_results']) can be found in the report.

Tasks

• [x] Research installation error using python 3.10.12
• [ ] Update the E2E framework to support the installation of CentOS packages across all versions.

Validation

• [ ] Install with success a centos package using python 3.10.12

Evidences

• report.zip

[jseg380]

Update

The error is being caught in the try... except block of the install_package function. After replicating the error these are the relevant logs obtained:

2024-09-26 21:17:18 Installing package on agent1 (remote_operations_handler.py:315)
2024-09-26 21:17:18 Installing package on agent2 (remote_operations_handler.py:315)
2024-09-26 21:17:21 Package installation result {'ansible_facts': {'pkg_mgr': 'unknown'}, 'changed': False, 'msg': ['Could not detect which major revision of dnf is in use, which is required to determine module backend.', 'You should manually specify use_backend to tell the module whether to use the dnf4 or dnf5 backend})']} (system.py:560)
2024-09-26 21:17:21 Error installing package on agent2: expected string or bytes-like object (remote_operations_handler.py:328)
2024-09-26 21:17:21 Operation result: False (remote_operations_handler.py:415)
2024-09-26 21:17:21 Package installation result {'ansible_facts': {'pkg_mgr': 'unknown'}, 'changed': False, 'msg': ['Could not detect which major revision of dnf is in use, which is required to determine module backend.', 'You should manually specify use_backend to tell the module whether to use the dnf4 or dnf5 backend})']} (system.py:560)
2024-09-26 21:17:21 Error installing package on agent1: expected string or bytes-like object (remote_operations_handler.py:328)

There is a message which could lead to the root cause of the problem about an issue with dnf. It doesn't seem to be categorized as an "error" yet its contents make it appear like one.

[jseg380]

Update

Reviewing the report.zip it has been found that it has failed whenever the package grafana was installed, different versions 9.x and 8.5.x were the ones that caused the error.

[jseg380]

Update

Having difficulties to track down the root cause because of ansible inventories and pytest.

[jseg380]

Conclusion

The error happens because of a difference in ansible and ansible-core python packages version (pip). In the requirements.txt only a lower limit is defined but no upper limit is defined for most of the packages, so in Python 3.10.12 as it is able to install some packages with a greater version it does, leading to the installation of ansible 10.4.0 and ansible-core 2.17.4 as opposed to the versions in which the tests are working (8.7.0 and 2.15.12 respectively). For some reason in these ansible versions the OS is not properly recognized causing it to only accept as package managers dnf4 and dnf5, see warnings in https://github.com/wazuh/wazuh-qa/issues/5717#issuecomment-2377779050 , this leads to the unsuccessful interaction of the OS-specific installation module (yum) and the later crash of the test.

There are multiple ways of solving this, one of which is to modify the requirements.txt ansible version to limit it to 8.7.0, but since this could lead to quite a lot of trouble later on another solution has been developed. The ansible "playbook" (the infratest method which takes as parameters the contents of what a valid ansible playbook would be), can execute arbitrary commands in the machine, so it is possible to force the installation in this rudimentary way.

PR:

[rafabailon]

LGTM