Today I asked myself what the differences between the two Node Manager versions are.
The documentation says:
Java-based Node Manager provides more security than the script-based version.
But why is the Java-based version more secure?
See: Node Manager Dokumentation
Determining Which Node Manager Version to Use:
The script based Node Manager requires a much simpler security configuration than the Java version. RSH and SSH are generally easier to configure than SSL which is the method of security used by the Java version of Node Manager. The script version of Node Manager also required a smaller footprint than the Java version
http://docs.oracle.com/cd/E13222_01/wls/docs92/server_start/nodemgr.html
Related
I'm using Karaf 4.2.3 over JDK 1.8. I had ran a Black Duck Scan, and it is pointing to Apache ActiveMQ -5.15.9 with some vulnerabilities, one of them is critical. I'd like to know if it is possible to get this updated to the recommended version which is 5.17.1. Please if you have some advice it'd be highly appreciated. I'd like to point out that in the current project, I'm not really using ActiveMQ.
ActiveMQ 5.17.1 requires Java 11 so you won't be able to use that. You should upgrade to ActiveMQ 5.16.5 instead. It's the latest version which supports Java 8. That said, if you're not using ActiveMQ in your project then the simplest (and most secure) thing you can do is just remove it.
I know Mule ESB Enterprise edition can be installed on Raspberry Pi because it ships with support for arm based processors. Unfortunately, Community edition does not have it. This makes it difficult to use Mule ESB on pi for longer time as I don't have the enterprise license (it's for personal projects and enterprise trial ends in 30 days). I wonder, why community edition does not have this support? Are there any restrictions for using community edition on pi?? Can the support be added to community edition? Has anyone done it and using it?
Yes, it is possible to install and run Mule on Raspberry PI 3 (and by extension any armhf/armel machine). You have to tweak your installation to ensure Mule uses the Linux armhf 32-bit Java Service Wrapper (or the related OS/architecture Wrapper). The steps in details:
Install Mule CE
Install Mule Standalone as you would do on any other machine:
Download the Mule CE Runtime
Unpack the content somewhere, such as in /opt/mule (i.e. MULE_HOME=/opt/mule) and change owner of the content to a Mule user (such as mule:mule)
Optionally, perform some hardening
You should be able to run Mule using $MULE_HOME/bin/mule start|stop|restart
Configure Java Service Wrapper
You need to manually add the Java Service Wrapper support for your OS and processor architecture, for Raspberry PI 3 it would be Linux armhf 32-bit.
Download the Linux armhf 32-bit Community Tanuki Java Service Wrapper and unpack it
Copy the Wrapper lib/libwrapper.so to $MULE_HOME/lib/boot/libwrapper-linux-armhf-32.so, ensure it has read+execute permission and is Mule user owned
Copy the Wrapper lib/wrapper.jar to $MULE_HOME/lib/boot/wrapper-{version}.jar (replace {version} by your Wrapper version), ensure it's Mule user owned and remove or backup somewhere else the previous wrapper-{oldVersion}.jar
Copy the Wrapper bin/wrapper to $MULE_HOME/lib/boot/exec/wrapper-linux-armhf-32, ensure it has read+execute permission and is Mule user owned
This one is a bit tricky, you have to update the $MULE_HOME/bin/mule launch script. Look for the line case "$PROC_ARCH" in, Such as:
'x86_64')
DIST_ARCH="x86"
DIST_BITS="64"
break;;
Each case match a specific hardware name to define DIST_ARCH and DIST_BITS variables, allowing to use the proper Wrapper files. Add a new case to handle your Raspberry PI hardware. For Raspberry 3, it's should be something like armv71 (check with uname -m if required):
'armv71')
DIST_ARCH="armhf"
DIST_BITS="32"
break;;
You may need to update $MULE_HOME/conf/wrapper.conf to avoid memory related issues. I usually have to play around with the following properties:
wrapper.java.initmemory=512
wrapper.java.maxmemory=512
wrapper.java.additional.X=-XX:PermSize=256m
wrapper.java.additional.Y=-XX:MaxPermSize=256m
wrapper.java.additional.Z=-XX:NewSize=512m
wrapper.java.additional.V=-XX:MaxNewSize=512m
When Mule will run on armv71 hardware, it will now use wrapper-{OS}-{DIST_ARCH}-{DIST_BITS}, in our case wrapper-linux-armhf-32. You should be able to run Mule as usual - check the logs for any error on start-up.
This method has been tested with Raspberry PI 2 and 3 for Mule CE 3.7 and 3.8 (it should work for previous versions). It may be a bit tricky, if you have any issue post a comment I'll update this post to add details.
By the way, this method can be used to add support for any architecture and OS as long as it is supported by Java Service Wrapper.
I wonder, why community edition does not have this support?
I don't know, Mule CE simply does not support ARM architecture - for now. Only a limited list of platform and architecture is supported by CE (i.e. the launch script filtering architecture types). Maybe they simply did not take the time (~money) to add support, or they purposefully prevent ARM support to favor Mule EE. Considering Mule CE is open-source, in theory someone could contribute to add such support... (just saying ! :)
I'm starting to use redis for my applications as a cache backend and "shared memory" store.
I've asked the servers maintenance team to install Redis on our CentOS 6.5 production environments. From EPEL, the version is 2.4.10, which we hope will upgrade in the future. Also, on our internal registry, we have a 3.0.7 available. The maintenance team would prefer the EPEL version.
I'm not quite sure of the differences between the versions. I haven't found a document listing major changes from 2.x to 3.0. Are there major features/ performance improvements/bugfixes in 3.0 that I MUST have?
My first guess is that 2.4.10 would be sufficient enough for my needs.
The most significant change from 2.x to 3.0 is that Redis 3.0 introduces Redis Cluster which is a distributed implementation of Redis.
You can also get change list (bug fix, new features and so on) of other versions from 00-RELEASENOTES file of each version: github link:
I am getting following error while running /tmp/jprofiler8/bin/jpenable
No suitable Java Virtual Machine could be found on your system.
The version of the JVM must be at least 1.6 and at most 1.7.
Please define INSTALL4J_JAVA_HOME to point to a suitable JVM.
You can also try to delete the JVM cache file
I have also set INSTALL4J_JAVA_HOME to point to suitable JVM.
Java version on my machine is 1.4.2.
Can anyone please suggest what might be wrong or missing?
Unfortunately you did not mention details about your environment, so I don't know which Linux distribution you use.
There are some options though:
install a current JRE alongside the installer for JProfiler
As you can't install or update Java, you could provide a JRE in a kind of "portable application" setup. Simply unzip the server jre Oracle provides or (if you are not on an x64 architecture) unzip the jdk you also can download from Oracle.
But if the code you want to profile is limited to your pre-installed Java 1.4 you will run into another problem, because as far as I know Java 1.5 is the minimum JProfiler expects
use a different machine for profiling
Unless your code depends heavily on the environment you run it in you can even take a Windows 8.1 machine and profile the code there. Code that is slow is slow on any operating system. Or make use of a different Linux computer.
I need to do integration testing for a spring cloud application running with spring data on redis.
Tests work locally with the regular redis server instance and I need to run this on a Jenkins CI server that is controlled by the corporate CI engineering group.
Obviously I can attach to a redo server there so I used an embedded redis server (from here: https://github.com/kstyrc/embedded-redis).
Running tests locally with this redis server works well since there is a test profile to inject the embedded server in place of the production one.
Now the problem is that when we run this in the Jenkins environment this is the error we see.
/tmp/1430170830037-0/redis-server-2.8.19: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /tmp/1430170830037-0/redis-server-2.8.19)
So this version of redis has specific dependency on a specific version of glibc. I tried a couple of other libraries but they all depend on the same underlying version of the embedded redis server.
Is there a spring data mock framework that can be used to get around this sort of issue?
This might come a little late for you, but there is indeed a Spring Data Mock framework that you can use, which let's you mock repositories (regardless of the specific backend solution) without a real database connection.
Here is a link: https://github.com/mmnaseri/spring-data-mock
You don't have a high enough version of libc6, that is causing the error.
From How to fix “/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found”? – Super User:
That means the program was compiled against glibc version 2.14, and it requires that version to run, but your system has an older version installed. You'll need to either recompile the program against the version of glibc that's on your system, or install a newer version of glibc (the "libc6" package in Debian).
So, you just need to upgrade your libc6 package. All versions of Ubuntu have at least version 2.15 because it's a faily important package (reference).
To upgrade it, use these commands in a terminal:
sudo apt-get update
sudo apt-get install libc6
p.s. This is answer from askubuntu.com by minerz029