The service access facility (SAF) is a port management system that manages requests and responses for access to system ports. In this case, a port is defined as the physical connection between a peripheral device and the system. For example, most systems have one or more serial ports that allow for sequential data transmission, effectively down a single line. In contrast, a parallel port allows for several lines of data to be transmitted bidirectionally. The SAF system is designed to allow requests to be made to the system from peripheral devices through ports and ensure that these requests are appropriately serviced by the relevant port monitor.
Modems, which allow Solaris 9 systems to connect to the Internet over a phone line, require SAF to operate through system serial ports. Thus, it’s important to understand how to configure ports, port monitors, and listeners in preparation for making an Internet connection using a modem. Note that most Solaris systems are never accessed through a modem; however, if a system’s only network card has died and the console is physically inaccessible, a modem can be a lifesaver.
The Point-to-Point Protocol (PPP) daemon is commonly used to set up modem access to an Internet service provider (ISP). PPP supports TCP/IP and provides the Challenge Handshake Authentication Protocol (CHAP), providing a higher level of security than usually found on modem links. The PPP daemon relies on the chat program to perform the dial-up and handle connections. In this section, we’ll examine how to set up port monitors and PPP for Internet connections.
Central to the idea of providing services through serial ports is the port monitor, which continuously monitors the serial ports for requests to log in. The port monitor doesn’t process the communication parameters directly, but accepts requests and passes them to the operating system. Solaris 9 uses the ttymon port monitor, which allows multiple concurrent getty requests from serial devices.
To configure the port for a terminal, start up admintool and enter the user mode, which can be either Basic, More, or Expert. In most cases, Basic setup will be sufficient . admintool allows the configuration of most parameters for the port, including the baud rate for communications, default terminal type, flow control, and carrier detection. The values entered here should match those on the matching VT-100 terminal. Once the settings have been saved, it is possible to check the validity of the settings by using the pmadm command:
# pmadm -l -s ttyb
The process that initiates the service access facility is known as the service access controller (/usr/lib/saf/sac). It is started when the system enters run level 2, 3, or 4, as shown in this /etc/inittab entry:
sc:234:respawn:/usr/lib/saf/sac -t 300
Here, the respawn entry indicates that if a process is not running when it should be, it should be respawned. For example, if a system changes from run level 2 to run level 3, sac should be running. If it is not present, it will be restarted.
When sac is started, it reads the script /etc/saf/_sysconfig, which contains any local configurations tailored for the system. Next, the standard configuration file /etc/saf/_sactab is read, and sac spawns a separate child process for each of the port monitors it supports (ttymon and listen). A sample _sactab is shown here:
# VERSION=1 zsmon:ttymon::0:/usr/lib/saf/ttymon #
Port monitors also read a configuration file (/etc/saf/zsmon/_pmtab) that is used to configure the ttymon and listen port monitors. A sample _pmtab file is shown here:
# VERSION=1 ttya:u:root:reserved:reserved:reserved:/dev/term/a:I:: /usr/bin/login::9600:ldterm,ttcompat:ttya login\: ::tvi925:y:# ttyb:u:root:reserved:reserved:reserved:/dev/term/b:I:: /usr/bin/login::9600:ldterm,ttcompat:ttyb login\: ::tvi925:y:#
The point of this hierarchical configuration file structure is that values read from /etc/saf/_sysconfig and /etc/saf/_sactab by sac are inherited by the spawned port monitor processes, which then have the ability to configure their own operations.
The SAF has two types of port monitors: the terminal port monitor (ttymon) and the network port monitor (listen). For example, the ttymon port monitor for the console is started in run levels 2, 3, and 4, through an /etc/inittab entry like the following:
co:234:respawn:/usr/lib/saf/ttymon -g -h -p "`uname -n` console login: " -T vt100 -d /dev/console -l console -m ldterm,ttcompat
The ttymon process is active when a monitor is connected to a server, such as a dumb terminal, rather than a graphics monitor.
PPP is the most commonly used protocol for connecting modems over a phone line (or, uncommonly, over a normal serial line) to support TCP/IP. It replaces the earlier Serial Line Interface Protocol (SLIP), which did not provide any level of security or authentication for serial line services. The Solaris 9 implementation of PPP is based on the ANU version (ftp://cs.anu.edu.au/pub/software/ppp). PPP provides reliable access to the Internet because it includes error correction and the ability to autodetect some network parameters. All of the parameters for the PPP daemon (pppd) are stored in /etc/ppp/options. Alternatively, for options that are specific to each serial port, a new configuration file can be created (such as /etc/ppp/options.cua.a for the serial port /dev/cua/a). This is useful where two modems are connected to the two standard serial interfaces on a SPARC system that are connected to two separate modems, which in turn dial completely different ISPs—the lesson for high availability is to “be prepared” for the worst-case scenario. Supporting network operations through a 56K modem is going to be challenging, but not impossible, in an emergency. Figure 17-2 shows a PPP configuration with high availability in mind.
The listen port monitor is managed by the listen and nlsadmin commands. In contrast to ttymon, the listen port monitor manages network ports and connections by listening for requests to access services and daemons. The listen monitor uses the Transport Layer Interface (TLI) and STREAMS to implement OSI-compliant network service layers. Specific networks ports are assigned to the listen monitor, and child processes are spawned to handle each client request. One of the key features of listen is that it can provide services that are not managed by inetd—since all daemons can be accessed through a listen service. This is an important feature for the different users accessing services on a Solaris system. For example, a network connection could serve web traffic, while a dial-in connection could cater to telnet or SSH access.
The nlsadmin command is used to set up transport providers for STREAMS-compatible network services. In order to configure a TLI listener database, the nlsadmin command can be used to configure the listener. First, the TCP/IP database is created:
# nlsadmin -i tcp
Next, set the local hexadecimal address:
# nlsadmin -l \x11331223a11a58310000000000000000 tcp
All services that need to be run will then need to be entered into the TLI listener database.
Like any modern server system, Solaris 9 supports the connection of simple external devices through both a serial (RS-232-C or RS-423) and a parallel port. The two most common uses for serial devices on a SPARC system are connecting a VT-100 terminal or equivalent, to operate as the system console if no graphics device is installed, and as a modem, enabling dial-up Internet access using the Point-to-Point Protocol (PPP). The former is a common practice in many server rooms, where the expense of a monitor and video card can be eliminated by using a VT-100 terminal as the console, because many SPARC machines require a display device to boot at all. On x86 systems, there are many more devices available that often only have drivers available for other operating systems. Sun and other third-party hardware vendors are slowly making releases available for these devices through the Solaris Developer Connection. If you need to obtain an updated copy of the Solaris Device Configuration Assistant, and any updated device drivers for supported external devices, these are currently available for download at http://soldc.sun.com/support/drivers/boot.html.
Solaris 9 has a graphical user interface (GUI) for serial device configuration, provided through the admintool program. admintool is generally used for system administration tasks, like adding users and groups, but it also has facilities for configuring parallel devices (like printers) and serial devices (like modems). It contains templates for configuring standard modem and terminal devices, and supports multiple ports. It’s important to note that SMC is slated to replace admintool in future releases of Solaris.
Solaris 9 works best with external Hayes-compatible modems, which are also supported by other operating systems such as Microsoft Windows. However, modems that require specific operating system support (such as so-called “WinModems”), will not work with Solaris 9. In addition, internal modem cards are generally not supported by Solaris 9. While older modems tend to use external (but sometimes internal!) DIP switches, modern modems can be configured using software to set most of their key operational parameters.
Modem access can be configured to allow inbound-only, outbound-only, and bidirectional access, which allows traffic in both directions, using a similar scheme. In the following example, we’ll consider the scenario of dial-out-only access. The modem should be connected to one of the system’s serial ports (A or B) and switched on. The A and B serial ports map to the devices /dev/cua/a and /dev/cua/b, respectively.
To test the modem, use the tip command
# tip hardwire
where hardwire should be defined in /etc/remote. The hardwire entry should be similar to this entry
hardwire:\ :dv=/dev/cua/a:br#19200:el=^C^S^Q^U^D:ie=%$:oe=^D:
where 19,200 bps is the connection speed between the modem and the serial port. In addition, /etc/remote should have a connection string associated with each modem that’s connected to the system. For example, the string
cua1:dv=/dev/cua/a:p8:br#19200
specifies that 19,200 bps is the connection speed between the modem and the serial port, with 8-bit transmission and with no parity enabled. To use this entry specifically, you would use the command
# tip cua1
If the message
connected
appears on your terminal, the system is able to communicate successfully with the modem. For Hayes-compatible modems, command strings can be entered directly like this:
ATE1V1
If you see “ok”, the modem is communicating as expected and can be configured to run PPP.
The first step in configuring PPP is to insert appropriate configuration information in /etc/ppp/options. The following options are the most commonly used:
<tty_name> Name of the terminal device to use for communication.
<speed> Speed at which to transmit data.
auth Specifies that authentication is required (noauth specifies that no authentication is required).
callback Requests a callback from the remote server. Useful for saving on long distance charges!
connect or init Specifies the chat script to configure line communications.
mru Sets a maximum receive unit (MRU) value that specifies a limit on the packet size transmitted by the server.
mtu Sets a maximum transmit unit (MTU) value that specifies a limit on the packet size transmitted by the client.
Other options may be required, especially for authentication, but using these options is generally sufficient to make a connection. For further information, you should consult Celeste Stokely’s PPP guide: http://www.stokely.com/unix.serial.port. resources/ppp.slip.html.
The ttymon port monitor is managed by the ttyadm command. ttymon is designed to monitor requests from ports to allow remote access to the system. The ttymon operates continually, spawning child processes when appropriate in order to service requests, which are sequentially numbered (for example, ttymon1, ttymon2, and so forth). The most common request for terminals is probably for an interactive login; thus, /usr/bin/ login is requested. The sacadm command can be used to list all current ttymon processes:
# sacadm -l PMTAG PMTYPE FLGS RCNT STATUS COMMAND ttymon1 ttymon - 2 ENABLED /usr/lib/saf/ttymon #ttymon1 ttymon2 ttymon - 2 ENABLED /usr/lib/saf/ttymon #ttymon2 ttymon3 ttymon - 2 ENABLED /usr/lib/saf/ttymon #ttymon3
In order to view the services currently being provided through a particular monitor, you can use the pmadm command for each monitor process:
# pmadm -l -p ttymon2 PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC> ttymon2 ttymon 11 u root /dev/term/11 - - /usr/bin/login - 9600 - login: -tvi925 ttymon2 ttymon 12 u root /dev/term/12 - - /usr/bin/login - 9600 - login: -tvi925 ttymon2 ttymon 13 u root /dev/term/13 - - /usr/bin/login - 9600 - login: -tvi925 ttymon2 ttymon 14 u root /dev/term/14 - - /usr/bin/login - 9600 - login: -tvi925
Here, we can see that ports /dev/term/11 through /dev/term/14 are being serviced using the login service.
Once the /etc/ppp/options file has been set up, a connection can then be made from the command line. For example, to connect using a 56K modem using the chat script emergency1.chat, the following command will establish a connection without authentication:
# pppd connect 'chat –f emergency1.chat' /dev/cua/a 57600 noauth
The port monitors are managed by the pmadm command. Port services can be managed by using the following commands:
pmadm -a |
Adds a port monitor service. |
pmadm -d |
Disarms a port monitor service. |
pmadm -e |
Enables a port monitor service. |
pmadm -r |
Removes a port monitor service. |
The sacadm command is used to manage port monitors. The following functions are available:
sacadm -a |
Attaches a new port monitor |
sacadm -e |
Arms a port monitor |
sacadm -d |
Disarms a port monitor |
sacadm -s |
Initializes a port monitor |
sacadm -k |
Kills a port monitor |
sacadm -l |
Lists port monitor details |
sacadm -r |
Deletes a port monitor |
tip is a command that acts like a terminal. It can be used, for example, to access remote systems directly through a serial port, where one system acts as the console for the other. Next, we’ll use the tip command to connect a Solaris 9 system to a modem. Before proceeding, however, we’ll examine some of the key features of tip in its own right.
tip uses the /etc/remote file to enable it to make connections through the serial port. For example, if you have a profile set up in /etc/remote, it’s possible to fire up a terminal session immediately by using the command
# tip profile
where profile is the name of the profile that you’ve set up with all the settings that the port requires to operate. tip also uses initialization settings in the .tiprc file to specify its operational parameters.
The following table shows the most commonly used tip commands:
Command |
Description |
---|---|
~. |
Exits the session. |
~c |
Changes directory. |
~! |
Spawns a shell. |
~>> |
Sends a local file. |
~<< |
Receives a remote file. |
~p |
Sends a local file. |
~t |
Receives a remote file. |
~C |
Allows a local application to connect to a remote system. |
~# |
Issues a break command. |
~s |
Defines a variable. |
~^z |
Suspends tip. |