HOWTO: Control the gnome VNC vino-server from the command line

[doobiest]

For those that stumble upon this thread trying to start vino from the cli via a remote ssh connection look here: http://ubuntuforums.org/showthread.php?t=1017746
at post #7

1. ssh to that machine and authenticate as x
2. sudo -s to become root
3. export DISPLAY=:0.0
4. xhost +
5. exit from root shell using exit
6. export DISPLAY=:0.0
7. start vino-server using /usr/lib/vino/vino-server

There may be another way but this saved my bacon after the Karmic upgrade when I needed to get my desktop and vino wasn't started.

This worked perfectly for me, and really only 6 & 7 are needed.

6. export DISPLAY=:0.0
7. start vino-server using /usr/lib/vino/vino-server

I would a & actually, so /usr/lib/vino-server &

If this happens often you could create a script like I did

sudo vi /usr/local/bin/restart_vnc

insert these two lines

export DISPLAY=:0.0
/usr/lib/vino/vino-server &

save (:wq)

sudo chmod +x /usr/local/bin/restart_vnc


Also the gconf tips here dont work. I'm sure that toggles the config options but doesnt restart a crashed server.

Also I've experienced that SSH -X or -Y and issuing vino-preferences doesnt work. What is actually does it spawn a vino server on the client machine (if linux i guess) so when you vnc through your ssh tunnel it just loops back to your clients desktop.

[bobpaul]

Also I've experienced that SSH -X or -Y and issuing vino-preferences doesnt work. What is actually does it spawn a vino server on the client machine (if linux i guess) so when you vnc through your ssh tunnel it just loops back to your clients desktop.

If you ssh in and execute vino-preferences, it's running on the remote machine; only the UI is forwarded to the local X11 server. vino-preferences running in this way does not have access to the files/services on the local machine anymore than it would if you were sitting at the remote machines keyboard and running vino-preferences there. If vino-server was running on your local machine, it's either because it was already running or you ran vino-preferences on the local machine instead of the remote host.

You stated "so when you vnc through your ssh tunnel"... How did you have your port tunnel (-L) setup? My guess is you connected to the local vnc server on localhost directly instead of connecting to the ssh client's port tunnel. It didn't loop back... it never even left your machine.

[doobiest]

#ssh -X destination
#vino-preferences
*close vino-preferences
#ps aux|grep vino (shows the server running now)
#vncviewer -via destination localhost (executed locally, not in the ssh session)

This redirected me to my local vncsession, not the remote one. And No I have verified that the vino-server is not running locally on my client

It's completely reproducable I jsut did it right now again. It does run vino-server on the remote computer but it's attached to my local X display, not the remote one. If I close the ssh connection, then of course it stops vncing to my local session and doesnt vnc to the remote session either. The processing for the service might be occuring remotely but the routing is still going local.

[doobiest]

There's no level of technical accuracy here but this should describe what is happening.

[vncviewer]-->[ssh tunnel]-->[remote vnc server]
[local X ]<--[ssh tunnel]<--[remote vnc server]
[local X ]-->[ssh tunnel]-->[remote vnc server]
[vncviewer]<--[ssh tunnel]<--[remote vnc server]

(Following the arrows, read some lines left to right and some lines right to left)

ps aux|grep vino-server on Local box = NO
ps aux|grep vino-server on Remote box = YES

Are we certain that X11 Forwarding ISNT bi-directional? It sure seems that way to me.

[tormod]

Yes, doobiest is right, just running vino-preferences over an X11-forwarding ssh session might start a vino-server controlling the local (to you) display. This was also mentioned here http://ubuntuforums.org/showpost.php...67&postcount=4

You can verify which X server (display) the vino-server is controlling with:

cat /proc/`pgrep vino-server`/environ | tr '\0' '\n'|grep DISPLAY

If it shows DISPLAY=:0.0 it is the local display on the remote machine, thus the remote screen (which you most likely want to access). If it shows for instance DISPLAY=localhost:10.0 it is tunneling back through your X11-forwarding ssh connection and thus to your local screen and you get a loop.

The use of dbus-launch lets vino-server be started by the dbus server running in the remote session, so that it connects to the display of that session.

[tormod]

So here is how to make this work (tested on Ubuntu 9.10):
Connect with ssh -X to your remote machine. Find the dbus address of the processes in the desktop session running "locally" on the remote machine, for instance the nautilus process:

cat /proc/`pgrep nautilus`/environ | tr '\0' '\n' | grep DBUS

Now start vino-preferences on the remote machine but set the DBUS address which you found above:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-blahblah... vino-preferences

You can now run vinagre on your local machine.

On the other hand, the use of dbus-launch with gconftool-2 makes vinagre start on the right display, however the changes made in the vino-preferences GUI are not applied to the started server. At least that was what happened here, where I ended up with a bunch of dbus and gconf servers running. Even if I turned off the "You must confirm each access to this machine" in the GUI, this option stayed on for the started vino-server, so I could not connect to the unattended machine.

[doobiest]

Thanks thats actually very helpful. I need to take a deeper look at that.

I'll post this again, because I think what you posted may be too complicated for some users who don't have the background knowledge in this area.

Making a script like is worked great for me. I usually find vino crashes (inconsistently) when I'm using the clipboard. I can run vnc_restart from ssh easily to gain access again.

doobiest@LinuxBox:/usr/local/bin$ cat vnc_restart
export DISPLAY=:0.0
/usr/lib/vino/vino-server &

[dekelev]

Quick & Easy setup for connecting to a gnome session on ubuntu 10.04


configure the user on the remote computer:
1. remove /home/user/.gnome2/keyring/default.keyring or login.keyring
2. run command: sudo apt-get install libpam-keyring
3. append to /etc/pam.d/gdm: @include common-pamkeyring
4. log out and back
5. set 'System->Prefrences->Remote Desktop' ---> when you asked to enter a keyring give an empty password

every time you want to connect from a client computer:
vncviewer -via remote_host localhost:0
OR
vnc into port 5900 at ip_address from any vnc client

Enjoy!

[mattnworb]

Quick & Easy setup for connecting to a gnome session on ubuntu 10.04


configure the user on the remote computer:
1. remove /home/user/.gnome2/keyring/default.keyring or login.keyring
2. run command: sudo apt-get install libpam-keyring
3. append to /etc/pam.d/gdm: @include common-pamkeyring
4. log out and back
5. set 'System->Prefrences->Remote Desktop' ---> when you asked to enter a keyring give an empty password

every time you want to connect from a client computer:
vncviewer -via remote_host localhost:0
OR
vnc into port 5900 at ip_address from any vnc client

Enjoy!

This has the nasty side-effect of storing any passwords that you save in applications (such as Pidgin or Thunderbird) in plaintext, under ~/.gnome2/keyrings.

Since your user is logged into the machine automatically, then effectively anyone who has physical access to the machine can force a restart and then, if they know where to look, find your passwords.

[laciba]

Another simple workaround that did the trick for me,
in case you unfortunately logged out or rebooted the remote
machine and no automatic login was set previously.
(and if you even want to use vino-server as vnc server after this annoying fact)

The method requires only common sense

1.ssh <remote IP> (without -X)
2.sudo -s
3.apt-get install x11vnc (if not yet installed)
4.x11vnc -rfbport 5901 (or use any port not configured for vino-server)
(you may also have to configure a new tunnel for 5901 port if you played the secure way)
5. now you can reach logon screen with any vncviewer connecting to the 5901 port
6. logon to the remote machine and after that close vncviewer (this also halts the x11vnc server)
7. reconnect to the original vino-server on the original 5900 port.