Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide (coming soon)
- Migrating from GT2
- Migrating from GT3
Reference
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces (coming soon)
- Resource Properties
- Samples
- Glossary
- Performance Studies (coming soon)
Manuals
Common Runtime
Security
- Non-WS (General) Security
- WS Java Security
- Message-level
- Authz Framework
- CAS
- Delegation Service
- MyProxy
- GSI-OpenSSH
- SimpleCA
- SGAS
Data Mgt
MDS4
Execution Mgt
Table of Contents
RFT has the following prerequisites:
- Java WS Core - This is built and installed in a Installing GT 4.1.3.
- A host certificate (see Installing GT 4.1.3).
- GridFTP - GridFTP performs the actual file transfer and is built and installed in a Installing GT 4.1.3.
- 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 others have been tested. For instructions on configuring the PostgreSQL database for RFT, see below. .
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 the container are used. If they arenot specified, default credentials are used.
- GSI Secure conversation authentication is enforced for all methods.
Note: Changing the required authentication and authorization method will require suitable changes to the clients that contact this service.
To alter the security descriptor configuration, refer to security descriptor. The file to be altered is $GLOBUS_LOCATION/etc/globus_wsrf_rft/security-config.xml.
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.
Install PostgreSQL. Instructions on how to install/configure PostgreSQL can be found here.
Configure the postmaster daemon so that it accepts TCP connections. This can be done by adding the "-o -i" switch to the postmaster script (This is either the init.d script found in /etc/init.d/postgresql or /var/lib/, depending on how you installed PostgreSQL). Follow the instructions here to start the postmaster with the -i option.
You will now need to create a PostgreSQL user that will connect to the database. This is usually the account under which the container is running. You can create a PostgreSQL user by running the following command:
su postgres; createuser globus. If you get the following error:psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?this generally means that either your postmaster is not started with the -i option or you didn't restart the postmaster after the above mentioned step.Now you need to set security on the database you are about to create. You can do it by following the steps below:
sudo vi /var/lib/pgsql/data/pg_hba.confand append the following line to the file:host rftDatabase "username" "host-ip" 255.255.255.255 md5Note: use crypt instead of md5 if you are using PostgreSQL 7.3 or earlier.sudo /etc/init.d/postgresql restartTo create the database that is used for RFT run (as user globus):
createdb rftDatabase.To populate the RFT database with the 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:Open
$GLOBUS_LOCATION/etc/globus_wsrf_rft/jndi-config.xml.Find the
dbConfigurationsection under theReliableFileTransferService <service>section.Change the
connectionStringto point to the machine on which you installed PostgreSQL and to the name of the database you used in step 2. If you installed PostgreSQL on the same machine as your Globus install, the default should work fine for you.Change the
userNameto 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).Don't worry about the other parameters in the section. The defaults should work fine for now.
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. The default should work fine for now.maxActiveAllowed: This is the number of transfers the container can do at given point. The default should be fine for now.
With a default GT 4.1.3 installation, the RFT service is automatically registered with the default WS MDS Index Service running in the same container for monitoring and discovery purposes.
There is a jndi resource defined in $GLOBUS_LOCATION/etc/globus_wsrf_rft/jndi-config.xml as follows :
<resource name="mdsConfiguration"
type="org.globus.wsrf.impl.servicegroup.client.MDSConfiguration">
<resourceParams>
<parameter>
<name>reg</name>
<value>true</value>
</parameter>
<parameter>
<name>factory</name>
<value>org.globus.wsrf.jndi.BeanFactory</value>
</parameter>
</resourceParams>
</resource>
To configure the automatic registration of RFT to the default WS MDS Index Service, change the value of the parameter
<reg> as follows:
trueturns on auto-registration; this is the default in GT 4.1.3.falseturns off auto-registration.
By default, the following resource properties (from the RFT Factory Resource) are sent to the default Index Service:
ActiveResourceInstances: A dynamic resource property of the total number of active RFT resources in the container at a given point of time.TotalNumberOfTransfers: A dynamic resource property of the total number of transfers/deletes performed since the RFT service was deployed in this container.TotalNumberOfActiveTransfers: A dynamic resource property of the number of active transfers across all rft resources in a container at a given point of time.TotalNumberOfBytesTransferred: A dynamic resource property of the total number of bytes transferred by all RFT resources created since the deployment of the service.RFTFactoryStartTime: Time when the service was deployed in the container. Used to calculate uptime.DelegationServiceEPR: The end point reference of the Delegation resource that holds the delegated credential used in executing the resource.
You can configure which resource properties are sent in RFT's registration.xml file, $GLOBUS_LOCATION/etc/globus_wsrf_rft/registration.xml.
The following is the relevant section of the file:
<Content xsi:type="agg:AggregatorContent"
xmlns:agg="http://mds.globus.org/aggregator/types">
<agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
<agg:GetMultipleResourcePropertiesPollType
xmlns:rft="http://www.globus.org/namespaces/2004/10/rft">
<!-- Specifies that the index should refresh information
every 60000 milliseconds (once per minute) -->
<agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
<!-- specifies that all Resource Properties should be
collected from the RFT factory -->
<agg:ResourcePropertyNames>rft:TotalNumberOfBytesTransferred</agg:ResourcePropertyNames>
<agg:ResourcePropertyNames>rft:TotalNumberOfActiveTransfers</agg:ResourcePropertyNames>
<agg:ResourcePropertyNames>rft:RFTFactoryStartTime</agg:ResourcePropertyNames>
<agg:ResourcePropertyNames>rft:ActiveResourceInstances</agg:ResourcePropertyNames>
<agg:ResourcePropertyNames>rft:TotalNumberOfTransfers</agg:ResourcePropertyNames>
</agg:GetMultipleResourcePropertiesPollType>
</agg:AggregatorConfig>
<agg:AggregatorData/>
</Content>
If a third party needs to register an RFT service manually, see Registering with mds-servicegroup-add in the WS MDS Aggregator Framework documentation.