Configuring GridFTP

1. GridFTP server configuration overview

The configuration interface for GridFTP is the admin tool, globus-gridftp-server, which can be used with a configuration file and/or run-time options.

[Note]Note

Command line options and configuration file options may both be used, but the command line overrides the config file.

The configuration file for the GridFTP server is read from the following locations, in the given order. Only the first file found will be loaded:

  • Path specified with the -c <configfile> command line option.
  • $GLOBUS_LOCATION/etc/gridftp.conf
  • /etc/grid-security/gridftp.conf

Options are one per line, with the format:

<option> <value>

If the value contains spaces, they should be enclosed in double-quotes ("). Flags or boolean options should only have a value of 0 or 1. Blank lines and lines beginning with # are ignored.

For example:

  port 5000
  allow_anonymous 1
  anonymous_user bob
  banner "Welcome!"
      

For complete command documentation including all options, see globus-gridftp-server(1).

This page includes information about general configuration of the GridFTP server. Security options are discussed here, and more advanced configuration is described here.

2. Types of configurations

The following describes different GridFTP configurations of the front end (control channel) and back end (data channels).

  1. Typical configuration: this is the default where the data channel and control channel are separate socket connections within the same process. The client sends a command and waits to finish before issuing the next command. This is good for a single host, traditional-type user. If you have a single host and you want an ultra-reliable and light weight file transfer service, this is a good choice. Also good for testing purposes.

  2. Separate processes (or split process): control channel and data channel are on different ports - with front end run as a non-privileged user (typically the globus user) with very limited access to the machine and the back end is run as root, but configured to only allow connections from the front end 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. Provides greater security and also allows for proxying and load balancing. Many backend data movers can be behind a single point of client contact. Each client is assigned a different backend in a round robin fashion. For more information about this configuration, see Section 2, “Separation of Processes (Split Process)”.

  3. Striped servers: single control channel (front end), multiple data channels (back end) This is recommended for improved performance of large (1GB+) file transfers. Can also be useful if you want to use full data encryption and need to tether together many hosts to handle the processing load. For more information about this configuration, see Section 1, “Remote data-nodes and striped operation”.

[Note]Note

Furthermore, #2 and #3 can be combined. You can have an 8 node cluster that only uses 2 nodes at a time in a striped server configuration and load balances across the rest of the nodes.

3. globus-gridftp-server quickstart

The following is a quick guide to running the server and using the client:

Look through the list of options for globus-gridftp-server:

globus-gridftp-server --help

Start the server in anonymous mode (discussed more fully here):

globus-gridftp-server –control-interface 127.0.0.1 -aa –p 5000

where:

–control-interface
is the hostname or IP address of the interface to listen for control connections on . This option is only needed here as a rudimentary means of security for this simple example.
–aa
enables anonymous mode
–p
indicates on which port the server listens.

Run a two party transfer with client:

globus-url-copy -v file:///etc/group ftp://localhost:5000/tmp/group

Run 3rd party transfer:

globus-url-copy -v ftp://localhost:port/etc/group ftp://localhost:port/tmp/group2

Experiment with -dbg, and -vb options for debugging and checking the performance of your setup:

globus-url-copy -dbg file:///etc/group ftp://localhost:5000/tmp/group
globus-url-copy -vb file:///dev/zero ftp://localhost:5000/dev/null

where:

-dbg

A useful option when something is not working. It results in a GridFTP control channel protocol dump (along with other useful information) to stderr. If you understand the GridFTP protocol, or you have ambition to understand it, this can be a very useful tool to discover various problems in your setup such as overloaded servers and firewalls. When submitting a bug report or asking a question on the support email lists one should always send along the -dbg output.

-vb

Provides a type of progress bar of the user to observe the rate at which their transfer is progressing.

Ctrl-c - Kill the server.

[Note]Note

There are many possible options and configurations with globus-gridftp-server. For some guidelines on setting it up for your situation, see Key Admin Settings and Tuning Recommendations.

4. Running in daemon mode

The server should generally be run as root in daemon mode, although it is possible to run it as a user (see below). When run as root you will need to have a host certificate.

Run the server:

globus-gridftp-server < -s | -S > <args>

where:

-s
Runs in the foreground (this is the default mode).
-S
Detaches from the terminal and runs in the background.

The following additional steps may be required when running as a user other than root (for more details, review Basic Security Configuration):

  • Create a ~/.gridmap file, containing the DNs of any clients you wish to allow, mapped to the current username.
  • Create a proxy with grid-proxy-init.

5. Running under inetd or xinetd

[Note]Note

We also feature a user-configurable, super-server daemon plugin called GFork. Click here for more information.

5.1. Set up xinetd/inetd config file

[Note]Note

The service name used (gsiftp in this case) should be defined in /etc/services with the desired port.

Here is a sample GridFTP server xinetd config entry in /etc/xinetd.conf:

service gsiftp
{
instances               = 100
socket_type             = stream
wait                    = no
user                    = root
env                     += GLOBUS_LOCATION=(globus_location)
env                     += LD_LIBRARY_PATH=(globus_location)/lib
server                  = (globus_location)/sbin/globus-gridftp-server
server_args             = -i
log_on_success          += DURATION
nice                    = 10
disable                 = no
}

Here is a sample gridftp server inetd config entry in /etc/inetd.conf (read as a single line):

gsiftp   stream   tcp   nowait   root   /usr/bin/env env   \
    GLOBUS_LOCATION=(globus_location)                      \
    LD_LIBRARY_PATH=(globus_location)/lib                  \ 
    (globus_location)/sbin/globus-gridftp-server -i
[Note]Note

On Mac OS X, you must set DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH in the above examples.

On IRIX, you may need to set either LD_LIBRARYN32_PATH or LD_LIBRARY64_PATH.

[Note]Note

You should NOT include USERID in the log lines. See Section 5, “High latency for GridFTP server connections” for more information.

5.2. globus-gridftp-server -i

Use the -i commandline option with globus-gridftp-server:

globus-gridftp-server -i