Библиотека сайта rus-linux.net
Linux System Administrator's Survival Guide lsg11.htm
Chapter 11
Terminals and term
The most common Linux installation involves only a single screen, which is the system console that came with the PC Linux is running on. If you are running your Linux system for yourself and don't want to add another terminal to your system, your Linux configuration is complete as far as terminals are concerned and you can skip this chapter.
If, on the other hand, you want to add another PC or a terminal to your system, either for yourself to access (from another room, for example) or to provide access to Linux for others in your home or office, you need to know how to add and configure terminals. This chapter explains how to add terminals (including PC and Macintosh devices running terminal emulation software) to Linux and how to configure them. It also explains how to use the term program, which allows you to multiplex your serial lines, essentially supporting more than one device on a line.
Connecting Terminals
For the purposes of this book, the word terminal doesn't necessarily mean the old, dumb, ASCII-based terminals that many feel are remnants of days gone by. Although those machines are definitely terminals (and fully usable with Linux), modern terminals can range from inexpensive graphics-based systems to complex X workstations that have more in-built computing power than most PC machines (at a suitably hefty price). A terminal can also be any other computer (PC, Macintosh, UNIX system, Commodore 64, Amiga, and so on) that runs a terminal emulation package, which makes the machine act like a terminal.
You may want to add terminals to your system to allow other users to work with Linux at the same time you do (it is a multiuser system) or to provide access to your database of videotape movies (not to mention games) by running a terminal into your living room. If you are a parent, you can run terminals into your children's rooms, letting them use the system for education and entertainment. You may want to let friends access your system when they visit, or call in over the modem.
For whatever reason you need new terminals, you can add them to your Linux system by connecting them through an existing serial port on the back of your PC or through a multiport card with many serial ports on it.
Using Multiport Cards
Because many PC machines have a maximum of four serial ports (and the majority of systems only have two), expanding your Linux system using serial ports can be limiting. If you use an external modem, a serial printer, or other serial port devices, you may not have any serial ports left for terminals. In this case, you must use a multiport card.
Multiport cards are an easy and effective method of adding serial ports to a Linux system. Multiport cards have a plug-in board that is placed in a slot on your PC system and an oversized connector on the outer board edge to which a cable is attached. The cable either leads directly to a number of serial ports (in which case the cable is called an octopus) or to a hardware device that has serial ports laid out on it.
Multiport cards come in two basic types. The first is essentially a fast, somewhat intelligent serial port server. These cards are inexpensive because they are simple to manufacture. However, they lack any on-board processing or memory, so every device connected to the multiport card takes its toll on the Linux system's CPU and RAM.
The other type of multiport card is the intelligent controller. These cards cost much more, but have an on-board CPU to offload the Linux system's CPU. The on-board CPU can handle all the communications requests and, in some cases, is smart enough to provide terminal commands. These cards usually have RAM mounted on the board too, which provides a cache system for speeding up access. In general, these intelligent boards are much better for supporting four or more terminals and other devices than their dumber brethren, but you may be spending money on features you don't need if you have less than that number of attached devices.
Multiport cards can provide from 2 to 32 additional serial ports per card, and you can add multiple boards to the increase capacity even further, although this situation is very rare for Linux installations. A couple of manufacturers even offer systems that can support 256 terminals spread out in a cluster arrangement. Some multiport boards include parallel ports for printers, and a few high-end boards are designed to use SCSI devices.
Each port on the multiport card is usually wired for use by any serial device, including terminals, modems, printers, scanners, and so on. However, a few cards designed for simple terminal use support only a few of the wires in a serial port. These cards cannot support modems, printers, and similar complex devices properly. Different card manufacturers have different supported systems, so if you decide to go with a multiport card for your system, check the specifications carefully.
The types of connectors on multiport cards differ, too. Most use either standard DB25 25-pin connectors or DB9 9-pin connectors, identical to the ones found as PC serial ports. Some cards use the RJ45 connector, which looks like a wide modular telephone-style jack. Adapters are used to connect the RJ11 connector to a standard serial cable. Again, if you decide to use a multiport card, check the types of connectors and make sure the wiring of the connector is consistent with your serial devices or that converters and adapters are readily available.
If you are going to use a multiport card on your Linux system, make sure you use one with software device drivers that are designed for Linux. You cannot use any multiport card device driver designed for other versions of UNIX without modification. Because the drivers are usually already compiled, you cannot modify the drivers yourself. Several multiport card drivers, specially modified or written by Linux users to suit the most popular multiport cards, are available from FTP and BBS sites. As Linux becomes more popular, more multiport card vendors are developing optimized drivers for their products to integrate with Linux.
Multiport cards come with complete instructions for installing the device drivers for the multiport card, as well as configuring the terminals and other devices. Because the details of the configurations change depending on the manufacturer of the multiport card, you should consult the documentation accompanying your card for further information.
Connecting Serial Port Terminals
If you have a spare port, you can use your PC's serial ports to add terminals. In most cases, connecting the terminal is a matter of running a cable between the terminal and the serial port, and ensuring the proper connectors are used. You then update the Linux configuration files to tell the operating system to provide service for the terminal. The remote terminal should be active after this step.
You can choose any serial port for a terminal, although the port should not be shared with other devices (such as a modem) unless you are willing to disable other devices when the terminal is needed. If you need to run more than one device off a serial port, you can get switch boxes to connect the devices to. These boxes usually have a rotary switch on the front for routing the internal wiring to the proper port.
Serial port terminals are sometimes limited by the speed of the UARTs used in the PC, although most new PC machines have the faster 16550 UARTs capable of high-speed communications. Even older machines are very usable for all but graphics applications, as most character-based terminals don't need speeds above 38,400 baud. (In fact, 9600 baud is fast enough for most character-based applications, although 19,200 is better.)
Wiring Serial Cables
The wiring of cables between the terminal and the Linux PC depends on the type of connectors at both ends. The same problems usually occur whether you are using a serial port or a multiport card for your serial ports. In most cases, the cables you will use will be a DTE (Data Terminal Equipment) to DTE type. Some terminals and PC serial ports require DCE (Data Communications Equipment) cabling. As a general rule, terminals and remote computers use DTE, and modems use DCE. The difference between DTE and DCE cabling is in the way the wires run from each end connector; DTE crosses several of the wires between pins at either end.
Some store-bought cables are designed specifically for terminals and cross the internal wires as part of their connector design, and other cables are designed for modems and have wires that run straight through. If you find your terminal doesn't work even after following all the configuration instructions discussed in this chapter, chances are your cables are incorrectly wired. A null modem adapter (which forces a cross between wires) is the easiest solution, and you can add it anywhere in the chain from the terminal to the Linux PC.
A typical DCE cable (such as for a modem) uses straight through wiring, meaning that pin 1 on the PC end goes to pin 1 on the modem end, pin 2 through to pin 2, and so on. This cable is called a straight cable or modem cable.
DTE cables cross wires to allow sending and receiving ends accept signals on the same pins, so that pin 2 in a connector is always for transmit, for example, and pin 3 is always for receive. By crossing pins 2 and 3 between the two ends, one connector's transmit pin becomes the other connector's receive pin. When connecting a terminal, some of the pins must be crossed to permit signals to pass properly. The wiring of these cables (often called null modem cables) requires several such crosses or shorts to make the connection valid.
The sex of the connectors at each end of the cable is also important when buying or making a cable. Carefully note whether the connectors at each end are male (pins sticking out) or female (no pins). Usually, a PC has male serial port connectors (requiring a female end on the cable), and a terminal has female connectors (requiring a male connector on the cable), although if you are connecting a remote PC, you will need female connectors at both ends. Multiport cards differ widely in their sex and types of connectors, so check before buying cables!
Serial port connectors on a PC are either DB9 (9-pin) or DB25 (25-pin) D-shaped connectors. Not all the wires in either the 9-pin or 25-pin connector are required for a terminal. You can make a complete simple terminal cable with only three pins (send, receive, and ground), although Linux also likes to use the Carrier Detect wire to tell when a terminal is attached and active. Table 11.1 shows the important pins of 25-pin, DTE connector cables and their meanings. The pin numbers change with 9-pin connectors, but the crossings from one to another are the same.
| Terminal Pin | Computer Pin | Meaning |
| 1 | 1 | Ground |
| 2 | 3 | Transmit Data / Receive Data |
| 3 | 2 | Receive Data / Transmit Data |
| 4 | 4 | Ready to Send |
| 5 | 5 | Clear to Send |
| 6 | 20 | Data Set Ready / Data Terminal Ready |
| 7 | 7 | Ground |
| 8 | 20 | Carrier Detect / Data Terminal Ready |
| 20 | 6,8 | Data Terminal Ready / Data Set Ready, Carrier Detect |
<NOTE>If the wiring of a cable is not clearly indicated and your terminal doesn't work at all, you may need to purchase a null modem device. A null modem device is a connector that has the pin crossings within it, effectively converting a straight through cable to a null modem cable, and vice versa.<NOTE>
Understanding the Login Process
Administering a Linux system requires you to know many of the small processes involved in the kernel and device communications. One of the most important processes for users is observing a login prompt on their screens and logging in to the system successfully. Many users have no idea of the steps Linux goes through to provide a login prompt, so this section examines that process. An understanding of the login process is also necessary to know how to configure new terminals on your system, as several files must be modified to support the new devices.
init and inittab
The login process begins when the /etc/init daemon (sometimes stored in /sbin/init) is executed during the booting of the Linux system. The init process reads instructions from the file /etc/inittab and executes them in order. Usually, the init daemon is responsible for running a copy of the /etc/getty program for each terminal connected to the system. Without a getty process, the terminal and kernel can't communicate.
The init daemon knows whether a terminal is connected because of entries in the /etc/ttys and /etc/inittab files. The /etc/ttys file lists all ports on the system and the type of terminal that is connected to them. The /etc/inittab file holds a complete list of all terminals and their parameters. The section "/etc/ttys and /etc/inittab " examines these files in more detail.
When the /etc/ttys and /etc/inittab files indicate that a terminal is connected and active, the init daemon runs the /etc/getty program for that terminal. The getty program sets the communications parameters for the terminal and displays the login prompt on-screen. When a user logs in on a terminal, the getty process executes the login program to request a password. The login program validates the username and password against the entries in the /etc/passwd file.
If the login is validated properly, the login program displays the message of the day (stored in the file /etc/motd) and executes whatever the user is supposed to run as a startup program (usually a shell). As a final step, login sets the TERM environment variable, then exits.
/etc/ttys and /etc/inittab
Terminal configuration information is stored in the /etc/ttys and /etc/inittab files. The files are ASCII and can be modified by any editor, although you should be careful to keep the proper format and not disrupt existing entries. Before making any changes to the terminal configuration files, make a copy in case the changes you make are not effective and the file cannot be returned to its original state easily.
If you don't want to edit these files manually, some menu-driven programs are available that perform changes to the files for you based on a set of questions you answer. These administration utilities tend to be a little slower than editing the files manually, but they do ensure that the entries are in the proper format.
The /etc/ttys file is composed of two columns separated by any whitespace character. The first column shows the type of terminal assumed to be connected and is used to set the TERM environment variable. The second column holds the device name, less the /dev portion. A typical /etc/ttys file from a new installation of Linux looks like the following:
console tty1
console tty2
console tty3
console tty4
console tty5
console tty6
vt100 ttyp0
vt100 ttyp1
vt100 ttyp2
vt100 ttyp3
You use the /etc/inittab file to set the behavior of each terminal. The format of the /etc/inittab file follows this pattern:
ID:runlevel:action:process
The ID is a one or two character string that uniquely identifies the entry. For terminals, this string corresponds to the device name, such as 1 for tty1. The runlevel decides the capabilities of the terminal with the various states the Linux operating system can be in. Run levels vary from 0 to 6. If no entry is provided, the terminal supports all run levels. You can mention multiple run levels in the field.
The action indicates the behavior of the terminal device when the system starts and when a getty process is terminated on it. Several valid entries for the action field apply to terminals:
- once starts the process once
- ondemand always keeps the process running (the same as respawn)
- respawn always keeps the process running
A simple /etc/inittab file showing terminal startup commands (taken from an earlier version of Linux for clarity's sake, as the latest version complicates the lines a little) looks like the following:
# inittab for Linux
S1:1:respawn:/etc/getty 9600 ttyS0
S2:1:respawn:/etc/getty 9600 ttyS1
The lines indicate that a getty process should be started for ttyS0 (first COM port) and ttyS1 (second COM port) at 9600 baud and should be respawned (restarted) if the getty process terminates. You can use lines like these when you add terminals to serial ports. Multiport boards usually use commands in different files to start their getty processes.
/etc/getty and /etc/gettydefs
The /etc/getty program is referred to quite a lot when dealing with terminals. Basically, /etc/getty is a program that sets the communications parameters between Linux and a terminal, including the speed, protocol, and any special handling of the cable.
The /etc/getty program is called by /etc/init when the system boots or when the process terminates. When called, /etc/getty opens the serial port or other connection to the terminal and sets the communications parameters based on information in the file /etc/gettydefs (getty definitions). The getty process then generates the login prompt on the remote terminal. Many special handling and command options are available with the getty process, but most of them are of little interest to users and casual system administrators.
The /etc/gettydefs file supplies the settings getty uses for communications. The format of each line in the gettydefs file is as follows:
label:initial flags: final flags: login prompt: next label
you use the label to identify each line so that when /etc/getty is started with an argument (as it usually is, transparent to the user), the argument is used to match the label and provide the configuration information. You use initial flags and final flags to set any behavior for the connection before and after the login program has executed. The login prompt is the prompt to be displayed on the terminal. Usually it is just login:, but it can be any string unique to that terminal.
Finally, you use the next label to send getty to another line in case it can't use the current one. This parameter is typically used with modem lines that start at a high speed (such as 9600 baud), and then go to 4800, 2400, and 1200 in sequence, trying to connect at each step. For terminals, the next label is usually a pointer back to the line's first label.
An extract from a sample /etc/gettydefs file looks like the following:
console# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY
PARENB ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD
# B19200 OPOST ONLCR TAB3 BRKINT IGNPAR ISTRIP IXON IXANY PARENB
ECHO ECHOE ECHOK ICANON ISIG CS8 CREAD #Console Login: #console
9600H# B9600 # B9600 SANE IXANY PARENB TAB3 HUPCL #login: #4800H
4800H# B4800 # B4800 SANE IXANY PARENB TAB3 HUPCL #login: #2400H
2400H# B2400 # B2400 SANE IXANY PARENB TAB3 HUPCL #login: #1200H
1200H# B1200 # B1200 SANE IXANY PARENB TAB3 HUPCL #login: #300H
300H# B300 # B300 SANE IXANY PARENB TAB3 HUPCL #login: #9600H
If you look at the file that accompanies your Linux system, you will see that there are many more lines, but they all have the same format as the preceding examples. The easier lines to look at are the shorter ones (the last five lines in the preceding extract).
These lines are for a modem starting at 9600 baud. The initial flag is set to B9600, which sets the baud rate at 9600 baud. The final flags, used when a connection has been established, set the characteristics of the line (such as a tab meaning three spaces). Finally, the field at the end points to the next lower speed to provide checks for slower modems or poor lines that prevent fast logins.
The first lines in the preceding extract are typical for the system console. They set many initial and final flags that control how the console behaves. The reference at the end of the line is back to the same definition, as the terminal is hard-wired to the system. Terminals are defined in much the same manner, although their entries don't have to be as complex as the console's. A few simple terminal definitions are as follows:
# 38400 fixed baud Dumb Terminal entry
DT38400# B38400 CS8 CLOCAL CRTSCTS # B38400 SANE -ISTRIP CLOCAL CRTSCTS # login: #DT38400
# 19200 fixed baud Dumb Terminal entry
DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL # login: #DT19200
# 9600 baud Dumb Terminal entry
DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL # login: #DT9600
In each definition line, the baud rate is set with 8 bits (CS8) used. The flags are used to set initial behavior. The login is a simple prompt, and the end of the definition points back to the same line. These simple definitions in an /etc/gettydefs file suffice for all dumb terminals, once you select the proper speed. If you are using a terminal with more advanced capabilities, you can add those to the gettydefs file, too.
<NOTE>You may not have to change the entries in the default gettydefs file as it usually contains many different configurations. Examine the file carefully to find an entry that will work with the terminal you are using. If you do make changes to the gettydefs file, issue the command getty -c gettydefs to make the changes effective without rebooting.<NOTE>
The /etc/termcap File
The /etc/termcap file holds the instruction codes for the Linux kernel and getty to communicate with different terminals. Most terminals that are supported by the Linux operating system have an entry inside this file, so the file can be quite large. If you are going to make changes, copy a version to a safe filename first.
Each entry in the termcap file has a name or label to identify the terminal it refers to, along with several variations on the name, and then a set of codes and values for different terminal characteristics. Because terminals use many different codes for different actions, some of the more talented terminals use many codes.
An extract from a termcap file shows the definitions for two fairly simple terminals, the Wyse 30 and Wyse 85:
w0|wy30-vb|wyse30-vb|wyse 30 Visible bell:\
:vb=\E`8\E`\072\E`9:\
:tc=wy30:
wc|wy85|wyse85|Wyse 85 in 80 column mode, vt100 emulation:\
:is=\E[61"p\E[13l\E>\E[?1l\E[?3l\E[?7h\E[?16l\E[?5W:\
:co#80:li#24:am:cl=\E[;H\E[2J:bs:cm=\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\
:ce=\E[0K:cd=\E[0J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\
:ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:\
:kh=\E[H:xn:\
:im=:CO=\E[?25h:CF=\E[?25l:ic=\E[1@:dc=\E[1P:\
:dl=\E[1M:al=\E[1L:GS=\EF:GE=\EG:pt:
The meaning of each set of codes is not really of interest to most users and system administrators. You only have to start changing or rewriting terminal entries if you are adding a terminal type that does not exist in the termcap file already.
<NOTE>Most terminals offer multiple emulations. If you can't find the terminal type you need in the termcap file, look for an emulation that is supported (usually a Qume, VT, or Wyse type). It is easier to emulate a different terminal than write a termcap entry for a new type.<NOTE>
The /etc/ttys file uses the terminal characteristics in the /etc/termcap file. The first column of the ttys file gives the default terminal type used to set the TERM environment variable. The startup routine uses a pattern-matching utility to find a matching line in the termcap file, and then reads the codes that follow and uses those for all communications.
Adding a Terminal
Terminals are added to Linux in much the same manner as other devices, though the mknod command. To add a terminal, you must know name of the port to which the terminal will be connected. Linux refers to the serial ports on a PC as /dev/ttyS0 (for COM1), /dev/ttyS1 (for COM2), and so on.
Most PC systems have one or two serial ports, although up to four can be accommodated on a PC (/dev/ttyS0 to /dev/ttyS3). Linux uses the serial ports based on their addresses in the BIOS. The usual addresses for the serial ports are as follows:
| ttyS0 (COM1) | 0x03f8 |
| ttyS1 (COM2) | 0x02f8 |
| ttyS2 (COM3) | 0x03e8 |
| ttyS3 (COM4) | 0x02e8 |
If you are not sure about which serial port is which, you may have to either use a DOS-based diagnostic utility (like MS-DOS' MSD.EXE or a commercial package like Norton Utilities or Central Point Tools) or start at the lowest address and work up, testing the terminal each time. If the PC has only one port, it is almost always configured as COM1 (/dev/ttyS0). The Linux installation script usually configures the two PC serial ports, so you may only need to set the speeds and parameters for a terminal attached to a serial port. If you are using a multiport board, you will probably have to install drivers.
To create a new terminal device, you must run the mknod (make node) command to create the new device driver file, and then change the permissions on the file to let root or a root-started daemon run it. A typical command for creating a new terminal device is
mknod -m 660 /dev/ttyS0 c 4 64
where the -m 660 sets the permissions on the file, /dev/ttyS0 specifies the first serial port on the machine (COM1), the c indicates that the terminal is a character mode device (almost all terminals, except very high-speed high-end models are character devices), and the major and minor device numbers are set to 4 and 64, respectively. For the other serial ports on the PC (COM2 through COM4), the commands would be
mknod -m 660 /dev/ttyS1 c 4 65
mknod -m 660 /dev/ttyS2 c 4 66
mknod -m 660 /dev/ttyS3 c 4 67
The changes in the minor device number with the different commands above are required, although you can use any number you wish. The only requirement is that there must be a unique combination of major and minor device numbers for each terminal.
After the mknod command has been executed, you must set the device driver to the proper ownership. Issue the command
chown root.tty /dev/ttyS0
to set the ownership of /dev/ttyS0 (or whichever port you are working with) to root.tty, a special Linux ownership for the device driver files that provides the startup daemons with access.
You also need to change the entry in the /etc/ttys file to include the terminal type and device you have added so that the startup of the terminal can be performed properly. Because the /etc/inittab file already contains entries for the standard serial ports, you can edit the entry for your new terminal's port, if necessary, to set the baud rate and other parameters that may be required.
Setting Terminal Behavior with stty and tset
The stty command enables you to change and query a terminal option. The stty command is very complex, with dozens of options that modify the behavior of the terminal device driver. Luckily, only the most intense system administrators have to use the many options, so this section ignores most of the details. If you are curious, check the man page for more information.
To see the current settings of a terminal, use the stty command without any arguments or with just the device name, such as
stty /dev/ttyS1
The stty utility displays a set of parameters that indicate how the terminal is configured. You can use this information to verify that the terminal has read the configuration information properly from the /etc/inittab and /etc/gettydefs files. If the parameters don't match, check the configuration files to see whether there is a typographic error (very common) or an illegal command.
Like stty, the tset command has many options, most of which are seldom used (especially if you are not dealing with strange terminals and weird connectors). The tset command is used to initialize the terminal driver with a terminal's command set. If the tset command is given with a specific argument, it uses that. Otherwise, it uses the value defined in the TERM environment variable.
You can use tset within the startup files of a user who always logs in from a remote terminal (through a modem) to force a particular configuration, saving a few setup commands. If you put the command
tset -m dialup:vt100
in the shell startup file (.profile, .cshrc, and so on), the terminal type will be set to vt100 every time a connection is made through the modem. Of course, this command sets the terminal type even if someone isn't using a VT100 terminal. You can use the command
tset -m dialup:?vt100
to have the user connecting through the modem prompted for the terminal type. The prompt will look like the following:
TERM=(vt100)?
If the user presses Enter, the TERM variable is set to vt100. If the user doesn't want to use that value, the user can enter the correct string at the prompt.
In the examples shown so far, tset seems to be quite simple, but it has a very complex structure when dealing with hardwired terminals. To properly configure a terminal connected through a serial port, you need a command like the following:
eval `tset -s -Q -m dialup:?vt100 -m switch:z29`
The full details of this type of command are unimportant for most system administrators. If you want more information, check the man pages for tset and stty that came with your Linux system.
Resetting a Screwy Terminal
Every now and again a terminal connected through a serial port starts acting screwy, either not showing a prompt or generating garbage. There are two quick ways to try to reset the terminal. If they don't work, you should shut down the terminal and restart it. (You may have to kill the processes that were running on the terminal.)
The first approach is to issue a set of Ctrl+J characters on the screwy terminal, and then type stty sane followed by another Ctrl+J. The command stty sane should reset the terminal characteristics to normal (rereading the terminal characteristics from the configuration files). You probably won't see the letters you are typing, so enter them carefully. If you make a mistake, start the process again with a couple of Ctrl+Js. If the terminal isn't behaving at this point, type reset and press Enter or Ctrl+J. If this action doesn't work, you should reset the terminal manually.
Often, a problem with a terminal is not with the Linux software but the terminal itself. You can easily cure this type of problem by turning off the terminal, waiting a few seconds, and then turning it back on. If the problem was a terminal character code, the terminal should behave immediately. If it doesn't, check the processes running on the main Linux machine; there may be a hung process or runaway routine. You can kill the processes for that terminal and restart it.
Using term
The term program, which was developed by Michael O'Reilly, is included with many versions of Linux and is readily available on FTP and BBS sites. This program enables you to multiplex your serial lines so that you can support more than one device on a line. You can, for example, use the same serial port to control both a terminal (including an X terminal) and a modem simultaneously. The general process for working with term is to log in to a remote machine normally, run the term program on the remote, and then run term locally. Once the two term processes are properly talking, you can use the same line for your terminal and modem sessions, transferring files while you continue to move around the remote filesystem.
Although term shares many of the features of more complex TCP/IP protocols such as PPP and SLIP, it is unique in that it requires no kernel drivers. The term program functions by essentially making your serial port into a service port, much as SLIP and PPP do. The program manages the connection requests coming into the serial port and can maintain multiple processes through that port. The machine on which the serial port is based, called the server, can talk to other machines or peripherals (the clients) through the serial port protocol term imposes.
Installing term
Most Linux distributions include a compiled version of the term utility, so you don't have to compile the program. If you have only source code, you must compile it using the make utility. Each distribution supplies instructions for compiling term. Several versions of term are currently available, and each version has slightly different compilation processes and requirements. Check the documentation carefully before you begin the compilation.
The term system requires you to set a number of environment variables. Because any system user can run term, these variables should be defined for each user in the user's startup files. If the root login wants to use term, the environment variables must be defined in the root startup files. The environment variables that are important to term are as follows:
- The TERMDIR variable defines the directory term uses as its home directory (usually your home directory).
- The TERMSHARE variable defines the directory to be used when term is in shared mode (usually the same directory as TERMDIR).
- The TERMMODE variable indicates whether term should run in private or shared mode.
<NOTE>For versions of term prior to 1.16, only the TERMDIR environment variable is necessary because these versions do not support private and shared mode.<NOTE>
The commands needed to set the environment variables differ depending on the shell you use. The TERMDIR variable is usually set to your home directory, so it is defined in the following manner for the C shell or compatible (including tcsh) in the .cshrc or .login file:
setenv TERMDIR $HOME
In the Bourne and Korn shells (and their compatible shells), this variable is defined in the .profile file using the following lines:
TERMDIR=$HOME
export TERMDIR
You can explicitly define the directories if you want, as in the following example:
setenv TERMDIR /usr/tparker/termdir
If you are running a version of term later than 1.15, term supports shared and private usage. Define the TERMMODE variable in the same startup location as the TERMDIR command. For the C shell and compatible shells, use the following line if you want to run in private mode:
setenv TERMMODE 0
For the Bourne and Korn shells (and compatibles), you can set term to run in private mode with the following lines:
TERMMODE=0
export TERMMODE
If you want to run in shared mode, set the TERMMODE variable to a value of 1, and define the TERMSHARE variable to show where the shared directory is, as in the following examples for the C shell:
senenv TERMDIR /usr/tparker/term
setenv TERMMODE 1
setenv TERMSHARE $TERMDIR
The following commands are examples for the Bourne and Korn shells:
TERMDIR=/usr/tparker/term
TERMMODE=1
TERMSHARE=$TERMDIR
export TERMDIR TERMMODE TERMSHARE
Versions of term later than 2.0.0 also have an environment variable called TERMSERVER that must be defined when there is more than one modem and the modems can be used simultaneously. This variable tells term which modem line to use for which connection name. The variable is defined with the name of the connection. Suppose you were setting up three modems and three connections (called conn1, conn2, and conn3) for the C shell. You would add the following line to the startup file to tell term to use Conn1 for its connection:
setenv TERMSERVER Conn1
For the Bourne and Korn shell, you would use the following commands:
TERMSERVER=Conn1
export TERMSERVER
When the term command is started in these cases, the connection name must be specified as well. For example, with the above configuration information, you would start term with the command:
nohup term -v /dev/modem1 Conn1 &
This command line applies only to those systems with multiple modem connections using term.
Testing term
After you add the term environment variables to the startup files (and you have logged out and back in to make the changes effective), you can test the term daemon and its configuration. The term program uses a daemon running in the user's memory space to manage the simultaneous demands placed on a serial port.
A test program is included with most versions of term. If the test utility is not compiled and you have a C compiler present on your system, you can compile the program with the following command:
make term
In some distributions of Linux, the test program is already compiled. If you don't have a compiled version or a compiler, you can either search the BBSs and FTP sites for a compiled copy, or skip the testing step and start the term program (hoping for the best while you do so).
When the test program is available, run it at the command line by typing the utility's name (you should be in the directory term resides in to avoid confusion with the shell test command):
./test
When test starts, issue the following command to test the upload capability:
tupload ./test /tmp
This command places a copy of the test utility in the /tmp directory.
All local output from the term program is stored in the file local.log, and the remote output is stored in the file remote.log. You can examine these files if you run into problems or want to check the status of a session. You can force debugging information to these files by starting term with the following option:
-d255
This option is handy if you have been experiencing problems and want to see the log of all transactions.
Another utility supplied with the term package is linecheck, which is useful for testing the transparency of a connection. The linecheck utility sends each of the possible 256 ASCII characters (8-bit characters, of course) over the link and verifies that they are transferred properly.
To use linecheck, you should be connected to a remote terminal using any communications package you want, such as kermit (see the procedure for using term explained in the next section). Once you have established the connection between remote and local sites, switch to the remote machine and issue the following command:
linecheck linecheck.logfile
This command places all output of the linecheck utility in the file linecheck.logfile in the current directory on the remote system.
Then switch back to your local system and escape from the terminal mode. If you stay in terminal mode, the terminal software will misinterpret many of the characters linecheck generates. After you escape from terminal mode, issue the following command:
linecheck linecheck.logfile > /dev/modem < /dev/modem
This command tells linecheck to save results in the file linecheck.logfile (in your current directory on the local system) and take all input from the modem port and send all output to the modem port.
When the linecheck utility has terminated, examine the file linecheck.logfile on both the local and remote systems. There may be a set of numbers at the bottom of the file that linecheck has determined your system can't transfer. These numbers must be specified in the term startup file called termrc in order to prevent future problems.
For example, if the linecheck utility determines that it cannot send the character with ASCII value 200 from the local to remote system, but that this value transfers properly from the remote system to the local system, place the following line in your local system's termrc file:
escape 200
On the remote system, you must add the following line to tell the remote to ignore that ASCII value:
ignore 200
For each escape command on one system, there should be a matching ignore command on the other!
There will probably be several characters that can't be handled both ways, primarily because some of the valid ASCII characters are reserved by the communications software as escape characters to get you between modes.
If you can't get proper output from the linecheck utility, the XON/XOFF protocol is probably getting in the way. You can disable this command and rerun the linecheck utility with the following command:
linecheck linecheck.logfile 17 19 > /dev/modem < /dev/modem
Running term
The term utility is started both on the remote system and on the local systems, which means you must have copies of it properly configured both locally and remotely. Because you will want to transfer files with term, it is best to run in 8-bit mode. Start up your communications software and make sure your serial ports are set for 8-bit characters.
To use term, log in to the remote system and start up term. A useful command syntax to start term is the following:
exec term -l $HOME/termlog -s 38400 -c off -w 10 -t 150
Although this command line may seem like a lot to type, it includes the most useful term options. You can place it in a script file or alias it (with shells that allow aliasing) to make starting the term process easier.
Use the exec command to replace the currently running shell version on the remote with term. If you don't use exec, you leave your shell running on the remote machine, which ties up memory and process time for nothing. If you are in the process of debugging a term connection or want to terminate term at some point during your session, don't use the exec command in front of term.
The -l option specifies a log file for errors. In this case, all error messages are saved in the home directory in the file termlog. You can leave off the entire option if your term session is behaving properly and switch it on only after you have encountered a problem.
The -s option specifies the speed at which to run the connection. This speed should match the speed of the modem with any on-the-fly compression systems active. For example, 38400 baud is usually possible on most 14.4kbps modems that use compression. If the speed rate is set too fast, you may lose characters. Slow down the connection if necessary. Note that most PC machines require a 16550 UART for speeds higher than 9600 baud.
The -c option turns off data compression built into term. Because this command line represents a 14.4kpbs modem with inherent compression, the term compression is turned off to prevent double compression, which doesn't gain anything for performance. If your modem speed is 9600 baud or slower with no inherent compression, use the -c on option instead to active the term compression algorithm. Compression must match at both ends of the connection.
The -w and -t options are used to optimize a fast link over a 14.4kbps (or faster) modem. They set the transmission sliding window and timeout parameters. Usually, these settings are fine and need not be altered.
After establishing the remote term session, escape from your communications software to a local session and start term on your local machine with the following command:
term -r -l $HOME/logfile -c off -s 38400 -w 10 -t 150 < /dev/modem > /dev/modem &
The options mean the same thing as they did for the remote process. You must add the -r option on one end of the connection, or term will instantly die. This option sets one end of the connection as the server and the other as a client. As shown in the above example, you can run the entire command (which is best saved in a script or alias) in the background, which enables you to use the terminal window for other things. The term program executes without any problem in the background.
Now term should be functioning properly. If you experience problems, examine the log files or run the test and linecheck utilities to isolate the problem. If the connection works but is very slow, check the log files to see whether they contain timeout messages. If they do, double check the configuration because that is the most likely source of problems.
The connection may seem a little jumpy (characters coming in bursts), but that is normal, especially when compression is active. For most purposes, the term session is much slower than a normal login to a remote. The real advantage to term is when you are transferring files at the same time you are moving about on the remote system.
To terminate term, you can force a fast destruction of the connection by killing the process on both ends. A better approach, which properly closes the connection, is to issue the following command:
echo '00000' > /dev/modem
As long as the string you send has five zeros, the connection will close properly. Some versions of term include the command tshutdown, which closes the term session for you. Check the distribution software. If your term version is 1.14 or higher, tshutdown should work.
Using term with X
You can use the term utility from within an X terminal window. X (or XFree86 with most versions of Linux) enables you to open a window specifically to run term. Most of the X connection handling is with a utility called txconn. You must execute the txconn program on the remote machine (connected over a network, as X doesn't work with any reasonable degree of speed over a modem) and place it in the background as a daemon. When txconn goes to the background, it returns a message containing a display number that identifies the process:
Xconn bound to screen 11
When you connect to the remote txconn daemon from an X window, you use this number to identify the screen. You identify the screen by using the DISPLAY environment variable. If the binding was to screen 11, as shown in the preceding message, you would set the variable to
setenv DISPLAY remotename:11
where remotename is the name of the remote machine (for the C shell). With the Bourne or Korn shell, you set the same environment variable with the following commands:
DISPLAY=remotename:11
export DISPLAY
When the term client is started in the local X window, it will connect to screen 11 on the remote machine. Because txconn knows about screen 11 on the remote, all X instructions will be transferred to the local machine's X window.
<NOTE>If txconn doesn't allow you to connect or you get permission messages, you may have to issue the command xhost + on your local machine to allow the remote to open and control a window on your local session. This form of the xhost command allows any remote machine to access your windows. If you want to be sure only the remote server can open windows, use its machine name in place of the plus sign, such as xhost merlin. Alternatively, use the xauth command to control access. See the xauth man page for more information.<NOTE>
You can run the local machine with windows opening on the remote system's X session using txconn, but a better approach is to use the tredir command, which is covered in the "Using term Utilities " section.
Running X sessions over a modem using txconn is possible, although the high amount of traffic X involves can bring even the fastest modem to a crawl. A local area network connection has enough speed to sustain X window traffic. A low-overhead version of X called LBX is available for some platforms that may help solve the overhead problem for modems. Also useful is a utility called sxpc, which compresses X protocol packets for transmission over modems. You can get sxpc with some versions of term, and it has worked well with 14.4kbps and higher speed modems, although performance is predictably slow.
Using term Utilities
The term software comes with a number of utility commands for handling file transfers. The utilities vary depending on the version of term. All these utilities require a term link to be established and functioning before you can use them.
The utilities that generally accompany term are the following:
- The fet utility is a front end to term that automates many of the startup functions. This utility is not available with many older versions of term.
- The tmon utility is a monitoring utility that shows a time histogram for transmitted and received characters.
- The trdate utility sets the time on the local machine to match that of the remote machine. This utility must be executed as root.
- The trdated utility is a daemon version of trdate that can be started in rc.local to update the time every five minutes.
- The tredir utility allows networking services to be performed over term. See the description later in this section for more information.
- The trsh utility is a remote shell similar to Berkeley's rsh. When used without arguments, trsh spawns an interactive shell o the remote system. When an argument is given, the argument is executed on the remote system.
- The tupload utility transfers a file to the opposite end of the connection. By default, current directories at each end are assumed. The tupload file is given relative to the local system (sending a file from the local to remote system, for example). To transfer from the remote to the local machines, use the trsh command to go into the remote and issue a tupload command there. If you want to change the directory for an upload, you must give the destination as a second argument. For example, to transfer the file bigfile to /usr/tmp to the other end of the connections, issue the following command:
tupload bigfile /usr/tmp
The tredir utility is a powerful tool and can be used to good advantage with term. The tredir program runs as a daemon in background and provides port services (much like other networking daemons). The tredir daemon monitors ports and forwards requests from the term remote. The tredir daemon redirects network services over the term link. The tredir system works with modems and over networks.
To show how tredir works, suppose you want to redirect a local serial port to the Telnet port on a remote machine (ports are assigned for specific protocols and services). To redirect local port number 2024 to remote port 23 (the Telnet port on the remote machine), issue the following command:
tredir 2024 23
Now whenever you use port 2024 on the local machine, it is redirected to the Telnet port on the remote. To connect to the local port 2024, you could use the telnet command. The following output shows that you access the remote Telnet port when you issue the telnet command from the shell prompt (the remote machine's name in this example is brutus):
$telnet localhost 2024
Trying 147.92.142.1
Connecting to brutus...
login:
So you have redirected the Telnet session, but what good is this action in the normal course of events? It is quite useful when you want to redirect output to machines for reading e-mail, news, databases, accessing the Internet, and so on. Suppose you have a corporate e-mail server. You could use tredir to set up a direct link to the server's Telnet port, and then easily access that machine directly from your local machine without worrying about protocols, windows, and so on.
One sneaky way of using tredir is to open X windows on a remote machine from your local machine. This technique relies on the fact that X uses a set of ports for protocol communications. An X server software package waits for instructions on a port number given by the following formula
port=6000+display_number
where displaynumber is the number of the window on the X session. For example, X window number 8 listens for instructions on port 6008.
If you want to open a window from your local X session on a remote X server, you can use these port numbers and tredir. The process involves mapping a local window onto an unused window on the server. For example, the command
tredir 6008 brutus:6004
establishes a redirection between the local X window identified by port 6008 (which is on your local machine) to the remote X window given by port 6004 (the remote machine's name is brutus in this example). Do not use 6000 as a port number because it is the root console of all X sessions. Instead, pick a higher number.
After you issue the tredir command, establish your DISPLAY variable to point to the port that is being remapped on your local machine:
setenv DISPLAY localname:8
This C shell command sets your display default to the local machine's window number eight (which is remapped through tredir). Of course, you should put your machine's name in the command.
Finally, when you issue the xterm command on your local machine, it should open a window on the remote machine for you. If this command doesn't work, it's because of restrictions on the remote machine. Run the xhost + command when logged in as root to solve the problem, or use the xauth command to establish your machine as authorized to open windows.
Finally, some term-friendly utilities are available in Linux FTP sites, including versions of FTP, Telnet, and Mosaic. Check with the local distribution software sets, as well as FTP and BBS sites to find out which utilities have been modified to work with term if you plan to use term as a primary utility.
Summary
Although few systems will have terminals hanging off them, running several terminals from a single PC is a great way to share the resources of your system. It makes it very handy when two or more people want access, especially for games!
This chapter has shown you the basics of handing terminals with the Linux system. The information presented applies to most versions of Linux, although there may be some slight changes in options and arguments as the different utilities are enhanced or streamlined. If you want more information about any of the commands mentioned in this chapter, refer to the man pages and other documentation that came with Linux.
The term package is a powerful, easy-to-use utility that lets you simplify many file transfer and remote session actions when you can access a remote Linux machine also running term. Once you have set the environment variables term requires, it operates quickly and easily. Check for new releases of the term package periodically; the authors and other programmers are always adding new features and software utilities.
