Re: [SUBMIT] sshsession task

[Kevin Jackson]

Hi,

[snip desc]

This sounds very handy, and a real solution to ssh tunneling for ant.

> In the attached tgz of an svn diff, please find SSHSession.java,
> sshsession.html, and mods to defaults.properties and optionaltasklist.html

As you may have already noticed, attachments are stripped form the mailing list.

The recommended way of submitting code is to open an enhancement issue
on bugzilla, and attach your patch/src to that.

I look forward to seeing your code appear on bugzilla as I want to try
this out myself!

Thanks,
Kev

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: First-time contributor - advice needed

[Steve Loughran]

[EMAIL PROTECTED] wrote:

Steve Loughran said:
I have a new task to contribute under optional/ssh, but when I do an 

"ant

-f patch.xml" I get a lot of other files in the patch.tar.gz.  I'm
thinking it should only have my new class source and the patch to
default.properties.  Am I correct, and should I just manually remove 

the

extraneous files, or am I doing this wrong?



this is pretty unusual. I fear your IDE has designed to reorganise 

things.

Hmmm... I used Eclipse 3.1, and just installed the Subclipse plugin to 
check out

the trunk as an Eclipse project.


By way of background, I wrote and built the changes using a source
download, but then installed svn and did a checkout of
http://svn.apache.org/repos/asf/ant/core/trunk, added the new source 

file,

modified the default.properties accordingly, and generated the
patch.tar.gz.  Suggestions?




Best to do a clean checkout of the trunk -which is always up to date-
and add the new source file.


That is what I did, using Eclipse with subclipse.  I'll have to try a 
clean

checkout outside of Eclipse, and see if I have better luck.


If the patch has lots of noise in it, dont include those patches. Tests
are nice though; we've always been a bit lax about testing SSH stuff
because its a functional test that needs servers and permissions set up
right, but we could improve that perhaps.


Because I've utilized the existing authentication and connection logic 
from
SSHExec and SSHBase, the new task is as reliable in that regard as 
SSHExec.
I've personally tested only the keypair with passphrase method of 
authentication,

along with local port forwarding.  As you say, I have no server setup to
accomodate testing the other authentication options or the remote port 
forwarding.



What is your new task trying to do?


It is sshsession, a container task which establishes an SSH connection,
and optionally any number of local or remote tunnels over that connection,
then executes any nested tasks before taking down the connection.

My purpose in writing it is that we use cvs, and secure all access by only
allowing cvs connections from localhost, which are tunneled over SSH 
connections.
Establishing those connections is the only manual step in an otherwise 
automated
build process.  While I could use exec to issue the putty command (this is 
done
on windoze) conditionally if a server is not already accessible at 
localhost
port 2401, it gets more complicated with a passphrase on the keypair being 
used.

Furthermore, there was no way to ensure that an existing connection is the
connection we should be using, and no way to bring the connection down 
once we

are done with it.

So I wrote SSHSession, extending SSHBase, and implementing TaskContainer.
The TaskContainer implementation is lifted directly from Sequential, and 
the
remainder is adapted from SSHCommand, though all the command execution 
related
properties and logic were removed.  I added support for defining the 
tunnels via
properties and/or nested elements.  I only needed local port forwarding, 
but added
remote port forwarding for completeness.  Using SSHSession with a local 
tunnel

(2401:localhost:2401) and nested CVS commands does exactly what we need.

Example1:  using nested  element and a cvs task

  
  


Example2: using localtunnels parameter (comma-delimited list of 
colon-delimited lport:rhost:rport triplets)


  





this looks very nice indeed.

1.  should be lower case only, to be consistent with 
everything else
2. I'd put the nested commands into a , the way we did in 
. This makes it clear it is sequential, and it leaves room to 
add new things alongside .


-steve

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: componentdef

[Peter Reilly]

On 8/9/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > Hi,
> > I am ready to commit the componentdef patch
> > see:
> > http://marc.info/?t=11581423414&r=1&w=2
> > and
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=40511
>
> +1
>
> > This will allow removal of the ConditionBase#createDynamicElement
> > hack ;-)
>
> If it hadn't been in a release already, true.

I think that we can safely remove this hideous hack.
I very much doubt that any third-party code casts the ConditonBase
to a DynamicElement or calls createDynamicElement directly.

Peter

