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(R) 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(R) 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(R) 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.
For FreeBSD, there are three kinds of terminals:
The remaining subsections describe each kind.
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/cuaaN
for FreeBSD versions older than 6.0, and
/dev/cuadN
for 6.0 and later versions.
The "N"-part of a device name is the serial port number.
Uwaga:
Note that device numbers in FreeBSD start from zero and not
one (like they do, for instance in MS-DOS(R)-derived systems).
This means that what MS-DOS(R)-based systems
call "COM1" is
usually /dev/cuad0 in FreeBSD.
Uwaga:
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 Rozdział 12, The FreeBSD Booting Process 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/ttysfor the entry in the/devdirectory for the serial port if it is not already there.Specify that
/usr/libexec/gettybe run on the port, and specify the appropriategettytype from the/etc/gettytabfile.Specify the default terminal type.
Set the port to "on."
Specify whether the port should be "secure."
Force
initto reread the/etc/ttysfile.
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.
/etc/ttysSuppose 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:
ttyd1ttyd5 "/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
|
| The second field is the command to execute for
this line, which is usually getty(8).
The The file When setting the 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,
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 |
| 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
It is highly recommended that you use
"insecure"
even for terminals that are behind locked doors. It
is quite easy to login and use |
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
Uwaga:
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:
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1
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.