Hi all,
I've been tracking down a strange bug for most of this morning.
Here's my build.xml (snippets)
macro to make ssh/scp easier:
<target name="config-ssh-macro-with-password" unless="keyfile.present">
<echo message="Keyfile not found, falling back to password-based
authentication"/>
<macrodef name="ssh-cmd">
<attribute name="command"/>
<attribute name="fail" default="true"/>
<sequential>
<sshexec host="${deploy.machine.address}"
port="${deploy.machine.ssh.port}"
username="root"
password="${deploy.machine.root.user.password}"
command="@{command}"
failonerror="@{fail}"
trust="true"/>
</sequential>
</macrodef>
<macrodef name="scp-cmd">
<attribute name="to-dir"/>
<element name="scp-filesets"/>
<sequential>
<scp todir="@{to-dir}"
port="${deploy.machine.ssh.port}"
password="${deploy.machine.root.user.password}"
trust="true">
<scp-filesets/>
</scp>
</sequential>
</macrodef>
</target>
macro in use (where it fails...)
<target name="install-crypto">
<scp-cmd to-dir="[EMAIL PROTECTED]:/">
<scp-filesets>
<fileset
dir="${src.tools.build.dir}/james/crypto">
<include name="**"/>
</fileset>
</scp-filesets>
</scp-cmd>
</target>
macro in use (works correctly...)
<scp-cmd to-dir="[EMAIL PROTECTED]:/etc/init.d">
<scp-filesets>
<fileset
dir="${src.tools.build.dir}/james/config/etc/init.d">
<include name="**" />
<exclude name="**/*.exclude"/>
</fileset>
</scp-filesets>
</scp-cmd>
Ok. So this morning I updated from a rather ancient jsch-0.1.24.jar
to the latest version, 0.1.33.
In the build I scp over an entire (custom) james distribution, then I
run some commands, and finally copy over config files etc. All with
ant (svn trunk) and jsch.
Prior to the update when I was using 0.1.24, everything worked well.
After the update, it looked like everything was working well until the
3rd time in the script that my <scp-cmd> macro was called, the files
were copied over (cryptography jars/config), but then the build hung.
So I checked the changelog and couldn't see anything that would cause
this. I went back through various versions of jsch.
0.1.32 (hangs)
0.1.31 (hangs)
0.1.30 (hangs)
0.1.29 (works)
So I think that something that was changed between 0.1.30 & 0.1.29 [1]
has caused a problem with the ant scp task (in some way).
Has anyone come across something similar? At first I thought sshd on
the server had been updated, but as the same build works fine with
older versions of the jsch library...
If this is something that needs to be updated in the ant scp/ssh
tasks, we need to get it done before shipping 1.7.1
Thanks,
Kev
[1] Jsch changelog extract
Changes since version 0.1.29:
- bugfix: ChannelSftp#cd() will not throw an exception even if
a file is given. FIXED.
- bugfix: ChannelSftp#put() has a bug which will appear in using
on the slow network. FIXED.
- bugfix: ChannelSftp#ls() has a bug which will appear in using
on the slow network. FIXED.
- bugfix: a bug had sneaked in the remote port forwarding. FIXED.
- bugfix: some APIs from JCE have the memory leak on Mac OS X,
so we have re-written the code(com.jcraft.jsch.jcraft.HMAC*
classes) without them. On Mac OS X, such new classes will
be used automatically. FIXED.
- bugfix: the session will be crashed by the long banner message. FIXED.
- change: '/dev/random' will not be referred on Gnu/Linux.
- change: if non-standard TCP port number is used, that number will
be saved in known_hosts file as recent OpenSSH's ssh client does.
- change: Channel#getOutputStream will not use Piped{Output,Input}Stream.
- change: com.jcraft.jsch.HostKeyRepository interface has been
slightly modified.
- feature: Session#setPortForwardingR(String bind_address, ...) has been added.
- feature: the packet compression method '[EMAIL PROTECTED]' has been supported.
- feature: the hashed known_hosts file has been supported.
Refer to 'examples/KnownHosts.java'.
- feature: the authentication method 'gssapi-with-mic' has been
experimentally supported.
- feature: com.jcraft.jsch.Logger interface and
JSch#setLogger(Logger logger) have been added.
Refer to 'examples/Logger.java' for the usage.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
