GT 3.9.3 WS GRAM : System Administrator's Guide

Introduction

This document describes the installation and deployment of WS_GRAM including administrator-selected features, configuration options, and additional host settings necessary for WS_GRAM operation. Readers should be familiar with the Key Concepts and Implementation Approach for WS_GRAM to understand the motivation for and interaction of the various deployed components.

For basic instructions on installing GT 3.9.3, see the Installation Guide.

Building and Installing

Local Prerequisites

WS_GRAM requires the following:

Host credentials

In order to use WS_GRAM, the services running in the WSRF hosting environment require access to an appropriate host certificate.

GRAM service account

WS_GRAM requires a dedicated local account within which the WSRF hosting environment and GRAM services will execute. This account will often be a globus account used for all local services, but may also be specialized to only host WS_GRAM. User jobs will run in separate accounts as specified in the grid-mapfile or associated authorization policy configuration of the host.

Functioning sudo

WS_GRAM requires that the sudo command is installed and functioning on the service host where WS_GRAM software will execute.

Authorization rules will need to be added to the sudoers file to allow the WS_GRAM service account to execute (without a password) local scheduler adapters in the accounts of authorized GRAM users. This topic is covered in detail in the Software Setup section.

Local scheduler

WS_GRAM depends on a local mechanism for starting and controlling jobs. If the fork-based WS_GRAM mode is to be used, no special software is required. For batch scheduling mechanisms, the local scheduler must be installed and configured for local job submission prior to deploying and operating WS_GRAM. The supported batch schedulers in the GT 3.9.3 release are: PBS, Condor, LSF

RFT prerequisites include PostgreSQL to be installed and configured. The instructions are here GRAM depends on RFT for file staging and cleanup. File staging from client host to compute host and visa versa. Jobs requesting these function will fail Without RFT properly setup.

Full GT4 Installation including WS_GRAM

  1. Download and expand the full GT source tarball
  2. Build source
    3.         % wget <GT tarball location>/gt3.9.3-wsrf-source-installer.tar.gz
        % cd gt3.9.3-wsrf-source-installer
        % install-wsrf <install directory>
  3. Done! You have a full Globus Toolkit install including WS_GRAM - with the default configuration.

Configuring

Information on configuration settings and environment variables can be found in the public interface guide.

Enabling Local Scheduler Adapter

The batch scheduler interface implementations included in the release tarball are: PBS, Condor and LSF. To install one of the batch scheduler adapters, follow these steps:

  % cd gt3.9.3-wsrf-source-installer
	% cd schedulers
	% ls

This gives you the following output:

gt4-gram-condor-3.9-src_bundle.tar.gz
gt4-gram-lsf-3.9-src_bundle.tar.gz
gt4-gram-pbs-3.9-src_bundle.tar.gz

Using PBS as the example, make sure the batch scheduler commands are in your path (qsub, qstat, pbsnodes). Then to build and install the PBS bundle type these commands:

	% gpt-build gt4-gram-pbs-3.9-src_bundle.tar.gz gcc32dbg
	% gpt-postinstall

Last thing is to define the GRAM and GridFTP file system mapping for PBS.

Done! You have added the PBS scheduler adapters to your GT installation.

Configuring sudo

When the credentials of the service account and the job submitter are different (multi user mode), then GRAM will prepend a call to sudo to the local adapter callout command. If sudo is not configured properly, the command and thus job will fail.

As root, here are the two lines to add to the /etc/sudoers file for each GLOBUS_LOCATION installation, where /opt/globus/GT393 should be replaced with the GLOBUS LOCATION for your installation:

# Globus GRAM entries
   globus  ALL=(username1,username2) 
           NOPASSWD: /opt/globus/GT393/libexec/globus-gridmap-and-execute 
           /opt/globus/GT393/libexec/globus-job-manager-script.pl *
   globus  ALL=(username1,username2) 
           NOPASSWD: /opt/globus/GT393/libexec/globus-gridmap-and-execute 
           /opt/globus/GT393/libexec/globus-gram-local-proxy-tool *

Extra steps for non-default installation

service credentials

In a default build and install of the Globus Toolkit, the local account is configured to use host credentials at /etc/grid-service/containercert.pem and containerkey.pem. If this is not an option, then you can configure an alternate location to point to host credentials -or- configure to use just a user proxy (personal mode).

Security descriptor configuration details are here, but the quick change is to edit this file $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml.

Change the cert and key paths to point to host credentials that the service account owns.

To run the container using just a user proxy, simply comment out the ContainerSecDesc parameter in the this file $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd like so:

    <!--
        <parameter 
            name="containerSecDesc" 
            value="etc/globus_wsrf_core/global_security_descriptor.xml"/>
     -->

Running in personal mode (user proxy), another GRAM configuration setting is required. GRAM will authorize the RFT service when performing staging functions, it needs to know the subject DN for verification. Here are the steps:

	% cd $GLOBUS_LOCATION/setup/globus
	% ./setup-gram-service-common --staging-subject=
         "/DC=org/DC=doegrids/OU=People/CN=Stuart Martin 564720"

You can get your subject DN by running this command:

	% grid-cert-info -subject

GridFTP server

By default, the GridFTP server is assumed to run as root on localhost:2811. If this is not true for your site then change it by running this command with the proper GridFTP URL values:

	% cd $GLOBUS_LOCATION/setup/globus
	% ./setup-gram-service-common --gridftp-server=gsiftp://gridftp.host.org:1234"

Also, the GridFTP host and/or port must be updated by editing the GRAM and GridFTP file system mapping config file $GLOBUS_LOCATION/etc/gram-service/globus_gram_fs_map_config.xml.

non-default container port

By default, the globus services will assume 8080 is the port the Globus container is using. However the container can be run under a non-standard port, for example:

	% globus-start-container -p 4321

When doing this, GRAM needs to be told the port to use to contact the RFT service, like so:

	% cd $GLOBUS_LOCATION/setup/globus
	% ./setup-gram-service-common --staging-port="4321"

Testing

See the WS GRAM users guide for submitting a test job.

Troubleshooting