UNIX Unleashed, System Administrator's Edition
Salim Douba
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:
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.
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>
NOTE: Do not be surprised, upon checking the /etc/inittab file, if you see entries pertaining to ttymon port monitor. There is no contradiction between what you see and what has already been explained. Simply put, SVR4 allows a so-called "express mode" invocation of ttymon by init. This particularly applies to the case of the console port. You will still be able, however, to create instances of ttymon that are controlled and administered by sac.
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.
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.
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.
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.
| Process Filename | Invoked by Admin Command | Admin Filename | config | |
| sac | init | /etc/saf/_sactab | /etc/saf/ | _sysconfig sacadm |
| port monitor | sac pmadm | /etc/saf/<pmtag>/_pmtab /etc/saf/<pmtag>/_config | ||
| port service | port monitor | optional | pmadm |
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:
Figure 23.1.
Flow chart illustration of SAF initialization process.
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.
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:
| STARTING: | sac is in the process of starting it. This is a transitional state between NOTRUNNING and ENABLED or DISABLED. |
| ENABLED: | The port monitor is running and is accepting connection requests. |
| DISABLED: | The port monitor is running but refusing connection service requests. |
| STOPPED: | The port monitor is undergoing the shutdown process. This state is transitional from ENABLED or DISABLED and NOTRUNNING. |
| NOTRUNNING: | The port monitor is not running. None of the port services associated with it is currently accessible. |
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
NOTE: When a port monitor is removed, its associated directories are not cleaned up and deleted. To avoid confusion in the future, you may have to take care of that yourself.
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
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 :
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 :
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
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
CAUTION: A record that you delete may belong to a hunt sequence, in which case it is your responsibility to restore integrity to the affected sequence.
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.
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.
Figure 23.2.
listen's port service address format.
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 100.0.0.1 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
00020203640000010000000000000000
TIP: To avoid dealing with decimal-to-hex conversions to figure out the hexadecimal equivalent to your host IP address, you can use the lpsystem -A. Figure 23.3 demonstrates the use of lpsystem -A output in order to figure out the host's IP address in hexadecimal notation.
Figure 23.3.
Using lpsystem -A to find the hexadecimal equivalent of the host's
IP address.
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
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).
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.
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.
Figure 23.4.
Wiring diagram and corresponding pin definition of a DB25-to-DB25 RS232C/D straight-through
cable.
Figure 23.5.
Wiring diagram of a DB9-to-DB25 straight-through cable.
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.
CAUTION: In cases in which one end of the cable is a DB-25 connector and the opposite end is a DB-9, the cable must be wired as shown in Figure 23.6.
Figure 23.6.
Null modem wiring arrangements corresponding to different combinations of connectors.
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.
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.
| Switch | Position | Function |
| 1 | Up | If the computer asserts its DTR low, the modem reacts by hanging up the line. |
| Down* | Forces the DTR permanently high, which means the modem will no longer have to worry about this signal. | |
| 2 | Up* | Forces the modem to respond to modem dialing and initialization commands in English. |
| Down | Forces the modem to respond using numerical messages. | |
| 3 | Up | Suppresses result codes, thus overriding switch 2. |
| Down* | Enables result codes. | |
| 4 | Up* | AT commands are echoes as they are entered. |
| Down | AT commands are not echoed. | |
| 5 | Up* | Modem answers the phone. |
| Down | Modem does not answer the phone. | |
| 6 | Up | CD is asserted when a carrier is detected; this allows the computer to know when a call is received. |
| Down* | CD and DSR are forced permanently high. | |
| 7 | Up* | Modem is attached to single-line phone. |
| Down | Modem is attached to multiline phone. | |
| 8 | Up | Disables the modem from recognizing and executing modem commands. |
| Down* | Modem's intelligence is enabled; modem recognizes and executes modem commands. |
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.
| Command | Significance |
| AT&F | Reset modem to factory settings |
| ATDP | Dial using Pulse tone |
| ATDT | Dial using Touch tone |
| ATE0 | Enable local echoing of commands |
| ATE1 | Disable local echoing of commands |
| ATQ0 | Enable result codes |
| ATQ1 | Disable result codes (that is, known as the quiet mode) |
| AT&W | Write settings to nonvolatile memory |
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.
| Command/Response | Explanation |
| #cu -l term/01 | A command: I want to talk to the modem. |
| Connected | A response: Go ahead. |
| AT | A command: Do I have your attention? |
| OK | A response: Yes you do! |
| AT&F | A command: Reset to factory settings. |
| OK | A response: Done! |
| AT&C1 | A command: Use CD to indicate carrier detection. |
| OK | A response: Done! |
| AT&D2 | A command: Drop the connection when DTR drops. |
| OK | A response: Done! |
| ATE0Q1 | A command: Disable local echo, and keep quiet (that is, disable result codes). |
| OK | A response: Done! |
| AT&W | A command: Save settings into nonvolatile RAM. |
| OK | A response: Done! |
| ~. | A command to shell out to UNIX requesting disconnection, and going back to the UNIX shell. |
| Disconnected | A response: Granted! |
# 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/##
ATDT <phone_number>
9. If the modem is intended for dial-out use, test it by dialing into it. If it fails to respond properly, try the following Troubleshooting: tips: Verify that the modem is set to Autoanswer mode. Verify that echo is turned off. Verify that result codes are disabled (that is, the modem is set for quiet mode). Make sure that you always write modem settings to the modem's nonvolatile memory using the AT&W command.
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).
NOTE: TERMCAP is another shell environment variable that should be set to the name of the directory where the database is maintained.
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 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:
| /etc/ttys | Terminal line configuration file. |
| /etc/ttytab | This is SunOS's version of /etc/ttys file. Both files will be addressed shortly. |
| /etc/gettydefs | Terminal line settings database. Similar to /etc/ttydefs under SVR4. Consequently, it won't be described here. |
| /etc/gettytab |
Includes entries for initializing terminals to desired line speed(s). Following are contents of a sample /etc/gettytab file: c|std.300|300-baud:\ :nd#1:cd#1:ap#300: :nd#1:cd#1:ap#300: x :fd#1:sp#1200: 2|std.9600|9600-baud:\ :sp#9600: This gettytab file has entries for initializing terminals to three different baud rates, 300, 1200, and 9600 bits per seconds. |
| /etc/termcap | Terminal type definitions database. This database defines the capabilities of each of the terminal types it supports. Examples of supported terminal types are vt220, and wyse60. Again, this file is similar in contents and purpose to SVR4's /usr/lib/terminfo explained earlier in the chapter. |
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
| serial_port | Is the name of the special file in the /dev directory. Remember that special filenames, under BSD, assume the form tty##. tty00, for example, refers to /dev/tty00, the first serial port that is supported by the host. | ||||||||
| command | Is the name of the program that init must respawn to control and monitor
this serial port. For most purposes the program being specified (and consequently
being invoked) is getty. Under BSD, getty is the counterpart to
ttymon-type port monitor under SVR4, described earlier. Along with the specified
command, a parameter specifying the line settings is normally included. The parameter
provides a pointer to a record in the /etc/gettytab file. Following is an
example of the contents of the command field: /usr/etc/getty std.9600 According to this command, init spawns getty on the affected port (described in the first field) and initializes it to 9600 bits per second. std.9600 is just a label specification referencing a line setting in the /etc/gettytab, file as noted above. |
||||||||
| terminal_type | Is the name of the terminal type being connected to the serial port. The type described
in this field serves as a pointer to a record in the /etc/termcap terminal
settings database. For example, if this field is set to vt100, the /etc/termcap
database is searched for a record describing the capabilities of the vt100
terminal. Subsequently, the corresponding /etc/termcap record is used in
initializing the serial line for proper support for the connected terminal type. The terminal_type field supports options such as network (to imply virtual terminal), unknown (to imply modems or unknown terminals), and dialup (again, to imply modem lines). |
||||||||
| status | This field can contain multiple keywords. Recognized keywords include:
|
Here is a partial listing of the contents of a sample /etc/ttys file:
| #name | getty command | type | status |
| console | /etc/getty std.9600 | vt220 | on secure |
| tty00 | /etc/getty std.2400 | vt100 | on secure |
| tty01 | /etc/getty std.19600 | unknown | off |
| tty02 | /etc/getty std.19600 | dialup | on |
| tty03 | /etc/getty std.19600 | unknown | off # dialout |
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
or equivalently,
# 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,
| filename | Is the name of the device special file. Continuing on the above example, this would be cua0. |
| [c] | [b] | Is the nature of the device undergoing creation. c indicates a raw device. A raw device deals with characters individually rather than in blocks of characters, whereas b indicates a block device. For modems, the device of choice is a raw device. Correspondingly, this parameter should be always set to c. |
| major | Is the major device number. The major device number designates the device class. Put differently, major acts more like a pointer to the device driver routines in the kernel that support this class of devices (i.e. the serial device driver in our case). |
| minor | Is the minor device number. It designates the device subtype within the device class. Continuing on our example, the minor device number corresponding to cua0 provides a pointer to the modem dial-out routines within the driver designated by major. |
# ls -l /dev/ttyd0 crw--w--w- 1 root 12, 0 Nov 26 22:25 /dev/ttyd0
2. The /dev/cuan device corresponding to the /dev/ttydn port should have its major number identical to that of /dev/ttydn, whereas its minor number should 128 more than that of /dev/ttydn. Again, continuing on our example, this implies that the major and minor numbers corresponding to /dev/cua0 should be set to 12 and 128. Use the following mknod command to create this file:
# 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.
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).
Creating ttySn Device File
Should your Linux system fail to have any of the /dev/ttySn files, you can easily create the appropriate file by using mknod in a similar way to the description provided in the previous section. Major and minor numbers corresponding to any of the devices are well defined in the man pages. To look up the exact details of mknod command that apply, enter:
# man ttys
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:
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.
BSD and Linux Printing
The print daemon on BSD-derived UNIX systems is lpd. BSD systems do not recognize print classes that SVR4 supports.
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:
#/usr/lib/lp/lpsched
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
#accept dotmatrix
and to logically turn it on (that is, allow it to do the printing), enter
#enable dotmatrix
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.
Figure 23.7.
Concept of print servers illustrated.
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
Figure 23.8.
X displays and screens.
#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
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>
in which
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,
