iXvnc patch for VNC X-Server (Xvnc)

Warning 1: this patch is no longer required because is included in the original sources of the current releases.
Warning 2: this option is useful only if you want to use XDM to start the user sessions (otherwise you get just a gray screen) , check the xdm man pages.

Goal

I wasn't able to convince my users to start their own Xvnc before using the viewer, so it must start on demand. With this patch you'll be able to use inetd to launch Xvncs as clients connect.

To achieve this we've made some minor changes for Xvnc to support the new -inetd command line option.
If -inetd option is not used then Xvnc should work as usual and can be started by the vncserver perl script provided with Xvnc.

This patch was designed to minimize changes to the original source code, currently only two files are patched (init.c and sockets.c).

Features (-inetd option):

Doesn't listen for connections of any kind (http included).
Receives a connected socket from inetd and uses these client connection.
Finds a free display number and uses it.
If connection is gone then terminate Xvnc
Logging to /usr/adm/Xddmsgs

How to:

Suppose you have the Xvnc source. Would be better to compile it first (just to be sure its ok).

Get the appropriate patch file (check "Change Log"):

Newer releases of Xvnc	No patch required, -inetd option included in original source.
Xvnc version 3.3.3	18062000 - ixvnc3b.tgz (10 Kb) 18062000 - ixvnc3b.patch.tgz (1 Kb) 20091999 - ixvnc3a.tgz (10 Kb) 18091999 - ixvnc3.tgz (10 Kb)
Xvnc version 3.3.2 R3	12031999 - ixvnc.tgz (16 Kb)

Go to vnc directory in your source tree (.../Xvnc/programs/Xserver/hw/vnc)

Untar the TGZ file(*)
WARNING !!!! - this will overwrite some files, if you which backup first.
Rebuild (and that's it)

(*) Now you can also use the patch versions, untar the ixvncXX.patch.tgz file and then, in the vnc directory, use the patch command (patch < ixvncXX.patch).

Installing/Using

New entries are required in /etc/services and /etc/inetd.conf.

/etc/services

In this file the new services must be defined: service-name port-number/protocol. In our case we want to give users several options about geometry's and depths so my file has this lines (you may want just one):

vnc-640x480x8	5950/tcp
vnc-800x600x8	5951/tcp
vnc-800x600x16	5952/tcp

On the client side this means displays :50 :51 and :52. The display number used by Xvnc won't be the same; with -inetd option an available display number will be searched and used.

/etc/inetd.conf

In this file you must add the lines to launch Xvnc, in my case the basic options are:

vnc-640x480x8	stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -broadcast -once -geometry 640x480 -depth 8
vnc-800x600x8	stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -broadcast -once -geometry 800x600 -depth 8
vnc-800x600x16	stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -broadcast -once -geometry 800x600 -depth 16

You must add other command line options required for your local configuration, namely -fp.

As you can see Xvnc will run as nobody (check if that's ok for your local configuration). Any number of clients may connect to :50 :51 or :52, inetd will launch a Xvnc for each. You may use any Xvnc options (some systems may restrict the number of command args in inetd.conf) but don't forget -inetd -broadcast -once, of course -broadcast can be replaced by -query {hostname}.

After changing these files you must send a HUP signal to inetd process (or reboot).

Other points

To support the Java client, just serve the applet from a standard httpd (must be on the same machine as Xvnc) directed to the appropriate host/port. Even if one is not required, the VNC viewer applet always asks for a vnc password, changing this requires major rewriting of the applet. Anyone interested?
As pointed out by Laurent Bardi allowing or denying IP clients access it's now easy. Just check "man tcpd".
By using VNC this way some interesting features are lost, namely being able to keep Xvnc server running while connecting and disconnecting as you need and sharing the desktop. Adam Nevins said keeping those features would be nice, to be able to do so, something like a self-generated password would be required. Other ideas?

Change Log

12-03-1999 ixvnc.tgz	For Xvnc version 3.3.2 R3, patched files are: init.c sockets.c rfbserver.c
18-09-1999 ixvnc3.tgz	Just adapting to Xvnc version 3.3.3, and minor changes: only two patched files are required now (init.c sockets.c). Instead of searching a free display up, starting at 0, search is now down, starting at 99.
20-09-1999 ixvnc3a.tgz	Logging support added/Bug removed - iXvnc now closes handle 2 (stderr), the X-server stuff detects this and will write logs to file /usr/adm/Xddmsgs (where dd is the display number). Of course this only works if the user id used by Xvnc has the right permissions there. Logging is most useful for trouble shooting, I hope it won't be used too often, when something goes wrong just check the log file.
18-06-2000 ixvnc3b.tgz ixvnc3b.patch.tgz	Now TCP port number (6000+display) is checked, this should solve the problem of systems where the X-Server locking mechanism is not used (HP-UX). I don't have any HP-UX around to test, i hope this will solve the problem. There is now a diff version of the files.

BUGS and Problems

Because with iXvnc display numbers will be locked without using the corresponding vnc ports, if you also use the vncserver script you may expect it to issue warning messages about this fact.
Before executing Xvnc inetd closes handles 0, 1 and 2 and then copies the connected socket to these handles. This means stdin, stdout and stderr are all directed to the tcp connection.
Before version 3a iXvnc patch removes all vnc logs and error reporting that are normally directed to stderr. However it does not remove the X-Server error logs. If there is an error in X-server stuff the error message is written to stderr and will produce fatal effects. If you get something like "invalid protocol", "invalid rfb server" or "unknown message" on the vncviewer this probably means some error has occurred and an error message was written on stderr. If this happens when you connect you can get the error message by using a telnet client directed to the vnc port.
This patch searches for a free display the same way the vncserver perl script does, however that isn't correct. The lock file should be created on the search and not when the X server starts afterwards (when two or more searches take place at the same time it's easy to guess what may happen).
Gray screen this is the most reported problem, however it's not a VNC problem. If you get a gray screen and nothing else then you probably don't have a XDM server running on your network. You should setup one, when this is done, you will get a nice login window on your gray screen. Check xdm man pages (on the unix shell run: man xdm). Recente desktop environements carry specific XDM servers, like KDM for KDE and GDM for GNOME.

asc@isep.ipp.pt
http://www.dei.isep.ipp.pt/~asc
Departamento de Engenharia Informática (DEI)
Instituto Superior de Engenharia do Porto (ISEP)
Instituto Politécnico do Porto (IPP)

Rua Dr. Bernardino de Almeida 431
P-4200-072 PORTO, Portugal