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 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
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
