Re: new jclouds/login features

Wed, 11 Feb 2015 05:45:07 -0800 

OK, I've finally characterised this.
My project depends on brooklyn-all-0.7.0-SNAPSHOT-with-dependencies, a shaded jar which contains classes from all its dependencies including the 2 bouncycastle jars. However, as the BC jars are signed, the classes cannot be loaded from the shaded Brooklyn jar. 


I've worked around this by explicitly adding the required BC jars to the 
head of my classpath; it might be worth considering removing the 
all-with-dependencies artifact, or at least advising our users about the 
implications.


A.
--
Alasdair Hodge
Principal Engineer,
Cloudsoft Corporation


On 10/02/2015 18:47, Alex Heneveld wrote:


Hi Alasdair,

Building it up dynamically shouldn't make a difference.  Can you try the
same settings in a brooklyn.properties to confirm?

You might also want to try setting loginUser.privateKeyFile . It's
possible there was a default being used there which must now be
explicitly specified.  (On that subject, is SSH_USER root?  And can you
see in the logs if AWS is giving us credentials for loginUser?)  If not
that then I wonder if the update to bouncycastle crypto routines might
have changed something; you could try reverting just the crypto changes.

Best
Alex


On 10/02/2015 18:33, Alasdair Hodge wrote:

Hey Alex,

I've just discovered that these changes break my (not-too-wacky??) use
case in a customer project.

In my scenario, the top-level application class has a main() method
that gets invoked by a deployment script which *dynamically builds a
Brooklyn named location* via a handful of system properties:


 [snip]

java -cp ${DEFAULT_CLASSPATH}  -Xmx1024m \
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}=jclouds:aws-ec2:${AMAZON_REGION}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.user=${SSH_USER} \
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.privateKeyFile=${SSH_KEY}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.publicKeyFile=${SSH_KEY}.pub
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.imageId=${AMAZON_REGION}/${AMAZON_IMAGE}
\
-Dbrooklyn.location.named.${BROOKLYN_LOCATION_NAME}.hardwareId=${AMAZON_INSTANCE_TYPE}
\
  ${JAVA_MAIN_CLASS} $* named:${BROOKLYN_LOCATION_NAME}


Public and private keys (RSA) are contained within the project itself,
and EC2 credentials are in my regular brooklyn.properties file.

Commit 793c990 (which merged your improvements back to master) fails
for this scenario: the VM is obtained from EC2, but subsequent jclouds
init throws SshException:


1) SshException on node us-west-1/i-2499d9e7:
org.jclouds.ssh.SshException:
  (root:rsa[fingerprint([snip]),sha1([snip])]@54.219.228.35:22)
  (root:rsa[fingerprint([snip]),sha1([snip])]@54.219.228.35:22)
  error acquiring {hostAndPort=54.219.228.35:22, loginUser=root,
ssh=null,
  connectTimeout=60000, sessionTimeout=60000} (out of retries - max 50):
  Unable to reach a settlement: [] and [aes128-ctr, aes192-ctr,
  aes256-ctr, arcfour256, arcfour128, aes128-cbc, 3des-cbc,
blowfish-cbc,
  cast128-cbc, aes192-cbc, aes256-cbc, arcfour,
[email protected]]
    at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:385)
    at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:204)
    at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:224)
    at
org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:72)

    at
org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:121)

    at
org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:49)

    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

    at java.lang.Thread.run(Thread.java:745)
Caused by: net.schmizz.sshj.transport.TransportException: Unable to
  reach a settlement: [] and [aes128-ctr, aes192-ctr, aes256-ctr,
  arcfour256, arcfour128, aes128-cbc, 3des-cbc, blowfish-cbc,
cast128-cbc,
  aes192-cbc, aes256-cbc, arcfour, [email protected]]
    at net.schmizz.sshj.transport.Proposal.firstMatch(Proposal.java:165)
    at net.schmizz.sshj.transport.Proposal.negotiate(Proposal.java:147)
    at
net.schmizz.sshj.transport.KeyExchanger.gotKexInit(KeyExchanger.java:239)

    at
net.schmizz.sshj.transport.KeyExchanger.handle(KeyExchanger.java:364)
    at
net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:477)
    at net.schmizz.sshj.transport.Decoder.decode(Decoder.java:127)
    at net.schmizz.sshj.transport.Decoder.received(Decoder.java:195)
    at net.schmizz.sshj.transport.Reader.run(Reader.java:72)



'loginUser=root' is correct but 'ssh=null' looks potentially
suspicious (although I've no idea what it refers to). I can tell from
previous Brooklyn logging that the imageId and hardwareId flags have
been correctly passed through, but I guess something's gone awry with
the keys. I have a more detailed log but haven't gone through it to
redact sensitive bits; hopefully the above executive summary is helpful.

FYI, the commit immediately prior to this on master (40b4ccd) works fine.

A.


























					Reply via email to