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="zweije@xs4all.nl">
|
||||
|
||||
<date>11 July 2000
|
||||
<date>13 November 2000
|
||||
|
||||
<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
|
||||
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
|
||||
is on security. This mini-HOWTO also contains information on running
|
||||
X applications locally, but with a different user-id.
|
||||
is on security. This mini-HOWTO also contains information on running X
|
||||
applications locally, but with a different user-id, and information on
|
||||
setting up a computer as an X terminal.
|
||||
|
||||
</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"
|
||||
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,
|
||||
etc... I want this to remain a simple readable document, though, in the
|
||||
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">
|
||||
|
||||
<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,
|
||||
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
|
||||
|
||||
<p>
|
||||
|
|
Loading…
Reference in New Issue