LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

new

This commit is contained in:
gferg 2001-03-20 22:35:08 +00:00
parent f25d1fade3
commit b0994907bc
2 changed files with 917 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

519
LDP/howto/docbook/Remote-Serial-Console-HOWTO.sgml Normal file
View File

@ -0,0 +1,519 @@
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<article>
<!-- Header -->
<artheader>
<!-- title of HOWTO, include the word HOWTO -->
<title>Remote Serial Console HOWTO</title>
<author>
<firstname>Mark</firstname>
<othername>F.</othername>
<surname>Komarinski</surname>
<affiliation>
<address>
<email>mkomarinski@valinux.com</email>
</address>
</affiliation>
</author>
<revhistory>
<revision>
<revnumber>0.1</revnumber>
<date>2001-03-20</date>
<authorinitials>mfk</authorinitials>
<revremark>
First revision
</revremark>
</revision>
<!-- Additional (*earlier*) revision histories go here -->
</revhistory>
<abstract>
<indexterm>
<primary>abstract</primary>
</indexterm>
<para>
Most UNIX-based systems have the concept of a serial console.
Linux is no exception to this, and this document covers how to
set up your hardware to use a serial console.
</para>
</abstract>
</artheader>
<section id="intro">
<title>Introduction</title>
<section id="copyright">
<title>Copyright Information</title>
<para>
This document is copyrighted (c) 2001 Mark F. Komarinski 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>
</section> <!-- copyright -->
<section 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>
</section> <!-- disclaimer -->
<section id="credits">
<title>Credits</title>
<para>
This HOWTO is based on
<filename>/usr/src/linux/Documentation/serial-consold.txt</filename>,
written by Miquel van Smoorenburg (<email>miquels AT cistron.nl</email>).
Many thanks to Miquel for the information in his document.
</para>
</section> <!-- credits -->
<section 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>mkomarinski AT valinux.com</email>.
</para>
</section> <!-- feedback -->
</section> <!-- introduction -->
<section id="whyserial">
<title>Why use Serial Consoles?</title>
<para>
Serial consoles do not appear to have much going for
them. They are slow, require special null-modem cables,
and do not provide a graphical interface. But what is
going for them is considerable. Serial cables are
standard equipment and can run over RJ-45 cables,
can run up to 200 ft (about 100m) at 9600bps.
Serial concentrators can run the consoles of over 32
ports into a central box, so all the consoles in a
cluster can be accessed from a single location.
</para>
<para>
You will not require a crash cart, KVM switch, or keyboard,
montior, or mouse. Because of the serial concentrator, you can
access the console of a machine in a colocation cage from
your desktop.
</para>
<para>
The real limiting factor so far has been that even though you can
access the Linux console via a serial port, most x86 hardware was
not set to send its POST and BIOS information to the serial port.
More and more <quote>server</quote> motherboards are starting to
include full serial support in the BIOS, so you can access the
BIOS and make boot changes via the serial port.
</para>
</section> <!-- whyserial -->
<section id="configuration">
<title>Configuring Linux for Serial Consoles</title>
<para>
There is two parts to getting a serial console set up under
Linux. First, you must tell Linux to redirect its console output
to the serial port. Second, you must set up mgetty to start
a login process on the serial port once the kernel has completed booting.
Some distributions use mingetty for the video console, but mingetty
has no serial port support. You will instead want to use mgetty.
A third (optional) configuration is to set the hardware BIOS to redirect
its POST and BIOS information to the serial port. Check your motherboard
documentation for more information about this.
</para>
<section id="configurationkernel">
<title>Configuring LILO and the Linux Kernel</title>
<para>
If you're using LILO as your bootloader, you can quickly test
using serial console from Linux by entering:
</para>
<screen>
LILO: Linux console=ttyS0,9600n8
</screen>
<para>
Assuming the LILO tag for your Linux kernel is called
<quote>Linux</quote>. Change this for the name of your kernel.
The generic format for the console option is console=device,options.
You can give multiple console statements, and kernel messages will go to
all listed devices, but the last one listed will be used as
<filename>/dev/console</filename>.
</para>
<informaltable>
<tgroup cols="2">
<tbody>
<row>
<entry>device</entry>
<entry>The device entry to use as the console without
<filename>/dev/</filename>. You can use tty0 to get normal behavior,
ttyx to put the console on another virtual console, or ttySx to put
the console on a serial port.</entry>
</row>
<row>
<entry>options</entry>
<entry>This is mostly used for passing options to the serial port.
The format for this is BPN, where B is speed in bps (so use 9600,
19200, 38400, etc.). The P is parity and is one of three letters: n
for no parity, e for even parity, and o for odd parity. The N is the
number of data bits, and is usually either 7 or 8. The default is
9600n8. Most users will want to use the default, or increase the
speed to 19200 bps.
</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
You should see the Linux kernel start through the decompression process
then you will see no more on-screen information until the kernel has
completed and mgetty starts up a login prompt on the screen. If you are
monitoring the serial port, you'll see the Linux bootup information coming
over the serial port. However, you probably will not see a login prompt
on the serial port (yet). We'll cover that in
<xref linkend="configurationgetty">.
</para>
<para>
Once you are sure this is working, you can now edit LILO to pass this
information to the kernel each time it boots. You can also configure
LILO to send its prompt to the serial port. Fire up your favorite editor
of choice and load up the /etc/lilo.conf file. You will want to add
two lines, one to the general configuration and one to the specific
kernels you want to use.
</para>
<screen>
serial=0,9600n8
append="console=tty0 console=ttyS0,9600n8"
</screen>
<para>
The append statement contains the statement we listed above, and tells
Linux to send its output to the serial port. The serial command goes to
LILO, and tells it to open port 0 (ttyS0, or COM1). The options for
serial are the same as to the console statement.
</para>
<note>
<para>
Make sure the serial port settings for serial and console are the
same. If they are different, you will need to change your serial
port application between LILO and the kernel, which becomes very
inconvenient.
</para>
</note>
<para>
Re-run <filename>/sbin/lilo</filename> and reboot. You should now see
everything except the login prompt on the serial port. Information
should still be going to the monitor, just in case you have problems
with the serial port.
</para>
</section> <!-- configurationkernel -->
<section id="configurationgetty">
<title>Configuring getty for use with serial ports</title>
<para>
Some distributions may ship with mingetty that does not support serial
ports. The first thing you have to do is make sure the version
of getty you are using supports serial ports. Both agetty and mgetty
do this. So run off now using your favorite packaging system to make
sure this is the case. Don't worry, this document will still be here
when you get back.
</para>
<para>
Back so soon? Great! Let's get that serial port configured.
</para>
<para>
You will want to make sure that all your serial port settings are
consistent. No sense in making getty run at 9600bps, while
LILO and the kernel are talking 19200.
</para>
<para>
To get login prompts to appear on the serial port, edit the
<filename>/etc/inittab</filename> file and add a line similar to
the following:
</para>
<screen>
s0:2345:respawn:/sbin/getty ttyS0 DT9600
</screen>
<para>
The format for entries in inittab are covered in most basic Linux and UNIX
books, but to repeat, each field is separated by a colon (:) and
represent:
</para>
<itemizedlist>
<listitem>
<para>
s0 - Arbitrary entry for inittab. As long as this entry doesn't
appear anywhere else in inittab, you're okay. We named
this entry s0 because it's for ttyS0.
</para>
</listitem>
<listitem>
<para>
2345 - run levels where this entry gets called. If we switch to
runlevel 1, this getty process will be shut down.
</para>
</listitem>
<listitem>
<para>
respawn - re-run the program if it dies. We want this to happen
so that a new login prompt will appear when you log out of the
console.
</para>
</listitem>
<listitem>
<para>
/sbin/getty ttyS0 DT9600 - the command to run. In this case, we're
telling getty to connect to /dev/ttyS0 using the settings for DT9600
which exist in <filename>/etc/gettydefs</filename>. This entry
represents a dumb terminal running at 9600bps. There are other
entries that run at different speeds.
</para>
</listitem>
</itemizedlist>
<para>
The entries in <filename>/etc/inittab</filename> will be loaded into
<command>init</command> when root sends a HUP signal.
</para>
<screen>
# kill -HUP 1
</screen>
<note>
<para>
Remember that <command>init</command> always has a PID of 1.
</para>
</note>
<para>
Now that <command>getty</command> is set up, you will be able to go
from powerup to login prompt all over the serial port
</para>
</section> <!-- configurationgetty -->
</section> <!-- configuration -->
<section id="applications">
<title>Serial Port Applications</title>
<para>
This section covers applications and some configuration information
that you can use to look at your serial console, now that
your Linux boxes are talking to the serial port.
</para>
<section id="applicationsminicom">
<title>Minicom</title>
<para>
Minicom is one of the easier serial port applications to use. It is
curses based, so it's a full screen application with a status bar,
menus, and an easy-to-use interface. It is installed on most
distributions, and initially has to be run as the root user. In
some cases, <command>minicom</command> will be installed suid root,
so anyone will be able to access the configurations. Check the
documentation for your particular distribution to see how it's
configured.
</para>
<para>
Security of minicom is set by the
<filename>/etc/minicom.users</filename> file. Usernames can that are
listed along with a configuration can use the listed configurations.
This allows only authorized users to connect to the serial ports.
</para>
<para>
<command>Minicom</command> creates individual configurations to
separate files. Configure the serial port as needed, then save the
configuration. Files are kept in <filename>/etc</filename> with a
prefix of minirc.
</para>
</section> <!-- applicationsminicom -->
</section> <!-- applications -->
<section id="cabling">
<title>Cabling serial ports together</title>
<para>
Since you will be connecting two DTEs together, you will need to
have a null modem run between the two devices. A null modem
crosses transmit and receive, and ties a few status lines together
so the application can open the port. This null modem can be a
dongle that connects to the cable, or can be built into the cable.
A dongle will get expensive if you have a large number of cables, so
it is usually easier to get cables with the null modem
built in.
</para>
<para>
Most PC hardware these days use DB-9 connectors, giving 9 pins for
transmitting data and status, which is fine for us. Pre-built DB-9
cables can be had for a few dollars for a few feet of cable. More
flexible is building a DB-9 to RJ-45 connector and building
the null modem into that. The RJ-45 connector then accepts
regular 10BaseT cables that can be custom-built, or with varying
legths. This gives a lot of flexibiliy in arranging cables, since
each cable can be the correct length to run between machines. Little
extra cable is left lying around.
</para>
<para>
DB-9 to RJ-45 connectors can be purchased unassembled since
there are no real standards for making this conversion.
So long as Tx and Rx cross and CTS RTS cross, you have a null
modem connection. The cabling I have here comes from my own
design, and works just fine. Note that there have to be two different
DB-9 to RJ-45 connectors because of the way pins are switched. I labeled
them as <quote>1</quote> and <quote>2</quote>. They can be placed
on either end of the cable.
</para>
<table id="dbtorj">
<title>DB9 to RJ-25 connector</title>
<tgroup cols="4">
<colspec colname="column1">
<colspec colname="column2">
<colspec colname="column3">
<colspec colname="column4">
<spanspec namest="column1" nameend="column2" spanname="hdr1"
align="center">
<spanspec namest="column3" nameend="column4" spanname="hdr2"
align="center">
<thead>
<row>
<entry spanname="hdr1">Connector 1</entry>
<entry spanname="hdr2">Connector 2</entry>
</row>
<row>
<entry>DB-9</entry>
<entry>RJ-45</entry>
<entry>DB-9</entry>
<entry>RJ-45</entry>
</row>
</thead>
<tbody>
<row>
<entry>1</entry>
<entry>5</entry>
<entry>1</entry>
<entry>5</entry>
</row>
<row>
<entry>2</entry>
<entry>6</entry>
<entry>2</entry>
<entry>4</entry>
</row>
<row>
<entry>3</entry>
<entry>4</entry>
<entry>3</entry>
<entry>6</entry>
</row>
<row>
<entry>4</entry>
<entry>7</entry>
<entry>4</entry>
<entry>7</entry>
</row>
<row>
<entry>5</entry>
<entry>3</entry>
<entry>5</entry>
<entry>3</entry>
</row>
<row>
<entry>6</entry>
<entry>2</entry>
<entry>6</entry>
<entry>2</entry>
</row>
<row>
<entry>7</entry>
<entry>1</entry>
<entry>7</entry>
<entry>8</entry>
</row>
<row>
<entry>8</entry>
<entry>8</entry>
<entry>8</entry>
<entry>1</entry>
</row>
<row>
<entry>9</entry>
<entry>n/c</entry>
<entry>9</entry>
<entry>n/c</entry>
</row>
</tbody>
</tgroup>
</table>
</section> <!-- cabling -->
</article>

