Using GRAM4

1. Generating a valid proxy

In order to generate a valid proxy file, use the grid-proxy-init tool available under $GLOBUS_LOCATION/bin:

    % bin/grid-proxy-init
    Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA.mymachine/OU=mymachine/CN=John Doe
    Enter GRID pass phrase for this identity:
    Creating proxy ................................. Done
    Your proxy is valid until: Tue Oct 26 01:33:42 2004
    

2. Delegating credentials

There are three different uses of delegated credentials:

  1. for use by the MEJS to create a remote user proxy
  2. for use by the MEJS to contact RFT
  3. for use by RFT to contact the GridFTP servers. The EPRs to each of these are specified in three job description elements -- they are jobCredentialEndpoint, stagingCredentialEndpoint, and transferCredentialEndpoint respectively. Please Job Description Schema Reference and RFT transfer request schema documentation for more details about these elements.

The globusrun-ws client can either delegate these credentials automatically for a particular job, or it can reuse pre-delegated credentials (see next paragraph) through the use of command-line arguments for specifying the credentials' EPR files. Please see the GRAM4 Commands for details on these command-line arguments.

It is possible to use delegation command-line tools to obtain and refresh delegated credentials in order to use them when submitting jobs to GRAM4. This, for instance, enables the submission of many jobs using a shared set of delegated credentials. This can significantly decrease the number of remote calls for a set of jobs, thus improving performance.

The following example shows how to delegate credentials. globus-credential-delegate delegates to the specified delegation factory on lucky0.mcs.anl.gov, prints some information and stores the endpoint reference of the delegated credentials into the file delegCred.epr

[martin@osg-test1 ~]$ globus-credential-delegate \
> -s https://lucky0.mcs.anl.gov:8443/wsrf/services/DelegationFactoryService \
> delegCred.epr
Delegated credential EPR:
Address: https://lucky0.mcs.anl.gov:8443/wsrf/services/DelegationService
Reference property[0]:
<ns1:DelegationKey xmlns:ns1="http://www.globus.org/08/2004/delegationService">
  55e2a450-58be-11dd-b83c-e4ec640dfe13
</ns1:DelegationKey>

To destroy the delegated credential use wsrf-destroy:

[martin@osg-test1 jobs]$  wsrf-destroy -e delegCred.epr 
Destroy operation was successful

For more information about the delegation command-line tools see Command-line tools

3. Local resource managers interfaced by a GRAM4 installation

A GRAM4 instance can interface to more than one local resource manager (LRM), as shown in the previous section. A user can explicitly specify what LRM should be used for a job. But in a larger Grid it might be confusing for users to remember which LRM's are available on which machines.

That's why GRAM4 configures a default local resource manager, which is used for job submission if the client didn't explicitly specify one.

3.1. Finding available local resource managers

You can check the resource property availableLocalResourceManagers of a GRAM4 factory service to get that information. Replace host and port in the below example to query against other containers:

[martin@osg-test1 ~]$ globus-wsrf-get-property \
  -s https://osg-test1.unl.edu:8443/wsrf/services/ManagedJobFactoryService \
  "{http://www.globus.org/namespaces/2008/03/gram/job}availableLocalResourceManagers"

The result on that machine is (formatted for better readability) shows that the local resource managers Fork, Multi, Condor and PBS are available:

<ns1:availableLocalResourceManagers 
      xmlns:ns1="http://www.globus.org/namespaces/2008/03/gram/job">
  <ns1:localResourceManager>Fork</ns1:localResourceManager>
  <ns1:localResourceManager>Multi</ns1:localResourceManager>
  <ns1:localResourceManager>Condor</ns1:localResourceManager>
  <ns1:localResourceManager>PBS</ns1:localResourceManager>
</ns1:availableLocalResourceManagers>

A more typical result in a production environment is probably Fork, Multi and just one additional LRM like Condor, PBS or LSF.

3.2. Finding the default local resource manager

You can check the resource property defaultLocalResourceManagers of a GRAM4 factory service to get that information. Replace host and port in the below example to query against other containers:

[martin@osg-test1 ~]$ globus-wsrf-get-property \
  -s https://osg-test1.unl.edu:8443/wsrf/services/ManagedJobFactoryService \
  "{http://www.globus.org/namespaces/2008/03/gram/job}localResourceManager"

The result on that machine shows that PBS is the default local resource managers:

<ns1:localResourceManager xmlns:ns1="http://www.globus.org/namespaces/2008/03/gram/job">
    PBS
</ns1:localResourceManager>