SDB:VNC usage
If you want to contribute, please read the rules for this wiki and if you have any questions, don't hesitate to contact the wiki team, we are more then willing to help you! :-)
General
So what is VNC?
VNC gives you a window on the client in which a remote session is running on the server, which for all practical purposes is equivalent to sitting at "Server" and using the Monitor/Keyboard/Mouse there.
VNC can use a "Virtual" GraphicCard, Keyboard, and Mouse on server. In this form you can start as many "Virtual Sessions" as "Server" has resources to handle. This allows multiple persons to work on "Server" simultaneously (using his/her local keyboard/mouse/screen ). This is similar to the windows "Terminal Server" function.
VNC can also copy the contents of the real Graphic Card giving access to the real screen on "Server" (Remote Desktop). Since you got access to the Physical screen, both the remote and the local users share this session and can see what the other is doing. That is why these methods are used for remote support, and called "Remote Desktop Sharing".
As you can see VNC is very flexible, and therefor has lots of options each suited for diferent needs. Infact you can even "Remote Desktop" share a VNC Terminal Session, by combing 2 of the methods together!
Strengths vs. weaknesses
- + Easy to use web browser as a client
- + Comes with most Linux distributions
- - Difficult to install and use (... lets not dwell.)
- - Slow
- - Insecure
- - Can not adjust to different client monitor sizes easily
- - Bad server and client management (... lets not dwell.)
Installation
The easiest way to achieve this is to install the default OpenSUSE package "tightvnc".
Connectivity
For VNC client connection remember to open ports 5901-> in the firewall. (1 port/Xsession.)
For HTTP connection with Java, remember to open ports 5801-> in the firewall. (1 port/Xsession.)
By default VNC connections will start at port 5900 (or port 5800 for HTTP connections) and then add the display number of the Xsession that has been started. i.e. if the Xsession has been started as display :1 then the port to use to connect to this VNC Xserver session is 5901 (or 5801), likewise the port will be 5902 (or 5802) if the Xsession has been started as display :2.
Remote X login
Here we use a VNC setup designed to use minimal resources on the server. This is done by not starting the VNC session until someone tries to connect, and shutting the VNC session down as soon as client disconnects from it.
The VNC sessions are identical to the sessions on the physical screen of "Server", they even start of with the identical logon screen.
User sessions
Here we "Prestart" vnc sessions for specific users, therefore no login screen is presented. This uses more resources as the VNC Session is running even when no client is connected to the session watching it. But there in lies it's advantage, "watching a session" and "using a session" are not the same thing! This method is very usefull for starting long running programs before going home. Once home you can re-connect to the session and see how things are going.
Sharing a users session
Here VNC is used to "Share" the current user's Desktop by copying the contents of the physical Graphic Card giving access to the real screen on "Server" (Remote Desktop). Since you get access to the Physical screen, both the remote user and the local user share this session and can see what the other is doing. That is why these methods are used for remote support, and called "Remote Desktop Sharing".
As both users have complete control over the desktop, it can be a lot of fun watching people 200 miles apart fighting for control over a single mouse pointer. However this fun can be stopped by making the session "viewonly", where the remote user can see what is going on but cannot have any input via the keyboard or mouse.
Using the built-in desktop sharing feature of KDE
To use this feature within KDE you should install the package "kdenetwork3-vnc" (or "KDE4-krfb" if you want to use the KDE4 version) within YAST. The application can then be run as "krfb" from the command line or found as "Desktop Sharing - krfb" in the SUSE menu under Applications - System - Remote Access.
Using this application will allow your local Xsession to become a shared Xsession that others can join. Krfb will automatically make the required changes and create an invitation for the remote user to join your session, that can then be sent either via an email or by letting them know the ipaddress, screen number and password which have been assigned by some other suitable means. Remember that if the remote connection is coming from an external network the ipaddress reported by krfb will be incorrect and the remote user will need to replace it with the external ipaddress of your router. It is likely that the required ports will also have to be forwarded within your router so that it will connect to the intended PC. When the remote user attempts to connect to the shared desktop the issuer of the invitation will be required to accept the connection first and can choose at that time to allow either full or view only access.
If you are not running a KDE desktop or simply want to have complete control over the process, then you can do this manually. One example of this is the application "x11vnc". This comes standard with OpenSUSE but will probably have to be installed first. This can be done easily from within YAST by searching for and then installing the package "x11vnc".
Once installed you can run this from the command line and have complete control over how the Xsession is shared. There are many options available and if want to investigate them the man page for x11vnc is perhaps the best place to start. If you just want to get something going then a quick and dirty default would be the command below:
x11vnc -usepw -ncache -display :0
Broken down this calls the application "x11vnc", tells it to use a password for connection "-usepw", turns on cacheing to speed things up "-ncache" and tells the vnc server to use the first session "-display :0". This is not very fancy and you can even get away with just specifying the display and nothing else but it is generally a much better idea to at least use a password. Experimenting with the different methods of compressing or eliminating some of the network traffic will likely also get you a much faster response on the remote side. But keeping things simple at the start will at least tell you that things are working.
Note that the initial Xsession started at login is labeled as display 0 by default. Subsequent sessions will be started by default as display 1 , 2 ... etc. A password can be created by using the command "x11vnc -storepasswd actual_password /path/to/password_file" or just "x11vnc -storepasswd" if you wish to use the password from an existing VNC installation.
You should be able to test this now by using a VNC viewer from another PC on your internal network to connect remotely. If this is not possible then you can use your own PC to connect "remotely" to your own desktop. This should only be used if you do not have another PC on the local network to use, as you may get some strange screen behavior from it.
Using ssh to establish a secure VNC session
If x11vnc and ssh services are available on the remote machine and you wish to establish a secure VNC session to remotely control an active live desktop try using the following two steps. In one console enter the following command but fill in the user and domain names as needed -
ssh -t -L 5900:localhost:5900 loggedInUserName@computername.domain 'x11vnc -localhost -nolookup -nopw -display :0'
This establishes a secured encrypted connection from your machine to the remote machine. The -t option allows you to run a screen based program and the -L option binds your local VNC port (5900) to the remote machines VNC port. Then you log in as the user on the remote machine and of course you will be asked for a password. Once connected, this will launch the x11vnc server on the remote machine. The parameters given to the x11vnc server allow the local host to establish a connection (-localhost), limits how host name and IP address lookups are done (-nolookup), stops the warning message about not supplying a password (-nopw) and connects to display 0
Next, from a separate console, on your machine, start a vncviewer window with the following command -
vncviewer -encodings "tight copyrect hextile" localhost:0
This will connect to port 5900 which you bound to the remote host port 5900 and pass the encoding parameters that you desire (-encodings "tight copyrect hextile") to the remote x11vnc server and give you a display of the remote desktop on your local display.
This effectively accomplishes the same thing as using the KDE tools Krfb and Krdc (which as of SuSE11.0,11.1 are broken) and gives you a VNC session with a live desktop. (useful for sysadmins, helping mothers, etc..) PLUS it is all done over a secured connection and does not require the user on the other end to do anything!
Sharing the local X-Windows session
Here we setup vnc to allow remote access directly to the physical graphic card (X-Windows system), allowing us to see / use the real screen on "Server". This is most used in support where operators do not want 2 people working on the same machine at the same time. In this method the person physically at server can watch everything the remote user is doing.
NOTE: (the windows version of VNC server only supports this mode, as windows does not support virtual screens)