Installer playbook fatal errors on older version without bypass ability

[jhawkwind]

When the console's sensor update policy is set to a version newer (early adopter version) than on the playbooks' default (latest version), the playbooks fatal errors on the step "CrowdStrike Falcon | Install Falcon Sensor Package"

The proper behavior should be that if a version is not specified and an update policy is not specified and a client is already installed, one of three things must be possible to ensure idempotency:

1. Permit a newer version of the client exists via a flag to be set to "ignore_error".
2. Read the sensor asset inventory and determine it's assigned sensor group's update policy and ensure it matches; and re-install the correct version.
3. Permit the setting of using the "Early Adopter" version.

[carlosmmatos]

@jhawkwind Thanks for opening up an issue. Let me look into this.

[carlosmmatos]

Okay so did a few tests just to make sure we support Early Adopt via sensor update policies and the answer is yes. That is working fine on my tests. Unfortunately it looks like the current Early Adopter build coincides with the latest sensor build so trying to match your scenario doesn't match 1:1.. A few things to talk about:

1. Can you provide the exact error you are getting for the CrowdStrike Falcon | Install Falcon Sensor Package task?
   1. Allowing an upgrade of a package to be installed is default behavior and works fine from testing. However downgrading is not currently configured, but should not fail.
2. When you say "Read the sensor asset inventory".. are you asking if we could dynamically pull your falcon hosts metadata from the API to see if there is a sensor update policy associated to it?
   1. If so, I think there are a few ways we can work towards this, and perhaps one way that you can use now to work with this:
      1. We have been discussing the idea of developing inventory plugins, which would be very useful when managing existing hosts with the falcon-sensor installed. We have also talked about introducing an inventory plugin that can also show unmanaged hosts (those that don't have the sensor installed) as well.
      2. We're also in the works of creating a more API centric collection, that would allow us to use our existing APIs to provide much more flexibility than simple install/configure.
      3. Finally, for now, you could make use of hostgroups in your inventory file. Assuming that your sensor update policies have some form of host group association already, you could translate those into your Ansible inventory file. For example:

         
         [linux-prod]
         prod-*.example.com

[linux-dev] dev-*.example.com

[linux-prod:vars] falcon_sensor_update_policy_name="Prod Update Policy" ...

[linux-dev:vars] falcon_sensor_update_policy_name="Early Adopter Policy" ...

3. To follow onto your 3rd response, we allow you to pass and use the name of a sensor update policy, which is currently how one would identify Early Adopter builds. 

[jhawkwind]

Specifically this task: "CrowdStrike Falcon | Install Falcon Sensor Package (Linux)"

The error is: "A later version is already installed"

And yes, if EA = latest, then of course it is fine. It really is when EA > latest it blows up. My workaround before I submit the issue was to move the system to my latest group and out of the EA group to get it to go.

As for asset inventory, it is an option and "ideal" solution, because at that point, it will know the correct version to "enforce" on the asset that is intended on the console. Otherwise if there is a mismatch in the setting (purposefully, when explicitly set; or not, with defaults) the playbook would cause the sensor to upgrade/downgrade version flapping every time the playbook is run.

Though CrowdStrike upgrade/downgrades so far is non-disruptive, I can imagine a downgrade on a production system might violate certain controls, while setting a version number on the playbooks might be a redundant extra control point with unnecessary administrative overhead.

EDIT: Ooops, I forgot to post an important aspect of the error! The package installer flags!

"invocation": {
    "module_args": {
      "deb": "/tmp/ansible.f1zmnqk3falcon/falcon-sensor_6.48.0-14511_amd64.deb",
      "state": "present",
      "update_cache_retries": 5,
      "update_cache_retry_max_delay": 12,
      "cache_valid_time": 0,
      "purge": false,
      "force": false,
      "upgrade": null,
      "dpkg_options": "force-confdef,force-confold",
      "autoremove": false,
      "autoclean": false,
      "fail_on_autoremove": false,
      "only_upgrade": false,
      "force_apt_get": false,
      "clean": false,
      "allow_unauthenticated": false,
      "allow_downgrade": false,
      "allow_change_held_packages": false,
      "lock_timeout": 60,
      "update_cache": null,
      "package": null,
      "default_release": null,
      "install_recommends": null,
      "policy_rc_d": null

I think we just need to be able to set "allow_downgrade" to "true" and the fatal part would go away. But it won't solve the version flapping.