Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
3 tasks done
Rebits opened this issue Sep 4, 2024 · 5 comments · Fixed by #5787
Closed
3 tasks done
Assignees
Labels

Comments

@Rebits
Copy link
Member

Rebits commented Sep 4, 2024

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

  • 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

@jseg380 jseg380 self-assigned this Sep 18, 2024
@jseg380
Copy link
Member

jseg380 commented Sep 26, 2024

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
Copy link
Member

jseg380 commented Sep 27, 2024

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
Copy link
Member

jseg380 commented Sep 30, 2024

Update

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

@jseg380
Copy link
Member

jseg380 commented Oct 1, 2024

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 #5717 (comment) , 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
Copy link
Member

LGTM

@Rebits Rebits closed this as completed Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants