 Ch 23 -- Device Administration 
   
UNIX Unleashed, System Administrator's Edition - 23 - Device Administration 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: - Service Access Facility Under SVR4
- Device Administrative Tasks Under SVR4
- Connecting Printers
- Connecting a PC to UNIX Systems
- Connecting X Terminals
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. Port Services 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. Port Monitors 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>
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 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. | 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 | | 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: 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. 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: - 1. # sacadm -t<type> -l to obtain a listing of all port monitors of same type, or
2. # sacadm -p<pmtag> -l to obtain information about a specific port monitor. 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 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: - 1. ttymon administration conforms with SAF's generic interface. This brings managing ttymon port monitors into line with management concepts applied to other port monitors, providing the benefit of convenience.
2. By using SAF management commands, the administrator has the choice of managing ttymon port services collectively or selectively. When using getty, the administrator can manage only one port at a time.
3. One invocation of the ttymon port monitor by sac can take care of multiple ttys, whereas getty/uugetty requires an entry per supported tty in the /etc/inittab file.
4. As will be discussed later, ttymon comes with support of a new feature, namely the AUTOBAUD feature. This feature allows ttymon to automatically determine the line speed suitable to the connected terminal.
5. ttymon can optionally be invoked directly by init, in "express" mode. This may be done by including an entry in the /etc/inittab file. As a matter of fact, if you examine the contents of the /etc/inittab file, you will notice the existence of a similar entry taking care of the UNIX system console in express mode. The entry should look similar to the following: 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
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. 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 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. 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> | 
