falcon_install role does not configure CID about ansible_collection_falcon

[carlosmmatos]

@TinLe - Appreciate the comment. Yes, we try to give an example of what this looks like here: https://github.com/CrowdStrike/ansible_collection_falcon?tab=readme-ov-file#example-using-the-built-in-roles-to-install-falcon

But I agree, we can update the falcon_install documentation to be more specific of how this works for Linux/Mac and Windows.

[TinLe]

@TinLe - Appreciate the comment. Yes, we try to give an example of what this looks like here: https://github.com/CrowdStrike/ansible_collection_falcon?tab=readme-ov-file#example-using-the-built-in-roles-to-install-falcon

But I agree, we can update the falcon_install documentation to be more specific of how this works for Linux/Mac and Windows.

My expectation of the falcon_install role is that:

• If it's going to automatically start the service after installation, then it should at least minimally configured it so that the service run correctly.
• If I wanted more tweaking, then I can optionally run falcon_configure to do so.

Otherwise, do not start the service automatically after install if it's going to be broken anyway and will not run.

Looking into the falcon_install tasks, I see that it does get the CID from api server already, and that falcon_configure will actually call falcon_install if the CID was not given as a var. Then falcon_install might as well set the CID after installing, before starting the service.

I think adding a boolean falcon_start_service var to falcon_install to determine whether the service should be started or not would be useful. Set it by default to false and let the user of the role decide.

[carlosmmatos]

@TinLe The role itself does not automatically start the service after installing the sensor. The sensor package itself is doing that (not ansible). The CID in the install role is really for Windows systems only, this is just an artifact of what the old collection used to be.

So basically, for linux, this is how it works:

• Download and Install the sensor
  • The sensor is automatically started and of course will fail to start because no CID has been provided. This does not fail your ansible stuff at all.
• Configure the sensor by at minimum providing the CID (this can be manually or via the API)
• Restart the sensor

Hope this explains better what is happening. Also, feel free to create your own roles or playbooks as well since as of V4, we really started focusing more on building out modules, dynamic inventories, and EDA plugins. The roles are just their as a nice to have right now, not sure if we will keep them or drop them in the future in lieu of playbook examples using the modules. Or we might decide to re-do the roles... stay tuned ;)

[TinLe]

@carlosmmatos Thank you for the background history. Yes, maintaining legacy code can be... challenging.

I agree that it's the sensor package that set itself up to autostart. However, my expectation is that the role should override that by default. Hence the suggestion of falcon_service_start flag, with the default of false. The service requires a valid CID and will not start without one, so IMHO, it's broken and should not even get started at all.

The example show that you must run falcon_configure after installing. Since it is a required step, then falcon_install should disable/stop the service from starting. I do not look forward to having many instances with broken service installed.

A use case is where I might stage the install on many instances, but don't want it running yet till some time later when I can configure them.

I don't want to have a customized version of the role, that becomes a maintenance nightmare.