The File Transfer Agent (FTA) can be used to transfer files to and from any node in the Network Queuing Environment (NQE) in either immediate (interactive) or queued mode. It also provides network peer-to-peer authorization (NPPA) of users, which is a more secure method than ftp(1) provides.
This chapter provides the following information about managing FTA:
FTA overview
Configuration
Administration
The FTA facility consists of the three components shown in Table 13-1.
Table 13-1. File Transfer Components
Component | Program | Location of description |
|---|---|---|
User interface | ftua(1) and rft(1) | |
Common services | fta(8) | |
File transfer services | ftad(8) and nqsfts(8) |
and |
The three-tier stack of file transfer components consists of the file transfer user interface, the common services, and the file transfer services (FTS).
The ftua(1) and rft(1) commands use FTA to transfer files. A file transfer request is an object that contains information describing the file transfer operations that FTA will perform on behalf of a user.
The fta command performs the actions required for reliable file transfer between hosts. These functions include transfer retry, status, and recovery. File transfer management options are also provided.
Using fta, the file transfer user commands are given a common interface to the file transfer services that operate on various networks. A domain name selects the file transfer services for a given host name.
The ftua(1) and rft(1) commands are the user interfaces to FTA services. They transfer files to and from a remote host by using the file transfer services supported by the underlying file transfer agent. FTA supports file transfer services that use TCP/IP protocols. In fact, ftua operates like the TCP/IP ftp(1b) file transfer program. The ftua utility supports autologin through the use of the .netrc file to allow access to accounts without specifying a password.
 | Note: The ftua autologin feature is prohibited on UNICOS and UNICOS/mk systems when the multilevel security feature is enabled. |