>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: componentdef

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> On 8/9/07, Stefan Bodewig <[EMAIL PROTECTED]>
> wrote:
> > On Wed, 8 Aug 2007, Peter Reilly
> <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > > I am ready to commit the componentdef patch
> > > see:
> > > http://marc.info/?t=11581423414&r=1&w=2
> > > and
> > >
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=40511
> >
> > +1
> >
> > > This will allow removal of the
> ConditionBase#createDynamicElement
> > > hack ;-)
> >
> > If it hadn't been in a release already, true.
> 
> I think that we can safely remove this hideous hack.
> I very much doubt that any third-party code casts
> the ConditonBase
> to a DynamicElement or calls createDynamicElement
> directly.
> 

Assuming nobody vetoes the PropertyHelper stuff, we
know we've got a minor version increment on the way;
we could do it then with a clear conscience, no?

-Matt

> Peter
> 
> >
> > Stefan
> >
> >
>
-
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: componentdef

[Steve Loughran]

Peter Reilly wrote:

On 8/9/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

On Wed, 8 Aug 2007, Peter Reilly <[EMAIL PROTECTED]> wrote:

Hi,
I am ready to commit the componentdef patch
see:
http://marc.info/?t=11581423414&r=1&w=2
and
http://issues.apache.org/bugzilla/show_bug.cgi?id=40511

+1


This will allow removal of the ConditionBase#createDynamicElement
hack ;-)

If it hadn't been in a release already, true.


I think that we can safely remove this hideous hack.
I very much doubt that any third-party code casts the ConditonBase
to a DynamicElement or calls createDynamicElement directly.


well, take it from gump and we find out.

I know I have had to do some ugly things to extend waitfor, but they 
should be OK, and I will check before ant ships


--
Steve Loughran  http://www.1060.org/blogxter/publish/5
Author: Ant in Action   http://antbook.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

SSHSession design (was: Re: First-time contributor - advice needed)

[DJohnson]

Steve Loughran said:
>>> What is your new task trying to do?
>>
>> It is sshsession, a container task which establishes an SSH connection,
>> and optionally any number of local or remote tunnels over that 
connection,
>> then executes any nested tasks before taking down the connection.
>>
>> My purpose in writing it is that we use cvs, and secure all access by 
only
>> allowing cvs connections from localhost, which are tunneled over SSH
>> connections.
>> Establishing those connections is the only manual step in an otherwise
>> automated
>> build process.  While I could use exec to issue the putty command (this 
is
>> done
>> on windoze) conditionally if a server is not already accessible at
>> localhost
>> port 2401, it gets more complicated with a passphrase on the keypair 
being
>> used.
>> Furthermore, there was no way to ensure that an existing connection is 
the
>> connection we should be using, and no way to bring the connection down
>> once we
>> are done with it.
>>
>> So I wrote SSHSession, extending SSHBase, and implementing 
TaskContainer.
>> The TaskContainer implementation is lifted directly from Sequential, 
and
>> the
>> remainder is adapted from SSHCommand, though all the command execution
>> related
>> properties and logic were removed.  I added support for defining the
>> tunnels via
>> properties and/or nested elements.  I only needed local port 
forwarding,
>> but added
>> remote port forwarding for completeness.  Using SSHSession with a local
>> tunnel
>> (2401:localhost:2401) and nested CVS commands does exactly what we 
need.
>>
>> Example1:  using nested  element and a cvs task
>> > keyfile="${ssh.key.file}"
>> passphrase="${ssh.key.passphrase}"
>> username="${ssh.username}"
>> knownhosts="${ssh.knownhosts.file}">
>>   
>>   > cvsRoot="${cvs.root}"
>> dest="${local.root}"
>> failonerror="true"/>
>> 
>>
>> Example2: using localtunnels parameter (comma-delimited list of
>> colon-delimited lport:rhost:rport triplets)
>> > localtunnels="2401:localhost:2401"
>> keyfile="${ssh.key.file}"
>> passphrase="${ssh.key.passphrase}"
>> username="${ssh.username}"
>> knownhosts="${ssh.knownhosts.file}">
>>   > cvsRoot="${cvs.root}"
>> dest="${local.root}"
>> failonerror="true"/>
>> 
>>
>>
>
>this looks very nice indeed.
>
>1.  should be lower case only, to be consistent with
>everything else
>2. I'd put the nested commands into a , the way we did in
>. This makes it clear it is sequential, and it leaves room to
>add new things alongside .
>

Thanks!  I did resolve my issues with pulling together a patch, and 
submitted it before you offered these latest suggestions.  I'll revise the 

doc to use lower case. 
I'd like to discuss further your suggestion of incorporating  
(, according to 1.7.0 doc??) into sshsession to hold the 
nested tasks.  Please explain further why this is prefereable.  Multiple
tasks are supported now, and while by default, they execute in order,
someone could use a   task to get another behavior, if they
wish.  Since the expected behavior of ant is to process tasks 
sequentially unless a  task is used, why is sequential 
processing within  unclear?  Also, I don't understand 
how introduction of  makes it any easier to add other 
things alongside  and ?

