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.
Related
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.
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.
I have a machine running FreeBSD and the ports tree is accidentaly updated to one of FreeBSD 8 stable. The problem is that my FreeBSD 8.1 is not configured to use PKG for packages so I cannot update or install packages.
I want to upgrade the machines FreeBSD but get the ports tree in working order before I do that.
It seems the only solution is installing an old 8.1 version of the ports tree, but I cannot find any.
Can someone tell me where to find this?
Would upgrading to the lastest stable version 8 also solve my problem?
As far as the "8.1" tree, you can find that by using svn to checkout ports/tags/RELEASE_8_1_0 instead of ports/head but keep in mind this tree is going to be terribly out dated and have lots of insecure software and many things are not even going to fetch properly any more. This is probably not the way to go.
Instead, you are better off upgrading to 8.1, but that is one of two steps needed to fix your situation. The other step is to switch to pkg(ng). The way to do that is to run pkg2ng. See the handbook section on pkgng for more details. Running pkg2ng is a one time operation and doesn't require rebuilding or re-installing all your ports. Instead this just tells pkg about the existing software so it can manage it.
I'm trying to get started with Node.js on a Windows machine. Yes, I found the installer on their site. That worked just fine and I can run it. However, after that there's no instructions or requirements. Some issues I ran into:
I learned that most of these cool modules need to be built locally.
I was told I needed Git installed
I found I needed Python to build modules
I discovered I needed Visual Studio to compile
Once things are built they should be executable. However, they are not natively found in the path. I discovered them under %APPDATA%\npm, but there's no mention of adding that to the PATH.
What else am I going to discover? Is there a guide to this anywhere?
Altough I might suggest you to develope node on a unix based os (Ubuntu 12.04+WebStorm is my favorite combination for many reasons I can mention) I found my self in your situation at work when Windows 7 is a must.
I found this video really helpful
Once youe have node installed on your machine (window or any other) I (and most community) would recommend you to use WebStorm as IDEA it contains every inch of support to make your development process easy and clean, mange your global and local modules and build/debug your code easily.
It sounds like you've actually installed Node.js fine, but are having problems with the packages built by people in the community, some of which use Python or a native C compiler. Git shouldn't be necessary unless you're perhaps cloning projects from a remote repository? Or maybe the packages have dependencies on projects hosted in GitHub?
Keep in mind that Node is separate from all the modules and packages available in the community, accessed through the npm registry. Node provides you the ability to execute JavaScript locally, additional APIs, and an ecosystem to build additional packages which can do, as you've said, really cool things. But each of these packages can have unique installation requirements.
Most packages have dependencies of their own, and are often installed using the npm install command. This (usually) downloads other packages from https://www.npmjs.org/, and in some cases requires compiling additional files. This might have been the issue you hit.
The other thing to keep in mind is that a lot of people might assume things are installed and available since they have it installed for them, or are running a different operating system than you. I've often found that folks will hard code / somewhere in their scripts, which cause problems on Windows based systems. This can lead to problems with the executables that are created as part of the node packages created by the community.
To better understand what Node has and what's available, I'd recommend the nodeschool.io projects. These cover some of the main areas provided by the base Node platform, and get you used to playing around with things from GitHub and npm. Maybe if you run into specific issues there folks can help more directly.
I customize Linux (RHEL) Operating Systems releases for specific platforms/customers, etc... (and windows). We do kickstart installs, customize the branding, install specific packages, customize partitioning, etc...
I need suggestions on better ways to version control these OS's. Currently, we use SVN to Control the base installs (i.e. RHEL 5.6, 6.1, etc...) We don't upload the base RPMS to the Subversion server as they bloat the repo quick, only custom elements. We have YUM repos for each of the versions. A script gets run after checking out the base OS version which then performs a grab from the YUM repo for the specific package versions needed. I have been unable to find any other posts/guides doing exactly what I need to do.
We basically have to version control the package list for each OS release and do goofy things to get the packages into the base OS to create the final OS image which then gets installed via kickstart (different process for windows).
I find this cumbersome and leads to potential errors. There must be a better way! I've looked into an Artifact Repository for the non-modified components but not sure if this will significantly help me.
PS: Version control for each custom release is critical, I can't even just say RHEL 6.2 is RHEL 6.2, I have to be able to prove the custom release is the correct custom release somehow (as SVN would do).
ANY suggestions are appreciated!
Have you considered using Pulp? You can create a repository for each "release" that you want to track.