Unable to resolve com.sun.jna when running Sonatype Nexus Repository Manager 3.6 on Linux for ARM architecture - repository

The following error appears after extracting the Linux archive (nexus-3.6.2-01-unix.tar.gz)
then, nexus run
ERROR: Bundle com.sun.jna [9] Error starting reference:file:system/net/java/dev/jna/jna/4.1.0/jna-4.1.0.jar (org.osgi.framework.BundleException: Unable to resolve com.sun.jna [9](R 9.0): missing requirement [com.sun.jna [9](R 9.0)] osgi.native; (|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=wince)(osgi.native.processor~=arm))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparcv9))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ia64))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=macosx)(|(osgi.native.processor~=x86)(osgi.native.processor~=x86-64)(osgi.native.processor~=ppc)))) Unresolved requirements: [[com.sun.jna [9](R 9.0)] osgi.native; (|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=wince)(osgi.native.processor~=arm))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparcv9))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ia64))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=macosx)(|(osgi.native.processor~=x86)(osgi.native.processor~=x86-64)(osgi.native.processor~=ppc))))])
org.osgi.framework.BundleException: Unable to resolve com.sun.jna [9](R 9.0): missing requirement [com.sun.jna [9](R 9.0)] osgi.native; (|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=wince)(osgi.native.processor~=arm))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparcv9))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ia64))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=macosx)(|(osgi.native.processor~=x86)(osgi.native.processor~=x86-64)(osgi.native.processor~=ppc)))) Unresolved requirements: [[com.sun.jna [9](R 9.0)] osgi.native; (|(&(osgi.native.osname~=win32)(osgi.native.processor~=x86))(&(osgi.native.osname~=win32)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=wince)(osgi.native.processor~=arm))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86))(&(osgi.native.osname~=sunos)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparc))(&(osgi.native.osname~=sunos)(osgi.native.processor~=sparcv9))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc))(&(osgi.native.osname~=aix)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc))(&(osgi.native.osname~=linux)(osgi.native.processor~=ppc64))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86))(&(osgi.native.osname~=linux)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=linux)(osgi.native.processor~=arm))(&(osgi.native.osname~=linux)(osgi.native.processor~=ia64))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=freebsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86))(&(osgi.native.osname~=openbsd)(osgi.native.processor~=x86-64))(&(osgi.native.osname~=macosx)(|(osgi.native.processor~=x86)(osgi.native.processor~=x86-64)(osgi.native.processor~=ppc))))]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4132)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1371)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.lang.Thread.run(Thread.java:748)
Despite the error, from a quick test, nexus appears to run normally. However, a solution or a workaround for the error would be very welcome.
Nexus Version: Sonatype Nexus OSS 3.6.2-01
System info
uname -a
Linux arm-host 3.14.79-27-ARCH #1 SMP PREEMPT Mon Jul 10 19:29:37 MDT 2017 aarch64 GNU/Linux
Java version
java -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
Related post: Cannot run Sonatype Nexus Repository Manager 3.0 on Windows 2012
An issue was opened here:
https://issues.sonatype.org/browse/NEXUS-15107

After testing the latest version of the Linux archive (nexus-3.10.0-04-unix.tar.gz) I can no longer reproduce the issue, therefore it has been resolved.

Related

A JNI error has occurred in Serverless DynamoDB Local on Mac

When I try to use DyanmoDB Local (https://www.serverless.com/plugins/serverless-dynamodb-local)
A JNI error has occurred.
Error: A JNI error has occurred, please check your installation and try again
In terminal, java, javac version is samed.
$ java -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)
$ javac -version
javac 1.8.0_281
And $JAVA_HOME is not set. but it is not problem.
Because it was executed in other Mac without $JAVA_HOME

Unable to provision rabbitmq using chef and testkitchen

