UNIX Unleashed, System Administrator's Edition
- 23 -
Central to the system administrator's responsibilities is the provision to users of access to the distributed and shared resources belonging to their environment. Some of the resources are software (for example, applications, the file system, and so on), whereas others are hardware such as terminals, modems, printers, and so on. Other chapters will address the issues and concerns pertaining to the administration of software resources; this chapter addresses issues pertaining to the administration and management of hardware resources (that is, devices). Namely, you will be presented with the skills necessary to set up, configure, and maintain the performance of modems, terminals, printers, x terminals, and PCs.
For the purposes of terminal, modem, and printer setup UNIX SVR4 comes with a very powerful and central access facility known as Service Access Facility (SAF). No treatment of device administration under SVR4 is complete without covering SAF. Neither is it possible for the system administrator to complete the aforementioned tasks successfully without a rigorous understanding of what SAF is all about, and the skillful use of its associated commands. Hence, SAF will be presented first. Next, device administration using SAF will be covered next.
BSD UNIX is lacking in providing a unifying interface, such as SAF, for device administration. Concepts, tools, and skills needed in setting up and administering devices under BSD will be covered, in a separate section, in the context of the described tasks.
Following is a list of the major topics that this chapter covers:
Service Access Facility Under SVR4
Prior to System V release 4 of UNIX, administrators were provided with different processes and interfaces, along with their associated tools, to manage different physical resources on the system. Local port access used to be administered and controlled by interfaces that are different from those needed to set up for network access, or those pertaining to printer setup and so on. Administrators were therefore confronted with the challenge of learning and mastering the many different skills and interfaces needed to get the job done. To alleviate this challenge, SAF was introduced with SVR4. SAF provides a commonly applicable interface for the purpose of comprehensive and uniform management of all system resources. Upon mastering the concepts and associated commands that SAF provides, the administrator will be able to install, configure, monitor, and maintain information relevant to the local and network access to physical port services in SAF database files.
SAF consists primarily of port services, port monitors, the service access controller (sac) process, and SAF Administrative Files and Commands
A description of each of these components will be provided. Then the SAF initialization process will be detailed.
SAF defines a hierarchy of port control processes, of which port service is the lowest and the most "intimate" to the actual physical services. A port service is defined as a process that controls and monitors access to applications and other services, through physical ports such as ttys and TCP/IP. A tty service may provide users with dial-in/dial-out capabilities, thus allowing them to utilize high-level applications such as uucp, cu, and login. A TCP/IP port-related service may be required to provide printing, rlogin, or nfs services across the network.
There is a one-to-one association between physical ports (the actual physical service) and port services (the controlling process). It is not possible, for example, for two ttys to share the same port service; neither is it possible for one tty port to be controlled by more than one port service.
Upon creation of a port service, the system administrator assigns it a service name, which is referred to as the service tag. Service tags are used to conveniently distinguish between the port services running on the system. Port services are supported and controlled by intermediate-level processes called port monitors, which are described next.
A port monitor is an intermediate level process that controls a set of related services. SAF currently recognizes two types of port monitors: ttymon and listen. However SAF is not limited to those two types. Vendors and system programmers are provided with a well-defined network programming interface, to enable them to write their own monitor types.
Port monitor type ttymon controls and monitors tty-related port services, thus replacing pre-SVR4 getty and uugetty programs. Although maintaining support to uugetty and getty processes in SVR4 for reasons of backward compatibility, ttymon is the preferred method of installing, configuring, and monitoring tty port services in SVR4. Port monitor type listen, on the other hand, takes advantage of TCP/IP communications protocols to provide across-the-network services mentioned earlier, such as network printing and remote file-sharing capabilities. Both port monitor types will be comprehensively explained in the upcoming sections.
System administrators are allowed the flexibility to create as many port monitors of any type as they deem necessary. Upon creation of a port monitor, a so-called port monitor tag has to be assigned to it. As in the case of port services, port monitor tags are names that help in distinguishing between port monitors. They can be given convenient names that may describe the nature of the service they support. Being a mid-level process, port monitors themselves are invoked, controlled, and monitored by the service access controller (sac) process.
Service Access Controller
The service access controller process is the highest in SAF hierarchy. There is only one sac per system. It invokes and controls all port monitors, irrespective of type, which have been created and configured by the system administrator. sac is a program that is spawned by init upon system startup when multiuser mode is entered. When SVR4 is installed, an entry supporting sac is automatically included in the /etc/inittab file. A depiction of how this entry should look is as follows:
sc:234:respawn:/usr/lib/saf/sac -t 300
Due to the -t 300 option, sac routinely checks port monitors every 300 seconds for services. In order to change it to any other different value, enter
#sacadm -t <seconds>
SAF Administrative Commands and Files
SAF distinguishes between sac-specific, port monitor-specific, and port service-specific administrative and configuration files as well as administrative commands. In this section, administrative and configuration files and SAF-related commands will be described. The emphasis will be on their nature and the job they do. Command syntax and utilization for the purposes of creating, configuring, or checking the status of port monitors and port services will be left until later sections where they'll be discussed at length in the context of tasks to accomplish.
Service Access Controller Specific Files and Commands
Once brought up, sac fetches two files. Those files are as follows: 1) /etc/saf/_sactab, which is the administrative database that contains entries pertaining to port monitors defined by the system administrator, and 2) the /etc/saf/_sysconfig file, which is a sac-specific configuration file. Whereas sac uses the first file to identify the port monitors to invoke, it uses the second one in order to self-customize its own environment. Contents of /etc/saf/_sactab can be modified by the sacadm command, which is sac's administrative command. Using sacadm allows administrators to create port monitors, check their status, and enable or disable them as well as remove them. Also, each port monitor provides an administrative command that can be used with sacadm in command substitution mode. The listen port monitor administrative command is nlsadmin, whereas ttymon's is ttyadm.
/etc/saf/_sysconfig file, on the other hand, is a file that would be used by sac to specify the environment governing all the services controlled by it. The sac program, once started by init, reads and interprets this file prior to the invocation of any service defined by /etc/saf/_sactab. There can optionally be one _sysconfig file per system, and it can be edited using vi or any other UNIX editor.
Port Monitor Specific Files and Commands
When a port monitor is created using sacadm, an /etc/saf/<pmtag> directory will be created where port-specific files are maintained. Of prime interest are 1) /etc/saf/<pmtag>/_pmtab, and 2) /etc/saf/<pmtag>/_config. If, for example, you create a port monitor, which you assign a tag called ttyserv, the directory called /etc/saf/ttyserv will be created in which the administrative file called /etc/saf/ttyserv/_config will be maintained. This file is similar to the /etc/saf/_sactab in its functionality, as it is used by the port monitor to determine and bring up the port services as defined by the system administrator. /etc/saf/<pmtag>/_pmtab is a one-per-port monitor file and is modified using the pmadm command whether creating, deleting, or modifying the status of any of the associated port services. The /etc/saf/<pmtag>/_config is an optional port monitor specific configuration file that can be created by the system administrator using vi. Commands in this file can add to, or override, those found in the system configuration file _sysconfig. Before starting a port monitor defined in /etc/saf/_sactab file, sac checks the port monitors' respective directory, described previously, for the _config file. If found, _config is read and interpreted by sac to customize the port monitor's environment, and then the port monitor is started.
Port Service-Specific Files and Commands
Being at the bottom of the SAF hierarchy, port services have no administrative files associated with it. The system administrator, however, has the option to create a port service-specific configuration script named after the service tag and kept in the associated port monitor's directory. So if, for example, a port service was created under port monitor ttyserv and was given the service tag ttylogin1, then the port service configuration file is named ttylogin1 and is kept in the /etc/saf/ttyserv directory. The complete filename thus becomes /etc/saf/ttyserv/ttylogin1. This file is read and interpreted by the controlling port monitor before starting the port service. Configuration commands included in the file may override or add to those found in the _config port monitor's file or _sysconfig that are associated with this service.
Table 23.1 summarizes what has been discussed so far and provides you with a quick way to narrow down the files and commands associated with each SAF component.
Table 23.1. Administrative files and commands associated with each of the SAF components.
SAF Initialization Process
Figure 23.1 shows a flow chart summarizing the SAF initialization process. Note how it all starts with init invoking sac after reading a sac-associated entry in the /etc/inittab file. Once sac is started, it proceeds as follows:
sac checks for the /etc/saf/_sysconfig configuration file. If found, it reads the file in order to self-customize its environment. This environment is a global one that, unless otherwise modified or overridden, will govern all defined SAF services.
sac determines which port monitors to invoke by reading the /etc/saf/_sactab file. For each port monitor, sac checks for the associated /etc/saf/<pmtag>/_config file. If one exists, the sac process reads, interprets, and implements the contents and customizes the port monitor's environment, irrespective of any earlier associated settings defined in _sysconfig files. The port monitor is then invoked.
Once invoked, the port monitor determines which port services to start by reading its /etc/saf/<pmtag>/_pmtab file. Next, the port monitor checks for the optional /etc/saf/<pmtag>/<svctag> corresponding to each port service. If one exists, it is read and interpreted to customize the port service environment. The port service is then invoked.
After the initialization process is completed, sac continues to poll the port monitors at regular intervals as defined by the -t option in the corresponding entry in the /etc/inittab file. Port monitors failing to respond to this polling process prompt sac into respawning them.
SAF Administration and Management
This section introduces some of the concepts and skills pertaining to SAF management and administration. Because those skills commonly apply to all types of port monitors and their associated port services, the discussion will focus on how to accomplish each of the following tasks described, with little emphasis on the nature of the service being rendered to the user. SAF management and administration is a two-level system: one level applies to port monitors, whereas the other applies to port services. This section is therefore presented in two parts.
Port Monitor Administration and Management As explained earlier in this chapter, for an administrator to offer port services, be it across the network or local to the system, he or she must first create the port monitor supporting it. Only then can port services be created and released to the user community. There are also troubleshooting instances when the administrator may need to check on the status of suspect port monitors or even temporarily disable them.
Creating a Port Monitor Port monitors are administered and managed using the sacadm administrative command. In addition to sacadm, each port monitor type provides for an administrative command that is commonly used with sacadm in "command substitution mode." ttyadm is ttymon's command, whereas nlsadmin is listen's. To create a port monitor, sacadm must be entered along with the following options:
#sacadm -a -p<pmtag> -t<type> -c"<pm_cmd>" -v ver [-fd|x] \ [-n <count>] [-y"comment"]
where: -a stands for add or create a port monitor.
-p <pmtag> assigns the port monitor being created a name, which can be conveniently used to distinguish it from other port monitors. Although the name can be anything you choose, it should be descriptive of the type of service with which it is associated.
-t <type> specifies the type of monitor to create (that is, ttymon versus listen).
-c "<pm_cmd>" specifies the command to invoke when the port monitor is later spawned by sac: /usr/lib/saf/ttymon to invoke a ttymon port monitor, or /usr/lib/saf/listen to invoke a listen port monitor.
-v ver specifies the version of the port monitor. The version may more conveniently be provided by invoking the port monitor's specific administrative command (ttyadm or nlsadmin) with the -V option in command substitution form (that is, as an argument to -v). In this case, the -V option would be typed as follows:
# sacadm -a ... -v'ttyadm -V' ...
-f [d|x] specifies the status of the port monitor upon invocation, with d meaning to start the port monitor in disabled state and x meaning not to start it. If flagged x, the port monitor can only be started by the system administrator. There onward, sac takes over in controlling the port monitor.
-n<count> specifies the retry count used by the port monitor in restarting a failing port monitor. If not included, the default that applies is zero.
-y "comment" can be any comment that you may want to include in the /etc/saf/_sactab file. For your convenience, you may want to include a comment describing what this port monitor is for.
When a port monitor is created, the following happens: 1) An entry in sac's administrative file /etc/saf/_sactab is added pertaining to the port monitor, including all of the arguments provided on the command line. 2) The port monitor's supporting directory /etc/saf/<pmtag> is also created. As a matter of fact, another directory, /var/saf/<pmtag>, will also be created where a port monitor log file is maintained. The filename is /var/saf/<pmtag/log. It is used by sac to log all messages pertaining to the port monitor.
For a better feel for what has been said so far, take a look at an example of creating a port monitor. This example will be carried over to upcoming sections to demonstrate aspects of managing the port monitor. In this example it is assumed that the system administrator wants to allow users local logins to the system, using serial communications. Hence, the first task is to create the port monitor in preparation for creating the necessary associated port services.
Due to the nature of the service (that is, serial communication), the port monitor has to be of a ttymon type. The system administrator has chosen to assign the port monitor the tag ttyserv, start it in the disabled state, and include a comment saying "only two logins." Upon failure, sac should attempt restarting the monitor twice. The sacadm command should therefore look like this:
#sacadm -a -p serial -t ttymon -v 'ttyadm -V' \ -c"/usr/lib/saf/ttymon" -fd -n 2 -y "only two logins"
Next, you'll be learning how to check on the status of the port monitor. For the time being, however, we can carry a check using cat to look up the contents of sac's /etc/saf/_sactab file. cat /etc/saf/_sactab should reveal the following entry:
ttyserv:ttymon:d:2:/usr/lib/saf/ttymon #only two logins
and if you enter ls -l /etc/saf, you will be able to verify that the subdirectory is ttyserv. ttyserv (the subdirectory) is created among others existing at /etc/saf level. Reflecting back on the _sactab entry shown previously, you should have guessed how each field in /etc/saf/_sactab file maps to arguments you enter on the command line. The first field refers to the pmtag, the second to the port monitor type, the third to the state in which the port monitor is started (disable state, in this example). The fourth mandates that two restarts be attempted should the port monitor fail, and the fifth specifies the complete path- name of the command to invoke. Note also that the comment is included as well.
Checking the Status of the Port Monitor To check on the status of the port monitor, use the sacadm command with -l option among the others as follows:
If you enter sacadm -pttyserv -l to check on the port monitor just created in the preceding example, you get the following output:
PMTAG PMTYPE FLGS RCNT STATUS COMMAND ttyserv ttymon d 2 DISABLED /usr/lib/saf/ttymon #only two logins
Note that the status field indicates that the port monitor is in a disabled state. If you check the status immediately after the port monitor is created, the status field may indicate that it is STARTING.
The port monitor can be in one of the following states:
Enabling, Disabling, and Removing a Port Monitor To enable, disable, or remove a port monitor, use sacadm -e, sacadm -d, or sacadm -r, respectively. To enable the ttyserv port monitor, enter
# sacadm -pttyserv -e
whereas to disable it, enter
# sacadm -pttyserv -d
and to remove it, enter
# sacadm -pttyserv -r
Port Service Administration and Management Only after the port monitor is created is the system administrator in a position to create and manage the associated port services. Port creation and administration is achievable via the pmadm command.
Creating a Port Service To create a port service, pmadm should be used with the -a option, among the others as follows:
# pmadm -a -p<pmtag> -s<svctag> -m"pmspecific" \ -v ver [-fx|u] -y"comment"
in which -a stands for create a port service.
-p<pmtag> specifies the tag of the port monitor to which the port service belongs.
-s<svctag> specifies the service tag assigned to the port service.
-m"<pmspecific>" specifies port-specific information to be passed as an argument to the pmadm command. Normally, this information is generated by employing either ttyadm or nlsadmin in command substitution mode, depending on the type of the port monitor specified with the -p option.
-v <ver> passes the version of the port monitor. Depending on the type of the port monitor, either ttymon -V or nlsadmin -V can be used in command substitution mode.
-f specifies the state with which the port service should be started, and whether a utmp entry is to be created. Both or any of the flags can be specified, where d specifies that the port should be started in disabled state, and u specifies that a utmp entry be created for the service.
The following example adds a ttymon port service to the ttyserv port monitor created earlier in this section:
#pmadm -a -pttyserv -s s01 -v 'ttyadm -C' -fd \ -m "'ttyadm -d /dev/term/01 -l 9600 -s/usr/bin/login \ -p"Welcome To UNIX, Please Login:"'"
The port service thus created is assigned service tag s01 and added to a port monitor called ttyserv (the one created in the earlier section). s01 port is associated with /dev/term/01 device file (that is, COM2 on an Intel 386/486 machine. -l 9600 refers to a record in a terminal line setting database file (/etc/ttydefs), which, when used by the port, sets the line speed. The other settings are described in a subsequent section. When s01 port is invoked by the ttyserv port monitor, it is going to write a prompt ("Welcome to UNIX, Please Login:" according to the preceding example) to the terminal connected to the COM2 port. It starts monitoring the port until it receives a request to connect. Upon receiving the prompt, it invokes /usr/bin/login to take care of the request.
When a port service is created, the /etc/saf/<pmtag>/_pmtab is modified to include an entry pertaining to the service. Hence, in the preceding example, an entry pertaining to s01 must be present in the /etc/saf/ttyserv/_pmtab. You can display it either by using cat or the pmadm command as described in the next section.
Listing and Checking the Status of a Port Service To list and check on the status of a port monitor, enter
#pmadm -l -p<pmtag> -s<svctag>
To list or check on the status of all port services associated with a specific port monitor, enter
#pmadm -l -p<pmtag>
whereas to list, or check, the status of all port monitor services, enter
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> ttymon3 ttymon 00s u root /dev/term/00s - - /usr/bin/ _login - 2400 - login: - # ttymon3 ttymon 01s u uucp /dev/term/01s b - /usr/bin/ _login - 2400 - login: - # ttymon3 ttymon 00h u root /dev/term/00h - - /usr/bin/ _login - 9600 - login: - # tcp listen 0 x root \x02000ACE64000001 - c - / _usr/lib/saf/nlps_server _#NLPS SERVER tcp listen lp - root - - - - /var/spool/lp/fifos/ _listenS5 #NLPS SERVER tcp listen 105 - root - - c - /usr/net/servers/rfs/ _rfsetup #RFS server
The following two examples demonstrate the first two commands.
#pmadm -l -pttyserv -s s01 PMTAG PMTYPE SVCTAG FLGS ID PMSPECIFIC ttyserv ttymon s01 d root /dev/term/01 -- /usr/bin/login - 9600 - Welcome to UNIX, Please Login: - # #pmadm -l -pttyserv PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> ttyyserv ttymon 00s u root /dev/term/00s - - /usr/bin/login - 2400 - login: - # ttyserv ttymon 01s u uucp /dev/term/01s b - /usr/bin/login - 9600 - login: - #
Enabling, Disabling, and Removing a Port Service To enable, disable, or remove a port service, use pmadm -e, pmadm -d, or pmadm -r, respectively. Hence, to enable s01 port monitor, enter
#pmadm -pttyserv -s s01 -e
whereas to disable it, enter
#pmadm -pttyserv -s s01 -d
and to remove it, enter
#pmadm -pttyserv -s s01 -r
The ttymon port monitor
As its name implies, the ttymon port monitor is responsible for invoking and monitoring port services associated with your system's tty ports. When invoked, ttymon looks up its /etc/saf/<pmtag>/_pmtab file to determine: which port services to invoke; which tty port associates with which service; how the port services are configured (for example, startup in an enabled state, what line speed to configure tty port to, and so on); and which application, or process, to invoke upon user request (for example, login service, uucp, and so on).
ttymon replaces both getty and uugetty. Though getty and uugetty are still supported by SVR4 for backward compatibility reasons, system administrators are strongly recommended to use ttymon. This recommendation stems from the following comparison:
co:12345:respawn:/usr/lib/saf/ttymon -g -v -p "Console Login: "-d /dev/console -l console
Upon reading this entry, init starts a ttymon port monitor to take care of console login needs. This particular invocation of ttymon falls beyond sac's control.
Special Device Files and the Terminal Line Settings Database Among the arguments that the system administrator must pass to pmadm to create a port service, two will be described: the device special filename corresponding to the tty serial interface undergoing configuration and a label identifying an entry in a terminal line settings database.
Device Special Filenames Under SAF Special filenames underwent some changes under SVR4. In earlier releases of UNIX, getty and uugetty referred to the special files in the /dev directory as tty##, where ## refers to the actual port number. With SAF under SVR4, tty port special files are maintained in a subdirectory called /dev/term and the special files are named ## in that directory. com1 port on a 386 machine is now referred to as /dev/term/00, whereas under getty it is referred to as /dev/tty00. Due to the ongoing support to uugetty and getty, both conventions are currently supported. It is the administrator's responsibility, however, to make sure that the right convention is applied with her preferred way of invoking a port service.
The Terminal Line Settings Database As mentioned earlier, this database is the ttymon administrative file, which defines the line settings applying to the tty port being invoked. The database filename is /etc/ttydefs, whereas getty's is /etc/gettydefs. Both files remain supported by SVR4 and both are maintained using the /etc/sbin/sttydefs command. A good understanding of these databases helps you to provide the level of support that matches the users' terminal emulation need. In the following discussion, however, only /etc/ttydefs' file data structure is examined and explained. The use of the sttydefs command to add, modify, or delete entries in the database also is described.
The discussion begins with a close look at the contents of the /etc/ttydefs file. To list its contents, enter
#/usr/sbin/sttydefs -l ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ 19200: 19200 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread : 19200 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread ::9600 ------------------------------------------------------------------------------------------------ -------------------------------------------------------------------------------------------------- ttylabel: 19200 initial flags: 19200 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread final flags: 19200 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread autobaud: no nextlabel: 9600 ---------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------- 9600: 9600 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread : 9600 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread ::4800 ---------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------------- ttylabel: 9600 initial flags: 9600 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread final flags: 9600 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread autobaud: no nextlabel: 4800 ----------------------------------------------------------------------------------------------------------- ------------------------------------------------------------------------------------ 4800: 4800 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread : 4800 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread ::2400 -------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------- ttylabel: 4800 initial flags: 4800 opost onlcr tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread final flags: 4800 opost onlcr sane tab3 ignpar ixon ixany parenb istrip echo echoe echok isig cs7 cread autobaud: no nextlabel: 2400 . . .
As you see, sttydefs formats the listing into a user-friendly format. If you want the actual data structure of the command, enter
#cat /etc/ttydefs . . . onlcr sane tab3 ignpar istrip ixon ixany echo echoe echok isig cs8 cread ::console5 console5: 19200 opost onlcr tab3 ignpar istrip ixon ixany echo echoe echok isig cs8 cread : 19200 opost onlcr sane tab3 ignpar istrip ixon ixany echo echoe echok isig cs8 cread ::console 4800H: 4800 : 4800 ixany parenb sane tab3 hupcl ::9600H 9600H: 9600 : 9600 ixany parenb sane tab3 hupcl ::19200H 19200H: 19200 : 19200 ixany parenb sane tab3 hupcl ::2400H 2400H: 2400 : 2400 ixany parenb sane tab3 hupcl ::1200H 1200H: 1200 : 1200 ixany parenb sane tab3 hupcl ::300H 300H: 300 : 300 ixany parenb sane tab3 hupcl ::4800H 19200NP: 19200 opost onlcr tab3 ignpar ixon ixany istrip echo echoe echok isig cs8 cread : 19200 . .
The following is a description of each field: Label: It is unique and is used in identifying the record. You will be passing this label to ttymon, using pmadm, when creating the port service. Every time ttymon attempts invoking the port service, it searches for that label in the ttydefs file.
Initial flags: This field describes the initial terminal line settings. They allow users to provide login information upon initial contact.
Final flags: They define the terminal line settings after a connection request is detected, and right before the associated port service is invoked.
Autobaud: This field can contain either A or null. By including A in this field, you are prompting ttymon to automatically determine the line speed upon receiving a carriage return from the user's terminal.
Next label: This field includes the label of the next record to fetch should the line settings specified in the current label fail to meet the user's terminal needs. ttymon recognizes the failure upon receiving a BREAK sent by the user. This technique allows ttymon to fall back on any number of alternate configurations in search of the desired line speed. Records linked together in this fashion are said to form a hunt sequence, with the last one normally linked to the first record. The sample partial listing shown previously includes a hunt sequence that starts with label 4800H and ends with 300H.
An example record in ttydefs follows, along with an explanation of its field contents.
9600NP: 9600 tab3 ignpar ixon ixany echo echoe cs8 : 9600 sane tab3 ignpar ixon ixany echo echoe cs8::4800NP
This record is labeled 9600NP. Both the initial and final flags set the port to 9600 bps, no parity (ignpar), enable XON/OFF flow control(ixon), any character should restart output (ixany), echo back every character typed (echo), echo erase character (echoe), and to set the character size to 8 bits. The autobaud field is null, which means that no autobaud support is required. The last field points to the next record labeled 4800N.
To find more about the valid initial and final flag settings, consult your vendor's manuals, or simply enter "man stty" on the command line.
What if you don't find what you want in ttydefs? As noted earlier, SVR4 provides you with the /usr/sbin/sttydefs command to make changes to the /etc/ttydefs database. Among the changes you are allowed to make is adding the record of your liking. The command syntax to do that follows:
#sttydefs -a<ttylabel> [-b] [-n<nextlabel>] [-i<initialflags>]\ [-f <finalflags>]
in which -a <ttylabel> adds an entry to ttydefs with label specified (first field)
-i <initialflags> specifies initial speed among other line settings (second field)
-f <finalflags> specifies final line settings (third field)
-b enables autobaud (fourth field in which case A will be included in this field)
-n describes the next record's label
For example, the sttydefs that follows adds a new record, labeled 4800, with initial flags set to support 4800 bps line speed:
#sttydefs -a4800 -i"4800 hupcl tab3 erase ^b" \ -f"4800 sane ixany tab3 erase ^h echoe" -n2400np
To remove an entry, simply enter sttydefs -r <ttylabel>.
For example: to delete the 4800 label, enter
#sttydefs -r 4800
The ttymon Port Monitor Administrative Command ttyadm ttyadm is ttymon's administrative command. Its prime function is to pass information to both sacadm and pmadm in the formats they require. The following are the ttyadm options: -V specifies the version of ttymon
-d device specifies the /dev/term/## tty with which the port service will be associated
-b if included, will configure the port service for bidirectional flow of data
-r <count> specifies the number of times ttymon should try to start the service before a failure is declared
-p "prompt" is the string used to prompt users when a port service request is detected.
-i "message" is the message to be displayed if the port is in a disabled state
-t <timeout> is the number of seconds that ttymon must wait for input data before closing the port
-l <ttylabel> specifies the label of the desired record in the /etc/ttydefs file described earlier in this section
-s specifies the name of the service provider program on the tty port (for example, login, cu, and so on)
At this point, all of the necessary elements that you will need to implement terminal and modem connections have been covered. If you are anxious to try implementing, you may jump right ahead to the section titled "Connecting Terminals and Modems." Otherwise, continue reading the next section, which explains the listen port monitor.
The listen Port Monitor
listen is a network port monitoring process that is invoked and controlled by sac. It runs on any transport provider (most commonly TCP), and supports two classes of service: a class of general services, such as RFS and network printing; and terminal login services for terminals trying to access the system by connecting directly to the network. Like ttymon, listen can support and monitor multiple ports, with each assigned a network service to take care of. Once invoked, the listen port monitor initializes port services as defined in its /etc/saf/<pmtag>/_pmtab file. It then monitors the ports for service connection requests. Once a request is received on a listen port, the associated service (for example, printing) is invoked and the user is connected to it.
Port Service Addressing During TCP/IP setup (refer to Chapter 20 for more on TCP/IP), your system will have been assigned an Internet address that is 8 hexadecimal digits long, with each pair of digits represented by one octet. Stations shipping requests across the network to your system use this address to reach your machine's doorstep only. Because your machine is more likely to be configured to respond to a variety of service requests, there arises the requirement to assign unique addresses to port services. This allows the listen port monitor to support multiple port services. Upon adding a listen port service, you are required to provide the applicable address to nlsadmin (the listen port monitor administrative command). For this reason, you are provided with the address format shown in Figure 23.2.
The elements of the address format are as follows: Family address: This is four digits long. It is always set to 0020.
Port address: This is four digits long and is the port service-specific address. For example, listenS5 print server is assigned x0ACE, whereas listenBSD print server is assigned x0203.
Internet address: This is the IP address you assigned to the system upon installing TCP/IP. It is eight digits long.
Reserved: This is 16 digits long and is reserved for future use. Currently, it is set to 16 zeros.
As an example, assume that the IP address of your system is 188.8.131.52 and that you want to set up a listen port to take care of print service requests sent across the network by BSD systems. The port address in hexadecimal notation then becomes
It will be shown later in this section how to pass this address to pmadm when creating the port service.
The listen Port Monitor Administrative Command nlsamdin nlsadmin is the administrative command specific to the listen port monitor. nlsadmin can be used to add, configure, and change the status of a port monitor. Also, it can be used to start or kill the listener process. Mostly it will be used in command substitution mode, in order to supply some of the required arguments to both sacadm (the sac administrative command) and pmadm. Options that you specify on the command line will determine which arguments to pass, and in what format.
Creating a listen Port Monitor To create a ttymon port monitor, you use the sacadm command. The same applies to creating a listen port monitor. Instead of using ttyadm, however, you must use nlsadmin in command substitution mode in order to pass some of the required information to sacadm. The use of sacadm in creating a listen port monitor is as follows:
#sacadm -a -p<pmtag> -t listen -c<"command"> -v'nlsadmin -V'\ [-n<count>] [-fd|x] [-y<"comment">]
All options bear the same significance described in earlier sections (refer back to the "Creating a Port Monitor" section for a review). Note in particular, the use of 'nlsadmin -V' in order to pass the port monitor's version to sacadm. Also note that the -c option specifies the program invoked to bring up the listen port monitor. The program is /usr/lib/saf/listen. Once a port monitor is created, an entry pertaining to it is added to sac's administrative file /etc/saf/_sactab.
As an example, the following sacadm command creates a listen port monitor with pmtag tcp. Note that the program filename to invoke is /usr/lib/saf/listen, and sac is required to try up to three times to bring up the port monitor, should it ever fail respond to sac's polls.
sacadm -a -t listen -p tcp -c "/usr/lib/saf/listen" \ -v'nlsadmin - V' -n3
Managing listen Port Monitors To check on the availability of listen port monitors, enter
#sacadm -l -t listen
As a result, you see a listing of all listen port monitors currently controlled by sac on your system. The listing looks like the following:
PMTAG PMTYPE FLGS RCNT STATUS COMMAND tcp listen - 3 ENABLED /usr/lib/saf/listen -m inet/tcp0 tcp
For a review of the interpretation of the preceding listing, refer to the "Checking the Status of the Port Monitor" section.
In order to enable, disable, or remove a port monitor, enter sacadm with -e, -d, or -r respectively, as described earlier in this chapter.
Creating a listen Port Service To create a listen port service, use the pmadm command. The syntax follows.
#pmadm -a -p<pmtag> -s<svctag> [-i id] -v 'nlsadmin -V'\ -m"'nlsadmin options'" -y"comment"
The following command adds a new port service to a port monitor with pmtag tcp:
#pmadm -a -p tcp -s lpd -i root -v 'nlsadmin -V'\ -m"'nlsadmin -o /var/spool/lp/fifos/listenBSD -A \ \x00020203640000020000000000000000'"
The preceding command demonstrates the use of the port address discussed earlier. The port address described in the preceding example configures the port to accept printing requests sent by BSD clients across the network.
Managing Port Services To check on the status of a port service, enter
#pmadm -p<pmtag> -s<svctag> -l
To enable it, enter
#pmadm -p<pmtag> -s<svctag> -e
whereas to disable it, enter
#pmadm -p<pmtag> -s<svctag> -d
and to remove it, enter
#pmadm -p<pmtag> -s<svctag> -r
Device Administrative Tasks Under SVR4
This section covers the motions of performing common device administrative-related tasks as applicable to SVR4 of UNIX. Subsequent sections cover other variants as well, including Solaris 2.x, and Linux. The section, "Connecting Terminals and Modems," applies to all variants, as they provide a comprehensive coverage of hardware related issues that are common to all variants of UNIX (and other operating systems).
Connecting Terminals and Modems
UNIX has very powerful built-in serial communications capabilities. Administrators can make use of them in order to offer local terminal connection services, as well as across-the-telephone wire services. Services across the wire include remote terminal login, file transfer capabilities, and electronic mail exchange. Those services are provided by utilities such as uucp and cu, which are part of the Basic Networking Utilities (BNU) that comes with your UNIX operating system.
In this section, the concepts and steps to set up for both modem and terminal connections are presented. A properly wired and configured serial interface is a basic requirement that is common to both types of services. Once this requirement is fulfilled, you can proceed to implementing the necessary additional steps to take care of modem and terminal connections.
Making the Connection
To make the serial connection, prepare for the physical connection, determine the availability of associated resources, and create the port service.
Preparing for the Physical Connection In this step, you are primarily involved in readying the cable that will connect the modem, or the user's terminal to the UNIX system. RS232C/D is the standard interface that most hardware platforms use to connect devices. So that you can understand the how and why of different cable arrangements, a brief examination of the standard is provided.
RS232C/D defines the interface between so-called data circuit-terminating equipment (DTE) and data circuit communication equipment (DCE). In practical terms, and for the purposes of this section, this means that it defines the physical interface between a computer (the DTE) and the modem (the DCE). The interface defines four aspects of the physical layer. These are electrical, mechanical, functional, and procedural.
The electrical specification defines how data is electrically represented on the wire. Because computer data is binary in its raw form, the specification describes what voltage level represents which logical level.
The mechanical specification describes the mechanics of the connection, including the connector type and the number of pins supported. A DB-25 connector is specified for the RS232C/D interface. The industry introduced another de facto standard, however. This is the DB-9 connector most commonly found on PC workstations.
The functional specification defines the pinout of the connector (that is, what each pin stands for).
The procedural specification defines the handshake mechanism that should precede, accompany, and terminate the exchange of data between the DTE and DCE.
Figure 23.4 shows the wiring diagram and corresponding pin definition of the DB25-to-DB25 cable, which is normally used to connect a DTE to a DCE. Figure 23.5 shows the wiring diagram of a DB9-to-DB25 cable. Following is a description of the most commonly used circuits. Because pin definitions are not the same for both types of connectors, the description refers to the circuit name rather than the pin number.
SG provides the common return path for both the transmit (TD) and receive (RD) circuits.
DTR and DSR are asserted by both the computer and modem to indicate readiness to exchange data. Both circuits must be asserted before any other activity can occur across the interface. At this point, the computer may attempt to dial another computer by passing the dialing command string to the modem.
DCD is asserted by the modem if it successfully connects at the remote end. It is interpreted by the computer as an indication of a successful connection. This circuit has to remain asserted for the duration of the call.
TD and RD are the transmit and receive circuits.
Any time the computer wants to transmit, it asserts the RTS circuit and waits for permission to do so from the modem, by virtue of asserting the CTS circuit. This usage of the RTS/CTS circuit pair applies to the half-duplex mode of communications. In full-duplex communications, RTS and CTS circuits are used to control the flow of data between the DTE and the DCE devices. The DTE drops its RTS circuit in order to request the DCE to stop sending data on DTE's receive circuit. Likewise, the CTS is dropped by the DCE in order to request the DTE to stop sending data on the transmit circuit.
Connecting a computer directly to a terminal (that is, a DTE-to-DTE type of connection) is a tricky business, but easy to understand. Because RS232C/D defines the interface strictly between a DTE and DCE, many vendors and users have developed variations on a cabling trick that allows DTE-to-DTE connection. This trick is called the null modem cable. The underlying idea is to convince both ends of the connection that they are indeed talking to modems directly connected to them. Figure 23.6 shows two diagrams depicting the same cabling trick corresponding to different combinations of connectors.
When the interface pinout was described, it was done from the DTE perspective. This means that if you look at the interface from the DCE perspective, some pins bear quite the opposite significance. For example, DTEs send and receive pins are DCEs receive and send, respectively. It is not, therefore, hard to imagine what would happen if you were to attempt connecting two DTEs using a direct cable. Data emerging from both devices on directly connected transmit circuits would be endlessly colliding, while they are hopelessly waiting for an impulse to occur on the wire connecting their receiving circuits.
To remedy this situation, the send and receive circuits are cross-wired. Also, recall that whenever the computer asserts its RTS circuit, it is asking for clearance to transmit. This clearance is indicated by having the CTS asserted (normally by the modem), which explains why this circuit pair is also cross-wired. Finally, note how DSR, DTR, and DCD are wired. When DTR is asserted by any DTE, the other one detects a DCD and DSR, which are interpreted as both modem-ready and connection-established indicators, just as though they were sent by the receiving DTE's local modem. If the DTE is prepared to engage in data communications, it asserts its DTR and both sides can now talk to each other.
There are variations on the theme of the null modem. Although the preceding variation caters to the most general cases, it is advisable that you check with your vendor to determine your exact cabling needs.
Determine the Availability of Resources Before you can proceed to creating the port service, there are two resources that you need to check: 1) availability of tty ports, and 2) availability of a suitable record in the /etc/ttydefs file.
To obtain a list of all tty ports that are currently in use, enter the command pmadm -l -t ttymon. The listing will look like the following:
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> ttymon3 ttymon 00s ux root /dev/term/00 ... ttymon3 ttymon 11s - uucp /dev/term/11 ...
The device special filenames under the <PMSPECIFIC> column indicate which ttys to avoid in your subsequent steps. Depending on availability of extra free tty ports, choose the one you want.
Next, list the contents of the /etc/ttydefs file by entering the command sttydefs -l, and examine its contents for the record and label that match your terminal needs. If you do not find one, then you ought to add the desired entry to the database yourself, by using the sttydefs command. For this, you are referred back to the "Special Device Files and the Terminal Line Setting Database" section.
Creating the Port Service Now that you have all the pieces (that is, the cable, the tty port, and the label of the record in /etc/ttydefs file), you can proceed with putting them together to create the port service. To do so, you ought to use pmadm with the -a option. The example that follows demonstrates the use of pmadm to create a bidirectional port service, with svctag 04s, which invokes the service login, restarts the port three times upon failure, and prompts the terminal with a friendly message. Also note the use of ttyadm in command substitution mode in order to pass some of the arguments to pmadm.
#pmadm -a -pttyserv -s04s -i root -v 'ttyadm -V' \ -m "'ttyadm -b -r3 -p"Welcome Home! LOGIN:" -d/dev/term/04 \ -l 9600 -s /usr/bin/login'"
Use pmadm -l to check on the state of the service. If the new service is not enabled, use pmadm -p<pmtag> -s<svctag> -e to do so.
Connecting the Modem
As noted earlier, you connect a modem to the serial port (for example, COM2) using a straight-through cable. To configure the modem properly, you must read the documentation supplied with it. The things you ought to pay attention to are the DIP switch settings and the AT commands that are necessary for proper modem initialization and dialing. Because the majority of modems today are Hayes compatible, the list in Table 23.2 can act as the configuration guidelines that apply to them.
Hayes modems have an 8-bit DIP switch. Table 23.2 summarizes the meanings associated with each bit switch position.
Table 23.2. Hayes modem switch settings.
On ports configured for dial-in, UNIX responds to asserted DSR and CD by writing a login prompt to the modem. This, therefore, requires turning off echoing as well as result codes on the modem. Failing to do so leads the login process into interpreting locally echoed login prompt characters as a sequence of responses, which leads into a vicious cycle of login denials and subsequent reattempts. To turn local echo and result codes off, set switch positions 3, 4, and 6 to up, down, and up, respectively.
What if you do not have switches on your modem? You can use the AT modem control command set instead! AT commands let you configure the modem to initialize and manage a connection in ways deemed suitable to your applications. Table 23.3 lists some of the AT commands commonly supported by Hayes compatible modems. For a complete command list, consult your modem's manuals.
Table 23.3. Partial list of some of the most commonly supported AT commands.
To issue AT commands, you need to have some sort of direct access to the modem. The following steps show you how you can do it using the cu command.
After you login to UNIX, switch user, using the su command, to uucp:
#su uucp password: $
Edit the /etc/uucp/Devices file (see Chapter 26 for more details) to include the following entry:
Direct term/## - <speed> direct
where ## corresponds to the tty port number, and <speed> refers to the speed to which you want to initialize the modem. If, for example, you have a 2400 bps Hayes-compatible modem connected to COM2, the entry would look like this:
Direct term/01 - 2400 direct
I am assuming here that there is no other reference to term/01. If there is one, disable the entry by inserting the # sign at the beginning of the line. Make sure to save the file before quitting.
At the command line, enter
#cu -l term/##
This command directly connects you to the modem and is confirmed by displaying the message "Connected" on your screen. Table 23.4 is an illustration of a sequence pertaining to a sample modem session, during which the modem is configured for proper dial-in support.
Table 23.4. An illustrated modem configuration session along with supporting explanation.
# Note in particular the use of the ~. character sequence to disconnect from the modem and go back to the shell. In fact, ~ allows you to issue UNIX commands without having to quit the direct modem session.
For dial-out, it is more convenient to enable local echo and result codes. In any case, it is imperative that you carefully read and follow the modem's manual for proper operation.
Here is a checklist to which you may refer whenever you install, or troubleshoot, a modem.
Direct term/## - <speed > direct
#cu -l term/##
Many of the preparatory steps that are required to connect terminals have already been described in the last two sections. To summarize, these steps are as follows:
Depending on whether the terminal is connected directly or remotely to the system, you have to prepare either a cross-wired RS232C/D cable or a straight-through cable.
In the case of remote connection, you ought to configure the modem connecting to the UNIX system for dial-in in the manner depicted in the "Connecting the Modem" section.
A port service should have been created, which, upon detection of a service request (by virtue of having both DSR and CD asserted), will write a login prompt to the port and transfer port control to the login process itself. This is achieved by entering the following pmadm command:
#pmadm -a -p<pmtag> -s<svctag> -i root -v'ttyadm -V' \ -m"'ttyadm -b -rn -p"login prompt message" -d/dev/term/## \ -l<label> -s /usr/bin/login'"
The use of the pmadm command to create port services was described earlier in this section.
One more step, which will be discussed now, is to set the shell environment for proper support to the user's terminal.
UNIX is designed to shield programs from concerns pertaining to the physical terminal specifics. Instead of talking directly to the terminal, programs interface with a virtual terminal by making calls to a standard library of screen routines. Those calls invoke, on behalf of programs, the desired behavior on the physical screen.
In doing so, two advantages are derived: Developers are relieved of the laborious and needless (if not impossible) task of writing and maintaining programs in a way that keeps them compatible with all kinds of terminal types, those existing now and those that will emerge in the future. Also, users continue to benefit, without any modifications or the associated cost of upgrades, from programs deployed on their UNIX platforms irrespective of changes that may be introduced to their terminal types in the future.
Proper support to the actual terminal is conditional upon setting the environment variable TERM to the correct type. This is normally done from the user's login script. The user may as well set it by entering (assuming the user's shell is Korn shell):
$TERM=<terminal_type> $export TERM
An example of terminal type would be vt220.
UNIX uses the value assigned to TERM to reference a binary file, which exclusively defines that terminal's capabilities. The file is named after the terminal type (for example, if the terminal is vt220, then the file must have been named vt220) and is part of a large terminal information database maintained in the /usr/lib/terminfo directory.
If you list the contents of the /usr/lib/terminfo directory, you obtain a listing similar to the following:
#ls /usr/lib/terminfo 1 3 5 7 9 B H P V b d f h j l n p r t v x z 2 4 6 8 A C M S a c e g i k m o q s u w y
Each letter or numeral is the directory name where terminal capabilities definition files, pertaining to types starting with that letter or numeric, are saved. For example, if TERM is set to vt220, UNIX fetches the file /usr/lib/terminfo/v/vt220 for the terminal information capabilities (also referred to as terminfo entry).
After having gone through all of the steps required to connect the terminal, you should proceed to connect it, bring it up, and attempt login. It would be a good idea to try a direct connection first, if the terminal is intended for modem access. In any case, if you fail to get the login prompt and fail to login, you may have to carry the following checks:
Make sure that the port service is configured properly, and that it is enabled. Use pmadm to do that.
Check the cable to verify that it is the correct one. Do not rely only on the wiring diagram provided in this chapter; you are better off relying on your terminal and/or your modem vendor's documentation.
Verify that the modem is configured to Autoanswer.
Check the modem lights, and verify that the sequence of events depicted by the flashing lights conforms to what you expect to see. In particular, check DSR and CD during the connection establishment phase because, unless they are both asserted, the login prompt won't be written to the tty port. Check the modem's hard and soft settings to address any observed anomalies.
Make sure that the speed, parity, and number of stop bits match on both the terminal and the UNIX system.
Connecting Terminals and Modems Under BSD
Connecting terminals and modems under BSD is done differently from SVR4. The hardware setup, however, remains the same as in SVR4, and therefore won't be repeated.
To start with, like SVR4, BSD UNIX requires that hardware devices be associated with device special file in the /dev directory. Device special files for serial ports are normally created under tty## name. The "##" refers to the port number. For example, tty02 refers to the second serial port.
Terminal Line Settings and Configuration Files (BSD) Following are the configuration files supporting terminal lines under BSD:
The /etc/ttys file contains one record per serial port. The record provides details of resources associated with the serial port being supported, including pointers to information that are necessary for the proper initialization of this port by the init process.
Following is the syntax of that entries in /etc/ttys must comply with:
serial_port command terminal_type status Where
Here is a partial listing of the contents of a sample /etc/ttys file:
According to this file, the console is enabled (status is set to on) runs at 9600, and allows root login (status is set to secure). On the other hand, tty03 is disabled as it is used for dial-out purposes only. Using the second entry (that of tty00), for example, init initializes the first serial port to 2400 bps by virtue of cross referencing the std.2400 parameter in the /etc/gettytab file. The terminal type being specified (that is, vt100) also serves as a pointer to the actual record describing the terminal capabilities as defined in the /etc/termcap file.
Adding the Terminal (BSD) Once the aforementioned configuration files are updated to support the terminal pending connection, and the hardware and serial cable are taken care of properly (discussed earlier in the chapter), starting the new terminal line becomes a simple matter of sending init a hang-up signal (HUP) as follows:
# kill -1 1
# kill -HUP 1
By sending it a hang-up signal, init is forced to reinitialize itself by reading the configuration files, including those mentioned above. Consequently, init takes the proper action by spawning getty on the new port and initializing it for support for the specified line speed, and terminal types as specified in the /etc/ttys file.
Adding a Modem (BSD) Under BSD UNIX, connecting a modem to a serial port requires creating different device special files from those used for directly connected terminals. Under SunOs, for example, for dial-in modems, the device special file is usually called /dev/ttydn, where n designates the modem line (starting with 0). This means the /dev/ttyd0 would be the dial-in device file of the first modem line. For dial-out modems, the device file is named /dev/cuan, where again, n corresponds to the modem line. Hence, /dev/ttyd0 and /dev/cua0 are the device files corresponding to dial-in and dial-out modems for the same line, respectively.
If you check the /dev directory, you might not find any of the files just mentioned. This is particularly applicable to a system that has never been required to connect to modems. In this case, you will need to create both files. Creating the /dev/ttydn device is rather simple. It involves renaming the special device file corresponding to the physical port where the modem will be connected to /dev/ttydn. For example, if you want to connect a modem to the first physical serial port on your system, you need to rename the /dev/ttya file to /dev/ttyd0 as follows:
# mv /dev/ttya /dev/ttyd0
Creating the /dev/cua0 file is a two-step process involving the use of the mknod command. Following is the general syntax of mknod:
mknod filename [c] | [b] major minor
where in this syntax,
# ls -l /dev/ttyd0 crw--w--w- 1 root 12, 0 Nov 26 22:25 /dev/ttyd0
# mknod cua0 c 12 128
Once the cuan device file is created, you will need to secure it by changing its ownership to uucp and the permissions to 600, as shown below:
# chmod 600 /dev/cua0 # chown uucp /dev/cua0
Now that both /dev/ttyd0 (the dial-in device file) and /dev/cua0 (the dial-out device file) are created, what remains (aside from configuring the modem and attaching it to the port as described earlier in the chapter) is to update the /etc/ttytab file as described in the previous section.
Connecting Terminals and Modems Under Linux
Being a BSD variant of UNIX, connecting terminals and modems to Linux involves most of the steps depicted in the previous section with a few subtle differences. These are:
d1:2345:respawn:/sbin/getty ttyS0 38400
According to this entry, getty is respawned by init while the system is any of 2,3,4 or 5 run levels. The port being controlled is ttyS0 (i.e. the first serial port, COM1). 38400 is a label designating an entry in the /etc/gettydefs file (the line settings database, described earlier).
Printing services in UNIX are supported by the LP spooler. The LP spooler offers administrators comprehensive capabilities that allow them to address varied scenarios in order to meet different user needs and requirements. To name a few, print services can be physically set up to allow users to print on printers connected to the host they are logged in to or, alternatively, to printers connected to other hosts on the network. LP printing service includes a library of filters from which administrators can choose to support their user needs. By implementing them, users' print jobs will be processed, making them more "compatible" with the target printer. Administrators are provided with management capabilities allowing them to use global management as well as selective management of print services. Because this chapter is about "Device Administration," the objectives of this section will be limited to include the following topics:
How Does the LP Printing Service Work (SVR4, Solaris 2.x)
Print services are invoked by init upon start-up when the system enters the multiuser state run level 2. The services are brought up by the /etc/rc2.d/S80lp script and are killed whenever the system is shut down by /etc/rc2.d/K20lp script.
When users address printers to handle their print jobs, the files they send for printing are not handled immediately by the printers. Instead, the files are queued in directories, by a process known as the spooler, for subsequent handling by a printing daemon known as lpsched (an acronym and program name for the lp scheduler daemon). To understand how this works, imagine yourself as part of a community of users sharing one or two printers, among other UNIX resources. Ask yourself what would happen should you be able to address the printer directly for a print request while someone else is doing exactly the same thing. You are right! The output will be more of a character soup than presentable piece of work. This is due to the fact that the printer will be handling characters as they arrive, thus mixing the ones that belong to your file with those belonging to other users.
To alleviate this problem, the spooler takes over as you send print jobs to printers. It simply stops them on their way to their destination and diverts them to a waiting area on your system disk. This area is a subdirectory known as the print queue. Files destined for the same printer are queued in the same directory until the printer becomes available. The aforementioned process is known as spooling. You may be wondering whether this means that the terminal will be tied up for as long as it takes for the print job to materialize. The answer is no. This is because once a print job is queued, another background process known as the printing scheduler daemon (lpsched) takes over and supervises the ongoing printing services, making sure that every request, including yours, is honored.
In addition to the basic service, LP printing services allow administrators to aggregate printers of similar type into a printer class. This provides for the optimal utilization of printing resources, as users target a class of printers instead of targeting a specific one. When this happens, lpsched sends the print job to the first printer to become available in the requested class. Other printing services include tasks pertaining to starting interface programs that are suitable to the printer, applying the filters to user files whenever necessary, notifying users, if desired, of the status of printing jobs, and, in the case of network printing, the LP printing service has the additional job of sending print jobs to the hosts to which requested printers are connected.
Setting Up Local Printing Services (SVR4, Solaris 2.x)
In this section, the setup and configuration of local printing services are presented. Local printing services provide users with the capability to print to printers connected directly to the host they are logged in to. The following are the required steps to set up printers, irrespective of whether they are parallel, serial, or network printers.
The resources for which you want to check are lp login id, lpsched, and an available port (serial or parallel). The lp login id is normally created during initial system installation. If the lp account does not exist in the /etc/passwd directory, then you ought to create one. It will be required at a later step in the setup process. Second, verify that lpsched is running by checking the output of the command
#ps -ef | grep "lpsched"
If not enabled, you may do so by entering the following command:
The next step is to create a print destination by using the lpadmin command. The syntax of lpadmin follows.
/usr/lib/lpadmin -p<name> -v<pathname> -m<interface> \ [-h|l] - c<class>
In this syntax, -p<name> is the name you want to assign to the printer. It can be anything you like. It is more convenient, however, to assign it a name that makes sense to the user community.
-v<pathname> is the special device file pathname. Depending on whether the printer is parallel or serial, the pathname is /dev/lp# or /dev/term/## (# and ## represent decimal digits representative of the parallel and serial ports on your system).
-m<interface> is a program that is invoked by lp as it sends print jobs to the printer port. <interface> is responsible for printer port and physical printer initialization, and performs functions pertaining to printing a banner if desired, producing the right number of copies, and setting the page length and width. You have the freedom to write and use your own interface programs (in which case you must specify its name using the -i<interface> option). If you do not specify one, the standard and generic interface supplied with the system will be used by default. When installing the printer for the first time, it is advisable to start with the standard interface. If all goes well, you can always change over to the interface of your choice. Printer interfaces are usually maintained in the /usr/lib/lp/model directory.
[-h|l]: h indicates that the printer is hardwired, whereas l indicates that the device associated with the printer is a login terminal. h and l are mutually exclusive. In the event that none is specified, h is assumed.
-c<class> specifies the class to which the printer belongs. Users will subsequently be able to specify the class using lp with -d option.
Assuming that you want to create a printer destination for a parallel printer that is to be connected to your parallel port, the lpadmin command would look like this:
#lpadmin -d dotmatrix -v /dev/lp1 -m standard #lpadmin
Because the printer port device special file can be written to directly, as with any other file, you ought to make sure that users have no direct access to it. This involves changing the port ownership to login lp, as well as changing the file permissions to 600. The following two commands demonstrate how to do this to /dev/lp1.
#chown lp /dev/lp1 #chmod 600 /dev/lp1
Before you release the printer to the user community, you may want to make it the default destination. A user failing to specify the printer destination when using the lp command will have his print job sent to the default printer. To make a printer the default destination, enter the following command:
#lpadmin -d <printer_name>
The lpadmin command to make dot matrix the default printer therefore becomes
#lpadmin -d dotmatrix
Finally, to make the printer accessible to users, you must allow the printer destination to accept print jobs as well as logically turn on the printer. To allow printer dotmatrix to accept print jobs, enter
and to logically turn it on (that is, allow it to do the printing), enter
Setting Up Network Print Servers (SVR4, Solaris 2.x)
Sometimes in a multisystem, multiplatform environment users find themselves in need of printers that are attached to a different system than what they are currently logged in to. Figure 23.7 depicts a scenario whereby the user wants her print job sent to printer odie, attached to system engg, while logged in to system arts.
To provide this level of service, UNIX comes with enough support that, if implemented properly, allows users to print to any printer on the network. While doing so, users do not even have to be concerned with any additional detail on how to address those printers than they already know about addressing their own. Figure 23.8 demonstrates the governing principles of network print services. In the depicted scenario, system engg becomes the so-called print server, whereas system arts is the client. The setup procedure calls on having print destinations (that is, queues) created on both systems (say, odie and garfield on engg and arts, respectively). Whereas odie is associated with the printer attached to engg, garfield has to be logically associated with odie (not with any printer that may happen to be attached to system arts). A user logged in to arts has to address the local printer destination--in this case garfield--to be able to print to odie as shown. The lp print request then becomes
#lp -p garfield <file_name>
In doing so, the user is in fact addressing the local LP print service running on system arts. Next, LP on system arts checks the actual resource with which printer destination garfield is associated, to find that it actually maps to a print service resource (odie) supported on system engg. As a consequence, LP on system arts routes the request, along with the print job, to engg for subsequent handling.
The steps involved in setting up the service are not as complex as they may sound. For the most part, they are similar to those listed in the previous section with some subtle variations. Because this level of service involves both the client and server systems, both of them need to be configured.
Configuring the Print Server Print server configuration requires two additional steps to those listed and described in the section on local printing. The two steps are creating a listen port service and registering client systems with the print service.
Because the print service under description is a network service (that is, runs on a connection-oriented transport service), then there is a requirement to create a listen port service with which it associates. Before doing that, however, it might be worth your while to check on readily available ones. When UNIX is first installed, your system is automatically configured to support a listen port monitor with port monitor tag tcp. Also, tcp is configured to support two print server-associated port services, with one taking care of System V clients whereas the other one takes care of BSD clients. To verify their existence, enter
#pmadm -l -t listen PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> . . . tcp listen 0 x root \x02000ACE64000001 - c - /usr/lib/saf/nlps_server #NLPS SERVER tcp listen lp - root - - - - /var/spool/lp /fifos/listenS5 #NLPS SERVER . .
If the listing you get on your screen includes the two entries shown in the preceding partial listing, you do not need to create the port services and you may skip the next step. If they do not exist, use pmadm to create them. To create a port service to listen to print requests sent by System V clients, enter
#pmadm -a -p<pmtag> -s lp -i root -v 'nlsadmin -V' \ -m 'nlsadmin -o /var/spool/lp/fifos/listenS5'
where pmtag is the name assigned to the port monitor. To create a port service to respond to BSD clients, however, you must enter lpsystem -A. The output displays the port address that you ought to use as an argument with nlsadmin upon using pmadm to create the port service. Following is an example output of lpsystem -A, as it appears on my monitor:
#lpsystem -A 02000203640000010000000000000000
Next, to create the port service under tcp port monitor, enter the following command:
#pmadm -a -p tcp -s lpd -i root -v 'nlsadmin -V' \ -m'nlsadmin -o /var/spool/lp/fifos/listenBSD \ -A'\x02000203640000010000000000000000''
To force the port monitor to recognize the changes you made, use the command
#sacadm -x -p tcp
The next step is to register the client with the server, using the lpsystem command. In addition to registering the client, lpsystem allows you to define the communications parameters that you want to enforce on the connection maintained between both the server and the client after it is invoked. Defined parameters are saved in the /etc/lp/Systems file. Though you can edit it directly using vi, it is recommended that you avoid doing that. The syntax of the lpsystem command is
lpsystem [-t<type>] [-T<timeout>] [-R <retry>] \ [-y"comment"] systemname
in which -t<type> specifies whether the client is System V or BSD.
-T<timeout> specifies the idle time after which the connection should be terminated. The <timeout> can be n, 0, and N, where N is the number of minutes the connection idles before the connection is dropped. If 0 is specified, the connection will be dropped as soon as it idles, whereas n means never time-out. Depending on your environment, you should configure the connection to the one that suits you best. If users occasionally print across the network, you may be better off with the 0 option. This frees up the resources reserved on both systems to service the request as soon as it is honored. If, on the other hand, the frequency of service utilization is high, you may consider configuring the connection to n (never time-out). This way, you save both systems the repeated tasks of establishing, maintaining, and relinquishing the connection every time they ought to respond to a print service request. Added to the saving in CPU utilization on both systems is the saving on bandwidth utilization due to packet exchange pertaining to link establishment and disconnection.
-R<retry> specifies in minutes the duration of time to wait before link re-establishment is attempted, when it was abnormally disrupted.
-y"comment" can be any convenient comment.
systemname specifies the remote system's name to which the communications parameters apply.
Applying the preceding to the example in Figure 23.8, in order to register arts with the print server host engg, you should enter
#lpsystem -t s5 -T n arts
Configuring the Client As in the case of server setup, here too you ought to make sure that you have a port monitor that is properly configured to support network printing services. To do that, enter
#pmadm -l -p tcp
The output should include the following three entries (the first two pertaining to System V support, whereas the third one pertains to BSD client support):
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> tcp listen 0 - root \x00200ACE64000001 -c - /usr/lib/sac/nlps_server #NLPS SERVER
tcp listen lp - root ....
tcp listen lpd - root \x0020020364000001 -c - /var/spool/lp/fifos/listenBSD
If any of the preceding entries is missing, then you must create the associated port services yourself using pmadm. Depending on what is missing, use one or more of the following commands:
#pmadm -a -p tcp -s lp -i root -v'nlsadmin -V' \ -m 'nlsadmin -o /var/spool/lp/fifos/listen5' #pmadm -a -p tcp -s 0 -i root -v 'nlsadmin -V' \ -m 'nlsadmin -o /usr/lib/saf/nlps_server \ -A "\x02000ACE640000010000000000000000"' -y "NLPS SERVER" #pmadm -a -p tcp -s lpd -i root -v 'nlsadmin -V' \ -m 'nlsadmin -o /var/spool/lp/fifos/listenBSD \ -A "\x0020203640000010000000000000000"'
The last pmadm command would be required only if you are setting up for BSD support as well.
Next, register the remote server with the client using the lpsystem command, as discussed in the preceding section.
Now, you have only to create the printer destination; instead of associating it with any particular port, you will associate it with the printer destination that you created on the print server host. To do that, enter the following command
#lpadmin -p<client_printer> \ -s<remote_printer>!<print_server_host>
client_printer specifies the printer destination undergoing creation on the local machine.
remote_printer specifies the print server's printer destination, with which the client_printer is associated.
print_server_host specifies the host name of the system where the remote_printer destination is.
Applying the preceding to the scenario of Figure 23.7, the following is the command to enter at host arts:
#lpadmin -p odie -s garfield!engg
The remaining steps, as you should know by now, are to enable the printer and make it accept print jobs. Hence the commands,
#enable odie #accept odie
To send a print job down the wire to garfield to print, the user must address odie while logged in to arts. For example, to print file monalisa, the user must enter
#lp -p odie monalisa
LP print service on host arts will redirect the print job to garfield destination on host engg.
In addition to the tools required to set up, enable, and disable printers, the LP print service presents the system administrator with a comprehensive set of management tools. Those tools can be applied to change printer configuration, as well to assist in maintenance and troubleshootingsituations. The following subsections describe aspects of printing management and associated tools.
Enabling and Disabling LP Print Service lpsched is the program to start LP print service, whereas lpshut is the program to shut it down. Only login root or lp can start and shut down printing services. All printers that were printing at the time of invoking lpshut will stop printing. Whenever lpsched is restarted, print requests that were disrupted at the time LP service was shut down will print from the very beginning.
Managing Print Requests lpmove is a command that lets you move print jobs from one printer to another. There are, primarily, two scenarios that may prompt you to do that. In one, you may want to disable printing to a printer in order to disconnect it for routine maintenance or troubleshooting. Instead of leaving your users in the cold waiting for their print jobs to materialize, you would move their print jobs to some other printer of equivalent quality. In the second scenario, you may use lpmove for load balancing purposes in case you encounter situations in which one printer is heavily used while another one is sitting idle. The syntax of the lpmove command is
#lpmove <requests> <dest>. Or,
where requests presents lpmove with a list of request id's to move to the printer specified in dest. To obtain the print request IDs, use the lpstat command. Its output should look like the following:
#lpstat garfield-4 root 112 March 24 06:20 garfield-5 root 567 March 24 06:22
where the first column is the print request ID and is made of two components: the name of the printer to which the print job was submitted, and the order in which it is received. The second column displays the name of the user who submitted the print job, followed by the date and time of submission columns.
Assuming that acctlp is an idling printer to which you want to move the print job garfield-5, the lpmove command then becomes
#lpmove garfield-5 acctlp
To move the entire printing load from one printer to another, enter
#lpmove <dest1> <dest2>
To cancel undesirable print requests, use the cancel command. The syntax is
To cancel, for example, garfield-5, enter
Printer Configuration Management Printer configuration management includes tasks such as changing printer class, changing printer port, removing printers, and removing classes. All these tasks can be achieved using the lpadmin command.
To change a printer class, enter
#lpadmin -p<dest> -c<class>
If the specified class does not exist, the class will be created and the specified destination will be inserted into it. To remove the printer from a certain class, enter
#lpadmin -p<dest> -r <class>
If the printer is the last one of its class, then the class itself will be removed as well.
To change the printer port, enter
#lpadmin -p<dest> -v <special_file_pathname>
You may need to do this on occasions when you suspect something went wrong with the original port to which the printer was connected. This reconfiguration will allow you to continue offering print services while Troubleshooting: the defective port.
Finally, to check the configuration of a particular printer, enter
#lpstat -p<printer> -l
In the example that follows, lpstat is entered to check on the configuration of garfield destination.
#lpstat -pgarfield -l printer garfield (login terminal) is idle. enabled since Thu Mar 24 18:20:01 EST 1994. available. Form mounted: Content types: simple Printer types: unknown Description: Connection: direct Interface: /usr/lib/lp/model/standard On fault: mail to root once After fault: continue Users allowed: (all) Forms allowed: (none) Banner required Character sets: (none) Default pitch: Default page size: Default port settings:
whereas to check the configuration of all printers, enter
Print Service User Management User access to LP print service on UNIX systems can be managed and restricted for reasons that may pertain to security or resource allocation and management.
If you carefully examine the sample output of the lpstat -p garfield -l command in the last example, you will see the names of the users allowed access in the "Users allowed" entry. According to the preceding example, no one is either on the allowed or the denied lists. This corresponds to the default security configuration and implies that any logged-in user can send print jobs to printer garfield. If you do not like that, however, you can use lpadmin with the -u option to restrict access to the printer. The syntax of the lpadmin -u command to list users on the allow list is the following:
#lpadmin -p<printer> -u allow:<login-ID-list>
To prevent users from accessing the printer, enter
#lpadmin -p<printer> -u deny:<login-ID-list>
Following is a list of legal arguments that you can include in the login-ID-list:
For each printer, the LP print service maintains deny and allow lists. The way they are used is summarized in the following paragraphs.
If the allow list is not empty, only users on that list are allowed access to the printer. If the allow list is empty but deny list is not, then all users except those on the deny list will be allowed access to the printer.
A user cannot exist on both lists simultaneously. When a user is added to either list, the user's login-ID will be checked and removed from the other one.
For example, to allow users Nadeem, Andrea, and May access to the printer garfield, you enter
#lpadmin -p garfield -u allow:Nadeem Andrea May
Next, you should check that this indeed took place by entering the command
#lpadmin -p garfield -l printer garfield (login terminal) is idle. enabled since Tue Apr 12 05:18:07 EDT 1994. not available. Form mounted: Content types: simple Printer types: unknown Description: Connection: direct Interface: /usr/lib/lp/model/standard On fault: mail to root once After fault: continue Users allowed: nadeem andrea may Forms allowed: (none) Banner required Character sets: (none) Default pitch: Default page size: Default port settings:
Users educated about the use of the -q option with the lp command can assign print queue priority levels to print jobs that they submit to the LP service. Although this can sometimes be a useful feature, it may well prove to be a cause of concern to some of the user community as they find that their print jobs are constantly delayed in favor of those belonging to others of equal or less functional status. Fortunately, the LP print service allows you to set limits on how high a priority can be a assigned to print jobs submitted by users. Using the lpusers different priority limit assignments can be made to apply to different users. The syntax of lpusers is as follows:
#lpusers -q<priority_level> -u<login-ID-list>
in which -q<priority_level> is an integer ranging between 0 and 39, with 0 representing the highest priority level.
-u<login-ID-list> is a comma- or space-separated list of user IDs to whom the restriction applies. The login-ID list argument can have any of the following values:
Users submitting print jobs can assign them priorities as high as they are allowed to assign as set with the -q option.
Setting Up Local Printing on BSD Systems
Setting up printing on BSD systems mainly involves making changes to the /etc/printcap file, creating the spooling directory (also known as the print queue), and editing the /etc/rc file so that the lpd spooling daemon is started at boot time. Here is what these steps involve: /etc/printcap The /etc/printcap file is a database file that contains one record for every attached/enabled printer. In addition to defining the printer characteristics, /etc/printcap records include printer configuration information that is vital to supporting the printer properly. This file includes records for both local and network printers.
Following is an example of what an /etc/printcap record should look like:
# printcap entry for printer goofy goofy|lp:\ :lp=/dev/ttya:br#9600:\ :ms=-parity,onlcr,ixon:\ :sd=/var/spool/goofy:\ :lf=/var/adm/goofy_errors:\ :pl=66:pw=132:
As shown in this entry, /etc/printcap entries contains colon-separated fields. Additionally, the last field must end with a colon ":". The first field of each entry must start with the name that the printer is known by. Printer names are pipe"|" character-separated. In the example, the printer being defined is known as goofy and lp. In fact, lp is a special alias that designates the printer as being the default one. In other words, by virtue of assigning printer goofy the lp printer name, users who submit a print job without specifying the printer name will have their jobs sent to goofy. Consequently, only one printer can be assigned the special name lp, thus designating it as the default printer.
Fields subsequent to the name field are introduced by a two-character code. A field describing a numerical value takes the form code# (br#9600, in the above example). Otherwise, the field takes the form code= (sd=/var/spool/goofy). Following is an explanation of the remaining fields:
There are many more fields that can be included in the /etc/printcap file than what has just been described. You will find, however, that the above ones are the most commonly used. The man pages on /etc/printcap provide comprehensive listing of all the supported field codes including a proper description of each.
Following is a self-explanatory example of an /etc/printcap entry for parallel printer support:
lp|HPLaser:\ :lp=/dev/lp:\ :sd=/var/spool/lp:\ :pl=66:pw=132:\ :lf=/var/spool/laser_errors:
Setting Up Spooling Directories Every printer must have a dedicated spooling directory. Setting up the spooling directory involves both creating it, changing its permissions to 755, changing its ownership to special user daemon, and changing its group to the group daemon. You should be logged in as root when creating/setting up the spooling directories. Following is the command sequence necessary to set up the spooling directory for printer goofy:
# mkdir /var/spool/goofy # chown daemon /var/spool/goofy # chgrp daemon /var/spool/goofy # chmod 755 /var/spool/goofy
Fixing access permissions to 755 on the spooling directory protects it from abusive manipulation by other users, which may result in accidental or malicious deletions of print jobs.
The above completes the minimal steps required to set up printing on BSD systems. To ensure that the print spooling daemon is activated at boot time, check the /etc/rc startup script and make sure that the following lines of code are not commented:
if [ -f /usr/lib/lpd ]; then rm -f /dev/printer /usr/spool.lock /usr/lib/lpd; echo -n `printer' > /dev/console fi
To test the viability of the printer setup, use the lpr command to print a test page as in the following example:
# lpr -P goofy testfile
Setting Up Network Printing Under BSD
Setting up network printing under BSD is far less complex than under SVR4. As in SVR4, the setup includes configuring both the print server (the host where the shared printer is attached) and the client (the host printing to the shared printer).
Setting up the shared printer on the server is not any different from local printing setup. The steps are identically the same as described on the previous pages. You need not do anything special to allow for printer sharing aside from ensuring that hosts authorized to access the server for printing services have their names in the /etc/hosts.equiv file on server host.
Configuring the client to recognize and print to remote printers simply involves adding an entry, similar to the following one, in the /etc/printcap file:
lp|remote printer|:\ :lp=:rm=tenor:rp=goofy:sd=/var/spool/lpd:
According to this entry, the client print daemon recognizes the remote printer as being the default printer. Since the lp field is left blank (i.e. lp=), the printer is assumed remote, and is attached to remote machine tenor (rm=tenor). The rp=goofy capability identifies the remote printer name as goofy, whereas sd identifies the /var/spool/lpd directory as being the corresponding spooling directory.
To print to the remote printer, the user ought to run the lpr command. No special options or command line parameters are required to make it work with non-local printers. If the remote printer is the client's default printer, simply enter:
# lpr filename
Otherwise, use the following form for the lpr command:
# lpr -P printername filename
where, printername is the name by which the printer in known locally, not its name as set on the remote host.
Managing Print Services Under BSD
As in UNIX SVR4, BSD provides the tools necessary to proper manage and administer printing service. Both the lpc and lpq commands help you do most of the desired administrative tasks.
Using lpc, a system administrator can manage printers which are defined in the /etc/printcap file. lpc includes support for starting/restarting/stopping a printer daemon, selectively enabling or disabling a particular printer, displaying printer status, status of printer daemon, and status of print queues, and as reordering print jobs in a given queue.
In its basic form, lpc assumes the following syntax:
lpc [command [parameter]]
where command specifies the action that you want lpc to take on the object specified by parameter. If no command is entered, lpc is invoked in an interactive mode as shown below:
# lpc lpc>
Subsequently, commands can be entered, and responded to interactively at the lpc> prompt. As in the shown here:
# /usr/etc/lpc lpc> down goofy lpc>
Typically parameter specifies the printer name. Supported commands include the following:
Refer to the man pages for details on using the lpc command.
Connecting a PC to UNIX Systems
Rather than purchase terminals, many users prefer to run UNIX sessions right from their desktop DOS or Windows 95-based PCs. This is mainly attributable to the low cost of the PC, its increased processing power, and the additional flexibility of being able to easily toggle back and forth between DOS applications and a UNIX session. This section describes two methods by which you can establish a connection with the UNIX system using the DOS platform. The two methods are as follows:
Connecting the PC Using COM Ports
Depending on how you are going to do it, configuring a PC to connect to a UNIX host via a COM port is the easier and less costly of the two methods. If both systems belong to the same site, where there is no requirement for a telephone wire to connect both machines, then a cross-wired cable is all the additional hardware you will need along with the COM port that is commonly readily available on your PC. Any communications software with decent terminal emulation capabilities can be used to emulate some the terminals that UNIX recognizes. I used to use Procomm Plus and I was satisfied with it until I decided to go the TCP/IP way for reasons that will be discussed later.
Configuring a PC to serially connect to a UNIX host involves some preparation on both systems. Before making any move, however, you must check on the availability of the following resources:
Additional requirements include two modems and two straight-through cables, if you are configuring a connection over a telephone wire, or a cross-wired cable, as discussed earlier in this chapter, to directly connect the PC to the UNIX system.
Configuring the UNIX system for support to tty port services was discussed earlier in this chapter.
Configuring the PC is a very simple matter that basically involves configuring the communication software to the same communication parameters implemented on the UNIX side of the connection. The parameters include baud rate, number of bits per character, parity, and number of stop bits.
Configuring the Modems The following are general guidelines that you should observe when configuring the modems:
Make sure that the modem you are installing at the UNIX end supports quiet mode. This mode is required in order to stop the modem from sending response codes to the port. Also, echo should be disabled. Failure to observe both of these rules may result in having the UNIX system "believe" that the echoed characters are in partial response to the login prompt it sent to the PC. This may lead to an endless sequence of login and password prompts, and so on.
Should you run into the problem of having user sessions unexpectedly suspending, try to re-create the problem. If, upon sending manually an XON (press Ctrl+Q), character communications resume, then you may need to disable XON/OFF flow control to rely only on RTS/CTS.
Set the modem connected to the UNIX system to autoanswer mode.
Connecting to UNIX via TCP/IP
TCP/IP is another way by which you can connect PCs in your environment to the UNIX system. This solution, however, is a bit more expensive than using COM ports. This is due to the investment in the network interface card (NIC) and the necessary software for implementing the TCP/IP suite of protocols in addition to the cabling cost incurred per workstation. Given the advantages of this solution, and depending on the intended use of the connection, you may find it worth the money and effort to take this route. Using TCP/IP, you will not only be able to establish a telnet session with the host, but you also will be able to use ftp for file transfers between the PC and UNIX, and rsh to remotely execute a UNIX command without having to necessarily log in to the system. Also, if you are using something like Novell's Lan Workplace Pro for Windows 95, you will be able to invoke multiple UNIX and Microsoft Windows applications simultaneously. You also will be able to cut and paste (to your heart's desire) between applications.
As in the COM port option, here too you have to set up both ends of the connection properly in order for them to communicate.
The method that you will be using to install TCP/IP on the PC depends to a large degree on the vendor from whom you purchased the software. You are required, however, to do the following:
Depending on the vendor, the TCP/IP software comes with ranging tools to help you troubleshoot and manage your PC on the network. For a minimum, any decent implementation of TCP/IP should provide tools such as the ping and netstat commands. Use these tools in case things fail to work properly.
Connecting X Terminals
Until X terminals emerged a few years ago, ASCII dumb terminals were almost exclusively the machines that users had at their disposal for accessing UNIX systems. Due to their nature, these terminals fell short of meeting the ever-increasing demands of engineering and scientific applications for graphical output. With X terminals, a new era of computer-to-human interface began. These terminals not only met the craving need of engineering and science applications for graphics, but they also presented UNIX users with a far more superior, and elegant, user interface.
An X terminal is a component of the X Window System technology (hereafter referred to as X, or X11) that was developed at the Massachusetts Institute of Technology, and is currently maintained by a consortium of universities and vendors.
One of X's greatest attributes is that it can be brought up on any platform. Though it was initially implemented in UNIX environments, X is now equally available to other platforms ranging from mainframes to DOS workstations. This platform independence is due to the mechanism and model that were put together to make X work: the X protocol and client/server model. As you will see later on, this has far-reaching implications as to how users will be able to work in multiplatform/multivendor environments.
To setup X terminals, it is essential that you understand the governing concepts that drive this technology. This section will therefore start with an examination of its various components, including the client/server model that X follows. Some terms will be introduced and defined to make you more familiar with the associated jargon. Setting up X and X servers will be discussed next. The focus of the discussion will preclude the many different kinds of GUI interfaces that are currently available to run on top of X, concentrating more on how to bring the engine (X platform) and its associated gear to life.
The Architecture of X
X's architecture is based on two components: the client/server model and the X protocol.
The Client/Server Model of X A client server/model follows a mechanism by which an application is split into two components: the so-called backend and frontend. In the database client/server technology, for example, the frontend runs at the user's workstation and is termed the client, whereas the backend runs on a remote host that is shared by all authorized users, and is called the server. The database server acts as the main repository of data that clients need. Instead of having an entire file transferred to its machine from the server, the client uses scope-and-filter techniques while requesting only the data relevant to its needs for subsequent processing. From what has just been said, the client/server model components could be expressed as a matter of which is managing access to a resource, versus which is requesting use of the resource. The server component is the access-resource manager, whereas the client component is the one requesting access to and use of the resource.
The application is split into the following components: X client and an X display server.
An X client handles all data processing aspects of an application, except for the I/O interaction, which it delegates to a server process. The server process could be running on the same machine or a terminal located elsewhere in the environment. This implies that, unlike database and other familiar server technologies, the X display server belongs to the user's machine where actual I/O and user interface capabilities are provided. Clients, therefore, become the shared resource that all users can access and run remotely.
The X Protocol Rather than base the X client/server model on a particular set of software and hardware resources, which could restrict its portability across platforms, X architects chose to base it on a protocol mechanism called X protocol. In doing so, vendors and developers of X applications were insulated from platform-related concerns and specifics. Applications complying with X specifications can be easily ported to any environment, while having X servers mediate the I/O interaction with the physical display units. Having said that, this clearly implies that an X server presents applications with a virtual display unit that they can manage. The display server maps I/O primitives, passed to it by applications to physical actions on the actual display unit.
Another aspect of X protocol worth mentioning is that it builds on some of the most commonly deployed transport protocols, including TCP/IP, IPX/SPX, and DECnet to enable clients and servers to talk to each other. A user on an X terminal, with multiprotocol support, can invoke one session with a mainframe while maintaining another with a UNIX system, and yet another one across a dial-up line.
From what has already been said about X, it can be concluded that X is a network-based graphics engine. It allows users to connect to, and run applications on, remote systems while handling I/O interaction using locally available graphical terminals. Being an engine implies that readily available GUI interfaces are built on top of X, rather than being part of it.
Central to X functionality is the concept of resources. A resource is a configurable attribute of an application. Examples of resource attributes are the font the application uses, background color, initial location, and size of an application window.
The fact that the same X client may have to deal with different servers means that it must be supported with a configuration mechanism that is flexible enough to deal with ranging hardware capabilities and user preferences. Examples of hardware differences are monitor color and resolution capabilities. Also, one user's preferred color, font, and window location and size may not agree with someone else's. It can be concluded that X applications cannot be developed with built-in support for any hardware type or for the developer's perception of how the user interface and preferences should look. Users should be allowed to have a choice of hardware and be able to configure an application's output however they feel is best for them.
X provides for this capability using one of two methods: command-line options and resource definition files.
Independent of the method you are using, when an application is invoked, an X display manager will autoload the associated attributes onto your server (more on this later). This provides the I/O capability and interface you have defined.
Setting X Resources with Command-Line Options In this method, users define resources upon invoking an application using command-line options. Most X applications allow users to define resources using the same command option names. The following are examples of the most commonly used arguments:
Table 23.5. Most common user-definable X resources.
For example, say that a user wants to invoke xterm (an X terminal emulation client) titled "X Terminal" with a blue background color, gray border, and the window initially located at the upper-left corner of the monitor. The user then has to enter the following command:
% xterm -display arts:0 -title "X Terminal" -bg blue -bd grey -g +1+1
Given the number of clients that a user may have to invoke simultaneously, this method of loading resources can be tedious and is prone to errors.
Defining Resources Using Resource Definition Files To alleviate the tedium of defining resources using command-line options, X provides the following two resource definition files: Xresources and $HOME/.Xresources. Both of these files contain per-application lists of attribute assignments. Xresources contains global definitions applying to all X servers, whereas $HOME/.Xresources may contain user-specific definitions. Both sets of resources are loaded by the xrdb program whenever a connection is established with an X server. Sample $HOME/.Xresources file contents are as follows:
!xclock resource definitions: xclock*update: 1 xclock*analog: false xclock*chime: false xclock*geometry: -0+0 !xterm resource definitions: xterm*title: XTerminal xterm*background: grey xterm*foreground: black xterm*geometry: 40x24+1+1 xterm*scrollBar: true
The first set of resources pertains to xclock. According to what is shown, the clock is to be updated at the rate of once a second, displayed in digital format, and the chime is disabled. The second set of resources pertains to xterm, and that set specifies a window title XTerminal, a yellow background color, black text, scroll bar enabled, and a window size of 40x24 displayed at the upper-left corner of the monitor.
A window manager is an X client that normally is invoked during start-up on an X session, from the user's start-up $HOME/.xsession script file. It can also be invoked on the command line.
Window managers allow users to manage their applications' windows whether moving, resizing, or reducing them to icons.
There are many different flavors of window managers. Tab Window Manager (twm) is the one that comes with MIT's distribution of X. Open Look provides olwm, whereas OSF/Motif provides mwm. Linux, additionally supports so called Free Virtual Window Manager (fvwm).In this chapter, reference will be made to twm only.
twm behavior is governed by the system.twmrc configuration file in the /usr/X/lib/twm directory (please refer to the note below for information on X resource files on the different UNIX platforms). You can edit this file, changing its default behavior to anything that suits your users' needs.
Setting the Shell Environment Variables
Two shell environment variables need to be taken care of, in order to successfully start an X session. These are PATH and DISPLAY.
PATH should be modified to include the path to X client programs. This can be done in the user's start-up script $HOME/.xsession. The script should include:
PATH=$PATH:/usr/X/bin export PATH
DISPLAY X environment variable specifies to the client the name of the host, and display number, to send its output to.
X distinguishes between displays and screens. Figure 23.8 tries to make the distinction clear. In X, a display is a collection of monitors that share a common keyboard and mouse. Shown in Figure 23.8 is an X server that has one display and two monitors. The monitors are referred to as screens and are numbered starting with 0.
Hence an appropriate setup of the DISPLAY variable should take care of both the display and monitor to which the output is sent. The DISPLAY variable can be specified using the following format:
DISPLAY can be set in the user's login script. It can also be set manually as a command-line argument, using the -display option, when a client is being invoked:
% xterm -display arts:0
The X Display Manager
The X Display Manager (xdm) is the preferred way of starting up an X session. xinit is another option. This discussion is restricted to xdm only.
In SVR4, xdm is started as a daemon when the system is booted. It is invoked by one of the /etc/rc2.d scripts. On my system the startup script is S69xdm.
Once invoked, xdm provides users with a graphical login window where they must enter their user IDs and passwords. Once authenticated and logged in, xdm automatically loads resources to X servers and starts X clients as specified in the user's $HOME/.xsession startup script.
xdm is a customizable X client. Its behavior depends to a large degree on what is in its configuration files. All xdm configuration files are in the /usr/X/lib/xdm directory. They are as follows:
*xdm-config *Xresources *Xsession *Xservers *Xaccess *Xsetup_0 *GiveConsole *TakeConsole
Some of these files pertain to different versions of X. In the following subsections, the purpose of each file is described in the context of starting X server sessions. User-specific files (that is, $HOME/.xsession, $HOME/.Xresources, and $HOME/.xsession-errors) are described as well.
xdm-config xdm-config is the first file that is read by xdm when spawned. This file primarily defines where the rest of the configuration files listed previously belong. Following is an example of the its contents:
DisplayManager*session: /usr/X/lib/xdm/Xsession DisplayManager*resources: /usr/X/lib/xdm/Xresources DisplayManager.errorLogFile: /dev/X/xdm-errors DisplayManager.pidFile: /dev/X/xdm-pid DisplayManager.keyFile: /usr/X/lib/xdm/xdm-keys DisplayManager.servers: /usr/X/lib/xdm/Xservers DisplayManager._0. authorize: true DisplayManager._0.setup: /usr/X/lib/xdm/Xsetup_0 DisplayManager*authComplain: false
It can be seen that the preceding xdm-config file contains some self-customizing resource definitions.
Xservers and Xaccess There are two methods by which xdm knows which X servers to connect to. One method pertaining to release 3 of X (also referred to as X11R3) relies on the Xservers file. In Xservers, the administrator has to maintain a list of names of X servers to be managed by xdm. This was the only way available to xdm to connect to X servers. Following is a sample of the contents of an Xservers file:
0: local /usr/X/bin/X engg:0 foreign May's X terminal arts:0 foreign Andrea's X terminal
Note how, in all entries, the host's name and display number (colon separated) are followed by one of two terms, local or foreign. local means the X server is running on the console, whereas foreign means it is on the network.
Because Xservers was read only when xdm was started, however, this posed serious problems as X terminals were brought up later on and as others were temporarily turned off. The only way the administrator could force xdm to recognize a newly brought up X server was by restarting. This involves sending xdm a SIGHUP signal using the following command:
#kill -HUP <pid_of_xdm>
where the process id can be found by entering
To remedy this problem, X Display Manager Control Protocol (XDMCP) was introduced in X11R4. XDMCP is a protocol that is implemented at both ends of the connection: the X server and the xdm client. An X server with XDMCP support is responsible for requesting xdm for a connection and should not require an entry in the Xservers file.
To request a connection, an XDMCP-compatible server issues one of three types of queries, depending on how it is configured. The three types are as follows: Direct query: This is a directed query addressed to a specific host.
Broadcast query: The server sends out a general query addressed to all xdm
clients requesting a connection. In this case, the X server connects to the first
xdm client responding to the query.
Xaccess is an XDMCP-related file. As the name implies, it provides for a degree of access control at the machine level. This means that only hosts with their names listed in Xaccess will have their request to connect honored, receiving a login window. A user still has to undergo the authentication process by providing the login ID and the password.
The Xresources File The Xresources file contains resource definitions that ought to be loaded to X servers upon establishing the connection. All X servers are subject to the same treatment. The first thing that xdm does upon connecting is send a login window, which requires that associated resources be loaded. As for user-specific resources, they are loaded by the server after the user logs in, based on either $HOME/.Xresources and/or $HOME/.xsession files.
Xsession and $HOME/.xsession files Xsession and .xsession files are start-up scripts that execute upon user login. Xsession is a system-wide script that executes every time a user logs in to the system. .xsession is the user's personal script, which is executed by xdm only if Xsession (the system script) calls for it. It is mainly responsible for setting up the user's environment properly and the subsequent invocation of some of the user's applications. Following is a sample .xsession file.
#!/bin/sh #Update the user's PATH variable to include /usr/X/bin where all the #X clients can be found. PATH=$PATH:/usr/X/bin export PATH #load and merge user resources as defined in $HOME/.Xresources xrdb -merge $HOME/.Xresources #start user's applications xclock & xterm & xcalc & #start the window manager twm
The preceding .xsession file starts by modifying the PATH variable to include the directory where all the X binaries are stored in the file system. Next, xdm calls and executes xrdb to load and merge the X client resources with those already loaded from Xresources at the X server. This suggests that the user is maintaining a .Xresources file in the home directory. A .Xresources file may have the following contents:
!xclock resource definitions: xclock*update: 1 xclock*analog: false xclock*chime: false xclock*geometry: -0+0 !xterm resource definitions: xterm*title: XTerminal xterm*background: grey xterm*foreground: black xterm*geometry: 40x24+1+1 xterm*scrollBar: true !xcalc resource definitions: xcalc*title: XCalculator xcalc*geometry: +0+0
It is important that resources are loaded first, explaining why xrdb is called first and running in the foreground.
After resources are loaded, application clients are called next. Note how they are made to run in the background. Otherwise (that is, if applications are run in the foreground), the script will hang pending the completion of the application.
Finally, twm (Tab Window Manager) is loaded in the foreground. Unless this is done, execution of the script completes and exits, which may reset your X server. Hence, the last application to load should always be running in the foreground.
Now that you have a feel for how the user-specific files (that is, .Xresources and .xsession) are used to set up the user's X server session, take one more look at the Xsession that made it all happen. As noted before, .xsession is called and executed from the system-wide /usr/X/lib/xdm/Xsession. Following is a listing of the Xsession file that comes within X11 distribution:
#!/bin/sh exec > $HOME/.xsession-errors 2>&1 case $# in 1) case $1 in failsafe) exec xterm -geometry 80x24-0-0 ;; esac esac startup=$HOME/.xsession resources=$HOME/.Xresources if [-f $startup]; then exec $startup else if [ -f$resources]; then xrdb -load $resources fi twm & exec xterm -geometry 80x24+10+10 -ls fi
Note the following points about the script:
GiveConsole and TakeConsole Configuration Files GiveConsole and TakeConsole are scripts that, as their names imply, change the ownership of the system console to the user, and back to root, respectively.
To summarize the X startup and user session establishment process, xdm is invoked as daemon by the /etc/rc2.d/S69xdm script when the system enters the multiuser state. Upon starting up, xdm fetches its /usr/X/lib/xdm/xdm-config file to determine the names and locations of its configuration files. It starts by loading Xresources file into the X servers listed in its Xservers file, or into those who successfully queried it using the XDMCP protocol. A login window is subsequently sent. When a user requests a login by entering a valid login ID and password, xdm fetches the /usr/X/lib/xdm/Xsession script for execution. Subsequent actions are determined depending on what was included in this script. It is recommended that user session handling and configuration be dealt with using .Xresources and .xsession in the manner discussed previously. xsession is equivalent to a personal login script in that, if it exists, it invokes the xrdb client to load user resource definitions in the .Xresources file, and to load user applications that are included in the .xsession script.
X Server Access Security
The basic premise of the X Window System is that it allows an X client to send its output to the X server specified using the -display option. This being the case, you should be able to predict the security hazard that is associated with this mechanism. Unless your X display server is properly secured against unwelcome X clients, hackers can maliciously connect to it and crash your session. In the following few paragraphs, one security control method is described, along with its advantages and disadvantages. For more on X security, refer to X Window System reference manuals that ship with UNIX.
xhost Access Control Method Using this method of protection involves the use of xhost client and the /etc/Xn.hosts file, where n refers to the display number to which the access control file applies. Because most systems have one display, reference will be made only to the /etc/X0.hosts file. The X0.hosts file must be created on the X server and edited by the system administrator to include the names of hosts from which clients are allowed access to the X server. So, if the /etc/X0.hosts file contains the following host names:
then clients on arts, engg, and fin can establish X sessions with the X server and have their outputs sent to it.
xhost is a command that also can be used to add hosts to the server's access control list. The syntax of xhost is as follows:
#xhost [+|-] [hostname]
To authorize a host, enter
#xhost + hostname
whereas to remove a host from the server's access control list, enter
#xhost - hostname
In the following example, host sam is allowed access, whereas host view is not:
#xhost + sam - view
If you want to allow all hosts access to the server, enter
and to disable access, enter
It must be kept in mind, however, that currently established sessions will not be affected by the "xhost -" commands. Only future connections will be refused.
A question that may have occurred in your mind by now is, what if you want to invoke clients on host view, or any other host, which is denied access to your server? The answer to that is tough. You simply cannot do it! X Windows System provides a few other alternatives to the xhost control method. An example is the MIT-MAGIC-COOKIE-1, which is more of a user-based authentication process in which restrictions are enforced on users rather than on hosts.
Types of X Servers
No discussion of X is complete without a degree of exposure to the different types of X servers and their ranging capabilities.
Originally, a few years ago, X servers and X terminals were synonyms. Talking of one used to imply the other. This is because X servers used to be supplied on terminals tailored to handle X services, thus providing users with GUI capabilities, as opposed to the ASCII terminals, which handled characters only. Today, in addition to X terminals, an X server can be brought up and delivered to users on a variety of platforms, thanks to X protocol design, which provided for X's independence from operating systems as well as hardware. Among the relative newcomers to the X market are PC-based implementations of X servers. An example is the eXceed series of X servers for DOS, OS/2, and Windows by Hummingbird Communications Ltd.
X terminals are what the name implies: dumb terminals with X Windows support. They are therefore better suited to support graphical applications including arts, science, and engineering. X terminals come with different features and capabilities, some of which are as follows:
PC X Servers As mentioned earlier, PC-based X servers are relative newcomers to the X Windows market. The broad install base of PCs, the improved performance of Intel CPUs, and the continuing drop of PC hardware cost inspired vendors to develop X server software that nears the performance of dedicated X terminals. Some vendors went farther by implementing the X server software as an MS Windows application. This made them more attractive by allowing the user the luxury and flexibility of maintaining DOS, Windows, and UNIX sessions. And by supporting the Inter Client Communications Conventions Manual (ICCCM), X servers allow users to interchangeably cut and paste between those environments. Figure 23.16 illustrates how eXceed/W, a high-end X server by Hummingbird Communications Ltd., provides this support. It illustrates the use of the X server software to establish multiple X sessions with clients running on different host platforms including IBM, HP, and an MS Windows application.
There are some performance-related factors that need to be considered before trying to install PC X servers. These are as follows:
Obviously, the more CPU power and RAM memory, the better the X server will run. For optimal performance, however, you need no less than a 386 CPU with clock rates starting from 16 Mhz. Though most vendors require memory sizes in the four-megabyte range, you will find that this range delivers the service but not the performance. Therefore, you may still need more memory. Of all the factors, the video graphic interface may prove to be the single most important factor on your PC. Remember that the idea of X is to provide users with the elegance and capabilities of the associated GUI interfaces. No matter how fast X is on the PC, there is nothing as annoying as poor, if not disgusting, graphics. There are many implementations of X, with each supporting a variety of graphical interfaces with ranging capabilities. Depending on the nature of what you intend to do on the PC X server, you ought to budget for the suitable interface and monitor. Finally, a 16-bit interface card provides better performance on the wire, and consequently contributes to the improved overall performance of the X server.
Not all PC X servers are born equal. Some currently available implementations are more compatible with the latest distribution of X than others. Some even may have more capabilities built into them, or they may be easier to install and configure. Following is a list of features and capabilities to help you better assess the PC X options that you may have at your disposal.
X compliance X11R6: Make sure that the PC X server you choose is 100 percent compatible with X11R6. Non- or partial compliance may even prevent some of the application from displaying on your PC. Lack of compatibility with ICCCMP protocol may impair your ability to cut and paste across application windows.
XDMCP full compliance: Though users will always be able to login and start an X session using protocols such as telnet, rlogin, and sh, today XDMCP is the preferred method of logging in to X hosts. It also relieves you of the headaches associated with the older way of administering connections using the Xservers configuration file.
MS Windows support: With the user community moving closer by the day to MS Windows, you may consider an implementation that integrates both environments. This is particularly useful if the PC X server you choose is ICCCMP compatible, which allows you to freely cut and paste across application windows.
Transport support: The PC X server of choice should provide the same level of transport support that is compatible with already deployed protocols supporting your X clients. Most PC X servers support TCP/IP, but not as many support additional protocols. To access, for example, X clients running on UnixWare using IPX/SPX transport, you will need a PC X server such as eXceed/W. Another aspect of transport support is the maximum number of connections the X server can simultaneously allow.
X traces capability: This is a diagnostic capability that may prove extremely helpful in troubleshooting X connections.
Among the resources that UNIX system administrators are required to manage are ASCII terminals, modems, printers, and X servers. To manage these resources, different flavors of UNIX provide different sets of tools. UNIX SVR4 presents system administrators with a cohesive set of concepts and tools that come under the hood of Service Access Facility (SAF). SAF recognizes a three-level hierarchy of processes: sac (service access controller), port monitors, and port services. sac is at the top of the hierarchy, and is responsible for invoking and managing the port monitors, which are mid-level processes. Port monitors are responsible for invoking and managing port services, which run at the bottom of the SAF hierarchy. There are two types of port monitors: ttymon and listen. Whereas ttymon takes care of service requests received via the serial (or tty) ports, listen takes care of across-the-network services.
Once SAF is setup appropriately, the administrator can provide all kinds of services, including dial-in access, print services access, and access to X clients running on the UNIX host. Enough details for setting up these services were presented in this chapter to allow the administrator to successfully bring up a similar environment in his workplace.
Under BSD, device management lacks the unified approach that SVR4 supports. Instead, system administrators are required to deal with the tasks of device configuration and management using different set tools and interfaces.
Finally, most UNIX systems come today equipped with support for graphical user interface (GUI). GUI implementations on UNIX are built on top of what is known as X server/client graphics engine. This chapter presented detail of generic X setup, leaving to specialized books on X administration a more comprehensive and precise treatment of the subject matter.