SAF Architecture
Figure 30 shows the architecture of SAF. Each of the architectural elements is described in the following paragraphs.
Figure 30. Service Access Facility Architecture
The init Process
The init process controls the overall state of the UNIX operating system and creates processes by using the information stored in the /etc/inittab file. The init process monitors the sac. The /etc/inittab file has an entry that restarts the sac process if init receives a signal indicating that the sac process has died.
Service Access Controller
The sac daemon controls the overall state of arbitrary processes that are started in response to connection requests. The sac daemon receives all of the requests to enable, disable, start, or stop port monitors and takes the appropriate action. If port monitor processes are terminated, sac is responsible for restarting them.
The sac is started from the following entry in the /etc/inittab file.
sc:234:respawn:/usr/lib/saf/sac -t 300
When sac is started, it first customizes its own environment by reading the /etc/saf/_sysconfig configuration file. Each system has one /etc/saf/_sysconfig file. When the sac process is started, this file is interpreted and used for all of the port monitors on the system. Modifications to the environment from this file are inherited by all of sac's child processes.
Then, sac starts all of the designated port monitors by using information from the /etc/saf/_sactab file. For each port monitor to be started, sac forks a port monitor child process. The ttymon port monitor reads its configuration information from the /etc/saf/pmtag/_pmtab port monitor table. If configured, the listen port monitor reads its configuration information from the /etc/saf/pmtag/_pmtab file. You set the value of the pmtag variable when you use the sacadm command to create the port monitor. The default name for the ttymon port monitor for serial ports is zsmon; the default name for the listen port monitor is tcp.
Once the port monitors are running, sac polls them periodically for status information. If a port monitor that should be running has stopped, sac restarts it if a non-zero restart count was specified with the -n count option to the sacadm command when the port monitor was created.
Port Monitors
Port monitors monitor a set of homogeneous incoming requests on a system port, detect incoming requests, and connect them to the appropriate service process. As already mentioned, the Solaris Operating Environment provides a TTY port monitor daemon named ttymon and a network port monitor daemon named listen.
To find out which port monitors are running and to show their status, type sacadm -l and press Return.
oak% /usr/sbin/sacadm -l
PMTAG PMTYPE FLGS RCNT STATUS COMMAND
zsmon ttymon - 0 ENABLED /usr/lib/saf/ttymon #
oak%
In the above example, only the ttymon monitor, which is identified by the default port monitor tag of zsmon, is started, and the status is ENABLED.
Table 35 describes the fields shown in the output of the sacadm -l command.
Refer to Chapter 11, “Setting Up Modems and Character Terminals,” for information about how to configure, start, and enable the ttymon port monitor. Refer to Chapter 12, “Setting Up Printing Services,” for information about how to configure, start, and enable the listen port monitor.
To view the contents of the port monitor administrative file, type pmadm -l and press Return.
oak% /usr/sbin/pmadm -l
PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>
zsmon ttymon ttya u root /dev/term/a I -
/usr/bin/login - 9600 ldterm,ttcompat ttya login: - tvi925 y #
zsmon ttymon ttyb u root /dev/term/b I -
/usr/bin/login - 9600 ldterm,ttcompat ttyb login: - tvi925 y #
oak%
In the above example, the ttymon ports /dev/term/a and /dev/term/b show the default Solaris configuration. Table 36 describes the fields shown in the output of the pmadm -l command.
The ttymon Port Monitor
The ttymon STREAMS-based port monitor performs the functions provided by the getty process in SunOS 4.x system software. In addition, ttymon initializes and monitors tty ports, sets terminal modes and line speeds, invokes service on serial ports when it receives a connection request, and idles while a service is connected.
NOTE
In Solaris 2.x, the serial ports /dev/term/a and /dev/term/b are provided with a default configuration for the ttymon port monitor with a pmtag of zsmon.
Each instance of ttymon can monitor multiple ports, as specified in the port monitor's administrative file. You configure the administrative file with the pmadm and ttyadm commands.
When an instance of ttymon is started by the sac daemon, ttymon starts to monitor the ports that are under SAF control. For each port, it first initializes the line disciplines, if specified, and the speed and terminal settings. The values it uses for terminal initialization are taken from the appropriate entry in the /etc/ttydefs file, which is maintained by the sttydefs command. Default line disciplines on ports are set up by the autopush(1M) command. You do not need to do anything to configure autopush.
The listen Port Monitor
The listen process “listens” for network service requests, accepts requests when they arrive, and starts services in response to the requests.
NOTE
No listen processes are started by default in the Solaris Operating Environment.
The listen process provides services similar to those provided by the traditional Internet Services daemon, inetd. In Solaris 2.x system software, the inetd daemon is started with the -s option to run stand-alone outside of the SAF.
CAUTION
The Solaris Operating Environment does not support running inetd under SAF. Be sure that the -s option is always present.
Service Invocations
A service invocation is a process that provides the requested service to the incoming connection request. A service invocation can be a process such as login or lp. The ttymon port monitor works with the login process, and the listen port monitor works with the LP print service. The SAF architecture is structured so that programmers can write new port monitors to support other processes specified by the port monitor.
Port Monitor States
Once added, port monitors can be operational, transitional, or inactive in one of the six states shown in Figure 31.
Figure 31. Port Monitor State Model
Operational States
Port monitor operational states are ENABLED and DISABLED. Port monitors are started and enabled by default when you add them. Port monitors are stopped and disabled by default when you remove them. When a port monitor is enabled, it accepts requests for service. When a port monitor is disabled, existing services continue, but new service requests are refused. When a port monitor service is killed, all of its services are terminated.
Transitional States
A port monitor can be STARTING or STOPPING. When a port monitor is in the process of starting, it is in an indeterminate state in the process of becoming either ENABLED or DISABLED. When a port monitor is stopping, it has been terminated manually but has not yet completed its shutdown procedure. Consequently, it is in an indeterminate state in the process of becoming NOTRUNNING.
Inactive States
An inactive port monitor is either NOTRUNNING or FAILED. A failed port monitor is unable to start and remain running. When a port monitor is not running, it has been killed. All ports it was monitoring are inaccessible. Unlike the disabled state, when a port monitor is not running, the system cannot write a message on the inaccessible port telling the user that it is disabled.
The Line Control Model
The line control model for the Solaris Operating Environment is different from that of Solaris 1.x releases. The files /etc/gettytab and /etc/ttytab have been removed. Line settings are stored in the /etc/ttydefs file and in the ttymon configuration files. Table 37 compares the Solaris 1.x and Solaris 2.x line control models.
| Feature | Solaris 1.x File | Solaris 2.x File |
|---|---|---|
| Database descriptor. | /etc/termcap /etc/terminfo | /etc/terminfo |
| Set terminal I/O operation. | stty (BSD) | stty (SVR4) |
| Line settings and sequences. | /etc/gettytab /etc/ttytab | /etc/ttydefs |
| Administer-TTY definitions. | ttydef(1M) |
Figure 32 shows the interaction of the terminal control and the SAF. The init program starts sac, which controls the ttymon port monitor. In turn, ttymon monitors serial port devices. It connects incoming requests to services, which are usually login processes. Port monitors keep a close watch over the device or network transport, add and delete services, and start and stop services at the appropriate time. You can use the stty and tput commands to configure the terminal I/O settings to match the characteristics of the terminal. When ttymon gets a character from the terminal, it starts a login to the terminal. When the user logs out, ttymon hangs up to recycle the serial port and waits for another service request.
Figure 32. Terminal Control Architecture
The /etc/ttydefs File
The /etc/ttydefs file defines baud rates and terminal settings for TTY ports. When you set up modems, you use the ttyadm -l ttylabel argument as part of the pmadm command-line argument to specify information about the baud rate and the modem settings. The ttylabel variable specifies the first field for an entry in the /etc/ttydefs file. When ttymon initializes a port, it uses the information from the /etc/saf/pmtag/_pmtab file to search the /etc/ttydefs file for an entry that contains the ttylabel that matches the ttylabel for the port. The ttydefs file is similar to the old gettydefs file. Each entry in the /etc/ttydefs file has five fields, which are separated by colons.
ttylabel:initial-flags:final-flags:autobaud:nextlabel
The ttylabel field contains the TTY label that matches the port.
The initial-flags field contains the initial terminal input and output settings.
The final-flags field contains the terminal input and output values set by ttymon after a connections request is made but before the port service is started.
The autobaud field enables ttymon to determine the line speed of the TTY port by analyzing the first Return received and setting the speed accordingly. To enable autobaud, the field must contain the character A. If the field is empty, autobaud is disabled.
The nextlabel field specifies a hunt sequence that links speeds together in a closed set. For example, 4800 may be linked to 1200, which is linked to 2400, which is linked to 4800. If the current ttydefs entry does not provide a compatible line speed, the next speed in the sequence is tried. The default /etc/ttydefs file is shown below.
# VERSION=1 460800:460800 hupcl:460800 hupcl::307200 307200:307200 hupcl:307200 hupcl::230400 230400:230400 hupcl:230400 hupcl::153600 153600:153600 hupcl:153600 hupcl::115200 115200:115200 hupcl:115200 hupcl::76800 76800:76800 hupcl:76800 hupcl::57600 57600:57600 hupcl:57600 hupcl::38400 38400:38400 hupcl:38400 hupcl::19200 19200:19200 hupcl:19200 hupcl::9600 9600:9600 hupcl:9600 hupcl::4800 4800:4800 hupcl:4800 hupcl::2400 2400:2400 hupcl:2400 hupcl::1200 1200:1200 hupcl:1200 hupcl::300 300:300 hupcl:300 hupcl::460800 460800E:460800 hupcl evenp:460800 evenp::307200 307200E:307200 hupcl evenp:307200 evenp::230400 230400E:230400 hupcl evenp:230400 evenp::153600 153600E:153600 hupcl evenp:153600 evenp::115200 115200E:115200 hupcl evenp:115200 evenp::76800 76800E:76800 hupcl evenp:76800 evenp::57600 57600E:57600 hupcl evenp:57600 evenp::38400 38400E:38400 hupcl evenp:38400 evenp::19200 19200E:19200 hupcl evenp:19200 evenp::9600 9600E:9600 hupcl evenp:9600 evenp::4800 4800E:4800 hupcl evenp:4800 evenp::2400 2400E:2400 hupcl evenp:2400 evenp::1200 1200E:1200 hupcl evenp:1200 evenp::300 300E:300 hupcl evenp:300 evenp::19200 auto:hupcl:sane hupcl:A:9600 console:9600 hupcl opost onlcr:9600::console console1:1200 hupcl opost onlcr:1200::console2 console2:300 hupcl opost onlcr:300::console3 console3:2400 hupcl opost onlcr:2400::console4 console4:4800 hupcl opost onlcr:4800::console5 console5:19200 hupcl opost onlcr:19200::console contty:9600 hupcl opost onlcr:9600 sane::contty1 contty1:1200 hupcl opost onlcr:1200 sane::contty2 contty2:300 hupcl opost onlcr:300 sane::contty3 contty3:2400 hupcl opost onlcr:2400 sane::contty4 contty4:4800 hupcl opost onlcr:4800 sane::contty5 contty5:19200 hupcl opost onlcr:19200 sane::contty 4800H:4800:4800 sane hupcl::9600H 9600H:9600:9600 sane hupcl::19200H 19200H:19200:19200 sane hupcl::38400H 38400H:38400:38400 sane hupcl::2400H 2400H:2400:2400 sane hupcl::1200H 1200H:1200:1200 sane hupcl::300H 300H:300:300 sane hupcl::4800H conttyH:9600 opost onlcr:9600 hupcl sane::contty1H contty1H:1200 opost onlcr:1200 hupcl sane::contty2H contty2H:300 opost onlcr:300 hupcl sane::contty3H contty3H:2400 opost onlcr:2400 hupcl sane::contty4H contty4H:4800 opost onlcr:4800 hupcl sane::contty5H contty5H:19200 opost onlcr:19200 hupcl sane::conttyH
ppp115200:115200 cs8 -parenb hupcl:115200 cs8 -parenb hupcl::uu115200 ppp57600:57600 cs8 -parenb hupcl:57600 cs8 -parenb hupcl::uu57600 ppp38400:38400 cs8 -parenb hupcl:38400 cs8 -parenb hupcl::uu38400 ppp19200:19200 cs8 -parenb hupcl:19200 cs8 -parenb hupcl::uu19200 ppp9600:9600 cs8 -parenb hupcl:9600 cs8 -parenb hupcl::uu9600 ppp4800:4800 cs8 -parenb hupcl:4800 cs8 -parenb hupcl::uu4800 uu115200:115200 cs7 parenb parodd hupcl:115200 cs7 parenb parodd hupcl::ppp57600
uu57600:57600 cs7 parenb parodd hupcl:57600 cs7 parenb parodd hupcl::ppp38400 uu38400:38400 cs7 parenb parodd hupcl:38400 cs7 parenb parodd hupcl::ppp19200 uu19200:19200 cs7 parenb parodd hupcl:19200 cs7 parenb parodd hupcl::ppp9600 uu9600:9600 cs7 parenb parodd hupcl:9600 cs7 parenb parodd hupcl::ppp4800 uu4800:4800 cs7 parenb parodd hupcl:4800 cs7 parenb parodd hupcl::ppp2400
Figure 33 shows how the ttylabel entry in the /etc/saf/zsmon/_pmtab file matches an entry in the /etc/ttydefs file. In this example, the ttylabel is part of the default entry provided by the Solaris Operating Environment for serial port B.
Figure 33. How ttymon Identifies the ttylabel in the /etc/ttydefs File
The /etc/ttydefs file also contains information about speed and terminal settings for the TTY ports on a system. You can use the sttydefs(1M) administrative command to create new entries in the /etc/ttydefs file. See the sttydefs(1M) manual page for information on how to configure the /etc/ttydefs file.
The terminfo Database
The terminfo database describes the characteristics of TTY devices. The source files in terminfo specify a set of capabilities for a device by quantifying certain aspects of the device and by specifying character sequences that control particular results. This database is often used by applications such as vi and curses, as well as by the ls and more commands. Information in the terminfo database is stored in a compiled binary format. The terminfo compiler, tic(1M), translates a terminfo file from source format to the required compiled binary format that applications use.
If you have site-specific termcap entries for devices, you can use the captoinfo command to convert those entries into terminfo source format. Then, use the tic compiler to translate the data into compiled format. See the captoinfo(1M) and tic(1M) manual pages for more information.
The tput Command
Use the tput(1M) command to initialize or reset the terminal or to make terminal-dependent capabilities and information available to the shell. The tput command sets terminal characteristics, using data in the terminfo database. The tput command is similar to the SunOS 4.x tset(1B) command, which is provided in the SunOS/BSD Compatibility Package. The tput command has the following syntax.
tput [-Ttype] init tput[-Ttype] reset
The stty Command
The /usr/bin/stty command is the Solaris version of the SunOS 4.x stty command. The old /usr/ucb/stty command is available in the SunOS/BSD Compatibility Package. Use of the options varies, depending on which version of stty you are using. The stty command has the following syntax.
stty [-a] [-g] [options]
The -a option lists current options by their termio names. The -g option lists the same information in a format that can be used as an argument to another stty command.
The following examples show the default line settings using first the /usr/bin/stty command and then the /usr/ucb/stty command.
paperbark% /usr/bin/stty speed 9600 baud; -parity cstopb hupcl loblk rows = 46; columns = 79; ypixels = 700; xpixels = 721; erase = ^h; swtch = <undef>; -inpck -istrip icrnl -ixany ixoff onlcr echo echoe echok echoctl echoke iexten paperbark% /usr/ucb/stty speed 9600 baud; -parity cstopb hupcl loblk rows = 46; columns = 79; ypixels = 700; xpixels = 721; erase = ^h; swtch = <undef>; -brkint -inpck -istrip ixoff crt iexten paperbark%
Table 38 compares the default global line settings for SunOS 4.x and the Solaris Operating Environment. Note that the dash means not to set the value.
Table 39 compares the default input/output settings for SunOS 4.x and the Solaris Operating Environment. The i settings are for input, the o settings are for output.
Table 40 compares the default local settings for SunOS 4.x and the Solaris Operating Environment.
UUCP Files
To use uucp, tip, or cu with modems and terminals, you must use information from or add information to the /etc/uucp/Dialers and /etc/uucp/Devices files. Each of these files is described in the following sections.
The /etc/uucp/Dialers File
The /etc/uucp/Dialers file contains information that specifies the initial conversation that takes place on a line before it can be made available for transferring data. This conversation is usually a sequence of character strings that is transmitted and expected. The string often contains a telephone number that is dialed by an automatic call unit (ACU). Each entry in /etc/uucp/Dialers begins with a label identifying the type of the modem. The Solaris /etc/uucp/Dialers file contains support for many different modem types. Each type of caller, except built-in callers, included in the /etc/uucp/Devices file should be contained in the /etc/uucp/Dialers file. You probably do not need to create an entry in this file. You do need to look in this file to verify that it contains an entry appropriate for your modem and to determine the type to use when you edit the /etc/uucp/Devices file.
Each line consists of three parts: the name of the caller, the table that translates the phone number into the code for the particular device, and a chat script to establish the connection. Comments at the beginning of the /etc/uucp/Dialers file explain the codes shown in the following brief excerpt.
penril =W-P "" d > Qc : d- > sp9c )-Wp dsp9c-) yc : ETP > 9c OK ventel--=&-% "" p c $ <KT%% >c ONLINE! vadic =K-K "" 05p *- 05p-* 05p-* Dp BER? ETe c LINE develcon "" "" prpsc est: 07 EDe 07 micom "" "" sc NAME? D c GO direct ########## # The following entry is for use with direct connections # using ttymon with the -b and -r options on both ends, # or the old uugetty with the -r option. ########## uudirect "" "" d in:--in: # Rixon Intelligent Modem -- modem should be set up in the Rixon # mode and not the Hayes mode. # rixon =&-% "" d $ s9c )-W ds9c-) sc : T c $ 9c LINE # Hayes Smartmodem -- modem should be set with the configuration # switches as follows: # # S1 - UP S2 - UP S3 - DOWN S4 - UP # S5 - UP S6 - DOWN S7 - ? S8 - DOWN # hayes =,-, "" dApTE1V1X1Q0S2=255S12=255 c OK EATDTT c CONNECT
The /etc/uucp/Devices File
The /etc/uucp/Devices file contains information for all of the devices that can be used to establish a link to remote systems. Provisions are made for several types of devices, such as ACUs, direct links, and network connections. You need to add an entry to the /etc/uucp/Devices file if you want to set up support for a bidirectional modem. Each entry in the Devices file has the following format.
type line line2 class dialer-token-pairs
The following excerpt from the /etc/uucp/Devices file shows the default entries.
TCP,et - - Any TCP - ACU cua/b - Any hayes Direct cua/b - Any direct
The type argument you supply when editing the /etc/uucp/Devices file is the name of the modem as displayed at the end of the entry from the /etc/uucp/Devices file. It points to an entry in /etc/uucp/Dialers.
SAF Log Files
The SAF records port monitor behavior in the /var/saf/_log file. In addition, each ttymon port monitor has its own log file, /var/saf/pmtag/log, in which it records information, such as messages that it receives from sac and the services that it starts.
An example of the end of the /var/saf/_log file follows. This information shows that the system was rebooted three times and that the ttymon port monitor zsmon was started and enabled successfully each time.
paperbark% tail /var/saf/_log
Wed Oct 18 11:33:13 2000; 382; port monitor <zsmon> changed state from
STARTING to ENABLED
Wed Oct 18 17:11:59 2000; 383; *** SAC starting ***
Wed Oct 18 17:11:59 2000; 393; starting port monitor <zsmon>
Wed Oct 18 17:11:59 2000; 383; port monitor <zsmon> changed state from
STARTING to ENABLED
Thu Oct 19 08:24:15 2000; 383; *** SAC starting ***
Thu Oct 19 08:24:17 2000; 393; starting port monitor <zsmon>
Thu Oct 19 08:24:17 2000; 383; port monitor <zsmon> changed state from
STARTING to ENABLED
Fri Oct 20 10:02:47 2000; 381; *** SAC starting ***
Fri Oct 20 10:02:49 2000; 393; starting port monitor <zsmon>
Fri Oct 20 10:02:49 2000; 381; port monitor <zsmon> changed state from
STARTING to ENABLED
paperbark%
Following is an example of the /var/saf/_log file from another system that has a listen tcp port monitor configured.
seachild% tail /var/saf/_log
Fri Mar 24 12:06:19 2000; 176; *** SAC starting ***
Fri Mar 24 12:06:20 2000; 181; starting port monitor <tcp>
Fri Mar 24 12:06:20 2000; 182; starting port monitor <zsmon>
Fri Mar 24 12:06:21 2000; 176; port monitor <zsmon> changed state from
STARTING to ENABLED
Fri Mar 24 12:06:22 2000; 176; port monitor <tcp> changed state from STARTING
to ENABLED
Sat Mar 25 20:47:44 2000; 177; *** SAC starting ***
Sat Mar 25 20:47:44 2000; 183; starting port monitor <tcp>
Sat Mar 25 20:47:45 2000; 184; starting port monitor <zsmon>
Sat Mar 25 20:47:45 2000; 177; port monitor <zsmon> changed state from
STARTING to ENABLED
Sat Mar 25 20:47:46 2000; 177; port monitor <tcp> changed state from STARTING
to ENABLED
seachild%
The following example shows the end of the /var/saf/zsmon/log file. The pmtag zsmon is used for ttymon ports. This information shows more detailed information about how the ttymon port monitor zsmon was initialized successfully.
paperbark% tail /var/saf/zamon/log
Fri Oct 20 10:02:49 2000; 393; PMTAG: zsmon
Fri Oct 20 10:02:49 2000; 393; Starting state: enabled
Fri Oct 20 10:02:49 2000; 393; Got SC_ENABLE message
Fri Oct 20 10:02:49 2000; 393; max open files = 1024
Fri Oct 20 10:02:49 2000; 393; max ports ttymon can monitor = 1017
Fri Oct 20 10:02:49 2000; 393; *ptr == 0
Fri Oct 20 10:02:49 2000; 393; SUCCESS
Fri Oct 20 10:02:49 2000; 393; *ptr == 0
Fri Oct 20 10:02:49 2000; 393; SUCCESS
Fri Oct 20 10:02:49 2000; 393; Initialization Completed
paperbark%
The following example shows the end of the /var/saf/tcp/log file. The pmtag tcp is the default name for the listen port monitor.
seachild% tail /var/saf/tcp/log
04/06/2000 15:11:10; 183; Connect: fd 7, svctag lpd, seq 117, type passfd
04/06/2000 15:11:12; 183; Connect: fd 7, svctag lpd, seq 118, type passfd
04/06/2000 15:26:12; 183; Connect: fd 7, svctag lpd, seq 119, type passfd
04/06/2000 15:26:13; 183; Connect: fd 7, svctag lpd, seq 120, type passfd
04/06/2000 15:34:02; 183; Connect: fd 6, svctag 0, seq 41, type exec
04/06/2000 15:34:03; 3391; NLPS (lp) passfd: /var/spool/lp/fifos/listenS5
04/06/2000 15:50:10; 183; Connect: fd 7, svctag lpd, seq 121, type passfd
04/06/2000 15:50:11; 183; Connect: fd 7, svctag lpd, seq 122, type passfd
04/06/2000 16:05:12; 183; Connect: fd 7, svctag lpd, seq 123, type passfd
04/06/2000 16:05:12; 183; Connect: fd 7, svctag lpd, seq 124, type passfd
seachild%
NOTE
You should periodically clear out or truncate these log files. If you want cron to do the cleanup for you, create cron jobs with the crontab(1) command. Refer to the crontab(1) manual page for more information.