jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: jclouds-cli problems
Date Mon, 06 Apr 2015 22:06:28 GMT
Yes, that's what I mean. Invoke the factory there, only if there's a
need to connect to the SSH agent. This does not fix the issue, but it
is a reasonable improvement to have.

If you provide a patch I'll be happy to test it and give feedback! :)

On 6 April 2015 at 23:49, Andrew Phillips <aphillips@qrmedia.com> wrote:
>> That should minimize the impact of the issue, and allow normal
>> operation when jclouds knows how to conenct to the node.
>> WDYT?
> If I understand your proposal correctly, you mean essentially moving the
> first attempt to find a connector to here:
> https://github.com/jclouds/jclouds/blob/master/drivers/sshj/src/main/java/org/jclouds/sshj/SSHClientConnection.java#L166
> ? That would certainly help in the sense that, if you're providing any one
> of the other connection methods, you would not see this problem.
> I'm not sure what would happen in case you *do* want to use an agentproxy,
> though. I guess what we want to ensure is that, if usocket-nc works on your
> system, you do *not* get an error when using jclouds-cli.
> I think we would need to verify this...and then we should probably also
> document (if not already done) that agent proxying is *only* supported using
> netcat, i.e. not on Windows or using JNA.
> If I put together a quick PR that moves the first call to JSch's
> ConnectorFactory as you describe, would you be able to test whether a CLI
> built using that patch works with netcat available?
> Regards
> ap

View raw message