[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 <LocalTunnel> element and a cvs task
<sshsession host="cvshost.mydomain.com"
keyfile="${ssh.key.file}"
passphrase="${ssh.key.passphrase}"
username="${ssh.username}"
knownhosts="${ssh.knownhosts.file}">
<LocalTunnel lport="2401" rhost="localhost" rport="2401"/>
<cvs command="update ${cvs.parms} ${module}"
cvsRoot="${cvs.root}"
dest="${local.root}"
failonerror="true"/>
</sshsession>
Example2: using localtunnels parameter (comma-delimited list of
colon-delimited lport:rhost:rport triplets)
<sshsession host="cvshost.mydomain.com"
localtunnels="2401:localhost:2401"
keyfile="${ssh.key.file}"
passphrase="${ssh.key.passphrase}"
username="${ssh.username}"
knownhosts="${ssh.knownhosts.file}">
<cvs command="update ${cvs.parms} ${module}"
cvsRoot="${cvs.root}"
dest="${local.root}"
failonerror="true"/>
</sshsession>
this looks very nice indeed.
1. <LocalTunnel> should be lower case only, to be consistent with
everything else
2. I'd put the nested commands into a <sequence>, the way we did in
<macrodef>. This makes it clear it is sequential, and it leaves room to
add new things alongside <localtunnel>.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