I am trying to install an old version of RabbitMQ using Chef (cookbook 'rabbitmq', '~> 5.8.5') and Kitchen, below my configuration:
Attributes
#Erlang
default['erlang']['install_method'] = 'source'
default['erlang']['source']['version']='R13B03'
default['erlang']['source']['checksum']='e7c46c8b2778f22064a3b369c1a1b572a1cc0e8a2198166858d4b9a1b488d662'
#RabbitMQ
default['rabbitmq']['erlang']['enabled'] = true
default['rabbitmq']['version'] = "3.4.4"
default['rabbitmq']['rpm_package'] ='rabbitmq-server-3.4.4-1.noarch.rpm'
Recipe:
include_recipe 'rabbitmq::default'
When I run kitchen converge, I am getting the following exception:
Running handlers:
[2020-08-22T22:20:07+00:00] ERROR: Running exception handlers
Running handlers complete
[2020-08-22T22:20:07+00:00] ERROR: Exception handlers complete
Chef Infra Client failed. 9 resources updated in 06 minutes 26 seconds
[2020-08-22T22:20:07+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
[2020-08-22T22:20:07+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2020-08-22T22:20:07+00:00] FATAL: Mixlib::ShellOut::ShellCommandFailed: rpm_package[/tmp/kitchen/cache/rabbitmq-server-3.4.4-1.noarch.rpm] (rabbitmq::default line 224) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of ["rpm", "-i", "/tmp/kitchen/cache/rabbitmq-server-3.4.4-1.noarch.rpm"] ----
STDOUT:
STDERR: warning: /tmp/kitchen/cache/rabbitmq-server-3.4.4-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID 056e8e56: NOKEY
error: Failed dependencies:
erlang >= R13B-03 is needed by rabbitmq-server-3.4.4-1.noarch
---- End output of ["rpm", "-i", "/tmp/kitchen/cache/rabbitmq-server-3.4.4-1.noarch.rpm"] ----
Ran ["rpm", "-i", "/tmp/kitchen/cache/rabbitmq-server-3.4.4-1.noarch.rpm"] returned 1
But when I logged in to the VM, I can see erlang is installed:
[vagrant#kitchen-rmq-server-centos-7 ~]$ erl
Erlang R13B03 (erts-5.7.4) [source] [64-bit] [rq:1] [async-threads:0] [hipe] [kernel-poll:false]
Eshell V5.7.4 (abort with ^G)
1>
And it is the same version required by RMQ (R13B03)
Any idea how to solve this issue?
Edit: to replicate the issue https://github.com/Proximator/chef-rmq
Firstly, we have to make sure erlang is installed by the rabbitmq cookbook, and not by any other means. This is the note found on Chef supermarket for rabbitmq cookbook:
The packages are cannot be installed alongside with other Erlang packages, for example, those from standard Debian repositories or Erlang Solutions.
To make sure that the Erlang cookbook is not used by rabbitmq::default
Also, there is a compatibility matrix of RabbitMQ and Erlang versions. RabbitMQ 3.7.0 being the lowest supported version, for which the lowest compatible Erlang version is 19.3.
There are zero dependency Erlang RPMs "just enough to run RabbitMQ" as documented here:
https://github.com/rabbitmq/erlang-rpm
For example - to install RabbitMQ 3.7.x with the compatible Erlang 19.3.x:
You should have these attributes:
default['rabbitmq']['erlang']['enabled'] = true
default['rabbitmq']['version'] = '3.7.6'
default['rabbitmq']['erlang']['yum']['baseurl'] = 'https://dl.bintray.com/rabbitmq-erlang/rpm/erlang/19/el/7'
default['rabbitmq']['erlang']['version'] = '19.3.6.13'
Then include below recipes:
include_recipe 'rabbitmq::erlang_package'
include_recipe 'rabbitmq::default'

Apache MINA - stuck on SSL connection

I am having troubles with Apache MINA core library.
When I deploy my application to a remote server some of the requests are not processed (around 2%). It looks like there might be a problem with SSL.
Log tail: http://pastebin.com/48bwWsjs
When request is not being processed, it is always stuck on the:
org.apache.mina.filter.ssl.SslFilter - Session Server[40](ssl...): Processing the SSL Data
Did something similar happened to any of you?
I tried Apache-mina 2.0.7 and 2.0.16
Env:
bash-4.2$ java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
bash-4.2$ uname -a
Linux 8d9ad913fa03 4.4.39-34.54.amzn1.x86_64 #1 SMP Fri Dec 30 19:11:28 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Thanks any help!

PHP Warning: PHP Startup: Unable to load dynamic library

I am installing the ElastiCache Cluster Client for PHP on Red Hat 7.2 and centos 6.5 Amazon AMI , but issue still same on all.
cat /etc/os-release
NAME="Red Hat Enterprise Linux Server"
VERSION="7.2 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.2"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.2 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.2:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.2
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.2"
after install elastcache cluster cleint for php i got this error
php -v
PHP Warning: PHP Startup: Unable to load dynamic library '/etc/php/lib/php/extensions/no-debug-non-zts-20131226/amazon-elasticache-cluster- client.so' - libsasl2.so.2: cannot open shared object file: No such file or directory in Unknown on line 0
PHP 5.6.15 (cli)
i have installed php by compiling/configure.
please let me know how to get out from this error, i tried everything but issue still same.
On some systems, notably CentOS7 and Red Hat Enterprise Linux (RHEL) 7.1, libsasl2.so.3 has replaced libsasl2.so.2. On those systems, when you load the ElastiCache cluster client, it attempts and fails to find and load libsasl2.so.2. To resolve this issue, create a symbolic link to libsasl2.so.3 so that when the client attempts to load libsasl2.so.2, it is redirected to libsasl2.so.3. The following code creates this symbolic link.
cd /usr/lib64
sudo ln libsasl2.so.3 libsasl2.so.2
Source: From AWS documentation http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Appendix.PHPAutoDiscoverySetup.Installing.html

Can't compile 64bit redis-server

I'm trying to compile the latest stable (2.8.19) version of Redis. Build is successfull as well as all tests, but unexpectedly server runs on 32bit arch.
Log entries:
# Warning: 32 bit instance detected but no memory limit set. Setting 3 GB maxmemory limit with 'noeviction' policy now.
Redis 2.8.19 (00000000/0) 32 bit
Running in stand alone mode
Port: 6582
PID: 2381
Redis-cli INFO display arch_bits:32. Previous instance (version 2.4.6) works well on arch_bits 64, but I don't know which way it was installed.
OS version info:
root:~# uname -a
Linux localhost 2.6.32-5-amd64 #1 SMP Tue Mar 8 22:49:26 UTC 2011 x86_64 GNU/Linux
root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.1 (squeeze)
Release: 6.0.1
Codename: squeeze
root:~# arch
x86_64
What are the ways to fix this issue and run latest redis as 64bit?
UPD
Despite above commands output, dpkg --print-architecture returns i386 and all packages in system are all or i386. Only redis-server 2.4.*, installed as a package, is strangely ia64.
What can I do in this situation? The server was setup long time ago by another person, and I is still too newbie in Unix.
It seems, my server needs a full migration from 32 to 64-bit architeture.
Current task solved by downloading compiled 64-bit DEB-package and installing it manually.