Thanks Pat, that makes sense, I'll try it out.
pat marion wrote:
Actually I didn't write the notes at the hpc.mil <http://hpc.mil> link.
Here is something- and maybe this is the problem that Sean refers to-
in some cases, when I have set up a reverse ssh tunnel from login node
to workstation (command executed from workstation) then the forward
does not work when the compute node connects to the login node.
However, if I have the compute node connect to the login node on port
33333, then use portfwd to forward that to localhost:11111, where the
ssh tunnel is listening on port 11111, it works like a charm. The
portfwd tricks it into thinking the connection is coming from
localhost and allow the ssh tunnel to work. Hope that made a little
sense...
Pat
On Mon, Feb 8, 2010 at 6:29 PM, burlen <[email protected]
<mailto:[email protected]>> wrote:
Nice, thanks for the clarification. I am guessing that your
example should probably be the recommended approach rather than
the portfwd method suggested on the PV wiki. :) I took the
initiative to add it to the Wiki. KW let me know if this is not
the case!
http://paraview.org/Wiki/Reverse_connection_and_port_forwarding#Reverse_connection_over_an_ssh_tunnel
Would you mind taking a look to be sure I didn't miss anything or
bollix it up?
The sshd config options you mentioned may be why your method
doesn't work on the Pleiades system, either that or there is a
firewall between the front ends and compute nodes. In either case
I doubt the NAS sys admins are going to reconfigure for me :) So
at least for now I'm stuck with the two hop ssh tunnels and
interactive batch jobs. if there were someway to script the ssh
tunnel in my batch script I would be golden...
By the way I put the details of the two hop ssh tunnel on the wiki
as well, and a link to Pat's hpc.mil <http://hpc.mil> notes. I
don't dare try to summarize them since I've never used portfwd and
it refuses to compile both on my workstation and the cluster.
Hopefully putting these notes on the Wiki will save future
ParaView users some time and headaches.
Sean Ziegeler wrote:
Not quite- the pvsc calls ssh with both the tunnel options and
the commands to submit the batch job. You don't even need a
pvsc; it just makes the interface fancier. As long as you or
PV executes something like this from your machine:
ssh -R XXXX:localhost:YYYY remote_machine submit_my_job.sh
This means that port XXXX on remote_machine will be the port
to which the server must connect. Port YYYY (e.g., 11111) on
your client machine is the one on which PV listens. You'd
have to tell the server (in the batch submission script, for
example) the name of the node and port XXXX to which to connect.
One caveat that might be causing you problems, port forwarding
(and "gateway ports" if the server is running on a different
node than the login node) must be enabled in the
remote_machine's sshd_config. If not, no ssh tunnels will
work at all (see: man ssh and man sshd_config). That's
something that an administrator would need to set up for you.
On 02/08/10 12:26, burlen wrote:
So to be sure about what you're saying: Your .pvsc script
ssh's to the
front end and submits a batch job which when it's
scheduled , your batch
script creates a -R style tunnel and starts pvserver using
PV reverse
connection. ? or are you using portfwd or a second ssh
session to
establish the tunnel ?
If you're doing this all from your .pvsc script without a
second ssh
session and/or portfwd that's awesome! I haven't been able
to script
this, something about the batch system prevents the tunnel
created
within the batch job's ssh session from working. I don't
know if that's
particular to this system or a general fact of life about
batch systems.
Question: How are you creating the tunnel in your batch
script?
Sean Ziegeler wrote:
Both ways will work for me in most cases, i.e. a
"forward" connection
with ssh -L or a reverse connection with ssh -R.
However, I find that the reverse method is more
scriptable. You can
set up a .pvsc file that the client can load and will
call ssh with
the appropriate options and commands for the remote
host, all from the
GUI. The client will simply wait for the reverse
connection from the
server, whether it takes 5 seconds or 5 hours for the
server to get
through the batch queue.
Using the forward connection method, if the server
isn't started soon
enough, the client will attempt to connect and then
fail. I've always
had to log in separately, wait for the server to start
running, then
tell my client to connect.
-Sean
On 02/06/10 12:58, burlen wrote:
Hi Pat,
My bad. I was looking at the PV wiki, and thought
you were talking about
doing this without an ssh tunnel and using only
port forward and
paraview's --reverse-connection option . Now that
I am reading your
hpc.mil <http://hpc.mil> post I see what you mean :)
Burlen
pat marion wrote:
Maybe I'm misunderstanding what you mean by
local firewall, but
usually as long as you can ssh from your
workstation to the login node
you can use a reverse ssh tunnel.
_______________________________________________
Powered by www.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the
ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Follow this link to subscribe/unsubscribe:
http://www.paraview.org/mailman/listinfo/paraview
