VNC
From Helpful
| This article (or section) isn't finished, and may contain temporary best guesses. Feel free to fix and add, but consider that the original or last may be working on it on and off. |
(See also VNC and RDP from applets, Remote X windows)
Contents |
Introduction
VNC (Virtual Network Computing) is, as far as I know, the easiest remote desktop controller when you have the requirement that it has to crossplatform. Servers exist for windows, unices, macs (see here, and also here, java, and even java applet form (avoiding client installation).
It is a very simple solution in that has few requirements on the server side, which is the reason it is broadly applicable. Note, though, that servers work differently for different operating systems: You can start a new X windows inside VNC in unices, while in a windows you can only give control of a logged in session.
Alternatives to...
While X itself is a protocol that is network-transparent (though some modern X extensions sort of ignore that), it often isn't practical to use the X protocol in a networked way because of security details (no encryption) and somewhat complex configuration. It becomes potentially interesting again through VPN. See Remote X windows and e.g. hamachi if interested.
The windows-only Remote Desktop (a.k.a. Terminal Services) and the unix-only NX are more bandwidth-efficient by essentially being remote video drivers - they receive the succinct descriptions of what to draw - in contrast, VNC just notices the screen has change and sends well-compressed images of it.
Apparently there's also something called radmin.
If you only want only a single simple solution that involves connections to a single OS, look into the more specialized protocol, since there are also remote desktop clients for linux and NX for windows.
VNC implementations
- TightVNC: server and client, free, windows and *nix. Otherwise fairly minimal (e.g. no GLX support in the server(verify))
- RealVNC: server and client, free and paid-for versions, windows-only but has extra features like file transfer. It seems targeted at helpdesks.
- UltraVNC: Similar to RealVNC, but free.
TODO: Summarize [1] and put it here. The page also goes into a lot of technical detail only the nerdier will be interested in.
VNC, X and window managers
Unix VNC servers act as graphics drivers for X; a VNC server contains an X server. One of the few differences with a regular X server is that it has its own configuration file that lists what it should do when started.
I currently use the TightVNC server, which places this in ~/.vnc/xstartup which gets executed after the VNC server starts. Simple example contents:
xrdb $HOME/.Xresources xsetroot -solid grey xterm -geometry 80x24+10+10 -ls & twm &
xrdb sets a number of properties on the root window that is created (I'm not sure how necessary this actually is), xsetroot sets the background (the 'root window') to a solid color instead of the default pattern so that it compresses better, xterm -ls gives you a login shell in an xterm to start working with. (this shell is a child of the vnc server process, meaning it will outlive you killing the window manager, unlike shells you started from the window manager)
The last line runs the actual window manager. The X windowing system does not strictly need a window manager - it's just that you can't do very much without one. A window manger takes a running X process and, well, manages it, meaning it introduces borders and interactivity.
A window manager is really just a running program, and more client-like than you may think - it isn't actually very hard to kill a running window manager and run another. You start it here by running the executable that starts it off, like blackbox startkde, twm or whatnot.
It is best to choose a window manager that gives you whatever conveniences you want (me, I love alt-right-drag rescaling) but is not graphics intensive -- running, say, KDE, Gnome, or enlightenment over something not broadband will not generally make you happy. Still, with the animations tuned down, KDE runs fine over LANs.
It is technically possible to run XDM (or KDM or GDM) to give you a login and choice of window manager (see eg. this), but that's a little odd of a setup in a few ways. Look into downsides when you do this.
Server startup
The vncserver command syntax is probably partially specific to TightVNC. See the documentation of what you use for details.
TightVNC
Starting a vnc server:
vncserver
This is a perl script that will asume some defaults and start a vncserver on the first available X display. The local display, if applicable, usually takes up only :0, so this starts at :1. When more than one local / VNC display is used, you may want to specify a specific number to avoid confusion.
You can use more options:
vncserver :2 -geometry 900x700 -depth 16
Geometry controls the desktop size. I personally prefer a large view, but not one that makes the client window shadow my entire desktop (usually 1024x768 or 1280x960).
Depth 16 will be a little easier on the network than 24, and a little uglier.
Stopping a vnc server:
vncserver -kill :2
You should save things, of course, and possibly log out of your windowing environment to let it save its settings.
Image format note
Actually, if you want to get the best speeds you should check out both this and -pixelformat. The server side conversion is almost inherent anyway, but your client will be faster if your client computer uses exactly the format and depth that were sent, simply because it won't need client side pixel format conversion for each frame. If you communicate over only a LAN, that may easily outweigh using less bandwidth.
Ports
A VNC client connects to an IP and either a display-number-dependant port. The port is usually 5800 plus the display number, and/or 5900 plus the same. Of course, every vnc server instantiation can have its own password, which is unrelated to the user password.
In any case, the system admin will have to allow incoming connections in your firewall unless you use port forwarding or tunneling.
Multi-user setup
The above means people are on fixed ports, so when more than one person uses VNC on the same server it may be a good thing to settle on a division of ports to avoid a mess.
Multi-user setups are harder, because VNC was not made for it. It would either take reserving ports or telling people to start their servers and notice what display it takes.
It may be easier to use a XDMCP setup, making the VNC server do a XDMCP query instead of running a window manager - see Remote X windows for the general details. You can of course firewall it entirely as the client and server side are the same host, so most of the bother is pretty nicely moot.
This means you can run a number of VNC servers that have no (significant) password themselves but instead let users use the underlying system's authentication. It should be fairly simple to set up.
Security
Note that by default, VNC is not encrypted. Some flavours support it, but for more general security you may wish to look at ssh tunneling or the zebedee tunneling (apparently faster than ssh for this purpose) mentioned here.
A password is hashed and stored for a particular server (usually per-user), always one for interaction, and possibly one for viewing.
Clients may store this hash (The TightVNC client can store all connection info in a file so that a simple double-click will reconnect you). Therefore: don't use your best password, it may be brute forcable. Of course, the same goes for the password hash on the server side.
Details
There are various VNC toys, like the vnc2swf program that you can use to record interaction as Flash video. Various details and more are at eg. this page.
