Linux in Academic Labs Revisited

Using an X-based client server model to maintain network consistency.

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.

Implementation

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

smbmount widget?

Anonymous's picture

Where is this smbmount widget he mentioned? Please GPL and post. Thanks.

Re: Linux in Academic Labs Revisited

Anonymous's picture

Why is this article formatted to be so wide that it des not fit on my 1280 x 1024 screen without horizontal scrolling???

Re: Linux in Academic Labs Revisited

Anonymous's picture

I hate it when it doesn't wrap properly. Annoyed and decided to find out why this happened - not just this time; also that was before I saw this other question posted; after trouble-shooting maybe almost 30 minutes, I realized that it was a line in the HTML tag that contains hidden space characters. That line dictates the over length of the table.

The problematic line is:
# See the Mozilla Optimization mini-HOWTO: [lots of hidden trailing space characters here...]

If you save the (printable version of this) page locally and remove the trailing spaces in the above line, you can view the page locally with nice wrapping that fits in your browser.

Linux Journal Staff:
Would you raise awareness among yourselves to ensure that cut and paste into html code won't cause extra trailing spaces to be included, especially when the line is in HTML tag ?

Thanks.

Re: Linux in Academic Labs Revisited

Anonymous's picture

Oddly enough, if I open your comment in a new window and then choose the "Parent" link, I get a nicely formatted article. Go figure.

Re: Linux in Academic Labs Revisited

Anonymous's picture

Good question; it's really irritating. You'd think a site like LinuxJournal could make a page that has text wrapping that works.

Re: Linux in Academic Labs Revisited

Anonymous's picture

(Best I can do with w3m and nedit. Sigh. Odd HTML and images in tables)
HOWTO: Linux in Academic Labs Revisited Printer Friendly Page Send this *
Posted on Tuesday, January 13, 2004 by Article to a Friend
Salvador Peralta

Linux in Education Using an X-based client server model to maintain network
consistency.

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.

Implementation

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, OpenOffice.org 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 Mozilla.org. 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 fvwm.org.

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 Xinstall.sh script. Run Xinstall.sh -check to determine which
files you need for your system and download them. Run sh Xinstall.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
64.100.1.121 # Only allow specific systems to
login.
64.100.1.122
64.100.1.123
!* # 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:
# http://www.willamette.edu/~speralta/tldp/mozilla/
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:

id:5:initdefault:

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-
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

Troubleshooting

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.

Conclusions

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

* Mozilla Optimization Mini-HOWTO

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

[ljsubsbutto]

"Linux in Academic Labs Revisited" | Login/Create an Account | 4 comments
Threshold [0 ] [Thread ] [Oldest First ] [Refresh] [Post Comment]

The comments are owned by the poster. We aren't responsible for their content.

Re: Linux in Academic Labs Revisited (Score: 0)
by Anonymous on Wednesday, January 14, 2004
Why is this article formatted to be so wide that it des not fit on my 1280 x
1024 screen without horizontal scrolling???

[ Reply to This ]

* Re: Linux in Academic Labs Revisited by Anonymous on Wednesday, January 14,
2004
* Re: Linux in Academic Labs Revisited by Anonymous on Wednesday, January 14,
2004
+ text wrap by Anonymous on Wednesday, January 14, 2004

# #

#
[ssc_logo]
Systems Consultants, Inc. (SSC) publishers of Linux
Journal.
Privacy Statement
ndicated news file: news.rss
Powered by PHP-Nuke
#

text wrap

Anonymous's picture

Yah, like what this comment section has...

Re: Linux in Academic Labs Revisited

Anonymous's picture

What is the difference between this impementation and the Linux Terminal Server Project (LTSP)?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix