Linux in Academic Labs Revisited

by Salvador Peralta

In this article, I would like to revisit the idea of maintaining academic computing labs from the perspective of a case study implemented at the Mark O. Hatfield Library at Willamette University. In our case, we use an X-based client server model for maintaining an internally consistent, standardized software model in an academic lab with a heterogenous PC hardware environment.

The Hatfield Library is an undergraduate research library based at Willamette University in Salem, Oregon. The library's Systems Division is responsible for maintaining labs that service a wide range of client constituencies. We support a public computing environment for accessing library services, such as catalog and journal databases (OPAC); workstations for library staff and student workers; a student computing lab; and an instructional lab.

Due to budget constraints, the library's instructional lab traditionally has been the location where PC hardware--staff machines removed from service and antiquated systems division servers--are recycled. As a result, the lab consists of very different hardware running multiple versions of Microsoft Windows (98SE, NT, 2K) and Microsoft application software. This collection created significant maintenance problems for systems staff, as well as widely varying user experiences on the lab computers. All of this detracted significantly from the use of the lab as an instructional tool.

The primary software and hardware-related concerns articulated by staff and instructors who used the lab included:

  • The need to improve the performance of the wide range of computer hardware deployed in the lab environment.

  • The need for a centralized mechanism for maintaining a single security policy across all systems in the lab.

  • The need to improve printing performance in the lab.

  • The desire to create a more homogeneous software environment to facilitate student learning.

The Solution

This year, the Systems Division upgraded one of its Linux-based X application hosts--a 500MHz dual processor PIII, with 500MB of RAM--used to power many of its X terminal-based public computing infostations. This shift put the library in a position to upgrade the lab environment in a way that simplified administrative chores, created an internally consistent learning environment, mitigated the differences in PC hardware and met the needs of instructors without the need for purchasing additional PC hardware.

The X Window System, X for short, is the graphical interface software that provides a client-server interface between peripheral devices, such as the mouse, keyboard and video display, and a windowed desktop environment. X differs from traditional personal computing user interface software in that it is network transparent and it creates a division of labor between software execution and software display. Under X, for example, one can run multiple instances of client applications, such as a Web browser or a window-managed desktop on a remote application host, and use and display those applications on one or more workstations equipped with an X server.

Several benefits can be realized when using the X-networked client-server model in an instructional lab environment:

  • It mitigates the relatively poor performance of software on older hardware, because the workstation hardware is used only to display, not run, applications used in the lab.

  • It eliminates problems associated with students modifying desktop settings, such as browser home pages, or installing potentially malicious software on the system.

  • It facilitates system maintenance and creates a homogeneous desktop and software environment, because the desktop and its software are configured and maintained on a single application host.

  • Cost efficiencies and hardware availability. Because the hardware requirements of workstations running as display servers is significantly lower than what is required for systems that must run both the application and its display, hardware that would be marked for removal elsewhere in the institution can be recycled into the lab environment at no additional cost.


The basic implementation strategy was to create minimal workstation installations of Linux consisting of little more than the kernel, basic utilities, sshd and XFree86. We would then use XDMCP to connect those systems to an X application host running the desired client applications, window manager, browser, office software and so on.

For this project, we used the downloadable version of Red Hat 9.0 for both the workstation installations and the application host.

Application Host Software

XFree86 3.x or higher. The system that we decided to build requires XDM, XFS and Xauth. Assuming you are using an RPM-based distribution such as Red Hat 9.0, you need the following packages: XFree86-libs, XFree86-tools, XFree86-libs-data, XFree86-truetype-fonts, XFree86-xauth, XFree86, XFree86-xdm, XFree86-xfs and XFree86-base-fonts.

Window Manager. We used FVWM as the primary desktop in our environment because it has a small footprint on the system and is administrator-friendly. A full-featured desktop environment, say, KDE or GNOME, also works in this design.

Application Software. Our environment uses Mozilla, and a custom widget to enable students to smbmount and unmount their personal home directories over the network.

