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 SLIP or PPP login
(discussed in Chapter 7 and Chapter 8 ) than to be used for a simple login.
Nevertheless, each of these configurations can make use of a simple
program called a getty program.
The mgetty daemon is available in source form from
ftp://alpha.greenie.net/pub/mgetty/source/,
and 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 Hayes-compatible modems. 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 4-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 4-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 DTR (Data Terminal Ready) 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
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:
