Karaf
  1. Karaf
  2. KARAF-816

Wrapper feature doesn't load security libraries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.2
    • Fix Version/s: 2.2.4, 3.0.0
    • Component/s: karaf-os-integration
    • Labels:
      None
    • Environment:

      Ubunutu 10.04 LTS
      OpenJDK, HotSpot

      Description

      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"

        Issue Links

          Activity

          Hide
          Daniel Evans added a comment -

          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.

          Show
          Daniel Evans added a comment - 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.
          Hide
          Daniel Evans added a comment -

          Just in case anyone does a quick google, putting it in /etc/profile didn't seem to work.

          Show
          Daniel Evans added a comment - Just in case anyone does a quick google, putting it in /etc/profile didn't seem to work.
          Hide
          Jean-Baptiste Onofré added a comment -

          The quote in the wrapper conf file could source of the problem.

          Fixed on trunk: revision 1166057.
          Fixed on karaf-2.2.x: revision 1166058.

          Show
          Jean-Baptiste Onofré added a comment - The quote in the wrapper conf file could source of the problem. Fixed on trunk: revision 1166057. Fixed on karaf-2.2.x: revision 1166058.

            People

            • Assignee:
              Jean-Baptiste Onofré
              Reporter:
              Sam Hendley
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development