You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Sam Hendley (JIRA)" <ji...@apache.org> on 2011/08/16 16:13:29 UTC

[jira] [Created] (KARAF-816) Wrapper feature doesn't load security libraries

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

        

[jira] [Closed] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Jamie goodyear (Closed) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jamie goodyear closed KARAF-816.
--------------------------------

    
> 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
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 2.2.4, 3.0.0
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[jira] [Commented] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098775#comment-13098775 ] 

Jean-Baptiste Onofré commented on KARAF-816:
--------------------------------------------

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.

> 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
>             Fix For: 2.2.4, 3.0.0
>
>
> 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

       

[jira] [Updated] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré updated KARAF-816:
---------------------------------------

    Fix Version/s: 3.0.0
                   2.2.4

> 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
>             Fix For: 2.2.4, 3.0.0
>
>
> 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

       

[jira] [Commented] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Daniel Evans (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092543#comment-13092543 ] 

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

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

> 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

        

[jira] [Commented] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Daniel Evans (JIRA)" <ji...@apache.org>.
    [ 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

        

[jira] [Resolved] (KARAF-816) Wrapper feature doesn't load security libraries

Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/KARAF-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré resolved KARAF-816.
----------------------------------------

    Resolution: Fixed
      Assignee: Jean-Baptiste Onofré

> 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
>            Assignee: Jean-Baptiste Onofré
>             Fix For: 2.2.4, 3.0.0
>
>
> 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