398
LDP/howto/docbook/XDMCP-HOWTO.sgml Normal file
View File

@ -0,0 +1,398 @@
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[
]>
<ARTICLE><!-- Header --><ARTHEADER><TITLE>Linux XDMCP HOWTO</TITLE>
<AUTHOR><FIRSTNAME>Thomas</FIRSTNAME>
<SURNAME>Chao</SURNAME>
<AFFILIATION><ADDRESS>
<EMAIL>tomchao@lucent.com</EMAIL>
</ADDRESS></AFFILIATION></AUTHOR>
<REVHISTORY><REVISION><REVNUMBER>v1.1</REVNUMBER>
<DATE>20 March 2001</DATE>
<AUTHORINITIALS>tc</AUTHORINITIALS>
<REVREMARK>
</REVREMARK></REVISION></REVHISTORY>
<ABSTRACT><PARA>
This HOWTO describes how you can use the combination of X Display Manager (xdm, kdm and gdm) and XDMCP (X Display Manager Control Protocol) to provide the mechanism for an X-Terminal and a platform of cheap Remote X Apps solution. This document will be focusing on how to setup connection using XDMCP.
</PARA></ABSTRACT></ARTHEADER><!-- Section1: intro -->
<SECT1 ID="INTRO"><TITLE>Introduction</TITLE>
<PARA>
XDMCP stands for "X Display Manager Control Protocol" and is a network protocol. It provides a mechanism for an X-Terminal. The X-Terminal will only run the X-Server and it will allow applications running on remote machine to be displayed on it.
</PARA>
<PARA>
Some of us running Linux (like me) are looking for the best parts of Linux. Among them is the ability to re-use old systems (like 486 CPUs) as a X-Terminal (with the Win32 apps; like Hummingbird's Exceed or X-Win32) to run Linux from any PC remotely. It is somehow very surprising that there aren't many documents on the internet which guide you step by step on how to set this up. This is how I come up with this document as a way to share my experience with all user. Essentially, by using X and XDMCP, you can create a cheap solution of a X- environment.
</PARA>
<!-- 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: 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>tomchao@lucent.com</EMAIL>.
</PARA></SECT2></SECT1>
<SECT1 ID="PROCEDURE"><TITLE>The Procedure</TITLE>
<PARA>
This section details the procedures for setting up X-Terminal using XDMCP.
</PARA>
<!-- Section2: Backgrounds-->
<SECT2><TITLE>Before you begin, some backgrounds</TITLE>
<PARA>
Before you begin, it is better to have a basic understanding of how this works. (More details are at the <ULINK URL="#REFS">Resources</ULINK> below and <ULINK URL="http://www.linuxdoc.org">LDP HOWTO page</ULINK>)
</PARA>
<PARA>
The X server is usually started from the X Display Manager program (xdm, kdm and gdm. This document will use gdm as an example). It provides a nice and consistent interfaces for general users (X-based login, starting up a window manager, clock, etc.). X Display Manager manages a collection of X displays, which may be on the local host or remote servers. </PARA>
<PARA>When xdm runs, it is usually run as a local copy of X, also xdm can listen for requests from remote hosts over a network. For kdm (which comes with the KDE desktop), it is a replacement of xdm and configures the same way, except its files are in <FILENAME>/etc/X11/kdm</FILENAME>. The gdm ( Gnome Display Manager) is a reimplementation of the xdm program. gdm has similar funtions to xdm and kdm, but was written from scratch and does not contain any original XDM / X Consortium code. </PARA>
<PARA>In the case of xdm, it offers display management in two different ways. It can manage X servers running on the local machine and specified in Xservers, and it can manage remote X servers (typically X terminals) using XDMCP (the XDM Control Protocol) as specified in the Xaccess file. (Courtesy of xdm man page).</PARA>
<PARA>
<ITEMIZEDLIST>
<LISTITEM><PARA>The <ULINK URL="http://ibiblio.org/pub/Linux/docs/HOWTO/mini/other-formats/html_single/XDM-Xterm.html">XDM and Xterminal mini-HOWTO</ULINK></PARA>
</LISTITEM>
<LISTITEM>
<PARA>Linux <ULINK URL="http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-formats/html_single/Remote-X-Apps.html">Remote X Apps mini HOWTO</ULINK> A very good reference for Remote X in both theoretical and practical view. </PARA></LISTITEM>
<LISTITEM>
<PARA>The <ULINK URL="http://www.ibiblio.org/pub/Linux/docs/HOWTO/unmaintained/mini/Xterminal">Xterminal mini-HOWTO</ULINK></PARA></LISTITEM></ITEMIZEDLIST>
</PARA>
</SECT2>
<SECT2 ID="Security"><TITLE>Security Reminder</TITLE>
<PARA>
Using XDMCP is inherently insecure, therefore, most of the distributions shipped as its' XDMCP default turned off. If you must use XDMCP, be sure to use it only on a trusted networks, such as corporate network within a firewall. Unfortunely, XDMCP uses UDP, not TCP, therefore, it is not possible to forward XDMCP over SSH. Some people has success in X11 TCP/IP port Forwarding. Check this <ULINK URL="http://www.law.berkeley.edu/computing/howto/ssh/">UC Berkeley Howto</ULINK> site for more info.
</PARA></SECT2>
<SECT2 ID="SYSTEM"><TITLE>The System I use</TITLE>
<PARA>
I have tested the setup running a GNOME (gdm), as well as KDE (kdm) on Red Hat 6.0, 6.2 and Red Hat 7.0. The other I have tried on are on Caldera eDesktop 2.4, which is similar to RH's setup. I have not had a chance to test it on other Linux flavors (but plan to do so for Debian and Slackware in the future). If you have successfully setup one other than the Red Hat platform, please share it with me. I will add them into this document.
</PARA>
<PARA>My server hardware is an IBM PC clone running an Intel Pentium II 400 MHz with 128 MB memory and 30 MB ATA-66 Hard Drive. (I found out that 486 PC and my other Pentium 100 MHz PC runs this just fine). I use a 3COM 10/100 Fast Ethernet (3C509B) NIC.</PARA>
</SECT2>
<SECT2 ID="remote"><TITLE>Remote piece</TITLE>
<PARA>
I use the Hummingbird Exceed 6.x (with Service Pack) and have tested them on Windows 98 SE, Windows NT 4.0 and Windows 2000 Pro. I found out that another popular choice are X-Win32 and VNC. However, there are many open-source apps as well as commercial one available.
</PARA></SECT2>
<SECT2 ID="PREP"><TITLE>Server Preparation</TITLE>
<PARA>
To prepare your X Server for XDMCP session, you need to make sure the following are properly installed:
<ORDEREDLIST><LISTITEM><PARA>
Install your Linux OS. In my case, I installed
Red Hat 6.2 (Custom Installation). I also tried on RH 7.0.
</PARA></LISTITEM>
<LISTITEM><PARA>
Setup your Networking. To test it out,
<COMMAND>ping</COMMAND> and <COMMAND>telnet</COMMAND>
are good comamnds to use to determine if your network
works.
</PARA></LISTITEM>
<LISTITEM><PARA>
Setup X. Do <EMPHASIS>not</EMPHASIS> setup with a
resolution higher than what the remote users are able to use for
their display. Test the X Server by typing either
<COMMAND>startx</COMMAND> or <COMMAND>telinit 5</COMMAND>.
Make sure X is running properly.
</PARA></LISTITEM>
<LISTITEM><PARA>
Creates the necessary user accounts (and associated groups) for user who will access via the X-Terminal.
</PARA></LISTITEM></ORDEREDLIST>
</PARA></SECT2>
<SECT2 ID="STEPS"><TITLE>Steps to Complete the Procedures</TITLE>
<PARA>
These are steps I used to setup the Xserver for accepting XDMCP requests:
<ORDEREDLIST><LISTITEM><PARA>
Modify <FILENAME>/etc/rc.d/init.d/xfs</FILENAME> and make the
following changes. Change all (this is where the Font Server port):
</PARA>
<SCREEN>daemon xfs -droppriv -daemon -port -1</SCREEN>
<PARA>
to:
</PARA>
<SCREEN>daemon xfs -droppriv -daemon -port 7100</SCREEN>
<PARA>In RH 7.0, you do not need to do this, since by default, it is, for security enhancement, not listening to TCP port any longer! If you need to setup default font server to use, do it in /etc/X11/fs/config and add the setting there.</PARA></LISTITEM>
<LISTITEM><PARA>
In <FILENAME>/etc/X11/xdm/Xaccess</FILENAME>, change
(this allow all hosts to connect):
</PARA>
<SCREEN>#* # any host can get a login window</SCREEN>
<PARA>
to:
</PARA>
<SCREEN>* # any host can get a login window</SCREEN>
<PARA>xdm usually run as a local copy of X and can listen for requests from remote hosts over a network. xdm reads its configuration files <FILENAME>/etc/X11/xdm/xdm-config</FILENAME> for all configuration and log files that xdm uses. For kdm, it is a replacement of xdm and configures the same way, except its files are in <FILENAME>/etc/X11/kdm</FILENAME>. It is worth noting that the <COMMAND>Xsession</COMMAND> file is what runs your environment.</PARA>
<PARA>The gdm (Gnome Display Manager) is a reimplementation of the well known xdm. gdm has similar funtions to xdm and kdm, gdm is the Gnome Display Manager, and its configuration files are found in <FILENAME>/etc/X11/gdm/gdm.conf</FILENAME>. The <FILENAME>gdm.conf</FILENAME> file contains sets of variables and many options for gdm, and the Sessions directory contains a script for each session option; each script calls <FILENAME>/etc/X11/xdm/Xsession</FILENAME> with the appropriate option.</PARA>
</LISTITEM>
<LISTITEM><PARA>
I use the gdm as default and use gdm login window to switch between KDE and GNOME. Edit <FILENAME>/etc/X11/gdm/gdm.conf</FILENAME>.
This activates XDMCP, causing it to listen to the request. Change this:
</PARA>
<SCREEN>
[xdmcp]
Enable=0</SCREEN>
<PARA>
to:
</PARA>
<SCREEN>Enable=1</SCREEN>
<PARA>
Make sure &quot;<COMMAND>Port=177</COMMAND>&quot; is at the end of this block.
</PARA></LISTITEM>
<LISTITEM><PARA>
Now edit <FILENAME>/etc/inittab</FILENAME> and change
the following line:
</PARA>
<SCREEN>id:3:initdefault:</SCREEN>
<PARA>
to:
</PARA>
<SCREEN>id:5:initdefault:</SCREEN>
<PARA>
Before changing this line, you can use the
<COMMAND>telinit</COMMAND> command to test prior to
modifying the line. Use either <COMMAND>telinit 3</COMMAND>
to set to level 3, or <COMMAND>telinit 5</COMMAND> to set to
level 5, graphics mode (you can issue this command on the
second machine that telnets into this server).
</PARA></LISTITEM>
<LISTITEM><PARA>
Make sure the proper security of the file <FILENAME>/etc/X11/xdm/XServers</FILENAME> set to 444 (chmod 444).</PARA>
</LISTITEM>
<LISTITEM><PARA>
Locate <FILENAME>/etc/X11/xdm/Xsetup_0</FILENAME> and <COMMAND>chmod 755</COMMAND>
this file.
</PARA></LISTITEM>
<LISTITEM><PARA>
Edit the <FILENAME>XF86Config</FILENAME> file in <FILENAME>/etc/X11</FILENAME>
and change the line, if you are using RH 6.2:
</PARA>
<SCREEN>FontPath "unix:-1"</SCREEN>
<PARA>
to:
</PARA>
<SCREEN>FontPath "unix:7100"</SCREEN></LISTITEM>
<LISTITEM><PARA>
(You do not have to make this change. You can keep the default setting, but this is what I use. If you are not sure, leave this alone.) Add this line to the end of <FILENAME>/etc/inittab</FILENAME>:
</PARA>
<SCREEN>x:5:respawn:/usr/bin/gdm</SCREEN></LISTITEM></ORDEREDLIST>
</PARA>
<PARA>You are now ready to run a test.</PARA></SECT2>
<SECT2 ID="TESTING"><TITLE>Testing</TITLE>
<PARA>
To test if your XDMCP with X Server is ready to accept
connections, do these steps. I find it easier using the X
Server and another machine to test:
<ORDEREDLIST><LISTITEM><PARA>
(Though you don't need to; it doesn't hurt...) Reboot the machine (I am
assuming you are running level 5).
</PARA></LISTITEM>
<LISTITEM><PARA>
Make sure the Graphical login page comes up. Make sure the
display resolution and mouse work. Log in from the console to
see if the local access is OK. If OK, do not log off.
</PARA></LISTITEM>
<LISTITEM><PARA>
Setup Hummingbird Exceed to either query this machine (using
the IP address or fully qualified DNS name) or set to use XDMCP-Broadcast and try to
connect to the X server. You should see the X Session come
up and the login screen appear.
</PARA></LISTITEM>
</ORDEREDLIST>
</PARA></SECT2></SECT1>
<SECT1 ID="TS"><TITLE>Troubleshooting</TITLE>
<PARA>
<ITEMIZEDLIST><LISTITEM><PARA>
If X cannot come up and is broken:
</PARA>
<PARA>
If X is broken and the connection fails,
most of the time it has this error messages:
</PARA>
<SCREEN>
_ FontTransSocketUNIXConnect: Can't connect: errno = 111
failed to set dafault font path 'unix:-1'
Fatal server error:
could not open default font 'fixed'</SCREEN>
<PARA>
This is likely due to xfs not finding the correct port for
the Font Server (again, if you are running RH 6.2). To resolve this, check steps 1 and
7 above. Make sure the configuration are pointing to (port)
7100 and make sure you have the following fonts installed (if
not re-install the XFree86 font packages):
</PARA>
<SCREEN>
FontPath "/usr/lib/X11/fonts/75dpi/"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/CID"
FontPath "/usr/lib/X11/fonts/Speedo"
FontPath "/usr/lib/X11/fonts/100dpi"</SCREEN>
<PARA>
Use the command <COMMAND>startx</COMMAND> (on local) to restart
the X server (or use <COMMAND>telinit 5</COMMAND> to switch the run-level).
</PARA></LISTITEM>
<LISTITEM><PARA>
If Exceed has no respond:
</PARA>
<PARA>
In this case, most likely your xdm (or gdm, depending upon which
is used in <FILENAME>/etc/inittab</FILENAME>) is not starting
correctly. Issue the command:
<COMMAND>ps -ef | grep gdm</COMMAND> (or
<COMMAND>ps -ef | grep xdm</COMMAND> if xdm is used).
</PARA>
<PARA>
If the process is not running, check the steps on the setup above (make sure
there are no typo's and that the correct path is given). Restart
X using the command <COMMAND>telinit 5</COMMAND>.
</PARA></LISTITEM></ITEMIZEDLIST>
</PARA></SECT1>
<SECT1 ID="GDM"><TITLE>XDMCP and GDM (Gnome Display Manager)</TITLE>
<PARA>
The following is taken from the
<ULINK URL="http://www.oswg.org/oswg-nightly/oswg/en_US.ISO_8859-1/articles/gdm-reference/gdm-reference/index.html">
Gnome Display Manager Reference Manual</ULINK>:
</PARA>
<PARA>
GDM also supports the X Display Manager Protocol (XDMCP) for managing remote displays. GDM listens to UDP port 177 and will repond to QUERY and
BROADCAST_QUERY requests by sending a WILLING packet to the originator. GDM can also be configured to honor INDIRECT queries and present a host chooser to the remote display. GDM will remember the user's choice and forward subsequent requests to the chosen manager. GDM only supports the MIT-MAGIC-COOKIE-1 authentication system. Little is gained from the other schemes, and no effort has been made to implement them so far. Since it is fairly easy to do denial of service attacks on the XDMCP service, GDM incorporates a few features to guard against attacks. Please read the XDMCP reference section below for more information.
</PARA>
<PARA>
Even though GDM tries to outsmart potential attackers, it is still adviced that you block UDP port 177 on your firewall unless you really need it. GDM guards against DoS attacks, but the X protocol is still inherently insecure and should only be used in controlled environments. Even though your display is protected by cookies the XEvents and thus the keystrokes typed when entering passwords will still go over the wire in clear text. It is trivial to capture these. You should also be aware that cookies, if placed on an NFS mounted directory, are prone to eavesdropping too.
</PARA>
</SECT1>
<SECT1 ID="REFS"><TITLE>Additional References</TITLE>
<PARA>Some additional references on this subject include:
<ITEMIZEDLIST>
<LISTITEM><PARA>Your local xdm man page.</PARA></LISTITEM>
<LISTITEM><PARA>Your local gdm man page.</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.linuxgazette.com/issue43/nielsen.xdm.html">
Configuring XDM</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.con.wesleyan.edu/~triemer/network/xdmcp/xdmcp_udp.html">
xdmcp/udp</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/XDMCP/xdmcp.PS.gz">
XDMCP Documentation</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www-uxsup.csx.cam.ac.uk/security/probing/about/xdmcp.html">
Should you be running XDMCP?</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.linuxgazette.com/issue27/kaszeta.html">
X Window System Terminals</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.tcu-inc.com/mark/projects/xdm/index2.html">
A second way of using XDM</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.linuxworld.com/linuxworld/lw-2000-09/lw-09-legacy_1.html">
Accessing Xterms from Windows</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://ec.eng.usf.edu/SWFTP/xwin/">
How to download and install X-Win32</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.umanitoba.ca/campus/acn/support/xwin/xwininst.html">
How to install X-Win32 (another ref.)</ULINK>
</PARA></LISTITEM>
<LISTITEM><PARA><ULINK URL="http://www.rru.com/~meo/pubsntalks/xrj/xdm.html">Taming the X Display Manager</ULINK>
</PARA>
</LISTITEM>
<LISTITEM><PARA>
<ULINK URL="http://www.socsci.auc.dk/~mkp/gdm/">GNOME Display Manager</ULINK>
</PARA></LISTITEM>
</ITEMIZEDLIST>
</PARA></SECT1>
<SECT1 ID="AU"><TITLE>Authors</TITLE>
<PARA>
Current: Thomas Chao, Lucent Technologies
</PARA></SECT1>
<!-- Section1: copyright -->
<SECT1 ID="COPYRIGHT"><TITLE>Copyright Information</TITLE>
<PARA>
This document is copyrighted (c) 2000, 2001 Thomas Chao 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></SECT1></ARTICLE>