Deploying the GridFTP Server: globus-gridftp-server

It is assumed that the toolkit installation was successful and that Globus security is properly configured. For more information, see the Installing GT 4.1.3. Also be sure to reference Configuring .

1. Running in daemon mode

The server should generally be run as root in daemon mode, though 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:

  • 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.

2. Running under inetd or xinetd

The -i command line option enables the server to be run under inetd or xinetd.

See Configuring for example xinetd and inetd configuration entries.

3. 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: 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:

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

To start the data-node:

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.

4. Separation of Processes

As is 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 processes related to an authenticated user. This allows the server to leverage the operating systems 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 processes 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:

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

and the back end:

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

5. 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.