See the NQE User's Guide, publication SG-2148, for an overview of the user interface commands. The ftua(1) and rft(1) man pages contain complete reference information.
The fta(8) program provides the following FTA common services, which are common to any protocol used to transfer files:
Creation of the file transfer requests
Management of file transfer requests
Invocation of the file transfer services
Display of status information
Management of security keys for NPPA
Status about file transfers
File transfer requests are created when user agents invoke fta with the -service option.
Management functions must be invoked specifically. The primary management function is transfer recovery, which restarts transfers that failed or were interrupted.
To examine the status of requests, use the -queue option. You will get more complete output by also including the -verbose option.
| Note: For UNICOS and UNICOS/mk systems running the multilevel security
feature, in order for fta to operate correctly, you must
install fta with a specific security environment. This
can be done by using the spset command as follows to ensure
that the fqueue directory is wildcarded (see the spset(1) man page for additional information); the NQE_FTA_QUEUE variable
is set in the nqeinfo file:
|
The fta(8) man page contains complete reference information.
The file transfer service establishes the connection to the remote system. If the file transfer service being used is anything other than ftp, the invocation of the service results in an additional process. When the file transfer service completes, FTA updates the status of the request file and exits.
The FTS operation proceeds as follows:
Establishes a network connection to the remote host
Passes user validation information to the remote host
Performs file transfer operations
Closes the network connection
The file transfer service for the TCP/IP protocol FTP is integrated into the fta program. See the fta(8) man page for further details.
The nqsfts(8) program provides the file transfer service for exclusive use by NQS. This service supports only the NPK_MVOUTFILE subset of the NQS protocol. NQS can use this service through fta(8) to transfer job output files between NQS systems. This service supports the NQS hosts by using the TCP/IP network. See the nqsfts(8) man page for further details.
Figure 13-1 shows the relationships among the FTA components.
FTA configuration information is stored in the Network Load Balancer (NLB) during NQE startup. This FTA configuration applies to all hosts in the NQE except UNICOS systems that run only the NQE subset. For information about configuring FTA for UNICOS systems that run only the NQE subset, see “FTA Configuration for UNICOS Systems That Run Only the NQE Subset”.
The NPPA S-keys must be configured on each separate system. For information about configuring S-keys, see “Configuring S-keys”.
FTA configuration information is contained in the NLB database. Two FTA object types exist in the NLB database: FTA_CONFIG and FTA_DOMAIN.
| Note: If you change or add a port, you must edit system files on each system, as described in “Editing System Configuration Files”, in order for the FTA daemon (ftad(8)) to be invoked when a transfer request is received. |
FTA administration must take place on each system, even if the systems are reading the same configuration from the NLB. For more information about FTA administration, see “Administration”.
This section explains how to view and change the FTA configuration.
FTA configuration is contained in the NLB. The FTA configuration is contained in the NLB as objects of the following two attribute types:
Also, the queue parameter is defined in the nqeinfo file (see “Global FTA Configuration Parameters”).
FTA configuration may be viewed by using the nlbconfig command.
| Note: For UNICOS systems that run only the NQE subset (NQS and FTA components), see “FTA Configuration for UNICOS Systems That Run Only the NQE Subset”, for information about configuring FTA. |
If you issue the nlbconfig -odump -t FTA_CONFIG -n DEFAULT command, the output is as follows:
%nlbconfig -odump -t FTA_CONFIG -n DEFAULT
###############################################
# creation date: Mon Nov 13 16:45:09 1995
# created by: luigi
# object timestamp: Tue oct 10 15:16:15 1995
########
object FTA_CONFIG ("DEFAULT") {
FTA_MODE = 384;
FTA_RESTART_LIMIT = 30;
FTA_ADMIN_USER = "root";
FTA_ADMIN_GROUP = "bin";
|
| Note:: FTA_MODE is represented in the NLB database as a decimal number (384). |
The nlbconfig FTA_CONFIG object type, displayed with the command nlbconfig -odump -t FTA_CONFIG, is defined as follows:
| Parameter | |||
Description | |||
| queue "path" | |||
Defines the directory that holds transfer request control files while they are present in the queue. This parameter is always required. You can change this parameter in the nqeinfo configuration file.
| |||
| FTA_RESTART_LIMIT=limit | |||
Defines the maximum number of FTS processes (limit) that will be started during transfer recovery. This figure is independent of any domain-specific limit. If limit is none or unspecified, limits are not applied. | |||
| FTA_MODE=file-mode | |||
Defines the file permission mode of the files in the queue directory. The default permission mode is 0600. Octal values must have a leading 0. | |||
| FTA_ADMIN_USER "username"| FTA_ADMIN_GROUP "groupname" [,...] | |||
Defines the users, groups, or a combination of the two that can perform FTA management functions on behalf of other users. Without this parameter, only the super user has this privilege. | |||
| FTA_STATUS_USER "username"| FTA_STATUS_GROUP "groupname" [,...] | |||
Defines the users, groups, or a combination of the two that can perform FTA status functions on behalf of other users. Without this parameter, only the super user has this privilege. | |||
| Note: For UNICOS systems that run only the NQE subset (NQS and FTA components), to configure FTA, see “FTA Configuration for UNICOS Systems That Run Only the NQE Subset”. |
If you issue the nlbconfig -odump -t FTA_DOMAIN -n inet command, the output is as follows:
%nlbconfig -odump t FTA_DOMAIN -n inet
###############################################
# creation date: Wed Nov 15 12:45:39 1995
# created by: luigi
# object timestamp: Fri Nov 13 09:34:31 1995
########
object FTA_DOMAIN ("inet") {
FTA_PORT = 605;
FTA_RESTART_LIMIT = 30;
FTA_FTS = "ftp";
FTA_FLAGS = "nopassword"; |
The nlbconfig FTA_DOMAIN object type, displayed with the command nlbconfig -odump -t FTA_DOMAIN is defined as follows:
| Parameter | |
Description | |
| FTA_FTS=class | |
Defines the file transfer service class to be associated with a domain. The valid class identifiers are described below. The validity of other domain configuration parameters depends on the FTA_FTS class used. This parameter is required. See Table 13-2 for a list of classes that may be used. | |
| FTA_RESTART_LIMIT=limit | |
Defines the maximum number of FTS processes (limit) that will be started for a domain during transfer recovery. | |
| FTA_GATEWAY="hostname" | |
Defines the name of a gateway host. | |
| FTA_PORT=number | |
Defines the port number to connect to on the remote system. The default is 605 on NQE systems. By default, the ftad daemon listens on port 605; the ftpd demon listens on port 21. | |
| FTA_PATH="fts_path" | |
Defines the path of the FTS process to be invoked. | |
| FTA_FLAGS=flag [,flag]... | |
Defines the flags to be used with the domain. An exclamation point (!) can precede a flag to explicitly declare a flag to be off. See Table 13-3 for a list of flags that can be used with this parameter. | |
The class associated with the FTA_FTS parameter can be any of the following, as shown in Table 13-2:
Table 13-2. FTA_FTS Class Parameters
Class | Description | |
|---|---|---|
common | Defines a domain in which the FTS uses a standard FTS interface module. The path of the FTS program is required. | |
dap | Defines a domain for a remote DECnet (DAP) gateway, which is controlled by using the built-in FTP FTS program. The hostname associated with the FTA_GATEWAY parameter must be running an FTP/DAP gateway. A gateway TCP/IP hostname name is required and defined using the FTA_GATEWAY parameter. | |
ftp | Defines an Internet FTP domain. The ftp FTS program is built into fta. An additional path parameter is not required. | |
The flags associated with the FTA_FLAGS parameter can be any of the following, as shown in Table 13-3:
Table 13-3. FTA_FLAGS Parameters
Flag | Description | |
cancel | Specifies that user agent cancellation will be performed using the FTS. | |
debug | Specifies that the FTS be run with debug tracing enabled. The FTS program determines the exact function of the FTS debug tracing flag. | |
nopassword | Specifies that a password need not be provided before a file transfer request is accepted; that is, the password is optional. NPPA requires this flag. | |
nopermanent | Specifies that any permanent error be treated as transient. This will enable the transfer to be recovered. | |
nostart | Specifies that a request should not be started when the user agent completes a session with the fta server; instead, a request is processed when transfer recovery is initiated. | |
notify | Specifies that user agent notification will be performed using the FTS. | |
privileged | Specifies that the FTS will be invoked as a privileged process, inheriting all privileges endowed to the fta recovery process. This usually results in the FTA process running as root (user ID 0). | |
trace | Specifies that the FTS will be run with protocol tracing enabled. The FTS program determines the exact function of the FTS protocol tracing flag. | |
You can change the default FTA configuration using the following procedure:
List the FTA objects in the NLB database with the following commands:
# nlbconfig -olist -t FTA_CONFIG ------ type: FTA_CONFIG count: 1 ------ DEFAULT # nlbconfig -olist -t FTA_DOMAIN ------ type: FTA_DOMAIN count: 4 ------ inet ftp nqe nqs-rqs
The output indicates that there is one FTA configuration object named DEFAULT. There are four FTA domain objects named inet, ftp, nqe, and nqs-rqs. When the count is more than one, specify a specific name with the nlbconfig -t type -n name command.
To display all the attributes of the object type FTA_CONFIG with the name DEFAULT, issue the following command:
nlbconfig -odump -t FTA_CONFIG -n DEFAULT
You will receive output similar to the following:
############################################### # creation date: Mon Dec 25 16:45:09 1995 # created by: luigi # object timestamp: Fri Oct 13 15:16:15 1995 ######## object FTA_CONFIG ("DEFAULT") { FTA_MODE = 384; FTA_RESTART_LIMIT = 30; FTA_ADMIN_USER = "root"; FTA_ADMIN_GROUP = "bin";You can either completely replace this information with new information, or update it to change a part of it. Note that the FTA_MODE is represented in the NLB database as a decimal number (384).
To change the information, create a file (called, for example, odat.1) that contains the attribute(s) you want to change or add, as in the following example:
object FTA_CONFIG ("DEFAULT") { FTA_ADMIN_USER = "root, luigi"; }
Update the object file by using the nlbconfig -oupdat -f odat.1 command. All of the existing information is retained, and the FTA_ADMIN_USER attribute is modified.
To completely replace the information in the object file, dump the information in the object file into working file (called, for example, odat.2) by using the following command:
nlbconfig -odump -f odat.2
Edit this file to contain the information you want and replace the entire object file with the following command:
nlbconfig -oput -f odat.2
For UNICOS systems that run only the NQE subset (NQS and FTA components), FTA configuration is not maintained in the NLB. Instead, UNICOS FTA configuration is maintained in the FTA configuration file /nqebase/etc/fta.conf. To view fta configuration for UNICOS systems, use the fta -config command. For additional information, see the fta.conf(5) man page.
| Note: If you change or add a port, you must edit system files on each system, as described in “Editing System Configuration Files”, in order for the FTA daemon (ftad(8)) to be invoked when a transfer request is received. |
You must add the entry NQE_FTA_FTACONF=/nqebase/etc/fta.conf to the nqeinfo file (either by using the nqeconfig(8) utility or by manually adding the entry to the end of the file). To initially generate the fta.conf file and FTA queue directory, use the configure.fta script in the /nqebase/examples directory. This script will use values that are in the nqeinfo file to create the proper FTA configuration.
If you issue the fta -config command, the output is as follows. The section of the output that begins with FTA corresponds to the FTA_CONFIG NLB object. The section of the output that begins with FTS corresponds to the FTA_DOMAIN NLB object. NQE_FTA_QUEUE is set in the nqeinfo file.
% fta -config FTA queue="NQE_FTA_QUEUE" mode=0600 admin_users="root" admin_groups="bin" restartlimit=30 FTS domain="inet" fts=ftp restartlimit=30 port=605 flags="nopassword" |
Table 13-4 describes how the fta -config output corresponds to the output from the nlbconfig commands.
Table 13-4. fta -config Output and nlbconfig Output Comparison
fta -config output | nlbconfig output | |
|---|---|---|
mode | FTA_MODE | |
admin_users | FTA_ADMIN_USER | |
admin_groups | FTA_ADMIN_GROUP | |
restartlimit | FTA_RESTART_LIMIT | |
domain | FTA_DOMAIN | |
fts | FTA_FTS | |
port | FTA_PORT | |
flags | FTA_FLAGS | |
| Note:: nlbconfig represents FTA_MODE as a decimal number, rather than the octal number that is displayed when you use the fta -config command. |
If you are running a TCP/IP transport service from another vendor (that is, one other than the remote system TCP/IP), and the ftp daemon is already configured on port 21, you must add the ftpd service to an unused port number that is greater than 256 and less than 1024.
To add the ftpd service to an unused port number, you must ensure that this matches the ftp/fta port number on the local system.
FTA itself is configured during the installation of NQE. However, if you change or add a port, you must edit the following system files on each machine in order for inetd to invoke ftad when a transfer request is received:
/etc/services /etc/inetd.conf |
Optionally, you might edit /etc/syslogd.conf.
Add the following line to /etc/services:
fta unused_port_number/tcp |
Add the following lines to /etc/inetd.conf:
#<service_name> <socket_type> <proto> <flags> <user> <server_pathname> <args> <options> # # FTAD daemon # fta stream tcp nowait root /nqebase/bin/ftad ftad options |
You can add the -d option to the end of the last line. The -d option allows the server to log messages to syslogd.
If this option is required, ensure that the following line is included in syslog.conf (it may already be included if other daemons are already sending messages to syslogd):
*.debug /var/adm/messages |
The inetd utility rereads its configuration file once when it is started and again whenever it receives the hangup signal (SIGHUP). New services can be activated and existing services can be deleted or modified by editing the configuration file, then sending inetd a SIGHUP signal.
| Note:: On AIX systems, if you manually edit the inetd.conf file, you must synchronize the inetd.conf file and the object data manager (ODM) database by using the inetimp command. |
For additional information about setting port numbers, see the NQE Installation, publication SG-5236.
You can authorize users to transfer files without exposing passwords across the network. This is especially desirable for NQS users who might otherwise have to make their FTA passwords visible in the NQS job file script. Network peer-to-peer authorization (NPPA) is a method of enabling users to open a connection to a remote system without sending a password across the network.
| Note: NPPA is enabled by default on all platforms except UNICOS and UNICOS/mk systems. To enable NPPA on UNICOS and UNICOS/mk systems, use the ftad -N command in /etc/inetd.conf. |
NPPA requires the use of ftua or rft on the local system and ftad on the remote system. Both systems must have support for the NPPA process. NPPA only works if you have a flat user name space; that is the user name of an FTA user must be the same on both systems.
The FTA domains inet and nqe are set up to use NPPA by default. You do not have to make changes to the FTA domain configuration to use NPPA in these domains. If you want to use a different name for NPPA connections, you can add another domain. This procedure is described in “Modifying the NLB Database for NPPA”.
Each system that is going to use NPPA must be configured with the authentication information that it will send to another system during session setup, and with the authentication information that it will expect to receive from other NPPA systems. This authentication information consists of an S-key (security key) and a password, both of which are alphanumeric strings. The first S-key and password pair defined on each system is designated as the primary S-key and password pair for that system.
When a user starts ftua or rft and uses a domain configured for NPPA, the system encrypts its primary S-key and password pair and sends it to the system with which it is attempting to establish a connection. The remote system performs a similar encryption for each S-key and password pair on its list of expected authorization information and accepts the connection when it finds a match.
| Note: If multiple ftads are configured on different ports, they will all use the NPPA configuration file (fta.nppa) pointed to by the NQE_FTA_NPPAPATH variable that is set in the nqeinfo file. |
To configure network peer-to-peer authorization, the administrator must establish the primary S-key and password pair for each system. These S-key and password pairs can be the same for all systems, or they may differ.
The first S-key set up on each system becomes the primary S-key, which is sent to remote systems during connection establishment. After defining the primary S-key on a system, the administrator adds all the S-key and password pairs for all the hosts that will be authorized to open NPPA connections to that system.
To configure network peer-to-peer authorization, you must assign S-key and password pairs on all of the systems that will use NPPA.
To create and delete S-keys, you must be root.
| Note: On UNICOS systems that run only the NQE subset, use the fta(8) command to configure S-keys. |
To assign S-keys, use the skey -addkey keylabel command, as follows:
# skey -addkey key1 Enter key password Verification |
Alternatively, if FTA is running on the system, you can also use the fta -addkey command. The effect of the two commands is identical.
To display the keys on the system, use the -showkey option, as follows:
# skey -showkey Keys on this system 1) key1 - Primary Key |
To delete S-keys, use the skey -delkey keylabel command.
| Note:: For UNICOS systems running NQE 2.0 or earlier in your network, you cannot use ftua to connect to a UNICOS platform (whether it is a Cray Research system-to-Cray Research system or a workstation-to-Cray Research system) because UNICOS systems running the earlier versions of NQE do not support ftad. NQE version 3.0 running on UNICOS does support ftad. |
This example is based on having three systems that you want to communicate by using FTA. The systems are called host1, host2, and host3. They have the following characteristics:
Table 13-5. Example of NPPA Configuration Characteristics
System | FTS | Port FTS listens on | Port provided for domain nppa | S-keys |
|---|---|---|---|---|
host1 | ftp | 21 (ftpd) | 605 | key2 |
host2 | ftp | 605 (ftad) | 605 | key1 |
host3 | ftp | 605 (ftad) | 605 | key1, key2 |
Figure 13-2 shows this configuration.
In this configuration, you want users to be able to use cqsub to submit NQS batch requests from host3 to host1 and to have FTA return the output. FTA on host1 will construct an authentication packet that includes the S-key key2 as one of its components. host1 transmits its authentication packet to host3. On host3, two authentication packets are generated, one that uses the S-key key2 and one that uses the S-key key1. Both of the packets generated on host3 are checked against the packet received from host1. The packet that uses the S-key key2 matches, and the authentication succeeds.
If users initiate an FTA session from host3 to host1 that uses the domain nppa, the session will fail because no FTA daemon is listening on port 605 on the host1 system.
If users initiate an FTA session from host3 to host1 without specifying a domain, a connection to the ftp daemon port (usually 21) can be made successfully. This session will not use NPPA because the ftp daemon does not support NPPA.
Users can use cqsub to submit an NQS batch request from host3 to host2 and have FTA return the output. FTA on host2 constructs an authentication packet that includes the S-key key1 as a component. host2 transmits this packet to host3. On host3, two authentication packets are generated, and the one that uses the S-key key1 matches, and authentication succeeds.
If users initiate an FTA session from host3 to host2 that uses the domain nppa, the session will succeed because the FTA daemon is listening on the same port number (605) on host2.
If you want to create a new FTA domain for users to specify when they use NPPA, you must add that FTA domain to the NLB database. You must have ACL write privileges to change the NLB database. The domain must have the following attributes; you can add others if you want:
| Attribute | Description |
| FTA_FTS = ftp | File transfer class used by the remote system; ftp is an example. |
| FTA_PORT = nnn | TCP/IP ftad port number on the remote system on which the fta daemon is listening; “Example of Modifying the NLB Database” contains an example. |
| FTA_FLAGS = nopassword | Flag (nopassword) that informs FTA that NPPA can be used for this domain. |
For a complete listing of possible attributes and values, see “Viewing the FTA Configuration”.
To add an NPPA domain to the NLB database, create a file (called, for example, nppa.odat) such as the following, which adds the domain nppa on the local system, with the ftad daemon listening on port number 258:
object FTA_DOMAIN ( "nppa" ) {
FTA_FTS = "ftp";
FTA_PORT = 258;
FTA_FLAGS = "nopassword";
} |
To update NLB object file and add the new domain object to the NLB database, use the following command:
nlbconfig -oupdat -f nppa.odat |
For more details on how to modify the NLB database, see “Changing the FTA Configuration”.
FTA startup, logging, and recovery functions are not entirely contained within the bounds of the fta(8) program. This section explains some of the interactions that occur between the FTA facility and other parts of the operating system. The actions described in this section are done (or a default value is provided) during installation. If you want to make changes, you can use these procedures.
| Note:: FTA administration must take place on each system, even if the systems are reading the same configuration from the NLB. |
At system boot time, you can restart any FTA file transfers that stopped when the system shut down by running a recovery process.
| Note:: Do not start a recovery process before TCP/IP is brought up. |
The system startup recovery process is started as follows:
fta -recover |
The following sections describe FTA recovery.
Binary transfers can be recovered at the byte level. System administrators enable or disable this recovery level by setting the NQE_FTA_SMART_RESTART environment variable to be ON or OFF. The NQE_FTA_SMART_RESTART environment variable may be set in the nqeinfo file or through the shell. The default value is ON.
| Note:: The configuration variable is ignored if the operation is not taking place in binary mode; restarting will be disabled. |
The FTA_DBY NLB attribute of the FTA_ACTION object appears only after the transfer has begun; it remains even if the transfer is interrupted.
FTA does not have a daemon recovery service; that is, the recovery of a queued request is not automatically provided. Therefore, it is recommended that you start a recovery process either at regular intervals or at specific times of the day or week.
If you use the clock daemon, cron(8), to start FTA recovery for all users, you must use the super-user crontab file. The following example of a crontab entry starts an FTA recovery process every 15 minutes, each day of the week. Refer to crontab(1) for syntax information.
0,15,30,45 * * * * fta -recover |
It also is useful to run a recovery process at significant times, such as the following:
Nightly, to clean up any failures.
After network failure is resolved. Use -domain as a selector to direct the recovery for a specific domain or network.
After a remote host is rebooted. Use -host to recover requests that transfer to or from that specific host.
To recover queued requests for all users of the system, run the fta -recover process, using the root user ID or the ID of an FTA administrator.
The following example runs the recovery process on the specific file transfer request entry aa003yy; -debug is used to monitor the process:
% fta -debug -recover -entry aa003yy fta: debug: getuid=11431, geteuid=11431 fta: debug: Reading config file... fta: debug: ftsconf: class=1, domain=solaris, gateway=None, path=None, port=510 fta: debug: ftsconf: class=1, domain=osf, gateway=None, path=None, port=535 fta: debug: ftsconf: class=6, domain=nppa_ice, gateway=ice, path=None, port=256 fta: debug: ftsconf: class=1, domain=inet, gateway=None, path=None, port=0 fta: debug: User is an administrator fta: debug: User can see status fta: debug: queue: reading dir NQE_FTA_QUEUE fta: debug: entry aa006bk rejected (name mismatch) fta: debug: queue: opening file qfaa003yy fta: debug: entry aa003yy selected fta: debug: entry aa001bb rejected (name mismatch) fta: debug: entry aa004WE rejected (name mismatch) fta: debug: entry aa004YM rejected (name mismatch) fta: debug: entry aa004dw rejected (name mismatch) fta: debug: entry aa004fJ rejected (name mismatch) fta: debug: entry aa0053J rejected (name mismatch) fta: debug: entry aa0059I rejected (name mismatch) fta: debug: entry aa005Q0 rejected (name mismatch) fta: log: aa003yy: starting recovery. fta: debug: setUserId: uid=11431, euid=11431 fta: debug: ftp_open: connecting to yankee... fta: debug: ftp_connect: connection up fta: debug: waiting for initial 220 msg... fta: debug: got initial 220 msg fta: debug: doing request fta: debug: operation Copy (get) fta: debug: copyio: called fta: debug: copyio: 2879 bytes transferred fta: debug: operation completed (status = 20200) fta: debug: pullstatus: status = 20200 fta: debug: updating/removing request entry fta: debug: request succeeded (ES_NONE) fta: log: aa003yy: completed successfully. fta: debug: rmEntry: aa003yy: request removed |
The following problems might prevent file transfers from occurring when FTA is used:
A network route is down.
A remote system is down.
User validation information is not valid.
A file transfer operation is not valid.
These errors are categorized as either transient or permanent.
| Type of error | Resulting action | |
| Transient | FTA retains the request file in the request queue directory. Status information showing the reason for the failure is included in the request. | |
| Permanent | FTA notifies the user or user agent (ftua or rft) with a message containing information that describes the error, and the transfer request is removed from the request queue directory. |
When file transfer is successful, FTA removes the request file from the queue directory. You can use the ftua notify command to notify the user of successful completion.
A queued request that fails with a transient error can be rerun by invoking a recovery process. Recovery proceeds with the following steps:
Scan the queue for entries.
Invoke FTA and FTS processes for each request to be recovered.
Update the status of the request queue.
If you are root or an FTA administrator, you can start a recovery process by executing the following command:
fta -recover |
If many file transfer requests are queued, recovery can create many processes. This can create a heavy load on the system. To reduce the load, you can limit the number of requests that are recovered at any one time. The FTA_RESTART_LIMIT attribute of the FTA_CONFIG NLB object controls the number of requests that are started at any one time. The number of requests recovered at any one time, regardless of domain, is controlled by this limit. The following NLB object shows a global configuration restart limit of 30:
object FTA_CONFIG ("DEFAULT") {
FTA_MODE
FTA_RESTART_LIMIT = 30; |
To control the load presented by a specific domain, assign a limit on a per-domain basis. This limit is known as a domain restart limit. “Changing the FTA Configuration”, explains how to change the FTA configuration.
The following example from the NLB object shows that the inet domain restart limit as 10:
object FTA_DOMAIN ("inet") {
FTA_FTS = "common";
FTA_RESTART_LIMIT = 10;
} |
Both the fta and domain restart limits are applied to the queue during recovery. If either limit is reached, the number of requests recovered is constrained. If a domain restart limit is set higher than the fta restart limit, the number of requests recovered for that domain is constrained by the fta restart limit.
If neither an fta nor a domain restart limit is defined, no limit is applied. It also is possible to use the keyword none in place of a number to explicitly denote that there is no limit.
When you start a recovery process, the queue of file transfer requests is sorted before any restart limits are applied. The following criteria determine the order in which requests are recovered. The order of the following list is significant; the first differentiating factor determines the order in which the requests are recovered. Selector options are applied to the queue to filter out the requests chosen by a user.
Requests that were never run are favored over those that ran before.
Requests that were run least recently are favored over those that were run most recently.
Requests that were queued least recently are favored over those that were queued most recently.
The following example shows an application of these criteria. Because requests aa00093 and aa00136 never ran, they are favored over the other requests (rule 1). Because request aa00093 is older, it is placed before aa00136 in an internal recovery list (rule 3). Requests aa00101 and aa00127 have run. Because both have the same run date, they are equally qualified under rule 2; however, aa00101 was queued before aa00127, so aa00101 is favored over aa00127 (rule 3). Recovery would occur in the following order: aa00093, aa00136, aa00101, and aa00127.
QID | Date queued | Date run |
|---|---|---|
aa00093 | Thu Nov 16 08:16:35 | Never |
aa00101 | Thu Nov 16 08:18:22 | Thu Nov 16 08:28:14 BST 1995 |
aa00127 | Thu Nov 16 08:28:12 | Thu Nov 16 08:28:14 BST 1995 |
aa00136 | Thu Nov 16 08:30:43 | Never |
If the restart limit were set to 3, which limits the number of recovered requests, only the first three requests from this sorted list (that is, aa00093, aa00136, and aa00101) would be recovered.
Suppose that after the recovery the queue state is as follows:
QID | Date queued | Date run |
|---|---|---|
aa00101 | Thu Nov 16 08:18:22 | Thu Nov 16 09:45:13 BST 1995 |
aa00127 | Thu Nov 16 08:28:12 | Thu Nov 16 08:28:14 BST 1995 |
Requests aa00093 and aa00136 completed, but request aa00101 experienced a transient error and was requeued. If a second recovery starts now, neither request qualifies under rule 1; therefore, queue ordering would be determined by rule 2, the time the requests were last run. In this example, request aa00127 would be placed before aa00101, because aa00127 ran least recently.
The NQE_FTA_NLBCOLLECT variable activates logging of transfer information to the NLB. Values may be ON or OFF. The variable may be set in the nqeinfo file or as an environment variable. The default value is ON.
FTA information is logged by the syslogd(8) daemon under the facility name daemon. Three syslogd priorities are used: notice, err, and debug. Normal FTA events are logged with the notice priority; FTA errors are logged with the err priority, and all events are logged when debug is turned on.
Other facilities also use the syslogd facility name daemon, and a corresponding syslog.conf entry might already be in use. Review the syslog.conf file for other uses of the daemon facility.
The following is a sample entry from a syslog.conf file used to direct FTA notice and error logging information to the /usr/adm/syslog/daylog system log file:
daemon.notice;daemon.err /usr/adm/syslog/daylog |
With the addition of the following line, FTA errors also are sent to an operator's terminal:
daemon.err operator |
A typical entry in a log file that is generated by fta using syslogd follows:
Sep 29 12:27:21 yankee fta[16331]: aa003z7: starting recovery Sep 29 12:27:22 yankee fta[16331]: User: js Host: yankee Request: aa003z7 Mode: Immediate Sep 29 12:27:22 yankee fta[16331]: Remote file: lgn Local file: /net/home/palm3/js/temp Size: 879 bytes Sep 29 12:27:22 yankee fta[16331]: aa003z7: completed successfully Sep 29 12:28:20 yankee fta[16335]: aa005Q0: cancelled (null operation) Sep 29 12:28:20 yankee fta[16335]: aa005Q0: failed: Cancelled by user/operator Sep 29 12:28:26 yankee sendmail[16337]: AA16337: message-id=<[email protected]> Sep 29 12:28:26 yankee sendmail[16337]: AA16337: from=js, size=563, class=0, received from local Sep 29 12:28:27 yankee sendmail[16339]: AA16337: [email protected], delay=00:00:06, stat=Sent Sep 29 12:29:18 yankee fta[16342]: aa004YM: cancel: request active |
 | Caution: When you invoke FTA recovery, you can use the -log option to route the information logged to the standard output of the fta recovery process. If this option is used from a tty, you must redirect the standard output. If no redirection or pipe is used, and the output is sent to the controlling tty, some of the log output will be lost. This behavior is a side effect caused by fta using the setjob(2) system call during the recovery process |
FTA management functions include the following:
Canceling requests
Deleting requests
Holding requests
Releasing requests
Displaying request status
The super user can perform management functions on any requests that exist in the FTA queue.
If necessary, specific users or groups of users can be authorized to use FTA management functions. In the following NLB object example, user joe and the members of the group operator are authorized to perform FTA management functions:
object FTA_CONFIG ("DEFAULT") {
FTA_MODE = 384;
FTA_RESTART_LIMIT = 30;
FTA_ADMIN_USER = "joe";
FTA_ADMIN_GROUP = "operator"; |
Specific users or groups of users also can be authorized to display the status of any requests in the FTA queue. In the following NLB object example, user joe and the members of the group staff can display the status of any request:
object FTA_CONFIG ("DEFAULT") {
FTA_MODE = 384;
FTA_RESTART_LIMIT = 30;
FTA_STATUS_USER = "joe";
FTA_STATUS_GROUP = "staff";
|
| Note:: Unless explicitly listed, users can perform management functions on, and display the status of, only their own requests. |
You can use selector options to filter sets of requests for specific status or management functions (see the fta man page). Selectors are provided to filter requests based on the following attributes:
Time the request was queued
Domain name
Host name
Request owner
Queue request identifier
Request status
If you combine different selectors, a request is selected only when it satisfies all attributes specified with the given selectors. If selectors are not specified, all requests are selected. The following example lists all requests that were queued at or before 12 P.M. and that tried to transfer but failed.
fta -before 12:00 -failed -queue |
The following examples use the -debug option to show the output from requests to cancel and delete an entry:
% fta -cancel -entry aa005Q0 -debug fta: debug: getuid=11431, geteuid=11431 fta: debug: Reading config file... fta: debug: ftsconf: class=1, domain=solaris, gateway=None, path=None, port=510 fta: debug: ftsconf: class=1, domain=osf, gateway=None, path=None, port=535 fta: debug: ftsconf: class=6, domain=nppa_ice, gateway=ice, path=None, port=256 fta: debug: ftsconf: class=1, domain=inet, gateway=None, path=None, port=0 fta: debug: User is an administrator fta: debug: User can see status fta: debug: queue: reading dir NQE_FTA_QUEUE fta: debug: entry aa006bk rejected (name mismatch) fta: debug: entry aa001bb rejected (name mismatch) fta: debug: entry aa004WE rejected (name mismatch) fta: debug: entry aa004YM rejected (name mismatch) fta: debug: entry aa004dw rejected (name mismatch) fta: debug: entry aa004fJ rejected (name mismatch) fta: debug: entry aa0053J rejected (name mismatch) fta: debug: entry aa0059I rejected (name mismatch) fta: debug: queue: opening file qfaa005Q0 fta: debug: entry aa005Q0 selected fta: log: aa005Q0: cancelled (null operation). fta: log: aa005Q0: failed: Cancelled by user/operator. fta: debug: rmEntry: aa005Q0: request removed |
% fta -delete -entry aa006bk -debug fta: debug: getuid=11431, geteuid=11431 fta: debug: Reading config file... fta: debug: ftsconf: class=1, domain=solaris, gateway=None, path=None, port=510 fta: debug: ftsconf: class=1, domain=osf, gateway=None, path=None, port=535 fta: debug: ftsconf: class=6, domain=nppa_ice, gateway=ice, path=None, port=256 fta: debug: ftsconf: class=1, domain=inet, gateway=None, path=None, port=0 fta: debug: User is an administrator fta: debug: User can see status fta: debug: queue: reading dir NQE_FTA_QUEUE fta: debug: queue: opening file qfaa006bk fta: debug: entry aa006bk selected fta: debug: entry aa001bb rejected (name mismatch) fta: debug: entry aa004WE rejected (name mismatch) fta: debug: entry aa004YM rejected (name mismatch) fta: debug: entry aa004dw rejected (name mismatch) fta: debug: entry aa004fJ rejected (name mismatch) fta: debug: entry aa0053J rejected (name mismatch) fta: debug: entry aa0059I rejected (name mismatch) fta: debug: rmEntry: aa006bk: request removed |
The following examples show the output from requests to display the status of an entry:
% fta -queue
--QID-- ---Queued On --- --User-- ---State--- -----Status-----
aa001bb Tue Sep 14 09:19 sparks Active UA connected
aa004WE Tue Sep 21 08:54 sparks Active Connecting
aa004YM Tue Sep 21 09:00 sparks Active Connected
aa004fJ Tue Sep 21 09:36 sparks Active Connecting
aa0053J Tue Sep 21 11:52 sparks Active Connecting
aa0059I Tue Sep 21 12:09 sparks Active Connecting
% fta -queue -verbose
--QID-- ---Queued On --- --User-- --Group--
aa001bb Tue Sep 14 09:19 sparks rqsgrp
State: Active
Status: UA connected
Priority: 0
Last Attempt: Tue Sep 14 10:33:22
Controlling-PID: 27788
Domain: osf
Host: alphabet
Username: sparks
Copy (get)
RemoteFile: fta30.1.tar
LocalFile: /net/home/palm3/sparks/fta.tar
aa004WE Tue Sep 21 08:54 sparks rqsgrp
State: Active
Status: Connecting
Priority: 0
Last Attempt: Never
Domain: inet
Host: alphabet |
FTA provides progress statistics about file transfer status. The total file size, bytes transferred, and estimated time to completion are tracked, and the progress statistics are stored in the NLB. Users and administrators can view this status information by using the FTA summary option of the NQE GUI Status window. You can change the interval between NLB updates by setting the NQE_FTA_STAT_INTERVAL variable, which may be set in the nqeinfo file; alternatively, you can override the configured internal value through the NQE_FTA_STAT_IN environment variable in the shell. The variable is an integer, which represents the number of seconds between NLB updates. If the NQE_FTA_STAT_INTERVAL environment variable is set to 0, progress statistics are disabled. The default value is 2.
For DFS transfers, the FTA_DFS NLB attribute of the FTA_ACTION object appears only after the transfer has begun; it remains even if the transfer is interrupted. The FTA_DFS NLB attribute is set to -1 if FTA is unable to determine the file size; this action does not prevent the transfer from continuing.