[falcon_configure] Add ability to prevent service falcon-sensor to start

[dhoppe]

It looks like the variable falcon_service_state has not been defined at defaults/main.yml and therefore the task only relies on the default('restarted').

ansible_collection_falcon/roles/falcon_configure/tasks/configure.yml

Line 28 in ba37c6f

state: "{{ falcon_service_state | default('restarted') }}"

ansible_collection_falcon/roles/falcon_configure/tasks/win_configure.yml

Line 6 in ba37c6f

state: "{{ falcon_service_state | default('started') }}"

[carlosmmatos]

@dhoppe - what do you mean by "prevent" the service from starting for these tasks? They are for configuring the sensor, so when a change is made, the state needs to be restarted for linux.

I suppose we can make an argument for Windows that we don't really care about service state if someone wants to remove AID.

IMO the falcon_service_state should no longer exist, which needs to be fixed.

[dhoppe]

@dhoppe - what do you mean by "prevent" the service from starting for these tasks? They are for configuring the sensor, so when a change is made, the state needs to be restarted for linux.

@carlosmmatos I took a second look at the code and finally understand why the service is restarted.

IMO the falcon_service_state should no longer exist, which needs to be fixed.

@carlosmmatos I actually wanted to create a pull request to start or stop the service based on this variable. A change via falconctl would then trigger the handler via notify to restart the service. 🤔

When creating a golden image, the service should be stopped to ensure that no .lock files or similar exist. This would otherwise prevent the service from being started when creating a new EC2 instance.

[carlosmmatos]

I hear you. But the workflow is generally like this (linux):

1. Install the sensor. For some reason our sensor gets installed in started state 🤷🏼‍♂️ . For obvious reason the sensor doesn't start since no CID has been applied at this stage.
2. Then generally most people will set the CID and maybe some tags. In order for those to take effect, a restart must take place. After this restart, the sensor should make a connection to the cloud, do it's necessary metadata updates and be running.
3. For VM templates/Gold Images - then the AID is deleted (no restart needed).
4. Shutdown VM template/Gold Image
5. Drink beer/whiskey 😉

[dhoppe]

I hear you. But the workflow is generally like this (linux):

1. Install the sensor. For some reason our sensor gets installed in started state 🤷🏼‍♂️ . For obvious reason the sensor doesn't start since no CID has been applied at this stage.

@carlosmmatos I think this is handled by the package itself. For example, Debian / Ubuntu installs the package with a default configuration and starts the service. RedHat installs the package, but does not start the service by default until the user decides his configuration fits his requirements.

5. Drink beer/whiskey 😉

I am definitely in favor of whiskey. 😁

[carlosmmatos]

Yes, I'm well aware that the package itself does this, it was more of a "why did engineering" make it like so 🤦🏼‍♂️

And I think all the distros start on install. I just double-checked rhel8/9 and they both will be in a failed state do to attempting to start without a cid.