Connecting X Terminals to Linux Mini-HOWTO
Salvador J. Peralta
Revision History
Revision 1.2 release 2003-05-20 Revised by: sjp
Added more information on XFS and XDM configuration.
Revision 1.0 release 2002-12-21 Revised by: sjp
First official release. Removed old revision logs.
This Mini-HOWTO describes how to connect X Terminals with a Linux host using
nfs, xfs, xdm and xdmcp. Additionally, the document discusses configuration
recommendations to optimize Linux for use as a host system on a network of
thin clients. The most current version can be obtained [http://
www.willamette.edu/~speralta/tldp/xterm] here.
-----------------------------------------------------------------------------
Table of Contents
1. Copyright
2. Introduction
2.1. What is XFree86
2.2. What is an X Terminal?
2.3. Infrastructure Overview
3. Host Environment
3.1. Hardware
3.2. Software
4. Basic Host Configuration
4.1. Configuring NFS
4.2. Configuring XDM
4.3. Configuring Xaccess
4.4. Configuring Host Access
4.5. Configuring the X Font Server
4.6. Configuring the X Session
5. Advanced Host Configuration
5.1. Setting User and Group Limits
5.2. More Limits
6. Client Configuration
6.1. The Boot Process
7. Additional Resources
7.1. Linux Howto's
7.2. Man Pages
7.3. Linux Guides
7.4. Books
8. Errata
8.1. System Versions
8.2. Disclaimer
8.3. Feedback
8.4. Credits
1. Copyright
Copyright (c) 2002-2003 Salvador Peralta
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.2 or any later
version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.
-----------------------------------------------------------------------------
2. Introduction
This section provides a brief introduction to the X Window System and the
client server model for X terminals and their Linux-based host systems.
-----------------------------------------------------------------------------
2.1. What is XFree86
XFree86 is an Open Source implementation of the X Windows System (X). It
provides a client-server interface between mouse, keyboard, video display,
and a windowed desktop environment. Because X is network transparent, client
programs can be run on a different host machine than the one on which an X
Server resides.
The XFree86 bundle includes a large array of programs including a terminal
emulator, clocks, and a mail interface. This document will focus exclusively
on the portions of XFree86 required for maintaining an X Session between an X
Terminal and a Linux host. These are the X Display Manager, xdm, an access
control programs and the X Font Server, xfs.
-----------------------------------------------------------------------------
2.2. What is an X Terminal?
X Terminals are diskless networked microcomputers. These systems will
generally consist of mouse, monitor, keyboard, RAM, battery-powered NVRAM,
and secondary ports for connecting peripheral devices such as printer, bar
code scanner, etc. Because they are diskless, X Terminals load their
operating system, configuration information, and fonts into memory from a
host machine running nfs or tftp, and xfs.
The Operating System of an X Terminal will provide basic administrative
interface for configuration parameters such as tcp, xdmcp, font path, boot
path, and other host-related configurations. It's primary function, however,
is to act as an X Server which exchanges mouse, keyboard, and other display
information with client applications loaded on a remote host.
-----------------------------------------------------------------------------
2.3. Infrastructure Overview
The canonical way of deploying X Terminal systems on an IP-based network is
to use the Bootstrap protocol, bootp, to provide client and host ip addresses
and to request a bootable image to mount the operating system. Clients may
also store this information from their own NVRAM which mitigates the need for
fetching it off of a network. NFS or TFTP is utilized to load the os image
and system fonts into RAM on the client machine. XDM provides ip-based
authentication and management of the display session using XDMCP. XFS may
optionally be run on the host to provide anti-aliasing fonts to the client
system (highly recommended). TCP is commonly the transport layer for all
client-server interaction.
-----------------------------------------------------------------------------
3. Host Environment
In an X environment, a host is a system that provides resources for an X
Server. In a diskless workstation environment, the services provided by a
host system will generally include session authentication using xauth and
xhost, session management using xdm, file transfer services such as nfs and
tftp which provide system fonts and a bootable image to be loaded into the X
Terminal's RAM, and windowed client applications (e.g., Mozilla, Open
Office).
-----------------------------------------------------------------------------
3.1. Hardware
Our environment consists of 25 diskless workstations with 15 workstations
using Mozilla, 6 worsktations utilizing a proprietary graphical application
written in Java, and 4 workstations with an application running under a
terminal emulator.The 6 java-based workstations use Gnome as their desktop
environment. The remaining 19 workstations use FVWM2. To support that
environment, we use 2 dual processor pentium 3's. One system has 1 gig of
ram, the other has 500 megs. We have found that the stations running Gnome
and Java use dramatically more memory and cpu than the stations running
Mozilla.
-----------------------------------------------------------------------------
3.2. Software
In order to use Linux as a host for a network of thin client workstations,
you will want to get the latest release of the the XFree86 X Windows System,
FVWM2, and nfs-utils. Assuming that you are using an RPM-based distribution,
you will want the following packages: Xfree86-font-utils, Xfree86-libs,
Xfree86-devel, Xfree86, Xfree86-truetype-font, Xfree86-xdm,
Xfree86-base-fonts, nfs-utils, fvwm2, fvwm2-icons. To verify installed
packages on an rpm-based distribution such as Redhat, you can use "rpm-qa |
grep (packagename)". To install or update those packages simply download them
from their maintainer or from your installation media with and "rpm -Uvh
(packagename)". Alternately, you can use a graphical front end to rpm such as
gnoRPM to maintain the required packages are installed on your system. For
debian-based systems, or for Gentoo, please consult your system documentation
on apt-get and portage, respectively.
-----------------------------------------------------------------------------
4. Basic Host Configuration
Assuming that the required software is installed, we need to configure NFS to
mount the fonts and operating system for our thin client workstations,
configure XFree86 to provide remote display access, configure our Xsession to
deliver our choice of window manager to our client systems.
-----------------------------------------------------------------------------
4.1. Configuring NFS
In order to load the configuration information, base system fonts, and os
image from the host machine using NFS, you need to provide read access to the
directory or directories where that data is located. To do this, you will
need to edit the /etc/exports file.
/etc/exports is an access control list which provides an entry for any
directory that can be exported to an NFS client using the exportfs command.
Configuring /etc/exports is easy.
To provide read access to any system which requests resources in /home/
ncbridge, you would enter the following line into /etc/exports:
+---------------------------------------------------------------------------+
|/home/ncbridge *(ro) |
+---------------------------------------------------------------------------+
For better security, you can also specify access to individual client
systems. To do this, simply enter:
+---------------------------------------------------------------------------+
|/home/ncbridge client1.yourdomain.com (ro) |
|/home/ncbridge client2.yourdomain.com (ro) |
|/home/ncbridge client3.yourdomain.com (ro) |
+---------------------------------------------------------------------------+
/etc/exports also provides facilities such as globbing for grouping like
named groups together. For example, to provide read-only access to similarly
named clients:
+---------------------------------------------------------------------------+
|/home/ncbridge client*.yourdomain.com (ro) |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
4.2. Configuring XDM
The X Display manager is a program which authenticates, authorizes and
manages sessions for an X server. The standard configuration from the X
Consortium is appropriate for use with X Terminals.. However, this file needs
to be configured to not use display :0 as the default console, and XDM should
be configured to listen for XDMCP requests.
In /etc/X11/xdm/xdm-config make the following configuration changes - Comment
out the lines which would set display :0 as the console:
+---------------------------------------------------------------------------+
|! The following three resources set up display :0 as the console. |
|!DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0 |
|!DisplayManager._0.startup: /etc/X11/xdm/GiveConsole |
|!DisplayManager._0.reset: /etc/X11/xdm/TakeConsole |
+---------------------------------------------------------------------------+
Comment out the line which sets the requestPort for the display manager to :
0.
+---------------------------------------------------------------------------+
|!DisplayManager.requestPort: 0 |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
4.3. Configuring Xaccess
Xaccess is a file which XDM reads to determine which X Terminals can login
and access software running on the host machine. An X Terminal sends a
request to XDM which in turn runs an Xsetup script which sets up the login
screen and displays the xlogin widget which handles authentication and on
successful authentication sets up a session between client applications on a
host machine and an X Terminal.
The only configuration changes typically needed here involve setting up the
access control to restrict global access to the xserver, and to add
individual authorized hosts by ip address. Assuming that you are allowing
multiple clients to log in, your configuration should look something like
this:
+---------------------------------------------------------------------------+
|#* # Allow any X server can get a login window |
|158.100.5.121 # Only allow specific systems to login. |
|158.100.5.122 |
|158.100.5.123 |
|158.100.5.124 |
|158.100.5.125 |
|!* # Prevent all other systems from using XDM |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
4.4. Configuring Host Access
If you are not running terminals from a DNS server and/or are not allocating
IP addresses using DHCP (as we are not), you will need to add an entry for
each X Terminal in /etc/hosts on the Linux host machine.
+---------------------------------------------------------------------------+
|158.100.5.121 # One system per line with optional |
|158.100.5.122 # parameters for lprhost and loghost |
|158.100.5.123 |
|158.100.5.124 |
|158.100.5.125 |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
4.5. Configuring the X Font Server
The X Font Server (xfs) provides system fonts to X display servers. It is the
only way to provide anti-aliased fonts such as freetype to most X Terminals.
On most Linux systems, xfs is started from a script in /etc/init.d, and/or on
startup from one or more scripts, /etc rc.d/init.d or in one of the run-level
initialization scripts in /etc/rc[0-6].d. The most important thing to verify
is that the X Terminal and the X Host are broadcasting and listening on the
same port. Some X Terminals use the default xfs port, 7100, for other
services, so xfs can be run on an unassigned port, such as 7102, in order to
avoid a conflict.
On most systems, the configuration for XFS is in /etc/X11/fs/config. In order
to enable XFS to be accessed remotely, comment out the no-listen = tcp
directive from the configuration file. Be sure to set a max client limit
equal to or greater than the total number of clients you will be serving.
-----------------------------------------------------------------------------
4.6. Configuring the X Session
The Xsession file controls much of the information regarding a particular
host machines X environment. Examples of things that might be set in this
file includes logging, which desktop manager to run, and which keyboard
mappings to use. These settings are highly environment specific, and for that
reason will not be addressed in this document. Suffice to say that you will
want to decide whether to use user-level or global preferences for the
desktop environment and that those configuration changes must be made in this
file and in a .xsession file in the user's home directory.
-----------------------------------------------------------------------------
5. Advanced Host Configuration
The section addresses some optional configuration options that may improve
performance on a Linux X Host.
-----------------------------------------------------------------------------
5.1. Setting User and Group Limits
One of the dangers associated with the thin client model is that a runaway
process might eat up all of the available system memory and/or cpu on the
host system. When this happens, the performance on that system can degrade
resulting in system hangs, freezes, and a host of other generally undesirable
consequences.
Fortunately, Linux comes with a set of facilities to mitigate these kinds of
problems. The first tool that we will look at is the limits.conf file located
in /etc/security. limits.conf provides the ability to specify user and group
level limits to certain types of system resources, including memory. Limits
set in this file are set on a per user or per group basis. Though there are
many limits that can be set in this file, we will address only a few in this
tutorial.
The basic syntax for limits.conf consists of individual lines with values of
the following types: (domain) (type) (item) (value) where domain is user or
group, type refers to a hard or soft limit, item refers to the resource being
limited and value referring to the value associated with the limit being set.
For example, setting the following value:
+---------------------------------------------------------------------------+
|guest hard priority 19 |
+---------------------------------------------------------------------------+
places a hard limit on the priority with which jobs are scheduled for a user
named 'guest'. In this case, guest is always scheduled at the lowest possible
priority.
As another example, to set a max cpu time of 10 minutes for user guest, set
the following value:
+---------------------------------------------------------------------------+
|guest hard cpu 10 |
+---------------------------------------------------------------------------+
As a final example, to set a limit of 3 failed logins for a group called
guest, set the following value:
+---------------------------------------------------------------------------+
|@guest hard maxlogins 3 |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
5.2. More Limits
A second method for limiting the potential impact of runaway proceses is to
set limits on a per process basis. This can be achieved by setting the ulimit
command in /etc/profile.
To set a soft limit on the maximum amount of memory available to a given
process to a value that is less than the total amount of memory on the system
on a system with 1 gig of real memory and 500 megs of virtual memory you
would set the following values in /etc/profile:
+---------------------------------------------------------------------------+
|ulimit -S -m 1000000 |
|ulimit -S -v 500000 |
+---------------------------------------------------------------------------+
With this value set, the system will kill any process that tries to take up
more resources than you have set as a limit.
-----------------------------------------------------------------------------
6. Client Configuration
This section attempts to discuss, in generic terms, the configurations needed
to connect a generic X Terminal to a host system.
-----------------------------------------------------------------------------
6.1. The Boot Process
When an X Terminal is booted from a host on the network, it may either use
bootp or rarp to determine ip and host addresses, or it may store those
values locally in NVRAM on the terminal. The advantage to using bootp is that
the host information and ip addresses may be stored centrally in a single
configuration. An advantage to using the values locally on the client system
is that it allows for a more fine-grained control over tcp/ip and host
information.
Assuming that host and ip address information is properly configured for the
X Terminal, step two in the boot process is for the X Terminal to load its
operating system and core fonts. In order to do this, the client needs to
know the full path to the OS image and system configurations and base fonts.
It needs to have a boot method specified for fetching these files. On most
systems, that is tftp or nfs. Last, the X Terminal needs to know which will
be managing the XDMCP communication ( i.e., the system from which client
applications will be deployed ). All of this information is stored in NVRAM
on the X Terminal.
Step three in the boot process occurs when the X Terminal connects to the
client machine. Most X Terminals can send a direct or indirect query to an
xdmcp session manager on a network. In an indirect query, all available xdmcp
session managers will respond and display a menu of possible hosts. In the
case of a direct query, xdm on the host system runs the Xsetup script which
sets up the display for the login screen and provides the xlogin widget which
requires a valid userid and password to login and start an xdmcp session.
-----------------------------------------------------------------------------
7. Additional Resources
7.1. Linux Howto's
This document is intended as a replacement and extension of the unmaintained
X Terminal HOWTO. The following Mini-HOWTO's can be found at the Linux
Documentation Project (TLDP) at www.tldp.org: XWindow-Overview-HOWTO,
XWindow-User-HOWTO, XDM-Xterm Mini-HOWTO, NCD X terminal Mini-HOWTO.
-----------------------------------------------------------------------------
7.2. Man Pages
TLDP, the XFree86 project, and the GNU Organization have a series of online
manuals which describe many of the services dealt with in this Mini-HOWTO.
Man pages relevent to this document include pages for xdm, nfs, exports, X,
and ulimit.
-----------------------------------------------------------------------------
7.3. Linux Guides
Chapter 14 of the LDP "Network Administrator's Guide" (NAG) has useful
information on using NFS in Linux.
-----------------------------------------------------------------------------
7.4. Books
The "X Windows System Administrator's Guide" by O'Reilly and Associates is
highly recommended.
-----------------------------------------------------------------------------
8. Errata
8.1. System Versions
The methods outlined in this Mini-HOWTO have been used in a production
environment utilizing Redhat 7.3, 7.1, 6.3, and 6.1 with XFree86 versions
beginning with 3.2 through 4.2. The X Terminals used in this environment are
Network Computing Devices (NCD) Network Computer versions nc900, nc500, and
nc350.
-----------------------------------------------------------------------------
8.2. Disclaimer
This document is provided "as is". Neither the author nor the distributors of
the document are responsible for any physical, financial, or other form of
damage incurred by the suggestions provided in this text.
-----------------------------------------------------------------------------
8.3. Feedback
If you find any portion of this document useful, or if you have suggestions,
please email the maintainer, speralta [at] willamette [dot] edu.
-----------------------------------------------------------------------------
8.4. Credits
My sincere thanks goes to the Willamette University for employing me to build
and maintain Linux-based systems like the ones described in this document,
and to Michael Spalti for introducing me to this technology and for his
development and support of these systems.