GT 3.9.5 RFT : System Administrator's Guide

Introduction

This guide contains advanced configuration information for system administrators working with RFT. It provides references to information on procedures typically performed by system administrators, including installation, configuring, deploying, and testing the installation.

This information is in addition to the basic installation instructions in the GT 3.9.5 System Administrator's Guide.

RFT is used to perform third-party transfers across GridFTP servers. It uses a database to store its state periodically so the transfers can be recovered from any failures. RFT uses standard grid security mechanisms for authorization and authentication of the users. So in order to effectively use RFT you should have installed and configured a database with RFT database schemas and have the necessary security infrastructure in place to perform a 3rd party transfer.

Building and Installing

RFT is built and installed as part of a default GT 3.9.5 installation. For basic installation instructions, see the GT 3.9.5 System Administrator's Guide. No extra installation steps are required for this component.

The following are specialized instructions for advanced developers who want to deploy latest code from CVS:

1

Configure your CVSROOT to point to globus cvs location.
2

Run:

cvs co ws-transfer
3

Run:

cd ws-transfer/reliable
4

Set GLOBUS_LOCATION to point to your globus installation.
5

Run:

ant deploy

Configuring

Configuration overview

RFT has the following prerequisites:

  • Java WS Core - this is built and installed in a default GT 3.9.5 installation.
  • a host certificate (see Required Configuration.)
  • GridFTP Server - GridFTP perfoms the actual file transfer and is built and installed in a default GT 3.9.5 installation.
  • PostgreSQL - PostgreSQL is used to store the state of the transfer to allow for restart after failures. The interface to PostgreSQL is JDBC so any DBMS that supports JDBC can be used, although no other has been tested. For instructions on configuring the PostgreSQL database for RFT, click here.

RFT can be registered to an MDS index service to facilitiate monitoring and discovery. The MDS documentation contains a note on registering RFT to an Index Service.

Syntax of the interface

The security of the service can be configured by modifying the security descriptor. It allows for configuring the credentials that will be used by the service, type of authentication and authorization that needs to be enforced. By default, the following security configuration is installed:

  • Credentials set for use by container is used. If that is not specified, default credentials are used.
  • GSI Secure conversation authentication is enforced for all methods.

Note: Changing required authentication and authorization method will require suitable changes to the clients that contact this service.

To alter security descriptor configuration, refer to Security Descriptors. The file to be altered is $GLOBUS_LOCATION/etc/globus_wsrf_rft/security-config.xml

Required configuration: configuring the PostgreSQL database

PostgreSQL (Version 7.1 or greater ) needs to be installed and configured  for RFT to work. You can either use the packages which came with your operating system (RPMs, DEBs, ...) or build from source. We used PostgreSQL version 7.3.2 for our testing and the following instructions are good for the same.

  1. Install Postgresql. Instructions on how to install/configure postgresql can be found here.
  2. Configure the postmaster daemon so that it accepts TCP connections. This can be done by adding -o "-i" switch to postmaster script.
  3. To create the database that is used for RFT, run:
    createdb rftDatabase
  4. To populate the RFT database with appropriate schemas, run:
    psql -d rftDatabase -f $GLOBUS_LOCATION/share/globus_wsrf_rft/rft_schema.sql

    Now that you have created a database to store RFT's state, the following steps configure RFT to find the database:
  5. Open $GLOBUS_LOCATION/etc/globus_wsrf_rft/jndi-config.xml
  6. Find the dbConfiguration section under ReliableFileTransferService <service> section.
  7. Change the connectionString to point to the machine on which you installed Postgres and name of the database you used in step 2.
    If you installed Postgres on the same machine as your Globus install, the default should work fine for you.
  8. Change the userName to the name of the user who owns/created the database and do the same for the password. (It also depends on how you configured your database.)
  9. Don't worry about the other parameters in that section. The defaults should work fine for now.
  10. Edit the configuration section under ReliableFileTransferService. There are two values that can be edited in this section.
    • backOff  : Time in seconds you want RFT to backoff before a failed transfer is retried by RFT. Default should work fine for now.
    • maxActiveAllowed:  This is the number of transfers the container can do at given point. Default should be fine for now.

Deploying

[information about deploying the component into various containers/environments]

Testing

You need to checkout the tests from CVS because RFT tests are not included in the installer. Please follow these steps to run RFT unit tests:

1

Run:

cvs co ws-transfer/reliable/service/test
2

Start a gridftp server on the machine you are running the tests on; use port 5678. This can be done by running: 

globus-gridftp-server -s  -p 5678 &
3 Start the container with RFT deployed in it.
4 
cd ws-transfer/reliable/service/test/unit

Edit test.properties. Put in appropriate values for all the properties.
5

Generate a report of the tests that ran in the current working directory:

ant test

Security Considerations

Permissions of service configuration files

The service configuration files such as jndi-config.xml or server-config.wsdd (located under etc/<gar>/ directory) contains private information such as database passwords and username. Ensure that these configuration files are only readable by the user that is running the container.

The deployment process automatically sets the permissions of jndi-config.xml and server-config.wsdd files as user readable only. However, this might not work correctly on all platforms and this does not apply to any other configuration files.

Access of information stored in the database

RFT stores the transfer request in a database. Proper security measures need to be taken to protect the access of the data by granting/revoking appropriate permissions on tables that are created for RFT use and other steps that are appropriate and consistent with site specific security measures.

Permissions of persistent data

RFT uses subscription persistence API from GT4 core to store all of its subscription data under the ~/.globus/pe rsisted directory. Ensure that the entire ~/.globus/persisted directory is only readable by the user running the container.

Permissions of user's delegated proxy credential file

User's delegated proxy is stored in a file in /tmp directory ( on the host running the container ) and appropriate permissions are set on it so it can be accessed only by user running the container. This file is removed by the container after the expiration of RFT resource time to live. If it is removed manually before the expiration of resource lifetime all the transfers will fail. The transfers will also fail to start if there is not enough free space in /tmp dir to store the delegated credential.

Troubleshooting

Problem: If RFT is not configured properly to talk to a PostgreSQL database, you will see this message displayed on the console when you start the container : 

"Error creating RFT Home: Failed to connect to database ... 
Until this is corrected all RFT request will fail and all GRAM jobs that require staging will fail".

Solution: Usual mistake is Postmaster is not accepting TCP connections which  means that you must restart Postmaster with -i option  ( see step 2 ).

Problem: Make RFT print more verbose error messages:

Solution: Edit $GLOBUS_LOCATION/container-log4j.properties and add following line to it: log4j.category.org.globus.transfer=DEBUG . For more verbosity add log4j.category.org.globus.ftp=DEBUG which will print out Gridftp messages too.

Usage statistics collection by the Globus Alliance

The following usage statistics are sent by default in a UDP packet at the end of life time of each RFT Resource (or when a RFT resource is destroyed).

  • Total number of files transferred by RFT since RFT is installed
  • Total number of bytes transferred by RFT since RFT is installed
  • Total number of files transferred in this RFT Resource
  • Total number of bytes transferred in this RFT Resource
  • Creation time of this RFT Resource
  • Factory Start Time

We have made a concerted effort to collect only data that is not too intrusive or private, and yet still provides us with information that will help improve the GRAM component. Nevertheless, if you wish to disable this feature, please see the Java WS Core System Adminstrator guide section on Usage Statistics Configuration for instructions.

Also, please see our policy statement on the collection of usage statistics.