Please make sure to patch all OpenMRS our test environments

Hi everyone,

As you are aware, we do provide some test environments for OpenMRS. https://wiki.openmrs.org/display/ISM/OpenMRS+environments

Apparently not all of them were patched to address Critical Security Advisory CVE-2018-19276: 2019-02-04

So, can I ask the owner to please patch it?

@dkayiwa, we probably need to update our release process to ensure that mdsbuilder (platform), qa/modules/uat/demo servers are regularly upgraded after a release. Where’s the best place to change the documentation?

1 Like

Hi @cintiadr ,

I verified that and both sync and sync-legacy currently use the version 2.24.0 of the webservices module (https://github.com/openmrs/openmrs-module-sync2/blob/master/pom.xml#L211).

Link to Sync 2.0 distro properties files:

2 Likes

@cintiadr i think we would add that here: https://wiki.openmrs.org/display/docs/OpenMRS+Reference+Application+Release+Process

and here: https://wiki.openmrs.org/display/docs/OpenMRS+Platform+Release+Process

1 Like

I think refapp is easy, and I changed the wiki page to reflect that.

But the mdsbuilder it’s not so simple. I’m not sure if it’s even possible to upgrade it.

Maybe we should only upgrade if there are security bugs.

We had yet another problem this week in our infrastructure due to those two unpatched instances. Our provider currently blocked our network partially due to that. To avoid that in the future, we really need to address security patches on those services.


@dkayiwa and @raff , I need your advice. To upgrade mdsbuilder instance, one needs:

The thing is: I don’t know if this is safe. Is this something we can ask to be done on every release?

If so, I’m fairly sure I can make the deployment easier.


@darius or @ball, what can we do about ebola environment? Do we have anyone who could make sure it has the security patch applied? I’m afraid I cannot maintain a public system running such a vulnerable code.

Sorry, I missed your April post. I will try to figure this out.

@cintiadr why do you think that this may not be safe?

I really don’t understand our distributions or if there are breaking changes. If, for example, we need to upgrade those plugins, or if the release manager will be able to test the distribution locally before deploying.

Generally, i feel that this is a good place to start. We can update the release process to include these extra steps. I trust that given time, you can make it even easier. :slight_smile:

Hopefully fixing the Ebola distro is as easy as changing the REST module version to 2.24.0.

Unfortunately I don’t have an OpenMRS dev environment set up now. I can probably test this within a week, but can’t guarantee when.

If someone else is able to clone the repo, make a one-line change to the distro properties file, run it with the SDK, and manually poke the UI to see if anything obvious broke, please do!

Dear Darius

I rebuilt my local ebola from scratch with (old) rest 2.12. Created a patient; found patient record, ebola dashboard. However I don’t see how to add a patient to a ward. It does not show active patients – although I created 2 patients and all privileges set for the user. Ward rounds looks like this (grayed out).

I changed the openmrs-distro.properties

  • omod.webservices.rest=2.24

It works the same, but I’m not able to test the uiframework pages. Not sure if this proves that the new rest module isn’t breaking anything.

Ellen

I will be recreating this VM over the weekend, so both mdsbuilder and ebola will be down.

Data shouldn’t be lost.

@cintiadr I just edited https://github.com/openmrs/openmrs-module-ebolaexample/blob/master/openmrs-distro.properties to include the latest security-patched version of the REST module. I enabled the CI plan, and kicked off a build, but it failed with what looks like a permission issue https://ci.openmrs.org/browse/EBOLA-EEM-1209/log, and I don’t have time to debug now.

Does the ops process for this demo require that I do a successful bamboo build? Or is it enough to have updated the distro.properties file?

I was not able to test this locally (got blocked because it requires Java 7), but I hope Ellen’s test is a bit indicative that it will work. And worst case, if this doesn’t work, we’ll find out when the demo is up.

It should be fine, @darius , I will get that build green (no idea what’s happening, but it’s definitely an infra problem).

Thanks :slight_smile:

So that’s related to the fact that we need to update JDK 7 to a most recent update, which supports letsencrypt.

I attempted to upgrade the java to 8 (keeping the compatibility mode to 6), but that seems to have failed important tests. I contacted the OpenJDK repository to see if they plan on offering the new updates, otherwise I’ll have to come up with another work around.

JDK 7 is just not helping me: JDK 7 is not working anymore in CI

Anyway, I attempted to just use JDK 8, but there were test failures. I disabled to tests to see if the server would at least start when I deployed the new machine, without bitcoins miners.

But the provider blocked my access :smiley: Anyway the applications are down now. I’m not even sure what they expect me to do.

@raff, is there any chance you could verify that mdsbuilder data still correct? The server was recreated.

@darius and @ball

I’m having trouble with ebola demo.

If you clone ebola example module and run:

mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:3.12.0:build-distro -Ddir=docker -Dbundled=true -U

It will generate the dockerfile in web/Dockerfile. That will have tomcat 7 base image, which is JRE 8.

https://ebola-demo.openmrs.org/openmrs/initialsetup

Now it’s complaining that I’m not running Java 6. Finding a java 6 docker image won’t be easy, so I’m not sure what to do.

I believe that ebola needs Java 7. Not sure why it’s complaining about needing Java 6.

Which OpenMRS Platform version is the ebola demo running?