Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

3.4. Serial Devices and the login: Prompt

It was once very common that a Unix
installation involved one server machine and many
"dumb" character mode terminals or
dial-up modems. Today that sort of installation is less common, which
is good news for many people interested in operating this way,
because the "dumb" terminals are
now very cheap to acquire. Dial-up modem configurations are no less
common, but these days they would probably be used to support a PPP
login (discussed in Chapter 6) rather than a simple login. Nevertheless,
each of these configurations can make use of a simple program called
a getty program.

The term getty is
probably a contraction of "get
tty." A getty program opens a
serial device, configures it appropriately, optionally configures a
modem, and waits for a connection to be made. An active connection on
a serial device is usually indicated by the Data Carrier
Detect (DCD) pin on the serial device being raised. When a
connection is detected, the getty program issues
a login: prompt, and then invokes the login
program to handle the actual system login. Each of the virtual
terminals (e.g., /dev/tty1) in Linux has a getty
running against it.

There are a number of different getty
implementations, each designed to suit some configurations better
than others. The getty that we'll describe here is
called mgetty, which is quite popular because it has all sorts of
features that make it especially modem-friendly, including support
for automatic fax programs and voice modems. We'll
concentrate on configuring mgetty to answer conventional data calls
and leave the rest for you to explore at your convenience.

3.4.1. Configuring the mgetty Daemon

The
mgetty daemon is available in just about all
Linux distributions in prepackaged form. The
mgetty daemon differs from most other getty
implementations in that it has been designed specifically for modems
with the AT command set.

It still
supports direct terminal connections but is best suited for dialup
applications. Rather than using the DCD line to detect an incoming
call, it listens for the RING message generated by
modern modems when they detect an incoming call and are not
configured for auto-answer.

The main executable program is called
/usr/sbin/mgetty, and its main configuration
file is called /etc/mgetty/mgetty.config. There
are a number of other binary programs and configuration files that
cover other mgetty features.

For most installations, configuration is a matter of editing the
/etc/mgetty/ mgetty.config
file and adding appropriate entries to the
/etc/inittab file to execute
mgetty automatically.

Example 3-6 shows a very simple
mgetty configuration file. This example
configures two serial devices. The first,
/dev/ttyS0, supports a Hayes-compatible modem at
38,400 bps. The second, /dev/ttyS0, supports a
directly connected VT100 terminal at 19,200 bps.

Example 3-6. Sample /etc/mgetty/mgetty.config file

#
# mgetty configuration file
#
# this is a sample configuration file, see mgetty.info for details
#
# comment lines start with a "#", empty lines are ignored
#
# ----- global section -----
#
# In this section, you put the global defaults, per-port stuff is below
#
# access the modem(s) with 38400 bps
speed 38400
#
# set the global debug level to "4" (default from policy.h)
debug 4
#
# ----- port specific section -----
# 
# Here you can put things that are valid only for one line, not the others
#
#
# Hayes modem connected to ttyS0: don't do fax, less logging
#
port ttyS0
debug 3
data-only y
#
# direct connection of a VT100 terminal which doesn't like DTR drops
#
port ttyS1
direct y
speed 19200
toggle-dtr n
#

The configuration file supports global
and port-specific options. In our example we used a global option to
set the speed to 38,400 bps. This value is inherited by the ttyS0
port. Ports we apply mgetty to use this speed
setting unless it is overwritten by a port-specific speed setting, as
we have done in the ttyS1 configuration.

The debug keyword
controls the verbosity of mgetty logging. The
data-only keyword in the ttyS0 configuration
causes mgetty to ignore any modem fax features, to operate just as a
data modem. The direct keyword in the ttyS1
configuration instructs mgetty not to attempt
any modem initialization on the port. Finally, the
toggle-dtr keyword instructs
mgetty not to attempt to hang up the line by
dropping the Data Terminal Ready (DTR) pin on
the serial interface; some terminals don't like this
to happen.

You can also choose to leave the mgetty.config
file empty and use command-line arguments to specify most
of the same parameters. The documentation accompanying the
application includes a complete description of the
mgetty configuration file parameters and
command-line arguments. See the following example.

We need to add two entries to the
/etc/inittab file to activate this
configuration. The inittab file is the
configuration file of the Unix System V init
command. The init command is responsible for
system initialization; it provides a means of automatically executing
programs at boot time and re-executing them when they terminate. This
is ideal for the goals of running a getty program.

T0:23:respawn:/sbin/mgetty ttyS0
T1:23:respawn:/sbin/mgetty ttyS1

Each
line of the /etc/inittab file contains four
fields, separated by colons. The first field is an identifier that
uniquely labels an entry in the file; traditionally it is two
characters, but modern versions allow four. The second field is the
list of run levels at which this entry should be active. A run level
is a means of providing alternate machine configurations and is
generally implemented using trees of startup scripts stored in
directories called /etc/rc1.d,
/etc/rc2.d, etc. This feature is typically
implemented very simply, and you should model your entries on others
in the file or refer to your system documentation for more
information. The third field describes when to take action. For the
purposes of running a getty program, this field should be set to
respawn, meaning that the command should be
re-executed automatically when it dies. There are several other
options, as well, but they are not useful for our purposes here. The
fourth field is the actual command to execute; this is where we
specify the mgetty command and any arguments we
wish to pass it. In our simple example we're
starting and restarting mgetty whenever the
system is operating at either of run levels two or three, and are
supplying as an argument just the name of the device we wish it to
use. The mgetty command assumes the
/dev/, so we don't need to
supply it.

This chapter was a quick introduction to mgetty
and how to offer login prompts to serial devices. You can find more
extensive information in the Serial HOWTO.

After you've edited the configuration files, you
need to reload init to make the changes take effect. Simply send a
hangup signal to the init process; it always has a process ID of one,
so you can use the following command safely:

# kill -HUP 1