search

CrowdStrike / ansible_collection_falcon

Comprehensive toolkit for streamlining your interactions with the CrowdStrike Falcon platform.
https://galaxy.ansible.com/ui/repo/published/crowdstrike/falcon/
GNU General Public License v3.0
93 stars 56 forks source link

RPM updates shouldn't cause Ansible role to fail #539

Closed kkeane closed 1 month ago

kkeane commented 1 month ago

I just ran into #536 Can the handling of this situation is improved? Having Ansible scripting fail "out of the blue" can be disruptive especially when this Ansible role is embedded in a larger playbook.

Suggestion: either download the latest GPG key instead of hardcoding it (granted, some people may consider this a security concern, although that seems to be the common method), or hardcode the RPM version number as well as the key so they match.

carlosmmatos commented 1 month ago

@kkeane believe me I would love to be able to download the latest and use it, unfortunately there are no API endpoints or ways for us to "download" the GPG key as of today. This is something we have been working with engineering to provide but have come up empty so far.

So for now, we have to be quick about updating the GPG key and getting it out on a new release asap. Only thing I can ask of you (the end-user/customer) is to open this up as an IDEA request, or let your support team (Crwd) know why this is important so they can also push it up.

kkeane commented 1 month ago

Thank you! The real issue here is that the need to upgrade the collection causes management issues on the client end, and in some cases may not even be an option. In particular, please make sure that you never require ansible-core 2.17 or higher. Upgrading to that version breaks even on the relatively recent RHEL 8 (due to a python requirement).

Anyway - thanks for all the great work and quick responses!

carlosmmatos commented 1 month ago

That's actually a good point about ansible-core 2.17+. I ran into some strange stuff which prompted me to pin my github action workflows #533 to 2.16.7. I haven't had much time to look into what the heck is going on from the Ansible side, but if you have any GitHub issues or RH issues I can track, I can spread the word with RH since we are partners.

kkeane commented 1 month ago

The issue with ansible-core 2.17 is that it removed support for python 3.6 on the target hosts.

On RHEL 7, python 3.6 is the last available version, so ansible-core 2.17 can't run anything against RHEL 7.

On RHEL 8, python 3.6 is the system python version. RHEL 8 allows installing later versions of python, and a playbook will start to run, but then fail at the first module that needs the system python. One of these failing modules is dnf (or yum or package), which tends to be fairly crucial in most playbooks.

Here is a blog post that describes the issue: https://www.jeffgeerling.com/blog/2024/newer-versions-ansible-dont-work-rhel-8

Another thought occurred to me. Maybe you could extract the GPG key from the collection and put it as a separate asset into the releases. Tag it with "latest" so the URL remains constant, and then use get_url to retrieve the latest GPG key in the collection.

Sent with Proton Mail secure email.

On Wednesday, July 3rd, 2024 at 2:33 PM, Carlos Matos @.***> wrote:

That's actually a good point about ansible-core 2.17+. I ran into some strange stuff which prompted me to pin my github action workflows #533 to 2.16.7. I haven't had much time to look into what the heck is going on from the Ansible side, but if you have any GitHub issues or RH issues I can track, I can spread the word with RH since we are partners.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>