search

brooklyncentral / brooklyn

This project has moved and is now part of the ASF
https://github.com/apache/incubator-brooklyn
72 stars 27 forks source link

docker location's default password leaks into other location #1449

Open aledsage opened 10 years ago

aledsage commented 10 years ago

With persistence enabled (--persist auto) I restarted brooklyn. There were existing locations for jclouds-docker and jclouds-cloudstack.

I then attempted to deploy an app to a cloudstack 4.3 environment. It failed with the jclouds exception below.

Note this password hash corresponds to "password".

When I ran without --persist auto it worked fine.

This is with docker-1.7.2-ea-brooklyn.5.jar; see https://github.com/andreaturli/jclouds-labs/tree/1.7.2-ea-brooklyn.5

1) AuthorizationException on node 8a45cec6-1638-40d9-a939-33de61d90136: org.jclouds.rest.AuthorizationException: (root:pw[5f4dcc3b5aa765d61d8327deb882cf99]@10.47.2.216:22) (root:pw[5f4dcc3b5aa765d61d8327deb882cf99]@10.47.2.216:22) error acquiring {hostAndPort=10.47.2.216:22, loginUser=root, ssh=null, connectTimeout=60000, sessionTimeout=6 0000} (out of retries - max 50): Exhausted available authentication methods at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:380) at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:201) at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:221) at org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:76) at org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:125) at org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:146) at org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:53) at com.google.common.util.concurrent.Futures$1.apply(Futures.java:711) at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:849) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) at java.lang.Thread.run(Thread.java:804) Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods at net.schmizz.sshj.userauth.UserAuthImpl.authenticate(UserAuthImpl.java:114) at net.schmizz.sshj.SSHClient.auth(SSHClient.java:205) at net.schmizz.sshj.SSHClient.auth(SSHClient.java:190) at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:266) at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:236) at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:220) at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:138) at org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:38) at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:191) ... 10 more Caused by: net.schmizz.sshj.userauth.UserAuthException: keyboard-interactive auth failed at net.schmizz.sshj.userauth.UserAuthImpl.handle(UserAuthImpl.java:157) at net.schmizz.sshj.transport.TransportImpl.handle(TransportImpl.java:474) 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)

aledsage commented 10 years ago

It works when I comment out this line from org.jclouds.docker.DockerApiMetadata.defaultProperties()

`properties.setProperty(ComputeServiceProperties.IMAGE_LOGIN_USER, "root:password");`

This method is called as a result of the persisted locations, because we create a ComputeService for the docker provider when rebinding to the docker location. (When persistence is disabled, this code does not get called).

I have three hypotheses why this could make it fail:

  1. this property set in the docker ComputeService somehow leaks into the cloud stack ComputeService, e.g. through statics or a shared instance injected through juice!? This would be very surprising because jclouds is extremely careful and separation.
  2. within brooklyn, the value is read and ends up in a brooklyn docker location. Some state leaks from this location into our cloud stack location. I've no idea how that would happen though (I ran a test that disabled the sharing of ComputeService in JcloudsUtil.findComputeService() and it still failed).
  3. the ComputeServiceProperties.IMAGE_LOGIN_USER somehow interferes with our JcloudsLocation.LOGIN_USER_PASSWORD

Of these, (1) seems most likely to me currently.

My next step is to rebind to the state, then start a VM in an AWS location (so I can run it outside of the locked-down customer environment), and see if that uses "password". If it does, then I'll breakpoint and see where that is coming from.