Linking VNC to XDMCP

In order to simplify the VNC login procedure and eliminate the need for users to explicitly configure and launch the VNC server, you may want to link VNC to XDMCP. In this configuration, the VNC server's built-in X server contacts the computer's own XDMCP server to present a GUI login prompt using the VNC link to the VNC client. This configuration obviates the need to use a VNC-specific password or user configuration, but it poses certain challenges. Most importantly, you as a system administrator must link these components together. Doing so requires some effort, but it's effort that's well spent for a multiuser system.

To begin, review the earlier section, "Using X via an XDMCP Server." You must configure your XDMCP server to accept remote logins. One minor modification to the configuration described earlier is possible and even desirable, though: You can use the Xaccess control file (for XDM or KDM) or packet-filter firewall rules to block access to the XDMCP server and prevent it from accepting connections from anything except the localhost interface (127.0.0.1). Doing so can improve security by limiting the ways into the computer.

Once you've configured the XDMCP server, you must tell the VNC server to run in an unusual way. Rather than launch the server via the vncserver script, you configure it to run via your super server. The first step in doing this is to create an entry in /etc/services for the VNC service, which normally runs on a port between 5900 and 5999—port 5900 corresponds to VNC session 0, 5901 is VNC session 1, and so on. You can use a single port, or you can assign different ports to different functions. For instance, you might use two ports, one for 760 x 530 virtual desktops and another for 950 x 700 virtual desktops. Adding the following lines to /etc/services will do this job:

vnc-760x530 5900/tcp vnc-950x700 5901 /tcp

After you've done this, you must create a super server configuration to pass VNC logins onto the VNC server, Xvnc. This configuration must pass any options to the server that it needs in order to operate at the appropriate resolution, color depth, and so on. For instance, the following /etc/inetd.conf entry works on a Debian system:

vnc-760x530 stream tcp nowait nobody /usr/sbin/tcpd /usr/X11 R6/bin/Xvnc :1 *-inetd -query localhost -geometry 760x530 -depth 24 -once -fp */usr/X11 R6/lib/X11/fonts/Type 1 ,/usr/X11 R6/lib/X11/fonts/misc, */usr/X11 R6/lib/X11/fonts/75dpi,/usr/X11 R6/lib/X11/fonts/100dpi

This entry is extraordinarily long because of the large number of options passed to Xvnc. In reality, it should all go on one line in your inetd.conf file. The options include:

:1 This option tells the server to use X session 1. (The local X server's session number is 0.) If you run VNC on more than one port, you must use a different X session number for each VNC session.

-inetd This option tells Xvnc that it's being run via a super server.

-query The -query localhost option tells the X server side of Xvnc to contact localhost for an XDMCP login prompt. You can also use the -broadcast or -indirect hostname options, as described earlier, in "Using an XDMCP Client."

-geometry This option sets the size of the virtual desktop that VNC presents to clients. It can be just about anything you like, although geometries that are too large or too small aren't likely to be useable.

Tip You may want to use a geometry that's slightly smaller than a typical screen resolution. This will enable you to run a VNC window that nearly fills a client's screen without requiring the user to scroll to see elements along the edge of the virtual screen.

-depth This option sets the color depth used for transfers between the VNC server and client. In practice, 24 usually works well, but you can try other values, if you like.

-once This option tells Xvnc to quit once the connection is terminated.

-fp You set the font path with this option. On most systems, the font path will be quite lengthy, as in this example. You can copy the font path from your XF86Config file, except for the fact that Xvnc requires its font path to be on a single line, with each element separated by commas. Xvnc is very finicky about its font path, so if you have problems, this is one of the first features you should investigate.

As with most servers, Xvnc supports additional options that I don't have space to describe. Consult the Xvnc man page for information on these parameters.

If you run Mandrake or Red Hat, you must create a xinetd configuration that's equivalent to the preceding inetd.conf line. For instance, the following /etc/xinetd.d/vnc file works in Red Hat:

service vnc-760x530

disable = no socket_type = stream protocol = tcp wait = no user = nobody server = /usr/bin/Xvnc server_args = :1 -inetd -query localhost -geometry 760x530 -depth 24 *-once -fp unix/:7100

This configuration is almost exactly equivalent to the /etc/inetd.conf entry presented earlier, except for the font path. Red Hat uses a local font server to handle its fonts, so you can pass a pointer to that server (unix/:7100) as the font path. Mandrake's configuration is similar, except that the font path specification should be unix/:-1.

Once you've reconfigured your super server, tell it to reload its configuration file by typing killall -HUP inetd or killall -HUP xinetd. You should then be able to use a VNC client to access the relevant port. The vncviewer program won't prompt for a password; instead, you'll see an XDMCP login screen, as shown in Figure 26.8. You can enter your username and password and log in, selecting the environment you want to run.

Figure 26.8: Linking VNC to XDMCP gives you a traditional Linux GUI login over VNC. Note Each XDMCP server has its own unique look, and most distributions customize their XDMCP login screens. For this reason, your login screen probably won't look exactly like Figure 26.8, which shows KDM from KDE 3.1 running on Debian GNU/Linux 3.0.

Figure 26.8: Linking VNC to XDMCP gives you a traditional Linux GUI login over VNC. Note Each XDMCP server has its own unique look, and most distributions customize their XDMCP login screens. For this reason, your login screen probably won't look exactly like Figure 26.8, which shows KDM from KDE 3.1 running on Debian GNU/Linux 3.0.

Using XDMCP in conjunction with VNC gives the user what appears to be a single-protocol GUI login tool. Users needn't log in with SSH or Telnet prior to making the VNC or X connection, and a single VNC session number works for all users. If you want to support multiple virtual desktop sizes, you assign one to each VNC session number. When users log out, their sessions are closed, so you lose the persistence feature of conventional VNC logins.

0 0

Post a comment