The array system allows you to run distributed sessions on multiple nodes of an array. You can access the Array from either:

In each case, you log in to one node of the Array in the way you would log in to any remote UNIX host. From a workstation or an X terminal you can of course open more than one terminal window and log into more than one node.

ainfo -a arrayname machines

rlogin hydra6

You query the status of processes using the system command ps. To generate a full list of all processes on a local system, use a command such as the following:

ps -elfj

You can monitor the activity of processes using the command top (an ASCII display in a terminal window).

You can schedule commands to run at specific times using the at command. You can kill or stop processes using the kill command. To destroy the process with PID 13032, use a command such as the following:

kill -KILL 13032

Table 3-2, summarizes information about local process management..

Array Services is composed of a daemon-a background process that is started at boot time in every node-and a set of commands such as ainfo(1). The commands call on the daemon process in each node to get the information they need.

One concept that is basic to Array Services is the array session, which is a term for all the processes of one application, wherever they may execute. Normally, your login shell, with the programs you start from it, constitutes an array session. A batch job is an array session; and you can create a new shell with a new array session identity.

Each session is identified by an array session handle (ASH), a number that identifies any process that is part of that session. You use the ASH to query and to control all the processes of a program, even when they are running in different nodes.

Each node is server, and as such has a hostname. The hostname of a node is returned by the hostname(1) command executed in that node as follows:

% hostname
tokyo

The command is simple and documented in the hostname(1) man page. The more complicated issues of hostname syntax, and of how hostnames are resolved to hardware addresses are covered in hostname(5).

An Array system as a whole has a name too. In most installations there is only a single Array, and you never need to specify which Array you mean. However, it is possible to have multiple Arrays available on a network, and you can direct Array Services commands to a specific Array.

It is possible for the Array administrator to establish an authentication code, which is a 64-bit number, for all or some of the nodes in an array (see "Configuring Authentication Codes" on page 58). When this is done, each use of an Array Services command must specify the appropriate authentication key, as a command option, for the nodes it uses. Your system administrator will tell you if this is necessary.

---

Note: When running Secure Array Services, this configuration is not used. Authentication is enforced to AUTHENTICATION_NONE.

---

The -l and -s options work together. The -l (letter ell for “local”) option restricts the scope of a command to the node where the command is executed. By default, that is the node where the command is entered. When -l is not used, the scope of a query command is all nodes of the array. The -s (server, or node name) option directs the command to be executed on a specified node of the array. These options work together in query commands as follows:

The Array Services commands depend on environment variables to define default values for the less-common command options. These variables are summarized in Table 3-5.

If your network includes more than one Array system, you can use ainfo arrays at one array node to list all the Array names that are configured, as in the following example.

homegrown% ainfo arrays
Arrays known to array services daemon
ARRAY DevArray
    IDENT 0x3381
ARRAY BigDevArray
    IDENT 0x7456
ARRAY test
    IDENT 0x655e

Array names are configured into the array database by the administrator. Different Arrays might know different sets of other Array names.

You can use ainfo machines to learn the names and some features of all nodes in the current Array, as in the following example.

homegrown 175% ainfo -b machines 
machine homegrown homegrown 5434 192.48.165.36 0
machine disarray disarray 5434 192.48.165.62 0
machine datarray datarray 5434 192.48.165.64 0
machine tokyo tokyo 5434 150.166.39.39 0

In this example, the -b option of ainfo is used to get a concise display.

You can use ainfo nodeinfo to request detailed information about one or all nodes in the array. To get information about the local node, use ainfo -l nodeinfo. However, to get information about only a particular other node, for example node tokyo, use -l and -s, as in the following example. (The example has been edited for brevity.)

homegrown 181% ainfo -s tokyo -l nodeinfo
Node information for server on machine "tokyo"
MACHINE tokyo
    VERSION  1.2
    8 PROCESSOR BOARDS
        BOARD: TYPE 15   SPEED 190
            CPU:   TYPE 9   REVISION 2.4
            FPU:   TYPE 9   REVISION 0.0
...
    16 IP INTERFACES  HOSTNAME tokyo   HOSTID 0xc01a5035
        DEVICE  et0    NETWORK    150.166.39.0    ADDRESS   150.166.39.39  UP
        DEVICE atm0    NETWORK 255.255.255.255    ADDRESS         0.0.0.0  UP
        DEVICE atm1    NETWORK 255.255.255.255    ADDRESS         0.0.0.0  UP