Linux Display Server Software

For the Linux display server, you need the following:

  • XFree86 3.x or higher (see host for packages)

  • sshd to enable remote administration of the system

Installing Host Applications

In this tutorial, we install only two graphical applications beyond those that come standard with XFree86: FVWM and Mozilla. Mozilla can be downloaded in binary or source format from For instructions on installing Mozilla from source and customizing it for use in a multiuser Linux environment, refer to the Mozilla Optimization Mini-HOWTO (see Resources)

FVWM can be downloaded and installed in binary or source format from Although a detailed discussion of FVWM configuration is beyond the scope of this document, the Resources section has a link to a tarball of an FVWM configuration suitable for use with this tutorial.

Installing X

XFree86 is a standard component on most desktop Linux systems, and virtually all distributions have package managers (for example, RPM, deb) to facilitate installing XFree86. One feature new to 4.x versions of XFree86 is the XFree86 -configure command; it probes the system's hardware and writes out an initial XFree86 configuration file that is adequate for most systems.

The XFree86 sources and binaries can obtained from XFree86.Org. The process for installing X in binary format is relatively straightforward. Begin by downloading the script. Run -check to determine which files you need for your system and download them. Run sh to install XFree86. Run XFree86 -configure when the installation is complete to configure the system for use with your hardware. Finish by rebooting; although this isn't necessary, it is a step recommended by the XFree86 consortium.

Configuring X on the Host

For the purposes of this article, our application host provides the following services to the X display servers running on our workstations:

  • XDM: session authentication and management

  • XFS: anti-aliased fonts

The X Display Manager (XDM) is a program that authenticates, authorizes and manages sessions on the host for any connected X server. When XDM is started, it reads the master configuration file, usually /etc/X11/xdm/xdm-config. In most cases, the standard configuration for the resource file is sufficient with the caveat that, by default, XDM is configured to ignore XDMCP and to choose requests over TCP. To allow XDM to listen to XDMCP requests, simply comment out the line that sets the requestPort for the display manager to 0, like this:

!DisplayManager.requestPort: 0

When an X Server tries to connect to XDM, XDM reads its XAccess file, usually /etc/X11/xdm/Xaccess. Xaccess is a file that XDM reads to determine which X Terminals can log in and access software running on the host machine. The remote X server sends a request to XDM that in turn runs an X setup script to set up the login screen and displays the xlogin widget, which handles authentication. When successful authentication occurs, it sets up a session between client applications on a host machine and the workstation running the X display server.

Typically, you want to restrict global access to the login window and specify which Display Servers are allowed to try and authenticate on the Application Host. Assuming that you want to permit workstations to make a direct connection to XDM on the application host, an Xaccess configuration similar to the following should suffice:

* # Allow any X server can get a login window # Only allow specific systems to login. !* # Prevent all other systems from using XDM

The third file that needs to be configured is the Xsession file. The Xsession is a script that controls much of the information regarding a particular host machine's X environment, including which window manager to use, which applications to start, where to write logfiles and what configurations to use for keymappings and other systems resources.

Because Xsession is a shell script, the kinds of configurations that it supports are left entirely to the imagination and needs of the administrator maintaining the system. The first decision that needs to be made is whether to use a global configuration for all users, a local configuration for individual users or a mixture of both.

The code snippet below tries to run a user's personal .xsession file and defaults to system-specific desktop environments. The pattern below essentially says, if you find this file and it is executable, run it. Otherwise, move on to the next choice:

if [ -x "$HOME/.xsession" ]; then # First look for the user's preferences exec "$HOME/.xsession" # if found, execute user's .xsession file elif [ -x /usr/bin/gnome-session ]; then # otherwise look for gnome and start, if found. exec gnome-session elif [ -x /usr/bin/startkde ]; then # otherwise look for kde and start, if found. exec startkde elif [ /usr/X11R6/bin/twm ]; then # Haven't found anything so try twm exec twm else exec xterm -geometry 80x24-0-0 # can't find anything. Open a terminal fi

