Bahmni Wiki documentation of the "local" installation file

Additional note about the Bahmni install:

After installing the Bahmni command (Step 2 in the advanced instructions), I used the documented command “bahmni version” which caused bahmni to install ansible 2.2.0.0 for me, but not tell me bahmni version. Bahmni also did not tell me which version it was on subsequent calls to “bahmni version” and it complained about not having an inventory file. I did not understand why the inventory file was required to report which version was installed. I think this might be a bug? I can’t imagine why the installer version would rely on the inventory file.

Next observation: The Ansible version 2.2.0.0 that apparently shipped with the bahmni RPM is now unsupported and beyond “end of life” per Ansible’s documentation. https://docs.ansible.com/ansible/2.7/reference_appendices/release_and_maintenance.html

I would recommend updating the installer to include v 2.6 (or later) because the release notes indicate that 2.6 includes “critical bug fixes.” When I executed “# yum update ansible” I received version 2.6.7-1.e16 (on CentOS 6.10). The security threat fixed in 2.6 reads as follows: " Security Fix - Some connection exceptions would cause no_log specified on a task to be ignored. If this happened, the task information, including any private information could have been displayed to stdout and (if enabled, not the default) logged to a log file specified in ansible.cfg’s log_path. Additionally, sites which redirected stdout from ansible runs to a log file may have stored that private information onto disk that way as well."

Here are the release notes for 2.7 (latest ansible version)

An additional security threat arises from using Ansible on the localhost. Here’s some documentation on a “best practice” of using a separated control computer for Ansible tasks.

To improve security further, I wonder if it’s possible to set up a secure certificate-based mechanism for Ansible to hand off a cron task to a target machine. This job would synchronize the time clocks between the control/server and target machines and then provides ansible with a (new) sudoer account and access during a specific time window. A second cron job could then delete that user account if ansible doesn’t use it within a specified time-period and also after ansible stops using the user account.