VNC – allowing remote access to graphical desktops
VNC (an abbreviation for Virtual Network Computing) is a great client/server software package allowing remote network
access to graphical desktops.
TightVNC allows you to display X and Win32 desktops on remote X/Win32/Java displays.
In short, it will allow me to access my FreeBSD box from my Windows box via an X Windows interface (or the other way
around). That’s something
I’ve want to do for a while. A friend had told me about VNC, so I went to FreshPorts
and did a search for vnc. I chose TightVNC.
You should consider the security implication of using VNC over untrusted networks, such as the Internet. If you plan
on using VNC over the Internet, you should use SSH or SSL to secure the session. The documentation will direct you to
the right place.
I already had an up to date ports tree, so I installed TightVNC with this single command:
cd /usr/ports/net/tightvnc make install
My next step was to install the Windows client from the TightVNC download
area. Installation was straight forward and I won’t document it here. It’s Windows. What could go wrong?
But, should you need it, there is a TightVNC for Windows document.
In my situation, I’ll be running the VNC Server on my FreeBSD box, and a VNC Client on my Windows box. You should
note that you can do this the other way around and access your Windows box from your FreeBSB box.
Starting the server
On my FreeBSD machine, I did this:
[dan@undef:~] $ which vncserver
/usr/X11R6/bin/vncserver
[dan@undef:~] $ vncserverYou will require a password to access your desktops.
Password:
Verify:
xauth: creating new authority file /home/dan/.XauthorityNew 'X' desktop is undef.unixathome.org:1
Creating default startup script /home/dan/.vnc/xstartup
Starting applications specified in /home/dan/.vnc/xstartup
Log file is /home/dan/.vnc/undef.example.org:1.log[dan@undef:~] $ ps auwx | grep vnc
ps auwx | grep vnc
dan 41444 0.0 2.5 10824 9796 p0 I 9:18AM 0:36.84 Xvnc :1 -desktop X -httpd /usr/X11R6/share/tightvnc/classes -auth /home/dan/.Xauthority -geometry 1024x768 -depth 24 -rfbwait 120000 -rfbauth /home/dan/.vnc/passwd -rfbport 5901
[dan@undef:~] $
As you can see, the screen was set to 1024×768. I’ll look at changing that resolution later.
The password you just entered must be supplied when you connect to the server.
This password can be changed by running vncpasswd on the server.
Stopping the server
From man vncserver, you will see:
-kill :display
Stops the session running on the specified display.
So to kill the server, I did this:
vncserver -kill :1
Killing Xvnc process ID 46791
where 1 is the value returned when you started vncserver.
Starting the client
In the following example, I will be using the TightVNC client. I also tried the VNC client from
http://www.uk.research.att.com/vnc/.
I’m running a client on my Windows box. You should read the TightVNC for Windows document first.
I started the VNC Client by clicking on Start->Programs->TightVNC->TightVNC Viewer (Fast Compression). I then entered the details
of my VNC Server (undef.example.org:1).
Then you will be prompted for the session password which you supplied when you started the VNC server. This
password can be changed by running vncpasswd on the server.
If all goes correctly, you should now be looking at an X session running on your FreeBSD box. Here’s what it looked like
for me:
From here, it’s just like you’re on the FreeBSD box.
Changing the screen resolution
This was easier than I thought. First, I consulted the vncserver man page.
Then I supplied a value for geometry:
[dan@undef:~/.vnc] $ vncserver -geometry 1280x1024New 'X' desktop is undef.unixathome.org:1
Starting applications specified in /home/dan/.vnc/xstartup
Log file is /home/dan/.vnc/undef.unixathome.org:1.log[dan@undef:~/.vnc] $
Changing the Window manager
The window manager is started by the ~/.vnc/xstartup script. By default, VNCTight
uses twm as that is available on most Unix platforms. Here is the original script:
[dan@undef:~/.vnc] $ less xstartup.original
#!/bin/shxrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &
[dan@undef:~/.vnc] $
My window manager of choice is KDE. To use that, I changed twm
to startkde. From then on, I got KDE on my VNC:
VNC Madness
You can connect to the same VNC server session from more than one VNC client. I tried this and fired up
more than one client. You can see the same thing happen in all clients.
WARNING: I’ve been told that if you connect to the VNC server from within a VNC Client, you will hang the system.
I tried to start up an ethereal session as root from within
a vnc window running on FreeBSD 4.6-STABLE and it fails.
fastpc# ethereal &
[1] 2858
fastpc# Xlib: connection to ":1.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Gtk-WARNING **: cannot open display: :1.0
[1] Exit 1 ethereal
fastpc#
Running ethereal as a normal user works fine.
Has anyone else experienced this?
TIA
I can’t seem to win here. You’re asking a question. Questions are very unlikely to be answered here. PLEASE ask in the Support Forum.
VNC rocks.
I use it to manage my EnTee servers via my wide-area local network (i vpn’d los angeles—>san diego<—orange county).
If i need to hit a server over the internet, i can open the appropriate ports on the network’s router and add map to the server i want to control. i close the hole when i’m done, as VNC only uses 1 pass phrase (no user/password combo).
And all this from my *nix!
re: Ethereal – i haven’t tried to reproduce your issue, but you may be able to tcpdump to a file then examine the results.
Kudos to Dan for the quick’n’dirty on VNC.
~lance
Any time I have a problem with VNC it usually boils down to the screen resolution changing on the other machine and VNC crashing as a result of it. I’ve had this problem in both VNC and TightVNC. – The solution is just to restart VNC and you will pick up where you left off.
I imaging that the script that you placed in your original message is suggesting that there are bigger problems than a client just shutting down on you though. … If so then you might try emailing the wonderful folks at AT&T Laboritories Cambridge.
– Tim
Do you have any reason to prefer tightvnc to vnc?
I followed your article and found vnc to be very useful, but
I am wondering why there are two different *vnc’s in the ports.
Any comments?
-r
I read the descriptions of the two ports and decided upon tightvnc.
Yes, tightvnc is a better server depending on your circumstances. But the article doesn’t mention where tightvnc is better than normal vnc.
Firstly, tightvnc includes JPEG compression. This makes a huge difference if you’re viewing a remote desktop over, say, a 56k dialup. The difference was astounding enough for me to be able to use a 1024x768x32bpp at a superb speed.
Under *nix-type systems, you can enable the "tight" encoding from the viewer command line. I’m not a Windows user, so I can’t tell you where it is in the GUI version, but from the commandline:
$ xvncviewer -encodings tight -quality 0 <hostname:port>
This will produce noticeable JPEG compression artifacts, but your session will be faster if you’re over a low-bandwidth network.
There is, lastly, one more VNC in the pipeline. Tridia VNC (http://www.tridiavnc.com/) supplies a server with the "tight" encoding for low-bandwidth networks, and also wraps the connection in an SSL tunnel, so you get the benefit of an encrypted connection as well. Worth a look at.
Oh, and whilst you’re playing with VNC, take a look at krfb (http://www.tjansen.de/krfb/). I don’t know if it’s reached FreeBSD ports, but it’s definately got prospects. Being able to use a proper XFree86-accelerated desktop locally, and still be able walk away and pick up that same session remotely has great benefits.
I usally just create an sshtunnel from whereever i am at the time with compression enabled and then run tightvnc server at home.
Connection at home is 2.5/0.7 so i just disable compression in the vnc and live with the sshtunnel compression this works great for me..
Oviously you could go with sshtunnel comperssion + tightvnc comperssion + jpeg if you like to dont know if this help that much tough, i feel a slight "lag" when i tried with all that so i just stick to my sshtunnel 🙂
It’s a question of time and it is some kind of magic on the waves I have been trying vnc lately but I’ve compiled it from a tarball, well what about to make the corrections on the wrapper of the Xvnc that’s it on the vncserver? It’s better or worse to do in this way changing the depth and the geometry or the line that says uname -a? usually it reports errors and it is better to change it to localhost directly, you know not everybuddy has the same gear and VNC is the unique experiment on net that can be made whitout it, ah! usually people changes the localhost in your /etc/rc.conf and writes a fancy name, a solution can be done changing the line uname by localhost. I’ve tryed depth 24 and it works very well except if I use svncviewer it only admits a depth of 8 what I surmise that is due to the SVGAlib. 😉 Ximo
And the most fun is viewing your FreeBSD desktop on windows, and then running vncviewer from X and viewing your windows desktop…the picture goes ad infinitum(er, rather, till the last pixel in the corner).
Amazingly, this didn’t crash anything or even use a massive amount of bandwidth(compared to normal vnc use.)
Why not install an X-Server on your local windows server, use SSH to FreeBSD server and export the Display? How does this differ than TightVNC? Not to say this isn’t a correct way just wondering on alternatives, i’m new to the BSD world and learned how to export applications including KDE.
cos who wants to install cygwin or pay heaps of money for an x-server on your local windows server
Just a warning to those that don’t already know X as I didn’t. The TightVNC port doesn’t list the XFree86-4-clients as a dependancy but it is in that xauth which is needed for passwords and so on, is supplied by this port.
Cheers,
GregMo
Oh, something else, you just have to love FreeBSD! I got this running on my pitifull box. My FreeBSD box is a p75 with 16mb of ram. Show me a redhat box that will even install on 16mb 😉 Now, I do have more memory to put into this machine, but not going to till I have no other choice but to reboot given my beaut of an uptime 🙂
root@dimensions:/usr/X11R6/bin# uptime
9:49AM up 279 days, 6:47, 4 users, load averages: 0.01, 0.08, 0.18