My mirth is running on an AWS EC2 instance. I want to upgrade the version of Mirth Connect running there. I am currently using 3.8.0, which I want to upgrade to version 3.11. However, I haven't found any good instructions or scripts for performing the upgrade that does not involve GUI tools. Does anyone know where I can find such a script or instructions?
In place upgrades are not safe, given enhancements within Mirth Connect itself and JRE. Many changes might have happened across versions 3.9 and 3.10. I suggest getting the appropriate tar.gz file version from the NextGen website then installing version 3.11.0 as a second instance while assigning different HTTP and HTTPS ports. You can then export channels in version 3.8 and do incremental imports to version 3.11.0 while you monitor closely. The command line interface documentation here offers an easier way to handle channel exports and imports.
Related
We are trying to upgrade Rundeck version from 3.0.27 to the latest version (3.4.7)
We got below questions,
What is the approach to upgrade from 3.0.xxxx to 3.4.7? Could we do a direct upgrade or otherwise, if we have to run through multiple intermediary versions, what are those?
Does upgrading from 3.0.xxx to 3.4.7 fix the log4j vulnerability?
Please help to clarify above.
Thanks
Due to the big gap between 3.0.X and 3.4.X (and the upcoming 4.0.X) the best way to upgrade your instance is to create a fresh 3.4/4.0 instance and then import your projects and keys (exported previously), as a tip, try this on a non-prod environment first.
Rundeck 3.0.x uses log4j 1, so, even if the vulnerability doesn't affect explicitly the log4j 1.x EOL was in 2015 and isn't supported anymore, so, it's important to move to the latest version (Rundeck 3.4.10 at this moment).
I have read a lot about how bad this issue is and understand the options available to locate it within the code our company is producing and update servers that are using vulnerable versions.
What I am unable to find is if a particular server does not have Java installed i.e. if I log in as root and run java -version and get java: command not found is this server completely safe from this issue and so I can move on?
My initial instinct was: no Java - no issue. However, GitHub released an update for their Enterprise servers stating:
CRITICAL: A remote code execution vulnerability in the Log4j library, identified as CVE-2021-44228, affected all versions of GitHub Enterprise Server prior to 3.3.1. The Log4j library is used in an open-source service running on the GitHub Enterprise Server instance. This vulnerability was fixed in GitHub Enterprise Server versions 3.0.22, 3.1.14, 3.2.6, and 3.3.1. For more information, please see this post on the GitHub Blog.
And yet Java is not installed on their enterprise server.
I am guessing the offending service must be with Java running in a docker container. So I think I need to consider Java on the machine or Java running in a container.
Are there other hidden ways I have not considered in which this log4j process can be running?
log4j2 is a library that must be used by a running java process, to be vulnarable. But you are right, that checking if the java command is installed to the command line is not enough.
Here are two options (not meant to be complete), how your system could still be vulnerable without having the java command available on the command line.
Java could be downloaded into a directory without adding the java command or directory to the executable PATH. By using a .bash (or .bat) script a java process pointing to the downloaded java version could still be started. But when the directory is not added to the path, you will not find the java command enabled.
Java could be running inside of a docker container. the java command would only be available inside of your docker container but not visible from outside. I am not sure if an additional exploit would be required to break out of the container of if this is easily possible without extra effort.
I don't have a full answer yet but very definitely NO you are not safe even if Java is not installed, and Docker is not installed, and Java is not running in the process list, and Java is not in your yum/apt installed applications lists.
An obvious case I had not considered is when Java is added to an app as a JRE.
A Coverity platform server we have does not install Java but Java is running e.g. ps -ax | grep java
/home/coverity/cov_platform-2021.9.0/jre/bin/java -Djava.awt.headless=true -Djdk.tls......
Working out if a vulnerable version of Log4j is included in that JRE is much harder.
Further, just checking the process list is not enough either. In this case the process list contained java but Java may only be run when triggered by another process e.g. cron, nginx, etc
We upgraded our Oracle DB and oracle client from 12.1 to 19.10.
Our application server have below setup
OS is Linux
Python version is 2.7.5 and there is no plan to upgrade the python version yet
cx_Oracle library version is 5.3
A quick test shows the application works fine but I am wondering if I need to upgrade the cx_Oracle library? Does it have a support expiry date? I tried to google it, read the information on its Github page but can't find any statement that answers my question.
This combination hasn't been tested. But since the Oracle Client libraries keep compatibility it is likely to work, subject to whatever underlaying enforced changes have been made to the Oracle libraries, perhaps to drop unsupported TLS versions or whatever has occurred in the 8 years since 12.1 was released that I don't know about. You application testing should be the final confirmation.
You should definitely set a goal to update to Python 3 so you can get the latest cx_Oracle version.
So I am in the following situation:
We are writing an application which needs to be deployed onto the customer machines which are running either some older version of Ubuntu (16.04 or some older) or Debian 9. Till today our application was packaged as a standard .deb package and it had system dependencies in a way that a sane apt install could handle installing it together with all its dependencies (such as Qt, sqlite, gdal, proj, etc...).
Due to some requirements however recently we have developed a few features which require that some libraries, specifically gdal and proj are using the latest version of aforementioned libraries, which are not to be found on these older systems and we can't got to each of our customer and compile these libraries on their machines.
So, obviously the question comes:
What are the best recommendations to deploy our application in the most painless way with the new libraries onto the old systems?
I have looked into AppImage but I just can't get my head around it (and did not find a good tutorial on how to deploy a Qt application with it), and flatpak and snap are not good, since we don't want to depend on any other repositories.
Is it possible to install multiple GitLab versions in single server? I already have GitLab 5.0.1 installed and running and planning to install 6.8 on the same server, will there be any issue?
You are lucky :)
We have a GitLab recipe for that.
It can be an issue since the gitlab requirements can change and evolve from 5.0.1 and 6.8.
6.8 seems to support Ruby 1.9.3 still (like 5.+ did), so it might work.
But the easiest way to install multiple instances would be to isolate them in a Docker container, which is available on a (recent 3.10+) Linux, but also possible on a Mac or Windows, with a Vagrant 1.6+.
(See "Vagrant: Docker-Based Development Environments")
Without that isolation, you need to ensure no resources are shared, which is what that document describes, as mentioned in axil's answer.