You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Phillips <an...@apache.org> on 2015/04/03 04:54:28 UTC
Re: jclouds-cli problems
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" <no...@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
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
Quoting Ignasi Barrera <na...@apache.org>:
> Hmmm if this is failing now in 1.9, it should be also failing in 1.8,
Just tried to verify this in 1.8.0 and 1.8.1, but can't get those CLIs
working :-(
java.lang.Exception: Could not start bundle
mvn:org.apache.jclouds.karaf/core/1.8.1 in feature(s)
jclouds-services-1.8.1, jclouds-commands-1.8.1: Unresolved constraint
in bundle org.apache.jclouds.karaf.core [51]: Unable to resolve 51.0:
missing requirement [51.0] package;
(&(package=org.osgi.framework)(version>=1.6.0))
java.lang.Exception: Could not start bundle
mvn:org.apache.jclouds.karaf/core/1.8.0 in feature(s)
jclouds-services-1.8.0, jclouds-commands-1.8.0: Unresolved constraint
in bundle org.apache.jclouds.karaf.core [51]: Unable to resolve 51.0:
missing requirement [51.0] package;
(&(package=org.osgi.framework)(version>=1.6.0))
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
Hmmm if this is failing now in 1.9, it should be also failing in 1.8,
as there haven't been changes to this stuff IIRC. We can assume then
that there are no such scenarios "in use", so I'd say this discussion
is enough to go ahead.
Given that this hasn't been a reported issue till now, I'd agree to
merge the fix that forces the use of netcat. In the end, if the other
possible connectors are not tested, we shouldn't officially support
them, and if at some point we have to, we should make sure it works as
expected everywhere, including the CLI.
So I'd say, go ahead and merge the PR :)
On 8 April 2015 at 00:00, Andrew Phillips <ap...@qrmedia.com> wrote:
>> If we merge this pull request we might be *removing* working stuff.
>
>
> That is true, but the question here is whether that stuff was ever
> *intended* to work. It's certainly not been tested, from what I recall - the
> reason we originally didn't try to figure out how to get all the bundles
> loaded in Karaf because we decided that we only wanted/needed to support
> ssh-agent over netcat.
>
> How about sending an email to user@ to see if any other agentproxy scenarios
> are in use? If so, then we can indeed consider the custom ConnectorFactory
> approach involving classloading that you described.
>
> Regards
>
> ap
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
> If we merge this pull request we might be *removing* working stuff.
That is true, but the question here is whether that stuff was ever
*intended* to work. It's certainly not been tested, from what I recall
- the reason we originally didn't try to figure out how to get all the
bundles loaded in Karaf because we decided that we only wanted/needed
to support ssh-agent over netcat.
How about sending an email to user@ to see if any other agentproxy
scenarios are in use? If so, then we can indeed consider the custom
ConnectorFactory approach involving classloading that you described.
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
Thinking a bit more about this, the issue only affects OSGi users. I
mean, the current code should work fine on Unix and Windows systems
that use Pageant, as there should not be dependency issues. The only
issue is about how the agentproxy dependency exports its packages.
If we merge this pull request we might be *removing* working stuff. We
won't support the SSH agent in Windows anymore, so if possible, I'd
try to think about a different approach to make OSGi happy:
* One option is to catch the NCDFE as said before.
* Another approach could be to manually ask the classloader to load
the agentproxy classes. That throws a ClassNotFoundException, which is
a checked exception that can be cached. The ugly thing here is that we
should know which class to load depending on the platform. In
practice, we would be performing the agent proxy implementation lookup
and we would be hardcoding class names and packages that might change
in future versions of the agentproxy dependency, so this seems to be
even more evil.
At this point, I'm not sure which could be the better option to
workaround the exports issue: catching the NCDFE does not seem that
evil to me now. The current PR is cleaner, though, but we might be
dropping support for the SSH agent in some non OSGi environments.
Thoughts?
On 7 April 2015 at 15:12, Andrew Phillips <ap...@qrmedia.com> wrote:
> TL;DR: if we want to stick with the current functionality set, I think the
> PR against the sshj driver seems like "the right one."
>
>> Just to confirm, this is a temporal fix until your PR to fix the
>> agentproxy
>> bundle is in and released, right? Hopefully a fix for an eventual 1.9.1
>> and
>> to be reverted in 2.0.0?
>
>
> Well, it depends. The current approach is The Right Way, I think, to set up
> agentproxy if we only want to support ssh-agent via netcat. From what I
> recall, that was essentially the idea when this was added?
>
> *If* we decide that we want to support *all* the agentproxy options -
> netcat, JNA, pageant on Windows - *then* we should revert the current PR and
> modify the deps for both the sshj driver and karaf appropriately.
>
> Testing that this latter scenario works will not be all that easy, though, I
> suspect.
>
> Regards
>
> ap
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
TL;DR: if we want to stick with the current functionality set, I think
the PR against the sshj driver seems like "the right one."
> Just to confirm, this is a temporal fix until your PR to fix the agentproxy
> bundle is in and released, right? Hopefully a fix for an eventual 1.9.1 and
> to be reverted in 2.0.0?
Well, it depends. The current approach is The Right Way, I think, to
set up agentproxy if we only want to support ssh-agent via netcat.
From what I recall, that was essentially the idea when this was added?
*If* we decide that we want to support *all* the agentproxy options -
netcat, JNA, pageant on Windows - *then* we should revert the current
PR and modify the deps for both the sshj driver and karaf appropriately.
Testing that this latter scenario works will not be all that easy,
though, I suspect.
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
I've built your branch and I've been able to list nodes without issues (in OSX).
On 7 April 2015 at 08:29, Ignasi Barrera <na...@apache.org> wrote:
> Nice! I'll give it a try.
>
> Just to confirm, this is a temporal fix until your PR to fix the agentproxy
> bundle is in and released, right? Hopefully a fix for an eventual 1.9.1 and
> to be reverted in 2.0.0?
>
> Mind opening a jira linking to all these places to properly track this?
>
> Thanks!!
>
> I.
>
> El 07/04/2015 05:24, "Andrew Phillips" <ap...@qrmedia.com> escribió:
>>
>> Just FYI: https://github.com/ymnk/jsch-agent-proxy/pull/23
>>
>> Regards
>>
>> ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
Nice! I'll give it a try.
Just to confirm, this is a temporal fix until your PR to fix the agentproxy
bundle is in and released, right? Hopefully a fix for an eventual 1.9.1 and
to be reverted in 2.0.0?
Mind opening a jira linking to all these places to properly track this?
Thanks!!
I.
El 07/04/2015 05:24, "Andrew Phillips" <ap...@qrmedia.com> escribió:
> Just FYI: https://github.com/ymnk/jsch-agent-proxy/pull/23
>
> Regards
>
> ap
>
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
Just FYI: https://github.com/ymnk/jsch-agent-proxy/pull/23
Regards
ap
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
> If you provide a patch I'll be happy to test it and give feedback! :)
Here you go ;-) The "solution" (assuming it works, of course ;-))
turns out to be pretty nice, actually.
https://github.com/jclouds/jclouds/pull/721
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <ig...@gmail.com>.
:( In that case, right now, I can't think of a better solution than
catching that one in the factory method. But I'm not an OSGi expert.
Perhaps Chris Custine could give some light? Perhaps there is
something we can tweak on the karaf side to make this work
On 7 April 2015 at 00:23, Andrew Phillips <ap...@qrmedia.com> wrote:
>> Yes, that's what I mean. Invoke the factory there, only if there's a
>> need to connect to the SSH agent.
>
>
> Hrm...unfortunately it seems it's not quite so simple :-( This test is also
> used to verify whether an agent is even available, here:
>
> https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/functions/CreateSshClientOncePortIsListeningOnNode.java#L64
>
> Having that blow up with a NCDFError rather than a sane
> IllegalArgumentException seems pretty nasty. And I don't immediately see a
> way to figure out whether an agent is, in fact, available, other than asking
> the ConnectorFactory to try to create one.
>
> Which gets us back to the discussion of catching the NCDFE again :-(
>
> Any thoughts?
>
> Regards
>
> ap
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Yes, that's what I mean. Invoke the factory there, only if there's a
> need to connect to the SSH agent.
Hrm...unfortunately it seems it's not quite so simple :-( This test is
also used to verify whether an agent is even available, here:
https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/functions/CreateSshClientOncePortIsListeningOnNode.java#L64
Having that blow up with a NCDFError rather than a sane
IllegalArgumentException seems pretty nasty. And I don't immediately
see a way to figure out whether an agent is, in fact, available, other
than asking the ConnectorFactory to try to create one.
Which gets us back to the discussion of catching the NCDFE again :-(
Any thoughts?
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
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 <ap...@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
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
> 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
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
Oh, understood.
So, the main issue here is that the cli is failing because the agent
stuff is not there, even if the agent code is not going to be reached
at all.
Instead of changing the catch block then, I'd suggest to pass the
"Agent Factory" to the SshClient constructor, instead of passing the
Optional<Connector> resulting on the factory invocation: Let's feed
the SSH client with the factory that knows how to produce SSH agent
connectors, instead of giving it an optional agent connector. This way
it is completely up to the SSH client to call the factory to get the
SSH agent proxy or not, and it will be only invoked when needed.
That should minimize the impact of the issue, and allow normal
operation when jclouds knows how to conenct to the node.
WDYT?
On 6 April 2015 at 23:05, Andrew Phillips <ap...@qrmedia.com> wrote:
>> 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.
>
>
> I'd agree with that, but the tricky thing here is that what is thrown isn't
> even an Exception, it's an Error. So we'd have to catch all Errors here (or
> just this specific one), which seems nastier.
>
> I've been trying to see what happens if we add the other connector factory
> implementations to the jclouds-services feature in karaf. Unfortunately, it
> looks like that will require a change to jsch-agent-proxy itself, because
> currently it's stuck with a circular OSGi dep.
>
> I'll open a PR to see what happens there.
>
> Regards
>
> ap
Re: jclouds-cli problems
Posted by Andrew Phillips <ap...@qrmedia.com>.
> 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.
I'd agree with that, but the tricky thing here is that what is thrown
isn't even an Exception, it's an Error. So we'd have to catch all
Errors here (or just this specific one), which seems nastier.
I've been trying to see what happens if we add the other connector
factory implementations to the jclouds-services feature in karaf.
Unfortunately, it looks like that will require a change to
jsch-agent-proxy itself, because currently it's stuck with a circular
OSGi dep.
I'll open a PR to see what happens there.
Regards
ap
Re: jclouds-cli problems
Posted by Ignasi Barrera <na...@apache.org>.
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 <an...@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" <no...@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