Third−Party Printer Spooling Systems

± :x:−:s5:−:n:10:−:−:Allow all connections levi:x:−:bsd:−:n:1:−:−:Local printer on PC The first entry is the default one and it allows System V remote printing fromto all hosts in the network. Sometimes it is a good idea to move out this line with the command: lpsystem −r + Removed + this is the system response The second entry is our contribution; it defines BSD printing on the remote host levi. To list current remote printing possibilities: lpsystem −l System: + Type: s5 Connection timeout: never Retry failed connections: after 10 minutes Comment: allow all connections System: levi Type: bsd Connection timeout: never Retry failed connections: after 1 minutes Comment: local printer on PC The next step is to define the remote printer: the name of the printer for users and a real printers name on the remote system. lpadmin −p local −s levidefault The new printer is identified as local the name is arbitrary, but once defined users must use it to identify this specific printer. The remote printer name default is used here to denote the default PC printer in this case there is a single printer connected to the PC. Two more steps are required to enable the defined printer. The following two commands should be executed at the end of the process: accept local enable local Please note that starting with Solaris 2.6, the lpsystem command and the etclpSystems file are becoming obsolete.

10.4.3 Third−Party Printer Spooling Systems

Generally, UNIX provides a decent printer spooling subsystem independent of the specific flavor of the given system. It works well, it is flexible enough, and it is fully supported and well documented. However, in administering it, you will soon see occasional strange printing−related behaviors, unexpected problems with printers, hangs of the printing daemon, and difficulties in maintaining printing queues. During production hours, fixing these problems can be quite painful. These problems left a market open for third parties to develop better printer spooling software, and several solutions came into being, including third−party software for example, EasySpooler by the Seay Systems, Inc. and UNIX vendor−specific optional software like HP−UX JetAdmin software. 248 From the user standpoint, the use of the printing subsystem must be completely transparent; users should not be aware of underlying printing software, they simply need to be able to print. From the administration standpoint, however, it is crucial to have a reliable, stable, and easy to maintain printing subsystem. Though there are no universal formulas to make any specific decision in creating such a subsystem, it seems that the generic UNIX printing subsystem is quite sufficient for a print client, while under some circumstances, it is worth considering third−party printer spooling software for a print server. In any case, the final decision is up to the system administrator or the administration team responsible for the actual system. 249

Chapter 11: Terminals

11.1 Terminal Characteristics

Terminals have been common devices in the communication between users and UNIX systems for a very long time. The modus vivendi for each UNIX system is to provide services to users, so from the very early days of its development, UNIX has paid full attention to terminals as vehicles for users to log into the system. Evidence of this attention can be seen in many UNIX administration issues, primarily by the fact that the system guarantees an immediate respawning of the eventually killed getty process which controls each connected terminal. A terminal connection is too valuable for UNIX to allow it to be lost; a connected terminal without an attached getty process cannot function properly, so the getty process can never die. We will discuss this topic and other terminal−related issues in this Chapter. While terminals were, in the past, the only way for the system to communicate with users, today they are used only sporadically, primarily for the system console. All major communication with users is now performed through the network. Does this mean that terminals are obsolete? Well, this statement is partially true for terminal units themselves; however, the UNIX concept of communicating with users via terminals remains. The appropriate adaptation was needed: pseudo−terminals, logical terminals that behave like real terminals without having a corresponding physical unit, replace the old terminals. We will also address pseudo−terminals in this Chapter. Terminals are connected with the computer over serial lines and are accessed, like all other devices in UNIX, by the corresponding special device files. Modems are treated in almost the same way as terminals. As with many other issues, UNIX manages terminals in two major ways; again we will address two platforms: BSD and System V or ATT. The two approaches are quite different; they rely on different configuration files, they are based on different terminal capability databases, and sometimes they use different administrative commands. On the other hand, they also overlap in many aspects, and through their development, some of the administrative commands have become common for both platforms.

11.1.1 BSD Terminal Subsystem

Although most of the UNIX flavors that support BSD terminal subsystem are old−fashioned platforms, sometimes even obsolete ones or on their way to becoming obsolete, we will start with the BSD terminal subsystem. Obsolescence is generally true for terminals as inputoutput devices, with the exception of the console. In any case, it is difficult to discuss this topic without going back to the earlier days of UNIX, when terminals were a part of every UNIX system. However, there is no doubt about the educational benefits of discussing the BSD terminal subsystem; it explains the continuity in the UNIX development and makes it easier to understand the System V approach to terminals.

11.1.1.1 BSD Terminal Line Initialization

Terminals are connected to a system via terminal lines. To make a system available to users, the terminal lines must be initialized and put into operational mode during the system startup. The terminal line initialization is a regular part of the startup procedure to bring the system into multi−user mode. Originally, on the BSD system, init, the process 1, first spawns a shell during the 250