System Connectivity Tools

TightVNC is a VNC distribution with many new features, improvements, and bugfixes over VNC. It is optimized for faster operation on slow network links such as modem connections, provides more configuration options in the server, features automatic SSH tunneling in the Unix vncviewer, and more. The modified servers and viewers are fully compatible with the original VNC software.

Rated 9.10/10.00 (128 votes)

http://www.tightvnc.com/ http://freshmeat.net/projects/tightvnc/

http://www.uk.research.att.com/vnc/

ftp://ftp.uk.research.att.com/pub/vnc/dist/vnc-3.3.3r9_x86_win32.tgz http://www.uk.research.att.com/vnc/dist/vnc-3.3.3r9_winsrc.tgz http://www.uk.research.att.com/vnc/dist/vnc-latest_doc.tgz http://www.uk.research.att.com/vnc/dist/vnc-3.3.3r2_x86_linux_2.0.tgz http://www.uk.research.att.com/vnc/dist/vnc-3.3.3r2_javasrc.tgz http://www.uk.research.att.com/vnc/dist/vnc-3.3.3r2_unixsrc.tgz

http://www.zdnet.com/products/stories/reviews/0,4161,406544,00.html http://www.linux-mag.com/cgi-bin/printer.pl?issue=2000-11&article=desktop http://www.help2go.com/BestoftheNet/VNC.cfm http://www.utilitygeek.com/software/virtual/vnc.html http://security-archive.merton.ox.ac.uk/nt-security-199904/0011.html http://security-archive.merton.ox.ac.uk/nt-security-199904/0001.html http://www.tecmag.com/remote.htm

You should copy these programs to some directory which is in your PATH environment variable, such as /usr/local/bin:

If you want to use the Java VNC viewer, you should copy the class files from the classes directory to some suitable installation directory such as /usr/local/vnc/classes:

We recommend that you use the vncserver script to run Xvnc for you. You can edit the script as appropriate for your site. Things you may need to change include:

Creating default startup script /home/tong/.vnc/xstartup Starting applications specified in /home/tong/.vnc/xstartup Log file is /home/tong/.vnc/sunny:1.log

— connect to sunny:1, AOK

— connected as root!!!

When you make a connection to a VNC server, all other existing connections are normally closed. This is for security reasons, and because we normally think of VNC as a tool for mobility: your desktop follows you from place to place.

Command line options: -shared can fix it.

VNC uses a random challenge-response system to provide the basic authentication that allows you to connect to a VNC server. This is reasonably secure; the password is not sent over the network. Once you are connected, however, traffic between the viewer and the server is unencrypted, and could be snooped by someone with access to the intervening network.

So, make it simple, run vncserver as myself and avoid any further login requests.

How to 'tunnel' the VNC protocol through SSH is discussed in the article.

H has another advantage. It can compress the data as well. This is particularly useful if the link between you and the server is a slow one. It might be a better way to connect form my home to office using cable modem. And it might be the only way for vnc to go through the univ. firewall.

If you get a 'Client is not authorized to connect to Server' or similar message, there's something wrong with the X authority setup - perhaps xauth is not on your path? You could try using xhost to bypass this temporarily, but we wouldn't recomend this as a long-term solution. There should be some indication in the log file if xauth has failed.

From http://www.uk.research.att.com/vnc/archives/2000-06/0199.html

No!

I found out that there is nothing wrong with my server environment. I can start my vnc server locally, within / without a X server.

The problem is that I can't remotely start it, either from xterm or remote tty connection.

Besides, locally I can specify the -display parameter to lanuch my xterm from my X-window into my vnc-client. But remotely I can't:

If the remote machine is running Linux then,

Then using a viewer in Windows you can connect to remotemachine:1 and display it there. Or, you can browse to http://remotemachine:5801 with a Java capable web browser.

I would also refer you to

http://ftp.digital.com/pub/Digital/SRC/x2x/

and

The venerable x2x tool allows a single keyboard and mouse to control multiple X sessions, and moving from screen to screen can be set to occur when the mouse cursor "moves off an edge" of one display, whence it will appear on the adjoining edge of another display. Selection and cut buffers are synchronized.

VNC can be used in much the same way as dmx; the added features of VNC (accessability from most any platform, even any java-enabled web browser, session restarts, etc) are also there. For example, if you have two screens, you can start an Xvnc session the size of both of them side-by-side. For example, if you have two 1024x768 physical displays, you can create a single Xvnc virtual desktop of size 2048x768. Then, you can run vncviewer on each of the physical displays, each vncviewer displaying half the virtual desktop. This works reasonably well if one of the screens is mostly used to park display processes. You could couple it with x2x, but note that simply dragging a window from one physical screen to the other would still require you to drag it to span the divide, then drag it the rest of the way after warping the mouse to the other display (hopefully the limitation I'm talking about is clear).

So. VNC and x2x have some advantages over dmx.

Ultimately, dmx will be a better tool, and will have better support tools for dealing with window management to make the breaks between physical displays act more smoothly. But the other two are also worth looking at.

Wayne Throop