- A Globus Primer
- Globus Is Modular!
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide
- Migrating Guides
- GSI C
- GSI Java
- Java WS A&A
- C WS A&A (coming soon)
- Delegation Service
Table of Contents
- 1. Remote data-nodes and striped operation
- 2. Separation of Processes (Split Process)
- 3. Plugging in a Data Storage Interface (DSI)
- 4. Configuring GridFTP to run with the Community Authorization Service (CAS)
- 5. Configuring GridFTP to use UDT instead of TCP
- 6. Running with GFork Master Plugin
- 7. Configuring multicasting/broadcasting
- 8. Configuring GridFTP to enable Netlogger's bottleneck detection
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.
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
-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.
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
globus-url-copy -stripe gsiftp://machineA:5000/file file:///destination or globus-url-copy -stripe gsiftp://machineA:5000/file gsiftp://
Where machineX may be another striped server or a standard GridFTP server.
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
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
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
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.
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.
UDT is bundled with Globus starting with Globus v4.2, so downloading UDT separately is no longer needed.
Threaded build of the Globus GridFTP server. Note that starting with Globus v4.2, the default flavor of the server is threaded.
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.
Build and install UDT
globus$ make udt ("make gridftp udt" if gridftp is not built and installed already) globus$ make install
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:
If you run the server from commandline:
$GLOBUS_LOCATION/sbin/globus-gridftp-server -dc-whitelist udt,gsi,tcp
Run globus-url-copy with new command line option "-udt"
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.
To enable multicasting, you must whitelist the
gridftp_multicast driver with the
globus-gridftp-server -fs-whitelist file,gridftp_multicast
The above command whitelists both the
file driver and
For information about using multicasting, click here.
For information on enabling bottleneck detection via Netlogger, see the Gridftp-netlogger page on the CEDPS website.