Terminals provide a convenient and low-cost way to access your FreeBSD system when you
are not at the computer's console or on a connected network. This section describes how
to use terminals with FreeBSD.
The original UNIX® systems did not have consoles.
Instead, people logged in and ran programs through terminals that were connected to the
computer's serial ports. It is quite similar to using a modem and terminal software to
dial into a remote system to do text-only work.
Today's PCs have consoles capable of high quality graphics, but the ability to
establish a login session on a serial port still exists in nearly every UNIX style operating system today; FreeBSD is no exception. By
using a terminal attached to an unused serial port, you can log in and run any text
program that you would normally run on the console or in an xterm window in the X Window System.
For the business user, you can attach many terminals to a FreeBSD system and place
them on your employees' desktops. For a home user, a spare computer such as an older IBM
PC or a Macintosh® can be a terminal wired into a more
powerful computer running FreeBSD. You can turn what might otherwise be a single-user
computer into a powerful multiple user system.
Dumb terminals are specialized pieces of hardware that let you connect to computers
over serial lines. They are called “dumb” because they have only enough
computational power to display, send, and receive text. You cannot run any programs on
them. It is the computer to which you connect them that has all the power to run text
editors, compilers, email, games, and so forth.
There are hundreds of kinds of dumb terminals made by many manufacturers, including
Digital Equipment Corporation's VT-100 and Wyse's WY-75. Just about any kind will work
with FreeBSD. Some high-end terminals can even display graphics, but only certain
software packages can take advantage of these advanced features.
Dumb terminals are popular in work environments where workers do not need access to
graphical applications such as those provided by the X Window System.
If a dumb terminal has just enough ability to
display, send, and receive text, then certainly any spare personal computer can be a dumb
terminal. All you need is the proper cable and some terminal emulation software to run on the computer.
Such a configuration is popular in homes. For example, if your spouse is busy working
on your FreeBSD system's console, you can do some text-only work at the same time from a
less powerful personal computer hooked up as a terminal to the FreeBSD system.
There are at least two utilities in the base-system of FreeBSD that can be used to
work through a serial connection: cu(1) and tip(1).
To connect from a client system that runs FreeBSD to the serial connection of another
system, you can use:
#cu -l serial-port-device
Where “serial-port-device” is the name of a special device file denoting a
serial port of your system. These device files are called /dev/cuadN.
The “N”-part of a device name is the serial port number.
Note: Note that device numbers in FreeBSD start from zero and not one (like
they do, for instance in MS-DOS®-derived systems).
This means that what MS-DOS-based systems call COM1 is usually /dev/cuad0 in
FreeBSD.
Note: Some people prefer to use other programs, available through the Ports
Collection. The Ports include quite a few utilities which can work in ways similar to cu(1) and tip(1), i.e. comms/minicom.
X terminals are the most sophisticated kind of terminal available. Instead of
connecting to a serial port, they usually connect to a network like Ethernet. Instead of
being relegated to text-only applications, they can display any X application.
We introduce X terminals just for the sake of completeness. However, this chapter does
not cover setup, configuration, or
use of X terminals.
This section describes what you need to configure on your FreeBSD system to enable a
login session on a terminal. It assumes you have already configured your kernel to
support the serial port to which the terminal is connected--and that you have connected
it.
Recall from Chapter 12 that the init
process is responsible for all process control and initialization at system startup. One
of the tasks performed by init is to read the /etc/ttys file and start a getty process
on the available terminals. The getty process is responsible for
reading a login name and starting the login program.
Thus, to configure terminals for your FreeBSD system the following steps should be
taken as root:
Add a line to /etc/ttys for the entry in the /dev directory for the serial port if it is not already there.
Specify that /usr/libexec/getty be run on the port, and
specify the appropriate getty type from the /etc/gettytab file.
Specify the default terminal type.
Set the port to “on.”
Specify whether the port should be “secure.”
Force init to reread the /etc/ttys
file.
As an optional step, you may wish to create a custom getty type for use in step 2 by making an entry in /etc/gettytab. This chapter does not explain how to do so; you are
encouraged to see the gettytab(5) and the getty(8) manual pages
for more information.
The /etc/ttys file lists all of the ports on your FreeBSD
system where you want to allow logins. For example, the first virtual console ttyv0 has an entry in this file. You can log in on the console
using this entry. This file also contains entries for the other virtual consoles, serial
ports, and pseudo-ttys. For a hardwired terminal, just list the serial port's /dev entry without the /dev part (for
example, /dev/ttyv0 would be listed as ttyv0).
A default FreeBSD install includes an /etc/ttys file with
support for the first four serial ports: ttyd0 through ttyd3. If you are attaching a terminal to one of those ports, you
do not need to add another entry.
Example 24-1. Adding Terminal Entries to /etc/ttys
Suppose we would like to connect two terminals to the system: a Wyse-50 and an old 286
IBM PC running Procomm terminal software emulating a VT-100
terminal. We connect the Wyse to the second serial port and the 286 to the sixth serial
port (a port on a multiport serial card). The corresponding entries in the /etc/ttys file would look like this:
ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure
The first field normally specifies the name of the terminal special file as it is
found in /dev.
The second field is the command to execute for this line, which is usually getty(8). getty initializes and opens the line, sets the speed, prompts for a
user name and then executes the login(1) program.
The getty program accepts one (optional) parameter on its
command line, the getty type. A getty type configures characteristics on the terminal
line, like bps rate and parity. The getty program reads these
characteristics from the file /etc/gettytab.
The file /etc/gettytab contains lots of entries for terminal
lines both old and new. In almost all cases, the entries that start with the text std will work for hardwired terminals. These entries ignore parity.
There is a std entry for each bps rate from 110 to 115200. Of
course, you can add your own entries to this file. The gettytab(5) manual
page provides more information.
When setting the getty type in the /etc/ttys file, make sure that the communications settings on the
terminal match.
For our example, the Wyse-50 uses no parity and connects at 38400 bps. The
286 PC uses no parity and connects at 19200 bps.
The third field is the type of terminal usually connected to that tty line. For
dial-up ports, unknown or dialup is
typically used in this field since users may dial up with practically any type of
terminal or software. For hardwired terminals, the terminal type does not change, so you
can put a real terminal type from the termcap(5) database
file in this field.
For our example, the Wyse-50 uses the real terminal type while the 286 PC running Procomm will be set to emulate at VT-100.
The fourth field specifies if the port should be enabled. Putting on here will have the init process start
the program in the second field, getty. If you put off in this field, there will be no getty,
and hence no logins on the port.
The final field is used to specify whether the port is secure. Marking a port as
secure means that you trust it enough to allow the root account
(or any account with a user ID of 0) to login from that port. Insecure ports do not allow
root logins. On an insecure port, users must login from
unprivileged accounts and then use su(1) or a similar
mechanism to gain superuser privileges.
It is highly recommended that you use “insecure” even for terminals that
are behind locked doors. It is quite easy to login and use su if
you need superuser privileges.
After making the necessary changes to the /etc/ttys file you
should send a SIGHUP (hangup) signal to the init process to
force it to re-read its configuration file. For example:
#kill -HUP 1
Note:init is always the first process run on a
system, therefore it will always have PID 1.
If everything is set up correctly, all cables are in place, and the terminals are
powered up, then a getty process should be running on each
terminal and you should see login prompts on your terminals at this point.
Even with the most meticulous attention to detail, something could still go wrong
while setting up a terminal. Here is a list of symptoms and some suggested fixes.
Make sure the terminal is plugged in and powered up. If it is a personal computer
acting as a terminal, make sure it is running terminal emulation software on the correct
serial port.
Make sure the cable is connected firmly to both the terminal and the FreeBSD computer.
Make sure it is the right kind of cable.
Make sure the terminal and FreeBSD agree on the bps rate and parity settings. If you
have a video display terminal, make sure the contrast and brightness controls are turned
up. If it is a printing terminal, make sure paper and ink are in good supply.
Make sure that a getty process is running and serving the
terminal. For example, to get a list of running getty processes
with ps, type:
#ps -axww|grep getty
You should see an entry for the terminal. For example, the following display shows
that a getty is running on the second serial port ttyd1 and is using the std.38400 entry
in /etc/gettytab:
If no getty process is running, make sure you have enabled
the port in /etc/ttys. Also remember to run kill -HUP 1 after modifying the ttys
file.
If the getty process is running but the terminal still does
not display a login prompt, or if it displays a prompt but will not allow you to type,
your terminal or cable may not support hardware handshaking. Try changing the entry in
/etc/ttys from std.38400 to 3wire.38400 (remember to run kill -HUP 1
after modifying /etc/ttys). The 3wire
entry is similar to std, but ignores hardware handshaking. You
may need to reduce the baud rate or enable software flow control when using 3wire to prevent buffer overflows.
Make sure the terminal and FreeBSD agree on the bps rate and parity settings. Check
the getty processes to make sure the correct getty type is in use. If not, edit /etc/ttys and run kill -HUP 1.
