XVNC Server

Xvnc is the X VNC (Virtual Network Computing) server. It is based on a standard X server, but it has a "virtual" screen rather than a physical one. X applications display themselves on it as if it were a normal X display, but they can only be accessed via a VNC viewer.

To the applications it is an X server, and to the remote VNC users it is a VNC server. By convention the Xvnc developers have arranged that the VNC server display number will be the same as the X server display number, which means you can use eg. snoopy:2 to refer to display 2 on machine "snoopy" in both the X world and the VNC world.

Preinstall
First of all, you should decide which version of VNC you'd like to use. RealVNC isn't really recommended - TightVNC is more secure and efficient. XF4VNC should be more efficient and secure than RealVNC as well, and also support GLX extensions, which TightVNC does not.

You may find that you need to make a link to the fonts directory in order for the Xvnc server to work (This will also work for realvnc):

and also:

The server portion of VNC is controlled by the server USE flag, so you'll want to enable this for the appropriate package. You can do this by adding it to with, for example if you're going to use RealVNC:

Newer gentoo installations from scratch are missing the /usr/X11R6 -> /usr symbolic link, which is only a workaround for "old" software relying on monolithic X11. (see Gentoo Desktop Installation guide for more info). So if TightVNC / RealVNC complain about not finding some fonts under /usr/X11R6/lib don't forget to:

Install
For RealVNC:

For TightVNC:

Server password
Once finished, this should give you four vnc-related programs, including vncconnect, vncpasswd, vncserver, and vncviewer.

Now, wasn't that easy? We're not quite there yet, but you can easily test out your new VNC installation by starting your vnc server. You will be asked to enter a password for vnc viewer clients to authenticate themselves by, so go ahead and enter that and verify it. Next, you will be asked to enter a password for "view only" clients, meaning that they can see the desktop but cannot interface with it. Great for demonstrations! After you have gone through the password process, vncserver will finish initializing.

Here's what you'll see:

Simple testing
With that done, test out the VNC server!

This will open up a 800x600x24bit client. What you'll see is one very ugly desktop! But it's a start, and it proves that you're one big step closer to remote desktop. If you want another resolution or color-depth, just use the two last number shown in the services file.

Remember to route ports (5950-5954, 5960-5964, 5970-5974, 5980-5984) for external access. (You must configure your router/firewall, which is very individual depending on what kind of configuration you have)

If you are connecting from a windows box just open the Tightvnc viewer dialog and make sure you append the :1 to the end of the IP.

If you want a fully featured desktop when you login, you can choose the startup programs in {Path|~/.vnc/xstartup}}. You can remove the 'xterm' and 'fvwm' programs and add 'kwin & startkde' for the K Desktop.

Here's what worked for me with gnome.

xstartup has to executable, so you may need set permissions if you deleted the initial file:

Xinetd
Xinetd is used to automatically launch vncserver upon a vncviewer call from an external client.

There are several ways to allow xinetd to listen to external calls, here are some examples:

To open connections to all edit and put a # in front of the line: (you can also remove the line completely)


 * 1) only_from = localhost

If you only want access from internal hosts you can list them:

only_from = 192.168.0.1 192.168.0.2

For one interface to listen you can specify that interface's IP:

bind = 192.168.0.1

Warning: The top example allows any and all hosts from the outside to connect.

Add services
Edit these 2 files:

Create if it does not exist already. Warning: Make sure your editor (such as nano) does not wrap any of the long lines. If it does you will get connection refused errors. See: TIP Nano No Auto-wrap

Note: TightVNC users!

As you can see, we use the nobody user to open a vnc session and -SecurityTypes=None to make VNC allow connecting without a password, only use -SecurityTypes=None if using RealVNC as TightVNC does not support this option! '''TightVNC Xvnc will refuse to start if -SecurityTypes=None is present. Remove it!'''

Let's do the next step, configure the login manager. Once connected, the user will authenticate in your chosen login manager and the chosen session will be launched.

IF you want to allow anonymous logins, the user nobody must have a valid shell assigned when using the login manager. You will only get a gray screen when connecting if nobody has the default /bin/false set.

If you use kdm, no modification is required to the user nobody.

You might want to make sure you have XSESSION set. This is for KDE use xdm | gnome accordingly.

OR for gnome:

