Software Links
Getting Started
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- GT Developer's Guide
- GT User's Guide
- Migrating Guides
Reference
Manuals
Common Runtime
Security
- GSI C
- GSI Java
- Java WS A&A
- C WS A&A (coming soon)
- CAS
- Delegation Service
- MyProxy
- GSI-OpenSSH
- SimpleCA
Data Mgt
WS MDS
Execution Mgt
Table of Contents
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
There are three different uses of delegated credentials:
- for use by the MEJS to create a remote user proxy
- for use by the MEJS to contact RFT
- 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
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.
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.
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>