I would like to install Bahmni on CentOS using an “advanced installation” process. For this task, I think I need to modify the inventory-list (aka “Local”) file per step-4 of the advanced installation instructions. I’m currently stuck on that step for over a week. I can’t find any documentation about the Bahmni-specific implementation of Ansible and I’ve looked!
Does anyone “own” the installation code or familiar enough with it and Ansible to give me a run-down on roughly how to change up the inventory file or the YAML code to perform installations on non-Localhost machines? I don’t really know anything about Ansible yet, and I’m attempting to not have to learn everything about it just to get Bahmni installed securely, so any help would be appreciated.
I’d prefer to not have to reverse-engineer this installation process, so if anyone knows it, you’ll save me a ton of time trying to figure this out in order to get Bahmni installed.
“local” is just a name. It can be anything as long as you mention that for the “-i” parameter
bahmni install -i my_file
The documentation clearly mentions that.
bahmni -i <inventory_file_name> install
Inventory file format
we follow the INI file format. Where things are mentioned for groups and hosts. Groups are mentioned within the square bracket and you can have multiple hosts mentioned there.
[bahmni-emr]
172.16.1.1
172.16.1.2 passive=yes
While defining an active-passive setup, you will need to define which one is “passive”. Check example here
the group of groups mention what all the components are to be installed (of course, you may not define a host under a group)
[local:children]
Bahmni can be installed from a control machine. Its quite common to set this across 2 machines in a active-passive setup.
Check example inventory file here
Ansible requires SSH and you need to define a user appropriately so that that user has ssh to a machine and also have sudo access for installation. Once done, you can remove the user! You may also define a key file to use (parameter - ansible_ssh_private_key_file). Check the above inventory file example.
common parameters are “ansible_ssh_user”, “ansible_ssh_pass”, “ansible_host”
“localhost” is only applicable for local machine installation. the Advanced installation specifically mentions avoiding “localhost” for “Remote Setup/multi machine setup” section. You can use something like this as well, as part of the host definition.
We are installing Bahmni in master slave (active-passive) setup with 2 desktops. As mentioned here we have set up local files on both machines as follows -
and also made changes in openemr as master ip
Do we need to install bahmni on both machines separately and then make the above setup and then again run the installation?
Do we just install the installer on master then set up the local inventory file as above and then run the bahmni -i local install command from master which will install bahmni on both master and slave?
The command in a local file for ssh root and password is correct or I am making mistake.
Is there any wiki page specifically for master slave installation?
No. Just run from the control machine. Control machine maybe the master, or a different one.
No, only from the control machine. meaning where you are running the installer from.
Ansible ssh user must be able to ssh to the other machine and be part of sudoers. From the log, that clearly seems to be the case, either the machine is not reachable from the control machine, or the ssh is not successful.
best way to figure out - write a simple play that tries to install a package or copy a file. But the error reporting is clear - ansible is not able to identify or login or install anything on the machines.
The log shows that it found play [bahmni-emr] in all.yml and then it shows
TASK [setup].
Can you please point to the exact file (.yml) where you think it is failing?
So that we can try to check it further?
I am not sure about ping, because ping (ICMP) might be disabled.
Can you ping and get response from that machine?
Also, I think it might help to understand how ansible connects to a remote host. You can read more here
I will try to describe in brief here
think of ssh - unless instructed ansible will do exactly how you would normally connect a machine using ssh. which means, it will use the key of the user you specified (if not specified, then its the current user). Using an inventory file, you can customize what user you want ansible to connect as, what certificate to use etc etc.
Example: I have created a simple /etc/ansible/hosts file, where I have mentioned (you can use an inventory file as well)
Goes without saying that the public key of the user should be located in authorized_keys on the remote systems. Also, if you want to do something that requires sudo access, then the user that you used must be part of sudoers.
TASK [bahmni-backup-upload-directories : Add authorized key to passive machine]
task path: /opt/bahmni-installer/bahmni-playbooks/roles/bahmni-backup-upload-directories/tasks/main.yml:10
[WARNING]: Unable to find '/tmp/id_rsa.pub' in expected paths.
fatal: [slaveip]: FAILED! => {"msg": "An unhandled exception occurred while running the lookup plugin 'file'. Error was a <class 'ansible.errors.AnsibleError'>, original message: could not locate file in lookup: /tmp/id_rsa.pub"}
to retry, use: --limit @/opt/bahmni-installer/bahmni-playbooks/all.retry
This is mostly user access issue as AWS CentOS 7 Community version does not have root user access. So changed the user for id_rsa.pub to bahmni and copied the file to /tmp folder and rerun the install but it again failed on
TASK [bahmni-odoo : Switch off chkconfig for Odoo on passive]
task path: /opt/bahmni-installer/bahmni-playbooks/roles/bahmni-odoo/tasks/main.yml:90
fatal: [slaveIP]: FAILED! => {"changed": false, "msg": "Could not find the requested service Odoo: host"}
PLAY [postgres-backup-tool]
to retry, use: --limit @/opt/bahmni-installer/bahmni-playbooks/all.retry
PLAY RECAP
masterIP : ok=113 changed=42 unreachable=0 failed=1
slaveIP : ok=168 changed=82 unreachable=0 failed=1
Though the installation was running for longer time.