Customizing Subprocess Control

Whenever SoftBench starts a process (either local or remote), it uses the Subprocess Control (SPC) service. This section describes how you can customize SPC behavior.

The SPC Authentication Directory

SoftBench uses the SPC to start a SoftBench tool on a remote system. Before you can use a remote SoftBench tool, access must be authenticated. During authentication, the SPC server on the remote execution host creates a temporary file in a directory to verify the user's identity on both systems.

Requirements for the SPC Authentication Directory

In order for authentication to succeed:

The authentication directory must exist.
Both the local and the remote system must have read/write access to the authentication directory.
The directory must allow read/write access by any SoftBench user.
The directory may be local on one system, but must be mounted on the other. It may be mounted on both.
This may be a hard mount, or the mount may occur automatically through the -hosts automounter map.
Operation of the validation directory is unreliable if it is mounted through an automounter map other than -hosts.

Changing the Authentication Directory

The default SPC authentication directory is /var/tmp on the remote execution host. An alternate location can be defined.

The default location may not always be practical. For example, you may not be able to export /var/tmp with write permission if the parent directories have different access permissions. Another example where access may be restricted is if you are trying to automount the directory via a -hosts map and the parent directories are not also exported.

For a system to receive remote execution requests in these cases, the administrator of that system must specify an alternate temporary directory to use. The directory may reside on any system on the network, as long as the requirements listed in “Requirements for the SPC Authentication Directory ” are met.

Once the alternate location is selected, the full path to the alternate validation directory should be placed in the file:

/opt/softbench/config/sharedtmpdir

on each system where remote SoftBench tools are to be executed.

Although /opt/softbench/config/sharedtmpdir is the recommended location for this information, the contents of that file can be overridden by a sharedtmpdir file in one of the following alternate locations:

Override sharedtmpdir file on HP-UX 11.0:

/etc/opt/softbench/config/sharedtmpdir

Override sharedtmpdir files on HP-UX 10.20:

		/etc/opt/softbench/config/sharedtmpdir
	/usr/bms/config/sharedtmpdir
	/etc/usr/bms/config/sharedtmpdir

Other Authentication Configurations

If you are using remote SoftBench processes between more than two systems, you may want to set up a single authentication directory for a group of systems. The advantage of this is

it may be much simpler to create and export a single authentication directory.

The disadvantage of this is

having a single authentication directory for a large number of may cause a bottleneck that delays remote processes.
if the system where the directory is located is unavailable, remote SoftBench processes could not be started.

For example, if your team has a single reliable hub system that already provides remotely mountable disks, the shared temporary directory could be placed on that system. Every system used by your team could then share that one directory, minimizing the administration needed to set up each new system.

Customizing Environment Variables for SoftBench

When one of the SoftBench tools needs to control other processes, such as SoftBench Builder running make, it can run these processes on a different host. To do this type of remote processing, your access rights are checked on the remote system, and your current environment is transmitted to the remote process.

To check access rights on the remote system:

A validation file is created in a directory accessible to both hosts.
The user ID of the file owner is obtained and the remote process runs as this user ID.
This user ID is used to obtain initial settings for the HOME and SHELL environment variables for the remote process. See getpwent(3) for more information.

When the process is run, the environment of the parent process is modified before it is inherited by the child. For local processes, the following procedure is followed:

The contents of the file /opt/softbench/config/softenv are read and each variable found in this file is put into the child environment. The variables in this file overwrite existing variables with the same names in the child environment.
The environment created by step 1 is further modified by the contents of your $HOME/.softenv file. As in step 1, a variable in the $HOME/.softenv file overwrites any existing variable of the same name.
The environment created by steps 1 and/or 2 is further modified by the contents of your $HOME/.softenv.hostname file. As in the preceding steps, a variable in the $HOME/.softenv.hostname file (where hostname is the name of the local system) overwrites any existing variable of the same name. This file is especially useful if you have your launch directory mounted on more than one system. You can create $HOME/.softenv.hostname files to customize the environment variables used by SoftBench on each system.

Using softenv Files with Remote Processes

When SoftBench starts a process on a remote system, customizations to environment variables used by SPC are evaluated in the following order:

The environment is modified according to the following files on the local host:
- /opt/softbench/config/softenv
- $HOME/.softenv
- $HOME/.softenv.local-host (where local-host is the name of the local system)
The environment is transferred to the remote host.
The environment is modified according to the following files on the remote host:
- /opt/softbench/config/softenv
- $HOME/.softenv
- $HOME/.softenv.remote-host (where remote-host is the name of the remote system)
DISPLAY is modified to point to the same display as the invoking tool.

The remote process is then run, inheriting this modified environment.

Creating a Custom softenv File

To specify an environment variable in the /opt/softbench/config/softenv, $HOME/.softenv, or $HOME/.softenv.hostname files, use varname=value, where varname is the name of the environment variable and value is the desired value.

The format of a softenv file is similar to other shell command files (such as .login) with the following exceptions:

Only environment variable assignments are supported.
Environment variables in the value part of an assignment are not expanded. For example, if you have a statement such as:
PATH=/bin:$PATH
The $PATH is not expanded when PATH is assigned. softenv entries strictly redefine environment variables.
White space can appear in a value without using quoted strings.
If you place quotes in a value, the quotes are retained in the value of environment variable being set.
Line continuation (backslash followed by newline) is not supported.

Controlling Access and Security in SoftBench

Remote execution of SoftBench Debugger and remote compiles from SoftBench Builder require that the inetd process be configured and running on the remote system. The normal installation procedures configure the inetd automatically, and the networking services described in the Installing and Administering LAN/9000 manual are required.

The inetd.sec file is described in detail in the inetd.sec(4) reference page.

If SoftBench is to be run on a system connected to a network, it should be configured to restrict access to only the work-group that requires SoftBench. This security model is very similar to the X model in which /etc/X0.hosts is used to restrict access to the service.

The "mserve" (Message Server) and "spc" (Sub-Process Control) services, defined by SoftBench, are automatically restricted in inetd.sec by the customization script to:

Host name of the system if it is running standalone.
Nodes in the cluster if it is a cluster system.

To provide access from systems other than the above, edit the inetd.sec file manually. It is advisable to keep the access list down to a minimum, as these services allow access to the system by anyone connecting to the port (just as X11 does).

Example of Controlling Access

For example, on a cluster of three nodes, the inetd.sec file contains the following after installation:

	mserve  allow   hostA hostB hostC
	spc     allow   hostA hostB hostC

To add a new host, simply append it to the end of the line. To add a complete network, simply include the network or subnet component of the address:

	mserve  allow   hostA hostB hostC 192.6.36.*
	spc     allow   hostA hostB hostC 192.6.36.*

If a system attempts to connect to the message server or spc without access permissions, an error message occurs. The error message may indicate a broken connection and may suggest that the inetd.sec should be checked. Since there are other reasons why a connection may be broken, SoftBench cannot always identify the cause as a security problem. If the system on which SoftBench is started does not have permission to connect to the message server, softbench exits immediately on startup with a broken connection error. Even if inetd.sec was correctly configured upon installation, later modifications to the file could generate this problem.

The host on which the environment is first started must always be allowed in inetd.sec. If inetd.sec is shared via an NFS mount (not recommended), then it would have to include all hosts which need to talk to any message server with access to the shared file. This would not be handled automatically by the installation procedure as it only provides permission to the installing host and cluster.

Note that if the hostname or internet address of the system is changed, the inetd.sec file should be checked to make sure it still allows access to the correct systems.