...
    0 GRAPHICS INTERFACES
    MEMORY
        512 MB MAIN MEMORY
        INTERLEAVE 4

If the -l option is omitted, the destination node will return information about every node that it knows.

The system commands who(1), top(1), and uptime(1) are commonly used to get information about users and workload on one server. The array(1) command offers Array-wide equivalents to these commands.

homegrown 180% array -s tokyo -l who 
joecd    tokyo        frummage.eng.sgi -tcsh 
joecd    tokyo        frummage.eng.sgi -tcsh 
benf     tokyo        einstein.ued.sgi. /bin/tcsh 
yohn     tokyo        rayleigh.eng.sg vi +153 fs/procfs/prd
...

homegrown 181% array uptime 
   homegrown:  up 1 day,  7:40,  26 users,  load average: 7.21, 6.35, 4.72
    disarray:  up  2:53,  0 user,  load average: 0.00, 0.00, 0.00
    datarray:  up  5:34,  1 user,  load average: 0.00, 0.00, 0.00
       tokyo:  up 7 days,  9:11,  17 users,  load average: 0.15, 0.31, 0.29
homegrown 182% array -l -s tokyo uptime 
       tokyo:  up 7 days,  9:11,  17 users,  load average: 0.12, 0.30, 0.28

homegrown 183% array top 
        ASH        Host           PID User       %CPU Command
----------------------------------------------------------------
0x1111ffff00000000 homegrown        5 root       1.20 vfs_sync
0x1111ffff000001e9 homegrown     1327 arraysvcs      1.19 atop
0x1111ffff000001e9 tokyo        19816 arraysvcs      0.73 atop
0x1111ffff000001e9 disarray      1106 arraysvcs      0.47 atop
0x1111ffff000001e9 datarray      1423 arraysvcs      0.42 atop
0x1111ffff00000000 homegrown       20 root       0.41 ShareII
0x1111ffff000000c0 homegrown    29683 kchang     0.37 ld
0x1111ffff0000001e homegrown     1324 root       0.17 arrayd
0x1111ffff00000000 homegrown      229 root       0.14 routed
0x1111ffff00000000 homegrown       19 root       0.09 pdflush
0x1111ffff000001e9 disarray      1105 arraysvcs      0.02 atopm

In an Array system you can start a program with processes that are in more than one node. In order to name such collections of processes, Array Services software assigns each process to an array session handle (ASH).

An ASH is a number that is unique across the entire array (unlike a PID or PGID). An ASH is the same for every process that is part of a single array session; no matter which node the process runs in. You display and use ASH values with Array Services commands. Each time you log in to an Array node, your shell is given an ASH, which is used by all the processes you start from that shell.

The command ainfo ash returns the ASH of the current process on the local node, which is simply the ASH of the ainfo command itself.

homegrown 178% ainfo ash 
Array session handle of process 10068: 0x1111ffff000002c1
homegrown 179% ainfo ash 
Array session handle of process 10069: 0x1111ffff000002c1

In the preceding example, each instance of the ainfo command was a new process: first PID 10068, then PID 10069. However, the ASH is the same in both cases. This illustrates a very important rule: every process inherits its parent's ASH. In this case, each instance of array was forked by the command shell, and the ASH value shown is that of the shell, inherited by the child process.

You can create a new global ASH with the command ainfo newash, as follows:

homegrown 175% ainfo newash 
Allocating new global ASH
0x11110000308b2f7c

This feature has little use at present. There is no existing command that can change its ASH, so you cannot assign the new ASH to another command. It is possible to write a program that takes an ASH from a command-line option and uses the Array Services function setash() to change to that ASH (however such a program must be privileged). No such program is distributed with Array Services.

The command array ps returns a summary of all processes running on all nodes in an array. The display shows the ASH, the node, the PID, the associated username, the accumulated CPU time, and the command string.

To list all the processes on a particular node, use the -l and -s options. To list processes associated with a particular ASH, or a particular username, pipe the returned values through grep, as in the following example. (The display has been edited to save space.)

