DRC,
On 11/10/2012, at 2:39 AM, DRC wrote:
> Not sure why you're specifying -encodings "tight copyrect" with the old
> viewer, as that's the default behavior. The new viewer won't support
> that literal argument, since there is no need for it.
That was a workaround for this problem:
Same machine: preferring raw encoding
when specifying "localhost" for the hostname after manually setting up an SSH
tunnel.
Yes, I know that the official solution (when using the X11 viewer is to use the
"via" option), but it felt messy to have our application spawn a vncviewer
process which then spawned a separate SSH process. We wanted the SSH process
which created the tunnel be directly spawned by our application so we could
feel like we had complete control over it.
For an example of why it may be useful to do the tunnelling separately, we had
a case recently where our application failed to create an SSH tunnel for one
user (while attempting to use SSH keys), because his home directory had
drwxrwxrwx permissions, so the SSH session refused to use the SSH keys and
asked for a password to be entered interactively (which was hidden from the
user). SSH doesn't always provide useful feedback when there are permissions
problems. So our application now tests that SSH tunnelling is working OK
before starting the VNC stuff. In the case of our HPC system, starting a VNC
session requires requesting a "visualisation node", with 12 CPUs and 2 GPUs,
using qsub. If we didn't test the SSH tunnelling stuff separately, then we
could end up with a wasted "visualisation node" job in the HPC system's queue
which was unusable for the user who was unable to create an SSH tunnel.
Cheers,
James
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
VirtualGL-Devel mailing list
VirtualGL-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
