LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/docbook/XDM-Xterm.sgml

1815 lines
54 KiB
Plaintext
Raw Permalink Blame History

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<article id="index">
<!-- Header -->
<artheader>
<title>XDM and X Terminal mini-HOWTO</title>
<author>
<firstname>Kevin</firstname>
<surname>Taylor</surname>
<affiliation>
<address>
<email>kevin@northants.lug.org.uk</email>
</address>
</affiliation>
</author>
<revhistory>
<revision>
<revnumber>v1.00</revnumber>
<date>2002-05-16</date>
<authorinitials>KT</authorinitials>
<revremark>
Minor updates to all sections. Added details of Windows/Linux interoperability.
Added section on starting XDM. Added details of KDM and GDM. Added new software
resources.
</revremark>
</revision>
<revision>
<revnumber>v0.05</revnumber>
<date>14 November 2000</date>
<authorinitials>KT</authorinitials>
<revremark>
Added cross-references to other Howtos
</revremark>
</revision>
<revision>
<revnumber>v0.04</revnumber>
<date>6 November 2000</date>
<authorinitials>KT</authorinitials>
<revremark>
Updates after first public draft.
</revremark>
</revision>
<revision>
<revnumber>v0.03</revnumber>
<date>3 July 2000</date>
<authorinitials>KT</authorinitials>
<revremark>
Minor updates from first comments
</revremark>
</revision>
<revision>
<revnumber>v0.02</revnumber>
<date>28 June 2000</date>
<authorinitials>KT</authorinitials>
<revremark>
First SGML source draft from HTML source
</revremark>
</revision>
<revision>
<revnumber>v0.01</revnumber>
<date>27 June 2000</date>
<authorinitials>KT</authorinitials>
<revremark>
First HTML source draft
</revremark>
</revision>
</revhistory>
<abstract>
<indexterm>
<primary>template</primary>
</indexterm>
<para>
This document describes the basic ideas for using XDM to manage
X terminals. It is not meant to be a comprehensive discussion
of all the features of XDM, but a gentle introduction to what XDM
can do.
</para>
<para>
For a full discussion about the installation and configuration
of X terminals, please refer to the 'Thin-client' HOWTO, from
the Linux Documentation Project or the Linux Terminal Server Project
(see <xref linkend="resources">).
</para>
</abstract>
</artheader>
<!-- Section1: intro -->
<sect1 id="intro">
<title>Introduction</title>
<indexterm>
<primary>disk!introduction</primary>
</indexterm>
<!-- Section2: copyright -->
<sect2 id="copyright">
<title>Copyright Information</title>
<para>
This document is copyrighted (c) 2000-2002 Kevin Taylor and is
distributed under the terms of the Linux Documentation Project
(LDP) license, stated below.
</para>
<para>
Unless otherwise stated, Linux HOWTO documents are
copyrighted by their respective authors. Linux HOWTO documents may
be reproduced and distributed in whole or in part, in any medium
physical or electronic, as long as this copyright notice is
retained on all copies. Commercial redistribution is allowed and
encouraged; however, the author would like to be notified of any
such distributions.
</para>
<para>
All translations, derivative works, or aggregate works
incorporating any Linux HOWTO documents must be covered under this
copyright notice. That is, you may not produce a derivative work
from a HOWTO and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the Linux HOWTO coordinator at
the address given below.
</para>
<para>
In short, we wish to promote dissemination of this
information through as many channels as possible. However, we do
wish to retain copyright on the HOWTO documents, and would like to
be notified of any plans to redistribute the HOWTOs.
</para>
<para>
If you have any questions, please contact
<email>linux-howto@metalab.unc.edu</email>
</para>
</sect2>
<!-- Section2: disclaimer -->
<sect2 id="disclaimer">
<title>Disclaimer</title>
<para>
No liability for the contents of this documents can be accepted.
Use the concepts, examples and other content at your own risk.
As this is a new edition of this document, there may be errors
and inaccuracies, that may of course be damaging to your system.
Proceed with caution, and although this is highly unlikely,
the author(s) do not take any responsibility for that.
</para>
<para>
All copyrights are held by their by their respective owners, unless
specifically noted otherwise. Use of a term in this document
should not be regarded as affecting the validity of any trademark
or service mark.
</para>
<para>
Naming of particular products or brands should not be seen
as endorsements.
</para>
<para>
You are strongly recommended to take a backup of your system
before major installation and backups at regular intervals.
</para>
</sect2>
<!-- Section2: newversions-->
<sect2 id="newversions">
<title>New Versions</title>
<indexterm>
<primary>(your index root)!news on</primary>
</indexterm>
<para>
The latest version number of this document may be
obtained from
<ulink url="http://www.northants.lug.org.uk/projects/xdm-mini/">
The Northants LUG, UK Project Pages
</ulink>.
</para>
</sect2>
<!-- Section2: credits -->
<sect2 id="credits">
<title>Credits</title>
<para>
Thanks go to the following people for help with information and
proof reading of the document.
</para>
<para>
Scot W Stevenson for the original X terminal mini-howto document,
from 1995, on which some of the material for the section on advanced
xdm-config configurations was obtained.
</para>
<para>
Members of the Northants LUG, UK for proof reading the document.
</para>
<para>
The writers of the XDM, Xserver man pages and the default XDM scripts.
</para>
<para>
<variablelist>
<VarListentry>
<term> Credits for 0.05
</term>
<listitem>
<para>
Everyone who commented on the earlier versions, including Neil Zanella,
Rafael Herrera, Paul Hornshaw, Clive Jones, Robert de Geus, Alex Schenkman,
Richard Kaszeta, Malcolm Herbet
</para>
</listitem
</VarListentry>
<VarListentry>
<term> Credits for 1.00
</term>
<listitem>
<para>
The following people provided feedback and comments which have led up to
the 1.00 release: Alan James, Stephen Eglen, Malcolm Hunter, Holgar Hoffman,
Patrick Rynhart, Amedeo Lanza, Alexander Skopalik, Mike Banahan.
</para>
</listitem
</VarListentry>
</variablelist>
</para>
</sect2>
<!-- Section2: feedback -->
<sect2 id="feedback">
<title>Feedback</title>
<para>
Feedback is most certainly welcome for this document. Without
your submissions and input, this document wouldn't exist. Please
send your additions, comments and criticisms to the following
email address: <email>xdm-mini@northants.lug.org.uk</email>.
</para>
</sect2>
<!-- Section2: todo -->
<sect2 id="todo">
<title>To do</title>
<para>
I probably ought to mention some details about the following at
some point ...
<itemizedlist>
<listitem>
<para>
Debugging problems with XDM.
</para>
</listitem>
<listitem>
<para>
FAQs and common mistakes
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<!-- Section1: intro: END -->
<!-- Section1: Basics -->
<sect1 id="basics">
<title>Basic Concepts</title>
<indexterm>
<primary>disk!basics</primary>
</indexterm>
<!-- Section2: Coverage -->
<sect2 id="coverage">
<title>What is covered</title>
<para>
This document describes the basic concepts behind using XDM
(the X Display Manager) to manage X terminals and X servers,
in order to provide 'thin-client' computing, using Linux.
</para>
<para>
X (or the 'X Window System') is the windowing and graphics environment
of choice for Unix systems. Its particular strength (and the key bit
that we are interested in for this document) is that it separates the
running applications (web browser, word processor, etc) from the actual
graphics screen and input devices (mouse, keyboard, etc) via a network
communications mechanism.
</para>
<para>
Essentially, this means that you can be running
an application on one machine, but have its input and output redirected
to another machine via a network. This is the key feature that makes
an X terminal possible.
</para>
<para>
This document should be treated as a 'getting started with XDM' document,
in that it describes the basic terms and concepts for using XDM and
X terminals, with simple examples that provide the minimum amount of
security.
</para>
<para>
The reader is advised to consult the list of resources provided at
the end of the document in order to proceed beyond these basic
facilities - in particular, the configuration of the 'authentication'
and security settings should be examined, as the examples given in
this document utilise the least secure modes of operation.
</para>
<para>
Please note - the majority of the information in this document was obtained from
systems running Debian 2.1, SuSE 6.4, Mandrake 7.0 and RedHat 6.0.
</para>
<para>
This document does not discuss the installation or
configuration of a network or X on Linux. Please refer to the
appropriate HOWTO documents from the Linux Documentation Project for
details (see <xref linkend="resources">).
</para>
<para>
This document also does not attempt to describe how to install and configure
Linux for operation as an X terminal. For this information, please refer
to the 'thin-client' HOWTO document, provided as part of the Linux Documentation
Project, or the Linux Terminal Server Project (see <xref linkend="resources">).
</para>
</sect2>
<!-- Section2: About -->
<sect2 id="about">
<title>About this document</title>
<para>
This document came about because I wanted to experiment with Linux
on a 486 PC as an X terminal to my main Linux box.
</para>
<para>
After reading the man pages, specifications and current howto documents
relating to XDM and X terminals, I ended up getting really confused
about where XDM was supposed to run and confusing XDM servers with
X servers and the like, and so after an evening or two of
experimentation, this document was born.
</para>
<para>
Once the basic terminology has been sorted out, the documentation
for XDM and self-documenting sample files make very good reading
- I just could not find a simple introduction to the basic concepts
anywhere to get me started. Hopefully this document could prove
to be a suitable introduction to someone in a similar position to
me.
</para>
<para>
Oh, and in case you are wondering, a 486dx2/66 with 16 Mb RAM
makes a fine X terminal!
</para>
</sect2>
</sect1>
<!-- Section1: Terms -->
<sect1 id="xdm">
<title>XDM</title>
<indexterm>
<primary>disk!xdm</primary>
</indexterm>
<!-- Section2: What is XDM -->
<sect2 id="xdm-what">
<title>What is XDM</title>
<para>
Put simply, XDM (the X Display Manager) can be thought of as a graphical
replacement for the command line 'login' prompt. In reality, it can
actually do much more than that.
</para>
<para>
Typically, it would be started by the 'root' user (or the system startup
scripts) on power up, and would present a user with a graphical login
prompt. It will then manage the users X session once they login -
i.e. it will initiate the running of their window manager and applications.
</para>
<para>
This could be considered a typical 'simple local machine login'
configuration, as may be found installed by many Linux distributions
by default. However, XDM can also manage remote X servers and provide
login prompts to remote 'X terminals'. In short, it is not limited to
the local machine - it can easily manage other machines connected via
a network.
</para>
<para>
XDM is a very configurable utility and this document will only just
'scratch the surface' of what may be achieved. This document aims to
provide enough information to configure your X terminals and application
servers to connect to each other. The reader is referred to
<xref linkend="resources"> for further information on the topics
discussed here.
</para>
<para>
A note on security: X (in its default configuration) and XDMCP are not
particularly secure. I am assuming that you are running X on a
'trusted' network and that security is not an issue.
For details of how to tighten up your X connections
(and more details about using the networking capabilities of X) please
refer to the 'Running Remote X Applications' Howto document, which is
also part of the LDP (see <xref linkend="resources">).
</para>
</sect2>
<!-- Section2: What is an X Terminal -->
<sect2 id="xdm-xterm">
<title>What is an X terminal</title>
<para>
This term could be used to cover various configurations, but at its
simplest, is a machine with a network connection, keyboard,
mouse and monitor, configured to run the X Windows System to connect
to an application server somewhere on the network.
</para>
<para>
There are several configurations of 'X terminal' with varying levels
of functionality, ranging from completely diskless terminals to full
X workstations.
</para>
</sect2>
<!-- Section2: Terminolgy -->
<sect2 id="xdm-terms">
<title>Some Terminology</title>
<para>
Before I go any further, I ought to explain the terms I will be using
in this document. When talking about X, there is quite a lot of
confusion over what is serving facilities to what. This is especially
true when you are considering distributed sessions over a network
involving X terminals. I will be using the terms described below.
</para>
<para>
<variablelist>
<VarListentry>
<term> Diskless X terminal
</term>
<listitem>
<para>
This would be a machine with no local disks, that would perform its
boot up from an EPROM (or similar) and utilises a network connection to a
server. It would obtain its
network configuration, operating system, system configuration and all
applications from the server. Once booted however, this
would be the same as a 'dumb X terminal' (see below). Typically this
configuration would use a combination of the following network protocols
in order to boot: BOOTP, DHCP, TFTP, etc. Refer to
<xref linkend="resources">
for some references that detail how to build diskless X terminals.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> Dumb X terminal
</term>
<listitem>
<para>
This would be a machine that boots from its local disk into an operating
system, and starts the 'X server' program and nothing more. Somehow, a login
prompt would be provided on the machine, to enable a user to login to an
'application server' somewhere on the network.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> X Workstation
</term>
<listitem>
<para>
This would be similar to a dumb X terminal, but would provide the option
of logging on to the local machine itself, hence would be quite capable of
becoming a standalone workstation (i.e. no network connectivity) if required.
Most distributions can be configured 'out of the box' as a stand-alone
X Workstation, with a graphical login prompt.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> Application Server
</term>
<listitem>
<para>
In the context of this document, I use the term 'application server' to
describe a machine that will provide the applications (X clients) that our X
terminal will want to run. This can include everything from editors and browsers,
through to the actual 'Window Manager' itself.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> X Server
</term>
<listitem>
<para>
This is the program that manages the display of a machine with a physical
console (display, keyboard, mouse, etc). It can be thought of as a combined
graphics card, keyboard and mouse 'driver'.
This will provide these facilities as a service to X clients (hence the term
'server'). Please refer to the X User Howto in
<xref linkend="resources">
for more details.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> X Client
</term>
<listitem>
<para>
This is an application that requires the use of an X server to access
input (keyboard and mouse) and output (display). An X client cannot produce
output without the services of the X server. The X server could be
running locally (on the same machine, as is the case with an X
workstation) or elsewhere on the network
(as is the case with an X terminal connecting to an Application Server).
</para>
</listitem>
</VarListentry>
</variablelist>
</para>
<para>
From the above descriptions, an X Workstation could be thought of
as consisting of a dumb X terminal and application server running on the same
machine.
</para>
<para>
This document will be looking at the architecture of the various options
listed above and will describe the role that XDM can play in configuring
them.
</para>
</sect2>
<!-- Section2: What can XDM do -->
<sect2 id="xdm-do">
<title>What can XDM do</title>
<para>
XDM is responsible for providing the user with a login
prompt and initiating their X session. It can manage local sessions (i.e. people
logging into an X workstation) or sessions on remote machines, via a connection
to an application server, from a diskless or dumb X terminal.
</para>
<para>
XDM would typically run on an application server, to permit users to logon
and run applications from that server.
</para>
<para>
There are 2 main ways that XDM can interact with an X Server:
<itemizedlist>
<listitem>
<para>
XDM accepts queries from X server
</para>
</listitem>
<listitem>
<para>
XDM manages X server
</para>
</listitem>
</itemizedlist>
</para>
<sect3 id="xserv-query">
<title>XDM accepts queries from X Server</title>
<para>
The communications between XDM and the actual 'X server' (the machines
with the physical screen/keyboard/mouse/etc) are handled via XDMCP the
'X Display Manager Control Protocol'.
</para>
<para>
This permits X servers to send out queries to servers running XDM.
Effectively, the X server has to say 'I have someone wanting to login -
please give me a login prompt'. In this mode of operation, XDM will
not do anything unless it is asked to by your X server.
</para>
<para>
The query from the X server can take one of 3 forms:
<itemizedlist>
<listitem>
<para>
Direct query: the X server contacts a named host, requesting that XDM
on that host presents a login prompt on its display.
</para>
</listitem>
<listitem>
<para>
Broadcast: the X server sends out a broadcast message to the network,
and the first server running XDM that responds to the broadcast will
be the one to present the login prompt on its display.
</para>
</listitem>
<listitem>
<para>
Indirect query: the X server contacts a named host, but asks it which
other hosts it knows about on the network. The named host will then
present the user with a list of hosts to choose from, and will then
go on to initiate communications with the selected host resulting in
the selected host presenting a login prompt on the X servers display.
</para>
</listitem>
</itemizedlist>
</para>
<para>
There are several other options, but these will not be described here
- refer to the XDM and XDMCP documentation in <xref linkend="resources">
for more details.
</para>
</sect3>
<sect3 id="xdm-server">
<title>XDM Manages X Server</title>
<para>
If you have a set of machines (e.g. diskless or dumb X terminals) that just
end up running an X server, all designed to provide a login prompt to a
single application server, then it is possible to configure XDM on the
application server to connect back to each X server and present its login
prompt on each display automatically.
</para>
<para>
In this mode of operation, XDM will actively 'push out' a login prompt
to any listed X server that it knows about, without waiting for
a query from the X servers themselves.
</para>
<para>
In this case, the configuration file 'Xservers' (see later) lists each
machine (including the local display, if required) to which XDM should
connect, to display its login prompt.
</para>
<para>
This configuration, when used with no remote X servers listed in the
configuration, is the typical configuration used for a X workstation,
in order to present a user with a graphical login to the local machine
he is working on. As stated earlier, most distributions will support
this configuration 'out of the box' in order to present the user with
a local graphical login prompt.
</para>
<para>
Note: XDM must be permitted to connect to the X servers in question - so
the access control on the X servers must be configured accordingly.
</para>
</sect3>
</sect2>
</sect1>
<!-- Section1: config -->
<sect1 id="config">
<title>Configuring XDM</title>
<indexterm>
<primary>disk!config</primary>
</indexterm>
<para>
This section covers what needs to be configured for XDM to perform
the functions described so far in this document.
</para>
<para>
In each case, the configuration described is the minimum necessary to
accomplish each goal. In most cases this means that the configuration
is also the least secure. Please refer to some of the additional
documentation listed in <xref linkend="resources">
for information about securing XDM and X terminals
(in particular the 'Running Remote X Applications Howto' from the LDP).
</para>
<!-- Section2: Config Files -->
<sect2 id="config-files">
<title>Configuration Files</title>
<para>
This describes the following scheme of XDM configuration files:
<itemizedlist>
<listitem>
<para>
xdm-config
</para>
</listitem>
<listitem>
<para>
Xaccess
</para>
</listitem>
<listitem>
<para>
Xservers
</para>
</listitem>
<listitem>
<para>
Xresources
</para>
</listitem>
</itemizedlist>
</para>
<para>
These must be setup for the machine actually running XDM itself. They will typically be
found in (Debian 2.1. Mandrake 7.0.2, RedHat 6.2):
<screen>
/etc/X11/xdm
</screen>
or (SuSE 6.4):
<screen>
/usr/X11R6/lib/X11/xdm
</screen>
</para>
<para>
<variablelist>
<VarListentry>
<term> xdm-config
</term>
<listitem>
<para>
Defines the names and locations of the other configuration files and the basic
access permissions. For all distributions considered for this document,
the file names were as listed here (but sometimes the locations varied).
</para>
<para>
This also defines the scripts to be run for the various state
transitions for an X session, i.e. on startup, etc. You should
not need to change these, as most distributions would appear to
come with this pre-configured for you.
</para>
<para>
Note that XDM managed X sessions have a different set of startup
and configuration scripts to X sessions started via xinit or startx
(i.e. non-XDM managed X sessions).
</para>
<para>
Some distributions (e.g. Redhat 7.1) include the following line in this configuration
file, which will prevent XDM from listening for queries:
<screen>
DisplayManager.requestPort: 0
</screen>
This must be commented out as follows:
<screen>
!DisplayManager.requestPort: 0
</screen>
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> Xaccess
</term>
<listitem>
<para>
Determines which machines can connect to XDM - i.e.
from which other machines on the network we are accepting XDMCP
queries. If a machine is not listed in this file, then it will not
be able to request a login prompt from XDM.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> Xservers
</term>
<listitem>
<para>
Contains a list of machines that XDM will connect to, to provide a
login prompt, automatically - i.e. those machines already running an X
server, but would like this machine to provide the login prompt.
</para>
<para>
This is only required for 'XDM Managed X Servers'. You do not need
any entries in this file if you will be relying on remote X servers
to query XDM.
</para>
<para>
When running as a stand-alone 'X Workstation', there is usually a
single entry in this file, listing just the localhost.
</para>
</listitem>
</VarListentry>
<VarListentry>
<term> Xresources
</term>
<listitem>
<para>
Details of the X properties used by the XDM widgets (e.g. size of the
login 'box', colours, bitmap backgrounds, etc).
</para>
</listitem>
</VarListentry>
</variablelist>
</para>
</sect2>
<!-- Section2: XDM Managing X Servers -->
<sect2 id="xdm-xserv">
<title>Configuring XDM to Manage X Servers</title>
<para>
An entry must be placed in the Xservers file for each X server
that XDM will be presenting a login prompt on. This could include
the local machine and/or a list of remote machines.
</para>
<para>
Example
<screen>
# First the local host
:0 local /usr/bin/X11/X vt7
#
# Then the remote hosts
emma:0 foreign
alex:0 foreign
</screen>
</para>
<para>
This will start XDM on the local machine and also present
a login screen on the X servers running on the hosts 'emma' and 'alex' (assuming that
permissions have been setup on 'emma' and 'alex' such that this machine
is permitted to connect to the running X servers).
</para>
<para>
Note that it is possible to specify the host and display (:0, :1, etc)
if required. This is useful, for example, if you are running multiple X servers on a
single machine, etc.
</para>
</sect2>
<!-- Section2: XDM for queries -->
<sect2 id="xdm-queries">
<title>Configuring XDM to Receive Queries</title>
<para>
The file Xaccess determines which hosts may query XDM on this machine,
in order to request a login prompt.
</para>
<para>
Example
<screen>
# First line for direct queries
*
# Following line for indirect queries
* CHOOSER BROADCAST
</screen>
</para>
<para>
This means that any host may request a login prompt via XDM (the first '*')
using a direct query.
</para>
<para>
The 'CHOOSER' line specifies which hosts can connect to XDM using
indirect queries - in this case, any host may query this machine for
a list of potential hosts to connect to (the second '*' line).
</para>
<para>
'BROADCAST' means that the 'chooser' application on this machine
will obtain its list of available servers (that will also be running XDM)
via network broadcast queries. I will talk about the 'chooser' later.
</para>
<para>
It is possible to place specific host names or specifications of network IP
addresses (e.g. a whole IP network or specific hosts) in these entries (and there
are also other indirect queries possible, without using the chooser)
but this is not described here (refer to <xref linkend="resources">
for some links to more information).
</para>
</sect2>
<!-- Section2: Starting X -->
<sect2 id="xdm-startx">
<title>Starting X</title>
<para>
The way you start the X server itself, will depend upon how you want it to
interact with XDM locally and remotely.
</para>
<para>
<variablelist>
<varlistentry>
<term> X Workstation: XDM and local X server
</term>
<listitem>
<para>
XDM will normally start X automatically for you and XDM will usually
be configured to run as part of the startup process (via the init scripts).
Most distributions have a specific 'run-level' for starting the system up
with a graphical login prompt.
</para>
<para>
The Xservers file would typically contain a single entry - that of the
local host, and the Xaccess file would only need to permit access from
the local host.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term> X Terminal: Remote XDM
</term>
<listitem>
<para>
Just start X with no clients, with access permissions such that the
remote XDM is able to connect when it starts up. The following will start
X with no access control:
<screen>
/usr/X11R6/bin/X -ac
</screen>
</para>
<para>
When the remote XDM is started, it will 'push out' a login prompt to
all such configured X servers (as listed in its Xservers file).
</para>
</listitem>
</varlistentry>
<varlistentry>
<term> X Terminal: Query a remote XDM
</term>
<listitem>
<para>
Recall there are 3 modes for queries: direct, indirect and broadcast
(direct for a single host, indirect for a list of hosts or broadcast for
the first host that replies):
<screen>
/usr/X11R6/bin/X -query the.remote.host
/usr/X11R6/bin/X -indirect the.remote.host
/usr/X11R6/bin/X -broadcast
</screen>
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
In each case, X will probably have to be started as root.
</para>
<para>
It is possible to have a machine automatically start X and perform a query
for a running XDM on the network. One way is to 'hijack' the inittab setting
for running as a graphical login (this is runlevel 5 on Debian and
Redhat based systems, and 3 for SuSE - this example assumes runlevel
5 throughout). This is often the line beginning x:5 towards the end of /etc/inittab.
Set this to (or add it if it doesn't exist):
<screen>
x:5:respawn:/usr/X11R6/bin/X -broadcast
</screen>
Replacing -broadcast with -direct or -indirect, etc. as required. You may have to
change your default runlevel to be 5 too, (and then reboot), as follows:
<screen>
id:5:initdefault:
</screen>
</para>
</sect2>
<!-- Section2: Staring XDM -->
<sect2 id="xdm-startup">
<title>Starting XDM</title>
<para>
In a standard X workstation configuration, XDM would typically be started up by
specifying the default initial run-level to be that corresponding to a full graphical
login. On Redhat and Debian based systems this is usually runlevel 5. On SuSE it is
run-level 3.
</para>
<para>
It is possible to run XDM automatically on startup by changing the default runlevel
to that described above. This is configured in /etc/inittab as follows:
<screen>
id:5:initdefault:
</screen>
</para>
<para>
Alternatively it is possible to add a startup script for XDM itself to the rc scripts
in the startup directories (/etc/rc.d/ for Redhat/Debian), to start and stop XDM in a
similar manner to other services on a Linux machine.
</para>
<para>
The following script is suitable for a Redhat (and probably Mandrake) based system,
and should be saved as /etc/rc.d/init.d/xdm. You will have to enable it using
'chkconfig --add xdm'.
<screen>
#!/bin/sh
# xdm start/stop script for RedHat based systems
#
# chkconfig: 234 60 60
# description: xdm permits remote users to logon to this X display
# processname: /usr/X11R6/bin/xdm
# config: /etc/X11/xdm/xdm-config
# source function library
. /etc/rc.d/init.d/functions
[ -x /usr/X11R6/bin/xdm ] || exit 0
prog=/usr/X11R6/bin/xdm
RETVAL=0
start () {
echo -n $"Starting $prog: "
# start daemon
daemon $prog
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/xdm
return $RETVAL
}
stop () {
echo -n $"Stopping $prog: "
killproc $prog
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/xdm
return $RETVAL
}
restart () {
stop
start
RETVAL=$?
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status $prog
RETVAL=$?
;;
restart)
restart
;;
condrestart)
# only restart if it is already running
[ -f /var/lock/subsys/xdm ] && restart || :
;;
reload)
echo -n $"Reloading $prog: "
killproc $prog -HUP
RETVAL=$?
echo
;;
*)
echo $"Usage: $0 (start|stop|restart|condrestart|reload|status)"
RETVAL=1
esac
exit $RETVAL
</screen>
</para>
</sect2>
<!-- Section2: The Chooser -->
<sect2 id="xdm-chooser">
<title>The Chooser Application</title>
<para>
When XDM receives an indirect query, and assuming that the appropriate options
have been specified in Xaccess for the 'chooser' application, it can
provide the user with a list of other XDM managed servers that it
knows about.
</para>
<para>
In this mode of operation, instead of the normal XDM login prompt,
the user will be presented with a 'chooser' application, which will
provide a list of detected hosts on the network that are currently
accepting XDM connections.
</para>
<para>
When I first tried the use the chooser, I found that the Xresources
files that came with my SuSE and Debian systems, specified a size for
the chooser widget that was too big for the screens ... The following
line from the Xresources file fixed that:
<screen>
Chooser*geometry: 700x500+300+200
</screen>
</para>
<para>
The chooser will obtain its lists of hosts by one of two methods:
<itemizedlist>
<listitem>
<para>
Broadcast Query: In this mode a request is broadcast over the network,
and a list is built up from the replies received from other application
servers running XDM.
</para>
</listitem>
<listitem>
<para>
Explicit Listing: It is possible to provide a list of hosts for
the chooser in the Xaccess file, as follows:
<screen>
%hostlist emma alex liam abigail
* CHOOSER %hostlist
</screen>
This will mean that the hosts emma, alex, liam and abigail will all be
listed as candidates - even if one of the machines is down
(there is often a button to 'ping' the host to see if it is
running, before trying to connect to it).
</para>
</listitem>
</itemizedlist>
</para>
<para>
Not that it is possible to include the localhost in the list of machines
known to the chooser as well. XDM should be configured not to startup on
the local console display though. Login should always be performed via
an indirect query to the local chooser application, then the localhost
should appear alongside any other hosts on the network.
</para>
</sect2>
<!-- Section2: XDM Alternatives -->
<sect2 id="xdm-alternatives">
<title>Alternatives to XDM</title>
<para>
Both KDE and Gnome have their own application to replace the standard
XDM. They do similar things and are well documented.
As far as providing remote X access, there is a single setting in the configuration
file for the application to enable XDMCP support.
</para>
<para>
<variablelist>
<varlistentry>
<term> KDM: KDE Display Manager
</term>
<listitem>
<para>
The following must be set in the KDM configuration file (/usr/share/config/kdm/kdmrc
for a Mandrake 8.1 system):
<screen>
[Xdmcp]
Enable=True
</screen>
</para>
</listitem
</varlistentry>
<varlistentry>
<term> GDM: Gnome Display Manager
</term>
<listitem>
<para>
The following must be set in the GDM configuration file (/etc/X11/gdm/gdm.conf):
<screen>
[Xdmcp]
Enable=True
</screen>
To have GDM running without starting the local X server, comment out the line
<screen>
0=Standard
</screen>
in the 'servers' section of the configuration file too.
</para>
</listitem
</varlistentry>
</variablelist>
</para>
</sect2>
</sect1>
<!-- Section1: Advanced Configuration -->
<sect1 id="xdm-advconfig">
<title>Advanced Configuration Options</title>
<indexterm>
<primary>disk!advanced</primary>
</indexterm>
<!-- Section2: Config Sets -->
<sect2 id="adv-configsets">
<title>Configuration Sets</title>
<para>
The xdm-config file provides a rich set of options, when it comes
to defined scripts and other configuration files. In many cases,
the defaults provided with your distribution should be fine, but
for those of you who want more ...
</para>
<para>
The names of the startup scripts and configuration files used by
XDM are determined by a series of statements in the top-level
xdm-config file. This permits you to configure a different set
of files for different X servers and X terminals, with different
abilities.
</para>
<para>
For example, say you are using XDM to manage your local display, but
also want it to accept queries from other X terminals on the network.
It is possible to specify a different Xresources file for each of these
cases, by using the following 2 lines in xdm-config:
<screen>
DisplayManager._0.resources /etc/X11/xdm/Xres_0
DisplayManager*resources /etc/X11/xdm/Xresources
</screen>
This will use Xres_0 for the local display (_0 is the XDM way of
saying :0) and Xresources for everything else (the '*').
</para>
<para>
Similarly, if you wanted a particular resource file for a specific
host, you would use an entry like the following:
<screen>
DisplayManager.host_0.resources /etc/X11/xdm/Xres_host_0
</screen>
</para>
<para>
Note that XDM configuration files use the terminology host_0, where you
would normally use host:0, to designate 'display 0 on host'.
</para>
<para>
If you look over your default xdm-config file, you will probably
find that it has been setup so that your local X server has different
files to the remote ones anyway, as different things must be performed
on startup and reset of the server. My Debian file has the following
for local servers:
<screen>
DisplayManager._0.resources: /etc/X11/xdm/Xresources_0
DisplayManager._0.setup: /etc/X11/xdm/Xsetup_0
DisplayManager._0.startup: /etc/X11/xdm/Xstartup_0
DisplayManager._0.reset: /etc/X11/xdm/Xreset_0
</screen>
and the following for remote servers:
<screen>
DisplayManager*resources: /etc/X11/xdm/Xresources
DisplayManager*setup: /etc/X11/xdm/Xsetup
DisplayManager*startup: /etc/X11/xdm/Xstartup
DisplayManager*reset: /etc/X11/xdm/Xreset
</screen>
</para>
</sect2>
<!-- Section2: X Resources -->
<sect2 id="x-resources">
<title>X Resources</title>
<para>
This document has only briefly touched on the available X resources, but
I should mention that it is possible to fully configure XDM via the Xresources
file.
</para>
<para>
The following may all be changed if required:
<itemizedlist>
<listitem>
<para> Fonts, login prompt sizes
</para>
</listitem>
<listitem>
<para> Background graphics
</para>
</listitem>
<listitem>
<para> Window Titles, etc
</para>
</listitem>
</itemizedlist>
</para>
<para>
There is a more detailed discussion of XDM resources, on Richard Kaszeta's web site
(see <xref linkend="resources">)
</para>
</sect2>
</sect1>
<!-- Section1: Common Configurations -->
<sect1 id="common-configs">
<title>Common Configurations</title>
<indexterm>
<primary>disk!advanced</primary>
</indexterm>
<!-- Section2: Linux to Linux -->
<sect2 id="cfgs-linux">
<title>Linux to Linux</title>
<sect3 id="cfgs-stdalonex">
<title>Stand-alone X Workstation</title>
<para>
This has already been mentioned several times in this document, but
in summary, it is a PC running XDM, with a single entry in the Xservers
file, relating to the localhost (i.e. the local machine).
</para>
<para>
This is usually the default configuration provided by most distributions
'out of the box'.
</para>
</sect3>
<sect3 id="cfgs-xtermapps">
<title>X Terminal and Application Server</title>
<para>
XDM runs on the application server:
<itemizedlist>
<listitem>
<para>
Xserver: Contains no entries
</para>
</listitem>
<listitem>
<para>
Xaccess: Must permit the X terminal to connect
</para>
</listitem>
</itemizedlist>
</para>
<para>
X terminal runs X using a direct query to the application server:
<screen>
/usr/X11R6/bin/X -query the.application.server
</screen>
</para>
</sect3>
<sect3 id="cfgs-mngexterm">
<title>Group of Managed X Terminals</title>
<para>
XDM runs on an application server:
<itemizedlist>
<listitem>
<para>
Xserver: Lists each X terminal to be managed
</para>
</listitem>
<listitem>
<para>
Xaccess: Must permit each X terminal to connect
</para>
</listitem>
</itemizedlist>
</para>
<para>
Each X terminal, just runs X, with suitable access control to
permit XDM to connect to it.
<screen>
/usr/X11R6/bin/X -ac
</screen>
</para>
</sect3>
</sect2>
<!-- Section2: Linux to Other -->
<sect2 id="cfgs-toother">
<title>Linux to Other Systems</title>
<para>
It is possible to use a Linux X terminal to connect to another
system running XDM. The same principles as above apply, but
the specifics of configuring XDM (or its equivalent) will be
specific to that system.
</para>
<sect3 id="cfgs-linsol">
<title> Linux and Solaris </title>
<para>
You can run X on a Linux box, instructing it to query
a Solaris machine as previously described:
<screen>
/usr/X11R6/bin/X -query the.solaris.server
</screen>
</para>
<para>
Note that you may have to configure X on the Linux
machine to use the font server from the Solaris box.
Although my Linux box connected and logged in fine without
doing this, the fonts used by CDE were not displayed
correctly.
</para>
<para>
I have not got this to work yet, as I don't have a
Solaris box that I have any control over - but I am
told that a font entry in /etc/XF86config similar to
the following should work - you may have to change the
port number from 7200 to something else (7100 has been
quoted at me before). Can anyone confirm that this works?
<screen>
FontPath "tcp/solaris.box:7200/all"
</screen>
</para>
</sect3>
<sect3 id="cfgs-linwin">
<title> Linux and Windows </title>
<para>
It is not possible to use X to remotely display Windows applications
on a Windows box. It is possible to use X to display Windows versions
of X applications on a Linux box, using a Windows X Server and Windows
X applications (for example the XFree86 Win32 port -
see <xref linkend="resources">)
</para>
<para>
It is possible to view Windows applications remotely on a Linux box
using one of the following applications (which don't rely on X or XDM):
<itemizedlist>
<listitem>
<para>
Windows Terminal Services (WTS). RDesktop is a Linux application that
understands the 'RDP' protocol used by WTS. This enables Linux to act
as a client to WTS (see <xref linkend="resources">).
</para>
</listitem>
<listitem>
<para>
Vitual Network Computing (VNC). This is an excellent platform independent
remote desktop system that provides a bi-directional 'Windows or Linux' to
'Windows or Linux' networked desktop. It can be a bit slow, but works
well (see <xref linkend="resources">).
</para>
<para>
You can actually do quite strange things with VNC, such has having multiple
machines connect and 'control' the desktop (and consequently 'fight' over
control of the mouse :). It also doesn't maintain any
state in the client, so you can leave your client, shutdown, bootup again,
reconnect and carry on from where you left off. There is even a version
of the viewer implemented as a Java applet, usable from any Java-enabled web
browser.
</para>
</listitem>
</itemizedlist>
</para>
</sect3>
</sect2>
<!-- Section2: Other to Linux -->
<sect2 id="cfgs-tolinux">
<title>Other Systems to Linux</title>
<para>
If you have an X server for your system, it should be able to connect
to a Linux XDM application server.
</para>
<sect3 id="cfgs-sollin">
<title>Solaris and Linux </title>
<para>
I assume that you would run XDM on the Linux box as usual, and
instruct X on Solaris to query the Linux box - does anyone have
any information on this?
</para>
</sect3>
<sect3 id="winlin">
<title> Windows and Linux </title>
<para>
If you have an X server for windows that supports XDMCP queries, then
it should be possible to configure it to query the Linux box. You should
just run XDM on the Linux box as usual.
</para>
<para>
There are many commercial X Server implementations for Windows, and I will
not list them all here. There is also a port of XFree86 to Windows, that
makes use of the cygwin libraries (used to port many GNU/Linux tools to
Windows - see <xref linkend="resources">). This works well.
</para>
<para>
The following batch file would start the cygwin XFree86 X server on
Windows and connect to a Linux box (or any OS/machine running XDM),
assuming a default installation of cygwin and XFree86 in c:\cygwin
(save it as xdm.bat):
<screen>
@echo off
if "%1"=="" goto noserver
goto allok
:noserver
echo Usage: xdm servername
goto end
:allok
set path=%PATH%;\cygwin\bin;\cygwin\usr\X11R6\bin
c:
chdir \cygwin\usr\X11R6\bin
XWin -query %1
:end
</screen>
</para>
</sect3>
</sect2>
</sect1>
<!-- Section1: resources -->
<sect1 id="resources">
<title>Resources</title>
<indexterm>
<primary>disk!resources</primary>
</indexterm>
<para>
This section lists some resources that have been consulted in order to
construct this document and which provide further details to the concepts
described.
</para>
<para>
Many of the references listed below form part of the Linux Documentation
Project (LDP): <ulink url="http://www.tldp.org/">
http://www.tldp.org/</ulink>
</para>
<para>
<variablelist>
<varlistentry>
<term> The X Window System
</term>
<listitem>
<para>
<itemizedlist>
<listitem>
<para>
X User Howto (from the
<ulink url="http://www.tldp.org/">LDP</ulink>)
</para>
</listitem>
<listitem>
<para>
Running Remote X Applications Mini Howto (from the
<ulink url="http://www.tldp.org/">LDP</ulink>)
</para>
</listitem>
<listitem>
<para>
Man pages: X (main concepts), Xserver (X server concepts)
</para>
</listitem>
<listitem>
<para>
X FAQ (on
<ulink url="http://www.x.org/">http://www.x.org/</ulink>)
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term> Thin-clients/X terminals
</term>
<listitem>
<para>
<itemizedlist>
<listitem>
<para>
Thin-client Howto Document (from the
<ulink url="http://www.tldp.org/">LDP</ulink>)
</para>
</listitem>
<listitem>
<para>
Linux Terminal Server Project:
<ulink url="http://www.ltsp.org/">http://www.ltsp.org/</ulink>
</para>
</listitem>
<listitem>
<para>
Setting up LTSP systems (using quiet hardware):
<ulink url="http://development.gbdirect.co.uk/xterminal.html">http://development.gbdirect.co.uk/xterminal.html</ulink>
</para>
</listitem>
<listitem>
<para>
Diskless Howto Document (from the
<ulink url="http://www.tldp.org/">LDP</ulink>)
</para>
</listitem>
<listitem>
<para>
X terminal pages:
<ulink url="http://dns.solucorp.qc.ca/xterminals">http://dns.solucorp.qc.ca/xterminals</ulink>
</para>
</listitem>
<listitem>
<para>
Richard Kaszeta: Converting old PCs into Standalone X Terminals:
<ulink url="http://www.menet.umn.edu/~kaszeta/unix/xterminal/">http://www.menet.umn.edu/~kaszeta/unix/xterminal/
</ulink>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term> XDM, XDMCP, etc
</term>
<listitem>
<para>
<itemizedlist>
<listitem>
<para>
Man pages: xdm
</para>
</listitem>
<listitem>
<para>
XDMCP Howto Document (from the
<ulink url="http://www.tldp.org">LDP</ulink>)
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term> Software
</term>
<listitem>
<para>
<itemizedlist>
<listitem>
<para>
Cygwin/XFree86 (Win32): <ulink url="http://www.cygwin.com/">http://www.cygwin.com/</ulink>
</para>
</listitem>
<listitem>
<para>
VNC: <ulink url="http://www.uk.research.att.com/vnc/">http://www.uk.research.att.com/vnc/</ulink>
</para>
</listitem>
<listitem>
<para>
rdesktop: <ulink url="http://www.rdesktop.org/">http://www.rdesktop.org/</ulink>
</para>
</listitem>
<listitem>
<para>
X Servers for Windows (and other systems): <ulink url="http://www.rahul.net/kenton/xsites.html">http://www.rahul.net/kenton/xsites.html</ulink>
</para>
</listitem>
<listitem>
<para>
GPL Java X Server: <ulink url="http://www.jcraft.com/weirdx/">http://www.jcraft.com/weirdx/</ulink>
</para>
</listitem>
<listitem>
<para>
X Terminal/Diskless specific distributions: <ulink url="http://lwn.net/Distributions/">http://lwn.net/Distributions/</ulink>
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect1>
</article>
View Git Blame Copy Permalink