VNC -- Virtual Network Computing Summary VNC gives you access to the desktop of a user on a remote computer. In KDE 3.1, this is intgrated as "Shared desktop" and can be configured in the Control Center. VNC is cross-platform -- it runs on Windows, Macs, and Linux. It generally works beautifully and without complications. VNC also works through a browser, using Java, but this is slower.
Try http://spello:5801/ (you need tightvnc-java on the server for
this). You can also run VNC to a firewalled machine, and use it to run applications on remote machines you have some kind of access to. Software
Instructions For a systematic setup, see file://localhost/usr/share/doc/vncserver/README.inetd (present if you've installed vncserver). Setting up VNC with OpenSSH: http://www.linuxjournal.com/article.php?sid=5499
To start a server, issue
or more explicitly
This size works perfectly for a 1600x1200 display, so you don't
get scrollbars. For lower resolution over low-bandwith connections,
try -depth 8 (or 16; most monitors use 24 default). For all the
flags, see man vncserver. To view the desktop on a remote computer, you can log into that computer (say, through a tunnel) and then issue, vncviewer :1You'll be prompted for a password and the desktop will appear. Use your current X11 session "With x11vnc you can export your currently running X11 session to any VNC client. You do not have to launch another session as the regular VNC server does. So it's very useful, if you want to move to another computer without having to log out, or to help a distant colleague to solve a problem with their desktop." This is of course how Windows VNC sessions work, not giving you the choice of a new session. As a desktop Edit .xsession: exec vncviewer -truecolour -passwd $HOME/.vnc/passwd -fullscreen localhost:1From behind a firewall If the server is behind a firewall at the other end of a tunnel, this works: client: vncviewer -listen 1Note that you need to get the port number from the client -- the vncviewer -listen command will tell you where to send the page. This is a lot faster than starting the vncviewer on the remote machine! On cogweb.net
Using other displays Normally vncserver will choose the first available display number and tell you what it is, but you can specify a display number if you always wish to use the same one: vncserver :2 You can cause applications to a particular display by setting the DISPLAY environment variable to the VNC server you want, or by starting the application with the -display option. For example: xterm -display paco:2 & For instance, Gubbio is for some reason not starting a windows manager with vncserver (details below), but it does start X-windows. To get to the desktop, ssh to Gubbio and issue xterm -display gubbio:2 & Once the xterm has started, you'll see it in the vncviewer window. Issue startkde As KDE starts, you can hide the xterm and proceed as normal. For using vnc through ssh tunneling, see http://www.uk.research.att.com/vnc/sshvnc.html From the man pages: vncserver parses first the site wide configuratione file /etc/vnc.conf and then the user configuration file ~/.vncrc. This way a user can override or delete the values from the site wide vnc.conf. A user can also trigger the default value when he sets the value to the empty string "". The java viewer can be called from console -- and even from localhost: jtightvncviewer localhost:1 Make sure you're the right user or it will abort. This works on gubbio, and from gubbio to paco -- yet gubbio is still not starting an xserver. To start the KDE Desktop Sharing program issue krfb -caption "%c" To get the desktop in gubbio, start vncviewer, get they gray X-window, and issue xterm -display gubbio:1 & Once you have the xterm, issue startkde. Works! You can have all four sisters on the second desktop, scaled and fitting into the large screen. By unchecking "Show windows from all desktops" in the KDE Panel configuration, you don't see these remote desktops listed as applications on the default desktop "kicker" panel. This stuff is magic. To OSX I got this working by enabling Remote Desktop and then under
Access Privileges, checking "VNC Viewers may control screen with
password" and entering a password. Installation history on Debian Spello and Cyberspace worked out of the box, but on Paco and Gubbio the window manager didn't start on its own, so I just got a gray X-window with a cursor. The problem is signaled when you start the vncserver: "Starting applications specified in /etc/X11/Xsession". Neither systems had this file, which is part of kdm (or gdm/xdm). On Paco I installed kdm and it started working; on Gubbio, the file /etc/X11/default-display-manager had the single line /usr/bin/gdm, which I had long since uninstalled. I changed it to console. That still didn't fix the problem. I installed kdm; still no luck. I then issued /vc/software/debs/X-4.2.1-6# dpkg --force-conflicts -i xlibs_4.2.1-6_i386.deb to downgrade xlibs from 4.3 to 4.2.1 -- the 4.3 version has been split into xlibs and xlibs-data. I had already done this on paco, to get the video driver to work. So it looks like the new xlibs may be causing problems. However, this all made no difference, and just for the fun of it I reverted to xlibs 4.3. I did find the solution to getting the desktop, however, and learned a few things at the same time: just start an xterm in the X-window, and run startkde from it. You can start any program with the -display gubbio:1 & flag. So this is working. If you don't close down this KDE session, it will be there next time you start vncviewer. In fact, the normal mode of doing things leaves you a bit less flexibility. Previous notes that don't refer to Debian -- the SuSE 7.3 installations Software
Guide
Linux installation TightVNC installations On 25 April 02 I installed TightVNC on Cyberspace. I had to compile it, following the instructions in the README file; there were no problems. I compiled the version without the zlib and jpeg libraries, after checking that libjpeg was already installed (I knew zlib was). I then copied the files as instructed to /usr/local/bin and /usr/local/vnc/classes, overwriting the previous ATT VNC installation (without warning me). I moved back to /home/steen and gave the vncserver command; the program was not found. I queried,
and got /usr/sbin:/bin:/usr/bin:/sbin:/usr/X11R6/bin -- but no /usr/local/bin, which I added like this:
This successfully added /usr/local/bin to the $PATH environmental variable. You need to get better at handling these, but anyway this one worked. Then I started vncserver and it started :5 under root -- I realized that I was su root and that /usr/local/bin shouldn't even really be in the path. So I killed the :5 server and exited su root. I then ssh'd to steen, killed the running VNC servers, and started up a new one, which should be the new TightVNC! It seems to run fine. On 2 July 2002 I got SuSE-Linux-244-vnc.tar from ftp://ftp.kinetworks.com/tightvnc/ and installed it on gubbio, after uninstalling the VNC I had. It installed in /usr/local/bin/ over the old version from AT&T. I also updated the installation on cyberspace -- perhaps not necessary. The binaries I downloaded lacked the man files, so I copied those from cyberspace to gubbio. TightVNC required some configuration. The configuration file that is generated automatically by the vncserver.sh script is mistaken on a couple of fronts. 1. /usr/local/bin/vncserver needed to be changed:
2. The ./vnc/xstartup script generated by vncserver.sh was wrong -- mainly in that the directory given for xrdb, xsetroot, xterm, and twm was wrong. Note that these files don't need a directory specified at all, as the old ./vnc/xstartup shows -- and incidentally, it works fine:
The new file (corrected) is identical. Just type vncserver as before to start up a new session; the
script vncserver.sh creates four sessions and generally messes things
up. ATT VNC installations On 23 March 02 I installed VNC on gubbio as root. I got the program from http://www.uk.research.att.com/. I got the x86 Linux version 3.3.3r2. the gzipped tar (tgz) opened in Archiver and I placed the package in /usr/src/packages/SOURCES/ I then followed the instructions in the README file:
I did so, from the command line: gubbio:/usr/local/bin # vncserver
gubbio:/usr/local/bin # I then started the WinVNC viewer in windows and typed 128.97.184.97:1 -- the network doesn't know the machine as gubbio. It worked! The default is to get an xterm window; on subsequent logins you get whatever you had when you last left off. You can run any program from the command line. To access the desktop, just type kde. You can have multiple versions of kde (and any other program) running through multiple VNC servers. Two clients cannot access the same VNC server simultaneously. I tried opera, konqueror, kwrite, and pixie, and they all worked great. The KDE apps crash when I exit, but no harm done. The resolution is a bit grainy. You cannot copy from Linux and paste into Windows, but you can copy from Windows and paste into Linux! I'll kill the server:
The control files are all kept in /home/steen/.vnc. To start over, just delete them. You can do this in a VNC session. To be safe, start the VNC session with ssh, and then remove it with ssh once you're done. Java client for VNC I just learned you don't even need a vnc client on your local machine to access another computer in this way -- you can use a browser and run the Java version of VNC (which I installed, cf. above) like this: Linux1: http://128.97.184.96:5801/ [currently KDE desktop] The last digit is the terminal number. You'll be greeted with a VNC login prompt and then you'll be connected and have full control. It's slower, but it works! On Linux, each VNC client gets a different VNC server. To support multiple clients, you start multiple servers. They don't share an X-window but start up their own. Windows only appears to support one and will block the second try. Windows server installation and configuration
I did this, wrote the registration keys to Spello's registry and started WinVNC. I set the password again as sherry, and save the connection to the Software directory (not secure, as the pw is saved).I then typed in Linux console,
and got the desktop! The only thing that isn't working is the status bar at the bottom -- an inconvenience between minimized programs can't be retrieved (there's likely some workaround). The Java version of VNC appears to install on Windows by default; it works fine to access it with a browser. Working on Linux viewing Windows Working on a Linux machine and having Windows remote works! It's actually nicer than the other way around -- Linux handles the remote desktop better. So this is a workable solution: you can switch to Linux and have your Windows machine running somewhere else. Of course, you Windows machine is completely insecure, so you can't really run it in a different room. Note that the clipboard works when Linux is the client -- you can cut and paste between Windows and Linux, at least from Windows into Linux (I didn't test the other direction).
|
|
|
|
|||||
Maintained by Francis F. Steen, Communication Studies, University of California Los Angeles |