homegrown 182% array -l -s tokyo ps | fgrep wombat 
0x261cffff0000054c        tokyo 19007   wombat    0:00 -csh
0x261cffff0000054a        tokyo 17940   wombat    0:00 csh -c (setenv...
0x261cffff0000054c        tokyo 18941   wombat    0:00 csh -c (setenv...
0x261cffff0000054a        tokyo 17957   wombat    0:44 xem -geometry 84x42
0x261cffff0000054a        tokyo 17938   wombat    0:00 rshd
0x261cffff0000054a        tokyo 18022   wombat    0:00 /bin/csh -i
0x261cffff0000054a        tokyo 17980   wombat    0:03 /usr/gnu/lib/ema...
0x261cffff0000054c        tokyo 18928   wombat    0:00 rshd

The arshell command lets you start an arbitrary program on a single other node. The array command gives you the ability to suspend, resume, or kill all processes associated with a specified ASH.

Using arshell

The arshell command is an Array Services extension of the familiar rsh command; it executes a single system command on a specified Array node. The difference from rsh is that the remote shell executes under the same ASH as the invoking shell (this is not true of simple rsh). The following example demonstrates the difference.

homegrown 179% ainfo ash Array session handle of process 8506: 0x1111ffff00000425 homegrown 180% rsh arraysvcs@tokyo ainfo ash Array session handle of process 13113: 0x261cffff0000145e homegrown 181% arshell arraysvcs@tokyo ainfo ash Array session handle of process 13119: 0x1111ffff00000425

You can use arshell to start a collection of unrelated programs in multiple nodes under a single ASH; then you can use the commands described under “Managing Session Processes” to stop, resume, or kill them.

Both MPI and PVM use arshell to start up distributed processes.

---

Tip: The shell is a process under its own ASH. If you use the array command to stop or kill all processes started from a shell, you will stop or kill the shell also. In order to create a group of programs under a single ASH that can be killed safely, proceed as follows: Within the new shell, start one or more programs using arshell. Exit the nested shell. Now you are back to the original shell. You know the ASH of all programs started from the nested shell. You can safely kill all jobs that have that ASH because the current shell is not affected.

---

#
# Local commands
#
command spin                    # Do nothing on multiple machines
        invoke /usr/lib/array/spin
        user    %USER
        group   %GROUP
        options nowait

#!/bin/sh
# Go into a tight loop
#
interrupted() {
        echo "spin has been interrupted - goodbye"
        exit 0
}
trap interrupted 1 2
while [ ! -f /tmp/spin.stop ]; do
        sleep 5
done
echo "spin has been stopped - goodbye"
exit 1

homegrown 175% ainfo ash
Array session handle of process 8912: 0x1111ffff0000032d
homegrown 175% ainfo ash
Array session handle of process 8941: 0x11110000308b2fa6

homegrown 176% array spin

homegrown 177% exit
homegrown 178% homegrown 177% 
homegrown 177% ainfo ash
Array session handle of process 9257: 0x1111ffff0000032d
homegrown 179% array ps | fgrep 0x11110000308b2fa6
0x11110000308b2fa6  homegrown  9033   arraysvcs   0:00 /bin/sh /usr/lib/array/spin
0x11110000308b2fa6  homegrown  9618  arraysvcs  0:00 sleep 5
0x11110000308b2fa6        tokyo 26021  arraysvcs   0:00 /bin/sh /usr/lib/array/spin
0x11110000308b2fa6      tokyo 26072  arraysvcs  0:00 sleep 5
0x1111ffff0000032d  homegrown  9642  arraysvcs  0:00 fgrep 0x11110000308b2fa6

homegrown 180% array kill 0x11110000308b2fa6
homegrown 181% array ps | fgrep 0x11110000308b2fa6
0x1111ffff0000032d  homegrown 10030  arraysvcs  0:00 fgrep 0x11110000308b2fa6

The array services daemon, arrayd(1M), runs as root. As with other system services, if it is configured carelessly it is possible for arbitrary and possibly unauthorized user to disrupt or even damage a running system.

By default, most array commands are executed using the user, group, and project ID of either the user that issued the original command, or arraysvcs. When adding new array commands to arrayd.conf, or modifying existing ones, always use the most restrictive IDs possible in order to minimize trouble if a hostile or careless user were to run that command. Avoid adding commands that run with "more powerful" IDs (such as user "root" or group "sys") than the user. If such commands are necessary, analyze them carefully to ensure that an arbitrary user would not be granted any more privileges than expected, much the same as one would analyze a setuid program.

In the default array services configuration, the arrayd daemon allows all the local requests to access arrayd but not the remote requests. In order to let the remote requests access the arrayd, the AUTHENTICATION parameter needs to be set to NONE in the /usr/lib/array/arrayd.auth file. By default it is set to NOREMOTE. When the AUTHENTICATION parameter is set to NONE, the arrayd daemon assumes that a remote user will accurately identify itself when making a request. In other words, if a request claims to be coming from user "abc", the arrayd daemon assumes that it is in fact from user "abc" and not somebody spoofing "abc". This should be adequate for systems that are behind a network firewall or otherwise protected from hostile attack, and in which all the users inside the firewall are presumed to be non-hostile. On systems, for which this is not the case (for example, those that are attached to a public network, or when individual machines otherwise cannot be trusted), the Array Services AUTHENTICATION parmeter should be set to NOREMOTE. When AUTHENTICATION is set to NONE, all requests from remote systems are authenticated using a mechanism that involves private keys that are known only to the super-users on the local and remote systems. Requests originating on systems that do not have these private keys are rejected. For more details, see the section on "Authentication Information" in the arrayd.conf(4) man page.

The arrayd daemon does not support mapping user, group or project names between two different namespaces; all members of an array are assumed to share the same namespace for users, groups, and projects. Thus, if systems "A" and "B" are members of the same array, username "abc" on system A is assumed to be the same user as username "abc" on system B. This is most significant in the case of username "root". Authentication should be used if necessary to prevent access to an array by machines using a different namespace.

The configuration files are read by the Array Services daemon when it starts. Normally it is started in each node during the system startup. (You can also run the daemon from a command line in order to check the syntax of the configuration files.)

The configuration files contain data needed by ainfo and array:

A configuration file is a readable text file. The file contains entries of the following four types, which are detailed in later topics.

Blank lines, white space, and comment lines beginning with “#” can be used freely for readability. Entries can be in any order in any of the files read by arrayd.

Besides punctuation, entries are formed with a keyword-based syntax. Keyword recognition is not case-sensitive; however keywords are shown in uppercase in this text and in the man page. The entries are primarily formed from keywords, numbers, and quoted strings, as detailed in the man page arrayd.conf(4).

The Array Services daemon, arrayd, can take one or more filenames as arguments. It reads them all, and treats them like logical continuations (in effect, it concatenates them). If no filenames are specified, it reads /usr/lib/array/arrayd.conf and /usr/lib/array/arrayd.auth. A different set of files, and any other arrayd command-line options, can be written into the file /etc/config/arrayd.options, (for SGI ProPack 4, this file is /etc/sysconfig/array) which is read by the startup script that launches arrayd at boot time.

Since configuration data can be stored in two or more files, you can combine different strategies, for example:

After you modify the configuration files, you can make arrayd reload them by killing the daemon and restarting it in each machine. The script /etc/init.d/array supports this operation:

To kill daemon, execute this command:

/etc/init.d/array stop

To kill and restart the daemon in one operation; peform the following command:

/etc/init.d/array restart

---

Note: On Linux systems, the script path name is /etc/init.d/array.

---

The Array Services daemon in any node knows only the information in the configuration files available in that node. This can be an advantage, in that you can limit the use of particular nodes; but it does require that you take pains to keep common information synchronized. (An automated way to do this is summarized under “Designing New Array Commands”.)

The man page arrayd.conf(4) details the syntax rules for forming entries in the configuration files. An important feature of this syntax is the use of several kinds of text substitution, by which variable text is substituted into entries when they are executed.

Most of the supported substitutions are used in command entries. These substitutions are performed dynamically, each time the array command invokes a subcommand. At that time, substitutions insert values that are unique to the invocation of that subcommand. For example, the value %USER inserts the user ID of the user who is invoking the array command. Such a substitution has no meaning except during execution of a command.

Substitutions in other configuration entries are performed only once, at the time the configuration file is read by arrayd. Only environment variable substitution makes sense in these entries. The environment variable values that are substituted are the values inherited by arrayd from the script that invokes it, which is /etc/init.d/array.

The configuration files contain many sections and options (detailed in the section that follow this one). The Array Services command ascheck performs a basic sanity check of all configuration files in the array.

After making a change, you can test an individual configuration file for correct syntax by executing arrayd as a command with the -c and -f options. For example, suppose you have just added a new command definition to /usr/lib/array/arrayd.local. You can check its syntax with the following command:

arrayd -c -f /usr/lib/array/arrayd.local

When testing new commands for correct operation, you need to see the warning and error messages produced by arrayd and processes that it may spawn. The stderr messages from a daemon are not normally visible. You can make them visible by the following procedure:

During steps 1, 2, and 4, the test node may fail to respond to ainfo and array commands, so users should be warned that the Array is in test mode.

A simple example of an ARRAY definition is a follows:

array simple
        machine congo
        machine niger
        machine nile

The arrayname simple is the value the user must specify in the -a option (see “Summary of Common Command Options”). One arrayname should be specified in a DESTINATION ARRAY local option as the default array (reported by ainfo dflt). Local options are listed under “Configuring Local Options”.

It is recommended that you have at least one array called me that just contains the localhost. The default arrayd.conf file has the me array defined as the default destination array.

The MACHINE subentries of ARRAY define the node names that the user can specify with the -s option. These names are also reported by the command ainfo machines.

The simple MACHINE subentries shown in the example are based on the assumption that the hostname is the same as the machine's name to Domain Name Services (DNS). If a machine's IP address cannot be obtained from the given hostname, you must provide a HOSTNAME subentry to specify either a completely qualified domain name or an IP address, as follows:

array simple
        machine congo
            hostname congo.engr.hitech.com
            port 8820
        machine niger
            hostname niger.engr.hitech.com
        machine nile
            hostname "198.206.32.85"

The preceding example also shows how the PORT subentry can be used to specify that arrayd in a particular machine uses a different socket number than the default 5434.

Under both ARRAY and MACHINE you can insert attributes, which are named string values. These attributes are not used by Array Services, but they are displayed by ainfo .Some examples of attributes would be as follows:

array simple
       array_attribute config_date="04/03/96"
       machine a_node
       machine_attribute aka="congo"
       hostname congo.engr.hitech.com

---

Tip: You can write code that fetches any arrayname, machine name, or attribute string from any node in the array.

---

When a user invokes the array command, the subcommand and its arguments are processed by the destination node specified by -s. Unless the -l option was given, that daemon also distributes the subcommand and its arguments to all other array nodes that it knows about (the destination node might be configured with only a subset of nodes). At each node, arrayd searches the configuration database for a COMMAND entry with the same name as the array subcommand.

In the following example, the subcommand uptime is processed by arrayd in node tokyo:

array -s tokyo uptime

When arrayd finds the subcommand valid, it distributes it to every node that is configured in the default array at node tokyo.

The COMMAND entry for uptime is distributed in this form (you can read it in the file /usr/lib/array/arrayd.conf ).

command uptime          # Display uptime/load of all nodes in array
        invoke /usr/lib/array/auptime %LOCAL

The INVOKE subentry tells arrayd how to execute this command. In this case, it executes a shell script /usr/lib/array/auptime , passing it one argument, the name of the local node. This command is executed at every node, with %LOCAL replaced by that node's name.

Look at the basic set of commands distributed with Array Services (/usr/lib/array/arrayd.conf ). Each COMMAND entry is defined using the subentries shown in Table 3-7. (These are described in great detail in the man page arrayd.conf(4).)

The system commands called by INVOKE and MERGE must be specified as full pathnames, because arrayd has no defined execution path. As with a shell script, these system commands are often composed from a few literal values and many substitution strings. The substitutions that are supported (which are documented in detail in the arrayd.conf(4) man page) are summarized in Table 3-8.

The OPTIONS subentry permits a number of important modifications of the command execution; these are summarized in Table 3-9.

The LOCAL entry specifies options to arrayd itself. The most important options are summarized in Table 3-10.

If you do not supply LOCAL USER, GROUP, and PROJECT values, the default values for USER and GROUP are “arraysvcs.”

The HOSTNAME entry is needed whenever the hostname command does not return a node name as specified in the ARRAY MACHINE entry. In order to supply a LOCAL HOSTNAME entry unique to each node, each node needs an individualized copy of at least one configuration file.

A basic set of commands is distributed in the file /usr/lib/array/arrayd.conf.template . You should examine this file carefully before defining commands of your own. You can define new commands which then become available to the users of the Array system.

Typically, a new command will be defined with an INVOKE subentry that names a script written in sh, csh, or Perl syntax. You use the substitution values to set up arguments to the script. You use the USER, GROUP, PROJECT, and OPTIONS subentries to establish the execution conditions of the script. For one example of a command definition using a simple script, see “About the Distributed Example”.

Within the invoked script, you can write any amount of logic to verify and validate the arguments and to execute any sequence of commands. For an example of a script in Perl, see /usr/lib/array/aps, which is invoked by the array ps command.

---

Note: Perl is a particularly interesting choice for array commands, since Perl has native support for socket I/O. In principle at least, you could build a distributed application in Perl in which multiple instances are launched by array and coordinate and exchange data using sockets. Performance would not rival the highly tuned MPI and PVM libraries, but development would be simpler.

---

The administrator has need for distributed applications as well, since the configuration files are distributed over the Array. Here is an example of a distributed command to reinitialize the Array Services database on all nodes at once. The script to be executed at each node, called /usr/lib/array/arrayd-reinit would read as follows:

#!/bin/sh
# Script to reinitialize arrayd with a new configuration file
# Usage:  arrayd-reinit <hostname:new-config-file>
sleep 10      # Let old arrayd finish distributing
rcp $1 /usr/lib/array/
/etc/init.d/array restart
exit 0

The script uses rcp to copy a specified file (presumably a configuration file such as arrayd.conf) into /usr/lib/array (this will fail if %USER is not privileged). Then the script restarts arrayd (see /etc/init.d/array) to reread configuration files.

The command definition would be as follows:

command reinit
   invoke /usr/lib/array/arrayd-reinit %ORIGIN:%1
   user   %USER
   group  %GROUP
   options nowait   # Exit before restart occurs!

The INVOKE subentry calls the restart script shown above. The NOWAIT option prevents the daemon's waiting for the script to finish, since the script will kill the daemon.

This section describes the differences between standard Array Services (arraysvcs) and Secure Array Services (sarraysvcs). Secure Array Services is built with OpenSSL version 0.9.7. It uses Secure Sockets Layer (SSL) to communicate between arrayd daemons.

---

Note: It is possible to relink the Secure Array Services (SAS) library /usr/lib/libarray.a with another version of OpenSSL to generate a new /usr/lib/libarray.so library. Since the resulting library is not tested by SGI, only limited support is provided for this kind of re-configuration. See /usr/lib/array/README.libarray for further instructions.

---

You need to make sure to properly protect access to various certificate files since they contain private information and keys for accessing the software.

A summary of the differences between standard Array Services and Secure Array Services is, as follows:

Certificates are used for authentication and for negotiating encryption of subsequent traffic between the sarrayd daemons in an array. The current implementation require the server and client certificates to be present. Upon starting, the /etc/init.d/sarray script attempts to create the required certificates using the makecert script. Certificates are not over-written. The default certificate, upon installation, allows a host to run stand-alone.

---

Note: The first invocation of the sarray services may take from five to ten minutes because it has to generate the Diffie-Hellman keys required for proper certificate exchange.

---

If it is required to run Array Services in a cluster, you need to sign SAS root certificate common to the entire cluster (see the gencert command information that follows later in this section). The SAS root certificate can be self-signed (default) or signed with any valid certificate obtained from an external source.

The layout of certificate files is, as follows:

There are two certificate utilities available. They both use /usr/bin/openssl command-line utilities. They reside in the /usr/lib/array directory and can only be executed by root. Descriptions of these certificate utilities are, as follows:

Currently, there are two parameters for Secure Array Services in the arrayd.conf file, as follows:

Secure Array Services requires that some version of Secure Shell (SSH) has been installed and is running. Secure Array Services has been tested with OpenSSH versions 3.6 and 4.1, but it should work with any version of SSH. The only known requirement for the current version of Secure Array Services is that the SSH implementation installed support the following options:

Any authentication strategy supported by SSH can be used for Secure Array Services. However, having to enter passwords for every host where application processes will execute is tedious and prone to error, as a result SGI discourages the use of such an approach for authentication. Also, executions of MPI applications launched via batch schedulers cannot be authenticated interactively. A better approach to authentication via SSH is the use of key agents, such as ssh-agent, or an unencrypted key. For additional information about these approaches we recommend you consult SSH, The Secure Shell: The Definitive Guide from O'Reilly publishing.

Since there is no standard defined location for the ssh client command, the full path for the desired client can be specified using the ARRAY_SSH_PATH environment variable. If this environment variable is undefined it is assumed that the client command is named ssh and resides in the defined PATH of the user.

SSH allows users to authenticate using multiple identities. Support for this is provided in Secure Array Services via the ARRAY_SSH_IDENT environment variable. If this environment variable is set the value will be used as the identity for authentication when the ssh client is authenticating on the remote system. The use of identities is particularly useful when different authentication methods depending upon if the user is trying to authenticate for an interactive session or a batch session. If this variable is undefined, the default identity of the user is used.