The one thing I can see which might be confusing is that localtunnel
and remotetunnel can be interspersed with tasks, e.g.









In this example, two local tunnels and one remote tunnel would be
established before any tasks are run, and then the three tasks would
be run in sequential order. 

A possible enhancement, however, would be to add support for a
nested  element within sshsession, providing a command
(and associated timeout and output parameters) to be executed on 
the remote server using the established SSH session.  In this 
scenario, it could make sense that the order of the  
elements relative to nested tasks is preserved.  In that case, an 
internal Command class would be added, but the createCommand 
method would add each instance to the same Vector which is storing
Tasks (via addTask). In SSHSession's execute method, I would have
to use "instanceof Command" when iterating over the Vector, and
use the logic from SSHExec to run Commands remotely, interspersed
with local Tasks, and executed in the order presented by the Vector.


It might make sense to have Command extend Task (are there issues 
with that if it isn't a Task Ant knows about?),  even though it is 
constructed via SSHSession, so that I don't have to treat any Vector
items differently, but the execute method of Command would need to
use the com.jcraft.jsch.Session created on the stack by SSHSession
execute method.  That would require saving the Session as a member
variable of the SSHSession intance, instead of on the stack, thereby 
maki

Re: SSHSession design (was: Re: First-time contributor - advice needed)

[Dominique Devienne]

On 8/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Steve Loughran said:
> >2. I'd put the nested commands into a , the way we did in
> >. This makes it clear it is sequential, and it leaves room to
> >add new things alongside .

> I'd like to discuss further your suggestion of incorporating 
> (, according to 1.7.0 doc??) into sshsession to hold the
> nested tasks.  Please explain further why this is prefereable.

Forward compatibility. Right now you allow:


  
  any tasks...


So someone somewhere use  in "any tasks...", and later on you
want to enhance  with a new  element. That someone's
build would now break with your new enhanced version.

Contrast this with this model:


  
  
any tasks...
  


Now you are free to add new elements directly under 
without potentially breaking any builds.

Code-wise, composing a Sequential instance is better/simpler IMHO than
inheriting TaskContainer (or Sequential).

An alternative in line with your proposed extension is to move the
inheritance away from  and into  and
, to allow:


  
any tasks...
  
  
any tasks...
  


Here as well, there's no possible conflict with a user script using an
element name you'd want to add to  itself.

I hope this helps. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38199] - symlink fails on second call

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38199





--- Additional Comments From [EMAIL PROTECTED]  2007-08-09 12:55 ---
Created an attachment (id=20626)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20626&action=view)
another build.xml illustrating problem!

Here are the results of this build.xml file =>
test1:
  [symlink] ln -s bar foo

