mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
b470d06dbd
commit
4c7a843ff6
|
@ -8,7 +8,7 @@
|
||||||
name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl"
|
name="Vincent Zweije">, <htmlurl url="mailto:zweije@xs4all.nl"
|
||||||
name="zweije@xs4all.nl">
|
name="zweije@xs4all.nl">
|
||||||
|
|
||||||
<date>11 July 2000
|
<date>13 November 2000
|
||||||
|
|
||||||
<abstract>
|
<abstract>
|
||||||
|
|
||||||
|
@ -16,8 +16,9 @@ This mini-HOWTO describes how to run remote X applications. That is, how
|
||||||
to have an X program display on a different computer than the one it's
|
to have an X program display on a different computer than the one it's
|
||||||
running on. Or conversely: how to make an X program run on a different
|
running on. Or conversely: how to make an X program run on a different
|
||||||
computer than the one you're sitting at. The focus of this mini-HOWTO
|
computer than the one you're sitting at. The focus of this mini-HOWTO
|
||||||
is on security. This mini-HOWTO also contains information on running
|
is on security. This mini-HOWTO also contains information on running X
|
||||||
X applications locally, but with a different user-id.
|
applications locally, but with a different user-id, and information on
|
||||||
|
setting up a computer as an X terminal.
|
||||||
|
|
||||||
</abstract>
|
</abstract>
|
||||||
|
|
||||||
|
@ -54,12 +55,12 @@ name="http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps">. Linux
|
||||||
url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html"
|
url="http://sunsite.unc.edu/LDP/HOWTO/HOWTO-INDEX-2.html"
|
||||||
name="sunsite.unc.edu">.
|
name="sunsite.unc.edu">.
|
||||||
|
|
||||||
This is version 0.6.3. No guarantees, only good intentions. I'm open
|
This is version 0.7.0. No guarantees, only good intentions. I'm open
|
||||||
to suggestions, ideas, additions, useful pointers, (typo) corrections,
|
to suggestions, ideas, additions, useful pointers, (typo) corrections,
|
||||||
etc... I want this to remain a simple readable document, though, in the
|
etc... I want this to remain a simple readable document, though, in the
|
||||||
best-meant HOWTO style. Flames to <tt>/dev/null</tt>.
|
best-meant HOWTO style. Flames to <tt>/dev/null</tt>.
|
||||||
|
|
||||||
Contents last updated on 11 July 2000 by <htmlurl
|
Contents last updated on 13 November 2000 by <htmlurl
|
||||||
url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije">
|
url="http://www.xs4all.nl/~zweije/index.html" name="Vincent Zweije">
|
||||||
|
|
||||||
<sect> Related Reading
|
<sect> Related Reading
|
||||||
|
@ -687,6 +688,254 @@ the window manager runs. If you run a remote window manager, it will
|
||||||
spawn remote applications, and this may not be what you want. Of course,
|
spawn remote applications, and this may not be what you want. Of course,
|
||||||
they still display on the display that is local to you.
|
they still display on the display that is local to you.
|
||||||
|
|
||||||
|
<sect> Setting Up an X Terminal
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Make use of your old PC! Turn it into an extra work place! No need
|
||||||
|
for buying expensive new hardware! You've already got all it takes!
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Seriously, you can set up an old PC as an X terminal. An X terminal
|
||||||
|
is a computer that basically runs nothing but an X server. You can log
|
||||||
|
in on it, and get an X session, with xterms, xbiff, xclock, every other
|
||||||
|
conceivable X client. However, all clients are running on a remote host,
|
||||||
|
and are using remote X to display their output on your local X terminal.
|
||||||
|
Even the window manager is running remotely.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
An X terminal takes very few resources, compared to a full blown unix
|
||||||
|
machine. Over here I have an X terminal with a 486 CPU, 16M of RAM,
|
||||||
|
and 250M of disk space. Oh, and a network connection, of course.
|
||||||
|
It doesn't even have user home directories.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
For some related reading, have a look at
|
||||||
|
the Xterminal mini-HOWTO, for example at <htmlurl
|
||||||
|
url="http://metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/mini/Xterminal"
|
||||||
|
name="http://metalab.unc.edu/pub/Linux/docs/HOWTO/unmaintained/mini/Xterminal">.
|
||||||
|
It is currently unmaintained, but it might contain some useful information
|
||||||
|
for you.
|
||||||
|
|
||||||
|
<sect1> Once More, a Little Theory First
|
||||||
|
|
||||||
|
<p>
|
||||||
|
As far as X is concerned, the X terminal will be running nothing but an
|
||||||
|
X server. This X server will be configured to talk to a remote host
|
||||||
|
using XDMCP (the X Display Manager Control Protocol). It will ask
|
||||||
|
the remote host for an X session. The remote host will put up a login
|
||||||
|
window on the X terminal, and after login it will run an X session with
|
||||||
|
all bells and whistles, including the window manager, all using remote
|
||||||
|
X to display on the X terminal.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
You will probably notice that the remote host is acting like a server,
|
||||||
|
though not an X server. The remote host is providing X sessions to X
|
||||||
|
servers that ask for one. So, with respect to XDMCP, the remote host is
|
||||||
|
actually a server, providing X sessions, also known as an XDMCP server.
|
||||||
|
The X server is playing the role of an XDMCP client! Are you still
|
||||||
|
with me?
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The program that provides the XDMCP service on the XDMCP server is
|
||||||
|
<tt/xdm/. So, in order to get an X terminal up and running, you must
|
||||||
|
configure two programs: <tt/X/ (the XDMCP client) on the X terminal,
|
||||||
|
and xdm (the XDMCP server) on the remote host.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
You must always remember that the X protocol (and the XDMCP protocol)
|
||||||
|
are not encrypted. If you use remote X, everything that goes over the
|
||||||
|
network can be sniffed by other hosts on the network. This is especially
|
||||||
|
bad with remote X sessions, since the first thing that happens is logging
|
||||||
|
in by giving a username and password. So, you must run remote X over
|
||||||
|
a trusted network only!
|
||||||
|
|
||||||
|
<sect1> Configuring <tt/X/ as an XDMCP Client
|
||||||
|
|
||||||
|
<p>
|
||||||
|
If you want to set up a Linux machine as an X terminal, you need very
|
||||||
|
few resources. Basically, you need what it takes to get a bare bones
|
||||||
|
Linux machine running, plus an X server. Specifically, you do <em/not/
|
||||||
|
need the X clients and libraries. It can be useful to install some X
|
||||||
|
fonts, but you can also use a font server somewhere on the network.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
There are a few ways for an X server to get an X session from an XDMCP
|
||||||
|
server. The simplest one is to go straight to a known XDMCP server and
|
||||||
|
ask for one. Alternatively, the X server can broadcast a request for
|
||||||
|
an XDMCP service and use the first XDMCP server that responds. Lastly,
|
||||||
|
the X server can go to an XDMCP server, ask it for a list of hosts
|
||||||
|
willing to provide a session, and let the user choose a session host.
|
||||||
|
|
||||||
|
<enum>
|
||||||
|
|
||||||
|
<item>
|
||||||
|
When you know the host that is going to provide you with sessions,
|
||||||
|
go straight to it. Run
|
||||||
|
<tscreen><verb>
|
||||||
|
X -query sessionhost
|
||||||
|
</verb></tscreen>
|
||||||
|
and, assuming <tt/xdm/ is running on <tt/sessionhost/, you'll get a
|
||||||
|
login window, and after login, an X session.
|
||||||
|
|
||||||
|
<item>
|
||||||
|
When you don't really care on which host you're getting your session,
|
||||||
|
use the broadcast method. Run
|
||||||
|
<tscreen><verb>
|
||||||
|
X -broadcast
|
||||||
|
</verb></tscreen>
|
||||||
|
and, assuming <tt/xdm/ is running somewhere on the network, you'll get
|
||||||
|
a login window from the first (and hopefully quickest) <tt/xdm/ that
|
||||||
|
responds, and after login, an X session.
|
||||||
|
|
||||||
|
<item>
|
||||||
|
When you want to choose the host where you want to have your session,
|
||||||
|
ask an XDMCP server for a list. Run
|
||||||
|
<tscreen><verb>
|
||||||
|
X -indirect xdmcpserver
|
||||||
|
</verb></tscreen>
|
||||||
|
and, assuming <tt/xdm/ is configured right there, you'll be presented a
|
||||||
|
list of hosts to choose from. Choose one; you'll get the login window
|
||||||
|
for that host, and after login, the session you were looking for.
|
||||||
|
|
||||||
|
</enum>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
You may have noticed the absence of the <tt/-auth/ option. The X
|
||||||
|
server will use XDMCP to negotiate a magic cookie with the XDMCP server.
|
||||||
|
The XDMCP server will put the cookie in your remote <tt>~/.Xauthority</tt>
|
||||||
|
after login.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
After a session is over, the X server will loop and go back to the
|
||||||
|
original XDMCP server and ask for another session (or chooser list).
|
||||||
|
If you don't want that, you can use the <tt/-once/ option. Note:
|
||||||
|
this doesn't seem to work with the <tt/-indirect/ option due to the
|
||||||
|
implementation of the chooser.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
When you have determined the way in which you want to run the
|
||||||
|
X server, you can also put it in a startup script, or even run
|
||||||
|
it straight from <tt>/etc/inittab</tt>. Please consult your own
|
||||||
|
distribution's documentation for how to modify your startup scripts
|
||||||
|
or <tt>/etc/inittab</tt>.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Do <em/not/ run an X server like this from the <tt/Xservers/ configuration
|
||||||
|
file. <tt/xdm/ expects to be able to connect to such servers, and may
|
||||||
|
kill them if it can't connect.
|
||||||
|
|
||||||
|
<sect1> Configuring <tt/xdm/ as an XDMCP Server
|
||||||
|
|
||||||
|
<p>
|
||||||
|
The program that provides the XDMCP service (the session service) is
|
||||||
|
usually <tt/xdm/. There are variants of this such as <tt/wdm/ or <tt/gdm/
|
||||||
|
on Linux, but these basically work the same way. So, make sure <tt/xdm/
|
||||||
|
or variant is installed on the host where you want to run your X sessions.
|
||||||
|
If you've got a local graphical login on the X session host, <tt/xdm/
|
||||||
|
is already installed; most Linux distributions come that way these days.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
In addition to <tt/xdm/, you will need the programs that you wish to be
|
||||||
|
able to run in an X session. That is, all X clients like <tt/xterm/,
|
||||||
|
<tt/xfig/, <tt/xclock/, window managers and all that. However, for an
|
||||||
|
XDMCP server, you do <em/not/ have to install an X server; the X server
|
||||||
|
will be running on the X terminal instead.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
From the X server story above, you can conclude that there are
|
||||||
|
basically two kinds of XDMCP service. There is the <em/direct/ service,
|
||||||
|
consisting of letting an XDMCP client log in, and then providing it
|
||||||
|
with an X session. Alternatively, there is the <em/indirect/ service,
|
||||||
|
in which an XDMCP client is provided with a list of hosts, providing a
|
||||||
|
direct service, to choose from.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
All <tt/xdm/ services are configured in the access file, generally
|
||||||
|
located at <tt>/etc/X11/xdm/Xaccess</tt> or a similar location. This
|
||||||
|
location is actually defined in the general <tt/xdm/ configuration file
|
||||||
|
<tt>/etc/X11/xdm/xdm-config</tt>, through the <tt/accessFile/ resource.
|
||||||
|
See your <tt/xdm/ manual for the default location.
|
||||||
|
|
||||||
|
<enum>
|
||||||
|
|
||||||
|
<item>
|
||||||
|
<p>
|
||||||
|
If you want to allow <tt/xdm/ to provide connecting XDMCP clients with an
|
||||||
|
X session, whether by broadcast or not, you put the host name of the XDMCP
|
||||||
|
client (the X server, remember?) by itself on a line in <tt/Xaccess/.
|
||||||
|
Actually, you can put a pattern on the line matching multiple hosts.
|
||||||
|
Here are some valid patterns:
|
||||||
|
<tscreen><verb>
|
||||||
|
xterm023.my.domain # xterm023.my.domain can get an X session
|
||||||
|
*.my.domain # any host in my.domain can get an X session
|
||||||
|
* # any host on Internet can get an X session (unsafe)
|
||||||
|
</verb></tscreen>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Whether you should want to provide any host in Internet with an X
|
||||||
|
session is arguable. Obviously, any service you provide is one more
|
||||||
|
possible hole in your server's security. On the other hand, the server
|
||||||
|
should be secure itself, and an XDMCP client asking for an X session
|
||||||
|
has to privide a valid authentication before the X session is granted.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Furthermore, the X session uses a remote X connection, which is
|
||||||
|
not encrypted. The username/password pair for the login will be
|
||||||
|
transported on this connection. People out there could be sniffing valid
|
||||||
|
username/password combinations, just as with plain telnet connections.
|
||||||
|
This is even worse then having xauth magic cookies sniffed.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Make your own decisions here, but I recommend not enabling this service
|
||||||
|
to the world unless you have a good reason.
|
||||||
|
|
||||||
|
<item>
|
||||||
|
<p>
|
||||||
|
If you want to provide XDMCP clients (<tt/X -indirect xdmcpserver/) with a
|
||||||
|
chooser list (a list of hosts to choose from to get an X session), follow
|
||||||
|
the client pattern with the keyword <tt/CHOOSER/ and the list of hosts
|
||||||
|
that that client may choose from. Instead of the list of hosts to choose
|
||||||
|
from, you can also specify <tt/BROADCAST/; with this, <tt/xdm/ broadcasts
|
||||||
|
on the network to query for servers willing to provide the session. Some valid examples:
|
||||||
|
<tscreen><verb>
|
||||||
|
xterm023.my.domain CHOOSER seshost1 seshost2
|
||||||
|
*.my.domain CHOOSER BROADCAST
|
||||||
|
* CHOOSER extseshost1 extseshost2
|
||||||
|
</verb></tscreen>
|
||||||
|
The first lets <tt/xterm023/ choose between sessions on either
|
||||||
|
<tt/seshost1/ and <tt/seshost2/. The second lets any host in
|
||||||
|
<tt/my.domain/ choose from any host that is willing to provide an
|
||||||
|
X session. The third lets any host out there choose between a session
|
||||||
|
on <tt/extseshost1/ or <tt/etsseshost2/.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
It is probably not a good idea to do <tt/* CHOOSER BROADCAST/. This will
|
||||||
|
allow hosts outside your network to get information about the hosts inside
|
||||||
|
your network. You probably don't want to pass out such information.
|
||||||
|
In fact, allowing a chooser to any outside host is probably not useful
|
||||||
|
anyway, since you should not be enabling arbitrary direct connections
|
||||||
|
either.
|
||||||
|
|
||||||
|
</enum>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
When you have reconfigured <tt/xdm/, send it the <tt/HUP/ signal to make
|
||||||
|
it re-read its configuration files.
|
||||||
|
<tscreen><verb>
|
||||||
|
# kill -HUP pid-of-xdm
|
||||||
|
#
|
||||||
|
</verb></tscreen>
|
||||||
|
|
||||||
|
<sect1> XDMCP Technically
|
||||||
|
|
||||||
|
<p>
|
||||||
|
Technically, as far as I can see, XDMCP is not entirely what you would
|
||||||
|
expect from the above description. <tt/xdm/ can redirect connecting X
|
||||||
|
servers to another place, and uses this trick to implement the chooser.
|
||||||
|
So, the choosing happens inside xdm, not in the X server, although the
|
||||||
|
chooser list is represented on the X server's display. This is also
|
||||||
|
why the X server's <tt/-once/ option does not combine with <tt/-indirect/.
|
||||||
|
|
||||||
<sect> Troubleshooting
|
<sect> Troubleshooting
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
Loading…
Reference in New Issue