Advanced Configuration

It is assumed that the toolkit installation was successful. For more information, see the Installing GT 4.2.0. Also be sure to reference Configuring GridFTP and globus-gridftp-server.

1. Remote data-nodes and striped operation

The GridFTP server now supports separate front end (client control connection) and back end (data node) processes. In addition, a single front end process may connect to multiple back end data nodes.

When multiple back end data nodes are available, the server is said to be in a striped configuration, or simply, is a striped server. In this mode, transfers are divided over all available data nodes, thus allowing the combined bandwidth of all data nodes to be used.

[Note]Note

The connection between the front end and data nodes is referred to as the IPC channel.

The ability to use inetd or daemon execution modes applies to both front end servers and data nodes, and the same certificate and user requirements apply.

To start the front end, run:

globus-gridftp-server <args> -r <host:port>[,<host:port>,...]

To start the data-node, run:

globus-gridftp-server -p <port> -dn

The -p <port> option used on the data-node is the port that will be used for IPC connections. This is the port that you will register with the front end server.

For example:

machineB> globus-gridftp-server -p 6000 -dn
machineC> globus-gridftp-server -p 7000 -dn
machineA> globus-gridftp-server -p 5000 -r machineB:6000,machineC:7000

The client would only connect to the front end at machineA:5000, for example, using globus-url-copy with the -stripe option:

globus-url-copy -stripe gsiftp://machineA:5000/file file:///destination
   or
globus-url-copy -stripe gsiftp://machineA:5000/file gsiftp://machineX/destination

Where machineX may be another striped server or a standard GridFTP server.

2. Separation of Processes (Split Process)

As illustrated above, the GridFTP server can be separated into front end and data node processes. This is the architecture used to achieve a striped server, but it can also be exploited to achieve a higher level of security.

Running the server as root is often desirable because it allows the server to fork and setuid on a child process related to an authenticated user. This allows the server to leverage the operating system's file system permissions and other security devices. However, it is not at all desirable to have a root-running process listening on a port open to the world. If an attacker were to compromise the process, they could obtain root-level access to the machine.

To overcome this security risk, the GridFTP server can be run in a front end/back end manner. The front end can be run as any user, say user globus, that has very limited access to the machine. The front end is the process open to the outside world. If it is compromised, an attacker has only gained access to that limited account. The back end is run as root, but configured to only allow connections from the front end.

To start the front end, run:

globus-gridftp-server -p 7000 -r localhost:7001

To start the back end, run:

globus-gridftp-server -p 7001 -dn -allow-from 127.0.0.1

3. Plugging in a Data Storage Interface (DSI)

FIXME GridFTP can be used as a network interface to existing Data Storage Interfaces (DSIs) using the -dsi option. With this option the DSI plugs into the backend (compatible with striping) and is transparent to the client or remote party. It can be used with either the GT standard DSI plugins or with custom-built DSI plugins. The standard DSI plugins available in a default GT installation are:

The above links point to complete information about setting up and running the GridFTP server with these DSIs.

4. Configuring GridFTP to run with the Community Authorization Service (CAS)

The Community Authorization Service (CAS) is used to administer access rights to files and directories and the GridFTP server can be configured to enforce those rights.

For more information, see How to Set Up CAS to Use with GridFTP.

5. Configuring GridFTP to use UDT instead of TCP

UDT is bundled with Globus starting with Globus v4.2, so downloading UDT separately is no longer needed.

5.1. Prerequisites

  1. Threaded build of the Globus GridFTP server. Note that starting with Globus v4.2, the default flavor of the server is threaded.

  2. For client-server transfers, threaded build of globus-url-copy. For third-party (server-server) transfers, threaded build of globus-url-copy is not needed. Refer to Section 7, “Switching between threaded and non-threaded flavors” for information on how to switch between threaded and non-threaded flavors of globus-url-copy.

5.2. Steps

  1. Build and install UDT

    globus$ make udt ("make gridftp udt" if gridftp is not built and installed already)
      
    globus$ make install
  2. Configure GridFTP server

    If you the GridFTP server from xinetd, add '-dc-whitelist
    	      udt,gsi,tcp' to 'server_args' in /etc/xinetd.d/gsiftp 
    	      

    Alternatively, you can use the file $GLOBUS_LOCATION/etc/gridftp.conf to configure this. Add the following to that file:

    	      dc-whitelist udt,gsi,tcp
    	      

    If you run the server from commandline:

    	      $GLOBUS_LOCATION/sbin/globus-gridftp-server -dc-whitelist
    	      udt,gsi,tcp
    	      

  3. Run globus-url-copy with new command line option "-udt"

6. Running with GFork Master Plugin

GFork is a service like inetd that listens on a TCP port and runs a configurable executable in a child process whenever a connection is made. GFork also creates bi-directional pipes between the child processes and the master service. These pipes are used for interprocess communication between the child process executables and a master process plugin. More information on GFork can be found here.

7. Configuring multicasting/broadcasting

To enable multicasting, you must whitelist the gridftp_multicast driver with the -fs-whitelist file,gridftp_multicast option:

globus-gridftp-server -fs-whitelist file,gridftp_multicast

The above command whitelists both the file driver and the gridftp_multicast driver.

[Note]Note

The file driver is the default XIO driver that handles reading and writing to file systems (disks). By default, this driver is already whitelisted. However, if you use the -fs-whitelist option, you must set all the drivers you want whitelisted (and the file driver will still be needed to allow reads and writes to disk for non-multicast users.

For information about using multicasting, click here.

8. Configuring GridFTP to enable Netlogger's bottleneck detection

For information on enabling bottleneck detection via Netlogger, see the Gridftp-netlogger page on the CEDPS website.