Like the system-wide Xsession file, a user-specific .xsession file is a script that can contain as much or as little information as is needed to maintain a coherent desktop system. In the example below, the script sets environment variables to specify the coordinates of the Mozilla browser on the screen; Mozilla does not support the -geometry argument. This example is interesting because it looks for the presence of a dot-file (.moz). If that file is found, it calls a script to reset Mozilla to its default preferences and to start Mozilla when X is started.

if [ $DISPLAY = ":0" ] || [ $DISPLAY = ":0.0" ]; then XTERMNAME=console xmodmap .local-x-keymaps else XTERMNAME=`echo $DISPLAY | cut -f1 -d":"` xmodmap .remote-x-keymaps fi export XTERMNAME export HOME=$HOME/$XTERMNAME # our version of Mozilla has been # hacked to transform it into a good # X citizen. # See the Mozilla Optimization mini-HOWTO: # MOZILLA_SCREEN_POS='screenx=1,screeny=1' MOZILLA_SCREEN_POS='top=1,left=1' export MOZILLA_SCREEN_POS # use local defaults for mouse and keyboard bindings xdefaults=/home/guest/.Xdefaults #set an environment variable $MOZ. If it refers to #an actual file set user preferences accordingly export MOZ=$HOME/.moz if [ -f $MOZ ]; then # execute a script that restores mozilla's # preferences to a default value. /home/guest/preferences.p # start mozilla exec /usr/local/mozilla # start FVWM using the themes-rc configuration file fvwm2 -f /home/guest/.fvwm/themes-rc else # start FVWM without Mozilla fvwm2 -f /home/guest/.fvwm/themes-rc2 fi

Configuring the Workstation

Workstation installations should be barebones systems plus SSH and XFree86. The XFree86 configuration is fairly straightforward. You are using these systems to display remote applications rather than to run applications for remote display, so no configuration changes to XDM should be necessary.

All that is needed is to set up the system to boot directly into X on the host machine. This requires making a few simply changes to the /etc/inittab file. /etc/inittab describes which processes are started when the system boots up and specifies which mode the system will run in when it boots.

On Linux, runlevel 5 sets the system to run in X11 mode. To set this, modify the inittab's initdefault so that it looks like:


Additionally, we can specify how we would like to start X when the system comes up. We want to set X to query XDM on the application host. To set the system to start a remote X session on a system called Plato, start X from a line like the following at the end of the inittab:

x:5:respawn:/usr/X11R6/bin/X -query plato

Finally, it might behoove us to disable the user's ability to escape out of X windows using Ctrl-<Alt-<Backspace. To do this we simply add the DontZap option to the ServerFlags section of the XF86Config file; on most Linux systems, this file is found in /etc/X11.

Section "ServerFlags" # NoTrapSignals DontZap # DontZoom EndSection


If the login succeeds but the login box redisplays, most likely the Xsession environment is not set up correctly--it is not set with the proper permissions or owner. Check the /etc/X11/xdm/Xsession file or the /home/user/.xsession file.

If you receive an XDMCP error: Host unwilling manager message, the XDM on the host system most likely has not been configured properly to accept remote connections from X servers over TCP. If this is not the case, then the X server does not have authority to get a login window. This usually signifies a misconfiguration in the access control list in Xaccess or a misconfiguration in xdm-config. Verify that the parameters have been set correctly, restart all instances of XDM and try again killall -HUP xdm.


The network transparency of XFree86 is an underutilized strength of the protocol. It can facilitate the administration of lab environments. It can increase return on hardware investment, and it can be used to provide a host-based, standardized software environment on heterogeneous personal computing hardware.

Additional Resources

Salvador Peralta is the Systems Administrator for the Mark O. Hatfield Library at Willamette University in Salem, Oregon.

Load Disqus comments