Home -> Toolkit -> Docs -> Development -> 3.9.4 -> Execution -> Wsgram -> Admin

GT 3.9.4 WS GRAM: System Administrator's Guide

• Introduction
• Building and Installing
• Configuring
• Testing
• Security Considerations
• Troubleshooting

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.4, see the Installation Guide.

Building and Installing

Local Prerequisites

WS_GRAM requires the following:

• Host credentials
• GRAM service account
• Gridmap authorization of user account
• Functioning sudo
• Local scheduler

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.

Gridmap authorization of user account

In order to authorize a user to call GRAM services, the security configuration must map the Distinguished Name (DN) of the user to the name of the user in the system where the GRAM services run. Here are the configuration steps:

1. In order to obtain the DN, which is the subject of the user certificate, run the bin/grid-cert-info -subject command in $GLOBUS_LOCATION on the submission machine.

   % bin/grid-cert-info -subject
   /O=Grid/OU=GlobusTest/OU=simpleCA-foo.bar.com/OU=bar.com/CN=John Doe
     

2. Create a /etc/grid-security/grid-mapfile. The syntax is to have one line per user, with the distinguished name followed by a whitespace and then the user account name on the GRAM machine. Since the distinguished name usually contains whitespace, it is placed between quotation marks, as in:

   "/O=Grid/OU=GlobusTest/OU=simpleCA-foo.bar.com/OU=bar.com/CN=John Doe" johndoe

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.4 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 GT 3.9.4 Installation including WS_GRAM

The specifics of the following steps might be somewhat different depending on your environment and preferences but you are doing the following things:

1. Creating a location for the Toolkit installation
2. Making that location your $GLOBUS_LOCATION
3. Downloading and expanding the full GT source tarball
4. Building the source

        % mkdir gt3.9.4

        % cd gt3.9.4

        % export GLOBUS_LOCATION=`/bin/pwd`

        % wget <distribution location>/gt3.9.4-all-source-installer.tar.gz

        % gzip -d gt3.9.4-all-source-installer.tar.gz

        % tar -xf gt3.9.4-all-source-installer.tar

        % cd gt3.9.4-all-source-installer

        % ./configure --prefix=$GLOBUS_LOCATION

        % make

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

Setting up 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 you already have host certs, then you can just copy them to the new name and set ownership.

	% cd /etc/grid-security
	% cp hostcert.pem containercert.pem
	% cp hostkey.pem containerkey.pem
	% chown globus.globus container*.pem

(replace globus.globus with the user and group the container is installed as)
You should now have something like:

/etc/grid-security$ ls -l *.pem
-rw-r--r--  1 globus globus 1785 Oct 14 14:47 containercert.pem
-r--------  1 globus globus  887 Oct 14 14:47 containerkey.pem
-rw-r--r--  1 root   root   1785 Oct 14 14:42 hostcert.pem
-r--------  1 root   root    887 Sep 29 09:59 hostkey.pem

The result is a copy of the host credentials which are accessible by the container.

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

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 (shown for pbs):

    % cd $GLOBUS_LOCATION\gt3.9.4-all-source-installer

    % make gt4-gram-pbs

    % gpt-postinstall

Using PBS as the example, make sure the batch scheduler commands are in your path (qsub, qstat, pbsnodes).

For pbs another setup step is required to configure the remote shell for rsh access:

    % cd $GLOBUS_LOCATION/setup/globus

    % ./setup-globus-job-manager-pbs --remote-shell=rsh

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/GT3.9.4 should be replaced with the GLOBUS LOCATION for your installation:

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

Extra steps for non-default installation

non-default service credentials

alternative location for host credentials

If setting up host credentials in the default location of /etc/grid-security/containercert.pem and containerkey.pem is not an option for you, then you can configure an alternate location to point to host credentials.

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.

User proxy

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

non-default 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 8443 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.

Security Considerations

[describe security considerations relevant for this component]

Troubleshooting

TODO