I’m a newbe on the openMRS site, and intend to work on some development and testing of openMRS.
I have had a good look around and find that the Bahmni / vagrant VM thing is very interesting.
However I’m a `debain’ nerd, and as such would like some assistance in setting up Bahmni on debian (eventually creating an ‘official’ deb installer maybe ??)
Also this would seem interesting as in my experience debian derrivatives (I’m thinking Ubuntu here) seem to be very popular, and this would enable more potenital users to try a demonstration install of openMRS.
Just to gauge the popularity of this idea, I am attaching a poll [poll]
Yes lets try for a debian version of Bahmni
This us stupid don’t do it
[/poll]
In light of the response I propose to continue this thread as the initial discussion place for this idea.
I’m leaving the poll open until we get a ‘critical mass’ of positive votes. Admitedly I’m not sure what the critical mass should be…
Looking at the forums (particularly this thread Can I install Bahmni on Ubuntu linux?) which has 500+ views, I’m guessing that this may be quite popular.
Thank you for your interest in Bahmni.
For now you can follow Bahmni Wiki to install Bahmni on Virtual Box. We do have debain ehnthusiastics(@ajjaswanth) in our team. We would love your help in creating Bahmni Deb installer.
@scibearspace :
As @swathivarkala pointed out, Debian packaging is something that we have been thinking about.
We can share, collaborate and work if you are interested.
The first will be the basic openMRS made available as a deb installer.
Looking at the download page there are a number of download options available.
However the reference application provides an embeded database and application server.
This works in a certain instance, but not for me. I would propose having just the raw application, then having the package install and configure (correctly) a local database and local application server.
It also notes that these are not intended for production use. The deb package should be usable as a production system (I believe), or at a minimum easily moved to be a production system.
Bahmni vagrant package.
This package build on the main deb detailed above.
In essence I propose to work our way up to a bahmni edition, gaining knowledge and experience on the way from creating a working ‘base install’
I would appreciate any comments from the current rpm package maintainers if this makes sense.
Finaly.
There is the reference app modules and data which I think we should supply as a supplemental download. An addition to the principle core system that I outlined as the package in point 1, or a simple bundling of this with the full system in either the bahmni or main pakage.
Alternatively depending on how ‘complex’ the whole thing is (ie can i create a script to do it ?) maybe we’ll end up with 4 packages.
core openMRS install, no database or application server
1.1 openMRS with non embeded database and application server.
1.2 package ‘with non’ embeded database and application server, and sample data
1.3 Application server only prepared for openMRS.
1.4 Database server, again prepared for openMRS.
Bahmni version.
2.1 Bahmni version with sample data.
The idea here is that the packages 1.1 to 1.4 will ease the install for individual wanting to install to a cluster (a likely production scenario). This would give the advantage that any updates (security / bug fixes) could be done just for these components, hopefully in isolation from the other parts of the system.
As mentioned earlier, we can work our way up to the bahmni version, maybe even get them integrated into the debian archives… but that will be a long way off.
@scibearspace, thanks for the interest in working on this!
I would suggest taking a very different approach, basically instead of assuming you’ll start from existing OpenMRS downloads, you should start from the existing Bahmni packaging scripts that are used to build the RPMs.
For example I would start by modifying these three gradle scripts to publish debs (alongside the rpms), and see what might need to be changed to get this to work:
As @darius mentioned, the 3 gradle scripts are the one’s that make the basic Bahmni up and running. Once we have the deb’s (openmrs, bahmni-emr and bahmni-web) ready, the next step is to concentrate on generating the bahmni-command line tool and install these deb’s using “bahmni install” command.
I’ve looked through a selection of the gradle.build files.
I’m not sure I made it terribly clear previously, but I’m a ‘newbie’ in terms of packaging (part of the reason I suggested the route I did was to use the main openMRS code in the debian tutorial for package building). But anyway… ever onwards… deeper into the abyss …
First impressions:
There are a number of variables in the many gradle files, such as buildir and projectdir are these coming from the actual os (ie centOS) as part of the rpm creation or are you setting them in a settings file somewhere that I haven’t found yet ? (did I mention I’m a newbie in terms of packaging ;)) ~ although on second look they remind me of maven / ant variable names.
However I can mostly follow what you are doing in the files.
so I can happily extract the various ‘dependencies’ etc.
Further to the links to the files you have already mentioned I notice that there are a lot of other directories under the bahmni-package parent.
I assume somewhere there is a ‘master file’ that will then include all of these others, but for now I haven’t found it, otherwise is there a documented chain of events that are required to be followed during the production of the rpm s?
Just to close…
If I was to run the various scripts for creating the rpm packages, what is the directory structure to ensure it ‘picks up’ the required files from either the maven repo or from the ‘local’ system.
sorry for the ‘silly’ questions… did I mention that I’m a newbie to packaging…
Bahmni-Package is the repo that contain directories each being a separate rpm.
For the dependencies… we right now manually place in the required position (to build the rpm’s locally)
But as part of build process, this is automated in our CI pipelines.
sorry, there is no doumentation for this. Please follow the below steps to manually build the rpm in your local.
cd bahmni-package
./gradlew bahmni-emr:buildRpm // building bahmni-emr rpm
Please let me know if you need any other clarifications.
Looks interesting. I am not a java developer so I haven’t used gradle. I may need some time to digest gradle code.
Few days back I installed OpenMRS on a LXC container. I would say base openMRS (war file) and the reference application (modules) as .deb can be easily done. I can write the shell script for to build .deb package. The package will have dependency check for tomcat8 and mysql and install them if not already installed.
Coming to Bahmni, I need some support from Bahmni team so I can create either the bash script or gradle script.
Bahmni installer (rpm based) seems so complicated. When all of the process can be done using installers post-install scripts. Can’t understand the logic of running a shell / python script after rpm deployment.
Let me know what rpms that go into Bahmni destribution. I will try to pack it into one deb and also write the post-install script for debian / ubuntu based system, which will be executed while .deb deployment itself.
Bahmni installers requirement of centOS version 6 will soon mean that Bahmni will be only running on unsupported version of centOS.
The idea is that a single fixed configuration of Bahmni isn’t going to work for all people (e.g. some people want OpenELIS, and some don’t), so we’ve separated things into multiple packages.
We do want to get this upgraded to the latest version of CentOS, but nobody has been able to prioritize this work yet. Here’s the trello card for it (though there’s no useful info here).
Pre-install script can be used to query for install options with the client and install what they want.
This week I am held up with other projects. I shall look into the .deb build next week. My strategy would be to download and extract the rpm and then build the .deb package from it. I am planning to keep all bahmni files under /opt/bhamni and create the necesary links to the war and config files as needed.
@drexvictor, let us know how this goes, and take good notes on how you need to reorganize the files to make things work as an rpm instead of a deb.
In the long run we would want the build scripts that our CD server runs to simultaneously package the build as both rpm and deb. So even if you aren’t able to do this yourself in the gradle build scripts, if you can document this process then someone else can do them in gradle later.