A new, complete reimplementation of the server.
Support for striping.
This new implementation will greatly ease new feature additions and modifications of the server (new commands, new data sources such as mass storage devices, etc.), maintainability, and resolves a licensing issue that was discovered.

Features that continue to be supported from previous versions

GSI security: This is the PKI based, de facto standard security system used in Grid applications. Kerberos is also possible but is not supported and can be difficult to use due to divergence in the capabilities of GSI and Kerberos.
Third-party transfers: Very common in Grid applications, this is where a client mediates a transfer between two servers (both likely at remote sites) rather than between the server and itself (called a client/server transfer).
Partial file access: Regions of a file may be accessed by specifying an offset into the file and the length of the block desired.
Reliability/restart: The receiving server periodically (the default is 5 seconds, but this can be changed) sends “restart markers” to the client. This marker is a messages specifying what bytes have been successfully written to the disk. If the transfer fails, the client may restart the transfer and provide these markers (or an aggregated equivalent marker), and the transfer will pick up where it left off. This can include “holes” in the file.
Large file support: All file sizes, lengths, and offsets are 64 bits in length.
Data channel reuse: Data channel can be held open and reused if the next transfer has the same source, destination, and credentials. This saves the time of connection establishment, authentication, and delegation. This can be a huge performance difference when moving lots of small files.
Integrated instrumentation (Performance Markers).
Logging/audit trail (Extensive Logging in the server).
Parallel transfers (Multiple TCP streams between a pair of hosts).
TCP Buffer size control (Protocol supports Manual and Automatic; Only Manual Implemented).
Server-side computation (Extended Retrieve (ERET) / Extended Store (ESTO) commands).
Based on Standards: RFC 959, RFC 2228, RFC 2389, IETF Draft MLST-16 , GGF GFD.020.

Other Supported Features

On the client side we provide a scriptable tool called globus-url-copy. This tool can take advantage of all the GridFTP protocol features and can also do protocol translation between FTP, HTTP, HTTPS, and POSIX file IO on the client machine.
We also provide a set of development libraries and APIs for developers wishing to add GridFTP functionality to their application.

Deprecated Features

None

2. Tested platforms

Tested platforms for GridFTP

i386 Linux
ia64 Linux (TeraGrid)
AIX 5.2
Solaris 9
PA-RISC HP/UX 11.11
ia64 HP/UX 11.22
Tru64 Unix
Mac OS X

While the above list includes platforms on which we have tested GridFTP, it does not imply support for a specific platform. However, we are interested in hearing reports of success or bug reports on any platform.

3. Backward compatibility summary

Protocol changes since GT 4.0.5

None

API changes since GT 4.0.5

None

Exception changes since GT 4.0.5

Not Applicable (GridFTP is not Java-based)

Schema changes since GT 4.0.5

Not Applicable (GridFTP is not SOAP-based)

4. Technology dependencies

GridFTP depends on the following GT components:

Pre-WS Authentication / Authorization
C Common Libraries
XIO

GridFTP depends on the following 3rd party software:

OpenSSL (version included in release)

5. Security considerations

The following are points to consider relative to security:

5.1. Two ways to configure your server

We now provide two ways to configuring your server:

The classic installation. This is equivalent to any FTP server you would normally install. It is run as a root setuid process. Once the user is authenticated, the process does a setuid to the appropriate non-privileged user account.
A new split process installation. In this configuration, the server consists of two processes:
- The control channel (the process the external user connects to) runs as a non-privileged user (typically the globus user).
- The data channel (the process that access the file system and moves the data) runs as a root setuid program as before but is only contacted by the control channel process from a local machine. This means an external user is never connected to a root running process and thus minimizes the impact of an exploit. This does, however, require that a copy of the host cert and host key be owned by the non-privileged user. If you use this configuration, the non-privileged user should not have write permission to executables, configuration files, etc.

5.2. New authentication options

There are new authentication options available for the server in GT 4.1.3:

Anonymous: The server now supports anonymous access. In order for this to work, a configuration switch must explicitly enable it, a list of acceptable usernames must be defined, and an account under which the anonymous user should run must be defined. If the necessary configurations are in place, and the client presents a username that is in the list of acceptable anonymous users, then the session will be accepted and the process will setuid to the anonymous user account. We do not support chroot in this version of the server.
Username / Password: This is standard FTP authentication. It uses a separate password file, used only by the GridFTP server, *NOT* the system password file.

	Warning
	WE HIGHLY RECOMMEND YOU NOT USE THIS. YOU WILL BE SENDING YOUR PASSWORD IN CLEAR TEXT OVER THE NETWORK.

We do, however, have some user communities who run only on internal networks for testing purposes and who do not wish to deal with obtaining GSI credentials. If you are considering this, we would recommend that you look at Simple CA and set up your own testbed CA. This can be done in less than an hour and then provides you full GSI security.

5.3. Firewall requirements

If the GridFTP server is behind a firewall:

Contact your network administrator to open up port 2811 (for GridFTP control channel connection) and a range of ports (for GridFTP data channel connections) for the incoming connections. If the firewall blocks the outgoing connections, open up a range of ports for outgoing connections as well.
Set the environment variable GLOBUS_TCP_PORT_RANGE:
```
export GLOBUS_TCP_PORT_RANGE=min,max 
```
where min,max specify the port range that you have opened for the incoming connections on the firewall. This restricts the listening ports of the GridFTP server to this range. Recommended range is 1000 (e.g., 50000-51000) but it really depends on how much use you expect.
If you have a firewall blocking the outgoing connections and you have opened a range of ports, set the environment variable GLOBUS_TCP_SOURCE_RANGE:
```
export GLOBUS_TCP_SOURCE_RANGE=min,max 
```
where min,max specify the port range that you have opened for the outgoing connections on the firewall. This restricts the outbound ports of the GridFTP server to this range. Recommended range is twice the range used for GLOBUS_TCP_PORT_RANGE, because if parallel TCP streams are used for transfers, the listening port would remain the same for each connection but the connecting port would be different for each connection.

	Note
	If the server is behind NAT, the `--data-interface <real ip/hostname>` option needs to be used on the server.

If the GridFTP client is behind a firewall:

Contact your network administrator to open up a range of ports (for GridFTP data channel connections) for the incoming connections. If the firewall blocks the outgoing connections, open up a range of ports for outgoing connections as well.
Set the environment variable GLOBUS_TCP_PORT_RANGE
```
export GLOBUS_TCP_PORT_RANGE=min,max 
```
where min,max specify the port range that you have opened for the incoming connections on the firewall. This restricts the listening ports of the GridFTP client to this range. Recommended range is 1000 (e.g., 50000-51000) but it really depends on how much use you expect.
If you have a firewall blocking the outgoing connections and you have opened a range of ports, set the environment variable GLOBUS_TCP_SOURCE_RANGE:
```
export GLOBUS_TCP_PORT_RANGE=min,max 
```
where min,max specify the port range that you have opened for the outgoing connections on the firewall. This restricts the outbound ports of the GridFTP client to this range. Recommended range is twice the range used for GLOBUS_TCP_PORT_RANGE, because if parallel TCP streams are used for transfers, the listening port would remain the same for each connection but the connecting port would be different for each connection.

Additional information on Globus Toolkit Firewall Requirements is available here.

Prev		Next
GT 4.1.3 GridFTP : Developer's Guide	Home	Usage Scenarios