Configuring VNC
From Crashcourse Wiki
(NOTE: This page is under construction since it's a rewrite of the initial VNC page and, when it's finished, it will replace that earlier page.)
Contents |
Overview
This recipe shows how to install, configure and use VNC in a very basic way between a couple of Fedora systems, followed by a number of more advanced tricks you can play with. While I'll restrict this discussion to Fedora, it should be easy to see how it generalizes to other Linux systems (and even Windows machines).
The package installation
Install the necessary software:
# yum install vnc [on the client side] # yum install vnc-server [on the server side]
It might be worth briefly examining the contents of those packages, just so you can appreciate what's being installed. The vnc package contains little beyond the client-side viewer program:
$ rpm -ql vnc /usr/bin/vncviewer /usr/share/applications/vncviewer.desktop /usr/share/doc/vnc-4.1.2 /usr/share/doc/vnc-4.1.2/LICENCE.txt /usr/share/doc/vnc-4.1.2/README /usr/share/icons/hicolor/16x16/apps/vnc.png /usr/share/icons/hicolor/24x24/apps/vnc.png /usr/share/icons/hicolor/48x48/apps/vnc.png /usr/share/man/man1/vncviewer.1.gz $
The server package is only moderately more involved, and we'll discuss some of that content later:
$ rpm -ql vnc-server /etc/rc.d/init.d/vncserver /etc/sysconfig/vncservers /usr/bin/Xvnc /usr/bin/vncconfig /usr/bin/vncpasswd /usr/bin/vncserver /usr/bin/x0vncserver /usr/lib64/xorg/modules/extensions/libvnc.so /usr/share/man/man1/Xvnc.1.gz /usr/share/man/man1/vncconfig.1.gz /usr/share/man/man1/vncpasswd.1.gz /usr/share/man/man1/vncserver.1.gz /usr/share/man/man1/x0vncserver.1.gz /usr/share/vnc /usr/share/vnc/classes /usr/share/vnc/classes/index.vnc /usr/share/vnc/classes/logo150x150.gif /usr/share/vnc/classes/vncviewer.jar $
Preparing the server system
If you're running a firewall on the server, make sure you allow incoming access to port 5901, which is where the vncserver program will be listening by default.
In addition, create the same (non-root) user account on both systems, which will represent both the account you're viewing from on the client side, and the account running vncserver on the server side.
NOTE: If you have only one Fedora system, you can probably treat that machine as both the client and server system, in effect VNC viewing to yourself as a learning experiment. Also note that you can do the vast majority of what follows as a regular user.
The recipe -- unannotated version
As a quick start (and without offering any explanations yet), you can see if VNC works as follows. First, log in as the same (non-root) user on both systems. (For the rest of this recipe, assume that the client and server systems have IP addresses 192.168.1.100 and 192.168.1.200, respectively.)
On the server side, start the VNC server thusly (and, assuming it's the first time you've ever invoked vncserver on that system, you'll be prompted for a VNC password):
$ vncserver You will require a password to access your desktops. Password: XXXXXXXX [some VNC password you make up on the spot here] Verify: XXXXXXXX New 'localhost.localdomain:1 (rpjday)' desktop is localhost.localdomain:1 Starting applications specified in /home/rpjday/.vnc/xstartup Log file is /home/rpjday/.vnc/localhost.localdomain:1.log $
Once that's done, on the client side, fire up a corresponding VNC viewer to contact the server (during which you'll need to type the VNC password you invented above):
$ vncviewer 192.168.1.200:1
and you should have a generic and somewhat boring TWM-based VNC session to the server. Wasn't that easy?
To shut down, on the client side, just kill the VNC client window. However, as long as you leave the vncserver program running on the server system, you can reconnect whenever you want. And to finally kill the listening VNC server, just type (on the server side, of course):
$ vncserver -kill :1
Piece of cake, no? And if that's all you really needed, well, you can stop reading. But, of course, it gets so much better.
NOTE: If you want to wipe out any history of vncserver running as that user on the server system, just remove that user's home directory of .vnc so that, the next time you invoke vncserver, you'll once again be prompted for a VNC password for that user account.
The recipe -- annotated version
For those who want to see what's happening behind the scenes, we'll do the same recipe again, and explain what to look for at each step to verify that things are working properly. This will also make it easier to check the more advanced VNC-related things you can do later.
Once again, on the server system, start the VNC server with:
$ vncserver
and let's examine the results.
First, the initial invocation of vncserver should create the hidden directory ~/.vnc with contents similar to:
$ ls -l .vnc total 16 -rw-rw-r-- 1 rpjday rpjday 519 2008-01-07 08:33 localhost.localdomain:1.log -rw-rw-r-- 1 rpjday rpjday 4 2008-01-07 08:33 localhost.localdomain:1.pid -rw------- 1 rpjday rpjday 8 2008-01-07 08:33 passwd [stored VNC password] -rwxr-xr-x 1 rpjday rpjday 334 2008-01-07 08:33 xstartup [initial client setup]
Next, you can verify what's now running on the server side related to VNC with:
$ ps aux | grep vnc
rpjday 16742 0.0 1.0 44972 4468 pts/4 S 13:59 0:00 \
Xvnc :1 \
-desktop localhost.localdomain:1 (rpjday) \
-httpd /usr/share/vnc/classes \
-auth /home/rpjday/.Xauthority \
-geometry 1024x768 -depth 16 -rfbwait 30000 \
-rfbauth /home/rpjday/.vnc/passwd -rfbport 5901 -pn
rpjday 16746 0.0 0.3 35916 1544 pts/4 S 13:59 0:00 vncconfig -iconic
...
What you can see from the above is that:
- there is now an Xvnc VNC server program running,
- that server program is considered to be associated with display ":1",
- it's using as an access password the password that's now saved in your personal VNC ~/.vnc/passwd file, and
- it's listening for incoming viewer requests on port 5901
If your output doesn't resemble the above, you should figure out why.
And, finally, you can also use netstat to verify the listening port of 5901:
$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN ...
Again, if vncserver is running, you should definitely see a line like the above in the output of netstat. Later, after you connect with a VNC viewer, you should see something like:
$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN ... tcp 0 0 192.168.1.200:5901 192.168.1.100:51504 ESTABLISHED ...
And, finally, you can shut down the client and server and see that all of the above has gone away.
Customizing your VNC session
The look and feel of your VNC viewer session is controlled on the server side by the file ~/.vnc/xstartup belonging to the user to whose VNC server you're connecting. Initially, that file contains something similar to:
#!/bin/sh # Uncomment the following two lines for normal desktop: # unset SESSION_MANAGER # exec /etc/X11/xinit/xinitrc [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources xsetroot -solid grey vncconfig -iconic & xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & twm &
Note that last line, which means you'll be running the generic and unexciting TWM window manager. If you want to experiment, try installing other window managers on the server side, such as fluxbox:
# yum install fluxbox
then shut down the VNC server, edit that file to invoke "fluxbox" instead of "twm", restart the VNC server, and invoke another viewer session.
If you're feeling ambitious, follow the comments at the top of that file to get a normal, server-side, user desktop.
Advanced VNC
Multiple users and multiple vncservers
Since a single non-root user can start a vncserver, it only makes sense that different non-root users can all start their own vncservers, and will all have their own .vnc directories keeping track of their own VNC password.
By default, listening ports and display numbers will be handed out in order depending on the order of starting those servers -- :1 and 5901, :2 and 5902, and so on. And clients will connect based on the display number of that user's vncserver:
$ vncserver 192.168.1.200:2
Just as obviously, since each user has his or her own personal .vnc directory, each of them can customize their VNC xstartup file however they choose.
Using the Java-based VNC client
If you don't have an actual VNC viewer installed on your system, you can still use a Java-based viewer available to your browser. After you start the VNC server, you can see the collection of listening ports corresponding to that server (assume normal VNC server at display :2 listening at port 5902 for this example):
$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State ... tcp 0 0 0.0.0.0:5802 0.0.0.0:* LISTEN ... tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN
Note the associated lower port number of 5802, which you can use if you want to use the Java-based viewer in your browser, by browsing to 192.168.1.200:5802. After that, the authentication works exactly as you've already seen.
For security reasons, you may not want to allow this browser-based access, and you can prevent it by starting that particular VNC server with the "-nohttpd" option.
Running vncservers automatically
Rather than manually invoking vncservers for a number of users, you can simply enter the appropriate information into the system-wide file /etc/sysconfig/vncservers, as in:
VNCSERVERS="1:rpjday 2:fred" VNCSERVERARGS[1]="-geometry 800x600" VNCSERVERARGS[2]="-geometry 1024x768"
You can then manually start and stop the VNC servers with the service command, and enable or disable their automatic operation with the chkconfig command.
(You might also check the man pages for vncserver and Xvnc to see all of the possible invocation options.)
Tunneling VNC through ssh
To make a long story short, if you want a secure connection, you can tunnel your VNC session through SSH using the "-via" option:
$ vncviewer -via localhost 192.168.1.200:1
If you want to enforce the use of SSH tunneling, simply start the respective VNC server with the "-localhost" option.
Native X display support
If you actually want control of the native X server (display :0) on the remote host, there are two ways to do it.
x0vncserver
The first technique to get remote control of the display is via the program x0vncserver, available in the vnc-server package.
On the server side, invoke x0vncserver with a mandatory password file, as in:
$ x0vncserver PasswordFile=/home/rpjday/.vnc/passwd main: XTest extension present - version 2.2 main: Listening on port 5900 ...
Subsequently, on the client side, you'll need to connect to that exact port:
$ vncviewer 192.168.1.200::5900
at which point, you should have remote control capability. I'm sure there's more you can do with this feature, but the above seems to work.
The vnc.so module
If you have access to configuring the X server, a superior technique is to use the vnc.so module, explained [here]. I'll fill this in later after I've had a chance to test it.
Feedback to rpjday@crashcourse.ca.
Return to Fedora_Cookbook.
