Terminals

Attaching terminals is one way to gain multiple access points to a Unix system. One common use for terminals is with headless servers (i.e. servers with no attached monitor or keyboard).

Terminal configuration involves these steps:

• Conecting the terminal.
• Attaching a process to the terminal to accept logins.
• Configuring the software.

Connecting the Terminal

In order to connect a terminal to a Unix system you need to find a free serial port, figure out which device file corresponds to that serial port, and obtain an appropriate serial cable. The first step is pretty self explanatory, the following two just a tad more complicated.

Each serial port has a corresponding device file in /dev through which the system passes information to the device. Unix workstations are likely to have at least one or two built in serial ports. As is typical with device files, the naming conventions for different operating systems can vary widely. The naming conventions for the four Unix flavors we are dealing with are shown in Table 4 (a plain text version is also available).

What kind of cable you use depends on what kind of connection you are trying to make. As you learned earlier, there are two configurations: DTE and DCE.

For a DTE (e.g. computer) to DCE (e.g. modem) connection, you'd use a straight-through cable where pin 1 on one end of the cable was wired to pin 1 on the other, and so on. For a DTE (e.g. computer) to DTE (e.g. terminal) connection, you'd use what's called a null-modem cable. In a null-modem cable, certain wires are crossed. Pin 2 (transmitted data) on one end is wired to pin 3 (received data) on the other and vice-versa, pin 4 (request to send) is wired to pin 5 (clear to send) and vice-versa, pin 6 (data set ready) is wired to pin 20 (data terminal ready) and vice-versa, and pin 8 (data carrier signal) is wired to pin 20 (data terminal ready) and vice-versa.

When to use which cable, and the need for the two, is often a source of confusion. It is explained very well by Central Data in their document, Central Data dte vs dce primer, <URL:http://www.cd.com:80/dtedce.html>:

Where it gets confusing is when you start to talk about signal definitions and direction. For example, it's easy for someone to understand that when you transmit data, you send it out. However, when you talk in terms of the DCE, it becomes an input. This is because the specification was written from the perspective of the DTE end of the link. Another example is that the Receive Data signal is an input to DTE, but an output from DCE.

Therefore, a straight through "one to one" cable is all that is necessary between a modem and a standard DTE serial port. However, if you want to connect two DTE ports together, you have to simulate the existence of the pair of DCE devices, typically modems, that would normally be between the two DTE devices. This is where the null-modem device or cable comes in.

If you are still confused about the difference, don't worry about it so much. For most purposes it will do just to remember that DTE to DTE connections require a null-modem cable and DTE to DCE connections require a straight-through cable.

Attaching a Login Process

Once you have the terminal connected, you need a way for people to login. You accomplish this by attaching a process to the serial port to wait for a connection and begin the login process.

One of the things that init does when a Unix system boots up is to start a process to monitor each serial port that is enabled. This process is typically getty or some similar program. The getty process sets up the serial port's characteristics and starts the login process. The complete login process is outlined below:

• getty displays the login prompt.
• The user enters their login name.
• getty spawns the login program with that user's login name.
• login prompts for a password, gets it, and checks the validity of that password in the password database.
• If the password was correct, login prints the message of the day from /etc/motd.
• login executes the user's login shell, passing along the TERM environment variable.
• When the user finishes and exits the shell, control returns to init, which spawns another getty process to monitor the terminal port.

Configuring the Software

Various files in the /etc directory control the characteristics of each terminal port, including whether a process monitors that port for logins, and the baud rate and terminal type to expect on that port. Unfortunately, these configuration files are another area where the different operating systems vary. Table 5 (a plain text version is also available) shows the files used by the different systems we are dealing with.

/etc/inittab

You have already learned about the /etc/inittab file's format and what it does in the boot procedure section of Installing the Operating System. Here we will just go over the specifics of enabling terminals in this file.

For every terminal that needs a getty process, there must be a corresponding entry in the inittab which defines the port to monitor, and the arguments to getty. Entries for terminal ports follow the same conventions that you read about earlier. Typical terminal port entries look something like this:

t2:23:off:/sbin/getty ttyd2 co_9600

The field that changes the most among the different systems we are covering is the last, the process field. We will cover how to configure this file for each system later.

/etc/ttytype

The ttytype file specifies the terminal type that will be used with each port. It's format is simple:

termtype device

device is the short name of the port's device file, and termtype is a terminal type from the system's database of terminals which is used by the program tset to initialize the TERM environment variable. A typical entry in the ttytype file looks something like this:

vt100 tty0p1

We will cover how to configure this file for each system later.

/etc/gettydefs

The gettydefs file defines port configurations which specify speed and terminal settings for use with getty. The format of a typical gettydefs is as follows:

label# initial-flags # final-flags # login-prompt #next-label

label:

The label for the entry, which getty tries to match.

initial-flags:

The flags for the initial ioctl settings of the port. These flags are set until getty executes login.

final-flags:

The ioctl flags which are set just before login executes, and remain thereafter.

login-prompt:

This field is used as the login prompt which getty provides. Tabs and newlines in backslash notation are permitted.

next-label:

The label of another entry that should be used if the user types a break character. This allows a a series of speeds to be linked together and cycled through, for instance from 38400 down to 300.

Any time you change the gettydefs file, you should issue the command getty -c /etc/gettydefs. This command scans the file and reports any entries that are not valid.

Operating System Specific Configuration

The following pages are required reading offering specific information on configuring terminals on each of the systems covered.

• HP-UX
• IRIX
• Linux
• Solaris

Terms used: ASCII, workstation, terminal, init, getty, login, Slackware, ioctl.