LDP/LDP/howto/docbook/Remote-Serial-Console-HOWTO...

7760 lines
313 KiB
Plaintext

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
<book id="Remote-Serial-Console-HOWTO" lang="en">
<bookinfo>
<title>Remote Serial Console HOWTO</title>
<pubdate>v2.6 2003-03-31</pubdate>
<authorgroup>
<author>
<firstname>Glen</firstname>
<surname>Turner</surname>
<affiliation>
<orgname>Australian Academic and Research Network</orgname>
<address><email>glen.turner+howto@aarnet.edu.au</email></address>
</affiliation>
</author>
<author>
<firstname>Mark</firstname>
<othername>F.</othername>
<surname>Komarinski</surname>
<affiliation>
<address><email>mkomarinskiATwayga.org</email></address>
</affiliation>
</author>
</authorgroup>
<revhistory>
<revision>
<revnumber>2.6</revnumber>
<date>2003-03-31</date>
<authorinitials>gdt</authorinitials>
<revremark>Correct opposing CTS/RTS explanations. Use
&lt;quote&gt; in markup. TLDP PDF is now good, so remove
instructions for rendering PostScript to PDF. Typo in GRUB
configuration.</revremark>
</revision>
<revision>
<revnumber>2.5</revnumber>
<date>2003-01-20</date>
<authorinitials>gdt</authorinitials>
<revremark>Only one console per technology type. Setting
timezone. Use off parameter rather than comments in inittab. Cable
lengths.</revremark>
</revision>
<revision>
<revnumber>2.4</revnumber>
<date>2002-10-03</date>
<authorinitials>gdt</authorinitials>
<revremark>Kernel flow control bug, more cabling, Debian,
Livingston Portmaster, typos (especially those found during
translation to Japanese).</revremark>
</revision>
<revision>
<revnumber>2.3</revnumber>
<date>2002-07-11</date>
<authorinitials>gdt</authorinitials>
<revremark>Updates for Red Hat Linux 7.3, corrections to serial
port speeds and UARTs, ioctlsave.</revremark>
</revision>
<revision>
<revnumber>2.2</revnumber>
<date>2002-05-22</date>
<authorinitials>gdt</authorinitials>
<revremark>Minor changes</revremark>
</revision>
<revision>
<revnumber>2.1</revnumber>
<date>2002-05-16</date>
<authorinitials>gdt</authorinitials>
<revremark>Corrections to kernel console syntax. Addition of USB
and devfs.</revremark>
</revision>
<revision>
<revnumber>2.0</revnumber>
<date>2002-02-02</date>
<authorinitials>gdt</authorinitials>
<revremark>Second edition.</revremark>
</revision>
<revision>
<revnumber>&le;1.0</revnumber>
<date>2001-03-20</date>
<authorinitials>mfk</authorinitials>
<revremark>First edition.</revremark>
</revision>
</revhistory>
<abstract>
<para>An <acronym>RS-232</acronym> serial console allows
<systemitem class="osname">Linux</systemitem> to be controlled from
a terminal or modem attached to an asynchronous serial port. The
monitor, mouse and keyboard are no longer required for system
administration. Serial consoles are useful where <systemitem
class="osname">Linux</systemitem> systems are deployed at remote
sites or are deployed in high-density racks.</para>
<para>This <citetitle>HOWTO</citetitle> describes how to configure
<systemitem class="osname">Linux</systemitem> to attach a serial
console.</para>
</abstract>
<keywordset>
<keyword>serial console</keyword>
<keyword>console</keyword>
<keyword>serial</keyword>
<keyword>modem</keyword>
<keyword>RS-232</keyword>
</keywordset>
</bookinfo>
<dedication id="dedication">
<title>Dedication</title>
<para>Glen Turner would like to thank his family for allowing him to
work on this project for the surprisingly large number of evenings
which it took to write this <citetitle>HOWTO</citetitle>. Thank you
Karen, Kayla and Ella.</para>
</dedication> <!-- dedication -->
<chapter id="intro">
<title>Introduction</title>
<epigraph id="intro-skb">
<para><wordasword>console</wordasword> <abbrev>n.</abbrev> [From
latin <foreignphrase>consolatio(n)</foreignphrase> <quote>comfort,
spiritual solace.</quote>] A device for displaying or printing
condolances or obituaries for the operator.</para>
<para>Stan Kelly-Bootle, <citetitle>The Computer
Contradictionary</citetitle>.</para>
</epigraph> <!-- intro-skb -->
<section id="intro-what">
<title>What is a console?</title>
<para>The console is the text output device for system
administration messages. These messages come from the kernel, from
the <application>init</application> system and from the system
logger.</para>
<para>On modern small computers the console is usually the
computer's attached monitor and keyboard.</para>
<para>On many older computers the console is an
<acronym>RS-232</acronym> link to a terminal such as a
<acronym>DEC</acronym>
<productname><acronym>VT100</acronym></productname>. This terminal
is in a locked room and is continually observed by the
minicomputer's operators. Large systems from Sun, Hewlett-Packard
and <acronym>IBM</acronym> still use serial consoles.</para>
<para>It is usually possible to login from the console. A login
session from the console is treated by many parts of the operating
system as being more trustworthy than a login session from other
sources. Logging in as the <systemitem
class="username">root</systemitem> super-user from the console is
the Command Line of Last Resort when faced with a misbehaving
system.</para>
</section> <!-- intro-what -->
<section id="intro-why">
<title>Why use a serial console?</title>
<para>For the average user a serial console has no advantage over a
console offered by a directly attached keyboard and screen. Serial
consoles are much slower, taking up to a second to fill a 80 column
by 24 line screen. Serial consoles generally only support
non-proportional <acronym>ASCII</acronym> text, with limited
support for languages other than English. A new terminal can be
more expensive than an old <acronym>PC</acronym>.</para>
<para>There are some scenarios where serial consoles are
useful. These are:</para>
<variablelist>
<varlistentry>
<term>Systems administration of remote computers</term>
<listitem>
<para><systemitem class="osname">Linux</systemitem> is a good
operating system for deployment at unstaffed sites. <systemitem
class="osname">Linux</systemitem> is also good for hosting
critical network infrastructure such as <acronym>DNS</acronym>
and <acronym>DHCP</acronym> services. These services are
generally installed at every site of an organisation including
sites which may be too small or too remote to have information
technology staff.</para>
<para>System administration of these remote computers is usually
done using <application><acronym>SSH</acronym></application>, but
there are times when access to the console is the only way to
diagnose and correct software failures. Major upgrades to the
installed distribution may also require console access.</para>
<para>In these cases the serial console is attached to a modem.
Access to the console is gained from a remote computer by
dialing into the modem. This allows the console to be reached
from any telephone socket.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>High density racks of computers</term>
<listitem>
<para>Clusters of personal computers can outperform mainframe
computers and form competitive supercomputers for some
applications. See the <ulink
url="http://www.tldp.org/HOWTO/Cluster-HOWTO.html"><citetitle>Cluster-HOWTO</citetitle></ulink>
for more information on clustering.</para>
<para>These clusters are typically assembled into 19 inch
telecommunications equipment racks and the system unit of each
computer is typically one rack unit (or 1.75 inches) tall. It
is not desirable to put a keyboard and monitor on each computer,
as a small cathode ray tube monitor would consume the space used
by sixteen rack units.</para>
<para>A first glance it seems that a monitor and keyboard switch
is the best solution. However the <acronym>VGA</acronym> signal
to the monitor is small, so even with the switch the monitor
cannot be placed very far away from the rack of
computers.</para>
<para>It is desirable to allow the consoles to be monitored in
the operators' room of the computer center, rather than in the
very expensive space of the machine room. Although monitor
switches with remote control and fiber optical extensions are
available, this solution can be expensive.</para>
<para>A standard <acronym>RS-232</acronym> cable can be 15
meters in length. Longer distances are easily possible. The
cabling is cheap. Terminal servers can be used to allow one
terminal to access up to 90 serial consoles.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Recording console messages</term>
<listitem>
<para>This is useful in two very different cases.</para>
<para>Kernel programmers are often faced with a kernel error
message that is displayed a split second before the computer
reboots. A serial console can be used to record that
message. Another <systemitem class="osname">Linux</systemitem>
machine can be used as the serial terminal.</para>
<para>Some secure installations require all security events to
be unalterably logged. One way to meet this requirement is to
print all console messages. Connecting the serial console to a
serial printer can achieve this.<footnote>
<para>The <systemitem class="osname">Linux</systemitem>
<productnumber>2.4</productnumber> kernel also supports the
output of console messages to
<productname>Centronics</productname> or
<citetitle><acronym>IEEE</acronym> 1284-2000</citetitle>
parallel printer interfaces.</para></footnote></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Embedded software development</term>
<listitem>
<para><systemitem class="osname">Linux</systemitem> is
increasingly being used as an operating system for embedded
applications. These computers do not have keyboards or
screens.</para>
<para>A serial port is a cheap way to allow software developers
to directly access the embedded computer. This is invaluable
for debugging. Most chip sets designed for embedded computers
have a serial port precisely for this purpose.</para>
<para>The shipping product need not present the
<acronym>RS-232</acronym> port on an external connector.
Alternatively the <acronym>RS-232</acronym> port is often used for
downloading software updates.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Craft terminal for telecommunications equipment</term>
<listitem>
<para><systemitem class="osname">Linux</systemitem> is
increasingly being used as the operating system inside
telecommunications equipment. The <ulink
url="http://www.osdlab.org/projects/cgl/">Carrier Grade
Linux</ulink> consortia hopes to accelerate and coordinate this
trend.</para>
<para>Most telecommunications equipment is remotely managed from
a distant computer. However, site technicans (called
<wordasword>craft personnel</wordasword> in telco-speak) need to
access the equipment to test installation changes, check the
status of reported faults, and so on. The terminal used by the
craft personnel is called the <wordasword>craft
terminal</wordasword>. The craft terminal plugs into the
<wordasword>craft interface</wordasword> on the equipment. The
serial console makes an ideal craft interface.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Unlike minicomputer systems, the
<productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname> was not designed to use a
serial console. This has two consequences.</para>
<para>Firstly, Power On Self-Test messages and Basic Input/Output
System (<acronym>BIOS</acronym>) messages are sent to the screen
and received from the keyboard. This makes it difficult to use the
serial port to reconfigure the <acronym>BIOS</acronym> and
impossible to see Power On Self-Test errors.</para>
<para>An increasing number of manufacturers of rackable
<emphasis>server</emphasis> equipment are altering their
<acronym>BIOS</acronym>s to optionally use the
<acronym>RS-232</acronym> port for BIOS configuration and test
messages. If you are buying a machine specifically for use with
serial console you should seek this feature. If you have an
existing machine that definitely requires access to the
<acronym>BIOS</acronym> from the serial port then there are
hardware solutions such as <ulink
url="http://www.realweasel.com/"><productname>PC Weasel
2000</productname></ulink>.</para>
<para>Secondly, the <acronym>RS-232</acronym> port on the
<productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname> is designed for connecting to a
modem. Thus a null modem cable is needed when connecting the PC's
serial port to a terminal.</para>
</section> <!-- into-why -->
<section id="intro-word">
<title>Alternative meanings of <quote>console</quote></title>
<para>Some authors use the word <quote>console</quote> to refer to
the keyboard and monitor that are attached to the system unit.
This is described as a <quote>physical console</quote> by some
<systemitem class="osname">Linux</systemitem> documentation. The
console where system messages appear is described as the
<quote>logical console</quote> by that documentation.</para>
<para>As an illustration of the difference, <productname>X
Windows</productname> should start on the physical console but
system messages issued by failures when starting <productname>X
Windows</productname> should be written to the logical
console.</para>
<para>To avoid confusion this <citetitle>HOWTO</citetitle> uses the
word <quote>console</quote> to describe the place where system
messages are printed. This <citetitle>HOWTO</citetitle> uses the
phrase <quote>attached monitor and keyboard</quote> rather than the
confusing words <quote>physical console</quote>.</para>
<para>These distinctions are also made in the naming of devices.
The device <filename class="devicefile">/dev/console</filename> is
used to send messages to the console. The symbolic link <filename
class="symlink">/dev/systty</filename> points to the device which
is used by the attached monitor and keyboard, often <filename
class="devicefile">/dev/tty0</filename>.</para>
<table frame="topbot" colsep="0" rowsep="0" id="intro-word-console">
<title>Different ways of referring to the <quote>console</quote></title>
<tgroup cols="3">
<thead>
<row>
<entry>Document</entry>
</row>
</thead>
<tbody>
<row>
<entry><para>This <citetitle>HOWTO</citetitle></para></entry>
<entry><para><quote>Console</quote></para></entry>
<entry><para><quote>Attached monitor and keyboard</quote></para></entry>
</row>
<row>
<entry><para>Some Linux documentation</para></entry>
<entry><para><quote>Logical console</quote></para></entry>
<entry><para><quote>Physical console</quote></para></entry>
</row>
<row>
<entry><para>Device names</para></entry>
<entry><para><filename class="devicefile">/dev/console</filename></para></entry>
<entry><para><filename class="devicefile">/dev/systty</filename></para></entry>
</row>
</tbody>
</tgroup>
</table> <!-- intor-word-console -->
</section> <!-- intro-word -->
<section id="intro-config">
<title>Configuration overview</title>
<para>There are five major steps to configuring a serial
console.</para>
<procedure>
<step>
<para>Optionally, the <acronym>BIOS</acronym> may be configured
to use the serial port.</para>
</step>
<step>
<para>If needed, the boot loader may be configured to use the
serial port.</para>
</step>
<step>
<para>The Linux kernel must be configured to use the serial port
as its console. This is done by passing the kernel the
<literal>console</literal> parameter when the kernel is started
by the boot loader.</para>
</step>
<step>
<para>The <application>init</application> system should keep a
process running to monitor the serial console for logins. The
monitoring process is traditionally called
<application>getty</application>.</para>
</step>
<step>
<para>A number of system utilities need to be configured to make
them aware of the console, or configured to prevent them from
disrupting the console.</para>
</step>
</procedure>
<para>Examples in this <citetitle>HOWTO</citetitle> are from
<productname>Red Hat Linux</productname> versions
<productnumber>7.1</productnumber> through to
<productnumber>7.3</productnumber> (released 2001 through to 2002).
The maintainer would appreciate updates when new versions of
<productname>Red Hat Linux</productname> appear. The maintainer
would very much appreciate examples for <systemitem
class="osname">Linux</systemitem> distributions that are dissimilar
to <productname>Red Hat Linux</productname>; particularly
<productname>Debian GNU/Linux</productname> and
<productname>Slackware Linux</productname>. All contributors are
acknowledged in <xref linkend="about-credits">.</para>
</section> <!-- intro-config -->
</chapter> <!-- intro -->
<chapter id="preparation">
<title>Preparation</title>
<para>This chapter ensures that access the existing console can be
restored should the serial console fail to start.</para>
<para>This chapter then discusses the selection of the
<acronym>RS-232</acronym> port and its parameters.</para>
<section id="preparation-fallback">
<title>Create fallback position</title>
<para>Good system administrators always have a viable fallback
plan to cope with failures. A mistake configuring the serial
console can make both the serial console and the attached monitor
and keyboard unusable. A fallback plan is needed to retrieve
console access.</para>
<para>Many <systemitem class="osname">Linux</systemitem>
distributions allow boot diskettes to be created. Writing a boot
diskette before altering the console configuration results in a
boot diskette that passes good parameters to the kernel rather than
parameters that may contain an error.</para>
<para>Under <productname>Red Hat Linux</productname> a boot
diskette is created by determining the running kernel
version</para>
<informalfigure id="preparation-fallback-kernelversion">
<screen format="linespecific">
<prompt>bash$</prompt> <command>uname -r</command>
<computeroutput>2.4.2-2</computeroutput></screen>
</informalfigure>
<para>and then using that version to create the boot
diskette</para>
<informalfigure id="preparation-fallback-rhldisk">
<screen format="linespecific">
<prompt>bash#</prompt> <command>mkbootdisk &hyphen;&hyphen;device /dev/fd0 2.4.2-2</command></screen>
</informalfigure>
<para>Under <productname>Debian
<acronym>GNU</acronym>/Linux</productname> the boot diskette is
created by determining the version of the running kernel and then
using that version to write the boot diskette</para>
<informalfigure id="preparation-fallback-debiandisk">
<screen format="linespecific">
<prompt>bash#</prompt> <command>mkboot /boot/vmlinuz-2.4.2-2</command></screen>
</informalfigure>
<para>An alternative fallback position is have a rescue diskette
with the machine. A common choice is <ulink
url="http://www.toms.net/rb/">Tom's root boot</ulink>.</para>
</section> <!-- preparation-fallback -->
<section id="preparation-setport">
<title>Select a serial port </title>
<section id="preparation-setport-name">
<title>Serial port names</title>
<para>Linux names its serial ports in the
<productname>UNIX</productname> tradition. The first serial port
has the file name <filename
class="devicefile">/dev/ttyS0</filename>, the second serial port
has the file name <filename
class="devicefile">/dev/ttyS1</filename>, and so on.</para>
<para>This differs from the <productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname> tradition. The first serial
port is named <filename class="devicefile">COM1:</filename>, the
second serial port is named <filename
class="devicefile">COM2:</filename>, and so on. Up to four serial
ports can be present on a <productname><acronym>IBM</acronym>
<acronym>PC/AT</acronym></productname> computer and its
successors.</para>
<para>Most boot loaders have yet another naming scheme. The first
serial port is numbered <literal>0</literal>, the second serial
port is numbered <literal>1</literal>, and so on.</para>
<para>If your distribution of <systemitem
class="osname">Linux</systemitem> uses the
<application>devfs</application> device manager then the serial
ports have yet another name. The first serial port is <filename
class="devicefile">/dev/tts/0</filename>, the second serial port
is <filename class="devicefile">/dev/tts/1</filename>, and so
on.</para>
<para>The result is that the first serial port is labeled
<filename class="devicefile">COM1:</filename> on the chassis of
the <productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname>; is known as <filename
class="devicefile">/dev/ttyS0</filename> to <systemitem
class="osname">Linux</systemitem>; is known as <filename
class="devicefile">/dev/tts/0</filename> to <systemitem
class="osname">Linux</systemitem> when configured with
<application>devfs</application>; and is known as port
<literal>0</literal> to many boot loaders.</para>
<para>The examples in this <citetitle>HOWTO</citetitle> use this
first serial port, as that is the serial port which most readers
will wish to use.</para>
<table frame="topbot" colsep="0" rowsep="0" id="preparation-setport-names-many">
<title>Many names for the same serial port</title>
<tgroup cols="4" align="center">
<thead valign="bottom">
<row rowsep="1">
<entry align="center" valign="bottom"><productname>IBM PC</productname></entry>
<entry align="center" valign="bottom"><systemitem
class="osname">Linux</systemitem> kernel</entry>
<entry align="center" valign="bottom"><systemitem
class="osname">Linux</systemitem> kernel with
<application>devfs</application></entry>
<entry align="center" valign="bottom">Most boot loaders</entry>
</row>
</thead>
<tbody>
<row>
<entry><filename class="devicefile">COM1:</filename></entry>
<entry><filename class="devicefile">/dev/ttyS0</filename></entry>
<entry><filename class="devicefile">/dev/tts/0</filename></entry>
<entry><literal>0</literal></entry>
</row>
<row>
<entry><filename class="devicefile">COM2:</filename></entry>
<entry><filename class="devicefile">/dev/ttyS1</filename></entry>
<entry><filename class="devicefile">/dev/tts/1</filename></entry>
<entry><literal>1</literal></entry>
</row>
<row>
<entry><filename class="devicefile">COM3:</filename></entry>
<entry><filename class="devicefile">/dev/ttyS2</filename></entry>
<entry><filename class="devicefile">/dev/tts/2</filename></entry>
<entry><literal>2</literal></entry>
</row>
<row>
<entry><filename class="devicefile">COM4:</filename></entry>
<entry><filename class="devicefile">/dev/ttyS3</filename></entry>
<entry><filename class="devicefile">/dev/tts/3</filename></entry>
<entry><literal>3</literal></entry>
</row>
</tbody>
</tgroup>
</table>
</section> <!-- preparation-setport-name -->
<section id="preparation-setport-interrupt">
<title>Cannot share interrupt used for console's serial
port</title>
<para>When used for a console the serial port cannot share an
interrupt with another device. The
<productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname> devices are usually installed
as shown in <xref linkend="preparation-setport-ibmpc">. If you
use the serial port <filename
class="devicefile">/dev/ttyS0</filename> for the console then you
should avoid sharing interrupt 4 by not installing a serial port
<filename class="devicefile">/dev/ttyS2</filename> in your
<acronym>PC</acronym>. If <filename
class="devicefile">/dev/ttyS2</filename> cannot be physically
removed then disable it using the <command>setserial</command>
command, as shown in <xref
linkend="preparation-setport-setserial">.</para>
<table frame="topbot" colsep="0" rowsep="0" id="preparation-setport-ibmpc">
<title>Interrupts used for <productname><acronym>IBM</acronym>
<acronym>PC/AT</acronym></productname> <acronym>RS-232</acronym>
ports</title>
<tgroup cols="3" align="center">
<thead valign="bottom">
<row rowsep="1">
<entry align="center">Device</entry>
<entry align="center">Interrupt</entry>
<entry align="center">Port</entry>
</row>
</thead>
<tbody>
<row>
<entry><filename class="devicefile">/dev/ttyS0</filename></entry>
<entry>4</entry>
<entry>0x3f8</entry>
</row>
<row>
<entry><filename class="devicefile">/dev/ttyS1</filename></entry>
<entry>3</entry>
<entry>0x2f8</entry>
</row>
<row>
<entry><filename class="devicefile">/dev/ttyS2</filename></entry>
<entry>4</entry>
<entry>0x3e8</entry>
</row>
<row>
<entry><filename class="devicefile">/dev/ttyS3</filename></entry>
<entry>3</entry>
<entry>0x2e8</entry>
</row>
</tbody>
</tgroup>
</table>
<figure id="preparation-setport-setserial">
<title>Using the <command>setserial</command> command in
<filename>/etc/rc.serial</filename> to disable the serial port
<filename class="devicefile">/dev/ttyS2</filename></title>
<programlisting>
# Disable /dev/ttyS2 so interrupt 4 is not shared,
# then /dev/ttyS0 can be used as a serial console.
setserial /dev/ttyS2 uart none port 0x0 irq 0
</programlisting>
</figure>
<para>Reading the source code suggests that the interrupt-sharing
constraint applies to all computer architectures, not just Intel
Architecture-32.</para>
</section> <!-- preparation-setport-interrupt -->
</section> <!-- preparation-setport -->
<section id="preparation-setspeed">
<title>Select a serial speed and parameters</title>
<para>This <citetitle>HOWTO</citetitle> does not discuss the
<acronym>RS-232</acronym> standard, which is formally known as
<citetitle><acronym>ANSI/TIA/EIA-232-F-1997</acronym> Interface
Between Data Terminal Equipment and Data Circuit-Terminating
Equipment Employing Serial Data Interchange</citetitle>. For an
explanation of <quote>bits per second</quote>, <quote>start
bits</quote>, <quote>data bits</quote>, <quote>parity</quote>,
<quote>stop bits</quote> and <quote>flow control</quote> refer to the
<ulink
url="http://www.tldp.org/HOWTO/Serial-HOWTO.html"><citetitle>Serial-HOWTO</citetitle></ulink>
and the <ulink
url="http://www.tldp.org/HOWTO/Modem-HOWTO.html"><citetitle>Modem-HOWTO</citetitle></ulink>.</para>
<para>The description of the command syntax for setting the serial
parameters in the kernel, boot loaders and login applications uses
the following variables which describe <acronym>RS-232</acronym>
parameters.</para>
<variablelist>
<varlistentry>
<term><replaceable>&lt;speed&gt;</replaceable></term>
<listitem>
<para>The speed of the serial link in bits per second.</para>
<para>The <systemitem class="osname">Linux</systemitem> kernel
on a modern <acronym>PC</acronym> supports a serial console
speeds of 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200
bits per second.</para>
<para>The kernel supports a much wider range of serial bit rates
when the serial interface is not being used as a serial
console.<footnote><para>There is no good reason for this
difference. Feel free to submit a patch to the linux-kernel
mailing list to correct this oddity.</para></footnote></para>
<para>Very recent <systemitem class="osname">Linux</systemitem>
kernels can also offer a serial console using a
<acronym>USB</acronym> serial dongle at speeds of 1200, 2400,
4800, 9600, 19200, 38400, 57600 and 115200 bits per
second.</para>
<para>Most boot loaders only support a different range of speeds
than are supported by the kernel.
<productname>LILO</productname>
<productnumber>21.7.5</productnumber> supports 110, 150, 300,
600, 1200, 2400, 4800, 9600, 19200, 38400, 56000, 57600 and
115200 bits per second. <productname>SYSLINUX</productname>
<productnumber>1.67</productnumber> supports 75 to 56000 bits
per second. <productname>GRUB</productname>
<productnumber>0.90</productnumber> supports 2400, 4800, 9600,
19200, 38400, 57600 and 115200 bits per second.</para>
<para>You must chose the same speed for both the boot loader and
for the <systemitem class="osname">Linux</systemitem> kernel.
An operating system may use more than one boot loader. For
example, <productname>Red Hat Linux</productname> uses
<productname>SYSLINUX</productname> to install or upgrade the
operating system; <productname>LILO</productname> as the boot
loader for <productname>Red Hat Linux</productname>
<productnumber>7.1</productnumber> and earlier; and
<productname>GRUB</productname> as the boot loader for
<productname>Red Hat Linux</productname>
<productnumber>7.2</productnumber> and later.</para>
<para>If you are using a serial terminal or if you are using a
dumb modem then the bit rate of the terminal or dumb modem must
also match the bit rate selected in the boot loader and
kernel.</para>
<para>If the serial console is connected to a Hayes-style modem
slower than 9600<abbrev>bps</abbrev> then configure the serial
console with the same speed as the modem. Modems faster than
9600<abbrev>bps</abbrev> will generally automatically
synchronize to the speed of the serial port.</para>
<para>The selected bit rate must also be supported by the serial
port's <acronym>UART</acronym> semiconductor chip. Early
<acronym>UART</acronym>s without on-chip receive buffers could
only reliably receive at up to 14400<abbrev>bps</abbrev>, this
includes models 8250A, 82510, 16450 and 16550 (with no
<wordasword>A</wordasword>). Recent <acronym>UART</acronym>s with
receive buffers will work at all serial console bit rates, this
includes models 16550A, 16552, 16650, 16654, 16750, 16850 and
16950.</para>
<para>Unless you have good reason, use the popular bit rate of
9600 bits per second. This is the default bit rate of a great
many devices.</para>
<para>The speeds that are supported by the kernel, the three
common boot loaders, and all <productname><acronym>IBM</acronym>
<acronym>PC</acronym>s</productname> capable of running
<systemitem class="osname">Linux</systemitem> are: 2400, 4800,
9600 and 19200 bits per second. This is a depressingly small
selection: not slow enough to support a call over an
international phone circuit and not fast enough to upload large
files. You may need to choose a speed that will result in a
less robust software configuration.</para>
<figure id="preparation-setspeed-bps">
<title>Syntax for serial bits per second rate, in extended
Backus-Naur form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;speed&gt;</replaceable> ::= <replaceable>&lt;digits&gt;</replaceable>
<replaceable>&lt;digits&gt;</replaceable> ::= <replaceable>&lt;digit&gt;</replaceable> | <replaceable>&lt;digit&gt;</replaceable><replaceable>&lt;digits&gt;</replaceable>
<replaceable>&lt;digit&gt;</replaceable> ::= <literal>0</literal> | <literal>1</literal> | &hellip; | <literal>9</literal>
</literallayout>
</figure>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>&lt;parity&gt;</replaceable></term>
<listitem>
<para>Number of parity bits and the interpretation of a parity
bit if one is present.</para>
<para>Allowed values are <literal>n</literal> for no parity bit,
<literal>e</literal> for one bit of even parity and
<literal>o</literal> for one bit of odd parity.</para>
<para>Using no parity bit and eight data bits is
recommended.</para>
<para>If parity is used then even parity is the common
choice.</para>
<para>Parity is a simple form of error detection. Modern modems
have much better error detection and correction. As a result
the parity bit guards only the data on the cable between the
modem and the serial port. If this cable has a low error rate,
and it should, then the parity bit is not required.</para>
<figure id="preparation-setspeed-parity">
<title>Syntax for serial parity, in extended Backus-Naur
form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;parity&gt;</replaceable> ::= <literal>n</literal> | <literal>e</literal> | <literal>o</literal>
</literallayout>
</figure>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>&lt;data&gt;</replaceable></term>
<listitem>
<para>The number of data bits per character.</para>
<para>Allowed values are <literal>7</literal> bits or
<literal>8</literal> bits, as Linux uses the
<acronym>ASCII</acronym> character set which requires at least
seven bits.</para>
<para>Eight data bits are recommended. This allows the link to
easily be used for file transfers and allows non-English text to
be presented.</para>
<figure id="preparation-setspeed-data">
<title>Syntax for serial data bits, in extended Backus-Naur
form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;data&gt;</replaceable> ::= <literal>7</literal> | <literal>8</literal>
</literallayout>
</figure>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>&lt;stop&gt;</replaceable></term>
<listitem>
<para>The number of stop bit-times.<footnote>
<para>A <wordasword>bit-time</wordasword> is the time taken to
transmit one bit. The distinction between
<wordasword>bit-times</wordasword> of signal and
<wordasword>bits</wordasword> of data is apparent when you
consider that 1.5 bit-times of signal is possible but that 1.5
bits of data is impossible.</para></footnote></para>
<para>Allowed values are <literal>1</literal> or
<literal>2</literal>.</para>
<para>One stop bit-time is recommended.</para>
<para>If the <acronym>RS-232</acronym> cable is very long then
two stop bit-times may be needed.</para>
<para>You may occassionally see 1.5 stop bit-times. The intent
is to gain 4% more data throughput when a link is too long for
one stop bit-time but is too short to require two stop
bit-times. 1.5 stop bit-times is now rare enough to be a hazard
to use.</para>
<figure id="preparation-setspeed-stop">
<title>Syntax for serial stop bits, in extended Backus-Naur
form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;stop&gt;</replaceable> ::= <literal>1</literal> | <literal>2</literal>
</literallayout>
</figure>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable>&lt;flow_control&gt;</replaceable></term>
<listitem>
<para>The type of flow control to use.</para>
<para>The Linux kernel allows no flow control and
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow
control.</para>
<para>No flow control is the default, this is indicated by
omitting &lt;flow_control&gt;.</para>
<para><acronym>CTS</acronym>/<acronym>RTS</acronym> flow control
is recommended, especially if login access is also provided to
the serial port. This is indicated by a &lt;flow_control&gt; of
<literal>r</literal>.</para>
<para><acronym>CTS</acronym>/<acronym>RTS</acronym> flow control
regulates the flow of chatacters. The computer does not send
characters until Clear To Send is asserted by the modem. If the
computer is has enough buffering to recieve characters from the
modem the computer asserts Ready to Send. Thus neither the
computer nor the modem's buffers are filled to
overflowing.</para>
<caution>
<para>The kernel's
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control is
currently buggy. Machines can take a significant time to write
console messages if flow control is enabled but
<acronym>CTS</acronym> will never be asserted (as occurs when
there is no call present on a modem or no session on a null
modem cable or cable to a terminal server). As a result of the
large number of kernel messages when the kernel is started a
machine configured with the kernel's
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control can
take many minutes to reboot.</para>
<para>The kernel's
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control
cannot be recommended at this time. The
<citetitle>HOWTO</citetitle>'s author has a kernel patch
available which he is seeking to have included in the
mainstream kernel source code.</para>
<para>The <acronym>CTS</acronym>/<acronym>RTS</acronym> flow
control in user-space applications does not share the kernel's
bugs and <acronym>CTS</acronym>/<acronym>RTS</acronym> flow
control is still recommended for
<application>getty</application>.</para>
</caution>
<figure id="preparation-setspeed-flow">
<title>Syntax for serial flow control, in extended Backus-Naur
form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;flow_control&gt;</replaceable> ::= <replaceable>&lt;nil&gt;</replaceable> | <literal>r</literal>
</literallayout>
</figure>
</listitem>
</varlistentry>
</variablelist>
<para>At present the <acronym>RS-232</acronym> status lines are
ignored by the kernel. A kernel message will be printed even if
Data Carrier Detect and Data Set Ready are not asserted. This
leads to the kernel messages being sent to a modem which is idle
and in command mode.</para>
<para>The console's slack interpretation of <acronym>CTS</acronym>,
<acronym>DSR</acronym> and <acronym>DCD</acronym> makes it
impossible to connect a serial console to an
<acronym>RS-232</acronym> multi-drop circuit. Multi-drop circuits
have more than two computers on the circuit; they are traditionally
four-wire, satelite or wireless services.</para>
<para>The Linux kernel uses the syntax in <xref
linkend="preparation-setspeed-modesyntax"> to describe the serial
parameters. Many boot loaders use a variation of the syntax used
by the Linux kernel.</para>
<figure id="preparation-setspeed-modesyntax">
<title>Syntax for kernel serial parameters, in extended
Backus-Naur form</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;mode&gt;</replaceable> ::= <replaceable>&lt;speed&gt;</replaceable><replaceable>&lt;parity&gt;</replaceable><replaceable>&lt;data&gt;</replaceable><replaceable>&lt;flow_control&gt;</replaceable>
</literallayout>
</figure>
<para>Note that <replaceable>&lt;mode&gt;</replaceable> does not
include <replaceable>&lt;stop&gt;</replaceable>. The kernel
assumes the number of stop bits to be one. This shortcoming needs
to be considered when deploying long <acronym>RS-232</acronym>
cables.</para>
<para>Most boot loaders default to <literal>9600n8</literal>. A
common default found on older terminals is
<literal>9600e7</literal>.</para>
<para>Use <literal>9600n8</literal> if possible, as this is the
default for most Linux software and modern devices.</para>
<para>This <citetitle>HOWTO</citetitle> always configures the
serial speed and parameters, even where not strictly necessary.
This is so that people configuring parameters other than the
recommended and common default value <literal>9600n8</literal>
will know what to alter.</para>
</section> <!-- preparation-setspeed -->
<section id="preparation-modem">
<title>Configure the modem or the null-modem cable</title>
<para>If a modem is used, configure it to be a dumb modem at the
port speed selected in <xref linkend="preparation-setspeed">. If
the modem accepts Hayes <acronym>AT</acronym> commands see <xref
linkend="modem"> to dumb-down the modem.</para>
<para>Alternatively if a terminal and a null-modem cable are used
see <xref linkend="serial-pc-terminal">, which discusses the pinout
of the null modem cable.</para>
</section> <!-- preparation-modem -->
<section id="preparation-terminal">
<title>Configure the terminal or the terminal emulator</title>
<para>Configure the terminal to match the serial parameters. The
data bits, parity bits and stop bits must match. If a modern
<quote>smart</quote> modem is used then the bit speeds need not
match. If a dumb modem or a null modem cable is used then the bit
speeds must match.</para>
<para>Set <acronym>CTS</acronym>/<acronym>RTS</acronym> handshaking
on, <acronym>DTR</acronym>/<acronym>DSR</acronym> handshaking off
and <acronym>XON</acronym>/<acronym>XOFF</acronym> handshaking off.
Your equipment may call
<acronym>CTS</acronym>/<acronym>RTS</acronym> handshaking or
<acronym>DTR</acronym>/<acronym>DSR</acronym> handshaking
<quote>hardware handshaking</quote> and may call
<acronym>XON</acronym>/<acronym>XOFF</acronym> handshaking
<quote>software handshaking</quote>.</para>
<para>Set automatic line wrapping on. This allows all of a long
console message to be read.</para>
<para>Set the received end of line characters to
<acronym>CR</acronym> <acronym>LF</acronym> (carriage return then
line feed). Set the transmitted end of line characters to just
<acronym>CR</acronym> (carriage return).</para>
<para>If you are using a terminal emulator then it is best to
choose to emulate the popular <acronym>DEC</acronym>
<productname>VT100</productname> or
<productname>VT102</productname> terminal. Later terminals in the
<acronym>DEC</acronym> <acronym>VT</acronym> range are compatible
with the <productname>VT100</productname>. If this terminal is not
available then try to emulate another terminal that implements
<citetitle><acronym>ANSI</acronym> <acronym>X3.64-1979</acronym>
Additional Controls for Use with American National Standard Code
for Information Interchange</citetitle> (or its successor
<citetitle> <acronym>ISO</acronym>/<acronym>IEC</acronym> 6429:1992
<acronym>ISO</acronym> Information technology &mdash; Control
functions for coded character sets</citetitle>). For example, many
emulators have a terminal called <literal>ANSI BBS</literal> which
uses the <productname>IBM PC</productname> character set, the 16
<productname>IBM PC</productname> colors, a 80 column by 25 line
screen and a selection of <citetitle>X3.64-1979</citetitle> control
sequences.</para>
<para>See the <ulink
url="http://www.tldp.org/HOWTO/Text-Terminal-HOWTO.html"><citetitle>Text-Terminal-HOWTO</citetitle></ulink>
for much more information on configuring terminals.</para>
</section> <!-- preparation-terminal -->
</chapter> <!-- preparation -->
<chapter id="bios">
<title>Optionally configure the <acronym>BIOS</acronym></title>
<para>Some <acronym>BIOS</acronym>s provide support for serial
consoles. If your computer's <acronym>BIOS</acronym> is one of
these you should investigate the extent of the support provided.
Depending upon the extent of serial console support you may not need
to explicitly configure the boot loader to use the serial
port.</para>
<para>The contributors to this <citetitle>HOWTO</citetitle> have
encountered the following styles of <acronym>BIOS</acronym> support
for serial consoles.</para>
<variablelist>
<varlistentry>
<term>Redirection of textual VGA output to the serial port</term>
<listitem>
<para>The <acronym>BIOS</acronym> takes the interrupt 0x10
<quote>video</quote> requests used to write to the screen and
sends the characters that would have appeared on the screen to
the serial port. Characters recieved from the serial port are
used to supply characters to <acronym>BIOS</acronym> interrupt
0x16 <quote>read key</quote> requests.</para>
<para>Any 16-bit application which uses the
<acronym>BIOS</acronym> functions for outputing text to the
screen and reading from the keyboard is redirected to the serial
port. This includes the <acronym>BIOS</acronym> itself, the boot
loader, and 16-bit operating systems (such as
<productname><acronym>MS-DOS</acronym></productname>).</para>
<para>When a 32-bit operating system (such as <systemitem
class="osname">Linux</systemitem>, <systemitem
class="osname">BSD</systemitem> or <systemitem
class="osname">Windows NT/2000/XP</systemitem>) loads the 16-bit
<acronym>BIOS</acronym> is no longer accessible and the
<acronym>BIOS</acronym> can no longer be used for input and
output. The 32-bit operating system loads its own device drivers
for this purpose. These device drivers then need to provide the
redirection of console <acronym>I/O</acronym> to the serial
port.</para>
<para>If your <acronym>BIOS</acronym> uses this technique then
you should:</para>
<procedure>
<step>
<para>Configure the <acronym>BIOS</acronym> to redirect
keyboard input and video output to the serial port.</para>
</step>
<step>
<para>Do not configure the boot loader, as the
<acronym>BIOS</acronym> will redirect this 16-bit application's
input and output to the serial port.</para>
</step>
<step>
<para>Configure <systemitem class="osname">Linux</systemitem>
to use the serial port as a console, as <systemitem
class="osname">Linux</systemitem> is a 32-bit operating
system.</para>
</step>
</procedure>
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>BIOS</acronym> configuration and power on self-test
uses the serial port</term>
<listitem>
<para>These <acronym>BIOS</acronym>s use the serial port for
configuration and the power-on self-test, but do not redirect the
interrupt 0x10 <quote>video</quote> requests interrupt 0x16
<quote>read key</quote> requests to the serial port.</para>
<para>Some <acronym>BIOS</acronym>s which usually redirect all
keyboard and video output to the serial port can be configured in
only to redirect <acronym>BIOS</acronym> input and output. Look
for a <acronym>BIOS</acronym> configuration option similar to
<guimenuitem>Cease redirection after boot</guimenuitem>.</para>
<para>If your <acronym>BIOS</acronym> uses this technique or you
choose to set <guimenuitem>Cease redirection after
boot</guimenuitem> then you should:</para>
<procedure>
<step>
<para>Configure the <acronym>BIOS</acronym> to send its output
to the serial port.</para>
</step>
<step>
<para>Configure the boot loader to use the serial port.</para>
</step>
<step>
<para>Configure <systemitem class="osname">Linux</systemitem>
to use the serila port as the console, as <systemitem
class="osname">Linux</systemitem> is a 32-bit operating
system.</para>
</step>
</procedure>
</listitem>
</varlistentry>
<varlistentry>
<term>Redirection of graphical <acronym>VGA</acronym> output to
the serial port</term>
<listitem>
<para>Some graphical 32-bit operating systems do not provide
their own facilities to send console output to the serial port.
Some BIOSs attempt to overcome this shortcoming, using a
propietary serial protocol to send graphical output to a remote
serial client.</para>
<para>As these machines cannot be connected to from a standard
terminal emulator this facility is best left unconfigured when
using the <systemitem class="osname">Linux</systemitem> operating
system.</para>
<procedure>
<step>
<para>Configure the <acronym>BIOS</acronym> not to send output
to the serial port.</para>
</step>
<step>
<para>Configure the boot loader to use the serial port.</para>
</step>
<step>
<para>Configure <systemitem class="osname">Linux</systemitem>
to use the serial port as the console.</para>
</step>
</procedure>
</listitem>
</varlistentry>
<varlistentry>
<term>No serial port facilities</term>
<listitem>
<para>The <acronym>BIOS</acronym> cannot be accessed from the
serial port, so power-on self-test messages cannot be
seen.</para>
<para>Note that <acronym>BIOS</acronym> may still be able to be
configured remotely using the <filename
class="devicefile">/dev/nvram</filename> device. This takes some
care.</para>
<procedure>
<step>
<para>Configure the boot loader to use the serial port.</para>
</step>
<step>
<para>Configure <systemitem class="osname">Linux</systemitem>
to use the serial port as the console.</para>
</step>
</procedure>
</listitem>
</varlistentry>
</variablelist>
<para>If you need to configure the boot loader to use the serial
port then continue to <xref linkend="configure-boot-loader">.
Otherwise go directly to <xref linkend="configure-kernel"> to
configure the kernel; this is done by configuring the boot loader to
pass boot parameters to the <systemitem
class="osname">Linux</systemitem> kernel.</para>
</chapter> <!-- bios -->
<chapter id="configure-boot-loader">
<title>Configure the boot loader</title>
<para>When a PC boots the CPU it runs code from Read-Only Memory.
This code is the Basic Input/Output System, or
<acronym>BIOS</acronym>. The <acronym>BIOS</acronym> then loads a
boot loader from the Master Boot Record of the first hard
disk.<footnote>
<para>As usual with <productname><acronym>IBM
PC/AT</acronym></productname> hardware <quote>loads a boot loader
from the <acronym>MBR</acronym> of the first hard disk</quote> is a
simplification. <acronym>BIOS</acronym> settings permitting, the
<acronym>MBR</acronym> can be loaded from the first two detected
hard disks of any controller card containing a
<acronym>BIOS</acronym> extension. Thus the
<acronym>MBR</acronym> can be loaded from one of the first two
detected <acronym>IDE</acronym> disks and one of the first two
detected <acronym>SCSI</acronym> disks.</para></footnote>
In turn, the boot loader reads the operating system into memory and
then runs it.<footnote>
<para>Another simplification. A 512 byte <acronym>MBR</acronym>
is too small to contain a program big enough to load a complex
operating system. Thus most boot loaders have two stages, the
first stage is located in the <acronym>MBR</acronym> and is only
able to load the second stage of the boot loader from somewhere on
a disk (such as the boot sector of the first partition). The
second stage of the boot loader presents the user interface and
loads the operating system.</para></footnote></para>
<para>Neither the <acronym>BIOS</acronym> nor the boot loader are
strictly necessary. For example, there are <ulink
url="http://www.acl.lanl.gov/linuxbios/">versions of Linux</ulink>
that run directly from the flash memory which usually contains the
<acronym>BIOS</acronym>. Linux was originally designed to run
without an interactive boot loader, by placing the kernel at
particular sectors of the disk.</para>
<para>The benefits of using a boot loader are:</para>
<itemizedlist>
<listitem>
<para>Multiple operating systems can be booted. See the <ulink
url="http://www.tldp.org/HOWTO/Linux+Windows-HOWTO/"><citetitle><systemitem
class="osname">Linux</systemitem> + <systemitem
class="osname">Windows</systemitem> HOWTO</citetitle></ulink> for
more information.</para>
</listitem>
<listitem>
<para>Parameters can be passed to the kernel interactively. This
is useful for solving hardware problems; for example, some
interrupt lines can be disabled, direct memory access to some
drives can be disabled, and so on. See the <ulink
url="http://www.tldp.org/HOWTO/BootPrompt-HOWTO.html"><citetitle><systemitem
class="osname">Linux</systemitem>
BootPrompt-HOWTO</citetitle></ulink> for a list of kernel
parameters.</para>
</listitem>
<listitem>
<para>Differing kernels can be interactively loaded. This is
useful when deploying a new kernel, as it provides simple fallback
to a proven kernel.</para>
</listitem>
</itemizedlist>
<para>For these reasons systems administrators want to be able to
interactively control the boot loader from the serial
console.</para>
<para><application>LILO</application>,
<application>GRUB</application> and
<application>SYSLINUX</application> are popular boot loaders for
<productname><acronym>IBM</acronym>
<acronym>PC</acronym>s</productname>. Find which of these boot
loaders your <systemitem class="osname">Linux</systemitem>
installation uses and then follow the instructions for your boot
loader in the following section.</para>
<section id="configure-boot-loader-lilo">
<title>Configure the <application>LILO</application> boot
loader</title>
<para><application>LILO</application> is the Linux Boot Loader used
on Intel machines. Other boot loaders for Intel machines exist,
common alternatives are <application>GRUB</application> and
<application>SYSLINUX</application>. Equivalents to
<application>LILO</application> exist for other processor
architectures, their names are usually some play upon
<quote>LILO</quote>.</para>
<para><application>LILO</application> is documented in the
<citetitle>lilo(8)</citetitle> and
<citetitle>lilo.conf(5)</citetitle> manual pages; the
<citetitle><application>LILO</application> Generic boot loader for
Linux &hellip; User's Guide</citetitle> found in the file
<filename>/usr/share/doc/lilo&hellip;/doc/User_Guide.ps</filename>;
and the <ulink
url="http://www.tldp.org/HOWTO/mini/LILO.html"><citetitle>LILO
mini-HOWTO</citetitle></ulink>.</para>
<para>The <application>LILO</application> configuration is kept in
the file <filename>/etc/lilo.conf</filename>. The first part of
the file applies to all images. The following parts are
<literal>image</literal> descriptions for each kernel.</para>
<para>Set <application>LILO</application> to use the serial port.
The syntax of the serial line parameters follows that used by the
kernel.</para>
<figure id="configure-boot-loader-lilo-syntax">
<title>Syntax of <productname>LILO</productname>
<command>serial</command> command, in
<acronym>EBNF</acronym></title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
serial=<replaceable>&lt;serial_port&gt;</replaceable>[,<replaceable>&lt;speed&gt;</replaceable>[<replaceable>&lt;parity&gt;</replaceable>[<replaceable>&lt;data&gt;</replaceable>]]]
</literallayout>
</figure>
<para>Where the variables are the same as used by the kernel (shown
in <xref linkend="preparation-setspeed-modesyntax">) and:</para>
<figure id="configure-boot-loader-lilo-ebnf">
<title><productname>LILO</productname> <command>serial</command>
<acronym>EBNF</acronym> variables</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;serial_port&gt;</replaceable> ::= <literal>0</literal> | <literal>1</literal>| &hellip; | <literal>3</literal>
</literallayout>
</figure>
<para>Our examples use <filename
class="devicefile">/dev/ttyS0</filename>, which
<application>LILO</application> knows as port
<literal>0</literal>.</para>
<figure id="configure-boot-loader-lilo-configuration">
<title><application>LILO</application> boot loader sample configuration</title>
<programlisting format="linespecific">
serial=0,9600n8
timeout=100
restricted
password=<replaceable>PASSWORD</replaceable></programlisting>
</figure>
<para>The parameters <literal>restricted</literal> and
<literal>password</literal> are used to avoid someone dialing in,
booting the machine, and stepping around the Linux access
permissions by typing:</para>
<example id="configure-boot-loader-lilo-hack">
<title>Using kernel parameters to avoid access permissions</title>
<screen format="linespecific">
<prompt>LILO:</prompt> <command>linux init=/sbin/sash</command></screen>
</example>
<para>The password should be good, as it can be used to gain
<systemitem class="username">root</systemitem> access. The
<application>LILO</application> password is stored in plain text in
the configuration file, so it should never be the same as any other
password. The permissions on the configuration file should be set
so that only <systemitem class="username">root</systemitem> can
read <filename>/etc/lilo.conf</filename>.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>chmod u=rw,go= /etc/lilo.conf</command></screen>
</informalfigure>
<para><application>LILO</application> has an option to display a
boot message. This does not work with serial consoles. Remove any
lines like:</para>
<informalfigure id="configure-boot-loader-lilo-remove-message">
<programlisting format="linespecific">
message=/boot/message</programlisting>
</informalfigure>
<para><application>LILO</application> is now configured to use the
serial console. The kernels booted from
<application>LILO</application> are yet to be configured to use the
serial console.</para>
</section> <!-- configure-boot-loader-lilo -->
<section id="configure-boot-loader-grub">
<title>Configure the <application>GRUB</application> boot
loader</title>
<para><application>GRUB</application> is a boot loader designed to
boot a wide range of operating systems from a wide range of
filesystems. <application>GRUB</application> is becoming popular
due to the increasing number of possible root filesystems that can
Linux can reside upon.</para>
<para><application>GRUB</application> is documented in a
<abbrev>GNU</abbrev> info file. Type <command>info grub</command>
to view the documentation.</para>
<para>The <application>GRUB</application> configuration file is
<filename>/boot/grub/menu.lst</filename>. Some distributions use
another configuration file; for example, <productname>Red Hat
Linux</productname> uses the file
<filename>/boot/grub/grub.conf</filename>.</para>
<para><application>GRUB</application> configuration files are
interpreted. Syntax errors will not be detected until the machine
is rebooted, so take care not to make typing errors.</para>
<para>Edit the <application>GRUB</application> configuration file
and remove any <command>splashimage</command> entries. If these
entries are not removed <application>GRUB</application> 0.90
behaves very oddly, transferring control between the serial console
and the attached monitor and keyboard.</para>
<para>If there is not already a <command>password</command> command
in the <application>GRUB</application> configuration file then
create a hashed password, see <xref
linkend="configure-boot-loader-grub-md5">. The password should be
good, as it can be used to gain <systemitem
class="username">root</systemitem> access.</para>
<figure id="configure-boot-loader-grub-md5">
<title>Using <command>md5crypt</command> to create a hashed
password for <application>GRUB</application> </title>
<screen format="linespecific">
<prompt>grub></prompt> <command>md5crypt</command>
<prompt>Password</prompt>: <userinput>**********</userinput>
<computeroutput>Encrypted: $1$U$JK7xFegdxWH6VuppCUSIb.</computeroutput></screen>
</figure>
<para>Use that hashed password in the
<application>GRUB</application> configuration file, this is shown
in <xref linkend="configure-boot-loader-grub-password">.</para>
<figure id="configure-boot-loader-grub-password">
<title><application>GRUB</application> configuration to require a
password</title>
<programlisting>
password &hyphen;&hyphen;md5 $1$U$JK7xFegdxWH6VuppCUSIb.</programlisting>
</figure> <!-- configure-boot-loader-grub-password -->
<para>Define the serial port and configure
<application>GRUB</application> to use the serial port, as shown in
<xref linkend="configure-boot-loader-grub-serial">.</para>
<figure id="configure-boot-loader-grub-serial">
<title><application>GRUB</application> configuration for serial
console</title>
<programlisting>
serial &hyphen;&hyphen;unit=0 &hyphen;&hyphen;speed=9600 &hyphen;&hyphen;word=8 &hyphen;&hyphen;parity=no &hyphen;&hyphen;stop=1
terminal serial</programlisting>
</figure> <!-- configure-boot-loader-grub-configuration -->
<para><literal>&hyphen;&hyphen;unit</literal> is the number of the
serial port, counting from zero, unit 0 being
<literal>COM1</literal>.</para>
<para>Note that the values of
<literal>&hyphen;&hyphen;parity</literal> are spelt out in full:
<literal>no</literal>, <literal>even</literal> and
<literal>odd</literal>. The common abbreviations
<literal>n</literal>, <literal>e</literal> and <literal>o</literal>
are <emphasis>not</emphasis> accepted.</para>
<para>If there is mysteriously no output on the serial port then
suspect a syntax error in the <command>serial</command> or
<command>terminal</command> commands.</para>
<para>If you also want to use and attached monitor and keyboard as
well as the serial port to control the
<application>GRUB</application> boot loader then use the
alternative configuration in <xref
linkend="configure-boot-loader-grub-serialconsole">.</para>
<figure id="configure-boot-loader-grub-serialconsole">
<title><application>GRUB</application> configuration for serial
console and attached monitor and keybaord console</title>
<programlisting>
password &hyphen;&hyphen;md5 $1$U$JK7xFegdxWH6VuppCUSIb.
serial &hyphen;&hyphen;unit=0 &hyphen;&hyphen;speed=9600 &hyphen;&hyphen;word=8 &hyphen;&hyphen;parity=no &hyphen;&hyphen;stop=1
terminal &hyphen;&hyphen;timeout=10 serial console</programlisting>
</figure> <!-- configure-boot-loader-grub-configuration -->
<para>When both the serial port and the attached monitor and
keyboard are configured they will both ask for a key to be pressed
until the timeout expires. If a key is pressed then the boot menu
is displayed to that device. Disconcertingly, the other device
sees nothing.</para>
<para>If no key is pressed then the boot menu is displayed on the
whichever of <literal>serial</literal> or
<literal>console</literal> is listed first in the
<command>terminal</command> command. After the timeout set by the
<command>timeout</command> the default option set by
<command>default</command> is booted.</para>
<figure id="configure-boot-loader-grub-press">
<title>GRUB output to default device when configured for serial
and attached monior output</title>
<screen format="linespecific">
<computeroutput>Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
GRUB version 0.90 (639K lower / 162752K upper memory)
+-------------------------------------------------------------------------+
| [ Red Hat Linux (2.4.9-21) ] |
| |
| |
+-------------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS or 'p' to enter a
password to unlock the next set of features.
The highlighted entry will be booted automatically in 10 seconds.
</computeroutput></screen>
</figure>
<para>If you are not using a <acronym>VT100</acronym> terminal then
the cursor keys may not work to select a
<application>GRUB</application> menu item. The instructions shown
in <xref linkend="configure-boot-loader-grub-press"> are literally
correct: <guilabel>Use the ^ and v keys</guilabel> means that the
caret key
(<keycombo><keycap>Shift</keycap><keycap>6</keycap></keycombo>)
moves the cursor up and letter vee key (<keycap>V</keycap>) moves
the cursor down.</para>
<para>Note when configuring <application>GRUB</application> that
there are two timeouts involved. <computeroutput>Press any key to
continue</computeroutput> is printed for <command>terminal
--timeout=10</command> seconds, waiting for someone on the keyboard
or terminal to press a key to get the input focus. Then the menu
is displayed for <command>timeout 10</command> seconds before the
default boot option is taken.</para>
<para>If the terminal attached to the serial port is not a real or
emulated <productname>VT100</productname>, then force
<application>GRUB</application> to use it's command line interface.
This interface is much more difficult to use than
<application>GRUB</application>'s menu interface; however, the
command line interface does not assume the
<productname>VT100</productname>'s terminal language.</para>
<figure id="configure-boot-loader-grub-dumb">
<title><application>GRUB</application> configuration for command
line interface for terminals other than
<productname>VT100</productname></title>
<programlisting>
terminal &hyphen;&hyphen;timeout=10 &hyphen;&hyphen;dumb serial console</programlisting>
</figure> <!-- configure-boot-loader-grub-dumb -->
<para>This <citetitle>HOWTO</citetitle> does not discuss the use of
<application>GRUB</application>'s command line. It is far too
complex and error-prone to recommend for use on production
machines. Wizards will know to consult
<application>GRUB</application>'s <application>info</application>
manual for the commands required to boot the kernel.</para>
<para><application>GRUB</application>'s menu's can be edited
interactively after <keycap>P</keycap> is pressed and the password
supplied. A better approach is to add menu items to boot the
machine into alternative run levels. A sample configuration
showing a menu entry for the default run level and an alternative
menu entry for single user mode (run level
<wordasword>s</wordasword>) is shown in <xref
linkend="configure-boot-loader-grub-runlevel">. Remember to use
the <command>lock</command> command to require a password for
single user mode, as single user mode does not ask for a
<systemitem class="osname">Linux</systemitem> password.</para>
<figure id="configure-boot-loader-grub-runlevel">
<title>Adding a single user mode option to the
<application>GRUB</application> menu</title>
<programlisting>
password &hyphen;&hyphen;md5 $1$U$JK7xFegdxWH6VuppCUSIb.
default 0
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
initrd /initrd-2.4.9-21.img
title Red Hat Linux (2.4.9-21) single user mode
lock
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 s
initrd /initrd-2.4.9-21.img
</programlisting>
</figure>
<para>File names in the <command>kernel</command> and
<command>initrd</command> commands are relative to the
<application>GRUB</application> installation directory, which is
usually <filename class="directory">/boot/grub</filename>. So
<filename>/vmlinuz-2.4.9-21</filename> is actually the file
<filename>/boot/grub/vmlinuz-2.4.9-21</filename>.</para>
<para><application>GRUB</application> is now configured to use the
serial console. The kernels booted from
<application>GRUB</application> are yet to be configured to use the
serial console.</para>
</section> <!-- configure-boot-grub -->
<section id="configure-boot-loader-syslinux">
<title>Configure the <application>SYSLINUX</application> boot
loader</title>
<para><ulink
url="http://syslinux.zytor.com/"><productname><application>SYSLINUX</application></productname></ulink>
is a boot loader that is installed on a MS-DOS floppy disk. As
directed by it's configuration file
<filename>\SYSLINUX.CFG</filename> it will load one of the files
from the floppy disk as a Linux kernel.</para>
<para><application>SYSLINUX</application> presents a simple text
interface that can be used to select between canned configurations
defined in the configuration file and can be used to add parameters
to the kernel.</para>
<para><application>ISOLINUX</application> and
<application>PXELINUX</application> are variants of
<application>SYSLINUX</application> for CD-ROMs and Intel's <ulink
url="http://developer.intel.com/ial/wfm/"><productname>Preboot
Execution Environment</productname></ulink>.</para>
<para><application>SYSLINUX</application> supports a variety of
serial port speeds, but it only supports eight data bits, no parity
and one stop bit. <application>SYSLINUX</application> supports the
serial ports <filename class="devicefile">COM1:</filename> through
to <filename class="devicefile">COM4:</filename>, as with most boot
loaders these are written as port <literal>0</literal> through to
port <literal>3</literal>.</para>
<para>For <application>SYSLINUX</application> to support a serial
console add a new <emphasis>first line</emphasis> to
<filename>\SYSLINUX.CFG</filename>:</para>
<figure id="configure-boot-loader-syslinux-serial-syntax">
<title>Syntax of <productname>SYSLINUX</productname>
<command>serial</command> command, in
<acronym>EBNF</acronym></title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<literal>serial</literal> <replaceable>&lt;space&gt;</replaceable> <replaceable>&lt;serial_port&gt;</replaceable> [ <replaceable>&lt;space&gt;</replaceable> <replaceable>&lt;speed&gt;</replaceable> [ <replaceable>&lt;space&gt;</replaceable> <replaceable>&lt;syslinux_flow_control&gt;</replaceable> ] ]
</literallayout>
</figure>
<para>The variables are the same as used by syntax descriptions in
<xref linkend="preparation-setspeed-modesyntax"> and <xref
linkend="configure-boot-loader-lilo-ebnf"> plus those in <xref
linkend="configure-boot-loader-syslinux-ebnf">.</para>
<figure id="configure-boot-loader-syslinux-ebnf">
<title><productname>SYSLINUX</productname>
<command>serial</command> <acronym>EBNF</acronym> variables</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;space&gt;</replaceable> ::= &lsquo;<literal> </literal>&rsquo;
<replaceable>&lt;syslinux_flow_control&gt;</replaceable> ::= <replaceable>&lt;hex_digits&gt;</replaceable>
<replaceable>&lt;hex_digits&gt;</replaceable> ::= <literal>0x</literal><replaceable>&lt;hex_digit&gt;</replaceable><replaceable>&lt;hex_digit&gt;</replaceable><replaceable>&lt;hex_digit&gt;</replaceable>
<replaceable>&lt;hex_digit&gt;</replaceable> ::= <literal>0</literal> | <literal>1</literal> | &hellip; | <literal>9</literal> | <literal>a</literal> | <literal>b</literal> | &hellip; | <literal>f</literal></literallayout>
</figure>
<para>The <replaceable>&lt;syslinux_flow_control&gt;</replaceable>
variable controlling the <acronym>RS-232</acronym> status and flow
control signals is optional. If your null-modem cable does not
present any status or handshaking signals then do not use it. The
value of <replaceable>&lt;syslinux_flow_control&gt;</replaceable>
is calculated by adding the hexadecimal values for the desired flow
control behaviours listed in <xref
linkend="configure-boot-loader-syslinux-flowcontrol">.</para>
<para>The behaviours for a correctly-wired null-modem cable or a
correctly configured modem are marked <quote>Required for full
<acronym>RS-232</acronym> compliance</quote> in the table. The sum
of these values is <literal>0xab3</literal>.</para>
<table frame="topbot" colsep="0" rowsep="0" id="configure-boot-loader-syslinux-flowcontrol">
<title><productname>SYSLINUX</productname> flow control
bitmap</title>
<tgroup cols="3" align="center">
<thead valign="bottom">
<row rowsep="1">
<entry><para>Flow control behaviour</para></entry>
<entry><para>Hex value</para></entry>
<entry><para>Required for full <acronym>RS-232</acronym>
compliance?</para></entry>
</row>
</thead>
<tbody>
<row>
<entry align="left"><para>Assert DTR</para></entry>
<entry><para>0x001</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Assert RTS</para></entry>
<entry><para>0x002</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Wait for CTS assertion</para></entry>
<entry><para>0x010</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Wait for DSR assertion</para></entry>
<entry><para>0x020</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Wait for RI assertion</para></entry>
<entry><para>0x040</para></entry>
<entry><para>No</para></entry>
</row>
<row>
<entry align="left"><para>Wait for DCD assertion</para></entry>
<entry><para>0x080</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Ignore input unless CTS asserted</para></entry>
<entry><para>0x100</para></entry>
<entry><para>No</para></entry>
</row>
<row>
<entry align="left"><para>Ignore input unless DSR asserted</para></entry>
<entry><para>0x200</para></entry>
<entry><para>Yes</para></entry>
</row>
<row>
<entry align="left"><para>Ignore input unless RI asserted</para></entry>
<entry><para>0x400</para></entry>
<entry><para>No</para></entry>
</row>
<row>
<entry align="left"><para>Ignore input unless DCD asserted</para></entry>
<entry><para>0x800</para></entry>
<entry><para>Yes</para></entry>
</row>
</tbody>
</tgroup>
</table>
<para>Our preferred configuration of 9600<abbrev>bps</abbrev>,
port <literal>0</literal>, full <acronym>RS-232</acronym> status
signals and <acronym>CTS</acronym>/<acronym>RTS</acronym> flow
control is written as:</para>
<informalexample>
<programlisting>
serial 0 9600 0xab3</programlisting>
</informalexample>
<tip id="tip-syslinux-flowcontrol">
<para>When using this configuration <acronym>SYSLINUX</acronym>
will not display anything and will not accept any typed character
until the <acronym>RS-232</acronym> status signals show a
connected modem call (or a connected terminal if you are using a
null-modem cable).</para>
</tip>
<para>If you have a null modem cable with no RS-232 status signals
and no flow control then use:</para>
<informalexample>
<programlisting>
serial 0 9600</programlisting>
</informalexample>
<para>Remember that the <command>serial</command> command must be
the first line in <filename>\SYSLINUX.CFG</filename>.</para>
</section> <!-- configure-boot-loader-syslinux -->
</chapter> <!-- configure-boot-loader -->
<chapter id="configure-kernel">
<title>Configure <systemitem class="osname">Linux</systemitem>
kernel</title>
<para>The <systemitem class="osname">Linux</systemitem> kernel is
configured to select the console by passing it the
<literal>console</literal> parameter. The
<literal>console</literal> parameter can be given repeatedly, but
the parameter can only be given once for each console technology.
So <literal>console=tty0 console=lp0 console=ttyS0</literal> is
acceptable but <literal>console=ttyS0 console=ttyS1</literal> will
not work.</para>
<para>When multiple consoles are listed output is sent to all
consoles and input is taken from the last listed console. The last
<literal>console</literal> is the one Linux uses as the <filename
class="devicefile">/dev/console</filename> device.</para>
<para>The syntax of the <literal>console</literal> parameter is
given in <xref linkend="configure-kernel-syntax">.</para>
<figure id="configure-kernel-syntax">
<title>Kernel <literal>console</literal> syntax, in EBNF</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<literal>console=ttyS</literal><replaceable>&lt;serial_port&gt;</replaceable>[<literal>,</literal><replaceable>&lt;mode&gt;</replaceable>]
<literal>console=tty</literal><replaceable>&lt;virtual_terminal&gt;</replaceable>
<literal>console=lp</literal><replaceable>&lt;parallel_port&gt;</replaceable>
<literal>console=ttyUSB</literal>[<replaceable>&lt;usb_port&gt;</replaceable>[<literal>,</literal><replaceable>&lt;mode&gt;</replaceable>]
</literallayout>
</figure>
<para><replaceable>&lt;serial_port&gt;</replaceable> is the number
of the serial port. This is defined in <xref
linkend="configure-boot-loader-lilo-ebnf"> and discussed in <xref
linkend="preparation-setport">. The examples in this
<citetitle>HOWTO</citetitle> use the first serial port, giving
<replaceable>&lt;serial_port&gt;</replaceable> the value
<literal>0</literal>, which in turn gives kernel parameter
<literal>console=ttyS0</literal>.</para>
<para>If you are using the <application>devfs</application> device
filesystem with your Linux installation the kernel parameter for the
first serial port is still <literal>ttyS0</literal>, even though the
first serial device is no longer known as <filename
class="devicefile">/dev/ttyS0</filename> but as <filename
class="devicefile">/dev/ttys/0</filename>.</para>
<para><replaceable>&lt;mode&gt;</replaceable> is defined in <xref
linkend="preparation-setspeed-modesyntax"> and is discussed in <xref
linkend="preparation-setspeed">. The examples in this
<citetitle>HOWTO</citetitle> use 9600 bits per second, one start
bit, eight data bits, no parity, one stop bit, and no
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control giving
<replaceable>&lt;mode&gt;</replaceable> the value of
<literal>9600n8</literal>. When the current kernel flow control
bugs are corrected this <citetitle>HOWTO</citetitle> will once again
recommend the value <literal>9600n8r</literal>.</para>
<para><replaceable>&lt;usb_port&gt;</replaceable> can specify the
address of a <acronym>USB</acronym> dongle containing a serial port
to be used as a serial console.<footnote>
<para>A serial console attached to a <acronym>USB</acronym> dongle
is only available in Linux kernel version 2.5.7 and later. The
2.5 series of kernels are developer's kernels and are not ready
for production use.</para></footnote>
For example, the serial port <literal>console=ttyS0,9600n8</literal>
when moved to a <acronym>USB</acronym> serial dongle would be
written as <literal>console=ttyUSB0,9600n8</literal>. The
<acronym>USB</acronym> subsystem is started rather late in the boot
process, console messages printed during boot before the
<acronym>USB</acronym> subsystem is loaded will be lost.</para>
<para>With no <literal>console</literal> parameter the kernel will
use the first virtual terminal, which is <filename
class="devicefile">/dev/tty0</filename>. A user at the keyboard
uses this virtual terminal by pressing
<keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>F1</keycap></keycombo>.</para>
<para>If your computer contains a video card then we suggest that
you also configure it as a console. This is done with the kernel
parameter <literal>console=tty0</literal>.</para>
<para>For computers with both a video card and a serial console in
the port marked <quote><acronym>COM1:</acronym></quote> this
<citetitle>HOWTO</citetitle> suggests the kernel parameters:</para>
<figure id="configure-kernel-parameters-video">
<title>Recommended kernel parameters, <acronym>PC</acronym>s with
video card</title>
<programlisting format="linespecific">
console=tty0 console=ttyS0,9600n8
</programlisting>
</figure> <!-- configure-kernel-parameters-video -->
<para>Kernel messages will appear on both the first virtual terminal
and the serial port. Messages from the
<application>init</application> system and the system logger will
appear only on the first serial port. This can be slightly
confusing when looking at the attached monitor: the machine will
appear to boot and then hang. Don't panic, the
<application>init</application> system has started but is now
printing messages to the serial port but is printing nothing to the
screen. If a <application>getty</application> has been configured
then a <computeroutput>login:</computeroutput> prompt will
eventually appear on the attached monitor.</para>
<para>For <acronym>PC</acronym>s without a video card, this
<citetitle>HOWTO</citetitle> suggests the kernel parameters:</para>
<figure id="configure-kernel-parameters-novideo">
<title>Recommended kernel parameters, <acronym>PC</acronym>s
without video card</title>
<programlisting format="linespecific">
console=ttyS0,9600n8
</programlisting>
</figure> <!-- configure-kernel-parameters-video -->
<para>These parameters are passed to the booting kernel by the boot
loader. Next we will configure the boot loader used by your
<systemitem class="osname">Linux</systemitem> installation to pass
the <literal>console</literal> parameters to the kernel.</para>
<section id="configure-kernel-lilo">
<title>Configure Linux kernel using
<application>LILO</application></title>
<para>For each <literal>image</literal> entry in
<filename>/etc/lilo.conf</filename> add the line:</para>
<figure id="configure-kernel-lilo-parameters">
<title>Recommended kernel parameters, <application>LILO</application> configuration</title>
<programlisting>
append=&quot;console=tty0 console=ttyS0,9600n8&quot;</programlisting>
</figure>
<para>Sometimes the <literal>append</literal> line will already
exist. For example</para>
<informalexample id="configure-kernel-lilo-append-exists">
<programlisting>
append=&quot;mem=1024M&quot;</programlisting>
</informalexample>
<para>In this case, the existing <literal>append</literal> line is
modified to pass all the parameters. The result is:</para>
<informalexample id="configure-kernel-lilo-append-merge">
<programlisting>
append=&quot;mem=1024M console=tty0 console=ttyS0,9600n8&quot;</programlisting>
</informalexample>
<para>As a complete example, a typical
<filename>/etc/lilo.conf</filename> configuration from
<productname>Red Hat Linux</productname>
<productnumber>7.1</productnumber> is:</para>
<example id="configure-kernel-lilo-rhl-vendor">
<title>Complete <application>LILO</application> configuration, as
installed by vendor</title>
<programlisting>
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
default=linux
image=/boot/vmlinuz-2.4.2-2
label=linux
read-only
root=/dev/hda6
initrd=/boot/initrd-2.4.2-2.img</programlisting>
</example> <!-- configure-kernel-lilo-rhl-vendor -->
<para>This is modified to</para>
<example id="configure-kernel-lilo-rhl-serial">
<title>Complete <application>LILO</application> configuration, modified for serial console</title>
<programlisting>
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
default=linux
# Changes for serial console on COM1: in global section
# Deleted: message=/boot/message
serial=0,9600n8
timeout=100
restricted
password=de7mGPe3i8
image=/boot/vmlinuz-2.4.2-2
label=linux
read-only
root=/dev/hda6
initrd=/boot/initrd-2.4.2-2.img
# Changes for serial console on COM1: in each image section
append=&quot;console=tty0 console=ttyS0,9600n8&quot;</programlisting>
</example> <!-- configure-kernel-lilo-rhl-serial -->
<para>Now that we have finished configuring
<application>LILO</application>, use the <command>lilo</command>
command to install the new boot record onto the disk:</para>
<informalfigure id="configure-kernel-lilo-install">
<screen format="linespecific">
<prompt>bash#</prompt> <command>chown root:root /etc/lilo.conf</command>
<prompt>bash#</prompt> <command>chmod u=rw,g=,o= /etc/lilo.conf</command>
<prompt>bash#</prompt> <command>lilo</command>
<computeroutput>Added linux *</computeroutput></screen>
</informalfigure> <!-- configure-kernel-lilo-install -->
</section> <!-- configure-kernel-lilo -->
<section id="configure-kernel-grub">
<title>Configure Linux kernel using
<application>GRUB</application></title>
<para>Find each <literal>title</literal> entry in the GRUB
configuration file. It will be followed by a
<literal>kernel</literal> line. For example</para>
<informalfigure id="configure-kernel-grub-kernel-before">
<programlisting>
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
initrd /initrd-2.4.9-21.img</programlisting>
</informalfigure>
<para>Modify each of the <literal>kernel</literal> lines to append
the parameters that inform the kernel to use a serial
console.</para>
<figure id="configure-kernel-grub-kernel-after">
<title>Recommened kernel parameters,
<application>GRUB</application> configuration</title>
<programlisting>
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8
initrd /initrd-2.4.9-21.img</programlisting>
</figure>
<para>As a complete example, <xref
linkend="configure-kernel-grub-rhl-vendor"> is a typical GRUB
configuration from <productname>Red Hat Linux</productname>
<productnumber>7.2</productnumber>.</para>
<example id="configure-kernel-grub-rhl-vendor">
<title>Complete <application>GRUB</application> configuration, as
installed by vendor</title>
<programlisting>
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
password --md5 $1$wwmIq64O$2vofKBDL9vZKeJyaKwIeT.
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6
initrd /initrd-2.4.9-21.img</programlisting>
</example> <!-- configure-kernel-grub-rhl-vendor -->
<para>The modified configuration file is shown in <xref
linkend="configure-kernel-grub-rhl-serial">.</para>
<example id="configure-kernel-grub-rhl-serial">
<title>Complete <application>GRUB</application> configuration,
modified for serial console</title>
<programlisting>
default=0
timeout=10
password --md5 $1$wwmIq64O$2vofKBDL9vZKeJyaKwIeT.
serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8
initrd /initrd-2.4.9-21.img
title Red Hat Linux (2.4.9-21) single user mode
lock
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/hda6 console=tty0 console=ttyS0,9600n8 s
initrd /initrd-2.4.9-21.img
</programlisting>
</example> <!-- configure-kernel-grub-rhl-serial -->
</section> <!-- configure-kernel-grub-parameters -->
<section id="configure-kernel-syslinux">
<title>Configure Linux kernel using
<application>SYSLINUX</application></title>
<para>Edit each <literal>LABEL</literal> entry to add an
<literal>APPEND</literal> line containing the serial console
parameter to pass to the Linux kernel. Like
<application>LILO</application>, if a kernel already has
parameters, then add our parameters to the list after
<literal>APPEND</literal>.</para>
<para>For example:</para>
<figure id="configure-kernel-syslinux-append">
<title>Recommended kernel parameters,
<application>SYSLINUX</application> configuration</title>
<programlisting>
APPEND console=tty0 console=ttyS0,9600n8</programlisting>
</figure>
<para>There are some traps for beginners in the differences between
<application>LILO</application> and
<application>SYSLINUX</application>.
<application>LILO</application> uses <literal>append=</literal>,
whereas <application>SYSLINUX</application> uses just
<literal>append</literal>. <command>lilo</command> needs to be run
after each change to <filename>/etc/lilo.conf</filename>, whereas
<command>syslinux</command> does not need to be run after changing
<filename>\SYSLINUX.CFG</filename>.</para>
</section>
</chapter> <!-- configure-kernel -->
<chapter id="getty">
<title>Configure <productname>getty</productname></title>
<para><application>getty</application> monitors serial lines,
waiting for a connection. It then configures the serial link, sends
the contents of <filename>/etc/issue</filename>, and asks the person
connecting for their login name. <application>getty</application>
then starts <application>login</application> and
<application>login</application> asks the person for their password.
If the user does nothing, <application>getty</application> or
<application>login</application> hang up and
<application>getty</application> goes back to waiting.</para>
<para>The <application>getty</application> command has been
re-implemented numerous times. There is a wide selection of
<application>getty</application> clones, each with slight
differences in behavior and syntax. We will describe the
traditional <application>getty</application>, and then some popular
alternatives.</para>
<para>One of the jobs of a <application>getty</application> is to
set the <varname>TERM</varname> environment variable to indicate the
make and model of the terminal which is connecting. In this
<citetitle>HOWTO</citetitle> we set the terminal to the commonly
emulated <productname><acronym>DEC</acronym>
<acronym>VT100</acronym></productname>. If you occassionally
connect using a different terminal emulation then you can
interactively change your choice of terminal by setting
<varname>TERM</varname> to the appropiate terminal listed in
<filename>/etc/termcap</filename>.</para>
<figure id="getty-term">
<title>Interactively altering the connecting terminal's make and
model</title>
<screen>
<prompt>bash$</prompt> <command>TERM=kermit</command>
<prompt>bash$</prompt> <command>tset -r</command>
</screen>
</figure>
<para>A <application>getty</application> is also responsible for
setting the time zone when a permanently-connected remote terminal
is located beyond the machine's default time zone. The
<application>getty</application> overrides the default timezone by
setting the <envar>TZ</envar> environment variable. As with the
<envar>TERM</envar> environment variable, a user connecting from a
modem can interactively override the default time zone.</para>
<figure id="getty-tz">
<title>Interactively altering the connecting terminal's time zone</title>
<screen>
<prompt>bash$</prompt> <command>TZ=Australia/Adelaide</command>
<prompt>bash$</prompt> <command>export TZ</command>
</screen>
</figure>
<para>If you do not know your time zone name, run the
<command>tzselect</command> utility to generate the appropiate
contents for <envar>TZ</envar>.</para>
<para>But first, let's see how <application>getty</application> gets
started in the first place.</para>
<section id="getty-init">
<title><productname>init</productname> system</title>
<para>The file <filename>/etc/inittab</filename> contains the
background programs that used to keep the system running. One of
these programs is one <application>getty</application> process per
serial port.</para>
<figure id="getty-init-inittab">
<title><application>getty</application> is started by
<application>init</application>, based upon an entry in
<filename>/etc/inittab</filename></title>
<screen format="linespecific">
co:2345:respawn:/sbin/getty ttyS0 CON9600 vt102</screen>
</figure>
<para>Each field in <filename>inittab</filename> is separated by a
colon and contains:</para>
<variablelist>
<varlistentry>
<term><literal>co</literal></term>
<listitem>
<para>Arbitrary entry for <filename>inittab</filename>. As long
as this entry doesn't appear anywhere else in
<filename>inittab</filename>, you're okay. We named this entry
<literal>co</literal> because it's for the console.</para>
<para><productname>Red Hat Linux</productname>
<productnumber>7.3</productnumber> has a program called
<application>kudzu</application> which configures the system
when it is booted. <application>kudzu</application> treats an
<filename>inittab</filename> entry of <literal>co</literal>
specially, setting it for the attached monitor and keyboard or
the serial console. Hardcoding the value of
<filename>co</filename> prevents this behaviour.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>2345</literal></term>
<listitem>
<para>Run levels where this entry gets started. Run levels 2,
3, 4 and 5 can be used for an operational system,
<application>getty</application> should not be used in other run
levels. The serial console still works in run level 1 (or
single user mode) even without a
<application>getty</application>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>respawn</literal></term>
<listitem>
<para>Re-run the program if it dies. We want this to happen so
that a new <prompt>login</prompt> prompt will appear when you
log out of the console.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>/sbin/getty ttyS0 CON9600 vt102</literal></term>
<listitem>
<para>The command to run. In this case, we're telling
<application>getty</application> to connect to <filename
class="devicefile">/dev/ttyS0</filename> using the settings for
<literal>CON9600</literal> which exists in
<filename>/etc/gettydefs</filename>. This entry represents a
terminal running at 9600<abbrev>bps</abbrev>. Initially assume
that the terminal is a later-model
<productname><acronym>VT100</acronym></productname>.</para>
</listitem>
</varlistentry>
</variablelist>
<para>After changing <filename>/etc/inittab</filename> restart
<application>init</application> with</para>
<informalfigure>
<screen format="linespecific">
<command>telinit q</command></screen>
</informalfigure>
<para>An alternative is to send the hangup signal to
<application>init</application> with the command <command>kill -HUP
1</command>. This is not recommended: if you make a typing mistake
and actually kill <application>init</application> then your system
will suddenly halt.</para>
<note>
<title>Comments in <filename>inittab</filename> and Red Hat's
<application>kudzu</application></title>
<para><application>kudzu</application> uses the
<literal>#</literal> line comment to activate and deactivate the
<application>getty</application>s for the attached monitor and
keyboard and for the serial port. To prevent a genuine comment
from becoming confused with a line saved by
<application>kudzu</application> use <literal>##</literal> at the
start of a line of genuine comments.</para>
</note>
</section> <!-- getty-init -->
<section id="getty-getty">
<title>Traditional <productname>getty</productname></title>
<para>Traditional <application>getty</application> implementations
include <application>uugetty</application> and
<application>getty_ps</application>.</para>
<para>The traditional <application>getty</application> is listed in
<filename>/etc/inittab</filename> with the name of a section in
<filename>/etc/gettydefs</filename> to use for its configuration.
Our example in <xref linkend="getty-init-inittab"> used the section
<literal>CON9600</literal>.</para>
<para>There is no <literal>CON9600</literal> in the standard
<filename>gettydefs</filename>. This is deliberate, as serial
consoles sometimes require slight tweaking. Copy the
<literal>DT9600</literal> entry and use it as your model.</para>
<figure id="getty-getty-gettydefs">
<title>Define <literal>CON9600</literal> in
<filename>gettydefs</filename></title>
<programlisting>
# Serial console 9600, 8, N, 1, CTS/RTS flow control
CON9600# B9600 CS8 -PARENB -ISTRIP CRTSCTS HUPCL # B9600 SANE CS8 -PARENB -ISTRIP CRTSCTS HUPCL #@S @L login: #CON9600</programlisting>
</figure>
<para>Separate each line with a blank line.</para>
<para>Each configuration line has the syntax:</para>
<figure id="getty-getty-gettydefs-syntax">
<title>Syntax of entries in <filename>/etc/gettydefs</filename>,
in EBNF</title>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<replaceable>&lt;label&gt;</replaceable># <replaceable>&lt;initial_flags&gt;</replaceable> # <replaceable>&lt;final_flags&gt;</replaceable> #<replaceable>&lt;login_prompt&gt;</replaceable>#<replaceable>&lt;next_label&gt;</replaceable></literallayout>
</figure>
<para>The <replaceable>&lt;label&gt;</replaceable> is referred to
on the <application>getty</application> command line.</para>
<para>The <replaceable>&lt;next_label&gt;</replaceable> is the
definition used if a <acronym>RS-232</acronym> Break is sent. As
the console is always 9600<abbrev>bps</abbrev>, this points back
to the original <replaceable>label</replaceable>. See <xref
linkend="security-sysrq"> if you ever intend to have more one line
for <literal>CON9600</literal> in
<filename>gettydefs</filename>.</para>
<para><replaceable>&lt;initial_flags&gt;</replaceable> are the
serial line parameters used by <application>getty</application>.
These are modeled on the <citetitle>stty(1)</citetitle> and
<citetitle>termios(3)</citetitle> options and the full list varies
depending upon your <application>getty</application> variant. The
parameters in <xref linkend="getty-getty-gettydefs"> ensure that a
line at 9600<abbrev>bps</abbrev> with eight data bits and no
parity is configured.</para>
<para><replaceable>&lt;final_flags&gt;</replaceable> are the serial
line parameters set by <application>getty</application> before it
calls login. You will usually want to set a
9600<abbrev>bps</abbrev> line, <literal>SANE</literal> terminal
handling, eight data bits, no parity and to hang up the modem when
the login session is finished.</para>
<para>The <replaceable>&lt;login_prompt&gt;</replaceable> for
serial lines is traditionally the name of the machine, followed by
the serial port, followed by <literal>login:</literal> and a space.
The macro that inserts the name of the machine and the serial port
varies, see the documentation for your
<application>getty</application>.</para>
</section> <!-- getty-getty -->
<section id="getty-agetty">
<title><productname>agetty</productname></title>
<para><application>agetty</application> is an <quote>alternative
getty</quote>. It takes all of its parameters on the command line,
with no use of <filename>/etc/gettydefs</filename> or any other
configuration file. <application>agetty</application> is
documented in the manual page
<citetitle>agetty(8)</citetitle>.</para>
<para><xref linkend="getty-agetty-inittab"> shows how to invoke
<application>agetty</application> for use with a serial
console.</para>
<figure id="getty-agetty-inittab">
<title><filename>/etc/inittab</filename> entry for
<application>agetty</application></title>
<programlisting>
co:2345:respawn:/sbin/agetty -h -t 60 ttyS0 9600 vt102</programlisting>
</figure>
<para><literal>ttyS0</literal> refers to the serial device
<filename class="devicefile">/dev/ttyS0</filename>.</para>
<para><literal>9600</literal> is the bits per second of the serial
link. agetty will support multiple values, using the modem's
<literal>CONNECT</literal> message or the <acronym>RS-232</acronym>
Break signal to select between them. Only use one value, as serial
consoles only have only one data rate.</para>
<para><literal>vt102</literal> sets the <varname>TERM</varname>
environment variable to indicate that a
<productname><acronym>VT100</acronym></productname> terminal is
connecting.</para>
<para><literal>-h</literal> activates CTS/RTS handshaking.</para>
<para><literal>-t 60</literal> allows 60 seconds for someone to
attempt to log in before the modem is hung up. You should test
this feature to ensure that <application>init</application> is not
restarting <application>agetty</application> every 60 seconds when
the link is idle. Look for a continually changing process
identifier for <application>agetty</application>.</para>
<para><application>agetty</application> uses escape sequences in
<filename>/etc/issue</filename> to insert information. For
example, <literal>\n.\o \l</literal> will appear as
<literal>remote.example.edu.au ttyS0</literal>.</para>
<para>When you log out <application>agetty</application> does not
appear to lower the Data Terminal Ready signal to force the modme
to hang up. If having people automatically disconnected at the end
of their login session matters to you then you might consider
<application>mgetty</application> instead.</para>
</section> <!-- getty-agetty -->
<section id="getty-mgetty">
<title><productname>mgetty</productname></title>
<para><productname>mgetty</productname> is a modem-aware
<application>getty</application>. It supports modems with the
Hayes <acronym>AT</acronym> command set and is especially designed
for supporting modems that are used to send faxes and to dial out
as well as dial in. These features are not required for a serial
console.</para>
<para><application>mgetty</application> does not require the
traditional <filename>/etc/gettydefs</filename> file. As a result
<application>mgetty</application> is invoked from
<filename>/etc/inittab</filename> without supplying an entry in
<filename>/etc/gettydefs</filename>.</para>
<figure id="getty-mgetty-inittab">
<title><filename>/etc/inittab</filename> entry for
<application>mgetty</application></title>
<programlisting>
co:2345:respawn:/sbin/mgetty ttyS0</programlisting>
</figure>
<para><application>mgetty</application> is configured using the
file <filename>/etc/mgetty+sendfax/mgetty.config</filename>. It
should contain an entry for the port used by the serial
console.</para>
<figure>
<title><application>mgetty</application> configuration file
<filename>mgetty.config</filename></title>
<programlisting id="getty-mgetty-mgettyconfig">
port ttyS0
speed 9600
direct yes
data-only yes
toggle-dtr yes
need-dsr yes
port-owner root
port-group root
port-mode 600
login-prompt @ \P login:\040
login-time 60
term vt102</programlisting>
</figure>
<para>All the options are documented in the
<productname>PostScript</productname> file
<filename>/usr/share/doc/mgetty&hellip;/mgetty.ps</filename>.</para>
<para>We set <literal>direct</literal>,
<literal>data-only</literal>, <literal>need-dsr</literal> and
<literal>toggle-dtr</literal> so that the <acronym>RS-232</acronym>
control lines are used correctly for a dumb modem.</para>
<para><literal>port-owner</literal>, <literal>port-group</literal>
and <literal>port-mode</literal> set the serial device to be
accessible only by the <systemitem
class="username">root</systemitem> user. Modem applications, which
normally use the <systemitem class="groupname">uucp</systemitem>
group, cannot now accidentally use the serial console.</para>
<para><literal>login-prompt</literal> shows the machine
(<literal>@</literal>) and serial port (<literal>\P</literal>)
being used. The text <literal>\040</literal> is simply the octal
code for a space after <literal>login:</literal>.</para>
<para><literal>term vt102</literal> gives the make and model of the
terminal most likely to dial in. This sets the
<varname>TERM</varname> environment variable, which you can change
if you are dialling in from another terminal type.</para>
<para>The remaining configuration files,
<filename>/etc/mgetty+sendfax/dialin.config</filename> and
<filename>/etc/mgetty+sendfax/login.config</filename>, do not need
to be altered.</para>
<para>If you wish to alter the suggested configuration then note
that <application>mgetty</application>'s
<literal>blocking</literal> and <literal>toggle-dtr</literal>
parameters do not co-exist well.</para>
<para>If you have difficulties, activate debugging by adding
<literal>debug 8</literal> to <filename>mgetty.config</filename>.
<application>mgetty</application>'s actions are then visible in the
file <filename>/var/log/mgetty.log.ttyS0</filename>.</para>
</section> <!-- getty-mgetty -->
<section id="getty-mingetty">
<title><productname>mingetty</productname></title>
<para><productname>mingetty</productname> is designed to be a
minimal <application>getty</application> for the virtual terminals
on the workstation's monitor and keyboard. It has no support
for serial lines.</para>
<para>You must not use <application>mingetty</application> for the
serial line in <filename>/etc/inittab</filename>, but the current
<application>mingetty</application> entries for the virtual
terminals can remain.</para>
<para>Each virtual terminal uses about 8<acronym>KB</acronym> of
kernel memory. If this matters, it is easy to allocate fewer
virtual terminals. In the <systemitem
class="osname">Linux</systemitem> 2.4 kernel virtual terminals are
created on demand, so not starting
<productname>mingetty</productname> on the virtual terminal will
not create the virtual terminal. If the machine does not have a
video card then remove all the <application>mingetty</application>
entries from <filename>/etc/inittab</filename>.</para>
<figure id="getty-mingetty-inittab">
<title>Fewer virtual terminals. Removing
<application>mingetty</application> entries from
<filename>/etc/inittab</filename></title>
<programlisting>
1:2345:respawn:/sbin/mingetty tty1
# Additional virtual terminals are not used
2:2345:off:/sbin/mingetty tty2
3:2345:off:/sbin/mingetty tty3
4:2345:off:/sbin/mingetty tty4
5:2345:off:/sbin/mingetty tty5
6:2345:off:/sbin/mingetty tty6
</programlisting>
</figure>
<para>After restarting <application>init</application> it would be
wise to remove the unused device files.</para>
<figure id="getty-mingetty-devtty">
<title>Fewer virtual terminals. Deallocating unused virtual
terminals and removing their device files.</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>telinit q</command>
<prompt>bash#</prompt> <command>deallocvt /dev/tty[2-9] /dev/tty[0-9][0-9]</command>
<prompt>bash#</prompt> <command>rm /dev/tty[2-9] /dev/tty[0-9][0-9]</command>
</screen>
</figure>
</section> <!-- getty-mingetty -->
<section id="getty-none">
<title>No <productname>getty</productname></title>
<para>If you are using serial console simply to print console
messages then do not run a <application>getty</application> process
on the serial port.</para>
<para><application>getty</application> follows a locking convention
that prevents other serial port applications from using the serial
port. Since we do not want other processes to use the serial port,
but are not running <application>getty</application>, manually
create the lock file.</para>
<para>Create a file <filename>/var/lock/LCK..ttyS0</filename> to
contain the text <literal>1</literal>. This lets other potential
serial port applications know that process 1 has the serial port in
use. Process 1 is always the <application>init</application>
process, and <application>init</application> is always running, so
the serial port is always locked.</para>
<para>The file is created upon each system boot, as lock files are
often cleared when the system boots. A convenient place to create
the lock file is from <filename>/etc/rc.serial</filename>. It
should contain:</para>
<figure id="getty-none-rcserial">
<title>Contents of <filename>/etc/rc.serial</filename> to lock
console serial port when no <application>getty</application>
used</title>
<programlisting>
# Lock /dev/ttyS0 as it is used by an output-only console
(umask 022 &amp;&amp; \
rm -f '/var/lock/LCK..ttyS0' &amp;&amp; \
echo '1' > '/var/lock/LCK..ttyS0')</programlisting>
</figure>
</section> <!-- getty-none -->
</chapter> <!-- getty -->
<chapter id="misc">
<title>Configure incidentals</title>
<para>A surprising number of other configuration files need small
modifications before the serial console works well.</para>
<para>The configuration of many items depends upon your security
requirements, especially depending upon the level of trust and
corresponding need for security at the remote site. By assuming a
high need for security at the remote site this
<citetitle>HOWTO</citetitle> can illustrate a large number of
configuration items.</para>
<section id="misc-securetty">
<title>Allow <systemitem class="username">root</systemitem> to
login from serial console</title>
<para>The file <filename>/etc/securetty</filename> controls the
devices that the <systemitem class="username">root</systemitem>
user can log in upon.</para>
<para>It is usually desirable to have <systemitem
class="username">root</systemitem> be able to log in from the
console, so add the basename of the serial console device to
<filename>/etc/securetty</filename>.</para>
<figure id="misc-secretty-ttys0">
<title>Alter <filename>securetty</filename> to allow <systemitem
class="username">root</systemitem> to log in from the serial
console</title>
<programlisting>
ttyS0</programlisting>
</figure>
<para>Almost anyone can now dial into the modem and attempt to
guess the <systemitem class="username">root</systemitem> password.
Normally we do not allow <systemitem
class="username">root</systemitem> to log in from a remote site,
rather we have a normal user log in and then use
<command>su</command> or <ulink
url="http://www.courtesan.com/sudo/"><command>sudo</command></ulink>
to become <systemitem class="username">root</systemitem>. This
gives some traceability.</para>
<para>Unfortunately, the <systemitem
class="username">root</systemitem> user needs to be able to log in
from the console to fix a full disk. Disk subsystems typically
reserve 5% of their space for root's exclusive use.<footnote>
<para>This is not as inefficient as it may appear. The last 5%
of a disk formatted with a general purpose filesystem always
performs poorly and is best left empty.</para></footnote>
This is enough space for the <systemitem
class="username">root</systemitem> user to log in and start
deleting the files that filled the disk.</para>
<note>
<title><filename>securetty</filename> and Red Hat's
<application>kudzu</application></title>
<para><application>kudzu</application> automatically adds the
device being used as the console to
<filename>securetty</filename>.</para>
</note>
</section> <!-- misc-securetty -->
<section id="misc-init">
<title>Change <application>init</application> level to textual</title>
<para>There is little point in running the <productname>X Window
System</productname> on a server with no screen. Edit
<filename>/etc/inittab</filename> finding the line containing
<literal>initdefault</literal>, such as</para>
<informalfigure id="misc-init-x">
<programlisting>
id:5:initdefault:</programlisting>
</informalfigure>
<para>Alter the default from run level 5 (multiuser with X Window
System) to run level 3 (multiuser).</para>
<informalfigure id="misc-init-text">
<programlisting>
id:3:initdefault:</programlisting>
</informalfigure>
<para>The <command>startx</command> command can be used if an
occassional <productname>X Windows</productname> session is
required upon an attached keyboard and monitor.</para>
<note>
<title>Run levels and Red Hat's
<application>kudzu</application></title>
<para><application>kudzu</application> automatically updates the
<literal>initdefault</literal> entry in
<filename>inittab</filename> to use run level 3 if a serial device
is being used as a console.</para>
</note>
<section id="misc-init-x11">
<title>Continuing to run X</title>
<para>Sometimes a computer with a serial console and no attached
monitor still needs to run the <application>X Window
System</application>. For example, the computer might host a
number of <application>X</application> terminals.</para>
<para>In this case the computer should remain in run level 5, but
should not run a <application>X</application> server for any
attached monitors. Alter
<filename>/etc/X11/xdm/Xservers</filename> and remove any lines
starting with a colon (which indicates an
<application>X</application> server on the local machine). <xref
linkend="misc-init-x11-xservers"> shows an unaltered
<filename>Xservers</filename> file.</para>
<figure id="misc-init-x11-xservers">
<title><filename>Xservers</filename> from Red Hat Linux
7.2</title>
<programlisting>
:0 local /usr/X11R6/bin/X
</programlisting>
</figure>
<para>If the operating system uses <acronym>GNOME</acronym>'s
<application>gdm</application> then alter its configuration file
<filename>/etc/X11/gdm/gdm.conf</filename>, removing any entries
for local <application>X</application> servers from the
<literal>[servers]</literal> section. <xref
linkend="misc-init-x11-gdmconf">shows an unaltered
<literal>[servers]</literal> section.</para>
<figure id="misc-init-x11-gdmconf">
<title><literal>[servers]</literal> section of
<filename>gdm.conf</filename> from Red Hat Linux 7.2</title>
<programlisting>
[servers]
0=/usr/bin/X11/X
</programlisting>
</figure>
</section> <!-- misc-init-x11 -->
</section> <!-- misc-init -->
<section id="misc-remove-ioctl-save">
<title>Remove saved console settings</title>
<para>The file <filename>/etc/ioctl.save</filename> contains the
serial and terminal parameters to use in single user mode. The
serial and terminal parameters are usually set by
<application>getty</application> &mdash; during single user mode no
<application>getty</application> runs and the contents of
<filename>/etc/ioctl.save</filename> are used to set the serial and
terminal parameters.</para>
<para>As we are changing consoles, the saved settings are no longer
correct.</para>
<figure id="remove-ioctl-save-rm">
<title>Removal of <filename>ioctl.save</filename> containing the
saved console parameters</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>rm -f /etc/ioctl.save</command></screen>
</figure>
<para>We re-create this file once we can log in from the serial
console.</para>
</section> <!-- misc-remove-ioctl-save -->
<section id="misc-devmodem">
<title>Serial console is not <filename
class="symlink">/dev/modem</filename></title>
<para>In many Linux distributions the file <filename
class="symlink">/dev/modem</filename> is a symbolic link to the
serial port containing a modem which is available for use.</para>
<para>Although the serial console is a serial port with a modem, we
certainly don't want it used to place an outgoing call.</para>
<para>Check that <filename class="symlink">/dev/modem</filename>
does not point to the serial port being used for the console, say
<filename class="devicefile">/dev/ttyS0</filename>. If it does,
then remove the symbolic link.</para>
<figure id="misc-devmodem-example">
<title>Remove <filename class="symlink">/dev/modem</filename> if
it points to the serial console's port</title>
<screen format="linespecific">
<prompt>bash$</prompt> <command>ls -l /dev/modem</command>
<computeroutput>lrwxrwxrwx 1 root root 10 Jan 01 00:00 /dev/modem -> /dev/ttyS0</computeroutput>
<prompt>bash#</prompt> <command>rm /dev/modem</command></screen>
</figure>
</section> <!-- misc-devmodem -->
<section id="misc-devsystty">
<title>Alter target of <filename
class="symlink">/dev/systty</filename></title>
<para>In many Linux distributions the file <filename
class="symlink">/dev/systty</filename> is a symbolic link to the
device which is used as the by the attached monitor and keyboard.
See <xref linkend="intro-word"> for a fuller description.</para>
<para>If there is no attached keyboard and monitor or no wish to
give the attached keyboard and monitor greater capabilities then a
text terminal, then alter <filename
class="symlink">/dev/systty</filename> to point to the serial
console.</para>
<para>Rather than directly altering this symbolic link, it is
better to modify the configuration file used by
<command>MAKEDEV</command>, which is then run to recreate the
symbolic link. The configuration file is in the directory
<filename class="directory">/etc/makedev.d</filename>. The default
configuration will point to the first virtual terminal, as shown in
<xref linkend="misc-devsystty-default">.</para>
<figure id="misc-devsystty-default">
<title>Default value of <filename
class="symlink">/dev/systty</filename> in
<filename>/etc/makedev.d/linux-2.4.x</filename></title>
<programlisting>
l systty tty0</programlisting>
</figure>
<para>Modify this to point to the serial port being used by the
console, as shown in <xref linkend="misc-devsystty-serial">.</para>
<figure id="misc-devsystty-serial">
<title>Alter value of <filename
class="symlink">/dev/systty</filename> in
<command>MAKEDEV</command> configuration file</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>cd /etc/makedev.d</command>
<prompt>bash#</prompt> <command>fgrep systty *</command>
<computeroutput>linux-2.4.x:l systty tty0</computeroutput>
<prompt>bash#</prompt> <command>vi linux-2.4.x</command>
</screen>
<programlisting format="linespecific">
l systty ttyS0
</programlisting>
</figure>
<para>Now re-create <filename
class="symlink">/dev/systty</filename> using its new definition, as
shown in <xref linkend="misc-devsystty-create">.</para>
<figure id="misc-devsystty-create">
<title>Installing new value of <filename
class="symlink">/dev/systty</filename></title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>cd /dev</command>
<prompt>bash#</prompt> <command>rm systty</command>
<prompt>bash#</prompt> <command>./MAKEDEV systty</command></screen>
</figure>
</section> <!-- misc-devsystty -->
<section id="misc-pam">
<title>Configure Pluggable Authentication Modules</title>
<para>The <application>Pluggable Authentication
Module</application> system can be used to give special privileges
to users that logged in through the console. It is used to make
devices like the floppy disk mountable by the console's user;
usually they would need to become the super-user to mount a
disk.</para>
<para>The <acronym>PAM</acronym> configuration file
<filename>/etc/security/console.perms</filename> contains the
<literal>&lt;console&gt;</literal> variable. For <productname>Red
Hat Linux</productname> <productnumber>7.1</productnumber>
<literal>&lt;console&gt;</literal> is the regular
expression:</para>
<figure id="misc-pam-default-console">
<title>Default <literal>&lt;console&gt;</literal> in
<filename>console.perms</filename> refers to attached keyboard and
screen</title>
<programlisting>
&lt;console&gt;=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]</programlisting>
</figure>
<para>Later in the file the <literal>&lt;console&gt;</literal> user
is granted permission to use some devices. This is done by
altering the devices' permissions upon login and logout.</para>
<figure id="misc-pam-default-dev">
<title>Default device listing in
<filename>console.perms</filename></title>
<programlisting>
&lt;console&gt; 0660 &lt;floppy&gt; 0660 root.floppy
&lt;console&gt; 0600 &lt;sound&gt; 0600 root
&lt;console&gt; 0600 &lt;cdrom&gt; 0660 root.disk
&lt;console&gt; 0600 &lt;pilot&gt; 0660 root.uucp
&lt;console&gt; 0600 &lt;jaz&gt; 0660 root.disk
&lt;console&gt; 0600 &lt;zip&gt; 0660 root.disk
&lt;console&gt; 0600 &lt;ls120&gt; 0660 root.disk
&lt;console&gt; 0600 &lt;scanner&gt; 0600 root
&lt;console&gt; 0600 &lt;camera&gt; 0600 root
&lt;console&gt; 0600 &lt;memstick&gt; 0600 root
&lt;console&gt; 0600 &lt;flash&gt; 0600 root
&lt;console&gt; 0600 &lt;fb&gt; 0600 root
&lt;console&gt; 0600 &lt;kbd&gt; 0600 root
&lt;console&gt; 0600 &lt;joystick&gt; 0600 root
&lt;console&gt; 0600 &lt;v4l&gt; 0600 root
&lt;console&gt; 0700 &lt;gpm&gt; 0700 root
&lt;console&gt; 0600 &lt;mainboard&gt; 0600 root
&lt;console&gt; 0600 &lt;rio500&gt; 0600 root</programlisting>
</figure>
<para>There are two types of devices listed above: those devices
required by someone connecting from an attached keyboard and
monitor and those devices that allow convenient access to devices.
The configuration file fails to make the distionction between
logical and physical console noted in <xref linkend="intro-word">.
The configuration file is modified to create that
distinction.</para>
<figure id="misc-pam-serial-dev">
<title>Devices in <filename>console.perms</filename> required for
attached keyboard and screen</title>
<programlisting>
&lt;console&gt; 0600 &lt;fb&gt; 0600 root
&lt;console&gt; 0600 &lt;kbd&gt; 0600 root
&lt;console&gt; 0600 &lt;joystick&gt; 0600 root
&lt;console&gt; 0600 &lt;v4l&gt; 0600 root
&lt;console&gt; 0700 &lt;gpm&gt; 0700 root</programlisting>
</figure>
<para>The remaining devices should be altered to give control only
to people attaching from the serial console. For example, we don't
want an unprivileged user at a co-location site mounting a floppy
disk. Define a new console type for the serial console, say
<literal>&lt;sconsole&gt;</literal>.</para>
<figure id="misc-pam-serial-sconsole">
<title>Add <literal>&lt;sconsole&gt;</literal> in
<filename>console.perms</filename> to refer to serial
console</title>
<programlisting>
&lt;sconsole&gt;=ttyS0</programlisting>
</figure>
<para>Now modify the remaining entries from
<literal>&lt;console&gt;</literal> to
<literal>&lt;sconsole&gt;</literal>.</para>
<figure id="misc-pam-serial-sdev">
<title>Remaining devices in <filename>console.perms</filename>
altered to refer to serial console</title>
<programlisting>
&lt;sconsole&gt; 0660 &lt;floppy&gt; 0660 root.floppy
&lt;sconsole&gt; 0600 &lt;sound&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;cdrom&gt; 0660 root.disk
&lt;sconsole&gt; 0600 &lt;pilot&gt; 0660 root.uucp
&lt;sconsole&gt; 0600 &lt;jaz&gt; 0660 root.disk
&lt;sconsole&gt; 0600 &lt;zip&gt; 0660 root.disk
&lt;sconsole&gt; 0600 &lt;ls120&gt; 0660 root.disk
&lt;sconsole&gt; 0600 &lt;scanner&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;camera&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;memstick&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;flash&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;mainboard&gt; 0600 root
&lt;sconsole&gt; 0600 &lt;rio500&gt; 0600 root</programlisting>
</figure>
</section> <!-- misc-pam -->
<section id="misc-configure-rhl">
<title>Configure <productname>Red Hat Linux</productname></title>
<para><productname>Red Hat Linux</productname> stores parameters concerning system start up in
the file <filename>/etc/sysconfig/init</filename>.</para>
<para>Alter the parameter <literal>BOOTUP</literal> to use
terminal-independent commands to write the
<computeroutput>OK</computeroutput>,
<computeroutput>PASSED</computeroutput> and
<computeroutput>FAILED</computeroutput> messages. These messages
will no longer appear in green, yellow or red. The comments in
<filename>/etc/sysconfig/init</filename> suggest that any value
other than <literal>color</literal> will do, but it seems that
<literal>BOOTUP</literal> must be set to
<literal>serial</literal>.</para>
<para>Alter the <literal>PROMPT</literal> parameter to disallow
interactive start up. Allowing an unauthenticated keystroke to stop
system services is not robust against line noise and allows anyone
that dials in during system boot to deny services.</para>
<figure id="misc-configure-rhl-etc-syslinux-init">
<title>Alterations to <filename>/etc/sysconfig/init</filename> for
<productname>Red Hat Linux</productname></title>
<programlisting>
BOOTUP=serial
PROMPT=no</programlisting>
</figure>
<para><productname>Red Hat Linux</productname> runs a hardware
discoverer, named <application>kudzu</application>. When
attempting to identify a serial port
<application>Kudzu</application> resets the serial port. This
stops the serial console. <application>Kudzu</application> is
configured from the file
<filename>/etc/sysconfig/kudzu</filename>.</para>
<para><application>Kudzu</application> can be prevented from
resetting hardware by setting the configuration parameter
<literal>SAFE</literal> to <literal>yes</literal>.</para>
<figure id="misc-configure-rhl-etc-syslinux-kudzu">
<title>Alterations to <filename>/etc/sysconfig/kudzu</filename>
for <productname>Red Hat Linux</productname></title>
<programlisting>
SAFE=yes</programlisting>
</figure>
</section> <!-- misc-configure-rhl -->
</chapter> <!-- misc -->
<chapter id="test">
<title>Reboot and test</title>
<section id="test-verify">
<title>Verify console operation</title>
<para>If possible, plug an <acronym>RS-232</acronym> breakout box
into the serial port. During reboot the Data Terminal Ready line
should become active and then the Transmit Data lights should flash
as console messages appear.</para>
<para>Attach a modem, or a null modem cable and a terminal.
Configure them to match the serial parameters used by the serial
console port. If using a modem, dial in to it from a terminal
emulator.</para>
<informalfigure id="test-verify-operation-connect">
<screen format="linespecific">
<command>+++</command>
<command>AT Z</command>
<command>AT DT 1234-5678</command>
<computeroutput>CONNECT 9600</computeroutput></screen>
</informalfigure>
<para>Configure the terminal or terminal emulator to match the
serial parameters used by the serial console. If using a modern
Hayes <acronym>AT</acronym>-style modem then the speed need not
match. If using a directly-attached terminal then the speed must
match.</para>
<para>Reboot the computer.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>shutdown -r now</command></screen>
</informalfigure>
<para>During reboot the terminal should see the usual boot loader
text, and then the default kernel booting, then the
<application>init</application> output, and finally the contents of
<filename>/etc/issue</filename> and
<application>getty</application> asking you to login.</para>
<informalfigure>
<screen format="linespecific">
LILO:
Linux version &hellip;
Kernel command line: auto BOOT_IMAGE=linux ro root=306 BOOT_FILE=/boot/vmlinuz-2.4.3-12 console=tty0 console=ttyS0,9600n8
&hellip;
INIT version &hellip;
&hellip;
/etc/issue says "All your base are belong to us".
remote.example.edu.au ttyS0 login:</screen>
</informalfigure>
<para>If you do not see the <prompt>login:</prompt> message then
press <keycap>Return</keycap> or <keycap>Enter</keycap>.</para>
</section> <!-- test-verify -->
<section id="recreate-ioctl-save">
<title>Re-create saved console settings</title>
<para>Log in as <systemitem class="username">root</systemitem> from
the serial console and send the console into single user mode. The
modem may hang up whilst doing this and you may need to
re-connect.</para>
<para>Without a <filename>/etc/ioctl.save</filename> containing the
saved terminal settings, <application>init</application> assumes a
directly attached terminal running at 9600bps with 8 data bits, no
parity, 1 stop bit and no flow control. Configure your terminal
with these settings.</para>
<informalfigure id="recreate-ioctl-save-login">
<screen format="linespecific">
<prompt>remote.example.edu.au ttyS0 login:</prompt> <userinput>root</userinput>
<prompt>Password:</prompt> <userinput>&hellip;</userinput>
<prompt>sh#</prompt> <command>rm -f /etc/ioctl.save</command>
<prompt>bash#</prompt> <command>telinit 1</command>
&hellip;<computeroutput>
Telling INIT to go to single user mode.
INIT: Going single user
INIT: Sending processes the TERM signal</computeroutput>
<prompt>sh#</prompt> <command>stty sane -parenb cs8 crtscts brkint -istrip -ixoff -ixon</command></screen>
</informalfigure>
<para>As you use <command>stty</command> to alter the Linux's
terminal settings remember to also alter the settings of the
attached terminal.</para>
<para>Exiting from single user mode back to the default run level
will save the serial console termnial configuration into
<filename>/etc/ioctl.save</filename>.</para>
<informalfigure id="recreate-ioctl-save-login-text">
<screen format="linespecific">
<prompt>sh#</prompt> <command>exit</command>
&hellip;
<prompt>bash#</prompt> <command>ls -l /etc/ioctl.save</command>
<computeroutput>-rw------- 1 root root 60 Jan 1 00:00 /etc/ioctl.save</computeroutput></screen>
</informalfigure>
<para>The terminal settings saved in
<filename>/etc/ioctl.save</filename> will be used if the machine
boots into single user mode for any reason.</para>
<para>If your attached terminal or modem cannot alter speed to
9600bps then the above procedure cannot be followed. <ulink
url="http://www.aarnet.edu.au/network/software/ioctlsave/"><command>ioctlsave</command></ulink>
has been written for this special case. It saves the current
terminal settings to a file in the same format as
<filename>ioctl.save</filename>. The procedure is shown in <xref
linkend="recreate-ioctl-save-ioctlsave">.</para>
<figure id="recreate-ioctl-save-ioctlsave">
<title>Using <command>ioctlsave</command> to create
<filename>/etc/ioctl.save</filename> without entering single user
mode</title>
<screen format="linespecific">
<prompt>remote.example.edu.au ttyS0 login:</prompt> <userinput>root</userinput>
<prompt>Password:</prompt> <userinput>&hellip;</userinput>
<prompt>bash#</prompt> <command>rm -f /etc/ioctl.save</command>
<prompt>bash#</prompt> <command>ioctlsave -t /dev/ttyS0 /etc/ioctl.save</command>
</screen>
</figure>
</section> <!-- recreate-ioctl-save -->
<section id="test-console">
<title>Test the console</title>
<para>Dial in from a machine, perhaps using
<application>Minicom</application>.</para>
<example id="test-console-session">
<title>Dialing into a serial console</title>
<screen format="linespecific">
<prompt>localhost bash$</prompt> <command>minicom</command></screen>
<screen format="linespecific">
<computeroutput>Initializing modem
Welcome to minicom 1.83.1
Press ALT-Z for help on special keys
AT S7=45 S0=0 L1 V1 X4 &amp;C1 E1 Q0
OK</computeroutput>
<keycombo><keycap>Alt</keycap><keycap>D</keycap></keycombo> <guimenuitem>remote.example.edu.au-ttyS0</guimenuitem>
<guilabel>Dialing: remote.example.edu.au-ttyS0 At: 1234-5678</guilabel>
<guilabel>Connected. Press any key to continue</guilabel>
<keycap>Any</keycap>
<computeroutput>CONNECT 115200/V34/LAPM/V42BIS/33600:TX/33600:RX</computeroutput></screen>
<screen format="linespecific">
<keycap>Enter</keycap>
<computeroutput>/etc/issue says "All your base are belong to us".</computeroutput>
<prompt>remote.example.edu.au ttyS0 login:</prompt> <userinput>user</userinput>
<prompt>Password:</prompt> <userinput>********</userinput>
<computeroutput>Message of the day is "be careful out there".</computeroutput>
<prompt>remote bash$</prompt> <command>stty -a</command>
<computeroutput>
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = &lt;undef&gt;;
eol2 = &lt;undef&gt;; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke</computeroutput>
&hellip;
<prompt>remote bash$</prompt> <command>logout</command></screen>
<screen format="linespecific">
<computeroutput>NO CARRIER</computeroutput>
<keycombo><keycap>Alt</keycap><keycap>X</keycap></keycombo>
<guimenu>Leave Minicom?</guimenu> <guimenuitem>Yes</guimenuitem>
<guilabel>Resetting modem</guilabel></screen>
<screen format="linespecific">
<prompt>localhost bash$</prompt></screen>
</example>
<para>Interestingly the <command>stty -a</command> command, used to
display the terminal settings, reports that the link from the modem
to the serial console is 9600<abbrev>bps</abbrev>. The
<literal>CONNECT</literal> message reports that link between the
two modems operates at 33600<abbrev>bps</abbrev>. The constant
speed modem-computer link is a very useful feature of the Hayes
<acronym>AT</acronym>-style modems: the calling computer need not
know in advance the line speed of the called serial console.</para>
</section> <!-- test-console -->
<section id="end">
<title>Where to next from here?</title>
<para>The serial console is now configured. Check the security
pointers given in <xref linkend="security"> to complete the
job.</para>
</section> <!-- end -->
</chapter> <!-- test -->
<chapter id="security">
<title>Security</title>
<para>Using a serial console with a modem gives anyone the
opportunity to connect to the console port. This connection is not
mediated by firewalls or intrusion detection sniffers. It is
important to prevent the misuse of the serial console by
unauthorized people.</para>
<para>The resurgence of the <acronym>BBS</acronym>-era technique of
<quote>war dialling</quote> is described in @Stake's <ulink
url="http://www.atstake.com/research/reports/acrobat/wardialling_brief.pdf"><citetitle>Wardialling
Brief</citetitle></ulink> and reported upon by <citetitle>The
Register</citetitle>, see an extract in <xref
linkend="security-leyden">.</para>
<figure id="security-leyden">
<title>Extract from <citetitle>Crackers favour war dialling and
weak passwords</citetitle></title>
<blockquote>
<para>With all the talk about zero day exploits and sometimes
esoteric vulnerabilities its easy to lose sight of the role of
older, less sophisticated techniques as a mainstay of cracker
activity.</para>
<para>During a hacking debate at InfoSecurity Europe yesterday
[2002-04-25], black hat hacker KP said that when he broke into a
network he did so 90 per cent of the time through an unprotected
modem, often through war dialling.</para>
<para>War dialling involves systematically trying to locate the
numbers associated with corporate modems through testing each
extension of a corporate phone system in turn.</para>
<para><quote>Intrusion detection systems are no real deterrent for
me because I get in through the back door,</quote> he
said. <quote>Many networks are constructed like Baked Alaska
&mdash; crunchy on the outside and soft in the
middle.</quote></para>
<para>KP often takes advantage of weak or default passwords to
break into networks&hellip;</para>
<!-- This part excised
..., and only uses social engineering attacks on telco
companies.</para>
<para>Coldfire, another cracker speaking at the debate, said he
too only used social engineering (persuading people to give
confidential information over the phone), against telco
suppliers.</para>
<para><quote>Hackers don't like talking to people - remember we're
socially inadequate,</quote> he joked.</para>
<para>In response to customer demand, security testing specialists
NTA Monitor this week launched a service to test against war
dialling vulnerability.</para>
<para><quote>This isn't particularly sexy,</quote> said NTA
Monitor's technical director Roy Hills. <quote>But we're seeing
high demand for this low-tech service.</quote></para>
<para>The issue of war dialling and insecure modem connections was
highlighted last month when BT inadvertently published the private
remote access numbers of thousands of its customers on its Web
site. The list was supposed to include the dial up numbers of
ISPs, but modem numbers of private companies and people were
published as well by mistake.</para>
<para>BT swiftly pulled the information from the BT Together site
but now before the monster telco earned brickbats from security
consultants.</para>
-->
</blockquote>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">
<citetitle>Crackers favour war dialling and weak passwords</citetitle>
John Leyden, <ulink url="http://www.theregister.co.uk/content/55/25044.html"><citetitle>The Register</citetitle></ulink>, 2002-04-26.</literallayout>
</figure>
<section id="security-password">
<title>Use good passwords</title>
<para>Anyone that can guess the <acronym>BIOS</acronym> password,
the boot loader password, or the <systemitem
class="username">root</systemitem> password can get full control of
the machine. These should be different, unrelated, excellent
passwords. Random text and digits are by far the best choice. You
should never use a password that you think would return a hit from
a search engine.<footnote>
<para>But don't submit your proposed password to a search engine!
Sending passwords in plain text across the Internet isn't good,
nor the possibility of having them appear in the logs of a search
engine.</para></footnote></para>
<para>Guessing a user's password is only slightly less severe, as a
hacker can obtain <systemitem class="username">root</systemitem>
access simply by waiting. The hacker waits for a <quote>local
exploit</quote> for a flaw in the operating system to appear and
uses that exploit before the machine is patched.</para>
<para>Severely limit the number of users on the machine. Ensure
that only good passwords are chosen by using a fascist password
checker such as a <ulink
url="http://www.users.dircon.co.uk/~crypto/"><application>cracklib</application></ulink>-based
<ulink
url="http://www.kernel.org/pub/linux/libs/Linux-PAM-html/pam.html"><application>PAM</application></ulink>
module.</para>
<para>You should write down the <acronym>BIOS</acronym> password,
the boot loader password and the <systemitem
class="username">root</systemitem> password. Now you don't need to
remember them, so there is no reason for them not to be totally
random, unrelated, excellent passwords. Fold the page, put it in
an envelope and seal it.</para>
<para>Now we have turned a computer security problem into a
physical security problem. We know how to solve those problems:
locks, keys, alarms, safes, guards, regular inspections. If your
site has staffed security then a good option is to leave the
envelope in the care of the guard post with instructions to treat
the envelope with the same procedures used for the site's master
keys. Smaller sites can use a safe, a cash box or a locked drawer.
A thief forcing a locked drawer still leaves shows more apparent
signs of entry and more clues to their identity than is left by a
hacker behind a modem.</para>
<para>These three passwords are an important corporate asset. If
the machine is secure then forgetting the major passwords for the
machine should result in a machine whose configuration cannot be
altered by actions short of disassembly. You should have written
procedures controlling the generation, storage, lifetime and use of
major passwords.</para>
</section> <!-- security-password -->
<section id="security-dtr">
<title>Obey Data Terminal Ready and Data Carrier Detect</title>
<para>The <acronym>RS-232</acronym> Data Terminal Ready signal is
lowered when the computer wishes the modem to hang up. The
computer wishes to hang up when people have ended their login
session ends or when they fail to respond to the
<prompt>login:</prompt> prompt.</para>
<para>Using a modem cable that has <acronym>DTR</acronym> wired and a
modem that is configured to obey <acronym>DTR</acronym> is essential
to prevent denial of service attacks upon the access to the
console.</para>
<para>Without <acronym>DTR</acronym> a caller can simply hold the
modem line open, denying system administrators access to the
console.</para>
<para>The <acronym>RS-232</acronym> Data Carrier Detect signal is
lowered when the user hangs up.</para>
<para>Using a modem cable that has <acronym>DCD</acronym> wired and
a modem that is configured to assert <acronym>DCD</acronym> is
essential to prevent people dialling in after a user has hang up
and from carrying on their session.</para>
<para>Without <acronym>DCD</acronym> the session is not cleared when
an accidental disconnection occurs. This allows any subsequent
caller to resume the previous session. The machine is totally
compromised if the previous user was <systemitem
class="username">root</systemitem>.</para>
</section> <!-- security-dtr -->
<section id="security-dumb">
<title>Use or configure a dumb modem</title>
<para>Most modems use the Hayes <acronym>AT</acronym> command set.
The modem's attention is gained by sending <literal>+++</literal>
surrounded by some idle time. Commands are then sent prefixed by
<literal>AT</literal>.</para>
<para>Unfortunately, if the modem sees <literal>+++</literal>
during a call it may revert to command mode. The modem can then be
configured by the caller. For example, the modem could be set to
permit incoming calls only from the number <quote>0</quote>, this
would deny the system administrators access to the modem.</para>
<para>The attention command can be removed using <command>AT
S2=255</command>. Of course once that is done no more
<acronym>AT</acronym> commands can be given to the modem, so any
other configuration of the modem needs to be done prior to that
command.</para>
<para>Unfortunately, when power to the modem is applied the modem
starts in command mode. So a carefully chosen console message
could disable the modem.</para>
<para>The best solution is to select a modem that has a
<quote>dumb</quote> or <quote>select profile</quote>
<acronym>DIP</acronym> switch or jumper. These switches disable
command mode and load the modem's saved configuration when they
start.</para>
</section> <!-- security-dumb -->
<section id="security-messages">
<title>Restrict console messages</title>
<section id="security-messages-log">
<title>Restrict console messages from the system log</title>
<para>Generating a stready stream of console messages can easily
overwhelm a 9600<abbrev>bps</abbrev> link.</para>
<para>Although displaying all <application>syslog</application>
messages on the console appears to be a good idea, this actually
provides the unprivileged user a simple method to deny effective
use of the remote console.</para>
<para>Configure system log messages to the console to the bare
minimum. Look in <filename>/etc/syslog.conf</filename> for lines
ending with <filename
class="devicefile">/dev/console</filename>.</para>
<para>Consider sending all log messages to another machine for
recording and analysis. <xref
linkend="security-messages-syslogconf"> shows the standard
<filename>/etc/syslog.conf</filename> from <productname>Red Hat
Linux</productname> <productnumber>7.2</productnumber> modified to
record log messages to a log server. Each line of
<filename>syslog.conf</filename> has been repeated to send a copy
of the message to the log server. The log server has the
<acronym>DNS</acronym> alias <systemitem
class="systemname">loghost.example.edu.au</systemitem>; using a
<acronym>DNS</acronym> alias allows the log server to be moved
without updating the configuration of all the remote machines.
The local copy of the log message is no longer the only means of
determining the cause of a system failure, so we can gain some
performance advantage by disabling synchronous file writes,
although this increases the odds of an inconsistent filesystem (an
issue with filesystems that do not do journalling). Placing a
<literal>-</literal> before the filename disables synchronous file
writes.</para>
<figure id="security-messages-syslogconf">
<title><filename>/etc/syslog.conf</filename> modified to copy log
messages to a log server</title>
<programlisting>
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none @loghost.example.edu.au
*.info;mail.none;authpriv.none;cron.none -/var/log/messages
# The authpriv file has restricted access.
authpriv.* @loghost.example.edu.au
authpriv.* /var/log/secure
# Log all the mail messages in one place.
mail.* @loghost.example.edu.au
mail.* -/var/log/maillog
# Log cron stuff
cron.* @loghost.example.edu.au
cron.* -/var/log/cron
# Everybody gets emergency messages
*.emerg @loghost.example.edu.au
*.emerg *
# Save news errors of level crit and higher in a special file.
uucp,news.crit @loghost.example.edu.au
uucp,news.crit -/var/log/spooler
# Save boot messages also to boot.log
local7.* @loghost.example.edu.au
local7.* -/var/log/boot.log
</programlisting>
</figure>
<para>A log server is configured using the standard
<filename>/etc/syslog.conf</filename> configured to allow the
reception of remote <application>syslog</application> messages.
This configuration for <productname>Red Hat Linux</productname> is
shown in <xref linkend="security-messages-sysconfig">. In
addition to configuring the system log daemon, also prevent denial
of service attacks by configuring <application>IP
Tables</application> to restrict the sources of the syslog
messages; and also improve performance by checking that
<application>nscd</application> is running to cache reverse
<acronym>DNS</acronym> lookups.</para>
<figure id="security-messages-sysconfig">
<title>Allowing remote log messages by setting options in
<filename>/etc/sysconfig/syslog</filename></title>
<programlisting>
# Red Hat Linux default value, does not write timer mark messages
SYSLOGD_OPTIONS="-m 0"
# Add option to accept remote syslog messages
SYSLOGD_OPTIONS="${SYSLOGD_OPTIONS} -r"
</programlisting>
</figure>
<figure id="security-messages-iptables">
<title>Restrict <application>syslog</application> messages to
<systemitem
class="systemname">remote.example.edu.au</systemitem></title>
<screen>
<prompt> bash#</prompt> <userinput>chkconfig iptables on</userinput>
<prompt> bash#</prompt> <userinput>/etc/init.d/iptables restart</userinput>
# Allow all IP traffic from this machine
<prompt> bash#</prompt> <userinput>iptables --append INPUT --source 127.0.0.0/8 --in-interface lo --jump ACCEPT</userinput>
# Perhaps filter other traffic
&hellip;
# Accept syslog messages from remote.example.edu.au
<prompt> bash#</prompt> <userinput>iptables --append INPUT --source remote.example.edu.au --protocol udp --destination-port syslog -j ACCEPT</userinput>
# Silently drop unexpected syslog messages
<prompt> bash#</prompt> <userinput>iptables --append INPUT --protocol udp --destination-port syslog -j DROP</userinput>
# Save the running configuration
<prompt> bash#</prompt> <userinput>/etc/init.d/iptables save</userinput>
</screen>
</figure>
<figure id="security-messages-nscd">
<title>Using <application>nscd</application> to cache reverse
<acronym>DNS</acronym> lookups</title>
<screen>
<prompt>bash#</prompt> <userinput>chkconfig nscd on</userinput>
<prompt>bash#</prompt> <userinput>/etc/init.d/nscd restart</userinput>
</screen>
</figure>
</section> <!-- security-messages-log -->
<section id="security-mesasges-wall">
<title>Restrict broadcast messages to the console</title>
<para>Users that are logged into the serial console should not
accept broadcast messages. Add new files to <filename
class="directory">/etc/profile.d</filename> to do this. <xref
linkend="security-messages-shlong"> shows a file for use by the
Bourne shell.</para>
<figure id="security-messages-shlong">
<title>Restrict sending of messages to console user</title>
<programlisting>
#
# Do we have files referred to?
if [ -x /usr/bin/mesg -a -x /usr/bin/tty ]
then
# Are we on serial console?
if [ `/usr/bin/tty` = /dev/ttyS0 ]
then
# Do not accept broadcast messages
/usr/bin/mesg n
fi
fi
</programlisting>
</figure>
<para>As this file is run frequently, we use a faster but less
readable version of <xref linkend="security-messages-shlong">,
shown in <xref linkend="security-messages-sh">.</para>
<figure id="security-messages-sh">
<title>Restrict sending of messages to console user,
<filename>/etc/profile.d/mesg.sh</filename></title>
<programlisting>
#
# /etc/profile.d/mesg.sh -- prevent people hassling the serial console user
[ -x /usr/bin/mesg -a -x /usr/bin/tty -a `/usr/bin/tty` = /dev/ttyS0 ] &amp;&amp; /usr/bin/mesg n
</programlisting>
</figure>
<para>We also need a C shell version, shown in <xref
linkend="security-messages-csh">.</para>
<figure id="security-messages-csh">
<title>Restrict sending of messages to console user,
<filename>/etc/profile.d/mesg.csh</filename></title>
<programlisting>
#
# /etc/profile.d/mesg.csh -- prevent people hassling the serial console user
if (-X mesg &amp;&amp; -X tty &amp;&amp; `tty` == /dev/ttyS0) then
mesg n
endif
</programlisting>
</figure>
<para>Although <filename>mesg.sh</filename> and
<filename>mesg.csh</filename> are included by the parent shell
rather than executed, the files need the execute permission
set. The procedure in <xref linkend="security-messages-install">
installs the files and sets the permissions.</para>
<figure id="security-messages-install">
<title>Install files into <filename
class="directory">/etc/profile.d</filename></title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>cp mesg.*sh /etc/profile.d/</command>
<prompt>bash#</prompt> <command>chown root:root /etc/profile.d/mesg.*sh</command>
<prompt>bash#</prompt> <command>chmod u=rwx,g=rx,o=rx /etc/profile.d/mesg.*sh</command></screen>
</figure>
</section> <!-- security-messages-wall -->
</section> <!-- security-messages -->
<section id="security-modem">
<title>Modem features to restrict usage</title>
<para>Most modems support the addition of a password. This is not
particularly useful as it has the same strengths and weaknesses of
all other password authentication schemes. We already have
password authentication in the <acronym>BIOS</acronym>, in the boot
loader and in <application>login</application>.</para>
<para>Many modems support call-back. The modem is called and a few
seconds after hang-up it calls a pre-configured number. This
limits the locations that can gain access to the console. </para>
<para>Many modems support checking the calling line identification
(CLI) against a predefined list. If the calling number is not on
the list then the call is cleared. The phone line to the modem
must be configured to send CLI, this may incur an additional charge
from the phone company. Not all calling phones can send CLI and
some valid callers may have asked their phone company to suppress
the sending of CLI.</para>
<para>Many modems can be configured to log the calling line
identification. This is useful when tracing misuse.</para>
<para>Many modems support encryption. Some modems allow multiple
keys. This gives a neat solution: only authorized modems can dial
in, but they can do so from any location. The modems usually need
to be of the same make, and perhaps of the same model.</para>
<warning id="warning-crypto">
<title>Encryption dual-use technology</title>
<para>Possessing, using, buying, selling, importing or exporting
modems with encryption features is a serious criminal offense in
some countries.</para>
<para>You must acquiant yourself with the laws in your
jurisdiction and the laws of jurisdictions you may travel
through.</para>
</warning>
<para>Many telephone services or <acronym>PBX</acronym> lines can
be set to allow only incoming calls. This is useful as it prevents
misuse of the modem should the computer be compromised. A
<quote>demon dialler</quote> can call many numbers seeking an
answering modem and the cost of these calls can be
significant.</para>
</section> <!-- security-modem -->
<section id="security-bios">
<title><acronym>BIOS</acronym> features</title>
<para>Most <acronym>BIOS</acronym>s can be configured with a
<quote>configuration password</quote>. This should set and tested.
Some motherboards will require a jumper to be set to allow the
password to take effect. Some <acronym>BIOS</acronym>s have
well-known <quote>master passwords</quote>, use a search engine to
ensure that your <acronym>BIOS</acronym> is not one of these. The
password should not be the same as the boot loader or <systemitem
class="username">root</systemitem> passwords.</para>
<para>The <acronym>BIOS</acronym> configuration will have a
<quote>boot order</quote> setting. It should be set to boot from
the hard disk before any other media. This prevents someone
inserting a rescue diskette, booting the machine, and gaining
access to the filesystems as <systemitem
class="username">root</systemitem>.</para>
</section> <!-- security-bios -->
<section id="security-bootloader">
<title>Use a boot loader password</title>
<para>Configure the boot loader to request a password when booting a
non-default image or when supplying parameters from the command
line.</para>
<para>This prevents someone from dialing in during the boot
sequence and booting the kernel with options to take control of the
machine, as in <xref
linkend="configure-boot-loader-lilo-hack">.</para>
<para>The password should not be the same as the
<acronym>BIOS</acronym> or <systemitem
class="username">root</systemitem> passwords.</para>
</section> <!-- security-bootloader -->
<section id="security-rhl-prompt">
<title>Non-interactive boot sequence</title>
<para><productname>Red Hat Linux</productname> has an
<quote>interactive boot</quote> option that can be used to prevent
services from being started. This may not be pleasant if the
purpose of the machine is web serving and the
<acronym>HTTP</acronym> daemon is interactively prevented from
starting by an unauthenticated person.</para>
<para>Edit <filename>/etc/sysconfig/init</filename> to contain the
line</para>
<informalfigure>
<programlisting>
PROMPT=no</programlisting>
</informalfigure>
</section> <!-- security-rhl-prompt -->
<section id="security-sysrq">
<title>Magic <keycap>SysRq</keycap> key</title>
<para>The <quote>magic <keycap>SysRq</keycap> key</quote> is a key
sequence that allows some basic commands to be passed directly to
the kernel. Kernel software developers use this interface to debug
their software. Under most circumstances it can also be used to
uncleanly reboot the computer, something that is otherwise
difficult or expensive to do remotely.</para>
<para>For computers that are not used for kernel software
development the magic <keycap>SysRq</keycap> key makes an ideal
denial of service device. A few unauthenticated keystrokes and the
computer is dead in the water. The console, serial or otherwise,
must be in an area with access limited to trusted people.</para>
<para>The serial console uses the <acronym>RS-232</acronym> break
function as the <quote>magic <keycap>SysRq</keycap> key</quote>. A
<quote>break</quote> is a period of no transmission on the serial
line, on traditional terminals it is activated by pressing a key
labeled <keycap>Break</keycap>.</para>
<para>Anyone can dial into a modem and send a break, so if the
serial console is attached to a modem we need to disable the magic
<keycap>SysRq</keycap> key . If the serial console is attached to
a terminal server which asks for authentication, or is attached
directly to another terminal using a null modem cable then you may
decide to activate the magic <keycap>SysRq</keycap> key.</para>
<para>The magic <keycap>SysRq</keycap> key can be disabled by
setting a kernel variable or by not compiling support for the
key.</para>
<para>Writing a <literal>0</literal> into
<filename>/proc/sys/kernel/sysrq</filename> will disable the magic
<keycap>SysRq</keycap> key. The command <command>sysctl</command>
can also be used:</para>
<figure id="security-sysrq-sysctl">
<title>Using <command>sysctl</command> to defeat the magic
<keycap>SysRq</keycap> key</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>sysctl -w kernel.sysrq=0</command></screen>
</figure> <!-- security-sysrq-sysctl -->
<para>Your Linux distribution may have a file
<filename>/etc/sysctl.conf</filename> which is used to run
<command>sysctl</command> during the boot of the machine. Add the
lines:</para>
<figure id="security-sysrq-sysctlconf">
<title>Configuring <filename>/etc/sysctl.conf</filename> to defeat
the magic <keycap>SysRq</keycap> key</title>
<programlisting>
# Disables the magic SysRq key
kernel.sysrq = 0</programlisting>
</figure> <!-- security-sysrq-sysctlconf -->
<para>Even when setting the magic <keycap>SysRq</keycap> key off in
<filename>/etc/sysctl.conf</filename> there is a period of
vulnerability after the kernel boots but before contents of the
file are applied.</para>
<para>It is much better to compile your own kernel and set the
following configuration parameter:</para>
<figure id="security-sysrq-menuconfig">
<title>Kernel <command>make menuconfig</command> showing disabled
<keycap>SysRq</keycap> key</title>
<screen format="linespecific">
Kernel hacking --->
[ ] Magic SysRq key</screen>
</figure> <!-- security-sysrq-menuconfig -->
<para>This should place the following configuration parameter in
<filename>/usr/src/linux/.config</filename>.</para>
<figure id="security-sysrq-dotconfig">
<title>Kernel <filename>.config</filename> showing disabled
<keycap>SysRq</keycap> key</title>
<programlisting>
# CONFIG_MAGIC_SYSRQ is not set</programlisting>
</figure> <!-- security-sysrq-dotconfig -->
</section> <!-- security-sysrq -->
<section id="security-ctrlaltdel">
<title>Adjust behaviour of <keycombo> <keycap>Ctrl</keycap>
<keycap>Alt</keycap> <keycap>Delete</keycap> </keycombo></title>
<para>The <productname>IBM PC</productname> used <keycombo>
<keycap>Ctrl</keycap> <keycap>Alt</keycap> <keycap>Delete</keycap>
</keycombo> to launch a reboot of the computer. Linux traps this
key chord and makes it available to the
<application>init</application> system. This is done by sending
the <application>init</application> process a
<literal>SIGINT</literal> signal (although <command>ctrlaltdel
hard</command> can undo this trap and make the key chord reboot the
comptuer immediately). The <application>init</application> system
uses <filename>/etc/inittab</filename> to determine how to handle
the signal generated by the <keycombo> <keycap>Ctrl</keycap>
<keycap>Alt</keycap> <keycap>Delete</keycap> </keycombo> key
chord.</para>
<para>Most distributions cleanly reboot the system, mimicing the
behaviour that most users expect. <xref
linkend="security-ctrlaltdel-telinit-default"> shows how this is
done.</para>
<figure id="security-ctrlaltdel-telinit-default">
<title>Default handling of <keycombo> <keycap>Ctrl</keycap>
<keycap>Alt</keycap> <keycap>Delete</keycap> </keycombo> in
<filename>/etc/inittab</filename></title>
<programlisting>
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
</programlisting>
</figure>
<para>Depending upon each individual site you may wish to disable
<keycombo> <keycap>Ctrl</keycap> <keycap>Alt</keycap>
<keycap>Delete</keycap> </keycombo>. This is shown in <xref
linkend="security-ctrlaltdel-telinit-ignore">.</para>
<figure id="security-ctrlaltdel-telinit-ignore">
<title>Ignoring <keycombo> <keycap>Ctrl</keycap>
<keycap>Alt</keycap> <keycap>Delete</keycap> </keycombo> in
<filename>/etc/inittab</filename></title>
<programlisting>
# Trap CTRL-ALT-DELETE and do nothing
ca::ctrlaltdel:
</programlisting>
</figure>
<para>Alternatively, you may wish to cleanly shut down the
computer. This is very easy to explain to operators and
instructions can be displayed on the monitor using
<filename>/etc/issue</filename> or a <productname>Post-it
Note</productname>. If the computer uses <productname>Advanced
Power Management</productname> (or <acronym>APM</acronym>) then
shutting down the computer will also remove the power.</para>
<figure id="security-ctrlaltdel-telinit-halt">
<title>Shut down cleanly upon <keycombo> <keycap>Ctrl</keycap>
<keycap>Alt</keycap> <keycap>Delete</keycap> </keycombo> in
<filename>/etc/inittab</filename></title>
<programlisting>
# Trap CTRL-ALT-DELETE and shut down
ca::ctrlaltdel:/sbin/shutdown -t3 -h now
</programlisting>
</figure>
</section> <!-- security-ctrlaltdel -->
<section id="security-log">
<title>Log attempted access</title>
<para>Look in the system logs for the output of
<application>getty</application>. Add the monitoring of these
messages to your log-watching procedures.</para>
</section> <!-- security-log -->
<section id="security-interception">
<title>Countering interception of telephony links</title>
<para>Modems calls over telephones can be intercepted. This can be
an issue if you do not trust a telecommunications carrier in your
call's path, or if you do not trust the law enforcement agencies
that may request interception facilities from that carrier.</para>
<para>International calls are particularly exposed. Calls which
are routed across satellite or wireless links can be intercepted by
readily-available radio receivers. Calls routed across undersea
links are much more expensive to intercept, so this is probably
limited to national governments, such as those using the <ulink
url="http://cryptome.org/cryptout.htm#Echelon">Echelon
system</ulink>.</para>
<para>If you do not pass sensitive data over the link, then the
major exposure is typing in your user name and password. Look into
<ulink
url="http://freshmeat.net/projects/pam_skey/"><application><acronym>S/KEY</acronym></application></ulink>
or look into <ulink
url="http://inner.net/opie/"><application><acronym>OPIE</acronym></application></ulink>
and its related <ulink
url="http://www.tho.org/~andy/pam-opie.html"><application>An
<acronym>OPIE</acronym> for
<acronym>PAM</acronym></application></ulink>.</para>
<para>These one-time password systems have flaws, a good summary of
these is <citetitle>Vulnerabilities in the
<productname><acronym>S/KEY</acronym></productname> one time
password system</citetitle> by Peiter &lsquo;mudge&rsquo;
Zatko.</para>
<warning id="security-interception-keys">
<title>Cryptographic key material</title>
<para>Possessing cryptographic key material, such as a one-time
password generator or list of one-time passwords, is a serious
criminal offense in some countries.</para>
<para>You must acquiant yourself with the laws in your
jurisdiction and the laws of jurisdictions you may travel
through.</para>
</warning>
<warning id="security-interception-law">
<title>Defeating telecommunications interception</title>
<para>Taking steps to defeat or avoid legislatively-approved
telecommunications interception is a serious criminal offense in
some countries.</para>
<para>You must acquiant yourself with the laws in your
jurisdiction and the laws of jurisdictions you may travel
through.</para>
</warning>
</section> <!-- security-interception -->
</chapter> <!-- security -->
<chapter id="kernelcompile">
<title>Configuring a kernel to support serial console</title>
<para>Most <systemitem class="osname">Linux</systemitem> kernels
shipped by distributors are configured to allow the serial console
to be enabled. However system administrators will almost certainly
encounter some problems best solved by recompiling a kernel. In
these cases configure the kernel to support the serial console. The
usual virtual terminal console is also configured, as we normally
want console messages to go a monitor as well as the serial
port.</para>
<section id="kernelcompile-25">
<title>Linux kernel version 2.5</title>
<para>Kernel version 2.5 is under active development, so this
section may be out of date. Version 2.5 includes support for the
console to a serial port attached to a USB dongle. The
<literal>-dj</literal> patch to the version 2.5 kernel has a
rewritten console layer; it is not known if the rewritten layer
effects the user-space use of the serial console.</para>
<para>When configuring the kernel set the following configuration
parameters:</para>
<figure id="kernelcompile-25-menuconfig">
<title>Kernel configuration for serial console using <command>make
menuconfig</command></title>
<screen format="linespecific">
Character devices &hyphen;&hyphen;&hyphen;&gt;
[*] Virtual terminal
[*] Support for console on virtual terminal
&lt;*&gt; Standard/generic (8250/16550 and compatible UARTs) serial support
[*] Support for console on serial port</screen>
</figure>
<para>This should set the following configuration parameters in
<filename>/usr/src/linux/.config</filename>.</para>
<figure id="kernelcompile-25-dotconfig">
<title>Kernel configuration for serial console using
<filename>.config</filename></title>
<programlisting>
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y</programlisting>
</figure>
<para>If you also want to use a serial port attached to a
<acronym>USB</acronym> bus, then in addition to the usual
<acronym>USB</acronym> configuration, configure the kernel to load
the <acronym>USB</acronym> console driver and one of the
<acronym>USB</acronym> serial dongles (our example uses the generic
serial dongle).</para>
<figure id="kernelcompile-25-usb-menuconfig">
<title>Kernel configuration for <acronym>USB</acronym> dongle
serial console using <command>make menuconfig</command></title>
<screen format="linespecific">
USB Serial Converter support &hyphen;&hyphen;&hyphen;&gt;
&lt;M&gt; USB Serial Converter support
[M] USB Serial Console device support
[M] USB Generic Serial Driver</screen>
</figure>
<para>This should set the following configuration parameters in
<filename>/usr/src/linux/.config</filename></para>
<figure id="kernelcompile-25-usb-dotconfig">
<title>Kernel configuration for <acronym>USB</acronym> dongle
serial console using <filename>.config</filename></title>
<programlisting>
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_CONSOLE=m
CONFIG_USB_SERIAL_GENERIC=m
</programlisting>
</figure>
<para>You should also configure the kernel without the magic
<keycap>SysRq</keycap> key, as described in <xref
linkend="security-sysrq">.</para>
</section> <!-- kernelcompile-25 -->
<section id="kernelcompile-24">
<title>Linux kernel version 2.4</title>
<para>When configuring the kernel set the following configuration
parameters:</para>
<figure id="kernelcompile-24-menuconfig">
<title>Kernel configuration for serial console using <command>make
menuconfig</command></title>
<screen format="linespecific">
Character devices &hyphen;&hyphen;&hyphen;&gt;
[*] Virtual terminal
[*] Support for console on virtual terminal
&lt;*&gt; Standard/generic (8250/16550 and compatible UARTs) serial support
[*] Support for console on serial port</screen>
</figure>
<para>This should set the following configuration parameters in
<filename>/usr/src/linux/.config</filename>.</para>
<figure id="kernelcompile-24-dotconfig">
<title>Kernel configuration for serial console using
<filename>.config</filename></title>
<programlisting>
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y</programlisting>
</figure>
<para>You should also configure the kernel without the magic
<keycap>SysRq</keycap> key, as described in <xref
linkend="security-sysrq">.</para>
</section> <!-- kernelcompile-24 -->
<section id="kernelcompile-22">
<title><systemitem class="osname">Linux</systemitem> kernel version
2.2</title>
<para>The later <systemitem class="osname">Linux</systemitem> 2.2
kernels use the same build parameters and parameter syntax as the
<systemitem class="osname">Linux</systemitem> version 2.4
kernels.</para>
<para>For earlier kernels see the <ulink
url="http://www.linuxjournal.com/article.php?sid=2040">article</ulink>
by Francesco Conti in issue 36 of <ulink
url="http://www.linuxjournal.com/"><citetitle>Linux
Journal</citetitle></ulink> published in April 1997.</para>
<para>This article included some patches for the kernel, which have
been extended in the notes below to use a broader range of serial
port speeds.</para>
<para>Choose to use the serial console by adding a couple of
<literal>#defines</literal> at the start of
<filename>/usr/src/linux/drivers/char/console.c</filename>:</para>
<informalfigure>
<programlisting>
#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x3f8 /* COM1 port address */</programlisting>
</informalfigure>
<para>Alternatively, to use <literal>ttyS1</literal> use these
lines:</para>
<informalfigure>
<programlisting>
#define CONFIG_SERIAL_ECHO
#define SERIAL_ECHO_PORT 0x2f8 /* COM2 port address */</programlisting>
</informalfigure>
<para>The kernel assumes a serial link speed of
9600<abbrev>bps</abbrev>. If you are using a differing bit rate
then find these two lines:</para>
<informalfigure>
<programlisting>
serial_echo_outb(0x00, UART_DLM); /* 9600 baud */
serial_echo_outb(0x0c, UART_DLL);</programlisting>
</informalfigure>
<para>and change <literal>0x0c</literal> to one of the values in
<xref linkend="kernelcompile-22-divisors">.</para>
<table frame="topbot" colsep="0" rowsep="0" id="kernelcompile-22-divisors">
<title><acronym>IBM-PC/AT</acronym> serial port bit rates and
their bit-clock divisors</title>
<tgroup cols="2">
<colspec colname="bps" colsep="0" rowsep="0" align="center">
<colspec colname="divisor" colsep="0" rowsep="0" align="center">
<thead>
<row rowsep="1" valign="bottom">
<entry colname="bps" align="center">Bit Rate</entry>
<entry colname="divisor" align="center">Divisor</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="bps">115200<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x01</literal></entry>
</row>
<row>
<entry colname="bps">57600<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x02</literal></entry>
</row>
<row>
<entry colname="bps">38400<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x03</literal></entry>
</row>
<row>
<entry colname="bps">19200<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x06</literal></entry>
</row>
<row>
<entry colname="bps">9600<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x0c</literal></entry>
</row>
<row>
<entry colname="bps">4800<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x18</literal></entry>
</row>
<row>
<entry colname="bps">2400<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x30</literal></entry>
</row>
<row>
<entry colname="bps">1200<abbrev>bps</abbrev></entry>
<entry colname="divisor"><literal>0x60</literal></entry>
</row>
</tbody>
</tgroup>
</table>
</section> <!-- kernelcompile-22 -->
</chapter> <!-- kernelcompile -->
<chapter id="serial">
<title>Serial cabling</title>
<section id="serial-jargon">
<title>Jargon</title>
<para><acronym>RS-232</acronym> cables were originally intended to
link terminals to modems. The terminal is formally named a Data
Terminal Equipment, abbreviated to <acronym>DTE</acronym>. The modem
is formally named a Data Communications Equipment, abbreviated to
<acronym>DCE</acronym>.</para>
<para>A standard <acronym>RS-232</acronym> cable has a 25-pin
D-type socket, which connects to the <acronym>DTE</acronym>, and a
25-pin D-type plug, which connects to the <acronym>DCE</acronym>.
All 25 pins are connected, with pin 1 on the plug wired to pin 1 on
the socket, pin 2 on the plug wired to pin 2 on the socket, and so
on. The shielding of the cable is attached to the metallic cover
on the socket.</para>
<para><acronym>RS-232</acronym> signaling is much more robust than
the signalling of many other communications standards. Pins can be
shorted, not connected or drive more than one output.</para>
<para>Signals are named from the point of view of the Data Terminal
Equipment. So Transmit Data on the <acronym>DTE</acronym> is
connected to Transmit Data on the <acronym>DCE</acronym>. The
Transmit Data pin on the <acronym>DTE</acronym> actually transmits
data, whereas Transmit Data pin on the <acronym>DCE</acronym>
actually recieves data.</para>
</section> <!-- serialjargon -->
<section id="serial-pc-modem">
<title>Cable from console port to modem</title>
<para>The <acronym>RS-232</acronym> standard defines the
interconnection of computers and modems, so there is little to go
wrong here by simply purchasing a pre-assembled cable. There are
two types of cable: cables with connectors for a standard 25-pin D
connector on the computer; and cables with connectors for a
proprietary 9-pin D connector used on the <acronym>IBM</acronym>
<productname><acronym>PC/AT</acronym></productname> and many other
computers. The cables have titles like
<citetitle><acronym>RS-232</acronym> 25-pin computer
(<acronym>DTE</acronym>) to 25-pin modem
(<acronym>DCE</acronym>)</citetitle> or
<citetitle><acronym>RS-232</acronym> 9-pin <acronym>IBM</acronym>
<productname><acronym>PC/AT</acronym></productname> computer
(<acronym>DTE</acronym>) to 25-pin modem
(<acronym>DCE</acronym>)</citetitle>. Most modems are packaged
with a suitable cable.</para>
<para>If you need to manufacture your own cables, see the
<citetitle>Serial-HOWTO</citetitle> for the
<acronym>RS-232</acronym> pinout for your computer. Connect
Transmit Data on the computer to Transmit Data on the modem,
Receive Data on the computer to Receive Data on the modem, and so
on for Signal Ground, Clear to Send, Ready to Send, Data Set Ready,
Data Terminal Ready and Data Carrier Detect.</para>
<para>For professional computer room installations consider routing
the serial cable through an <acronym>RJ-45</acronym> patch panel.
There are two common pinouts on used on the
<acronym>RJ-45</acronym> connector: <ulink
url="http://yost.com/Computers/RJ45-serial/">Yost</ulink> and
<ulink url="http://www.cisco.com/warp/public/701/14.html">Cisco
2500-series</ulink>.</para>
<para>If you create your own pinout for unshielded twisted pair
cable then be sure that your pinout twists a Signal Ground wire
with the Transmit Data wire and another Signal Ground wire with the
Receive Data wire. Although the <acronym>RS-232</acronym> signals
are not balanced, this twist will result in the least amount of
signal degradation and noise pickup.</para>
</section> <!-- serial-pc-modem -->
<section id="serial-pc-terminal">
<title>Cable from console port to terminal (or another PC)</title>
<para>The <acronym>RS-232</acronym> standard allows for, but does
not specify, the interconnection of two computers without
intervening modems. A special cable is required, called a
<quote>null modem</quote> cable.</para>
<para>The wiring within the null modem cable depends upon the
handshaking and control signals that are needed. Differing
manufacturers have differing views on this topic, so don't buy a
null modem cable that does not come with a wiring diagram.</para>
<para>Linux needs all of the flow control and modem control signals
to be correctly wired. The correct wiring of a null modem cable is
shown in <xref linkend="serial-pc-terminal-cable-good1"> with an
alternative shown in <xref
linkend="serial-pc-terminal-cable-good2">.</para>
<para>Linux uses <acronym>CTS</acronym> and <acronym>RTS</acronym> to
do handshaking, preventing the computer from overrunning the
terminal and preventing the terminal from overrunning the computer.
If you are connecting two computers together, then you will not get
reliable file transfers without
<acronym>CTS</acronym>/<acronym>RTS</acronym> handshaking.</para>
<para>Linux uses <acronym>DSR</acronym> and <acronym>DCD</acronym> to
sense that a terminal is connected. It will then request a login.
If a session is established and <acronym>DCD</acronym> falls then
Linux will log out the user.</para>
<para>Linux uses <acronym>DTR</acronym> to force the link to be
cleared. It does this after a user logs off to free up the
communications channel.</para>
<para>Either of the null modem designs in <xref
linkend="serial-pc-terminal-cable-good1"> or <xref
linkend="serial-pc-terminal-cable-good2"> meets the requirements of
the Linux kernel. <xref linkend="serial-pc-terminal-cable-good2">
may be marginally better when both computers are remotely located,
as the differing states of <acronym>DSR</acronym> and
<acronym>DCD</acronym> can be used to determine which end of the
null modem cable has become faulty.</para>
<para>All null modem designs have a common flaw. Computers
interconnected with real modems modem will drop Data Set Ready for
some time after the local modem is reset by the local computer
dropping Data Terminal Ready. Most software is designed to
accomodate this slight difference between modem links and null
modem links.</para>
<para>Major security exposures and significant loss of reliability
can occur with incorrectly wired null modem cables, including the
cables in <xref linkend="serial-pc-terminal-cable-bad">, <xref
linkend="serial-pc-terminal-cable-ugly1"> and <xref
linkend="serial-pc-terminal-cable-ugly2">.</para>
<figure float="1" pgwide="1" id="serial-pc-terminal-cable-good1">
<title>Null modem cable with full status and handshaking</title>
<programlisting>
Signal ground ---------------------- Signal ground
Receive data ---------------------- Transmit data
Transmit data ---------------------- Receive data
Ready to send ---------------------- Clear to send
Clear to send ---------------------- Ready to send
Data terminal ready -----------------+---- Data carrier detect
|
+---- Data set ready
Data carrier detect ----+----------------- Data terminal ready
|
Data set ready ----+
Ring indication -- not connected
not connected -- Ring indication</programlisting>
</figure>
<figure float="1" pgwide="1" id="serial-pc-terminal-cable-good2">
<title>Variation on null modem cable with full status and
handshaking</title>
<programlisting>
Signal ground ---------------------- Signal ground
Receive data ---------------------- Transmit data
Transmit data ---------------------- Receive data
Ready to send ---------------------- Clear to send
Clear to send ---------------------- Ready to send
Data terminal ready ----+----------------- Data carrier detect
|
Data set ready ----+
+---- Data set ready
|
Data carrier detect ----+------------+---- Data terminal ready
Ring indication -- not connected
not connected -- Ring indication</programlisting>
</figure>
<para>Unfortunately not all <systemitem
class="osname">Linux</systemitem> boot loaders support the control
signals required by the <systemitem
class="osname">Linux</systemitem> operating system. This odd state
of affairs may force you to do away with control signals and
handshaking if you need to issue commands to the boot
loader.</para>
<para>There are two ways of defeating the <acronym>RS-232</acronym>
handshaking: software and hardware.</para>
<para>If you have a modem then by far the best technique is to
disable the control signals and handshaking by using
<acronym>AT</acronym> commands to configure the modem's software.
This allows the handshaking to be restored when the boot loader
authors correct their support for serial connections.</para>
<para>For a null modem cable the best approach is to disable
handshaking in your terminal emulation software.</para>
<para>In the worst case for a null modem you will need a cable that
falsifies the handshaking and control signals. Try not to use
these cables in a production environment.</para>
<figure float="1" pgwide="1" id="serial-pc-terminal-cable-bad">
<title>Null modem cable with falsified status and
handshaking</title>
<programlisting>
Signal ground ---------------------- Signal ground
Receive data ---------------------- Transmit data
Transmit data ---------------------- Receive data
Data terminal ready ---+ +--- Data terminal ready
| |
Clear to send ---+ +--- Clear to send
| |
Data carrier detect ---+ +--- Data terminal ready
| |
Data set ready ---+ +--- Data set ready
Ready to send -- not connected
not connected -- Ready to send
Ring indication -- not connected
not connected -- Ring indication</programlisting>
</figure>
<para>If you are happy with a quick hack, perhaps just to use a
serial console to grab a kernel oops message, then you can
configure some <application>getty</application> programs to ignore
the <acronym>RS-232</acronym> status signals. For example,
<application>mgetty</application> has the <literal>direct</literal>
option in <filename>mgetty.conf</filename>. In this case only a
three-wire or two-wire <acronym>RS-232</acronym> null modem cable
is needed.</para>
<figure float="1" pgwide="1" id="serial-pc-terminal-cable-ugly1">
<title>Null modem cable with no status or handshaking</title>
<programlisting>
Signal ground ---------------------- Signal ground
Receive data ---------------------- Transmit data
Transmit data ---------------------- Receive data</programlisting>
</figure>
<figure float="1" pgwide="1" id="serial-pc-terminal-cable-ugly2">
<title>One-way null modem cable with no status or handshaking</title>
<programlisting>
Signal ground ---------------------- Signal ground
Transmit data ---------------------- Receive data</programlisting>
</figure>
<para>Don't use these cables in a production environment.</para>
</section> <!-- serial-pc-terminal -->
<section id="serial-distance">
<title>Lengths of serial cables</title>
<para>The <acronym>RS-232</acronym> standard 9600bps port will
drive 15 metres of shielded cable. More precisely, an
<acronym>RS-232</acronym> line driver will operate against a
capacitance of up to 2500 picoFarad with low enough skew to allow a
9600bps signal to be recovered.</para>
<para>If you select a cable with lower capacitance you can drive
further distances. For example,
<citetitle><acronym>ANSI/TIA/EIA-568-A</acronym></citetitle>
unshielded twisted pair category 5 cable has a maximum capacitiance
of 55<acronym>pF</acronym> per metre, so this popular
<quote><acronym>UTP</acronym> cat 5</quote> cable can be safely
driven up to 45m. Beyond that you should check the cable
manufacturers specifications for the actual <quote>shunt
capacitance</quote> (a common figure is 47.5
<acronym>pF/m</acronym>, giving a maximum cable length of about
50<acronym>m</acronym>). However long runs of unshielded cable
will pick up noise easily, as the <acronym>RS-232</acronym> signals
are not balanced. Some cable manufacturers offer shielded low
capacitance cables which can be driven up to
100<acronym>m</acronym>.</para>
<para>Similarly, if you select a lower data rate you can drive
further distances. <xref linkend="serial-manufacture-distance">
shows the maximum distances over standard shielded cable at
differing data rates.</para>
<table frame="topbot" colsep="0" rowsep="0" id="serial-manufacture-distance">
<title>Data rates and the maximum distances recommended in
<citetitle>RS-232</citetitle></title>
<tgroup cols="2">
<colspec colname="bps" align="center">
<colspec colname="m" align="center">
<thead>
<row>
<entry colname="bps">Data rate (bps)</entry>
<entry colname="m">Distance (m)</entry>
</row>
</thead>
<tbody>
<row>
<entry colname="bps"><para>2400</para></entry>
<entry colname="m"><para>60</para></entry>
</row>
<row>
<entry colname="bps"><para>4800</para></entry>
<entry colname="m"><para>30</para></entry>
</row>
<row>
<entry colname="bps"><para>9600</para></entry>
<entry colname="m"><para>15</para></entry>
</row>
<row>
<entry colname="bps"><para>19200</para></entry>
<entry colname="m"><para>7.6</para></entry>
</row>
<row>
<entry colname="bps"><para>38400</para></entry>
<entry colname="m"><para>3.7</para></entry>
</row>
<row>
<entry colname="bps"><para>56000</para></entry>
<entry colname="m"><para>2.6</para></entry>
</row>
</tbody>
</tgroup>
</table> <!-- serial-manufacture-distance -->
<para>If you are comfortable in working beyond specifications then
you might note that the experience of enterprise network operators
has been that structured cabling layout in buildings is limited by
the 100m distance limitation of fast ethernet over category 5
cable, not by the practical distances achieved by RS-232
asynchronous signals at 9600bps over category 5 cable.</para>
<para>For longer distances use an <acronym>RS-232</acronym> line
driver; these will typically drive up to 2000 meters over category
3 <acronym>UTP</acronym> cable. For greater distances consider
using fiber optical modems, the global telephony system, the mobile
telephony system, satellite or radio.</para>
</section>
<section id="serial-manufacture">
<title>Making serial cables</title>
<para>If you use a serial console for densely-racked computers you
will end up making a lot of null-modem serial cables. This section
has some hints on making serial cables. If you are making more
than ten cables and live in a city you will probably find it
economic to have the cables made by a specialty cabling
firm.</para>
<para>Attempt to minimise noise in your cabling design. Many BIOSs
and boot loaders will wait forever if they receive a single
character of line noise. You might choose to use shielded UTP
cables (these require special RJ-45 plugs but use standard RJ-45
sockets).</para>
<para>If the environment has a lot of radio frequency noise then
use traditional shielded cable and metal RS-232 connector shells.
Connect the shield in the cable to the computer at
<emphasis>one</emphasis> end. This can be done by connecting the
drain wire of the shield it to the Protective Ground (if present)
or by soldering the drain wire to the shell of the connector. If
there is a substantial amount of noise also place a ferrite core
over the shielded cable at both ends of the cable. Follow the
usual good practices of making the cable to the correct length and
screwing home the D connectors into the chassis.</para>
<para>If you are making one of these cables and have some soldering
skill, you can easily do the jumpering of the signal wires within
the backshell of the <acronym>DB9</acronym> or
<acronym>DB25</acronym> connector.</para>
<para>If you are making a large number of cables then crimping
systems are much faster than soldering. Again, pin jumpering can
be done within the backshell.</para>
<para>No matter what system is adopted, use the Resistance setting
of a multimeter to check for dead and shorted pins. A minute here
can save hours later.</para>
<para>For structured cabling systems, space is tight within
<acronym>DB9/RJ-45</acronym> backshells, so the jumpering is better
done behind the patch panel. The <acronym>DB9/RJ-45</acronym>
connectors present the <productname><acronym>IBM</acronym>
<acronym>PC</acronym></productname> pinout at the DB9 connector and
present the Yost or Cisco pinout at the <acronym>RJ-45</acronym>
connector.</para>
<caution id="caution-structuredcabling">
<title>Incompatible devices in structured cabling systems</title>
<para>Take care to connect only <acronym>RS-232</acronym> devices
to <acronym>RS-232</acronym> devices when patching structured
cabling systems. Other cables may be carrying ethernet,
<acronym>ISDN</acronym>, telephony, alarm and
<acronym>DC</acronym> power voltages. Connecting incompatible
voltages may destroy equipment.</para>
</caution>
</section> <!-- serial-manufacture -->
</chapter> <!-- serial -->
<chapter id="modem">
<title>Modem configuration</title>
<section id="modem-minicom">
<title>Using <productname>Minicom</productname> to give commands to
a modem</title>
<para><application>Minicom</application> is a full-screen serial
terminal emulation package, very much like the classic
<application>Telix</application> terminal emulator for
<productname>MS-DOS</productname>.</para>
<para>Firstly, start <application>Minicom</application> in
configuration mode with the command:</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>minicom -o -s</command></screen>
</informalfigure>
<para>The following menu appears:</para>
<informalfigure>
<screen format="linespecific">
<guimenuitem>Filenames and paths</guimenuitem>
<guimenuitem>File transfer protocols</guimenuitem>
<guimenuitem>Serial port setup</guimenuitem>
<guimenuitem>Modem and dialing</guimenuitem>
<guimenuitem>Screen and keyboard</guimenuitem>
<guimenuitem>Save setup as dfl</guimenuitem>
<guimenuitem>Save setup as..</guimenuitem>
<guimenuitem>Exit</guimenuitem>
<guimenuitem>Exit from Minicom</guimenuitem></screen>
</informalfigure>
<para>Select <guimenuitem>Serial port setup</guimenuitem> and
set</para>
<informalfigure>
<screen format="linespecific">
<guimenuitem>A - Serial Device:</guimenuitem> <userinput>/dev/ttyS0</userinput>
<guimenuitem>B - Lockfile Location:</guimenuitem> <userinput>/var/lock</userinput>
<guimenuitem>C - Callin Program:</guimenuitem>
<guimenuitem>D - Callout Program:</guimenuitem>
<guimenuitem>E - Bps/Par/Bits:</guimenuitem> <userinput>9600 8N1</userinput>
<guimenuitem>F - Hardware Flow Control:</guimenuitem> <userinput>Yes</userinput>
<guimenuitem>G - Software Flow Control:</guimenuitem> <userinput>No</userinput></screen>
</informalfigure>
<para>Now save the configuration</para>
<informalfigure>
<screen format="linespecific">
<guilabel>Give name to save this configuration?</guilabel>
<prompt>&gt;</prompt> <userinput>console</userinput></screen>
</informalfigure>
<para>and exit <application>Minicom</application>.</para>
<para>To configure a modem use the command <command>minicom -o
console</command> to start Minicom without sending an
initialization string to the modem. Now issue the
<literal>AT</literal> commands to configure the modem.</para>
<para>When finished use the <guimenuitem>Quit</guimenuitem> option
to leave <application>Minicom</application> without sending a reset
string to the modem; this option is
<keycombo><keycap>Alt</keycap><keycap>Q</keycap></keycombo>.</para>
<para>Sometimes <application>Minicom</application> will use
<keycombo><keycap>Ctrl</keycap><keycap>A</keycap></keycombo> rather
than <keycap>Alt</keycap> to access the menu system, look for a
hint in <application>Minicom</application>'s start up
message:</para>
<informalfigure id="modem-minicom-startup">
<screen format="linespecific">
Press ALT-Z for help on special keys</screen>
<screen format="linespecific">
Press CTRL-A Z for help on special keys</screen>
</informalfigure>
</section> <!-- modem-minicom -->
<section id="modem-dumb">
<title>Configure dumb modem</title>
<para>Linux, like most <productname>UNIX</productname>-like
operating systems, expects a serial console to be connected to a
dumb modem. Dumb modems are not seen much these days, perhaps only
on exotic hardware such as <acronym>ISDN</acronym> terminal adapters
or satellite ground terminals.</para>
<para>A dumb modem is configured using hardware. <xref
linkend="modem-dumb-front"> shows the front panel of a fanciful
dumb modem. In reality the speed and mode settings are likely to
be done using jumpers or DIP switches.</para>
<figure float="1" id="modem-dumb-front">
<title>Front panel of a dumb modem</title>
<programlisting>
+-----------------------------+
| |
| SPEED MODE |
| [ ] 300 [ ] Originate |
| [ ] 600 [X] Answer |
| [ ] 2400 |
| [X] 9600 |
| |
+-----------------------------+</programlisting>
</figure>
<para>The modem's speed is set to the desired bit rate, in our case
9600<abbrev>bps</abbrev>. The modem's mode is set to Answer,
that is, to wait for incoming calls and to answer them.</para>
<para>If the <acronym>RS-232</acronym> control line Data Terminal
Ready is low, the modem will not answer a call. The computer is
off or the computer's serial interface is not yet initialized.
Once <acronym>DTR</acronym> is high the modem will answer incoming
calls.</para>
<para>Once an incoming call is established the modem raises the
Data Carrier Detect control line. Only when DCD is high is
received data valid (data receieved from a dumb modem when DCD is
not asserted is probably line noise). Only when DCD is high is
transmitted data passed through the link.</para>
<para><application>getty</application> on the Linux computer has
been waiting for <acronym>DCD</acronym> to come high, and
<application>getty</application> welcomes the user and requests
them to log in.</para>
<para>Whilst the user is logged in and data is flowing, Clear to
Send and Ready to Send are used between the modem and the computer
to prevent data being sent too soon. The computer lowers Ready to
Send when it is too busy to receive a character. The modem lowers
Clear to Send when it is too busy to receive a character.</para>
<para>When the user hangs up, Data Carrier Detect falls and the
hang up signal is sent to all processes associated with the dial in
session.</para>
<para>Alternatively, the user can log out. When the shell dies,
the computer pulls Data Terminal Ready low, causing the modem to
hang up. When the <application>getty</application> brings Data
Terminal Ready high again, the modem will accept more incoming
calls.</para>
<para>We have not yet described Data Set Ready. This line is low
if the modem is off or if the modem has not yet initialized. When
DSR is low all other signals from the modem are undefined. For
example, if DSR is low but DCD "floats" to the high voltage then
software should behave as if DCD is not asserted.</para>
</section> <!-- modem-dumb -->
<section id="modem-hayes">
<title>Configure modem with <acronym>AT</acronym> commands</title>
<para>Most modems today are smart modems based upon the Hayes
modems and their command sets. But as discussed above, the
<systemitem class="osname">Linux</systemitem> serial console is
designed to operate with a dumb modem.</para>
<para>Thus the smart modem is dumbed-down until it resembles a dumb
modem. Some expensive modems will have a <acronym>DIP</acronym>
switch or board jumper to put them into dumb mode.</para>
<para>It is essential to have a manual for the modem which describes
that modem's <literal>AT</literal> commands. Although most modems
agree on the more popular <literal>AT</literal> commands, they
differ in the more technical commands.</para>
<section id="modem-hayes-bps">
<title>Configure port speed</title>
<para>Hayes <acronym>AT</acronym>-style modems can maintain a
static speed between the computer and the modem, no matter what
speed the dialing modem uses.</para>
<para>For most modems this is set automatically based upon the
speed of the first characters sent after power-on.</para>
<para>Power cycle the modem and connect to it with the command
<command>minicom -o console</command>. Press
<keycap>Enter</keycap> a few times. The modem should now be
running at the same bit rate used by
<application>Minicom</application>, which we set to the speed of
the serial console in <xref linkend="modem-minicom">.</para>
<para>You can check the port speed by asking the modem to generate
some output.</para>
<figure id="modem-hayes-bps-ati">
<title>Testing the modem's port speed</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>minicom -o console</command>
Welcome to minicom
Press CTRL-A Z for help on special keys
<keycap>Enter</keycap> <keycap>Enter</keycap> <keycap>Enter</keycap>
<command>ATI</command> <keycap>Enter</keycap>
56k V.90 Series 3 External V2.20
<keycombo><keycap>Ctrl</keycap><keycap>A</keycap></keycombo> <keycap>Q</keycap>
<guimenu>Leave without reset?</guimenu> <guimenuitem>Yes</guimenuitem></screen>
</figure>
<para>Some modems have an <acronym>AT</acronym> command to
re-establish the port speed, look in your modem's manual for the
<command>AT&amp;B1</command> command. Some modems have a command
to explicitly set the port speed, look in you modem's manual for
the <command>ATB</command> command.</para>
</section> <!-- modem-hayes-bps -->
<section id="modem-hayes-answer">
<title>Configure answer mode</title>
<para>The modem will answer an incoming call on the second ring
using the command <command>ATS0=2</command>.</para>
<para>Don't answer the phone on the first ring as this may
invalidate the certification of the modem in some telephony
jurisdictions.</para>
</section> <!-- modem-hayes-answer -->
<section id="modem-hayes-ctsrts">
<title>Configure <acronym>CTS</acronym>/<acronym>RTS</acronym> handshaking</title>
<para><acronym>CTS</acronym>/<acronym>RTS</acronym> handshaking
prevents lost characters.</para>
<para>The <literal>AT</literal> command is
<command>AT&amp;K3</command>.</para>
</section> <!-- modem-hayes-ctsrts -->
<section id="modem-hayes-dcd">
<title>Configure Data Carrier Detect</title>
<para>Data Carrier Detect should follow the presence or absence of
a calling modem.</para>
<para>The <acronym>AT</acronym> command is
<command>AT&amp;C1</command>.</para>
</section> <!-- modem-hayes-dcd -->
<section id="modem-hayes-dtr">
<title>Configure Data Terminal Ready</title>
<para>Data Terminal Ready should control the modem. If
<acronym>DTR</acronym> is high the modem is ready to receive calls.
If <acronym>DTR</acronym> is low the modem should not receive any
more calls and should hang up any existing call.</para>
<para>The <acronym>AT</acronym> command is
<command>AT&amp;D2</command>.</para>
</section> <!-- modem-hayes-dtr -->
<section id="modem-hayes-connect">
<title>Configure no <computeroutput>CONNECT</computeroutput>
messages</title>
<para>A Hayes <acronym>AT</acronym>-style modem usually outputs a
message when a call is received. For example:</para>
<informalfigure id="modem-hayes-connect-example">
<screen format="linespecific"><computeroutput>CONNECT 9600</computeroutput></screen>
</informalfigure>
<para>The modem has a <quote>quiet mode</quote> that disables these
messages.</para>
<para>The <acronym>AT</acronym> command is
<command>ATQ1</command>. There will be no
<computeroutput>OK</computeroutput> printed in response to this
command.</para>
</section> <!-- modem-hayes-connect -->
<section id="modem-hayes-echo">
<title>Configure no echo of commands</title>
<para>Echoing commands can confuse the console, so turn off
command echoing.</para>
<para>The <literal>AT</literal> command is
<command>ATE0</command>.</para>
</section> <!-- modem-hayes-echo -->
<section id="modem-hayes-speaker">
<title>Optionally, configure silent connection</title>
<para>Most modems have a speaker. By default this is connected
whilst a modem is connecting and negotiating a common protocol and
speed. This is very useful for a dialing modem, as it prevents a
human being accidentally repeatedly called. The speaker can be
annoying on answering modems.</para>
<para>If a quieter computer room is desirable, use the
<command>ATM0</command> command to turn off the speaker.</para>
</section> <!-- modem-hayes-speaker -->
<section id="modem-hayes-dtrdrop">
<title>Optionally, configure DTR delay</title>
<para>Data Terminal Ready drops when the semiconductor that
supports the <acronym>RS-232</acronym> link is reset. This then
hangs up the modem. This can be annoying. If the
<application>getty</application> supports a parameter similar to
<application>mgetty</application>'s
<literal>toggle-dtr-waittime</literal> then it is possible to
extend the time that the modem will ignore <acronym>DTR</acronym>.
The time that <application>getty</application> holds
<acronym>DTR</acronym> low to force a hang up is extended beyond the
modem's setting. The result is that resetting the semiconductor
does not hang up the modem, but <application>getty</application>
can still hang up the modem at the end of a login session.</para>
<para>Check your modem's documentation. Our example modem uses
S-register 25 to contain the threshold for noticing a change in
<acronym>DTR</acronym>. The value is in one-hundreds of a second.
By setting the modem with <command>ATS25=150</command> (1.5
seconds) and setting <application>mgetty</application> with
<literal>toggle-dtr-waittime 2000</literal> (2 seconds) we ignore
small blips in <acronym>DTR</acronym>.</para>
</section> <!-- modem-hayes-dtrdrop -->
<section id="modem-hayes-attention">
<title>Configure no attention sequence</title>
<para>Once the modem is correctly configured and works well,
disable the <literal>+++</literal> sequence that gives access to
the modem's command mode.</para>
<para>The <acronym>AT</acronym> command is
<command>ATS2=255</command>.</para>
<para>If this command is accidentally given see <xref
linkend="modem-hayes-reset"> to reset the modem to its factory
default parameters and start again.</para>
</section> <!-- modem-hayes-attention -->
<section id="modem-hayes-example">
<title>Configuration example</title>
<figure id="modem-hayes-example-config">
<title>Configure modem using <acronym>AT</acronym>
commands</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>minicom -o console</command>
<computeroutput>Welcome to minicom
Press CTRL-A Z for help on special keys</computeroutput>
<command>AT &amp;F</command> <keycap>Enter</keycap>
<computeroutput>OK</computeroutput>
<command>AT Z</command> <keycap>Enter</keycap>
<computeroutput>OK</computeroutput>
<command>AT &amp;C1 &amp;D2 &amp;K3 S0=2 M0</command> <keycap>Enter</keycap>
<computeroutput>OK</computeroutput>
<command>AT E0 Q1 S2=255 &amp;W</command> <keycap>Enter</keycap>
<keycombo><keycap>Alt</keycap><keycap>A</keycap></keycombo> <keycap>Q</keycap>
<guimenu>Leave without reset?</guimenu> <guimenuitem>Yes</guimenuitem></screen>
</figure>
</section> <!-- modem-hayes-example -->
<section id="modem-hayes-reset">
<title>Resetting the modem</title>
<para>If you need to issue more <acronym>AT</acronym> commands to
the modem then power cycle the modem. This should place the modem
into command mode.</para>
<para>Now issue the following commands to restore the modem's
factory configuration.</para>
<figure id="modem-hayes-attention-regain">
<title>Resetting a Hayes <acronym>AT</acronym>-style
modem</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>minicom -o console</command>
<computeroutput>Welcome to minicom
Press CTRL-A Z for help on special keys</computeroutput>
<command>AT &amp;F &amp;Y0 &amp;W &amp;W1</command> <keycap>Enter</keycap>
OK
<command>AT Z</command> <keycap>Enter</keycap>
OK
<keycombo><keycap>Alt</keycap><keycap>A</keycap></keycombo> <keycap>Q</keycap>
<guimenu>Leave without reset?</guimenu> <guimenuitem>Yes</guimenuitem></screen>
</figure>
<para>If this fails then you will need to clear the modem's
configuration memory. The procedure for this varies by
manufacturer, and probably requires the disassembly of the
modem.</para>
</section> <!-- modem-hayes-reset -->
</section> <!-- modem-hayes -->
<section id="modem-internal">
<title>Internal modems</title>
<para>An internal modem is basically an external modem and serial
port mounted upon a <acronym>PC</acronym> bus card. These are
cheaper than external modems as they do not require a power supply
or a chassis.</para>
<para>Internal modems work fine for remote serial console
applications. They are especially attractive for computers at
co-location sites, as those sites charge according to space and
power consumption.</para>
<para>Check that your internal modem preserves its setting across a
power cycle.</para>
<para>Ensure that the interrupt line and port address space used by
the internal modem's serial port do not conflict with that used by
any other pre-existing serial ports. Alternatively, ensure that
the internal serial port can be disabled, freeing its interrupt
line and port address space for use by the internal modem.</para>
<para>Be careful not to confuse an internal modem with a WinModem.
An internal modem does not need a special device driver, but
appears to <systemitem class="osname">Linux</systemitem> as a
stardard serial port.</para>
</section> <!-- modem-internal -->
<section id="modem-dsp">
<title>WinModems</title>
<para>If you look at a modem, with it's small central processing
unit and special-purpose digital signal processor, and then look at
a modern <acronym>PC</acronym>, with it's large <acronym>CPU</acronym>
and general-purpose <acronym>DSP</acronym> on the sound card, you may
wonder if the hardware duplication of an external modem is
necessary.</para>
<para>A <quote>WinModem</quote> incorporates the
<acronym>CPU</acronym> and <acronym>DSP</acronym> of the modem into
the slightly-enhanced fabric of a <acronym>PC</acronym>. They are
called "WinModems" because they originally only shipped with
<productname>Microsoft <systemitem
class="osname">Windows</systemitem></productname> device
drivers. These device drivers presented the illusion of a serial
port attached to a Hayes <acronym>AT</acronym>-style modem. For a
long time only <systemitem class="osname">Windows</systemitem>
versions of these drivers where available. Some manufacturers now
provide <systemitem class="osname">Linux</systemitem> versions of
their device drivers as well, these modems are jokingly called
<quote>LinModems</quote>.</para>
<para>It is probably possible to use a LinModem as a <systemitem
class="osname">Linux</systemitem> console. At the most this would
require altering the source code to dumb-down the AT command
emulation of the modem and recompiling the kernel.</para>
<para>Boot loaders, however, work in a very confined software
environment and struggle to support a simple serial chip.
Considering that some boot loaders do not even handle interrupts,
handling the complex <acronym>DSP</acronym> of a LinModem is well
beyond what is practical.</para>
</section> <!-- modem-dsp -->
</chapter> <!-- modem -->
<appendix id="bugs">
<title>Bugs and annoyances</title>
<section id="bugs-kernelp">
<title>Flow control in <systemitem
class="osname">Linux</systemitem> kernel</title>
<para>The Linux kernel can be asked to do
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control using
the <literal>r</literal> option on the <literal>console=</literal>
parameter. For example, a serial link at 9600bps with 8 data bits,
no parity and <acronym>CTS</acronym>/<acronym>RTS</acronym> flow
control is configured as shown in <xref
linkend="bugs-kernelp-config">.</para>
<figure id="bugs-kernelp-config">
<title>A kernel <literal>console</literal> parameter with
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control</title>
<programlisting>
console=9600n8r
</programlisting>
</figure>
<para>Because the Linux kernel only ever sends data,
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control is
implemented by checking that Clear to Send is not asserted. The
code which does is found in
<filename>/usr/src/linux/drivers/char/serial.c</filename>, the
relevant portion can be seen in <xref
linkend="bugs-kernelp-serialc">.</para>
<figure id="bugs-kernelp-serialc">
<title>Kernel source code for console
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control</title>
<programlisting>
static inline void wait_for_xmitr(struct async_struct *info)
{
&hellip;
/* Wait for flow control if necessary */
if (info-&gt;flags &amp; ASYNC_CONS_FLOW) {
tmout = 1000000;
while (--tmout &amp;&amp;
((serial_in(info, UART_MSR) &amp; UART_MSR_CTS) == 0));
}
}
</programlisting>
</figure>
<para>The loop driven by the <varname>tmout</varname> value of
1000000 results in a wait of about one second for the
<acronym>CTS</acronym> line to become asserted.</para>
<para>This code ignores the status of the <acronym>RS-232</acronym>
Data Set Ready and Data Carrier Detect status lines. This has a
number of consequences.</para>
<itemizedlist>
<listitem>
<para>If the <acronym>RS-232</acronym> cable is unplugged or the
terminal server port is idle then the code waits for
<acronym>CTS</acronym> to be asserted for about one second for
every character written to the console. So the huge number of
characters written to the console when booting a machine can
result in a very long wait for a reboot.</para>
</listitem>
<listitem>
<para>Clear to Send is only validly asserted if Data Carrier
Detect and Data Set Ready are asserted. The code should allow
for an unpowered device which allows <acronym>CTS</acronym> to float.</para>
</listitem>
<listitem>
<para>After looping one million times, if Clear to Send is not
assrted then the character is sent in any case. Thus the kernel
cannot be used on multidrop <acronym>RS-232</acronym> lines. The
character should be dropped instead.</para>
</listitem>
<listitem>
<para>The character is sent even if Data Carrier Detect is not
asserted. Thus the attached modem may be in command mode. This
results in a security flaw if an attacker can get arbitrary text
placed in a console messages. As many console messages contain
error text derived from user events, it would not be too
difficult to place <command>AT&amp;F</command> in a console
message and unprogram the modem's auto-answer
configuration.</para>
</listitem>
</itemizedlist>
<para>As a result of these bugs this <citetitle>HOWTO</citetitle>
no longer recommends the use of kernel-level flow control. The
author has a kernel patch which fixes all current-reported bugs and
is attempting to get that patch integrated into the mainline
kernel. Once the kernel bugs are corrected this
<citetitle>HOWTO</citetitle> will once again recommend kernel-level
flow control.</para>
</section> <!-- bugs-kernelp -->
<section id="bugs-rhl71">
<title><productname>Red Hat <systemitem
class="osname">Linux</systemitem></productname>
<productnumber>7.1</productnumber> and SysVinit</title>
<para>The System V <application>init</application> system shipped
with <productname>Red Hat Linux</productname>
<productnumber>7.1</productnumber> does not support serial console
correctly in single user mode. See Red Hat advisory
<citetitle><acronym>RHBA-2001:085-02</acronym> <ulink
url="http://www.redhat.com/support/errata/RHBA-2001-085.html"><citetitle>New
SysVinit package to fix hangs on serial
console</citetitle></ulink></citetitle>. The advisory announces an
update to the package
<filename>SysVinit-2.78-15.i386.rpm</filename> that is shipped on
the <productname>Red Hat Linux</productname>
<productnumber>7.1</productnumber> <acronym>CD</acronym>.</para>
</section> <!-- bugs-rhl71 -->
<section id="bugs-video">
<title><acronym>BIOS</acronym>s, keyboards and video cards</title>
<para>Some <acronym>BIOS</acronym>s will not boot if the keyboard is
not installed.</para>
<informalfigure id="bugs-video-keyboard">
<screen format="linespecific">
<computeroutput>Keyboard faulty, press F1</computeroutput></screen>
</informalfigure>
<para>Most <acronym>BIOS</acronym>s have settings that will allow
them to boot without a keybaord.</para>
<para>Some odd <acronym>BIOS</acronym>s will not boot if no video
card is installed.</para>
</section> <!-- bugs-video -->
<section id="bugs-reboot">
<title>Modem hangs up upon reboot</title>
<para>During reboot the serial controller is reset. This drops the
modem control line Data Terminal Ready. This in turn instructs the
modem to hang up.</para>
<para>Avoid the temptation to configure the modem to ignore
<acronym>DTR</acronym>. This leads to a worse bug, where the
telephone line does not clear down correctly, the modem is engaged,
and there is no way to clear it. Ignoring <acronym>DTR</acronym>
also gives no way to clear hostile callers from the line.</para>
<para>You may wish to record the amount of time that the computer
takes from <computeroutput>Restarting system</computeroutput> to
the boot loader prompt.</para>
<para>The modem may also hang up during the boot process (as the
serial chip is reset) or when the <application>init</application>
run level is changed (as <application>getty</application> is
restarted).</para>
</section> <!-- bugs-reboot -->
<section id="bugs-monitor">
<title><application>init</application> and
<application>syslog</application> output does not display on
secondary consoles</title>
<para>The kernel can be configured to output messages to the serial
port and to the attached monitor. However messages from
<application>init</application> and
<application>syslog</application> only appear on the last-listed
console device, in our case the serial port.</para>
<para>This can confuse someone looking at the attached monitor, as
the messages on the monitor suggest that the machine has hung just
before starting <application>init</application>. Eventually the
machine will finish booting and <application>getty</application>
will display a <prompt>login:</prompt> request. A Post-it Note on
the monitor may reassure the impatient.</para>
</section> <!-- bugs-monitor -->
<section id="bugs-whereami">
<title>The console is unresponsive after connecting</title>
<para>The terminal's screen may be blank after connecting to the
machine. Pressing <keycap>Enter</keycap> will usually bring up a
<prompt>login:</prompt> request.</para>
<para>If no characters appear upon the screen after pressing
<keycap>Enter</keycap> do not panic. The machine must have power
and the operating system must have booted: for our call to be
answered by the modem Data Terminal Ready must be active.</para>
<para>The most likely thing is that the machine booted and is
running a <command>fsck</command> filesystem check. These checks
can take some considerable time, all with no or very little
output.</para>
<para>It will help your peace of mind considerably to record in the
system log book the time <command>fsck</command> takes to check
each filesystem.</para>
<para>If you see garbled text after pressing <keycap>Enter</keycap>
then there are mismatched bit rates or parity parameters. Correct
your terminal emulator's configuration.</para>
</section>
<section id="bugs-setserial">
<title>Modem hangs up during initialization</title>
<para>Using <command>setserial</command> will reset the serial
port. This will hang up the modem.</para>
<para><command>setserial</command> is sometimes used during the
boot process, resulting in the output seen in <xref
linkend="bugs-setserial-init">. Look into the file
<filename>/etc/rc.serial</filename> and remove any references to
the port which is being used as the serial console.</para>
<figure id="bugs-setserial-init">
<title><command>setserial</command> causes a modem to hang up as
the machine initializes</title>
<screen format="linespecific">
<computeroutput>&hellip;
Mounting local filesystems: [ OK ]
Turning on user and group quotas for local filesystems: [ OK ]
Enabling swap space: [ OK ]
/dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A
NO CARRIER</computeroutput></screen>
</figure>
</section> <!-- bugs-setserial -->
<section id="bugs-bootloaderflow">
<title>Boot loader has no flow control</title>
<para>Most boot loaders do not support
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control. This can
cause some data loss where large speed mis-matches exist, as is
often the case with a modern modem connected into a
9600<abbrev>bps</abbrev> fixed-speed port.</para>
<para><application>SYSLINUX</application> 1.66 supports flow
control.</para>
</section> <!-- bugs-bootloaderflow -->
<section id="bugs-bootloadernoise">
<title>Boot loaders are vulnerable to line noise</title>
<para>Most boot loaders will sit at their prompt forever after
receiving a single character of line noise.</para>
<para>Some modems will let the <acronym>RS-232</acronym> signals
"float", sending noise when there is no caller. Because the modem
is not asserting Data Carrier Detect it expects the receiver to
discard the noise characters.</para>
<para>The combination of an unfortunate boot loader with an
unfortunate modem can result in a machine that will regularly hang
during booting.</para>
<para>If you cannot configure your boot loader to obey
<acronym>DCD</acronym> then be careful to test any modem you intend
to purchase to ensure that it does not generate characters when
their is no caller. At the present only
<application>SYSLINUX</application> implements full
<acronym>RS-232</acronym> status signals.</para>
</section> <!-- bugs-bootloadernoise -->
<section id="bugs-apm">
<title><productname>Advanced Power Management</productname></title>
<para><acronym>APM</acronym> allows control of the power from
software. This can be a blessing and a curse.</para>
<para>The blessing is that the machine can be cleanly and totally
shut down remotely. You may want to do this if the remote site is
maintaining their power supply.</para>
<para>The curse is that once powered down the machine will not
start up again until the <keycap>Power</keycap> button is
physically pressed. Some machines have a <acronym>BIOS</acronym> or
motherboard setting to defeat this unhelpful behaviour.</para>
<caution id="caution-shutdown">
<title>Errors when typing <command>shutdown</command> are worse
with <acronym>APM</acronym></title>
<para>Be careful not to confuse <command>shutdown -r
now</command>, which cleanly reboots the machine, with
<command>shutdown -h now</command>, which cleanly powers down the
machine. Someone will need to physically press the
<keycap>Power</keycap> button if you choose wrongly.</para>
</caution>
<para>If you are serious about remote site computing then you
should investigate remote power switches from companies like <ulink
url="http://www.wti.com/">Western Telematic</ulink>, <ulink
url="http://www.servertech.com/">Server Technology</ulink> and many
others. Some models include built-in terminal servers, built-in
modems and <acronym>RS-232</acronym> lines to simulate a
<acronym>UPS</acronym> input power failure (and thus shut the
<systemitem class="osname">Linux</systemitem> system down cleanly
before removing power).</para>
</section> <!-- bugs-apm -->
<section id="bugs-international">
<title>Modems and overseas telecommunications requirements</title>
<para>There is no world-wide approval processes to certify that a
modem is suitable for connection to the telephone network. This is
despite the presence of a common set of technical standards that
modems must meet for use on the global switched telephone network.
There is little or no recognition of one nation's approvals by
other national regulators.</para>
<para>There are national technical requirements concerning the use
of modems. Common requirements are to set the modem and its
software to answer after the second ring and never to dial the same
engaged or faulty number more than five times in a row.</para>
<warning id="warning-approval">
<title>Telecommunications device approvals</title>
<para>Using or importing unapproved telecommications equipment is
a criminal offense in most countries.</para>
<para>Additionally, the operator of some types of equipment may
require certification.</para>
</warning>
<para>Privacy laws may control what can be done with calling line
identification records.</para>
<para>Do not assume that Touch Tone dialling is globally available.
There is no common standard for decadic dialling: some countries
have the longest sequence for zero, other countries have the
shortest sequence for zero.</para>
<para>There is little coordination of national numbering plans. Be
careful not to call a national emergency services number when
intending to dial the international access code. Common emergency
services numbers are: 112, 911, 000. International access codes
vary by country.</para>
<para>Intelligent network features such as toll-free numbers are
usually not available to calls originating from abroad.</para>
<para>International calls may be routed through fiber optical
submarine cable, satelite or High Frequency radio. The possible
bit rates vary considerably between these options. Expect the
maximum throughput with no errors from fiber optical submarine
cable. Expect 1200<abbrev>bps</abbrev> to
2400<abbrev>bps</abbrev> with some errors from satelite. Expect
75<abbrev>bps</abbrev> to 300<abbrev>bps</abbrev> with many
errors from <acronym>HF</acronym> radio.</para>
<para>There will be considerable latency depending upon the
distance. If the latency becomes greater than the modem's error
correction window then you will get better
<productname>Zmodem</productname> file transfer performance if you
disable the <acronym>HDLC</acronym>-based error correction in the
modems.</para>
<para>International calls may have their signal altered
considerably. Traditionally, international calls are placed
through analogue conditioning circuits to minimise echo. This
conditioning limits the maximum bit rate a modem can achieve,
probably to less than 9600<abbrev>bps</abbrev>. You may be able to program a
<wordasword>guard tone</wordasword> to disable analogue
conditioning, this will vary by carrier and the commands to send
the guard tone vary by modem.</para>
<para>On some modern international circuits, particularly those
accessed by international calling cards, digital voice compression
is used. No reliable modem connection can be established over
these digitally-compressed circuits. The best current tactic for
identifying these digitally compressed circuits is to listen to the
background noise &mdash; when no-one is speaking the real
background noise will be replaced by a synthesized background noise
(a compression technique called <wordasword>silence
suppression</wordasword>).</para>
</section> <!-- bugs-international -->
</appendix> <!-- bugs -->
<appendix id="upload">
<title>Uploading files from a serial console</title>
<para>There are many scenarios where the machine is dead in the
water and you need to upload a file to correct that. In many of
these scenarios the only way to upload the file is via the serial
port being used as the console.</para>
<para>Moving files about over serial links has a long history in
microcomputing and this section goes back in time to uncover the
tools commonly used in the pre-Internet age of the Bulletin Board
System.</para>
<section id="upload-logging">
<title>Disable logging to console</title>
<para>Before attempting to upload or download files it is a good
idea to prevent messages from appearing on the console. These
messages will corrupt files moved using <command>cat</command> and
will cause <application>Xmodem</application> and similar protocols
to take much, much longer.</para>
<para>Alter your system's configuration to give
<application>klogd</application> the <literal>-c 1</literal>
parameter, inhibiting the display of kernel messages directly to
the console. Kernel messages will still go to the system
logger.</para>
<figure>
<title>Supressing kernel messages to the console in Red Hat
Linux</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>vi /etc/sysconfig/syslog</command></screen>
<programlisting format="linespecific">
KLOGD_OPTIONS="-2 -c 1"</programlisting>
<screen format="linespecific">
<prompt>bash#</prompt> <command>/etc/init.d/syslog restart</command></screen>
</figure>
<para>Also modify the system logger's configuration not to send
messages to the console. Edit
<filename>/etc/syslog.conf</filename>, altering lines sending
output to <filename class="devicefile">/dev/console</filename>.
Send this output to a file instead.</para>
</section> <!-- upload-logging -->
<section id="upload-cat">
<title><acronym>ASCII</acronym> upload and <command>cat</command></title>
<para><command>cat</command> is available on every
<acronym>UNIX</acronym>-like system. It copies the data received
from the keyboard to a file. Minicom and other terminal emulators
have an <quote><acronym>ASCII</acronym> upload</quote> facility that
will send a file up the serial link as though it had been
typed.</para>
<informalfigure>
<screen format="linespecific">
<prompt>remote bash$</prompt> <command>cat > upload.txt</command>
</screen>
<screen format="linespecific">
<keycombo><keycap>Alt</keycap><keycap>S</keycap></keycombo> <guimenu>Upload</guimenu> <guimenuitem>ascii</guimenuitem>
<guilabel>[ascii upload - Press CTRL-C to quit]</guilabel>
</screen>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">Wait for upload to complete&hellip;</literallayout>
<screen format="linespecific">
<guilabel>ASCII upload of "upload.txt"
10.0 Kbytes transferred at 3900 CPS... Done.
READY: press any key to continue...</guilabel>
</screen>
<screen format="linespecific">
<keycombo><keycap>Ctrl</keycap><keycap>D</keycap></keycombo>
<prompt>remote bash$</prompt>
</screen>
</informalfigure>
<para>Without hardware flow control <acronym>ASCII</acronym> upload
will drop the occassional character.</para>
<para>To upload binary files encode them into
<acronym>ASCII</acronym>, upload them, and then decode them into
binary again.</para>
<informalfigure>
<screen format="linespecific">
<prompt>localhost bash$</prompt> <command>uuencode upload.bin &lt; upload.bin &gt; upload.txt</command>
</screen>
<screen format="linespecific">
<keycombo><keycap>Alt</keycap><keycap>S</keycap></keycombo> <guimenu>Upload</guimenu> <guimenuitem>ascii</guimenuitem>
<guilabel>[ascii upload - Press CTRL-C to quit]</guilabel>
</screen>
<literallayout format="linespecific" linenumbering="unnumbered" class="normal">Wait for upload to complete&hellip;</literallayout>
<screen format="linespecific">
<guilabel>ASCII upload of "upload.txt"
10.0 Kbytes transferred at 3900 CPS... Done.
READY: press any key to continue...</guilabel>
</screen>
<screen format="linespecific">
<keycombo><keycap>Ctrl</keycap><keycap>D</keycap></keycombo>
<prompt>remote bash$</prompt>
</screen>
<screen format="linespecific">
<prompt>remote bash$</prompt> <command>uudecode &lt; upload.txt</command>
</screen>
</informalfigure>
<para>You can detect transmission errors by using a checksum
program such as <command>sum</command>, <command>cksum</command> or
<command>md5sum</command>. Print the ckecksum of the file before
it is sent from the local machine and after it is recieved upon the
remote machine.</para>
<informalfigure>
<screen format="linespecific">
<prompt>localhost bash$</prompt> <command>cksum upload.bin</command>
<computeroutput>1719761190 76 upload.bin</computeroutput>
</screen>
<screen format="linespecific">
<prompt>remote bash$</prompt> <command>cksum upload.bin</command>
<computeroutput>1719761190 76 upload.bin</computeroutput>
</screen>
</informalfigure>
<para>There are a number of checksumming programs. The
<command>sum</command> command should be used with caution, as
there are versions for <acronym>BSD</acronym> and
<productname>System V <acronym>UNIX</acronym></productname> which
give differing results. <command>cksum</command> is the attempt by
the <acronym>POSIX</acronym> standards developers to correct that
mess: it gives the same result for the same file on all
<acronym>POSIX</acronym> machines.</para>
<para>If the checksums of the original and uploaded files do not
match then the file will have to be uploaded again. If the link is
noisy and the file is big then you may never get a successful
upload. What is needed in this case is to divide the file into
many small parts, upload a part, check its checksum, and if it is
fine proceed to the next part.</para>
<para>This sounds like something that should be automated.
Entering from stage left is <application>Xmodem</application>.</para>
</section> <!-- upload-cat -->
<section id="upload-zmodem">
<title><application>Xmodem</application>,
<application>Ymodem</application> and
<application>Zmodem</application></title>
<para><application>Xmodem</application> sends 128 bytes and a
checksum, waits for a Acknowledgment to say all is well and sends
the next block. If a negative acknowledgement is received or if no
<acronym>ACK</acronym> or <acronym>NAK</acronym> ever appears then
the block is sent again.</para>
<para><application>Xmodem</application> is a simple protocol, as
you would expect of a program written for 8-bit computers running
<systemitem class="osname">CP/M</systemitem>. It has lots of
inefficiencies and minor problems, such as rounding up the file
size to the next 128 byte boundary. These deficiencies lead to an
evolution of the protocol with revisions of
<application>Xmodem</application>, then
<application>Ymodem</application> and finishing with
<application>Zmodem</application>.
<application>Zmodem</application> is substantially faster than
<application>Xmodem</application> and has no niggling problems.
The <application>Zmodem</application> protocol is substantially
more complex than the <application>Xmodem</application> protocol,
but since we only seek to at most compile the code, that complexity
need not concern us.</para>
<informalfigure>
<screen format="linespecific">
<prompt>remote bash$</prompt> <command>rz</command>
<computeroutput>... waiting to receive.**B0100000023be50</computeroutput>
</screen>
<screen format="linespecific">
<keycombo><keycap>Alt</keycap><keycap>S</keycap></keycombo> <guimenu>Upload</guimenu> <guimenuitem>zmodem</guimenuitem>
<guilabel>[zmodem upload - Press CTRL-C to quit]
Sending: upload.bin
Bytes Sent: 3072/ 10000 BPS:2185 ETA 00:09</guilabel>
</screen>
</informalfigure>
<para>If an upload fails and you are left with
<command>rz</command> waiting to recieve a file then typing
<keycombo><keycap>Ctrl</keycap><keycap>X</keycap></keycombo> a
number of times will return you to the command prompt. This also
works for <application>Xmodem</application>'s <command>rx</command>
and <application>Ymodem</application>'s
<command>ry</command>.</para>
<para>Useful <application>Zmodem</application> abilities are
resuming failed uploads and sending multiple files in a single
upload session.</para>
<para>An implementation of <application>Xmodem</application>,
<application>Ymodem</application> and
<application>Zmodem</application> for <acronym>POSIX</acronym>
computers is available from <ulink
url="http://www.ohse.de/uwe/software/lrzsz.html">http://www.ohse.de/uwe/software/lrzsz.html</ulink>.
<productname>Red Hat Linux</productname> distribute this in the
<filename>lrzsz</filename> <acronym>RPM</acronym> package.
<application>lrzsz</application> is a enhanced free software branch
of the public domain version of <ulink
url="ftp://ftp.cs.pdx.edu/pub/zmodem/rzsz.zip"><application>rzsz</application></ulink>
from <ulink url="http://www.omen.com/">Omen
Technology</ulink>.</para>
</section> <!-- upload-zmodem -->
<section id="upload-kermit">
<title><application>Kermit</application></title>
<para><ulink
url="http://www.kermit-project.org/"><application>Kermit</application></ulink>
is a terminal emulator and file transfer program delevoped by
<ulink url="http://www.columbia.edu/">Columbia University</ulink>.
It's popularity springs from the large range of computers that
<application>Kermit</application> could be used to access, from
<acronym>IBM</acronym> mainframes to
<productname><acronym>MS-DOS</acronym></productname>
<acronym>PC</acronym>s.</para>
<para>A <application>Kermit</application> variant named <ulink
url="http://www.columbia.edu/kermit/gkermit.html"><application>G-Kermit</application></ulink>
was released under the <citetitle>GNU Public License</citetitle>.
This is available in most <productname>Linux</productname>
distributions.</para>
<para>The recent <application>Kermit</application> and
<application>Zmodem</application> protocols are built upon the same
technologies. <application>Zmodem</application> has better
performance in calls with high error rates.
<application>Kermit</application> has been ported to more host
platforms.</para>
</section> <!-- upload-kermit -->
</appendix>
<appendix id="rhl">
<title>Upgrading <productname>Red Hat Linux</productname> from a
serial console</title>
<para>Upgrades to Linux distributions are frequently released. A
machine is not remotely manageable unless these upgrades can be
installed without needing to physically touch the machine.</para>
<para>This section examines the remote installation and remote
upgrade of <productname>Red Hat Linux</productname>.</para>
<para><productname>Red Hat Linux</productname> can be installed over
the network from a <acronym>HTTP</acronym> server using an install
diskette. We modify this diskette to use the serial console. If we
can control whether to boot from this diskette or from the hard disk
then we can remotely upgrade the Red Hat Linux distribution from the
serial port. If a blank diskette is placed in the drive when the
machine is deployed then no on-site intervention is needed to
upgrade the operating system.</para>
<para>If you have upgrade procedures for other
<systemitem class="osname">Linux</systemitem> distributions please contribute
them to the <citetitle>HOWTO</citetitle> maintainer.</para>
<section id="rhl-selectboot">
<title>Select boot disk</title>
<para>The key to a remote upgrade is to be able to boot from floppy
disk to perform the upgrade, and then to reboot from the hard disk.
The possibilities are:</para>
<orderedlist>
<listitem>
<para>Most <acronym>BIOSs</acronym> allow the boot disk order to be
controlled through the <acronym>BIOS</acronym>' configuration. If
the <acronym>BIOS</acronym> supports a serial console then the
machine can be upgraded whilst leaving the floppy disk in the
drive. No one need attend the site to upgrade the operating
system</para>
</listitem>
<listitem>
<para>Someone can insert a floppy disk before the upgrade and
remove it afterwards. Most co-location sites will provide this
level of <quote>board-swap</quote> technical support.</para>
</listitem>
<listitem>
<para>Two records of the CMOS memory which stores the
<acronym>BIOS</acronym> configuration can be made: one for booting
from floppy and another for booting from hard disk.
Unfortunately the nvram device driver does not yet work on a wide
enough variety of machines for this HOWTO to pursue this option
further.</para>
</listitem>
</orderedlist>
</section> <!-- rhl-selectboot -->
<section id="rhl-biosserial">
<title>Configure the <acronym>BIOS</acronym> to use the serial
port</title>
<para>Many servers allow the <acronym>BIOS</acronym> to be configured
from the serial port, especially on systems designed for rack
mounting. At the moment few machines designed to be used as
desktop systems allow the <acronym>BIOS</acronym> to be accessed from
the serial port.</para>
<para>Refer to your vendor's documentation to set the
<acronym>BIOS</acronym> to use the serial port. Some vendors call
this feature <quote>console redirection</quote>. Unfortunately, the
meaning of this term varies by vendor. Some vendors use it to mean
the redirection of the <acronym>VGA</acronym> output and keyboard
to a remote <acronym>PC</acronym> using a proprietary serial
protocol. This feature can only be used in conjunction with the
<systemitem class="osname">Linux</systemitem> serial console if the
<acronym>BIOS</acronym> can be instructed to disable the serial
redirection after booting.</para>
<para>As an example of the confusion, Dell uses <quote>console
redirection</quote> when describing the <productname>Dell
2400</productname> and the <productname>Dell 2450</productname>.
The <productname>Dell 2450</productname> <acronym>BIOS</acronym>
can be configured from the serial port. The <productname>Dell
2400</productname>'s <quote>console redirection</quote> is
additional hardware that remotely replicates the computer's
<acronym>VGA</acronym> monitor and keyboard.</para>
<para>An example of a <acronym>BIOS</acronym> configuration is given
in <xref linkend="rhl-biosserial-example">.</para>
<figure id="rhl-biosserial-example">
<title>Configuring <acronym>BIOS</acronym> to use serial link</title>
<screen format="linespecific">
BIOS setup console redirection
Enter BIOS setup during boot when
Keyboard: [Ctrl+Alt+Esc pressed]
Serial port: ["HAL" is typed]
Serial port
Port: [COM1]
Speed [9600] bps
Data: [8] bits
Parity: [None]
Stop: [1] bits
Handshaking: [Full CTS/RTS handshaking]
Terminal: [Dumb]</screen>
</figure>
<para>Many <acronym>BIOSs</acronym> will enter their configuration
dialogs if a particular terminal key is pressed during the
<acronym>BIOS</acronym> boot. This can be a problem if the modem
link is noisy.</para>
<para>For normal operation, set the boot order to attempt to boot
from the hard disk first.</para>
<figure id="rhl-biosserial-bootorder">
<title>Configuring BIOS to boot from hard disk</title>
<screen format="linespecific">
BIOS setup boot order
First: [Hard disk]
Second: [CD-ROM]
Third: [Floppy disk]</screen>
</figure>
</section> <!-- rhl-biosserial -->
<section id="rhl-ignoredtr">
<title>Configure modem to ignore <acronym>DTR</acronym> and assert
<acronym>DCD</acronym></title>
<para>The computer reboots a few times during the upgrade. These
reboots hang up the modem. Having to dial in a number of times
during the upgrade can become annoying. Altering the modem's
configuration to ignore Data Terminal Ready will cause the modem
not to hang up when the computer is rebooted. To ignore
<acronym>DTR</acronym> send the command
<command>AT&amp;D0</command> to the modem.</para>
<para>We may also wish to disconnect during the install to reduce
transmission charges. Configuring the modem to hold Data Carrier
Detect on will prevent any disconnection and reconnection from
being apparent to the installer. Use the command
<command>AT&amp;C0</command> to always hold <acronym>DCD</acronym>
high.</para>
<para>Apply these changes using the procedure in <xref
linkend="modem-hayes">, retaining all of the other
<literal>AT</literal> commands.</para>
</section> <!-- rhl-ignoredtr -->
<section id="rhl-preparefloppy">
<title>Prepare a network install floppy diskette</title>
<para>The <productname>Red Hat Linux</productname> web site has a
floppy diskette image for a network installation. For
<productname>Red Hat Linux</productname>
<productnumber>7.1</productnumber> the image is <ulink
url="ftp://ftp.redhat.com/pub/redhat/linux/7.1/en/os/i386/images/bootnet.img"><filename>ftp://ftp.redhat.com/pub/redhat/linux/7.1/en/os/i386/images/bootnet.img</filename></ulink>.</para>
<para>Install this image on a floppy disk.</para>
<informalfigure id="rhl-preparefloppy-image">
<screen format="linespecific">
<prompt>bash#</prompt> <command>mkfs -t msdos -c /dev/fd0</command>
<computeroutput>mkfs.msdos 2.2 (06 Jul 1999)</computeroutput>
<prompt>bash#</prompt> <command>dd if=bootnet.img of=/dev/fd0 bs=1440k</command>
<computeroutput>1+0 records in
1+0 records out</computeroutput>
<prompt>bash#</prompt> <command>sync</command></screen>
</informalfigure>
<para>Now mount the diskette and check that the installer files are
present.</para>
<informalfigure id="rhl-preparefloppy-mount">
<screen format="linespecific">
<prompt>bash#</prompt> <command>mount -t vfat /dev/fd0 /mnt/floppy</command>
<prompt>bash#</prompt> <command>ls /mnt/floppy</command>
<computeroutput>boot.msg general.msg ldlinux.sys rescue.msg vmlinuz
expert.msg initrd.img param.msg syslinux.cfg</computeroutput></screen>
</informalfigure>
<para>This floppy disk uses the
<application>SYSLINUX</application> boot loader which was
discussed in <xref linkend="configure-boot-loader-syslinux"> and
in <xref linkend="configure-kernel-syslinux">. Firstly, we alter
the boot loader configuration file
<filename>/mnt/floppy/syslinux.cfg</filename> to use the serial
port. If you are going to use the <application>vi</application>
editor to alter this file, use the <literal>-n</literal> option to
avoid writing a swap file to the floppy disk.</para>
<informalfigure>
<screen>
<prompt>bash#</prompt> <command>vi -n /mnt/floppy/syslinux.cfg</command></screen>
<programlisting>
serial 0 9600</programlisting>
</informalfigure>
<para>Secondly we add a new boot option. This is modeled upon the
other boot options in the file. Our variant passes the serial
console parameters to the kernel, the same parameters that we pass
during normal operation when using serial console. "serial" seems
an appropriate name for the boot option.</para>
<informalfigure>
<programlisting>
label serial
kernel vmlinuz
append initrd=initrd.img lang= text serial expert devfs=nomount console=ttyS0,9600n8</programlisting>
</informalfigure>
<para><literal>text</literal>, <literal>serial</literal> and
<literal>expert</literal> are parameters to the Red Hat
<application>anaconda</application> installer. Specifying
<literal>text</literal> ensures that the graphical installer does
not start. Specifying <literal>serial</literal> prevents scans for
possibly non-existent video hardware. You will need to run
<application>Xconfigurator</application> manually if you do have a
video card. Specifying <literal>expert</literal> allows all the
configuration options to be seen, giving one floppy image that can
be used for all purposes.</para>
<para>Thirdly, we make this new configuration start automatically.
As there is no-one at the site, there's no need to issue a
<prompt>boot:</prompt> prompt.</para>
<informalfigure>
<programlisting>
default serial
prompt 0</programlisting>
</informalfigure>
<para>Fourthy, we write the new configuration to diskette.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>umount /mnt/floppy</command></screen>
</informalfigure>
<para>Check that the diskette boots. If it does not then write a
new boot sector by downloading and running the most recent
<application>SYSLINUX</application>.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>syslinux /dev/fd0</command></screen>
</informalfigure>
<para>Finally, create a new boot image for copying to the
computers to be upgraded.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>dd if=/dev/fd0 of=bootserialnet.img bs=1440k</command>
<computeroutput>1+0 records in
1+0 records out</computeroutput></screen>
</informalfigure>
<para>If you test the new boot floppy on a machine with a serial
console you should briefly see <application>SYSLINUX</application>
booting</para>
<informalfigure>
<screen format="linespecific">
<computeroutput>SYSLINUX 1.52 2001-02-07 Copyright (C) 1994-2001 H. Peter Anvin</computeroutput></screen>
</informalfigure>
<para>and then presenting the <filename>boot.msg</filename> file
and then the <systemitem class="osname">Linux</systemitem> kernel should be
loaded</para>
<informalfigure>
<screen format="linespecific">
<computeroutput>Loading initrd.img..............
Loading vmlinuz............. ready.</computeroutput></screen>
</informalfigure>
<para>and run.</para>
<informalfigure>
<screen format="linespecific">
<computeroutput>Linux version 2.4.2-2BOOT (root@porky.devel.redhat.com) (gcc version 2.96 200001</computeroutput></screen>
</informalfigure>
<para>Next the <application>init</application> system flashes
by</para>
<informalfigure>
<screen format="linespecific">
<computeroutput>Greetings.
Red Hat install init version 7.0 starting
mounting /proc filesystem... done
mounting /dev/pts (unix98 pty) filesystem... done
Red Hat install init version 7.0 using a serial console
remember, cereal is an important part of a nutritionally balanced breakfast.
checking for NFS root filesystem...no
trying to remount root filesystem read write... done
checking for writeable /tmp... yes
running install...
running /sbin/loader</computeroutput></screen>
</informalfigure>
<para>before the installation application, called
<application>anaconda</application>, is started</para>
<informalfigure>
<screen format="linespecific">
<computeroutput>
Welcome to Red Hat Linux
+----------+ Devices +-----------+
| |
| Do you have a driver disk? |
| |
| +-----+ +----+ |
| | Yes | | No | |
| +-----+ +----+ |
| |
| |
+--------------------------------+
&lt;Tab&gt;/&lt;Alt-Tab&gt; between elements | &lt;Space&gt; selects | &lt;F12&gt; next screen</computeroutput></screen>
</informalfigure>
<para>There does not seem to be a way to access the function keys,
fortunately the user interface does not require their use.</para>
<para>Now that the floppy has been tested, eject the disk and
reboot the machine into normal operation.</para>
</section> <!-- rhl-preparefloppy -->
<section id="rhl-preparehttp">
<title>Prepare <acronym>HTTP</acronym> server</title>
<para>It is best if the web server runs the version of Red Hat
Linux as is being upgraded to. If it runs an earlier version, then
do not rebuild the operating system on this machine and install
<application>anaconda-runtime</application> from the later
operating system.</para>
<para>Copy the Linux distribution to a local web server using a
mirroring utility like <command>wget</command>. Alternatively the
files can be copied from the distribution <acronym>CD</acronym>s to
the web server.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash$</prompt> <command>mkdir &hyphen;&hyphen;mode=664 &hyphen;&hyphen;parents /var/www/html/redhat/linux/7.1/en/os/i386</command>
<prompt>bash$</prompt> <command>umask 002</command>
<prompt>bash$</prompt> <command>wget -nh -nH -r -N -nr -l0 -k -np -X SRPMS ftp://ftp.redhat.com/pub/redhat/linux/7.1/en/os/i386/ -P /var/www/html/redhat/linux/7.1/en/os/i386</command></screen>
</informalfigure>
<para>It's best to use a mirror site in place of Red Hat's <acronym>FTP</acronym> site
used in the example above.</para>
<para>It is very important not to gain files along the way. Delete
any files generated by <acronym>FTP</acronym> servers, web servers
and <acronym>CD-ROM</acronym>s.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash$</prompt> <command>cd /var/www/html/redhat</command>
<prompt>bash$</prompt> # Files added by FTP server
<prompt>bash$</prompt> <command>find . -name '.listing' -print -exec rm {} \;</command>
<prompt>bash$</prompt> <command>find . -name 'ls-*' -print -exec rm {} \;</command>
<prompt>bash$</prompt> # Files added by a wget from a HTTP server
<prompt>bash$</prompt> <command>find . -name '\?*' -print -exec rm {} \;</command>
<prompt>bash$</prompt> # Files added by a CD-ROM
<prompt>bash$</prompt> <command>find . -name 'TRANS.TBL' -print -exec rm {} \;</command></screen>
</informalfigure>
<para>We now need to add the latest updates to the distributed
software. This is done to avoid the machine being compromised
immediately following the upgrade.</para>
<para>Adding the updates is essential for <productname>Red Hat
Linux</productname> <productnumber>7.1</productnumber>, see <xref
linkend="bugs-rhl71">.</para>
<para>Collect together the updates <acronym>RPM</acronym>s from
<ulink url="ftp://ftp.redhat.com/pub/updates/7.1/en/os/"><filename
class="directory">ftp://ftp.redhat.com/pub/updates/7.1/en/os/</filename></ulink>
in the subdirectories <filename class="directory">i386</filename>,
<filename class="directory">i486</filename>, <filename
class="directory">i586</filename> <filename
class="directory">i686</filename>, <filename
class="directory">images</filename> and <filename
class="directory">noarch</filename>.</para>
<para>Merge these updates into the copy of the distribution. For
each updated <acronym>RPM</acronym> file, remove the original
<acronym>RPM</acronym> file then replace it with the updated
<acronym>RPM</acronym> file. For example:</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash$</prompt> <command>cd /var/www/html/redhat/linux/7.1/en/os/i386/RedHat/RPMS</command>
<prompt>bash$</prompt> <command>ls /var/www/html/redhat/updates/7.1/en/os/i386</command>
SysVinit-2.78-17.i386.rpm
<prompt>bash$</prompt> <command>ls SysVinit-*.rpm</command>
SysVinit-2.78-15.i386.rpm
<prompt>bash$</prompt> <command>rm SysVinit-2.78-15.i386.rpm</command>
<prompt>bash$</prompt> <command>cp /var/www/html/redhat/updates/7.1/en/os/i386/SysVinit-2.78-17.i386.rpm .</command>
<prompt>bash$</prompt> <command>chmod u=rw,g=r,o=r SysVinit-2.78-17.i386.rpm</command></screen>
</informalfigure>
<para>Merge the <acronym>RPM</acronym>s from the <filename
class="directory">updates</filename> subdirectories <filename
class="directory">i386</filename>, <filename
class="directory">i686</filename> and <filename
class="directory">noarch</filename> into <filename
class="directory">/var/www/html/redhat/linux/7.1/en/os/i386/RedHat/RPMS</filename>.
Merge the files from the directory <filename
class="directory">/var/www/html/redhat/updates/7.1/en/os/images</filename>
into the directory <filename
class="directory">/var/www/html/redhat/linux/7.1/en/os/i386/images</filename>.</para>
<para>The file
<filename>/var/www/html/redhat/linux/7.1/en/os/i386/RedHat/base/hdlist</filename>
and <filename>hdlist2</filename> contain the list of the
<acronym>RPM</acronym>s to install. This needs to be modified to
contain the names of the updated <acronym>RPM</acronym>s.</para>
<para>Install the <filename>anaconda-runtime</filename>
<acronym>RPM</acronym> on the <acronym>HTTP</acronym> server. This
<acronym>RPM</acronym> should be the same version as the Red Hat
Linux being upgraded to.</para>
<para>Now create a new <filename>hdlist</filename> with the
commands:</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash$</prompt> <command>cd /usr/lib/anaconda-runtime</command>
<prompt>bash$</prompt> <command>rm /var/www/html/redhat/linux/7.1/en/os/i386/RedHat/base/hdlist*</command>
<prompt>bash$</prompt> <command>umask 002</command>
<prompt>bash$</prompt> <command>./genhdlist &hyphen;&hyphen;withnumbers &hyphen;&hyphen;hdlist /var/www/html/redhat/linux/7.1/en/os/i386/RedHat/base/hdlist /var/www/html/redhat/linux/7.1/en/os/i386</command></screen>
</informalfigure>
<para>The distribution plus the updates can now be used for a
network install. They cannot be used for a <acronym>CD</acronym>
install, but that doesn't concern us.</para>
<para>As the distribution plus the updates is different from the
original distribution, we should not use the version number of the
original distribution. Appending the date to which the updates
have been applied seems best.</para>
<informalfigure>
<programlisting>
<prompt>bash$</prompt> <command>cd /var/www/html/redhat/linux/</command>
<prompt>bash$</prompt> <command>mv 7.1 7.1-20020202</command></programlisting>
</informalfigure>
</section> <!-- rhl-preparehttp -->
<section id="rhl-ifconfig">
<title>Record network configuration</title>
<para>If the machine does not use the Dynamic Host Configuration
Protocol then record the current network configuration. This is
used to complete the installer's <guimenu>Configure
TCP/IP</guimenu> screen.</para>
<example id="rhl-ifconfig-ifconfig">
<title>Displaying the Internet Protocol configuration</title>
<screenco>
<areaspec>
<area units="linecolumn" coords="3" id="rhl-ifconfig-ifconfig-ipaddr">
<area units="linecolumn" coords="15" id="rhl-ifconfig-ifconfig-router">
<area units="linecolumn" coords="20" id="rhl-ifconfig-ifconfig-dns">
</areaspec>
<screen format="linespecific"><prompt>bash$</prompt> <command>ifconfig eth0</command>
<computeroutput>
eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
inet addr:10.1.2.3 Bcast:10.1.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:344233 errors:0 dropped:0 overruns:0 frame:0
TX packets:285750 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0x9000</computeroutput>
<prompt>bash$</prompt> <command>netstat -r -n</command>
<computeroutput>
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.1.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 10.1.2.254 0.0.0.0 UG 40 0 0 eth0</computeroutput>
<prompt>bash$</prompt> <command>cat /etc/resolv.conf</command>
<computeroutput>
domain example.edu.au
nameserver 10.255.1.1
nameserver 10.255.2.1
nameserver 172.16.1.1</computeroutput></screen>
<calloutlist>
<callout arearefs="rhl-ifconfig-ifconfig-ipaddr">
<para>The value of <literal>inet addr</literal> is the
<quote>IP address</quote>. Our example shows
<literal>10.1.2.3</literal>. The value of
<literal>Mask</literal> is the <quote>Netmask</quote>. Our
example shows <literal>255.255.255.0</literal>.</para>
</callout>
<callout arearefs="rhl-ifconfig-ifconfig-router">
<para>The value in the Gateway column for Destination
<literal>0.0.0.0</literal> is the <quote>Default
gateway</quote>. Our example shows
<literal>10.1.2.254</literal>.</para>
</callout>
<callout arearefs="rhl-ifconfig-ifconfig-dns">
<para>The value of the first listed
<literal>nameserver</literal> is the <quote>Primary
nameserver</quote>. Our example shows
<literal>10.255.1.1</literal>.</para>
</callout>
</calloutlist>
</screenco>
</example>
</section> <!-- rhl-ifconfig -->
<section id="rhl-liloconfig">
<title>Record LILO configuration</title>
<para>Record the current value of <literal>append=</literal>,
<literal>boot=</literal> and <literal>linear</literal> in
<filename>/etc/lilo.conf</filename>.</para>
<example id="rhl-liloconfig-lilo">
<title>Displaying the <application>LILO</application>
configuration</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>fgrep append= /etc/lilo.conf</command>
<computeroutput>
append="console=tty0 console=ttyS0,9600n8"</computeroutput>
<prompt>bash#</prompt> <command>fgrep boot= /etc/lilo.conf</command>
<computeroutput>
boot=/dev/hda</computeroutput>
<prompt>bash#</prompt> <command>fgrep linear /etc/lilo.conf</command>
<prompt>bash#</prompt></screen>
</example>
<para>If the <literal>boot=</literal> parameter points to a hard
disk then <application>LILO</application> is installed in the
master boot record, or <acronym>MBR</acronym>. It can also point to
a partition.</para>
<para>If the <literal>linear</literal> parameter is present then
the hard disk that is booted from uses linear block addressing, or
<acronym>LBA</acronym>.</para>
</section> <!-- rhl-liloconfig -->
<section id="rhl-upgrade">
<title>Upgrade Red Hat distribution</title>
<para>In this section it all comes together. We will walk through
an entire serial console upgrade, not that it differs much from a
standard text mode upgrade.</para>
<para>Configure <acronym>BIOS</acronym> to boot from floppy or
insert the floppy disk. Now reboot the machine.</para>
<informalfigure>
<screen format="linespecific">
<prompt>bash#</prompt> <command>shutdown -r now</command>
<computeroutput>
SYSLINUX 1.64 1.64-pre2 Copyright (C) 1994-2001 H. Peter Anvin
Welcome to Red Hat Linux 7.1!
- To install or upgrade Red Hat Linux in graphical mode,
press the &lt;ENTER&gt; key.
- To install or upgrade Red Hat Linux in text mode, type: text &lt;ENTER&gt;.
- To enable low resolution mode, type: lowres &lt;ENTER&gt;.
Press &lt;F2&gt; for more information about low resolution mode.
- To disable framebuffer mode, type: nofb &lt;ENTER&gt;.
Press &lt;F2&gt; for more information about disabling framebuffer mode.
- To enable expert mode, type: expert &lt;ENTER&gt;.
Press &lt;F3&gt; for more information about expert mode.
- To enable rescue mode, type: linux rescue &lt;ENTER&gt;.
Press &lt;F5&gt; for more information about rescue mode.
- If you have a driver disk, type: linux dd &lt;ENTER&gt;.
- Use the function keys listed below for more information.
[F1-Main] [F2-General] [F3-Expert] [F4-Kernel] [F5-Rescue]
boot:
Loading initrd.img..............
Loading vmlinuz............. ready.
Linux version 2.4.2-2BOOT (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-79)) #1 Sun Apr 8 18:24:33 EDT 2001
</computeroutput>
</screen>
</informalfigure>
<para>Because we have booted into expert mode, the menus differ
slightly from the standard upgrade. For example, you probably
don't have a driver disk.</para>
<informalfigure>
<screen format="linespecific">
Welcome to Red Hat Linux
+----------+ Devices +-----------+
| |
| Do you have a driver disk? |
| |
| +-----+ +----+ |
| | Yes | |[No]| |
| +-----+ +----+ |
| |
+--------------------------------+</screen>
</informalfigure>
<para>The upgrade then continues in the usual fashion.</para>
<informalfigure>
<screen format="linespecific">
+--------+ Choose a Language +---------+
| |
| What language should be used during |
| the installation process? |
| |
| Czech : |
| [ English : ] |
| Danish : |
| French : |
| German : |
| Hungarian : |
| Icelandic : |
| Italian : |
| |
| +----+ |
| |[OK]| |
| +----+ |
| |
+--------------------------------------+</screen>
</informalfigure>
<para>Select <guimenuitem>HTTP</guimenuitem> to upgrade from the
web server we prepared previously.</para>
<informalfigure>
<screen format="linespecific">
+-----+ Installation Method +------+
| |
| What type of media contains the |
| packages to be installed? |
| |
| NFS image |
| FTP |
| [ HTTP ] |
| |
| +----+ +------+ |
| |[OK]| | Back | |
| +----+ +------+ |
| |
+----------------------------------+</screen>
</informalfigure>
<para>Here we supply the network details recorded in <xref
linkend="rhl-ifconfig-ifconfig">. If your network supports Dynamic
Host Configuration Protocol or the Bootstrap Protocol then these
work fine too.</para>
<informalfigure id="rhl-upgrade-ipaddr">
<screen format="linespecific">
+--------------------+ Configure TCP/IP +--------------------+
| |
| Please enter the IP configuration for this machine. Each |
| item should be entered as an IP address in dotted-decimal |
| notation (for example, 1.2.3.4). |
| |
| [ ] Use dynamic IP configuration (BOOTP/DHCP) |
| |
| IP address: 10.1.2.3________ |
| Netmask: 255.255.255.0___ |
| Default gateway (IP): 10.1.2.254______ |
| Primary nameserver: 10.255.1.1______ |
| |
| +----+ +------+ |
| |[OK]| | Back | |
| +----+ +------+ |
| |
+------------------------------------------------------------+</screen>
</informalfigure>
<para>Provide the name of the pre-prepared web server. Note that
the response to <guimenuitem>Red Hat directory</guimenuitem> must
start with a <filename class="directory">/</filename>.</para>
<informalfigure>
<screen format="linespecific">
+-----------------+ HTTP Setup +-----------------------------------+
| |
| Please enter the following information: |
| |
| o the name or IP number of your web server |
| o the directory on that server containing |
| Red Hat Linux for your architecure |
| |
| Web site name: www.example.edu.au_______________________ |
| Red Hat directory: /redhat/linux/7.1-20020202/en/os/i386____ |
| |
| +----+ +------+ |
| |[OK]| | Back | |
| +----+ +------+ |
| |
+------------------------------------------------------------------+</screen>
</informalfigure>
<para>The following status messages then fly by before the welcome
screen appears.</para>
<informalfigure>
<screen format="linespecific">
<guilabel>Retrieving base/netstg1.img...</guilabel>
<guilabel>Loading /mnt/runtime ramdisk...</guilabel>
<guilabel>Retrieving base/netstg2.img...</guilabel>
<guilabel>Loading /mnt/runtime/usr ramdisk...</guilabel>
<guilabel>Running anaconda - please wait...</guilabel>
<guilabel>Graphical installation not available for http installs. Starting text mode.</guilabel>
</screen>
<screen format="linespecific">
+----------------+ Red Hat Linux +-----------------+
| |
| Welcome to Red Hat Linux! |
| |
| This installation process is outlined in detail |
| in the Official Red Hat Linux Installation |
| Guide available from Red Hat Software. If you |
| have access to this manual, you should read the |
| installation section before continuing. |
| |
| If you have purchased Official Red Hat Linux, |
| be sure to register your purchase through our |
| web site, http://www.redhat.com/. |
| |
| +----+ +------+ |
| |[OK]| | Back | |
| +----+ +------+ |
| |
+--------------------------------------------------+</screen>
</informalfigure>
<para>Select <guimenuitem>Upgrade Existing
Installation</guimenuitem>, although this procedure works fine for
installations as well.</para>
<informalfigure>
<screen format="linespecific">
+--------------+ Installation Type +--------------+
| |
| What type of system would you like to install? |
| |
| Workstation |
| Server System |
| Laptop |
| Custom System |
| [ Upgrade Existing Installation ] |
| |
| +----+ +------+ |
| | OK | | Back | |
| +----+ +------+ |
| |
+-------------------------------------------------+</screen>
</informalfigure>
<para>The upgrade continues. When the <guimenu>LILO
Configuration</guimenu> screen appears insert the kernel parameters
recorded from <xref linkend="rhl-liloconfig-lilo">. These
parameters should include
<literal>console=ttyS&hellip;</literal>.</para>
<informalfigure>
<screen format="linespecific">
+---------------------+ LILO Configuration +---------------------+
| |
| A few systems will need to pass special options to the kernel |
| at boot time for the system to function properly. If you need |
| to pass boot options to the kernel, enter them now. If you |
| don't need any or aren't sure, leave this blank. |
| |
| [ ] Use linear mode (needed for some SCSI drives) |
| |
| console=tty0 console=ttyS0,9600n8_______________ |
| |
| +----+ +------+ +------+ |
| | OK | | Skip | | Back | |
| +----+ +------+ +------+ |
| |
+----------------------------------------------------------------+</screen>
</informalfigure>
<informalfigure>
<screen format="linespecific">
+-------------+ LILO Configuration +--------------+
| |
| Where do you want to install the bootloader? |
| |
|[/dev/hda Master Boot Record (MBR) ]|
| /dev/hda1 First sector of boot partition |
| |
| +----+ +------+ |
| | OK | | Back | |
| +----+ +------+ |
| |
+-------------------------------------------------+</screen>
</informalfigure>
<informalfigure>
<screen format="linespecific">
+----------------------+ LILO Configuration +-----------------------+
| |
| The boot manager Red Hat uses can boot other operating systems |
| as well. You need to tell me what partitions you would like to |
| be able to boot and what label you want to use for each of them. |
| |
| Device Partition type Default Boot label |
|[/dev/hda6 Linux Native * linux ] : |
| : |
| : |
| : |
| : |
| |
| +----+ +------+ +------+ |
| | Ok | | Edit | | Back | |
| +----+ +------+ +------+ |
| |
| |
+-------------------------------------------------------------------+</screen>
</informalfigure>
<para>The upgrade continues. As installing the packages may take a
few hours, you can disconnect.</para>
<informalfigure>
<screen format="linespecific">
+-------------+ Package Installation +--------------+
| |
| Name : |
| Size : |
| Summary: |
| |
| Packages Bytes Time |
| Total : 0 0M |
| Completed: 0 0M |
| Remaining: 0 0M |
| |
| |
+---------------------------------------------------+</screen>
</informalfigure>
<para>If you disconnected, then when reconnecting it is best to
press <keycap>Tab</keycap> rather than pressing
<keycap>Return</keycap>.</para>
<para>Pressing <keycap>Return</keycap> on the
<guimenu>Bootdisk</guimenu> screen writes a boot disk. This will
overwrite the upgrade disk.</para>
<para>You may wish to deliberately create a boot disk if you cannot
alter the <acronym>BIOS</acronym> parameters to boot from the hard
disk, or if you cannot wait for someone to eject the floppy disk
before rebooting.</para>
<informalfigure>
<screen format="linespecific">
+------------------+ Bootdisk +-------------------+
| |
| A custom boot disk provides a way of booting |
| into your Linux system without depending on |
| the normal bootloader. This is useful if you |
| don't want to install lilo on your system, |
| another operating system removes lilo, or lilo |
| doesn't work with your hardware configuration. |
| A custom boot disk can also be used with the |
| Red Hat rescue image, making it much easier to |
| recover from severe system failures. |
| |
| Would you like to create a boot disk for your |
| system? |
| |
| +-----+ +----+ |
| |[Yes]| | No | |
| +-----+ +----+ |
| |
+-------------------------------------------------+</screen>
</informalfigure>
<para>When the <guimenu>Complete</guimenu> screen appears prepare
to reboot into Linux. If you have a serial <acronym>BIOS</acronym>
be prepared to alter the <acronym>BIOS</acronym> parameters to boot
from the hard disk first. If you do not have a serial
<acronym>BIOS</acronym> ask someone to eject the floppy disk.</para>
<informalfigure>
<screen format="linespecific">
+-----------------+ Complete +------------------+
| |
| Congratulations, installation is complete. # |
| : |
| Press return to reboot, and be sure to : |
| remove your boot medium after the system : |
| reboots, or your system will rerun the : |
| install. For information on fixes which : |
| are available for this release of Red Hat : |
| Linux, consult the Errata available from : |
| http://www.redhat.com/errata. : |
| : |
| Information on configuring and using your : |
| Red Hat Linux system is contained in the : |
| |
| +----+ |
| |[OK]| |
| +----+ |
| |
+-----------------------------------------------+</screen>
<screen format="linespecific">
<computeroutput>sending termination signals...done
sending kill signals...done
disabling swap...
/tmp/swap/hda5
unmounting filesystems...
/mnt/sysimage/var/www/html
/mnt/sysimage/boot
/mnt/sysimage/proc
/mnt/runtime/usr
/mnt/sysimage
/proc/bus/usb
/mnt/runtime
/dev/pts
/proc
rebooting system
Restarting system.
LILO
Loading linux......................
Linux version 2.4.3-12 (root@porky.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)) #1 Fri Jun 8 15:05:56 EDT 2001</computeroutput></screen>
</informalfigure>
</section> <!-- rhboot -->
<section id="rhbootdisk">
<title>Create boot disk for serial console</title>
<para>Once the upgrade has been sucessfully done create a boot
floppy which has serial console support. This is most simply done
by creating a boot disk, as done by the
<application>anaconda</application> installer or as described in
<xref linkend="preparation-fallback">; modifying the configuration
file <filename>\SYSLINUX.CFG</filename> to configure the boot
loader to use the serial console, as described in <xref
linkend="configure-boot-loader-syslinux">; and finally configuring
the kernel to use the serial console, as described in <xref
linkend="configure-kernel-syslinux">.</para>
<para>An alternative is to create your own
<application>mkbootdisk</application> <acronym>RPM</acronym>
package containing a modified copy of the shell script
<filename>/sbin/mkbootdisk</filename>.</para>
<para>The <filename>\SYSLINUX.CFG</filename> file on the boot
floppy is written by <command>mkbootdisk</command> using the code
in <xref linkend="rhbootdisk-mkbootdisk-original">. We alter this
code to use the serial console; the result is shown in <xref
linkend="rhbootdisk-mkbootdisk-serial">.</para>
<figure id="rhbootdisk-mkbootdisk-original">
<title>Extract from Red Hat Linux 7.2
<filename>mkbootdisk</filename> which creates
<filename>SYSLINUX.CFG</filename></title>
<programlisting>
cat &gt; $MOUNTDIR/syslinux.cfg &lt;&lt;EOF
default linux
prompt 1
display boot.msg
timeout 100
label linux
kernel vmlinuz
append $INITRDARG root=$rootdev
EOF
</programlisting></figure>
<figure id="rhbootdisk-mkbootdisk-serial">
<title>Altered extract from <filename>mkbootdisk</filename>, which
creates a <filename>SYSLINUX.CFG</filename> that uses a serial
console</title>
<programlisting>
cat &gt; $MOUNTDIR/syslinux.cfg &lt;&lt;EOF
serial 0 9600
default linux
prompt 1
display boot.msg
timeout 100
label linux
kernel vmlinuz
append $INITRDARG root=$rootdev console=tty0 console=ttyS0,9600n8
EOF
</programlisting></figure>
<para>Created boot floppies will now use the serial console.</para>
<para>By far the best alternative would be the addition of
parameters to <command>mkbootdisk</command> to allow the kernel
parameters and serial port, speed and flow control to be given when
the boot floppy is created. For this enhancement request see Red
Hat Bugzilla entry <ulink
url="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=59351">59351</ulink>.</para>
</section> <!-- rhbootdisk -->
<section id="rhreferences">
<title>Further references</title>
<para>Sometimes the kernel on the installation
<acronym>CD</acronym> won't boot on the machine to be upgraded, or
the filesystem requires modules that are not present. In this case
you will need to build a new kernel and rebuild the installation
disk to use the new kernel. This is documented in the <ulink
url="http://cambuca.ldhs.cetuc.puc-rio.br/RedHat7-CDs-HowTo.html"><citetitle>RedHat7
CDs mini-HowTo</citetitle></ulink>. This is an informal HOWTO not
available through the Linux Documentation Project.</para>
<para>An older document that more fully describes an older Red Hat
distribution build process is <ulink
url="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/RedHat-CD-HOWTO.html"><citetitle>Burning
a RedHat CD HOWTO</citetitle></ulink>.</para>
</section> <!-- rhreferences -->
</appendix> <!-- rhupgrade -->
<appendix id="debian">
<title>Upgrading <productname>Debian
<acronym>GNU</acronym>/Linux</productname> from a serial
console</title>
<para>Make a boot disk and a root disk.</para>
<para>Boot the boot disk with the parameter
<literal>console=ttyS0,9600</literal>.</para>
<para>Start the install program.</para>
</appendix> <!-- debian -->
<appendix id="ts">
<title>Terminal server configuration</title>
<para>Terminal servers were originally designed for connecting
terminals to minicomputers. Each terminal would have an
<acronym>RS-232</acronym> port. The connection to the minicomputer
usually used an ethernet port. Connecting terminals would be
connected to a command line interface where they could select from a
list of predefined machines. A <application>Telnet</application>
session would then be started to that machine.</para>
<para>Over time terminal servers gained more features. For example,
modems could be connected. These initially allowed people to dial
in to the minicomputer but grew in features until most terminal
servers became routers with a great number of serial ports.</para>
<para>As well as allowing the connection of many console to a single
terminal, the terminal server can be configured with user accounts
and passwords, preventing unauthenticated access to the console
whilst still allowing the console to be reached from any
modem.</para>
<para>This remainder of this section lists the considerations when
purchasing terminal servers and the cabling pinouts and basic
software configuration needed for differing types of terminal
servers.</para>
<para>Further contributions are welcome and should be e-mailed to
the maintainer of this <citetitle>HOWTO</citetitle>.</para>
<section id="ts-buy">
<title>Considerations when buying second-hand terminal
servers</title>
<para>Internet Service Providers have been large users of terminal
servers in the past. Each modem would be connected to a terminal
server port and incoming users would be permitted to send
<acronym>IP</acronym> packets anywhere, not just to some predefined
minicomputer. Manufacturers renamed the equipment to <quote>access
servers</quote> or <quote>modem servers</quote> to reflect this new
use.</para>
<para>These access servers have been superseded by a new generation
which allows telephone trunks to be plugged directly into the
<acronym>ISP</acronym>'s router. There are no discrete modems; the
modem tones are decoded by digital signal processing chips within
the router. As a result terminal servers are currently readily
available on the second-hand market.</para>
<para>When purchasing a second-hand terminal server ensure that you
are also buying the rights to the software. Some companies license
their software and have contract terms which state that the license
cannot be resold, but has to be repurchased from the company if the
terminal server changes hands.</para>
<para>Many vendors require a current maintenance contract to obtain
software updates. These maintenance agreements can be expensive, a
common figure is 15% per annum of the manufacturer's retail price.
You may be able to source a cheaper software updates from a
third-party maintenance supplier.</para>
<para>Many older terminal servers are no longer sold or supported
by their vendors. Search the vendor's web site for <quote>end of
life</quote>.</para>
<para>Vendor support can be a particular issue when the
most-recently available software does not fit within the
<acronym>RAM</acronym> or flash memory contraints of the terminal
server you have purchased. You should check this before purchasing
a seond-hand terminal server. Upgrading flash memory can be
particularly difficult, as the <acronym>ROM</acronym> on the
motherboard may also need to be replaced with one aware of the new
flash memory's characteristics.<footnote>
<para>This is a fault with the design of flash memory. It
identifies itself with a model designator rather than with the
timings required to read and write the memory. So to load
software from flash memory the boot <acronym>ROM</acronym> must
have a table of flash memory models and
timings.</para></footnote></para>
<para>Third-party parts suppliers such as <ulink
url="http://www.kingston.com/">Kingston</ulink> or <ulink
url="http://www.memoryx.net/">MemoryX</ulink> can usually provide
dynamic <acronym>RAM</acronym> and flash memory. They cannot
usually supply <acronym>ROM</acronym>s or static
<acronym>RAM</acronym>.</para>
<para>Most old terminal servers will not support
<application>Secure Shell</application>. In this is the case
accessing the terminal server by its ethernet port is a poor idea:
when you login to the console you password will travel across the
Internet in clear text. Either dial in to the terminal server or
use a one-time password system such as the
<productname><acronym>RADIUS</acronym></productname> protocol with
<productname>S/KEY</productname> authentication.</para>
<para>An alternative to using a terminal server is to use a
multiport serial card in another <systemitem
class="osname">Linux</systemitem> system.</para>
</section> <!-- ts-buy -->
<section id="ts-cisco2511">
<title><productname>Cisco 2511</productname></title>
<para>The basic configuration for a Cisco 2511 access server is
shown in <xref linkend="ts-cisco2511-config">. A similar
configuration will work for other Cisco access servers. Cisco has
excellent documentation at its <ulink
url="http://www.cisco.com/">web site</ulink>; start by finding the
correct <citetitle>Configuration guide</citetitle>.</para>
<para>A current maintenance contract with Cisco or a reseller is
required to download software updates. This contract also includes
the provision of <acronym>ROM</acronym>s required for flash memory
upgrades. In most jurisdictions Cisco software licenses are not
transferrable, so if you purcashed the access server on the
second-hand market you will need to purchase a software license
from Cisco or a reseller.</para>
<figure id="ts-cisco2511-config">
<title>Basic configuration for <productname>Cisco
2511</productname> terminal server to <systemitem
class="osname">Linux</systemitem> <acronym>PC</acronym></title>
<programlisting>
interface Async1
description To Linux computer
ip unnumbered Loopback0
async mode interactive
no peer default ip address
line 1
location To Linux PC
session-timeout 30
no exec
login
modem InOut
terminal-type vt100
special-character-bits 8
transport preferred none
transport input telnet
telnet break-on-ip
telnet ip-on-break
stopbits 1
flowcontrol hardware
line vty 0 4
location Network
password <replaceable>PASSWORD</replaceable>
login local
terminal-type vt100
transport preferred none
transport output telnet</programlisting>
</figure> <!-- ts-cisco2511-config -->
<para>There is a <ulink
url="http://www.mcvax.org/~koen/uClinux-cisco2500/">port</ulink> of
Linux to the <productname>Cisco 2500</productname> series of
routers. At the time of writing it did not support the
asycnhronous ports on the <productname>Cisco 2511</productname>.
The attractiveness of running <systemitem class="osname">Linux</systemitem>
instead of running Cisco's <productname
class="trade">IOS</productname> is that
<systemitem class="osname">Linux</systemitem> can support <productname
class="trade">SSH</productname>. At the time of writing Cisco were
yet to release <productname>SSH</productname> on the
<productname>Cisco 2500</productname> series of routers, although a
unofficial beta version has been seen.</para>
</section> <!-- ts-cisco2511 -->
<section id="ts-maxserver">
<title>Xyplex/iTouch <productname>MAXserver
1600</productname></title>
<para>A good site for information on Xyplex terminal servers is
<ulink url="http://www.gno.org/~gdr/xyplex/"></ulink>. Cabling is
discussed at <ulink
url="http://www.conserver.com/consoles/xyplexcons.html"></ulink>.</para>
<para>The Xyplex terminal servers are now manufacturered by <ulink
url="http://www.itouchcom.com/">iTouch Communications</ulink>. A
current maintenance contract with iTouch is required to download
software updates.</para>
</section> <!-- ts-xyplex -->
<section id="ts-annex">
<title>Xylogics/Bay/Nortel <productname>Annex</productname></title>
<para>A good site for information on
<productname>Annex</productname> terminal servers is <ulink
url="http://www.ofb.net/~jheiss/annex/"></ulink>.</para>
</section> <!-- ts-annex -->
<section id="ts-pm">
<title>Livingston/Lucent <productname>Portmaster</productname></title>
<para>Firstly configure the terminal server, as shown in <xref
linkend="ts-pm-basic">. This figure uses the system name
<literal>example</literal>, with IP address 10.1.2.3, address mask
255.255.255.0, gateway address 10.1.2.254, and DNS server address
10.1.1.1. Replace these addresses with the addresses used in your
network.</para>
<figure id="ts-pm-basic">
<title>Portmaster unit configuration</title>
<screen>
<userinput>set sysname example</userinput>
<userinput>set password <replaceable>PASSWORD</replaceable></userinput>
<userinput>set ether0 address 10.1.2.3</userinput>
<userinput>set ether0 netmask 255.255.255.0</userinput>
<userinput>set ether0 broadcast high</userinput>
<userinput>set gateway 10.1.2.254</userinput>
<userinput>set namesvc dns</userinput>
<userinput>set nameserver 10.1.1.1</userinput>
<userinput>save all</userinput>
</screen>
</figure>
<para>Now configure each serial port of the terminal server, as
shown in <xref linkend="ts-pm-port">.</para>
<figure id="ts-pm-port">
<title>Portmaster port configuration</title>
<screen>
<userinput>set s0 service_device telnet 2000</userinput>
<userinput>set s0 device</userinput>
<userinput>reset s0</userinput>
<userinput>set s1 service_device telnet 2001</userinput>
<userinput>set s1 device</userinput>
<userinput>reset s1</userinput>
&hellip;
<userinput>set s29 service_device telnet 2029</userinput>
<userinput>set s29 device</userinput>
<userinput>reset s29</userinput>
<userinput>save all</userinput>
</screen>
</figure>
<para>To connect to serial port 0 enter the command <userinput>telnet
example 2000</userinput>. Use the associated TCP port number to
connect to telnet to the other serial devices.</para>
</section> <!-- ts-pm -->
</appendix> <!-- ts -->
<appendix id="advice">
<title>Gratuitous advice for developers</title>
<section id="advice-bootloader">
<title>Advice for boot loader authors</title>
<para>Serial console support in a boot loader is very useful.
Thank you for supporting it.</para>
<para>The boot loader should support the
<productnumber>8250A</productnumber> <acronym>UART</acronym> and
its programming-compatible <productnumber>82510</productnumber>,
<productnumber>16450</productnumber>,
<productnumber>16550</productnumber> and
<productnumber>16750</productnumber> descendants. The serial chip
used in the <productname>IBM PC/XT</productname>, the
<productnumber>8250</productnumber> (no A), and its
<productnumber>8250B</productnumber> descendant need not be
supported. The <productnumber>8250A</productnumber> data sheet is
<ulink
url="http://www.intersil.com/data/FN/FN2/FN2958/FN2958.pdf"><citetitle><productnumber>82C50A</productnumber>
<productname>CMOS Asynchronous Communications
Element</productname></citetitle></ulink> and is updated by Intel's
errata <ulink
url="http://support.intel.com/support/controllers/peripheral/7513.htm"><citetitle><productnumber>82510</productnumber>
PC Software Compatibility</citetitle></ulink>. The
<productnumber>16550</productnumber> data sheet is <ulink
url="http://www.national.com/ds/PC/PC16550D.pdf"><citetitle><productnumber>PC16550D</productnumber>
<productname>Universal Asynchronous Receiver/Transmitter with
FIFOs</productname></citetitle></ulink>.</para>
<para>To set the serial port and serial parameters, most
<acronym>Linux</acronym> boot loaders use a syntax modeled upon the
kernel's <literal>console</literal> parameter. It would be nice to
retain this consistency, since the user needs to learn the kernel
syntax in any case.</para>
<para>The default value should be 9600<abbrev>bps</abbrev>, 8 data
bits, no parity, 1 stop bit and
<acronym>CTS</acronym>/<acronym>RTS</acronym> flow control. This
gives the maximum interoperability with the other programs that use
the serial console.</para>
<para>Please do not ignore the lower speeds, as remote serial
console is at its most valuable when the computer is located three
days walk up a mountain in the New Guinea highlands. It is
difficult to get more than 75<abbrev>bps</abbrev> from
<acronym>HF</acronym> radio under adverse sky conditions.</para>
<para>Be conservative in your use of the modem status lines. Even
if you are ignoring incoming status (<acronym>DSR</acronym>,
<acronym>DCD</acronym>) and handshaking lines (<acronym>RTS</acronym>)
at least assert the outgoing status (<acronym>DTR</acronym>) and
handshaking (<acronym>CTS</acronym>) lines. Correctly configured
modems will not receive calls with <acronym>DTR</acronym> low, and
dropping <acronym>DTR</acronym> will cause the modem to hang
up.</para>
<para>Consider that the <acronym>BIOS</acronym> may have already
initialised the <acronym>UART</acronym> and provide a configuration
option to allow the boot loader to be informed of that. When the
boot loader initialises the <acronym>UART</acronym>,
<acronym>DTR</acronym> will fall and the line will hang up. In some
scenarios each hang up requires the satelite circuit to be
re-booked before another call can be placed. </para>
<para>Cater for line noise. Imagine the boot loader starting and
then being sent nonsensical characters every few seconds. Although
this is certainly wrong, a fault in a modem is difficult to
remotely diagnose and correct if the machine is left stranded at
the boot loader prompt. A solution is to boot the default image
upon the expiry of a timer; the boot occurring even if the user (or
line noise) has started to type. For example the boot loader
configuration could say:</para>
<informalfigure>
<programlisting>
<lineannotation># Start the machine regardless after 30 minutes
# 30 * 60 seconds per minute * units of tenths of seconds</lineannotation>
<command>lifetime 18000</command></programlisting>
</informalfigure>
<para>The default should be no life timer. The timer is also
useful in high availability applications: when a machine is used in
environments with an planned availability of 99.999% the lifetime
value should be configured to three minutes or less.</para>
<para>Check information read from the BIOS for reasonablness. For
example, if the BIOS's Extended Data Area suggests 0x000 as the
address for the serial port's registers then don't try to
initialise the registers.</para>
</section> <!-- advise-bootloader -->
<section id="advice-bios">
<title>Advice for <acronym>BIOS</acronym> authors</title>
<para>Thank you for adding support for remote operations to your
<acronym>BIOS</acronym>. A few points will maximize the benefits of
that support, most of them are listed in <xref
linkend="advice-bootloader">.</para>
<itemizedlist>
<listitem>
<para>Keep the user interface simple. There is no need for fancy
cursor-addressed terminal support. Fancy features simply limit
the number of client terminal emulators that can be used. A
surprising number of these have very buggy <acronym>DEC</acronym>
<productname>VT100</productname> implementations.</para>
<para>In addition to supporting lower speeds, also test your user
interface at low data rates.</para>
</listitem>
<listitem>
<para>Don't do too much. In <systemitem class="osname">Linux</systemitem> the
boot loader and operating system both have explicit support for a
serial console. So all the <acronym>BIOS</acronym> need do is to
support the a serial interface for itself.
<systemitem class="osname">Linux</systemitem> has no need for a generic serial
redirection facility. If you do provide such a facility for
other operating systems, please allow it to be disabled after
system boot.</para>
</listitem>
<listitem>
<para>Don't allow line noise to prevent the computer from
booting. Don't require just one key to enter the
<acronym>BIOS</acronym> configuration, make your users and your
marketing people happy by using a phrase like
<literal>dell</literal>, <literal>hp</literal> or
<literal>ibm</literal>. Copy the <literal>lifetime</literal> idea
from <xref linkend="advice-bootloader">.</para>
</listitem>
<listitem>
<para>Present a consistent prompt. Imagine a user with a
supercomputer array of five hundred <acronym>PC</acronym>s. You
want to change a <acronym>BIOS</acronym> parameter. Make it easy
for <application><ulink
url="http://expect.nist.gov/">Expect</ulink></application> to set
those parameters.</para>
</listitem>
<listitem>
<para>Make sure the <systemitem class="osname">Linux</systemitem> utilities
work. Check that the <systemitem class="osname">Linux</systemitem>
<function>nvram</function> device driver returns the full
contents of <acronym>CMOS</acronym>. This makes it simple to set
the same <acronym>CMOS</acronym> settings on a large number of
machines. The commands in <xref linkend="advice-bios-nvramget">
and <xref linkend="advice-bios-nvramset"> should work to copy the
<acronym>BIOS</acronym> settings from one machine to another, where
the make, model and <acronym>BIOS</acronym> versions of the
machines are the same.</para>
<figure id="advice-bios-nvramconfig">
<title>Configuring /dev/nvram to access the
<acronym>CMOS</acronym> configuration</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>/dev/MAKEDEV nvram</command>
<prompt>bash#</prompt> <command>vi /etc/modules.conf</command>
</screen>
<programlisting>
alias char-major-10-144 nvram
</programlisting>
<screen format="linespecific">
<prompt>bash#</prompt> <command>depmod -a</command>
</screen>
</figure>
<figure id="advice-bios-nvramget">
<title>Getting the <acronym>CMOS</acronym> configuration</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>cat /dev/nvram &gt; /etc/nvram.bin</command>
</screen>
</figure>
<figure id="advice-bios-nvramset">
<title>Setting the <acronym>CMOS</acronym> configuration</title>
<screen format="linespecific">
<prompt>bash#</prompt> <command>cat /etc/nvram.bin &gt; /dev/nvram</command>
</screen>
</figure>
</listitem>
<listitem>
<para>Have a flash <acronym>BIOS</acronym> upgrade program that
works from <systemitem class="osname">Linux</systemitem>. Make the source
code to this available. Or publish the specifications so that
one can be written.</para>
<para>Many flash <acronym>BIOS</acronym> update programs run from
a Microsoft <productname><acronym>MS-DOS</acronym></productname>
boot diskette. Please check that the program also works with the
similar <productname>Free<acronym>DOS</acronym></productname>
operating system. Many Linux computers do not have licenses for
Microsoft operating system software, so legally creating a
<productname><acronym>MS-DOS</acronym></productname> boot
diskette may not be possible.</para>
</listitem>
<listitem>
<para>Be clear in the documentation about what serial servies the
BIOS provides. Some <acronym>BIOS</acronym>s with a
<quote>serial redirection</quote> feature don't allow the
<acronym>BIOS</acronym> to be redirected to a plain text
terminal, but instead use a proprietary protocol. This isn't of
much use to <systemitem class="osname">Linux</systemitem> serial
console users.</para>
</listitem>
</itemizedlist>
</section> <!-- advice-bios -->
</appendix> <!-- advice -->
<appendix id="about">
<title>About this <citetitle>HOWTO</citetitle></title>
<section id="about-copyright">
<title>Copyright</title>
<para>The first edition of this document is copyright &copy; 2001
Mark <abbrev>F.</abbrev> Komarinski and is distributed under the
terms of the <citetitle>Linux Documentation Project
(<acronym>LDP</acronym>) License</citetitle>, see <xref
linkend="about-copyright-ldp">.</para>
<para>The revisions to this document for the second edition are
copyright &copy; AARNet Pty Ltd (Australian Company Number 084 540
518), 2001&hyphen;2003. These parts were written by Glen Turner.
He asserts his moral rights to be identified as one of the authors
of this work under the <citetitle>Copyright Act 1968 (Commonwealth
of Australia)</citetitle>. The Australian Academic and Research
Network and Glen Turner distribute these parts under the terms of
the <citetitle>Linux Documentation Project (<acronym>LDP</acronym>)
License</citetitle>, see <xref
linkend="about-copyright-ldp">.</para>
<para>This license meets the <ulink
url="http://www.debian.org/social_contract.html#guidelines">Debian
Free Software Guidelines</ulink>, so you should find this
<citetitle>HOWTO</citetitle> in the Debian package
<filename>doc-linux-html</filename>.</para>
<section id="about-copyright-ldp">
<title><citetitle>Linux Documentation Project
License</citetitle></title>
<para>Unless otherwise stated, <systemitem
class="osname">Linux</systemitem> <citetitle>HOWTO</citetitle>
documents are copyrighted by their respective authors. <systemitem
class="osname">Linux</systemitem> <citetitle>HOWTO</citetitle>
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 <systemitem class="osname">Linux</systemitem>
<citetitle>HOWTO</citetitle> documents must be covered under this
copyright notice. That is, you may not produce a derivative work
from a <citetitle>HOWTO</citetitle> and impose additional
restrictions on its distribution. Exceptions to these rules may be
granted under certain conditions; please contact the <systemitem
class="osname">Linux</systemitem> <citetitle>HOWTO</citetitle>
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 <citetitle>HOWTO</citetitle>
documents, and would like to be notified of any plans to
redistribute the <citetitle>HOWTO</citetitle>s.</para>
<para>If you have any questions, please contact
<email>linux-howto@metalab.unc.edu</email>.</para>
</section> <!-- about-copyright-ldp -->
</section> <!-- about-copyright -->
<section id="about-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> <!-- about-disclaimer -->
<section id="about-credits">
<title>Acknowledgments</title>
<para>The first edition of this <citetitle>HOWTO</citetitle> was
written by Mark Komarinski. It was based upon
<filename>/usr/src/linux/Documentation/serial-console.txt</filename>,
which was written by Miquel van Smoorenburg.</para>
<para>The second edition of this <citetitle>HOWTO</citetitle> was
written by the staff of the <ulink
url="http://www.aarnet.edu.au/">Australian Academic and Research
Network</ulink>, mainly Glen Turner and David Vu.</para>
<para>The following people have contributed to this
<citetitle>HOWTO</citetitle>. They are listed in no particular
order.</para>
<variablelist>
<varlistentry>
<term>LinuxSA mailing list</term>
<listitem>
<para>Proof reading of the Second Edition. <ulink
url="http://www.linuxsa.org.au/">LinuxSA</ulink> is a
<systemitem class="osname">Linux</systemitem> user group based
in South Australia.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>David Lawyer</term>
<listitem>
<para>Technical review of the Second Edition and recommending
the updated <citetitle>HOWTO</citetitle> to the Linux
Documentation Project. David is author of the <ulink
url="http://www.tldp.org/HOWTO/Text-Terminal-HOWTO.html"><citetitle>Text-Terminal-HOWTO</citetitle></ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Devin Reade</term>
<listitem>
<para>Xyplex terminal server information. Devin maintains
information about Xyplex terminal servers at <ulink
url="http://www.gno.org/~gdr/xyplex/"></ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Michael Brown, Marc Mondragon and other members of the
<citetitle>Linux on Dell PowerEdge</citetitle> mailing
list</term>
<listitem>
<para>Technically described how the <acronym>BIOS</acronym>
redirects characters to the serial port. The <citetitle>Linux
on Dell PowerEdge</citetitle> list can be subscribed to by
sending a message containing <literal>subscribe
linux-poweredge</literal> to
<email>linux-poweredge-request@dell.com</email>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Thomas Lunde, Gabor Kiss and Carlo Belon</term>
<listitem>
<para>Noticed errors of grammar and typography.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Darren Young</term>
<listitem>
<para>Updates to
<filename>/etc/security/console.perms</filename> for
<productname>Red Hat Linux</productname>
<productnumber>7.2</productnumber>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Yasufumi Haga</term>
<listitem>
<para>Spotted many errors whilst translating this
<citetitle>HOWTO</citetitle> into Japanese for the
<acronym>JF</acronym> Linux documentation endeavour.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Thomas Horsley</term>
<listitem>
<para>Pointed out that the <application>X Window
System</application> may still need to be running even if a
serial console is used. Supplied the <command>gdm</command>
configuration used in <xref
linkend="misc-init-x11-gdmconf">.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Greg Matthews, Nathan Neulinger and Romildo Wildgrube</term>
<listitem>
<para>Encountered and reported that machines hang when booting
if kernel parameter
<literal>console=ttyS</literal>&hellip;<literal>r</literal> is
used. This is due to a kernel bug which loops testing
<acronym>CTS</acronym> without firstly checking that
<acronym>DSR</acronym> and <acronym>DCD</acronym> are
asserted.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Shaun Karl and Keisuke Nakao</term>
<listitem>
<para>Procedures for <productname>Debian
<acronym>GNU</acronym>/Linux</productname>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Igor Sviridov</term>
<listitem>
<para>Configuration of <productname>Livingstone
Portmaster</productname> terminal server in <xref
linkend="ts-pm">.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Sue Bauer-Lee</term>
<listitem>
<para>Suggested using the <literal>off</literal> clause in
<filename>/etc/inittab</filename> in <xref
linkend="getty-mingetty-inittab"> rather than commenting or
deleting the excess <application>mingetty</application>
invocations. This has the advatage that no automated system
administration tool will restore the excess
<filename>inittab</filename> entries.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Yasuhiro Suzuki</term>
<listitem>
<para>Noticed inconsistent descrtiptions of Clear to Send and
Ready to Send.</para>
</listitem>
</varlistentry>
</variablelist>
</section> <!-- about-credits -->
<section id="about-feedback">
<title>Comments and corrections</title>
<para>The current maintainer of this <citetitle>HOWTO</citetitle>
is <author><firstname>Glen</firstname>
<surname>Turner</surname></author>. Please send corrections,
additions, comments and criticisms to
<email>glen.turner+howto@aarnet.edu.au</email>.</para>
<para>The maintainer would also appreciate e-mails from people that
have sucessfully used this <citetitle>HOWTO</citetitle> to
configure serial consoles on their machines. Please state the
version of the <citetitle>HOWTO</citetitle> you used (see the cover
page), your <systemitem class="osname">Linux</systemitem>
distribution and its version, and the number of machines involved.
This information allows the maintainer to show his employer
sufficient public benefit for his work on this
<citetitle>HOWTO</citetitle> to continue and will not be used for
any other purpose.</para>
<para><systemitem class="osname">Linux</systemitem> is continually
improving, so please send those small alterations required for the
latest version of your <systemitem
class="osname">Linux</systemitem> distribution.</para>
<para>The <citetitle>HOWTO</citetitle>'s maintainer is not a
professional writer. If you find some parts of this
<citetitle>HOWTO</citetitle> difficult to comprehend then let the
maintainer know.</para>
</section> <!-- about-feedback -->
</appendix> <!-- about -->
<colophon id="colophon">
<para>Written in DocBook 4.1 <acronym>SGML</acronym>.
<application>XEmacs</application> and the
<application><acronym>PSGML</acronym></application> package were
used to create the <acronym>SGML</acronym> source file. The
<acronym>HTML</acronym>, <productname>PostScript</productname> and
<productname><acronym>PDF</acronym></productname> output was
generated from the DocBook source by the Linux Documentation
Project.</para>
</colophon> <!-- colophon -->
</book> <!-- Remote-Serial-Console-HOWTO -->
<!-- Updating this HOWTO using CVS
# Initialise
mkdir cvs
cd cvs
export CVSROOT=:pserver:USERID@cvs.tldp.org:/cvsroot
cvs -d $CVSROOT login
cvs get LDP/howto/docbook/Remote-Serial-Console-HOWTO.sgml
# Update HOWTO, by copying local updated copy over CVS original copy
cd LDP/howto/docbook
cvs update Remote-Serial-Console-HOWTO.sgml
cp ~/Remote-Serial-Console-HOWTO.sgml Remote-Serial-Console-HOWTO.sgml
cvs ci -m 'COMMENT' Remote-Serial-Console-HOWTO.sgml
mail submit@en.tldp.org
-->
<!-- Keep this comment at the end of the file for Emacs's PSGML
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->