PART 4
Service Access Facility

This part describes the Solaris 2.x Service Access Facility (SAF) in three chapters.

Chapter 9 provides an overview of the SAF and describes the port monitors and services used by the SAF. Chapter 10 describes how to set up and administer the SAF for modems and terminals. Chapter 11 describes how to set up and administer the SAF for printers and how to troubleshoot printing problems.

Refer to the chapters in this part if you need to set up a new SAF service for terminals, modems, or printers or to modify an existing one.

CHAPTER 9
Understanding the Service Access Facility

Benefits of the SAF

The SAF Daemons

The SAF Commands

SAF Architecture

Reference to SAF Commands, Tasks, and Options

Admintool: Serial Ports and SAF

Templates

Starting Admintool: Serial Ports

THE SERVICE ACCESS FACILITY (SAF) IS A GROUP OF DAEMONS AND ADMINISTRATIVE commands that provide a flexible administrative framework for managing service requests in an open-systems environment. You can use the SAF to set up and administer port monitors so that users can log in from a terminal or a modem and can use network printing resources. The SAF replaces the SunOS 4.x getty, login, and stty commands and the /etc/gettytab and /etc/ttytab files. SAF controls and configures terminals and printers using the terminfo database.

You can use the Admintool: Serial Ports graphical user interface to the SAF to set up and configure modems and character terminals on a local system. See See Admintool: Serial Ports and SAF for more information. If you have Solstice AdminSuite available, you can use its Serial Port Monitor graphical user interface to set up and configure modems and character terminals remotely.

Benefits of the SAF

The SAF is an open-systems solution that controls how users access their UNIX system through TTY devices and local area networks. The SAF offers well-defined interfaces so that customers and value-added resellers can easily add new features and configure existing ones.

Flexibility is an important requirement in an open-systems environment. Service of incoming connection requests must be available regardless of the location or connection path of the requester. Both local and remote requests must be handled, as much as possible, independently of the available network transports.

Restrictions in previous System V and BSD-based versions of UNIX prevented this type of open-systems computing environment. Those restrictions included:

•  Lack of selective access control.

•  Inflexible getty process. Only the login service was provided because it was hard-wired in.

•  Difficulty in selectively disabling/enabling login service.

•  Impossibility of scaling an increasing number of ports because of the model of one getty per potential access port.

•  Inaccuracy of /etc/utmp in accounting for remote services.

•  Mixed or no authentication for non-RPC and TCP/IP requests.

You can use the Solaris 2.x SAF framework if you want to create a complex application, such as the banking database service shown in Figure 9-1.

Figure 9-1  A typical bank data-base server.

The left side of the figure shows incoming connection requests for services--some from local terminals, others from automatic teller machines (ATMs). The right side shows the service that is provided. Many requests come from local area networks that are running a variety of different transport protocols. Bank networks usually have wide-area network connections over a variety of datalink layers, such as X.25, SDLC, frame relay, and ISDN.

The SAF Daemons

The SAF uses the Service Access Controller daemon (sac) to oversee all of the SAF port monitors. The sac daemon is started at boot time at run level 2 by init.

The following two port monitors watch for activity on a port:

•  The ttymon port monitor handles requests for login services. Solaris 2.x provides a default set of ttymon services for use with a standalone system. You need to set up a ttymon port monitor to process login requests from modems and additional terminals (such as Wyse or VT terminals) if you configure them for a system.

•  The listen port monitor handles requests for network services, such as remote printing and remote file access. You need to set up a listen port monitor to provide remote printing services.

After the ports are configured, the port monitors are automatically started any time a system is running in multiuser mode. The ttymon and listen port monitors are described in more detail in "Port Monitors" on page 167.

The SAF Commands

You can use three SAF commands to administer modems and alphanumeric terminals--sacadm, pmadm, and ttyadm. You can also use three SAF commands to administer printing--sacadm, pmadm, and nlsadmin.

Use the sacadm command to add and remove port monitors. This command is your main link with the Service Access Controller (SAC) and its administrative files /etc/saf/_sactab, /etc/saf/_safconfig, and /etc/saf/pmtag/_config.

---

NOTE:  Although these configuration files are ASCII text and can be edited, the SAC may not be aware of the changes. SunSoft recommends that you do not edit these files directly. Instead, you should use the sacadm and pmadm commands to make changes to the SAF administrative files.

---

Use the pmadm command to add or remove a service and to associate a service with a particular port monitor. Each port monitor has its own administrative file.

You can use two additional commands, ttyadm and nlsadmin, as part of the command-line arguments to pmadm to provide input specific to a port monitor. The ttyadm command provides information for the ttymon port monitor; the nlsadmin command provides information for the listen port monitor. SAF commands, which use many options and arguments, can be quite lengthy. See the section “Reference to SAF Commands, Tasks, and Options” on page 179 for more information.

SAF Architecture

Figure 9-2 shows the architecture of SAF. Each of the architectural elements is described in the following paragraphs.

Figure 9-2  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.