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.
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.
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.
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
Section 7 for further information on the topics
discussed here.
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 Section 7).
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.
There are several configurations of 'X terminal' with varying levels
of functionality, ranging from completely diskless terminals to full
X workstations.
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.
- Diskless X terminal
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
Section 7
for some references that detail how to build diskless X terminals.
- Dumb X terminal
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.
- X Workstation
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.
- Application Server
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.
- X Server
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
Section 7
for more details.
- X Client
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).
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.
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.
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.
XDM would typically run on an application server, to permit users to logon
and run applications from that server.
There are 2 main ways that XDM can interact with an X Server:
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'.
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.
The query from the X server can take one of 3 forms:
Direct query: the X server contacts a named host, requesting that XDM
on that host presents a login prompt on its display.
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.
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.
There are several other options, but these will not be described here
- refer to the XDM and XDMCP documentation in Section 7
for more details.
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.
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.
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.
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.
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.
|
|