[Paraview] paraview - client-server

Mon Feb 8 20:12:29 EST 2010

Actually I didn't write the notes at the 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 <burlen.loring at gmail.com> 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 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 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
>>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20100208/1540b45a/attachment.htm>