karaf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Evans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (KARAF-816) Wrapper feature doesn't load security libraries
Date Sun, 28 Aug 2011 20:34:38 GMT

    [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092542#comment-13092542
] 

Daniel Evans commented on KARAF-816:
------------------------------------

This is a problem with JAVA_HOME not being present. The wrapper scripts/objects aren't as
forgiving as bin/karaf when they can't find JAVA_HOME. The service start issues the the java
command with the string %JAVA_HOME% unsubstituted, i.e.:

-Djava.endorsed.dirs="%JAVA_HOME%/jre/lib/endorsed:

Unless I'm mistaken this is windows batch file syntax, but I assume it was never intended
to be exposed (substitution was to occur internally). Failing hard when JAVA_HOME isn't present
would probably be preferable, working the same magic as bin/karaf is another solution.

Best workaround I can see at the moment is just to include "export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/jre"
at the top of the service script (put in your own JDK path). I'm not a linux expert so I'm
not actually sure how to provide JAVA_HOME to init.d scripts on startup. 

> Wrapper feature doesn't load security libraries
> -----------------------------------------------
>
>                 Key: KARAF-816
>                 URL: https://issues.apache.org/jira/browse/KARAF-816
>             Project: Karaf
>          Issue Type: Bug
>          Components: karaf-os-integration
>    Affects Versions: 2.2.2
>         Environment: Ubunutu 10.04 LTS
> OpenJDK, HotSpot
>            Reporter: Sam Hendley
>
> Using the wrapper feature to create an init.d script on ubunutu with either Java version
appears to be broken in the current karaf distribution. When we try to use the generated script
karaf starts correctly but none of the security packages are loaded. This manifests in a number
of ways when trying to use any SSL. The easiest manifestation of this bug is that the SSH
server doesn't have access to any ciphers for login. I see the following error in the log.
> AbstractSession  253 | 16 - sshd-core - 0.5.0 | Exception caught
> java.lang.IllegalStateException: Unable to negociate key exchange for item 2
>         at org.apache.sshd.common.session.AbstractSession.negociate(AbstractSession.java:886)
>         at org.apache.sshd.server.session.ServerSession.handleMessage(ServerSession.java:151)
>         at org.apache.sshd.common.session.AbstractSession.decode(AbstractSession.java:522)
>         at org.apache.sshd.common.session.AbstractSession.messageReceived(AbstractSession.java:225)
> This (misspelled) function appears to be catching and suppressing the root cause exception
which is a lack of the cipher suites, I get the full set of errors when running trying to
connect to an AMQP broker using SSL. The cause of these errors is that the cipher suites are
not on the classpath. The libraries in question are in JAVA_HOME/jre/ext/lib, which both the
regular ./bin/karaf scripts and the wrapper code appear to be configured to put on the classpath.
However there must be some misconfiguration or expected system variable for the wrapper generation
or script because it doesn't work.
> The simplest reproduction case I can come up with is:
> - download and untar karaf 2.2.2
> - start with ./bin/karaf
>   - features:install wrapper
>   - wrapper:install -s AUTO_START -n Test
>   - logout
> - start with ./bin/start
> - verify we can connect with ./bin/client
> - stop server with ./bin/stop
> - now try using wrapper script (still in same shell with same user): ./bin/Test-service
start
> - try connecting using ./bin/client, should see "error to negotatie errors on both sides"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message