You also might need...
When using xinetd and vnc server with above config you might get error: Abnormal termination of greeter for display your.host.name:83, code 1, signal 0 XDMCP socket creation failed, errno 97

This is due to default user being nobody (in xinetd config) and default behaviour of vnc to disallow connections if there is no password set. To fix this: vncpasswd /path/to/dir/vncpass -rfbauth /path/to/dir/vncpass So that example line in xinetd should look like: server_args = -inetd -query localhost -once -rfbauth /path/to/dir/vncpass -geometry 1280x1024 -depth 32 Someone might want to update above section. Hope it helps.
 * Create file with password somewhere on your filesystem:
 * Change permissions to file created above so that user nobody has access to it (chmod/chown)
 * Add parameter to each server_args entry in xinetd, so that vnc uses abovementioned file. Parameter is:

xdm
These changes are only required if your display manager is XDM. If you use GDM or KDM, see the next sections.

Open with your favorite editor.

Look at the last line : "DisplayManager.requestPort: 0"

Comment it out by inserting a ! at the beginning of the line.

Edit and uncomment the line " '* #any host can get a login window" by removing the single quote. You could also change it to 192.168.0.* for some security

kdm
edit (or /usr/kde/3.?/share/config/kdm/kdmrc /usr/share/config/kdm/kdmrc) and enable XDMCP on port 177

File: /usr/kde/3.?/share/config/kdm/Xaccess


 * CHOOSER BROADCAST  #any indirect host can get a chooser

or

192.168.0.* # hosts allowed are from the network 192.168.0

gdm
start gdmsetup and go the tab "Security" Make sure 'Enable XDMCP' is checked.

Alternately, edit /etc/X11/gdm/gdm.conf File: /etc/X11/gdm/custom.conf

Set access
To prevent a problem where you can log in, but then only get a blank screen, edit /etc/security/pam_env.conf and make sure the following lines ARE COMMENTED (have # in front): File: /etc/security/pam_env.conf


 * 1) REMOTEHOST    DEFAULT= OVERRIDE=@{PAM_RHOST}
 * 2) DISPLAY       DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
 * 3) XAUTHORITY    DEFAULT= OVERRIDE=@{XAUTHORITY}

Restart services
Note : Restarting xdm will end your X session

/etc/init.d/xinetd restart /etc/init.d/xdm restart

Tunneling through SSH
I use VNC over SSH to connect to computers at my local uni where the Cisco sniffers drop any sort of VNC packets (no matter what the port).

1) start vncserver on the host 2) on the client do: ssh -f -N -L localPort:vncServer:vncServerPort username@vncServerPort Note: (Should that be

ssh -f -N -L localPort:vncServer:vncServerPort username@vncServer

-MJL)

-f     Requests ssh to go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background. This implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm. -N     Do not execute a remote command. This is useful for just forwarding ports (protocol version 2 only). -L     [bind_address:]port:host:hostport

Rather than duplicate information (and to credit the original author), I will link to This page:

http://pigtail.net/LRP/vnc/ (this page is for windows). [edit] Additional notes for AMD64 users Note: I have had no problems TightVNC version 1.3.9 on my amd64 system. Any previous issues seem to have been resolved.

For now tightvnc seems to segfault when compiled for x86_64. If you really want to get it running on amd64, you might carefully try this:

Set up a 32bit chroot environment as explained in http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2 and then compile tighvnc static for 32bit

echo "net-misc/tightvnc static" >>/etc/portage/package.use emerge tightvnc quickpkg tightvnc

copy the package to /usr/portage/packages/All and install it on the 64bit system.

echo "net-misc/tightvnc ~amd64" >>/etc/portage/package.keywords emerge tightvnc --usepkg -pv emerge tightvnc --usepkg

At least this works for me. [edit] Having Troubles? Get Xvnc to write a log

Create the directory /usr/adm and chmod adm so that the user nobody will have write permission. Xvnc started with -inetd option will create logs there.

From --> http://www.dei.isep.ipp.pt/~andre/extern/ixvnc.htm

Issues
After upgrading to Gnome 2.16 I was having an issue after connecting to a VNC session. The window decoration was properly drawn, however, the internal widgets were not using the correct theme. Additionally, there were error messages indicating that certain icons could not be found, and that gnome-settings-daemon could not start properly. After some digging, was able to fix this by modifying my ~/.vnc/xstartup to change how it invoked gnome-session.

The following is my working xstartup: