search

IBM-Security / isam-ansible-roles

DEPRECATED Ansible Custom Modules, Handlers and Tasks for ISAM. Requires "ibmsecurity" python package.
Apache License 2.0
24 stars 43 forks source link

activate_module role not enforcing module names #11

Closed Ardun21 closed 7 years ago

Ardun21 commented 7 years ago

Per the doc for the activate_module role, the valid module names are "wga", "mga", and "federation". However, I observed that if I pass in a name other than those (e.g. "fed") then the module will still be activated successfully. However, if I re-run the same role, it will throw an error saying that the module is already activated and the play will terminate. This breaks idempotency for this role.

## This works for initial activation, but fails if module is already activated
- role: activate_module
  activate_module_id  : "fed"
  activate_module_code: "{{ lookup('file', '~/isam_federation_code.txt') }}"

If I use the correct module name ("federation" in this case) then the error will be successfully ignored.

## This runs successfully every time
- role: activate_module
  activate_module_id  : "federation"
  activate_module_code: "{{ lookup('file', '~/isam_federation_code.txt') }}"

IMO the module should never have been activated using an incorrect name in the first place. This would force the playbook author to use the correct name from the start instead of discovering their error much later on.

ram-ibm commented 7 years ago

Good point - the name of the module is used to establish idempotency. So giving a wrong name does create issues. One fix is to check the validity of the module name - but not sure how to handle when one passes, say, mga module name but the activation key for federation. That use case still would be a problem.

ram-ibm commented 7 years ago

Hoping to hear back on any other thoughts - I am not sure there is one fool proof way to solve this issue....

Ardun21 commented 7 years ago

My opinion on this is that the ibmsecurity.isam.base.activation.set() function should ignore the module id and just simply try to POST the code each time this method is invoked. If the response is not 200 (or whatever the successful response is), just check to see if the response message contains the string The capability specified in the request is already activated. and consider that a successful response.

The end goal is to have the module active, so it shouldn't count as an error just because it already is active.

ram-ibm commented 7 years ago

The idempotency check was build into the Python code so that you do not make a change to the appliance that is not required. There is a feature build into each function to override the idempotency check - use "force" variable and set it to True. The code will simply make the REST API call - you are on your own if that causes errors because of existing values.

I will go ahead and close this since I think force=True should take care of your particular use case.