لطفا منتظر باشید ...
Using an XDMCP
Server
Assuming there are no obstructing firewalls
or other obstacles, any system running an X server may be used as a display for
any computer that can run X applications. Sometimes this isn't quite enough,
though; sometimes you want your X server to work just like a local X server
would, displaying a desktop environment that's controlled by the remote system.
The login procedure that uses Telnet, SSH, or other remote-access protocols can
also be a bit on the tedious side, particularly when you want to give complete
control to the remote system. These issues are both addressed by entirely
X-based login protocols, such as the X Display Manager Control Protocol
(XDMCP). Most Linux systems come with the software that's necessary to use
XDMCP as a server (on the X client side), but most configurations restrict
access to the XDMCP server to the local system. Reconfiguring the server allows
it to serve many XDMCP clients (X servers). It's possible to use a Linux system
as an XDMCP client, but this requires modifying the X configuration to use
XDMCP to present a login display that's generated remotely rather than locally.
Understanding XDMCP Operation
Preceding sections of this chapter have
presented a model of remote X use that involves using a remote login protocol
such as Telnet, running the Telnet server on the X client in order to establish
the initial connection and allowing the user to establish a reciprocal X
connection. XDMCP effectively replaces Telnet, SSH, or some other text-based
remote access protocol. When a user connects to a remote system with Telnet,
the Telnet server launches a login process and, ultimately, a text-based shell.
The textual data from these processes pass back over the Telnet session to the
client system. XDMCP is similar in some ways, but instead of launching a
text-based shell, the XDMCP server initiates an X-based login process,
including a GUI login prompt and the launching of the user's normal window
manager, desktop environment, and so on. These programs run through a
reciprocal X connection; XDMCP automatically configures both the client and the
server via xauth , and sets the DISPLAY environment variable appropriately. In short, XDMCP automates many
of the login steps described earlier.In fact, the XDMCP server isn't used only for
remote X connections; it's used by Linux computers that are configured to boot
directly into X. When so configured, the XDMCP server runs and connects
directly to the X server, creating a GUI login prompt such as the one shown in
the XDMCP server creates this prompt, it differs from one server to another; in
fact, it can be customized, and so varies from one distribution to another.
Figure 14.2. An XDMCP
server's login prompt lets you enter your username, password, and sometimes
additional information, such as the desktop environment or window manager you
want to use.
Configuring a Login Server to Accept Connections
XDMCP servers are configured through files
that are typically stored in the /etc directory tree, and usually in /etc/X11 . Most
distributions ship in such a way that their servers are only accessible from
the localhost as a security precaution. If you want to permit remote XDMCP
logins, you must loosen this configuration. In addition, you must ensure that
the XDMCP server is running. There are three XDMCP servers commonly used in
Linux: The original X Display Manager (XDM) and the newer KDE Display Manager
(KDM) and GNOME Display Manager (GDM).
XDM Configuration
XDM is the oldest and simplest of the popular
XDMCP servers. Unlike GDM and KDM, XDM has no link to any Linux desktop
environment. It allows users to enter their usernames and passwords, but no
additional information, such as what window managers they want to use. Instead,
users' login parameters are controlled through the .xsession files in their
home directories. (This script is run from the global Xsession script, normally found in /etc/X11 or /etc/X11/xdm ). Users' .xsession files normally end with a line that starts a window manager or
desktop environment; when the script terminates (after the user logs out, thus
terminating the window manager), the X session ends, and XDM terminates the
remote link or (on a local display) redisplays the login prompt.
Adjusting XDM's Availability
XDM's availability to nonlocal systems is
controlled through its main configuration file, /etc/X11/xdm/xdm-config . Specifically,
many distributions ship with a line like the following: DisplayManager.requestPort: 0
This line tells XDM not to listen on its
usual port (UDP port 177) for external connection requests. You should comment
out this line by adding a pound sign ( # ) to its start if you
want to allow others to use XDMCP to log onto the computer.In addition to editing xdm-config ,
you may need to adjust the /etc/X11/xdm/Xaccess file. This file indicates the specific computers that may access
the XDM server. This file consists of a series of lines, each of which contains
a host specification followed by an indication of what type of access the host
is allowed. (Lines that begin with pound signs are comments, and are ignored.) If
the access type is not specified, the clients are permitted direct access,
which is the most important type. Other common options include CHOOSER , which
causes XDM to display a list of other computers that have XDMCP servers running
on the local network when the XDMCP client sends a so-called indirect query; and BROADCAST , which is
generally used in conjunction with CHOOSER to tell the
chooser to broadcast a query for other XDMCP servers when the system receives
an indirect request. An asterisk ( * ) as the host list causes XDM to allow
any host to connect. For instance, the following entries allow any computers to
connect to the system directly or use it as an indirect server, to obtain a
list of local XDMCP servers: * * CHOOSER BROADCAST
If you want to restrict access to certain
hosts, you should create lines that list those hosts, and eliminate the
asterisk entry. You may also use an asterisk as part
of a name to grant access to a domain. For instance, the following
system allows only the members of one domain and two outside computers to
connect to the XDMCP server for remote logins, and only the outside systems for
indirect queries: *.threeroomco.com bronto.pangaea.edu stego.pangaea.edu bronto.pangaea.edu CHOOSER BROADCAST stego.pangaea.edu CHOOSER BROADCAST
NOTE
align=left border=0> It's possible to configure a computer to
not accept XDMCP connections through means other than the XDM configuration
files. For instance, a computer's firewall rules (described in
Configuring iptables) could block access to a server.
Setting
Displays XDM is to Manage
The /etc/X11/xdm/Xservers file specifies a list of displays that XDM is to manage. When XDM
starts, it tries to connect directly to these displays, presenting a login
screen for them. By default, this file contains a line similar to the following
(the details differ from one distribution to another): :0 local /usr/X11R6/bin/X
This line tells the system to connect to and manage the local
display ( :0 ). Thus, XDM manages
the local X display, starting X in the process if necessary. (This is the
reason that starting XDM in a SysV startup script or the like launches X.) If
you want XDM to directly manage the displays of remote systems such as X
servers without using an intervening login prompt, you can list those systems
here: term.threeroomco.com:0 foreign
The foreign
specification tells XDM that this is a remote system, and to contact it as
such. Of course, that system must be configured to allow the XDMCP server to
connect to it and display the login prompt. Another reason to edit the Xservers file is to remove the default local
specification. If you do this, the computer won't launch X locally when you
start XDM. This might be useful if you want to use a powerful central system
via remote X terminals or the like. Such a system might run many X programs,
but have no need of an X server running locally.NOTE
align=left border=0> You do not need to tell XDM
to manage a display if you can configure that server to locate XDMCP servers,
as described in the upcoming section, "
You should tell XDM to manage a display only if the X server in question
should be used only to connect to the
computer on which XDM is running. You might use this approach with an X
terminal that connects to just one computer, for instance.
KDM Configuration
KDM is designed as a "drop-in" replacement for XDM,
but KDM offers expanded capabilities. Of most interest to most users, KDM
offers a clickable list of usernames, a Session Type list box in which users
may enter a window manager or desktop environment, and a Quit or Shutdown
button to exit from the local X server (when run remotely) or shut down the
computer (when run locally).
should refer to the preceding section, "
setting up KDM to accept remote logins. Some of KDM's additional features
require configuration above and beyond that of XDM, though. These features are
controlled through the kdmrc
file, which is stored in different locations on different distributions. Common
locations include /opt/kde2/share/config
and /usr/share/config . Options
in this file control the size of the login window, the GUI style, and so on.
One of the most important of these options is called SessionTypes . It determines the names of
the session types displayed for usersthat is, the window managers or desktop
environments from which they can select. If you add session types to this list,
you must also add them to the Xsession
or Xsession.d file in /etc/X11 or /etc/X11/xdm . Unfortunately, deciphering this file is
tedious at best, and it differs from one distribution to another. Look for
lines that use the variable SESSION
or something similar. Some distributions ship with a tool called chksession , which can automatically add
window managers or desktop environments to both KDM and GDM configurations if the window manager or desktop environment ships
with appropriate configuration files. In most cases, it's simpler for users to
customize their environments as they do in XDM, by editing the .xsession files in their home directories.
Users must select a specific KDM session entry, usually called Default, to have
the system use this file.
GDM
Configuration
GDM is GNOME's entry to the display manager race. Like KDM, it
offers users features such as the ability to select from among several desktop
environments and the ability to terminate a remote X session or shut down the
local computer. Unlike KDM, GDM uses its own configuration files, which are
normally stored in /etc/X11/gdm .
The most important of these files is gdm.conf .Systems that use GDM, like those that use most other XDMCP
servers, ship with the server configured to not
accept logins from remote servers. You can change this by locating the [xdmcp] section in gdm.conf and altering one or two entries.
Most importantly, you should change the line that reads Enable=0 to read Enable=1 . If you want GDM to provide a
list of other XDMCP-enabled computers to X terminals or the like, you should
also change the HonorIndirect=0
line to read HonorIndirect=1 .If you want to run GDM for remote access without starting X
locally, you can do so by commenting out the local servers in the [servers] section. Normally, this section
contains an entry like the following: 0=/usr/bin/X11/X
This entry tells GDM to start X (the program /usr/bin/X11/X , to be precise) to manage
the first X session, much like the default Xservers
configuration for XDM or KDM. Commenting out this entry causes GDM to run
without managing the local display, or starting X if it's not already running.Like KDM, GDM gives users a choice of window managers or
desktop environments. (In GDM, these choices are accessible from the Session
menu.) You can add or delete sessions by creating appropriate scripts in the /etc/X11/gdm/Sessions directory. The
default scripts usually call /etc/X11/xdm/Xsession ,
sometimes passing it a parameter to indicate what environment should be
launched. You might therefore have to edit this script, or create one that does
some of the same job, but add the capability to launch whatever new window
manager or desktop environment you want to use. Alternatively, on most systems,
users can edit their .xsession
files to customize their startup environments.
Running
an XDMCP Server
Running an XDMCP server is normally accomplished by setting
the computer to start X and accept GUI logins automatically. Most distributions
reserve runlevel 5 for this purpose, but some use other runlevelsspecifically,
SuSE prior to version 7.2 uses runlevel 3 for GUI logins, and Slackware uses
runlevel 4. Debian and its derivatives try to start X in all multi-user
runlevels.You can set the default runlevel in /etc/inittab by editing a line that
resembles the following: id:5:initdefault:
Most distributions include comments preceding this line that
describe the purpose of various runlevels. The number in the second
colon-delimited field is the runlevel that the system enters when it boots. If
this number is associated with the computer starting X, then the XDMCP server
will also run.You can change runlevels with the telinit command. For instance, telinit 5 changes to runlevel 5. This
change remains in effect until you issue another telinit command or reboot the computer.TIP
align=left border=0> If you make changes to your XDMCP server's configuration,
one way to implement those changes is to use telinit
to switch out of the X runlevel and into a text-mode runlevel, then switch
back to the X-related runlevel. Another method is to use kill or killall
to stop the XDMCP server, then run it again. You can use the SIGHUP signal to cause the XDMCP server
to reread its configuration files without exiting. (When the XDMCP server
exits, it normally terminates the local X display.)
Each distribution has its default XDMCP server, but you can reconfigure
any distribution to use any XDMCP server. Different distributions use different
methods to specify which XDMCP server is run. Methods of selecting the XDMCP
server include the following: prefdm
Some distributions, such as Red Hat and Mandrake, use a script called prefdm (usually stored in /etc/X11 ) to launch the XDMCP server. This
script in turn loads the contents of the file called /etc/sysconfig/desktop to determine the
default desktop environment and XDMCP server. Common values of this file
include KDE , GNOME , and AnotherLevel , which result in KDM, GDM, and XDM as the
XDMCP servers, respectively. SysV startup script Debian and
its derivatives start the XDMCP server through a standard SysV startup script,
such as /etc/init.d/ xdm . You
can edit or replace this file to have the system use a different XDMCP server,
as described in
similar method, but its xdm
startup script starts a specific XDMCP server according to the value of the DISPLAYMANAGER environment variable, which
is set in /etc/rc.config . Other startup scripts
Slackware uses the /etc/rc.d/rc.4
script to start the XDMCP server. As described in
quite the same way as most other Linux distributions, but the rc.4 script is conceptually similar to the
xdm SysV startup script of
Debian or SuSE. Caldera uses a similar approach, but calls its startup script /etc/rc.d/rc.gui . The Slackware script is
hard-coded to try to use KDM, then GDM, then XDM; the Caldera script only
starts KDM. You can edit the script to change this order or add other XDMCP
servers, if you like.
Configuring
a Remote X Login Client
As with other protocols, an XDMCP server alone isn't useful;
it must be matched with one or more XDMCP clients. These clients are normally
built into or included with X servers or X terminals. The XDMCP client may
contact an XDMCP server directly, or it may present a list of available X
servers, as shown in
Xmanager (http://www.netsarang.com ) X server for
Windows. When you select a computer and click Connect (or your chooser's
equivalent), you'll see an XDMCP login display such as the one shown in
will either take over your entire display or open a large window in which your
X desktop will appear, depending upon the X server's capabilities and
configuration.
Figure 14.3. A chooser displays a
list of available XDMCP servers; you select one to run X programs hosted on
that computer.
which you can configure their XDMCP operation.
Xmanager. Of particular interest are the radio buttons in the top half of the
dialog box. These may be called slightly different things in different
programs, but they illustrate methods the XDMCP client that's built into the X
server may use to create the initial connection to the XDMCP server: Do Not Use XDM (Passive) This
method requires that you initiate a manual connection from the X server
computer using Telnet or some other login technique, or that you configure the
XDMCP server to manage the X server's display (as for instance by creating a foreign entry in the /etc/X11/xdm/Xservers file, as described
earlier). If you elect the latter option, the XDMCP server will try to create a
login window on the X server computer when the XDMCP server starts. If you
restart the X server, though, this login window will disappear and may not
reappear until you restart the XDMCP server. XDM Query This option causes
the X server to send a login query directly to the specified host, whose name
or IP address you must enter. This server presents an XDMCP login display such
as that shown in
You can't log directly into another computer if you use this option. This
option is similar to the preceding one in many ways, but XDM Query causes the X
server to query the XDMCP server whenever the X server starts up, which is
usually a more sensible behavior than having the XDMCP server manage the X
server. XDM Broadcast If you're on a
local network with several X servers, this option may be the best one. It
causes the X server to send out a broadcast query to locate all the XDMCP
servers on its local network, and to display a list of the servers, as shown in
broadcast to just some addresses (the Register Hosts to Search button in
useful if you want to allow users to log into any of several computers that are
on a remote network. Enter the name or IP address of an XDMCP server on that
network, and the X server connects to this system to obtain a list of servers.
The XDMCP server must be configured to accept indirect queries, though, as
described in the preceding sections.
Figure 14.4. Most XDMCP clients
provide several options for how to locate and interact with XDMCP servers.
can present a list of available XDMCP servers. You can have XFree86 on Linux do
the same thing, although in this case you tell it to do so by starting X in
different ways. Specifically, you use the -query host.name ,
-broadcast , and -indirect host.name options, as in: $ /usr/X11R6/bin/X -indirect xdmcp-server.threeroomco.com
These options work much like those in Windows
X servers, as just described, with one major exception: The XFree86 -broadcast option doesn't present a chooser list; it connects to the first XDMCP server
that responds to the query, allowing you to log into that computer only.TIP
align=left border=0> If you want to configure a Linux computer
as a dedicated X terminal, you can do so. You should configure it so that X
does not start automatically via the XDMCP
serverthat is, run Linux in text mode. You can then create a custom startup
script or SysV startup script that runs X with an appropriate -query , -broadcast ,
or -indirect option. If you want to see a list of available local servers,
you'll need to configure one regular XDMCP server as an indirect server and
use the -indirect option when starting X. Used in this way, even an old 386 system
can make an adequate X terminal.
