Bahmni installation first time on a base centos minimal box depends on various repos like mysql repo, pgsql repo, epel repo (for python), base repo (for utils like wget), bahmni repo (for bahmni rpms)… If you want to provision it locally without internet, you will have to create a local repo copying all the required rpms and install it.
If you can manage the first time installation with internet, deploying bahmni for subsequent releases would be simpler offline with just configuring the bahmni rpm repo locally.
I am curious to understand your usecase of installation. If you want to try out and learn bahmni, you can use our demo. If you want to try out hands on installation, it is better to use a digital ocean droplet. The wiki is here. The installation on the cloud uses minimal internet from your side and the software downloads happen on the droplet which has very good internet connectivity.
Thank you for your response.
I have manage to install Bahmni on Digital Ocean.It works perfectly(except for a bug on the reports). My use case is to install bahmni for a Health Center at a remote area in Haiti with no internet access. My current internet connection cannot handle the base centos install.
@zoulouky Good to know it worked fine on a Digital Ocean droplet. I searched to see if there is any option to download a droplet for local use. I don’t think this can be done currently. Many users of Digital Ocean have requested this feature, but it isn’t there yet.
It would be nice if Bahmni could be installed with an ISO or some sort of a repo was available from where one could download all RPMs necessary for Bahmni (and its underlying dependencies), maybe using something like this:
My unsolicited feedback is that although I really like and appreciate the efforts to package up Bahmni deployment tools behind a set of rpms and a “bahmni” command, that we should not limit ourselves to this approach or tell people that unless they use RPMs on CentOS then they are out of luck.
At the end of the day, Bahmni EMR is only a slightly more involved OpenMRS setup than most users are accustomed to, and most imlementers are already familiar with (or rely) on being able to install an OpenMRS distribution through it’s component parts.
I don’t want to discourage the development of the RPM approach, because I really like it, but can’t we also communicate that setting up Bahmni manually is also possible by a simple set of steps like:
Install Sun Java 7, Tomcat 7, MySQL 5.6
Deploy X version of OpenMRS 1.12
Deploy Y versions of various modules (all of which can be found in OpenMRS Nexus or Bahmni Artifactory)
Create a bahmnicore.properties file with a particular set of properties
Add a bahmni-config folder with a particular structure
Deploy the bahmni app to either a) tomcat or b) apache depending on your setup
Is there more to it than this? I feel like we should empower users in challenging circumstances to be able to set things up this way if it is easier for them. It also demystifies “Bahmni” a bit, and enables users to recognize that it is an extension of OpenMRS.
This is certainly how I plan to set up my development environment, and to try to extend the OpenMRS SDK to support it, regardless of whether we use the RPM approach in production or not.
Thanks for your advice
I think a technical layered diagram could help in understanding how
everything stacks up in Bahmni setup. May be worth documenting for its own
In the context of this thread though.
The complexity here is rather basic than caused by Bahmni setup being RPM
based. We have all Bahmni RPMs available and if something missing could be
easily fixed. But RPM package based installation, which one will have to do
irrespective of Bahmni; for java, mysql, apache etc. That leads to tree of
dependencies making which available leads in the direction of making a ISO
image or something similar.
Kudos to the Bahmni collaborators.
I first learned about Bahmni from a blog post by James @arbaughj where he gave a detailed account on his visit at OpenMRS Worldwide Summit 2015. I have been a great admirer of the OpenMRS project for some time and I thought Bahmni was a wonderful addition in the EMR ecosystem.
Similarly, I was grateful for the various packaged solutions which enabled me to quickly setup Bahmni.
However, my joy ride hit a bump when I tried to perform a manual installation and stir away from the scripted path and CentOS.
I fully understand the need to provide an easy to maintain solution that will not require a full time IT specialist which in most case would be cost prohibitive, but I would also argue that even this noble goal should not come at the expense of shackling what is otherwise a web base application. I applaud proposed efforts to decouple such requirements.
The irony being, in trying to install Bahmni manually, I find myself spending the lion share of my time chasing OS dependencies, instead of doing actual development work in Bahmni.
I would like to comment on this thread regarding some complexities involved in Bahmni installation.
Bahmni is a distribution consisting of various applications like
b) Bahmniapps (angular js app running on apache)
c) OpenELIS (Lab System),
e) connectors which connect them to OpenMRS (like openerp-connect, bahmni-lab-connect using Atomfeed mechanism),
g) event-log-service (currently in alpha and used for offline support and synchronization),
h) Offline mobile app (with chrome extension) - this is WIP
and the list goes on. On top of this, we support mysql, pgsql replication at some of the sites. The abstraction of installation using ansible (and rpms) helps the implementers of Bahmni.
Even if it were a big list of instructions (or steps), I am not sure if it will be an easy installation.
Thanks for your feedback.
But since we are talking about multiple things here, I want to confirm you
ended up chasing RPM dependencies when you were trying to install in
offline mode? If so, then yes, we haven’t really solved that problem yet.
May be we need to be more clear that is an unsolved problem from Bahmni
But I got confused when you say that you are trying to development work.
Are you doing development work when you are offline?
Maybe the term “Bahmni” is confusing the matter here–I think what @mseaton and @esimeon are asking for is the steps to manually install the"Bahmni OpenMRS distribution".
Many of us are already very familiar with setting up OpenMRS in various forms, and so don’t need specific instructions on installing OpenMRS, but just the steps to set the Bahmni distro on top of it, which I assume would generally include:
Specific version of OpenMRS Core
A set of specific versions of required modules
Specific required metadata
? Anything I am missing?
I would think this would be very useful for existing OpenMRS devs as well as the OpenMRS implementers who don’t mind getting their hands dirty. I already have 4+ instances of OpenMRS installed on my development machine that I can fire up at any time, and would rather add a Bahmni OpenMRS instance to that environment and continue to develop that way rather than set up a completely separate VM, etc.
I think there may be a bit of a disconnect because I’d say that the majority of the people currently on this list would love the approach I laid out above, BUT the general audience/people new to OpenMRS (which may be a large percentage of the target Bahmni audience, because we really do need to scale up our development resources) wouldn’t really care as much because they are starting from scratch.
Apologies for resurrecting an old thread, but I just wanted to check…
Given Bahmni is still limited to CentOS (i.e. just one OS), if I were to fork the current bahmni-playbooks repository, add an optional, local-install option and then create a pull request would it be likely to be accepted?
I’d imagine we might be able to have a script that fetches the RPM files, stores them locally and then have the user pass a flag when re-deploying that installs (as required) the packages from local RPM files, instead? I haven’t looked at the playbooks recently, so there may be a better way – but ultimately, would this be something that you’d be open to including in the master branch?
Alternatively, given the dependencies are fairly strictly versioned (i.e. only specific versions of some dependencies are compatible, etc), could we do away with the remote check entirely and just install from the local RPM files, which could be downloaded as part of the initial Bahmni install (e.g. included in the bahmni-installer RPM)?
I provide support for a tiny hospital in a remote area of Papua New Guinea, with a very unreliable internet connection, and changes take a very long time to deploy. Something like this would make life much easier, but I’m not too keen on doing this unless there’s a chance it will be accepted into the master branch, due to the potential for code divergence.
I’d imagine we might be able to have a script that fetches the RPM files
For the RPMs only, yes that would be just fine to download them, probably directly into the Yum local repo and then run the install. Nothing would even be needed to modify in the playbooks because if a package is present in the cache and Yum does not have a connection, it will probably use the local package (if it is of the right version of course)
For the RPMs only, yes that would be just fine to download them, probably directly into the Yum local repo and then run the install. Nothing would even be needed to modify in the playbooks because if a package is present in the cache and Yum does not have a connection, it will probably use the local package (if it is of the right version of course).
The issue we have is that, whilst we have an internet connection, it is incredibly slow.
Also, you wouldn’t even need to work with yum caches, etc, as you could install the rpms using rpm -ih /local/path/to/package.rpm. This would be quicker and easier to automate, and would (as far as I can see) only require a few changes to the yum tasks in the playbooks.
However, not everything is shipped as a RPM. For instance the Oracle Java VM, OpenMRS modules, OpenMRS Core WAR file etc… Those are components that are fetched during installation.
That’s true, but there’s nothing to say we couldn’t include these files in the distribution, or at least download them into, say, /opt/bahmni/dependencies if they don’t exist and then ensure that ALL installations of these packages/WARs/omod files etc are installed/copied from a local path. If a local path can’t be used for whatever reason (i.e. with omod files, or whatever), we could start a simple ruby or python server (i.e. ruby -e -run httpd /opt/bahmni/dependencies -p 4000, python -m SimpleHTTPServer 4000).
I’ve done this for a copy of Bahmni 0.85 that I’ve been using in a development environment and haven’t had any issues at all.
Or did you consider creating a Docker container all set up the way you want (see Running Bahmni on Docker) and store the container in a repo accessible offline?
A docker container on a private registry may work in this instance, but I think it would be great to have a mainstream solution so that everyone can benefit from the performance/reliability improvements which would occur as a result of using locally sourced dependencies.
IMO, docker is already becoming so mainstream that this might be best approach to adopt.
Beyond the RPM files, there would be also tons of python libraries that you need to have.
Btw, recently at a conference I met up with few of the RHEL Fedora and CentOS core team members. They advised me not to invest on anything custom or adhoc till the new modularity features are packaged in forth coming releases of all RHEL distributions, sometime in April/May. (Actually RHEL enterprise and Fedora latest already have them). For Bahmni we have to do major upgrade on platform - OS, Python, etc etc. Many things we assumed were standards probably will have to relooked at and redesigned for packaging and distribution.
Actuallly we should start investing our time to learn about modularity and how to work with it immediately. We are already finding supporting python and dependent libraries hard.
I recently experimented setup of Odoo 11 on CentOS 7, and I had to break my head for a few days, compile things locally (including python 3.6) and still couldn’t do it all.
Whether modularity features are going to solve all our provisioning problems, I am sure it will not. but it will ease things. My gut feel is that upgrading Platform is going to be an enormous task, isolation with docker may buy us sometime till we figure native approaches.