test2:
  [symlink] ln -s bar foo
  [symlink] /bin/ln: `foo': File exists

BUILD FAILED
build.xml:6: ln failed with return code 1

--
It seems that neither "overwrite" and "failonerror" is working as expected. (I
would expect "overwrite=true" to prevent this problem, and "failonerror=false"
to stop the build from failing when the problem does occur.)

When I do "ln -s -f bar foo" from the command line, it works fine.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Proposed IsolateFailure task - feedback requested

[DJohnson]

I am using ant to combine multiple independant build processes under one 
umbrella.  Once I get beyond some initialization which applies to the 
whole process, I'd like to make the umbrella build tolerant of failures 
within the previously independant builds.  Furthermore, in the event of a 
failure in one of the builds, I'd like to e-mail notification of the 
failure, along with an attached log of the build. 
I am not aware of a way to do this with the existing Ant functionality. If 
I am wrong in this, please enlighten me.
What I propose to accomodate this is an  task.  It would 
contain a  element, implemented by a private NestedSequential 
class which implements TaskContainer, ala MacroDef.  However, the 
IsolateFailure class' execute method would catch any BuildException, and 
not rethrow it.  This would isolate tasks following the  
task from the failure, and allow them to continue executing. 
 would also accept an optional  element 
which, like , holds nested tasks, but these would only be 
executed if a BuildException was caught.  This would accomodate the 
requirement for special processing in the event of a failure. 
 would take an optional errorproperty="propertname" 
parameter, which would identify the name of a property which should be set 
with the message from the BuildException before executing the tasks nested 
within the .
I'm looking for feedback on this idea before I start work on it...


David S. Johnson

"Oh scholar, if your scholarship benefits not Mankind,
you deserve not admiration but contempt." -- Kahlil Gibran

Re: SSHSession design (was: Re: First-time contributor - advice needed)

[DJohnson]

Dominique Devienne wrote:
>On 8/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Steve Loughran said:
>> >2. I'd put the nested commands into a , the way we did in
>> >. This makes it clear it is sequential, and it leaves room 
to
>> >add new things alongside .
>
>> I'd like to discuss further your suggestion of incorporating 
>> (, according to 1.7.0 doc??) into sshsession to hold the
>> nested tasks.  Please explain further why this is prefereable.
>
>Forward compatibility. Right now you allow:
>
>
>
>any tasks...
>
>
>So someone somewhere use  in "any tasks...", and later on you
>want to enhance  with a new  element. That someone's
>build would now break with your new enhanced version.
>
>Contrast this with this model:
>
>
>
>
>any tasks...
>
>
>
>Now you are free to add new elements directly under 
>without potentially breaking any builds.
>
>Code-wise, composing a Sequential instance is better/simpler IMHO than
>inheriting TaskContainer (or Sequential).

I don't know about simpler code, but certainly not much harder, and 
probably better, for the reason you cite.  I see your argument for 
avoiding conflicting/ambiguous  elements, and after looking over 
MacroDef, I see that the  there is built by MacroDef, not 
the same as the  Task, so it is still free to process some 
future  (renamed from my earlier  suggestion, 

to eliminate the future conflict issue you raise) nested along with 
other tasks *within* .

>
>An alternative in line with your proposed extension is to move the
>inheritance away from  and into  and
>, to allow:
>
>
>
>any tasks...
>
>
>any tasks...
>
>
>
>Here as well, there's no possible conflict with a user script using an
>element name you'd want to add to  itself.

I'm not keen on this.  It restricts you to having only one tunnel at a 
time.  I think I'd like to establish all tunnels up front, then any of
the nested tasks can use any of the tunnels, in any order.  There is
already logic checking that you aren't defining conflicting tunnels
(unique lport on localtunnel and unique rport on remotetunnel) with 
the expectation that you may have multiple  and/or 
 elements for a single .

>
>I hope this helps. --DD
>

Yes, thanks.

Re: SSHSession design (was: Re: First-time contributor - advice needed)

[Dominique Devienne]

> >An alternative in line with your proposed extension is to move the
> >inheritance away from  and into  and
> >
>
> I'm not keen on this.  It restricts you to having only one tunnel at a
> time.  I think I'd like to establish all tunnels up front, then any of
> the nested tasks can use any of the tunnels, in any order.

Being ignorant about SSH tunneling, I simply assumed each tunnel
overwrote the previous one. Since that's not the case, this latter
option doesn't make much sense indeed. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed IsolateFailure task - feedback requested

[Dominique Devienne]

On 8/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> What I propose to accomodate this is an  task.

See also Ant-Contrib's  task. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Proposed IsolateFailure task - feedback requested

[Dominique Devienne]

On 8/9/07, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 8/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > What I propose to accomodate this is an  task.
>
> See also Ant-Contrib's  task. --DD

It's also possible that AntUnit, a mini Unit testing framework based
on Ant, could be (ab?)used to achieve similar results.

There's also a BuildListener that sends mail on failures, but that
applies to the whole build, and must be passed on Ant's command line.

There's also the -keep-going switch to Ant that overrides the default
behavior of failing the whole build on errors. Don't know much about
this one, but I vaguely remember one can maybe plug one's own policy
class to deal with errors.

All avenues to explore ;-) --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[SUBMIT] sshsession task, revised

[DJohnson]

This is a resubmission, incorporating suggestions to move the nested
tasks into a nested  element, and to lower-case any 
documentation references to nested elements  and 
.  The original task description follows:

Sshsession is a container task which establishes an SSH connection,
and optionally any number of local or remote tunnels over that connection,
then executes any nested tasks before taking down the connection.

My purpose in writing it is that we use cvs, and secure all access by only
allowing cvs connections from localhost, which are tunneled over SSH
connections.  Establishing those connections is the only manual step in an 

otherwise automated build process.   

While I could use exec to issue the putty command (this is done on  
windoze) conditionally if a server is not already accessible at localhost 
port 2401, it gets more complicated with a passphrase on the keypair being 

used.
 
Furthermore, there was no way to ensure that an existing connection is the
connection we should be using, and no way to bring the connection down
once we are done with it.
 
So I wrote SSHSession, extending SSHBase, and implementing TaskContainer.
The TaskContainer implementation is lifted directly from Sequential, and
the remainder is adapted from SSHExec, though all the command execution
related properties and logic were removed.  I added support for defining 
the tunnels via properties and/or nested elements.  I only needed local 
port forwarding, but added remote port forwarding for completeness.   

Using SSHSession with a local tunnel (2401:localhost:2401) and nested CVS 
commands does exactly what we need.  Other uses could involve anything 
needing to make a TCP connection to a server not otherwise accessible 
through a firewall, e.g. HTTP , SMTP , JDBC ... 

Because I've utilized the existing authentication and connection logic
from SSHExec and SSHBase, the new task is as reliable in that regard as
SSHExec. I've personally tested only the keypair with passphrase method of
authentication, but I tested both local and remote port forwarding.
I have no server setup to accomodate testing the other authentication 
options.

In the attached tgz of an svn diff, please find SSHSession.java,  
sshsession.html, and mods to defaults.properties and optionaltasklist.html 



David S. Johnson
 
"Oh scholar, if your scholarship benefits not Mankind,
you deserve not admiration but contempt." -- Kahlil Gibran-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [SUBMIT] sshsession task, revised

[Dominique Devienne]

On 8/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> In the attached tgz of an svn diff, please find SSHSession.java,
> sshsession.html, and mods to defaults.properties and optionaltasklist.html

Attachments are stripped. Please open an BugZilla Enhancement and
attach your code there. Discussions and sub-sequent code changes (if
any) then all happen in the bug itself.

Thanks, --DD

http://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant
You'll need a login.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: componentdef

[Stefan Bodewig]

On Thu, 9 Aug 2007, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Peter Reilly <[EMAIL PROTECTED]> wrote:
> 
>> On 8/9/07, Stefan Bodewig <[EMAIL PROTECTED]>
>> wrote:
>> > On Wed, 8 Aug 2007, Peter Reilly
>> <[EMAIL PROTECTED]> wrote:

>> > > This will allow removal of the ConditionBase#createDynamicElement
>> > > hack ;-)
>> >
>> > If it hadn't been in a release already, true.
>> 
>> I think that we can safely remove this hideous hack.  I very much
>> doubt that any third-party code casts the ConditonBase to a
>> DynamicElement or calls createDynamicElement directly.
> 
> Assuming nobody vetoes the PropertyHelper stuff, we
> know we've got a minor version increment on the way;
> we could do it then with a clear conscience, no?

Then we should deprecate it in the 1.7.x branch to give people an
early notice.  The problem is that the 1.7.x wouldn't provide a
non-deprecated alternative.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43083] New: - [SUBMIT] sshsession task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43083

   Summary: [SUBMIT] sshsession task
   Product: Ant
   Version: 1.7Alpha (nightly)
  Platform: All
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Optional Tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Sshsession is a container task which establishes an SSH connection,
and optionally any number of local or remote tunnels over that connection, 
then executes any nested tasks before taking down the connection. 

My purpose in writing it is that we use cvs, and secure all access by only 
allowing cvs connections from localhost, which are tunneled over SSH
connections.  Establishing those connections is the only manual step in an  
otherwise automated build process.

While I could use exec to issue the putty command (this is done on  
windoze) conditionally if a server is not already accessible at localhost  
port 2401, it gets more complicated with a passphrase on the keypair being  
used. 
  
Furthermore, there was no way to ensure that an existing connection is the 
connection we should be using, and no way to bring the connection down 
once we are done with it. 
 
So I wrote SSHSession, extending SSHBase.  The sshsession task establishes an
SSH connection with a remote machine running SSH daemon, optionally establishes
any number of local or remote tunnels over that connection, then executes any
nested tasks before taking down the connection.

SSHSession is adapted from SSHExec, though all the command execution 
related properties and logic were removed.  I added support for defining  
the tunnels via properties and/or nested elements.  I only needed local  
port forwarding, but added remote port forwarding for completeness.

Using SSHSession with a local tunnel (2401:localhost:2401) and nested CVS  
commands does exactly what we need.  Other uses could involve anything  
needing to make a TCP connection to a server not otherwise accessible  
through a firewall, e.g. HTTP , SMTP , JDBC ...  

Because I've utilized the existing authentication and connection logic 
from SSHExec and SSHBase, the new task is as reliable in that regard as 
SSHExec. I've personally tested only the keypair with passphrase method of 
authentication, but I tested both local and remote port forwarding. 
I have no server setup to accomodate testing the other authentication  
options.

In the attached svn diff, please find SSHSession.java,   
sshsession.html, and mods to defaults.properties and optionaltasklist.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43083] - [SUBMIT] sshsession task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43083





--- Additional Comments From [EMAIL PROTECTED]  2007-08-09 22:55 ---
Created an attachment (id=20634)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20634&action=view)
SVN Diff providing sshsession task implementation and documentation


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]