On Wed, 2 Jul 2008, Arno Schuurs wrote:
James,
Ok, but this means that every engineer has to start a vncserver session on
the server before he can make work on that server via the viewer.
This means that the engineer has to log in to the server remotely first
via a terminal, start a vncserver session, close and start vncviewer.
That is not what the engineers want to do.
They want to log on to the server (an offline simulator) like they are
logging on locally.
What we do is arrange to have a small script on the client end which does
(roughly)
starts vncviewer in 'listen' mode
ssh over to server with -R... (see later) and runs a script which
check if an xvnc is already running for this user
if one isn't then start one and wait for it to get running
use vncconnect/vncconfig to instruct the running xvnc to connect to
the viewer (over the ssh -R tunnel)
What the end-user sees is something which prompts for their ssh password
on the server (or whatever other ssh authentication one uses), and
magically a vnc viewer window appears. If a session had been left running
then it connects to that otherwise it will be a new one...
On unix/linux the following is part of the code that gets run on the
client end:
...
RANGE=3500
RPORT=$(( ( ( $RANDOM + $$ ) % $RANGE ) + $MIN ))
... code to check if vncviewer is already running ...
echo "start vncviewer"
if [ -f /usr/bin/vncconnect ]; then
# old vnc clients like 'tight' take different options, note
# especially that here the 'port' has 5500 added to it!
vncviewer -listen 0 -encodings 'tight copyrect hextile' &
else
# realvnc 4.x etc have many newer features like local cursors,
# better compression and supports re-sizing etc...
vncviewer -listen 5500 -AutoSelect=1 -FullColour -UseLocalCursor &
fi
...
ssh -x -f -2 -c arcfour -R $RPORT:localhost:5500 $HOST 'vncstartup' '-fport'
$RPORT $@
where vncstartup is a fairly simple piece of code which needs to be found
on the server.
It is a bit of a hack to guess a port which will be free on a random
remote server. If we could be bothered we could get it to open the -R
tunnel after checking for a free port on the server using the ssh
control-connection - with new enough versions of openssh anyway. Maybe
the client end of the tunnel shouldn't be fixed at 5500 but that is ok for
a single user workstation
Currently our vncstartup code (which I'm afraid is a bit linux specific)
essentially does:
check if the 'fport' we were given is owned by the right user and looks
like a vnc viewer (it talks trivial RFB to it)
look for a running xvnc display or starts one using a lightly modified
vncserver
use vncconnect/vncconfig to tell it to connect to localhost:$fport
In order to start sessions as we want them our vncserver runs the same
code we use on session startup (rather than xinit or whatever), and we
disable rfc authentication and rfb where possible - since we never need to
connect TO these vnc servers using rfb...
[ My patches to allow disabling rfb listening have been ignored presumably
because no-one can see why one would want to run xvnc without it listening
for rfb. ]
We also have a windows version of the client code though all of this still
needs some polishing - we have a few dozen people who have been using it
for a couple of years here and it mostly works (we need some better error
handling).
-- Jon
_______________________________________________
VNC-List mailing list
[email protected]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
