Web based School
- 40 — Device Administration
- Understanding Service Access Facility (SAF)
- SAF Administrative Commands and Files
- Service Access Controller Specific Files and Commands
- Port Monitor Specific Files and Commands
- Port Service-Specific Files and Commands
- SAF Initialization Process
- SAF Administration and Management
- Port Monitor Administration and Management
- Creating a Port Monitor
- Checking the Status of the Port Monitor
- Enabling, Disabling, and Removing a Port Monitor
- Port Service Administration and Management
- The ttymon port monitor
- Special Device Files and the Terminal Line Settings Database
- The ttymon Port Monitor Administrative Command ttyadm
- The listen Port Monitor
- Port Service Addressing
- The listen Port Monitor Administrative Command nlsamdin
- Creating a listen Port Monitor
- Managing listen Port Monitors
- Creating a listen Port Service
- Connecting Terminals and Modems
- Making the Connection
- Preparing for the Physical Connection
- Determine the Availability of Resources
- Creating the Port Service
- Connecting the Modem
- Connecting Terminals
- Connecting Printers
- How Does the LP Printing Service Work?
- Setting Up Local Printing Services
- Setting Up Network Print Servers
- Managing Printers
- Connecting a PC to UNIX Systems
- Connecting X Terminals
40 — Device Administration
40 — Device Administration
Device Administration
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 comes with a very powerful and central access facility known as Service Access Facility (SAF). No treatment of device administration 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. This chapter starts by explaining SAF.
Understanding Service Access Facility (SAF)
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 (see Chapter 37 for more on TCP/IP) 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:
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
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 40.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 |
SAF Initialization Process
Figure 40.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 40.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:
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:
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:
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:
- # sacadm -t<type> -l to obtain a listing of all port monitors of same type, or
- # 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:
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
whereas to disable it, enter
and to remove it, enter
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:
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:
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
To list or check on the status of all port services associated with a specific port monitor, enter
whereas to list, or check, the status of all port monitor services, enter
_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.
/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
whereas to disable it, enter
and to remove it, enter
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:
- 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.
- 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.
- 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.
- 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.
- 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 his or 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
As you see, sttydefs formats the listing into a user-friendly format. If you want the actual data structure of the command, enter
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.
This record is labelled 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 labelled 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 /etc/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:
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, labelled 4800, with initial flags set to support 4800 bps line speed:
To remove an entry, simply enter sttydefs -r <ttylabel>.
For example: to delete the 4800 label, enter
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 37 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 40.2.
Figure 40.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
Figure 40.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:
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.
Managing listen Port Monitors
To check on the availability of listen port monitors, enter
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:
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.
The following command adds a new port service to a port monitor with pmtag tcp:
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
To enable it, enter
whereas to disable it, enter
and to remove it, enter
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. A full treatment of UUCP
utilities is provided in Chapter 43.
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.
RS232D/C 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 40.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 40.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 40.4. Wiring diagram and corresponding pin definition of a DB25-to-DB25 RS232C/D straight-through cable.
Figure 40.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, respectively, 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, respectively.
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.
Figure 40.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 40.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:
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.
Use pmadm -l to check on the state of the service. If the new service is not enabled, use pmadm -p<pmtag> -s<svctag> -e to do so.
Connecting the Modem
As noted earlier, you connect a modem to the serial port (for example, COM2) using a straight-through cable. To configure the modem properly, you must read the documentation supplied with it. The things you ought to pay attention to are the DIP switch
settings and the AT commands that are necessary for proper modem initialization and dialing. Because the majority of modems today are Hayes compatible, the list in Table 40.2 can act as the configuration guidelines that apply to them.
Hayes modems have an 8-bit DIP switch. Table 40.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 40.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 (more on cu in Chapter 43).
After you login to UNIX, switch user, using the su command, to uucp:
Edit the /etc/uucp/Devices file (see Chapter 43 for more details) to include the following entry:
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:
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
This command directly connects you to the modem and is confirmed by displaying the message "Connected" on your screen. Table 40.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.
- Ensure that your modem is not conflicting with any other device over the chosen serial port. Conflicts normally arise when an internal modem is installed and configured to either COM1 or COM2.
- Make sure that you have the proper RS232C/D cable. Consult your modem documentation, and follow its recommendations religiously.
- If you intend to use the modem for dial-out, change the ownership of the tty port over to uucp (see Chapter 43 for more on this).
- Set the modem DIP switches according to what has been discussed already. This is especially critical if the intended use of the modem is for dial-out.
- For dial-in, check and make sure that a port monitor and a properly associated port service are created to take care of incoming service requests.
- Verify and add entries to UUCP files as deemed necessary. In particular, to be able to configure the modem using cu, you should have the following entry in the /etc/uucp/Devices file:
Direct term/## - <speed> direct - Using cu, establish a direct session with the modem and issue the AT commands to configure the modem properly. To establish the session, enter
#cu -l term/##
If the system fails to connect, use the -d option with cu. This option prompts cu to report the progress of the dial-out process. Depending on the nature of what is displayed on the screen, refer to the appropriate documentation for help.
- While in session with the modem, you should be able to dial out by entering
ATDT <phone_number>
Remember to exit just enter the ~. character sequence.
- 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.
Connecting Terminals
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:
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:
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:
Each letter or numeric is the directory name where terminal capabilities definition files, pertaining to types starting with that letter or numeric, are saved. For example, if TERM is set to vt220, UNIX fetches the file /usr/lib/terminfo/v/vt220 for the
terminal information capabilities (also referred to as terminfo entry).
After having gone through all of the steps required to connect the terminal, you should proceed to connect it, bring it up, and attempt login. It would be a good idea to try a direct connection first, if the terminal is intended for modem access. In any
case, if you fail to get the login prompt and fail to login, you may have to carry the following checks:
Make sure that the port service is configured properly, and that it is enabled. Use pmadm to do that.
Check the cable to verify that it is the correct one. Do not rely only on the wiring diagram provided in this chapter; you are better off relying on your terminal and/or your modem vendor's documentation.
Verify that the modem is configured to Autoanswer.
Check the modem lights, and verify that the sequence of events depicted by the flashing lights conforms to what you expect to see. In particular, check DSR and CD during the connection establishment phase because, unless they are both asserted, the
login prompt won't be written to the tty port. Check the modem's hard and soft settings to address any observed anomalies.
Make sure that the speed, parity, and number of stop bits match on both the terminal and the UNIX system.
Connecting Printers
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:
- A conceptual overview of the LP printing service
- Local printing services setup
- Network print servers setup
- Printer management
- Print user management
How Does the LP Printing Service Work?
Print services are invoked by init upon start-up when the system enters the multiuser state run level 2. The services are brought up by the /etc/rc2.d/S80lp script and are killed whenever the system is shut down by /etc/rc2.d/K20lp script.
When users address printers to handle their print jobs, the files they send for printing are not handled immediately by the printers. Instead, the files are queued in directories, by a process known as the spooler, for subsequent handling by a printing
daemon known as lpsched (an acronym and program name for the lp scheduler daemon). To understand how this works, imagine yourself as part of a community of users sharing one or two printers, among other UNIX resources. Ask yourself what would happen should
you be able to address the printer directly for a print request while someone else is doing exactly the same thing. You are right! The output will be more of a character soup than presentable piece of work. This is due to the fact that the printer will be
handling characters as they arrive, thus mixing the ones that belong to your file with those belonging to other users.
To alleviate this problem, the spooler takes over as you send print jobs to printers. It simply stops them on their way to their destination and diverts them to a waiting area on your system disk. This area is a subdirectory known as the print queue.
Files destined for the same printer are queued in the same directory until the printer becomes available. The aforementioned process is known as spooling. You may be wondering whether this means that the terminal will be tied up for as long as it takes for
the print job to materialize. The answer is no. This is because once a print job is queued, another background process known as the printing scheduler daemon (lpsched) takes over and supervises the ongoing printing services, making sure that every request,
including yours, is honored.
In addition to the basic service, LP printing services allow administrators to aggregate printers of similar type into a printer class. This provides for the optimal utilization of printing resources, as users target a class of printers instead of
targeting a specific one. When this happens, lpsched sends the print job to the first printer to become available in the requested class. Other printing services include tasks pertaining to starting interface programs that are suitable to the printer,
applying the filters to user files whenever necessary, notifying users, if desired, of the status of printing jobs, and, in the case of network printing, the LP printing service has the additional job of sending print jobs to the hosts to which requested
printers are connected.
Setting Up Local Printing Services
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.
- Verify availability of resources.
- Use lpadmin to create the printer.
- Change ownership and permissions to device special file.
- If this is your first printer, make it the default printer.
- Release the printer to the user community.
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
If not enabled, you may do so by entering the following command:
The next step is to create a print destination by using the lpadmin command. The syntax of lpadmin follows.
In wjocj
-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/##, respectively (# and ## represent decimal digits represetative 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:
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.
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 or her print job sent to the default printer. To make a
printer the default destination, enter the following command:
The lpadmin command to make dot matrix the default printer therefore becomes
Finally, to make the printer accessible to users, you must allow the printer destination to accept print jobs as well as logically turn on the printer. To allow printer dotmatrix to accept print jobs, enter
and to logically turn it on (that is, allow it to do the printing), enter
Setting Up Network Print Servers
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 40.7 depicts a scenario whereby the user wants his or her print job
sent to printer odie, attached to system engg, while logged in to system arts.
Figure 40.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 40.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 40.8. X displays and screens.
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
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, then use pmadm to create them. To create a port
service to listen to print requests sent by System V clients, enter
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:
Next, to create the port service under tcp port monitor, enter the following command:
To force the port monitor to recognize the changes you made, use the command
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
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 reestablishment 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 40.8, in order to register arts with the print server host engg, you should enter
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
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):
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:
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
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 40.7, the following is the command to enter at host arts:
The remaining steps, as you should know by now, are to enable the printer and make it accept print jobs. Hence the commands,
To send a print job down the wire to garfield to print, the user must address odie while logged in to arts. For example, to print file monalisa, the user must enter
LP print service on host arts will redirect the print job to garfield destination on host engg.
Managing Printers
In addition to the tools required to set up, enable, and disable printers, the LP print service presents the system administrator with a comprehensive set of management tools. Those tools can be applied to change printer configuration, as well to assist
in maintenance and troubleshooting situations. The following subsections describe aspects of printing management and associated tools.
Enabling and Disabling LP Print Service
lpsched is the program to start LP print service, whereas lpshut is the program to shut it down. Only login root or lp can start and shut down printing services. All printers that were printing at the time of invoking lpshut will stop printing. Whenever
lpsched is restarted, print requests that were disrupted at the time LP service was shut down will print from the very beginning.
Managing Print Requests
lpmove is a command that lets you move print jobs from one printer to another. There are, primarily, two scenarios that may prompt you to do that. In one, you may want to disable printing to a printer in order to disconnect it for routine maintenance or
troubleshooting. Instead of leaving your users in the cold waiting for their print jobs to materialize, you would move their print jobs to some other printer of equivalent quality. In the second scenario, you may use lpmove for load balancing purposes in
case you encounter situations in which one printer is heavily used while another one is sitting idle. The syntax of the lpmove command is
where requests presents lpmove with a list of request id's to move to the printer specified in dest. To obtain the print request id's, use the lpstat command. Its output should look like the following:
where the first column is the print request id and is made of two components: the name of the printer to which the print job was submitted, and the order in which it is received. The second column displays the name of the user who submitted the print
job, followed by the date and time of submission columns.
Assuming that acctlp is an idling printer to which you want to move the print job garfield-5, the lpmove command then becomes
To move the entire printing load from one printer to another, enter
To cancel undesirable print requests, use the cancel command. The syntax is
To cancel, for example, garfield-5, enter
Printer Configuration Management
Printer configuration management includes tasks such as changing printer class, changing printer port, removing printers, and removing classes. All these tasks can be achieved using the lpadmin command.
To change a printer class, enter
If the specified class does not exist, the class will be created and the specified destination will be inserted into it. To remove the printer from a certain class, enter
If the printer is the last one of its class, then the class itself will be removed as well.
To change the printer port, enter
You may need to do this on occasions when you suspect something went wrong with the original port to which the printer was connected. This reconfiguration will allow you to continue offering print services while troubleshooting the defective port.
Finally, to check the configuration of a particular printer, enter
In the example that follows, lpstat is entered to check on the configuration of garfield destination.
whereas to check the configuration of all printers, enter
Print Service User Management
User access to LP print service on UNIX systems can be managed and restricted for reasons that may pertain to security or resource allocation and management.
If you carefully examine the sample output of the lpstat -p garfield -l command in the last example, you will see the names of the users allowed access in the "Users allowed" entry. According to the preceding example, no one is either on the
allowed or the denied lists. This corresponds to the default security configuration and implies that any logged-in user can send print jobs to printer garfield. If you do not like that, however, you can use lpadmin with the -u option to restrict access to
the printer. The syntax of the lpadmin -u command to list users on the allow list is the following:
To prevent users from accessing the printer, enter
Following is a list of legal arguments that you can include in the login-ID-list:
|
login-ID |
Denotes a user on the local system |
|
system_name!login-ID |
Denotes a user on a client system |
|
system_name!all |
Denotes all users on a client system |
|
all!login-ID |
Denotes a user on all systems |
|
all |
Denotes all users on the local system |
|
all!all |
Denotes all users on all systems |
For each printer, the LP print service maintains deny and allow lists. The way they are used is summarized in the following paragraphs.
If the allow list is not empty, only users on that list are allowed access to the printer. If the allow list is empty but deny list is not, then all users except those on the deny list will be allowed access to the printer.
A user cannot exist on both lists simultaneously. When a user is added to either list, the user's login-ID will be checked and removed from the other one.
For example, to allow users Nadeem, Andrea, and May access to the printer garfield, you enter
Next, you should check that this indeed took place by entering the command
Users educated about the use of the -q option with the lp command can assign print queue priority levels to print jobs that they submit to the LP service. Although this can sometimes be a useful feature, it may well prove to be a cause of concern to
some of the user community as they find that their print jobs are constantly delayed in favor of those belonging to others of equal or less functional status. Fortunately, the LP print service allows you to set limits on how high a priority can be a
assigned to print jobs submitted by users. Using the lpusers different priority limit assignments can be made to apply to different users. The syntax of lpusers is as follows:
in which
|
-q<priority_level> is an integer ranging between 0 and 39, with 0 representing the highest priority level. | |
|
-u<login-ID-list> is a comma- or space-separated list of user IDs to whom the restriction applies. The login-ID list argument can have any of the following values: | |
|
login-ID |
Denotes a user |
|
system_name!login-ID |
Denotes a user on a particular system |
|
system_name!all |
Denotes all users on a particular system |
|
all |
Denotes all users |
|
all!login-ID |
Denotes a user on all systems |
Users submitting print jobs can assign them priorities as high as they are allowed to assign as set with the -q option.
Connecting a PC to UNIX Systems
Rather than purchase terminals, many users prefer to run UNIX sessions right from their desktop DOS-based PCs. This is mainly attributable to the low cost of the PC, its increased processing power, and the additional flexibility of being able to easily
toggle back and forth between DOS applications and a UNIX session. This section describes two methods by which you can establish a connection with the UNIX system using the DOS platform. The two methods are as follows:
- Establishing a session via a serial port
- Establishing a session via TCP/IP
Connecting the PC Using COM Ports
Depending on how you are going to do it, configuring a PC to connect to a UNIX host via a COM port is the easier and less costly of the two methods. If both systems belong to the same site, where there is no requirement for a telephone wire to connect
both machines, then a cross-wired cable is all the additional hardware you will need along with the COM port that is commonly readily available on your PC. Any communications software with decent terminal emulation capabilities can be used to emulate some
the terminals that UNIX recognizes. I used to use Procomm Plus and I was satisfied with it until I decided to go the TCP/IP way for reasons that will be discussed later.
Configuring a PC to serially connect to a UNIX host involves some preparation on both systems. Before making any move, however, you must check on the availability of the following resources:
- On the PC: Verify that you have a free COM port, and that its use of the IRQ interrupt number and I/O port address is not conflicting with any other interface cards on the machine.
- On the UNIX hosts: Verify the availability of a tty port and a suitable terminal line setting record in the /etc/ttydefs file (refer to the section, "Determine the Availability of Resources," in this chapter).
Additional requirements include two modems and two straight-through cables, if you are configuring a connection over a telephone wire, or a cross-wired cable, as discussed earlier in this chapter, to directly connect the PC to the UNIX system.
Configuring the UNIX system for support to tty port services was discussed earlier in this chapter.
Configuring the PC is a very simple matter that basically involves configuring the communication software to the same communication parameters implemented on the UNIX side of the connection. The parameters include baud rate, number of bits per
character, parity, and number of stop bits.
Configuring the Modems
The following are general guidelines that you should observe when configuring the modems:
Make sure that the modem you are installing at the UNIX end supports quiet mode. This mode is required in order to stop the modem from sending response codes to the port. Also, echo should be disabled. Failure to observe both of these rules may result
in having the UNIX system "believe" that the echoed characters are in partial response to the login prompt it sent to the PC. This may lead to an endless sequence of login and password prompts, and so on.
Should you run into the problem of having user sessions unexpectedly suspending, try to re-create the problem. If, upon sending manually an XON (press Ctrl+Q), character communications resume, then you may need to disable XON/OFF flow control to rely
only on RTS/CTS.
Set the modem connected to the UNIX system to autoanswer mode.
Connecting to UNIX via TCP/IP
TCP/IP is another way by which you can connect PCs in your environment to the UNIX system. This solution, however, is a bit more expensive than using COM ports. This is due to the investment in the network interface card (NIC) and the necessary software
for implementing the TCP/IP suite of protocols in addition to the cabling cost incurred per workstation. Given the advantages of this solution, and depending on the intended use of the connection, you may find it worth the money and effort to take this
route. Using TCP/IP, you will not only be able to establish a telnet session with the host, but you also will be able to use ftp for file transfers between the PC and UNIX, and rsh to remotely execute a UNIX command without having to necessarily log in to
the system. Also, if you are using something like Novell's Lan Workplace for DOS version 4.1, you will be able to invoke multiple UNIX and Microsoft Windows applications simultaneously. You also will be able to cut and paste (to your heart's desire)
between applications.
As in the COM port option, here too you have to set up both ends of the connection properly in order for them to communicate. Refer to Chapter 37 for a discussion on the installation and configuration of TCP/IP on the UNIX side. The discussion will
highlight the steps required to install TCP/IP on the PC/DOS machine.
The method that you will be using to install TCP/IP on the PC depends to a large degree on the vendor from whom you purchased the software. You are required, however, to do the following:
- You need to assign the PC an IP address in conformance with the rules discussed in Chapter 37.
- Assign the PC a host name.
- Create a hosts file on the PC. Include in the file the name to address mappings corresponding to all UNIX hosts to which the user has enough access rights. If domain name services are implemented on your site, then you can ignore this step.
- Beware that some TCP/IP solutions impose a default upper limit on the allowed number of connections that a PC can handle. Check on that and reconfigure if need be to the desired number.
Depending on whether DNS and/or RARP services are part of your environment, you may need to go farther:
- Provide the name server's address to the PC.
- Edit the ethers and the hosts file on the RARP server.
Depending on the vendor, the TCP/IP software comes with ranging tools to help you troubleshoot and manage your PC on the network. What I found particularly impressive about LAN WorkPlace for DOS V4.1 is the extensive support it provides to the network
manager. Among the things you get with this product is an SNMP compliant management console that helps in troubleshooting your TCP/IP installation and configuration. It also lets you target other machines on the network for subsequent management and
troubleshooting. For a minimum, any decent implementation of TCP/IP should provide tools such as the ping and netstat commands. Use these tools in case things fail to work properly. For more on troubleshooting TCP/IP networks, refer to Chapter 37.
Connecting X Terminals
Until X terminals emerged a few years ago, ASCII dumb terminals were almost exclusively the machines that users had at their disposal for accessing UNIX systems. Due to their nature, these terminals fell short of meeting the ever-increasing demands of
engineering and scientific applications for graphical output. With X terminals, a new era of computer-to-human interface began. These terminals not only met the craving need of engineering and science applications for graphics, but they also presented UNIX
users with a far more superior, and elegant, user interface.
An X terminal is a component of the X Window System technology (hereafter referred to as X, or X11) that was developed at the Massachusetts Institute of Technology, and is currently maintained by a consortium of universities and vendors.
One of X's greatest attributes is that it can be brought up on any platform. Though it was initially implemented in UNIX environments, X is now equally available to other platforms ranging from mainframes to DOS workstations. This platform independence
is due to the mechanism and model that were put together to make X work: the X protocol and client/server model. As you will see later on, this has far-reaching implications as to how users will be able to work in multiplatfom/multivendor environments.
To setup X terminals, it is essential that you understand the governing concepts that drive this technology. This section will therefore start with an examination of its various components, including the client/server model that X follows. Some terms
will be introduced and defined to make you more familiar with the associated jargon. Setting up X and X servers will be discussed next. The focus of the discussion will preclude the many different kinds of GUI interfaces that are currently available to run
on top of X, concentrating more on how to bring the engine (X platform) and its associated gear to life.
The Architecture of X
X's architecture is based on two components: the client/server model and the X protocol.
The Client/Server Model of X
A client server/model follows a mechanism by which an application is split into two components: the so-called backend and frontend. In the database client/server technology, for example, the frontend runs at the user's workstation and is termed the
client, whereas the backend runs on a remote host that is shared by all authorized users, and is called the server. The database server acts as the main repository of data that clients need. Instead of having an entire file transferred to its machine from
the server, the client uses scope-and-filter techniques while requesting only the data relevant to its needs for subsequent processing. From what has just been said, the client/server model components could be expressed as a matter of which is managing
access to a resource, versus which is requesting use of the resource. The server component is the access-resource manager, whereas the client component is the one requesting access to and use of the resource.
The application is split into the following components: X client and an X display server.
An X client handles all data processing aspects of an application, except for the I/O interaction, which it delegates to a server process. The server process could be running on the same machine or a terminal located elsewhere in the environment. This
implies that, unlike database and other familiar server technologies, the X display server belongs to the user's machine where actual I/O and user interface capabilities are provided. Clients, therefore, become the shared resource that all users can access
and run remotely.
The X Protocol
Rather than base the X client/server model on a particular set of software and hardware resources, which could restrict its portability across platforms, X architects chose to base it on a protocol mechanism called X protocol. In doing so, vendors and
developers of X applications were insulated from platform-related concerns and specifics. Applications complying with X specifications can be easily ported to any environment, while having X servers mediate the I/O interaction with the physical display
units. Having said that, this clearly implies that an X server presents applications with a virtual display unit that they can manage. The display server maps I/O primitives, passed to it by applications to physical actions on the actual display unit.
Another aspect of X protocol worth mentioning is that it builds on some of the most commonly deployed transport protocols, including TCP/IP, IPX/SPX, and DECnet to enable clients and servers to talk to each other. A user on an X terminal, with
multiprotocol support, can invoke one session with a mainframe while maintaining another with a UNIX system, and yet another one across a dial-up line.
From what has already been said about X, it can be concluded that X is a network-based graphics engine. It allows users to connect to, and run applications on, remote systems while handling I/O interaction using locally available graphical terminals.
Being an engine implies that readily available GUI interfaces are built on top of X, rather than being part of it.
X Resources
Central to X functionality is the concept of resources. A resource is a configurable attribute of an application. Examples of resource attributes are the font the application uses, background color, initial location, and size of an application window.
The fact that the same X client may have to deal with different servers means that it must be supported with a configuration mechanism that is flexible enough to deal with ranging hardware capabilities and user preferences. Examples of hardware
differences are monitor color and resolution capabilities. Also, one user's preferred color, font, and window location and size may not agree with someone else's. It can be concluded that X applications cannot be developed with built-in support for any
hardware type or for the developer's perception of how the user interface and preferences should look. Users should be allowed to have a choice of hardware and be able to configure an application's output however they feel is best for them.
X provides for this capability using one of two methods: command-line options and resource definition files.
Independent of the method you are using, when an application is invoked, an X display manager will autoload the associated attributes onto your server (more on this later). This provides the I/O capability and interface you have defined.
Setting X Resources with Command-Line Options
In this method, users define resources upon invoking an application using command-line options. Most X applications allow users to define resources using the same command option names. The following are examples of the most commonly used arguments:
|
X Resource
|
Description
|
|
-display <display> |
Specifies the name of the X server, display, and screen to use (that is, to send output to) |
|
-geometry <specs> |
Specifies the initial size and location of application's window |
|
-bg <colour> |
Specifies the background color |
|
-bd <colour> |
Specifies the border color |
|
-fg <colour> |
Specifies the foreground color |
|
-fn <font> |
Specifies the font |
|
-title <title> |
Specifies the window title |
For example, say that a user wants to invoke xterm (an X terminal emulation client) titled "X Terminal" with a blue background color, gray border, and the window initially located at the upper-left corner of the monitor. The user then has to
enter the following command:
Given the number of clients that a user may have to invoke simultaneously, this method of loading resources can be tedious and is prone to errors.
Defining Resources Using Resource Definition Files
To alleviate the tedium of defining resources using command-line options, X provides the following two resource definition files: Xresources and $HOME/.Xresources. Both of these files contain per-application lists of attribute assignments. Xresources
contains global definitions applying to all X servers, whereas $HOME/.Xresources may contain user-specific definitions. Both sets of resources are loaded by the xrdb program whenever a connection is established with an X server. Sample $HOME/.Xresources
file contents are as follows:
The first set of resources pertains to xclock. According to what is shown, the clock is to be updated at the rate of once a second, displayed in digital format, and the chime is disabled. The second set of resources pertains to xterm, and that set
specifies a window title XTerminal, a yellow background color, black text, scroll bar enabled, and a window size of 40x24 displayed at the upper-left corner of the monitor.
Window Managers
A window manager is an X client that normally is invoked during start-up on an X session, from the user's start-up $HOME/.xsession script file. It can also be invoked on the command line.
Window managers allow users to manage their applications' windows whether moving, resizing, or reducing them to icons.
There are many different flavors of window managers. Tab Window Manager (twm) is the one that comes with MIT's distribution of X. Open Look provides olwm, whereas OSF/Motif provides mwm. In this chapter, reference will be made to twm only.
twm behavior is governed by the system.twmrc configuration file in the /usr/X/lib/twm directory. You can edit this file, changing its default behavior to anything that suits your users' needs.
Because the default configuration is adequate for the purposes of this section (that is, setting up an X terminal), no further details will be provided on how to edit this file.
Setting the Shell Environment Variables
Two shell environment variables need to be taken care of, in order to successfully start an X session. These are PATH and DISPLAY.
PATH should be modified to include the path to X client programs. This can be done in the user's start-up script $HOME/.xsession. The script should include:
DISPLAY X environment variable specifies to the client the name of the host, and display number, to send its output to.
X distinguishes between displays and screens. Figure 40.8 tries to make the distinction clear. In X, a display is a collection of monitors that share a common keyboard and mouse. Shown in Figure 40.8 is an X server that has one display and two monitors.
The monitors are referred to as screens and are numbered starting with 0. In Figure 40.12b the X server has one display with one screen.
Hence an appropriate setup of the DISPLAY variable should take care of both the display and monitor to which the output is sent. The DISPLAY variable can be specified using the following format:
in which
|
|
|
|
|
|
|
|
|
DISPLAY can be set in the user's login script. It can also be set manually as a command-line argument, using the -display option, when a client is being invoked:
The X Display Manager
The X Display Manager (xdm) is the preferred way of starting up an X session. xinit is another option. This discussion is restricted to xdm only.
In SVR4, xdm is started as a daemon when the system is booted. It is invoked by one of the /etc/rc2.d scripts. On my system the startup script is S69xdm.
Once invoked, xdm provides users with a graphical login window where they must enter their user IDs and passwords. Once authenticated and logged in, xdm automatically loads resources to X servers and starts X clients as specified in the user's
$HOME/.xsession startup script.
xdm is a customizable X client. Its behavior depends to a large degree on what is in its configuration files. All xdm configuration files are in the /usr/X/lib/xdm directory. They are as follows:
Some of these files pertain to different versions of X. In the following subsections, the purpose of each file is described in the context of starting X server sessions. User-specific files (that is, $HOME/.xsession, $HOME/.Xresources, and
$HOME/.xsession-errors) are described as well.
xdm-config
xdm-config is the first file that is read by xdm when spawned. This file primarily defines where the rest of the configuration files listed previously belong. Following is an example of the its contents:
It can be seen that the preceding xdm-config file contains some self-customizing resource definitions.
Xservers and Xaccess
There are two methods by which xdm knows which X servers to connect to. One method pertaining to release 3 of X (also referred to as X11R3) relies on the Xservers file. In Xservers, the administrator has to maintain a list of names of X servers to be
managed by xdm. This was the only way available to xdm to connect to X servers. Following is a sample of the contents of an Xservers file:
Note how, in all entries, the host's name and display number (colon separated) are followed by one of two terms, local or foreign. local means the X server is running on the console, whereas foreign means it is on the network.
Because Xservers was read only when xdm was started, however, this posed serious problems as X terminals were brought up later on and as others were temporarily turned off. The only way the administrator could force xdm to recognize a newly brought up X
server was by restarting. This involves sending xdm a SIGHUP signal using the following command:
where the process id can be found by entering
To remedy this problem, X Display Manager Control Protocol (XDMCP) was introduced in X11R4. XDMCP is a protocol that is implemented at both ends of the connection: the X server and the xdm client. An X server with XDMCP support is responsible for
requesting xdm for a connection and should not require an entry in the Xservers file.
To request a connection, an XDMCP-compatible server issues one of three types of queries, depending on how it is configured. The three types are as follows:
Direct query: This is a directed query addressed to a specific host.
Broadcast query: The server sends out a general query addressed to all xdm clients requesting a connection. In this case, the X server connects to the first xdm client responding to the query.
Indirect query: The X server addresses the XDMCP query to an xdm client for "help." The latter forwards the request to other xdm clients on the network for a response.
Xaccess is an XDMCP-related file. As the name implies, it provides for a degree of access control at the machine level. This means that only hosts with their names listed in Xaccess will have their request to connect honored, receiving a login window. A
user still has to undergo the authentication process by providing the login ID and the password.
The Xresources File
The Xresources file contains resource definitions that ought to be loaded to X servers upon establishing the connection. All X servers are subject to the same treatment. The first thing that xdm does upon connecting is send a login window, which
requires that associated resources be loaded. As for user-specific resources, they are loaded by the server after the user logs in, based on either $HOME/.Xresources and/or $HOME/.xsession files.
Xsession and $HOME/.xsession files
Xsession and .xsession files are start-up scripts that execute upon user login. Xsession is a system-wide script that executes every time a user logs in to the system. .xsession is the user's personal script, which is executed by xdm only if Xsession
(the system script) calls for it. It is mainly responsible for setting up the user's environment properly and the subsequent invocation of some of the user's applications. Following is a sample .xsession file.
The preceding .xsession file starts by modifying the PATH variable to include the directory where all the X binaries are stored in the file system. Next, xdm calls and executes xrdb to load and merge the X client resources with those already loaded from
Xresources at the X server. This suggests that the user is maintaining a .Xresources file in the home directory. A .Xresources file may have the following contents:
It is important that resources are loaded first, explaining why xrdb is called first and running in the foreground.
After resources are loaded, application clients are called next. Note how they are made to run in the background. Otherwise (that is, if applications are run in the foreground), the script will hang pending the completion of the application.
Finally, twm (Tab Window Manager) is loaded in the foreground. Unless this is done, execution of the script completes and exits, which may reset your X server. Hence, the last application to load should always be running in the foreground.
%chmod x .xsession
Now that you have a feel for how the user-specific files (that is, .Xresources and .xsession) are used to set up the user's X server session, take one more look at the Xsession that made it all happen. As noted before, .xsession is called and executed
from the system-wide /usr/X/lib/xdm/Xsession. Following is a listing of the Xsession file that comes within X11R5 distribution of X:
Note the following points about the script:
- It first directs xsession error messages to .xsession-errors file. It is a good idea to keep one error file per user, as it conveniently helps you troubleshoot user sessions.
- Next, it checks whether the script was called with a failsafe argument. If so, .xsession is not executed and the user is sent a single xterm. This option is mainly used to assist users and administrators in troubleshooting a failing session. The user
invokes a failsafe session by pressing the F1 key or Ctrl+Return. Some preparation must have been made in the Xresources file, however, for this trick to work. For more on this topic, you are referred to your vendor's X Windows user manuals.
- In the last part of the script, Xsession tests for the existence of the $HOME/.xsession script. If it exists, control is transferred to .xsession. Note how .Xresources is avoided altogether in this case, and it is left to .xsession to handle the user's
resource definition file instead. In case .xsession does not exist, Xsession establishes a minimal session by loading .Xresources and invoking a single xterm session after spawning twm in the background.
GiveConsole and TakeConsole Configuration Files
GiveConsole and TakeConsole are scripts that, as their names imply, change the ownership of the system console to the user, and back to root, respectively. Both files are relatively new to X11R5.
To summarize the X startup and user session establishment process, xdm is invoked as daemon by the /etc/rc2.d/S69xdm script when the system enters the multiuser state. Upon starting up, xdm fetches its /usr/X/lib/xdm/xdm-config file to determine the
names and locations of its configuration files. It starts by loading Xresources file into the X servers listed in its Xservers file, or into those who successfully queried it using the XDMCP protocol. A login window is subsequently sent. When a user
requests a login by entering a valid login ID and password, xdm fetches the /usr/X/lib/xdm/Xsession script for execution. Subsequent actions are determined depending on what was included in this script. It is recommended that user session handling and
configuration be dealt with using .Xresources and .xsession in the manner discussed previously. xsession is equivalent to a personal login script in that, if it exists, it invokes the xrdb client to load user resource definitions in the .Xresources file,
and to load user applications that are included in the .xsession script.
X Server Access Security
The basic premise of the X Window System is that it allows an X client to send its output to the X server specified using the -display option. This being the case, you should be able to predict the security hazard that is associated with this mechanism.
Unless your X display server is properly secured against unwelcome X clients, hackers can maliciously connect to it and crash your session. In the following few paragraphs, one security control method is described, along with its advantages and
disadvantages. For more on X security, refer to X Window System reference manuals that ship with UNIX.
xhost Access Control Method
Using this method of protection involves the use of xhost client and the /etc/Xn.hosts file, where n refers to the display number to which the access control file applies. Because most systems have one display, reference will be made only to the
/etc/X0.hosts file. The X0.hosts file must be created on the X server and edited by the system administrator to include the names of hosts from which clients are allowed access to the X server. So, if the /etc/X0.hosts file contains the following host
names:
arts
engg
fin
then clients on arts, engg, and fin can establish X sessions with the X server and have their outputs sent to it.
xhost is a command that also can be used to add hosts to the server's access control list. The syntax of xhost is as follows:
To authorize a host, enter
whereas to remove a host from the server's access control list, enter
In the following example, host sam is allowed access, whereas host view is not:
If you want to allow all hosts access to the server, enter
and to disable access, enter
It must be kept in mind, however, that currently established sessions will not be affected by the "xhost -" commands. Only future connections will be refused.
A question that may have occurred in your mind by now is, what if you want to invoke clients on host view, or any other host, which is denied access to your server? The answer to that is tough. You simply cannot do it! X Windows System provides a few
other alternatives to the xhost control method. An example is the MIT-MAGIC-COOKIE-1, which is more of a user-based authentication process in which restrictions are enforced on users rather than on hosts.
Types of X Servers
No discussion of X is complete without a degree of exposure to the different types of X servers and their ranging capabilities.
Originally, a few years ago, X servers and X terminals were synonyms. Talking of one used to imply the other. This is because X servers used to be supplied on terminals tailored to handle X services, thus providing users with GUI capabilities, as
opposed to the ASCII terminals, which handled characters only. Today, in addition to X terminals, an X server can be brought up and delivered to users on a variety of platforms, thanks to X protocol design, which provided for X's independence from
operating systems as well as hardware. Among the relative newcomers to the X market are PC-based implementations of X servers. An example is eXceed series of X servers for DOS, OS/2, and Windows by Hummingbird Communications Ltd.
X terminals are what the name implies: dumb terminals with X Windows support. They are therefore better suited to support graphical applications including arts, science, and engineering. X terminals come with different features and capabilities, some of
which are as follows:
- The X server program loading method varies from one X terminal to another. One commonly used method is to have the terminal resort to TFTP protocol (see Chapter 37 for more on TFTP) to download X server software and fonts on boot time from a remote
host. Other terminals would have the X server software available locally on ROM. Yet a third category would provide a combination of both: ROM-based and TFTP-based methods. Some models such as WYSE WX-Series include an extra PCMCIA slot to use with an
optional FLASH ROM. With this support the terminal needs to contact a host for a download of X server software once, during which a permanent copy of it will be transferred to the FLASH ROM to be used for subsequent reboots.
- The most commonly supported transport protocol among vendors of X terminals is TCP/IP. Some of the vendors provide you with serial communications capabilities as well. In this case, you should carefully examine how the server is optimized to operate
over the limited bandwidth that is normally associated with serial facilities. If you are administering a multiprotocol environment, you may even have to go farther to shop around for ones that support your transport requirements.
- Recently, due to the explosion in the demand for multimedia support, some vendors such as Hewlett-Packard introduced multimedia X servers. An example model is the HP XEnvizex X station.
PC X Servers
As mentioned earlier, PC-based X servers are relative newcomers to the X Windows market. The broad install base of PCs, the improved performance of Intel CPUs, and the continuing drop of PC hardware cost inspired vendors to develop X server software
that nears the performance of dedicated X terminals. Some vendors went farther by implementing the X server software as an MS Windows application. This made them more attractive by allowing the user the luxury and flexibility of maintaining DOS, Windows,
and UNIX sessions. And by supporting the Inter Client Communications Conventions Manual (ICCCM), X servers allow users to interchangeably cut and paste between those environments. Figure 40.16 illustrates how eXceed/W, a high-end X server by Hummingbird
Communications Ltd., provides this support. It illustrates the use of the X server software to establish multiple X sessions with clients running on different host platforms including IBM, HP, and an MS Windows application.
There are some performance-related factors that need to be considered before trying to install PC X servers. These are as follows:
- CPU power
- Amount of Random Access Memory (RAM)
- Graphic interface card and monitor
- The network interface card (NIC)
Obviously, the more CPU power and RAM memory, the better the X server will run. For optimal performance, however, you need no less than a 386 CPU with clock rates starting from 16 Mhz. Though most vendors require memory sizes in the four-megabyte range,
you will find that this range delivers the service but not the performance. Therefore, you may still need more memory. Of all the factors, the video graphic interface may prove to be the single most important factor on your PC. Remember that the idea of X
is to provide users with the elegance and capabilities of the associated GUI interfaces. No matter how fast X is on the PC, there is nothing as annoying as poor, if not disgusting, graphics. There are many implementations of X, with each supporting a
variety of graphical interfaces with ranging capabilities. Depending on the nature of what you intend to do on the PC X server, you ought to budget for the suitable interface and monitor. Finally, a 16-bit interface card provides better performance on the
wire, and consequently contributes to the improved overall performance of the X server.
Not all PC X servers are born equal. Some currently available implementations are more compatible with the latest distribution of X than others. Some even may have more capabilities built into them, or they may be easier to install and configure.
Following is a list of features and capabilities to help you better assess the PC X options that you may have at your disposal.
X compliance X11R5: Make sure that the PC X server you choose is 100 percent compatible with X11R5. Non- or partial compliance may even prevent some of the application from displaying on your PC. Lack of compatibility with ICCCMP protocol may
impair your ability to cut and paste across application windows.
XDMCP full compliance: Though users will always be able to login and start an X session using protocols such as telnet, rlogin, and sh, today XDMCP is the preferred method of logging in to X hosts. It also relieves you of the headaches associated
with the older way of administering connections using the Xservers configuration file.
MS Windows support: With the user community moving closer by the day to MS Windows, you may consider an implementation that integrates both environments. This is particularly useful if the PC X server you choose is ICCCMP compatible, which allows
you to freely cut and paste across application windows.
Transport support: The PC X server of choice should provide the same level of transport support that is compatible with already deployed protocols supporting your X clients. Most PC X servers support TCP/IP, but not as many support additional
protocols. To access, for example, X clients running on UnixWare using IPX/SPX transport, you will need a PC X server such as eXceed/W. Another aspect of transport support is the maximum number of connections the X server can simultaneously allow.
X traces capability: This is a diagnostic capability that may prove extremely helpful in troubleshooting X connections.
Summary
Among the resources that UNIX system administrators are required to manage are ASCII terminals, modems, printers, and X servers. To manage these resources more easily, UNIX SVR4 presents system administrators with a cohesive set of concepts and tools
that come under the hood of Service Access Facility (SAF). SAF recognizes a three-level hierarchy of processes: sac (service access controller), port monitors, and port services. sac is at the top of the hierarchy, and is responsible for invoking and
managing the port monitors, which are mid-level processes. Port monitors are responsible for invoking and managing port services, which run at the bottom of the SAF hierarchy. There are two types of port monitors: ttymon and listen. Whereas ttymon takes
care of service requests received via the serial (or tty) ports, listen takes care of across-the-network services.
Once SAF is setup appropriately, the administrator can provide all kinds of services, including dial-in access, print services access, and access to X clients running on the UNIX host. Enough details for setting up these services were presented in this
chapter to allow the administrator to successfully bring up a similar environment in his or her workplace.
Popular Tutorials
-
MS Access
1109
-
C++
1222
-
HTML
584
-
JavaScript
616
-
Vbscript
873
-
Oracle
473
-
VC++
875
-
SQL
2959
-
XML
514
-
Java
814
-
Perl
455
-
Linux
451
