Contributed by Sean Kelly <kelly@plutotech.com> 28 July 1996
Terminals provide a convenient and low-cost way to access the power of 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 some 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 a 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.
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 graphic 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.
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.
To connect a terminal to your FreeBSD system, you need the right kind of cable and a serial port to which to connect it. This section tells you what to do. If you are already familiar with your terminal and the cable it requires, skip to Configuration.
Because terminals use serial ports, you need to use serial---also known as RS-232C---cables to connect the terminal to the FreeBSD system.
There are a couple of kinds of serial cables. Which one you'll use depends on the terminal you want to connect:
If you are connecting a personal computer to act as a terminal, use a null-modem cable. A null-modem cable connects two computers or terminals together.
If you have an actual terminal, your best source of information on what cable to use is the documentation that accompanied the terminal. If you do not have the documentation, then try a null-modem cable. If that does not work, then try a standard cable.
Also, the serial port on both the terminal and your FreeBSD system must have connectors that will fit the cable you are using.
A null-modem cable passes some signals straight through, like ``signal ground,'' but switches other signals. For example, the ``send data'' pin on one end goes to the ``receive data'' pin on the other end.
If you like making your own cables, here is a table showing a recommended way to construct a null-modem cable for use with terminals. This table shows the RS-232C signal names and the pin numbers on a DB-25 connector.
| Signal | Pin # | Pin # | Signal | |
|---|---|---|---|---|
| TxD | 2 | connects to | 3 | RxD |
| RxD | 3 | connects to | 2 | TxD |
| DTR | 20 | connects to | 6 | DSR |
| DSR | 6 | connects to | 20 | DTR |
| SG | 7 | connects to | 7 | SG |
| DCD | 8 | connects to | 4 | RTS |
| RTS | 4 | 5 | CTS | |
| CTS | 5 | connects to | 8 | DCD |
Note: For DCD to RTS, connect pins 4 to 5 internally in the connector hood, and then to pin 8 in the remote hood.
A standard serial cable passes all the RS-232C signals straight-through. That is, the ``send data'' pin on one end of the cable goes to the ``send data'' pin on the other end. This is the type of cable to connect a modem to your FreeBSD system, and the type of cable needed for some terminals.
Serial ports are the devices through which data is transferred between the FreeBSD host computer and the terminal. This section describes the kinds of ports that exist and how they are addressed in FreeBSD.
Several kinds of serial ports exist. Before you purchase or construct a cable, you need to make sure it will fit the ports on your terminal and on the FreeBSD system.
Most terminals will have DB25 ports. Personal computers, including PCs running FreeBSD, will have DB25 or DB9 ports. If you have a multiport serial card for your PC, you may have RJ-12 or RJ-45 ports.
See the documentation that accompanied the hardware for specifications on the kind of port in use. A visual inspection of the port often works, too.
In FreeBSD, you access each serial port through an entry in the /dev directory. There are two different kinds of entries:
Callin ports are named /dev/ttydX where X is the port number, starting from zero. Generally, you use the callin port for terminals. Callin ports require that the serial line assert the data carrier detect (DCD) signal to work.
Callout ports are named /dev/cuaaX. You usually do not use the callout port for terminals, just for modems. You may use the callout port if the serial cable or the terminal does not support the carrier detect signal.
See the sio(4) manual page for more information.
If you have connected a terminal to the first serial port (COM1 in DOS parlance), then you want to use /dev/ttyd0 to refer to the terminal. If it is on the second serial port (also known as COM2), it is /dev/ttyd1, and so forth.
Note that you may have to configure your kernel to support each serial port, especially if you have a multiport serial card. See Configuring the FreeBSD Kernel for more information.
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.
In a nutshell, you need to tell the init process, which is responsible for process control and initialization, to start a getty process, which is responsible for reading a login name and starting the login program.
To do so, you have to edit the /etc/ttys file. First, use the su command to become root. Then, make the following changes to /etc/ttys:
Add an 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 document 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 remaining sections detail how to do these steps. We will use a running example throughout these sections to illustrate what we need to do. In our example, we will connect two terminals to the system: a Wyse-50 and a 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).
For more information on the /etc/ttys file, see the ttys(5) manual page.
First, you need to add an entry to the /etc/ttys file, unless one is already there.
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 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.
When you installed your FreeBSD system, the /etc/ttys file included entries for the first four serial ports: ttyd0 through ttyd3. If you are attaching a terminal on one of those ports, you do not need to add an entry.
In our example, we attached a Wyse-50 to the second serial port, ttyd1, which is already in the file. We need to add an entry for the 286 PC connected to the sixth serial port. Here is an excerpt of the /etc/ttys file after we add the new entry:
ttyd1 "/usr/libexec/getty std.9600" unknown off secure
ttyd5
Next, we need to specify what program will be run to handle the logins on a terminal. For FreeBSD, the standard program to do that is /usr/libexec/getty. It is what provides the login: prompt.
The program getty takes one (optional) parameter on its command line, the getty type. A getty type tells about 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 manual page gettytab(5) 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. Here is the /etc/ttys file so far (showing just the two terminals in which we are interested):
ttyd1 "/usr/libexec/getty std.38400" unknown off secure
ttyd5 "/usr/libexec/getty std.19200"
Note that the second field---where we specify what program to run---appears in quotes. This is important, otherwise the type argument to getty might be interpreted as the next field.
The third field in the /etc/ttys file lists the default terminal type for the port. For dialup ports, you typically put unknown or dialup in this field because users may dial up with practically any kind of terminal or software. For hardwired terminals, the terminal type does not change, so you can put a real terminal type in this field.
Users will usually use the tset program in their .login or .profile files to check the terminal type and prompt for one if necessary. By setting a terminal type in the /etc/ttys file, users can forego such prompting.
To find out what terminal types FreeBSD supports, see the file /usr/share/misc/termcap. It lists about 600 terminal types. You can add more if you wish. See the termcap(5) manual page for information.
In our example, the Wyse-50 is a Wyse-50 type of terminal (although it can emulate others, we will leave it in Wyse-50 mode). The 286 PC is running Procomm which will be set to emulate a VT-100. Here are the pertinent yet unfinished entries from the /etc/ttys file:
ttyd1 "/usr/libexec/getty std.38400" wy50 off secure
ttyd5 "/usr/libexec/getty std.19200" vt100
The next field in /etc/ttys, the fourth field, tells whether to enable the port. Putting on here will have the init process start the program in the second field, getty, which will prompt for a login. If you put off in the fourth field, there will be no getty, and hence no logins on the port.
So, naturally, you want an on in this field. Here again is the /etc/ttys file. We have turned each port on.
ttyd1 "/usr/libexec/getty std.38400" wy50 on secure
ttyd5 "/usr/libexec/getty std.19200" vt100 on
We have arrived at the last field (well, almost: there is an optional window specifier, but we will ignore that). The last field tells whether the port is secure.
What does ``secure'' mean?
It means that the root account (or any account with a user ID of 0) may login on the port. Insecure ports do not allow root to login.
How do you use secure and insecure ports?
By marking a port as insecure, the terminal to which it is connected will not allow root to login. People who know the root password to your FreeBSD system will first have to login using a regular user account. To gain superuser privileges, they will then have to use the su command.
Because of this, you will have two records to help track down possible compromises of root privileges: both the login and the su command make records in the system log (and logins are also recorded in the wtmp file).
By marking a port as secure, the terminal will allow root in. People who know the root password will just login as root. You will not have the potentially useful login and su command records.
Which should you use?
Just use ``insecure.'' Use ``insecure'' even for terminals not in public user areas or behind locked doors. It is quite easy to login and use su if you need superuser privileges.
Here finally are the completed entries in the /etc/ttys file, with comments added to describe where the terminals are:
ttyd1 "/usr/libexec/getty std.38400" wy50 on insecure # Kitchen
ttyd5 "/usr/libexec/getty std.19200" vt100 on insecure # Guest bathroom
When you boot FreeBSD, the first process, init, will read the /etc/ttys file and start the programs listed for each enabled port to prompt for logins.
After you edit /etc/ttys, you do not want to have to reboot your system to get init to see the changes. So, init will reread /etc/ttys if it receives a SIGHUP (hangup) signal.
So, after you have saved your changes to /etc/ttys, send SIGHUP to init by typing:
# kill -HUP 1
(The init process always has process ID 1.)
If everything is set up correctly, all cables are in place, and the terminals are powered up, you should see login prompts. Your terminals are ready for their first logins!
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. Type
#
ps -axww|grep getty
to get a list of running getty
processes. You should see an entry for the terminal.
For example, the display
22189 d1 Is+ 0:00.03 /usr/libexec/getty std.38400 ttyd1
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. Make sure you have run kill -HUP 1.
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.
Switch the terminal (or the terminal emulation software) from ``half duplex'' or ``local echo'' to ``full duplex.''