X – Window system is a network-transparent window system. X11 server is the display server that manages the output on the bit-mapped display hardware. An application (or client) does the work and sends requests to the X11 server, or simply, the X server for display. The client application and the X server are usually located on the same host computer. However, the client and X server can be located on different hosts on a network. That is, an X application running on a host on network can display output on an X – window on some other host, also, on the network, provided the host running the application has been configured for remote login. So if you wish to use the capabilities of desktop or laptop computer from a netbook, you can configure the desktop or laptop computer as client and the netbook as the display server and run programs on the desktop or laptop computer from the netbook and get the graphical display outputs on the netbook.
Figure 1: Remote display with the X-Window System
X DISPLAY MANAGER
X Display Manager is the server program that facilitates a user’s login into a system. It manages the login procedure, starts the X server, and does some other miscellaneous jobs. The X Display Manager is implemented as XDM (the default), KDM (under KDE) and GDM (under GNOME). In the rest of this tutorial we will use the term GDM for XDM.
GNOME DISPLAY MANAGER (GDM)
In the case of remote display, an application runs on the local machine and the X server runs on the remote computer. Thus the windows and outputs come on the remote machine. That is, the end-user is at the remote machine. Here, we are talking from the point view of the application. Hence, the machine where application is running becomes local
and the other
machine on the network, where the user is sitting becomes remote
. To get to this configuration, the (remote) user has to login to the local machine. For the login, GDM becomes the application
running on the local machine.
GDM comes in two personalities. The first is the GDM daemon, who is the big boss and takes care of communication and creation of slave GDM processes, one for each display. The second is the GDM slave process. The GDM slave process is responsible for handling the login procedure. It creates a process gdmgreeter which displays the login dialog to the user. After the login is complete, the GDM slave process starts a session (x-session-manager) for the user.
X DISPLAY MANAGER CONTROL PROTOCOL (XDMCP)
By default, the GDM slave process starts an X server with a command like,
/usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
Of particular interest to us is the option -nolisten tcp. It simply means that the TCP/IP connections have been disabled for this X server. The X server on the remote machine and the GDM on the local machine communicate as per the X Display Manager Control Protocol (XDMCP). In order to access the local machine, the user on the remote machine indicates to its GDM slave process that access to some other machine on the network is desired. The current GDM slave process and the associated X server take leave (are terminated) and are replaced by a new set. The new GDM slave runs a process called gdmchooser, which lets the user choose the machine on which login is desired (local
machine, in our terminology). The user chooses the local
machine. The GDM slave and X server get replaced once again, and the new X server has been invoked with a command like,
/usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -terminate -query flute.local vt7
The -terminate option causes the X server to terminate itself at server reset. The -nolisten tcp option in previous invocation has changed to -query flute.local. The user has apparently chosen the host flute.local for login. The -query tells the X server to send query packets to this host for finding its willingness to accept subsequent login request packets. Further packets get exchanged between the X server and the local
GDM and if all goes on well, the authentication is successful and a session starts for the remote X server on the local machine.
SETTINGS (UBUNTU 9.04, JAUNTY JACKALOPE)
If you are using Jaunty, the settings can be done as follows:
The only settings that need to be configured are on the local
machine. On the local machine, run the gdmsetup program. The gdmsetup program can be run with super-user privileges as
sudo gdmsetup
or,
System -> Administration -> Login Window
Once the Login Window Preferences window is displayed, select the Remote tab. Select Style as Same as Local
. And, in case the remote machine’s screen shows icons and text upside down, try disabling the proprietary graphics display drivers on the local machine and see whether it helps.
REMOTE LOGIN IN UBUNTU 9.10 (KARMIC KOALA)
GDM based remote login in Karmic can be done as follows:
First, setup GDM in the local machine.
cd /etc/gdm sudo cp /usr/share/doc/gdm/examples/custom.conf .
Edit the custom.conf file such that there is an entry Enable = true just after the line [xdmcp]. For example,
# GDM configuration storage [xdmcp] Enable=true [chooser] [security] [debug]
Then, from the remote machine give the command,
sudo xinit -- :1 -query 192.168.1.100
where, 192.168.1.100 is the IP address of the local machine. You may replace 192.168.1.100 by the actual IP address of the local machine in your setup. This should start one instance of the X-server on the remote machine, giving access to the local machine to the (remote) user. The user can go to the X-server for his or her machine by pressing CTRL-ALT-F7, and, go to the X-server for the other machine by pressing CRTL-ALT-F9.
SECURITY CONSIDERATIONS
The authentication information is communicated in plaintext between the remote and local hosts. So if there is a possibility of snooping, the login information is openly available and the system becomes vulnerable to attacks. For this reason, GDM based remote access may be OK in small LANs but it is not a good idea to enable remote login on host accessible on the Internet. A better option is to execute an X application using tunnel provided by the secure shell, SSH.
SSH TUNNELING
We continue to use the terminology defined earlier, using the term local machine
to mean the host running the X application and the remote machine
to mean the host running the X server and providing display to the remote user. The secure shell server should be installed on the local machine. The secure shell client should be available on the remote machine. Or, to put it simply, the secure shell package should be installed on both the local and remote machines.
On the local machine. go to directory /etc/ssh and open the file sshd_config in a text editor. Go to the line containing the text X11Forwarding. Change it to,
X11Forwarding yes
Save the file sshd_config, Restart the sshd daemon.
RUNNING AN X-APPLICATION WITH SSH TUNNELING
On the remote machine, run the secure shell client as,
ssh -X user@host
The -X option enables X11 forwarding. Now you can execute an X-application from the SSH terminal window and the graphical output should come on the remote machine’s display.
REFERENCES
1. Jiri (George) Lebl, Using and Managing GDM
.
2. Keith Packard, X Display Manager Control Protocol, Version 1.1
, The Open Group.
