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 20:29:53 GMT
Thanks for the investigation Andrew!

The intention of the agentproxy is just to be able to authenticate
using the SSH agent, to avoid propagating the SSH credentials to the
program running jclouds. If the template options don't have
credentials, or jclouds can't authenticate to a node, it will fallback
to the system and the SSH agent to authenticate, so we can support
*anything* that allows us to talk to the SSH agent.

That said, I don't see option 1 that evil. Given that using the SSH
agent requires "something more" than just a bunch of classes in the
classpath and there might be errors we can't control, I'd say we can
safely catch a general Exception there and return an Absent value.
That will only disable the fallback tot he SSH agent authentication.
The fact that one of the auth mechanisms (the one with less priority)
is not available should not prevent the whole jclouds context to be
initialised, so I'd catch all exceptions there and continue normally.
In the end, the general use case is to provide the credentials (and in
most cases jclouds auto-generates ones via keypairs, etc), so that
shouldn't be a big deal.


HTH!

I.



On 3 April 2015 at 04:54, Andrew Phillips <andrewp@apache.org> wrote:
> Moving this to dev@...
>
> Hi Mike
>
> OK, so after a bit more digging what I've been able to find out so far is
> the following:
>
> 1) In order to *avoid* the NoClassDefFoundError, we'd need to add features
> corresponding to the dependencies jsch-agent-proxy-pageant,
> jsch-agent-proxy-usocket-jna and their transitive deps jna and jna-platform
> to jclouds-karaf. Unfortunately, it seems as though usocket-jna and
> usocket-nc have a "split package" problem: both export and import the same
> packages, and Karaf can't seem to resolve them.
>
> 2) Catching the NCDFE in SshjSshClientModule [1] with:
>
>   try {
>      return Optional.of(ConnectorFactory.getDefault().createConnector());
>   } catch (final AgentProxyException e) {
>      return Optional.absent();
>   } catch (final NoClassDefFoundError e) {
>      // will throw a NoClassDefFoundError if netcat is not available
>      return Optional.absent();
>   }
>
> seems to fix the CLI, but is pretty evil.
>
> In order to figure out to proceed, I think we need to go back and find out
> whether the intention here was to support *only*
> jsch-agent-proxy-usocket-nc, or whether other agentproxy options should also
> be supported if possible.
>
> In the former case, a "less evil" version of 2) seems like the better way;
> in the former case, I fear we'll need some OSGi magic to get all the bundles
> to load.
>
> @nacx: can you shed any light on the intended support for agentproxy?
>
> Regards
>
> ap
>
> PS: @Mike: if you'd like to try to patch the CLI to see if the fix also
> works for you, I can send you a build of jclouds-sshj that has the
> additional catch block. Please ping me if that would be useful.
>
> [1]
> https://github.com/jclouds/jclouds/blob/master/drivers/sshj/src/main/java/org/jclouds/sshj/config/SshjSshClientModule.java#L54-L58
>
>
>
> It seems as though adding additional features for agentproxy-jna
> Moving this tQuoting "Charnoky, Michael" <noky@nextbus.com>:
>
>
>> Well, I was able to update "assembly/pom.xml" to use a local copy
>> jclouds-karaf features.xml file. Indeed, maven downloaded the jar, I can
>> see it in the final packaging now:
>>
>> ./system/com/jcraft/jsch.agentproxy.usocket-jna/0.0.8/jsch.agentproxy.usocket-jna-0.0.8.jar.
>> However, the NoClassDefFoundError is still persisting.
>>
>> A possible clue: I don't see usocket-jna in any of the "bundle.info"
>> files, yet the other com/jcraft/jsch.* modules are in bundle.info files.
>> I'm no maven expert, not sure what all these bundles are for.
>>
>> On 03/30/2015 06:37 PM, Andrew Phillips wrote:
>>>>
>>>> in via the jclouds-karaf dependency. If I modify the feature.xml file
>>>> (that was downloaded during the first time through the build) and then
>>>> rebuild with "mvn package", the file just gets re-downloaded and my
>>>> edits are lost.
>>>
>>>
>>> Ah, yes, of course. Back to the fun land of Maven build hacking ;-)
>>>
>>> The line in question that seems to be pulling in the feature
>>> descriptor is [1]. It looks like we'll need to replace this with the
>>> modified one.
>>>
>>> A quick search (sorry, not a lot of time to test this right now)
>>> doesn't indicate whether it's possible to use e.g. "file:" as an
>>> alternative - otherwise, you should be able to install it in your
>>> local Maven repo using a different version or group ID.
>>>
>>> Thanks for pointing out the branding module - no idea why that's not
>>> working for you, indeed. I wonder if others out there are seeing the
>>> same thing?
>>>
>>> Regards
>>>
>>> ap
>>>
>>> [1]
>>> https://github.com/jclouds/jclouds-cli/blob/master/assembly/pom.xml#L175
>>
>>
>
>
>
> --
> Andrew Phillips
> Apache jclouds

Mime
View raw message