Testing the OSG Client

About this Document

hand This document is for OSG users. Simple tests will be introduced which may help testing the correct authentication with and operation of grid resources. This document also provides a step-by-step guide to determine the approximate cause of an error followed by recommendations when a ticket with the Grid Operation Center should be opened.

HELP NOTE
This document does not demonstrate how the Open Science Grid should be used for production runs. None of the techniques presented will scale to production levels! Do not use these tools for large scale productions runs, as these will cause the remote site to crash and possible get your account banned - Condor-G will work much better.

Customize this Document

This form allows you to customize the content of the examples in this document.

Server (CE) Host Name
Client Host Name
Client Login Name
 

Introduction

Using a grid resource involves a series of steps that differ from the steps taken on a Unix resource. The following sections introduce and demonstrate each step required to run a basic grid job submission scenario. By understanding these simple tests you will be well prepared to understand, operate and debug complex grid scenarios. The series of tests are:

  1. Authentication Test: create and verify your grid proxy used to authenticate yourself with a grid resource
  2. Job Submission Test: execute a program on a grid resource
  3. Data Transfer Test: copy data to and from a grid resource

HELP NOTE
The Data Transfer Tests and the Job Submission Tests all depend on the successful completion of the Authentication Test. All tests except the authentication test are independent of each other for the purpose of this document and you can select to run only the ones you choose. The Job Submission Tests require access to a Compute Element, which is the terminology used in the OSG to describe a grid resource that can run jobs. Most OSG Compute Elements have also a GridFTP server that allows to complete the basic Data Transfer Tests . More complex Data Transfer Tests , the ones using SRM, require access to a SRM Storage Element.

Requirements

  1. access to a resource that has OSG client tools installed
  2. a grid user certificate installed on the same resource in $HOME/.globus
  3. access to a potential test resource ( see next paragraph )

Choose a Test Resource

hand Except for the Authentication Test all tests require a grid resource to test against. Consider this guide for choosing an OSG grid resource to run the tests. Make sure to know what your membership Virtual Organization is and that the grid resource you choose supports this VO! This document uses ce.opensciencegrid.org as an example. It can be customized in the form above. The default is ce.opensciencegrid.org which should not be used to run your tests!

Authentication Test

The purpose of your grid certificate is to authenticate yourself with every service provided by a Compute Element. The authentication process is based on the X.509 Public Key Infrastructure which consists of a private key (userkey.pem) and a public key (usercert.pem). Both files together form your certificate and are by default located in $HOME/.globus:

[user@client ~]$ ls -al $HOME/.globus
total 68
drwxr-x---  4 user user  4096 Mar 18 18:50 .
drwx------ 29 user user 12288 Jul 28 08:38 ..
drwxrwxr-x  5 user user  4096 Jul 20 11:18 .gass_cache
drwx------  4 user user  4096 Mar 27 12:14 job
-rw-r-----  1 user user  1724 Dec 16  2008 usercert.pem
-r--------  1 user user  1919 Dec 16  2008 userkey.pem

Your certificate can be used to create a limited life-time Grid Proxy or a VOMS Proxy . You should use a VOMS Proxy if your membership Virtual Organization supports VOMS Proxies and is providing a VOMS Server. Some OSG sites may require the use of a VOMS Proxy and will reject authentication requests using Grid Proxies.

HELP NOTE
If uncertain please contact the VO Manager for your membership VO.

Authentication using a Grid Proxy

To display detailed information about your grid proxy grid-proxy-info can be used:

[user@client ~]$ grid-proxy-info
subject  : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994/CN=1692124231
issuer   : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
identity : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
type     : Proxy draft (pre-RFC) compliant impersonation proxy
strength : 512 bits
path     : /tmp/x509up_u500
timeleft : 291:11:00  (12.1 days)

Identity is sometimes also referred to as Grid Identity or more frequently as Distinguished Name. The last line of the output above indicates how long your current grid proxy will be valid. A grid proxy is said to have expired if there is not time left on it. To renew your grid proxy the program grid-proxy-init is used together with your grid password:

[user@client ~]$ grid-proxy-init -valid 500:00
Your identity: /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
Enter GRID pass phrase for this identity:
Creating proxy ................................. Done
Your proxy is valid until: Tue Aug 18 08:06:35 2009

Authentication using a VOMS Proxy

To display detailed information about your voms proxy voms-proxy-info can be used:

[user@client ~]$ voms-proxy-info -all
WARNING: Unable to verify signature! Server certificate possibly not installed.
Error: Cannot verify AC signature!
subject   : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994/CN=proxy
issuer    : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
identity  : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
type      : proxy
strength  : 1024 bits
path      : /tmp/x509up_u506
timeleft  : 388:18:27
=== VO LIGO extension information ===
VO        : LIGO
subject   : /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
issuer    : /DC=org/DC=doegrids/OU=Services/CN=voms.ligo.org
attribute : /LIGO/Role=NULL/Capability=NULL
timeleft  : 0:00:00
uri       : voms.phys.uwm.edu:15001

Identity is sometimes also referred to as Grid Identity or more frequently as Distinguished Name. Note the display of the extended attributes The first line marked timeleft of the output above indicates how long your current voms proxy will be valid. A voms proxy is said to have expired if there is not time left on it. To renew your voms proxy the program voms-proxy-init is used together with your grid password:

[user@client ~]$ voms-proxy-init -voms LIGO:/LIGO -valid 500:00
Enter GRID pass phrase:
Your identity: /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
Creating temporary proxy ................................ Done
Contacting  voms.phys.uwm.edu:15001 [/DC=org/DC=doegrids/OU=Services/CN=voms.ligo.org] "LIGO" Done
Creating proxy ......................................................... Done

HELP NOTE
The command line option -voms LIGO:/LIGO tells voms-proxy-init to contact the VOMS server for the LIGO VO. This may be different for your VO. Locate a file named vomses on your submission host to find out more about available VOMS servers.

Here what happens with a group you do not belong to, e.g., /MyGroup:

[user@client ~]$ voms-proxy-init --voms VDT:/MyGroup
Your identity: /DC=org/DC=doegrids/OU=People/CN=Firstname Lastname 392994
Enter GRID pass phrase: 
Creating temporary proxy .......................................... Done
Contacting  voms.phys.uwm.edu:15001 [/DC=org/DC=doegrids/OU=Services/CN=voms.ligo.org] "LIGO" Failed

Error: LIGO: Unable to satisfy G/MyGroup Request!

Failed to contact servers for LIGO.

HELP NOTE
If a subsequent attempt at a voms proxy fails, as ours did here, the previously generated proxy is still in effect. You can do another voms-proxy-info --all to verify this.

Mapping Test

A valid grid proxy does not guarantee that you may successfully authenticate with a remote grid resource. For a successful authentication your Distinguished Name must be mapped on the remote resource. A simple and quick way to check if your DN is mapped is to use globus-run:

[user@client ~]$ globusrun -a -r ce.opensciencegrid.org

GRAM Authentication test successful

HELP NOTE
This example requires the Grid Resource Allocation Manager (GRAM) to be available on the resource. This is usually the case on a Compute Element, but not on a Storage Element. If you want to test authentication with a Storage Element, use the next example instead.

Job Submission Test

Job Submission using GRAM

The Grid Resource Allocation Manager (GRAM) is a service running on a Compute Element that services your job submission request and which puts your job into execution after successful authentication.

Here we use the globus-job-run command to execute the id command on the remote resource using the default fork Job Manager:

[user@client ~]$ globus-job-run ce.opensciencegrid.org /usr/bin/id
uid=506(ligo) gid=506(ligo) groups=506(ligo)

Upon success /usr/bin/id returns information about the user account which has been used to execute the program itself on the grid resource. This is the account that your Distinguished Name is mapped to. Unlike the Mapping Test this test also verifies that the account exists and that the job manager was able to run the command on your behalf on the compute element.

HELP NOTE
If you have a restrictive firewall in place, some of this testing will not work, and you will likely get Globus error 74 or 43. See the Condor firewall tuning section on how to solve this.
Moreover, if your client is on a home network behind a NAT, you will also need to configure a GLOBUS_TCP_SOURCE_RANGE (range of non privileged ports) on your home router to forward them to the server.

HELP NOTE
Please open a ticket with the Grid Operation Center for the resource in case all your configurations are correct and the command did not succeed.

Test the Availability of a Job Manager

A Job Manager is a process running on the Compute Element which is managing the execution of your job. By default the job manager fork will be used to fork your program directly on the compute element. As a general rule of thumb you should avoid to use fork and to execute programs on the compute element unless that is your intention. A not complete list of job managers includes fork, managedfork, ccs, condor, lsf, pbs and sge. Depending on the setup of the grid resource more than one job manager may be supported.

Just like in the previous example we can use globus-job-run to verify that the fork job manager is available and used for the execution:

[user@client ~]$ globus-job-run ce.opensciencegrid.org/jobmanager-fork /usr/bin/id
uid=506(ligo) gid=506(ligo) groups=506(ligo)

Notice how we append /jobmanager-fork to the grid resource to explicitly request it. This can be used to detect if a certain job managers such as condor is available:

[user@client ~]$ globus-job-run ce.opensciencegrid.org/jobmanager-condor /bin/hostname
dom118

Because the job is scheduled to be executed through HTCondor this command will likely require more time to complete. Here we used the /bin/hostname command to return the hostname of the worker node executing the job.

To specify a job manager that is not supported by the grid resource creates a convenient way to find out what job managers are supported by the resource from the comfort of the command line:

[user@client ~]$ globus-job-run ce.opensciencegrid.org/jobmanager-pbs /bin/hostname
GRAM Job submission failed because the gatekeeper failed to find the requested service (error code 93)
[user@client ~]$ echo $?
93

HELP NOTE
The names for job managers are case sensitive and are all lower case for GRAM.

Job submission using Condor-G

This section only applies, if you have installed Condor-G in your client. Skip to the next section if otherwise.

This is a simple test. The Condor-G tutorial? documents better more complex examples and you can find even more information in the Condor-G documentation.

  1. Create a dummy shell script
    [user@client ~]$ cat << SCRIPT > test.sh
    #!/bin/bash
    uname -a
    id
    SCRIPT
    [user@client ~]$ chmod a+x test.sh
    
  2. Create a job submit file (replace the jobmanager-pbs with the jobmanager you want to use on the CE)
    [user@client ~]$ cat << JOB > submit.job
    universe = grid
    grid_resource = gt2 ce.opensciencegrid.org/jobmanager-pbs
    executable = test.sh
    log = log
    output = output
    error = error
    Transfer_Executable = True
    transfer_Input_files = 
    transfer_Output_files = 
    WhenToTransferOutput  = ON_EXIT
    Notification = Never
    queue
    JOB
    
  3. Submit job
    [user@client ~]$ condor_submit submit.job
    Submitting job(s).
    1 job(s) submitted to cluster 1.
    
  4. Monitor the job with job
    [user@client ~]$ condor_q
    
    -- Submitter: submit.my.org : <1.2.3.4:22878> : submit.my.org
     ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD               
       1.0   user           10/7  19:03   0+00:00:00 I  0   0.0  test.sh           
    
    1 jobs; 1 idle, 0 running, 0 held
    
  5. Once the job finishes (i.e. is not in the queue anymore), you will get the output in the output file. Check the log file for reports on progress or if the job fails.

Data Transfer Test

Data can be transferred to and from a grid resource using a version of ftp that supports grid authentication called GridFTP. Each Compute Element has a GridFTP server. Also all Storage Element have GridFTP servers, either public or behind a different frontend like Storage Resource Manager. The globus-url-copy command can be used to transfer files using GridFTP.

To verify that GridFTP is working correctly we will

  1. create a file using dd
  2. transfer the file to the grid resource using globus-url-copy
  3. transfer the file back from the grid resource using globus-url-copy
  4. compare both files using diff

First let's create the test file:

[user@client ~]$ dd if=/dev/zero of=/tmp/ce.opensciencegrid.org.test.0 bs=1k count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.005332 seconds, 197 MB/s

Next let's transfer the file to the grid resource:

[user@client ~]$ globus-url-copy file:///tmp/ce.opensciencegrid.org.test.0 gsiftp://ce.opensciencegrid.org/~/ce.opensciencegrid.org.test.0
[user@client ~]$ echo $?
0

To copy the file back to your resource use:

[user@client ~]$ globus-url-copy gsiftp://ce.opensciencegrid.org/~/ce.opensciencegrid.org.test.0 file:///tmp/ce.opensciencegrid.org.test.1
[user@client ~]$ echo $?
0

Finally let's compare the original with the copy received back from the remote resource:

[user@client ~]$ diff /tmp/ce.opensciencegrid.org.test.0  /tmp/ce.opensciencegrid.org.test.1
[user@client ~]$ echo $?
0

HELP NOTE
The file protocol in the URI is used for files on a local file system. In this case no authentication is performed with the local resource before the file is read or written. Replacing file by gsiftp always requires a GridFTP server running at the resource specified in the URI.

File Transfer using UberFTP

uberftp is another command to transfer files using GridFTP.

[user@client ~]$uberftp ce.opensciencegrid.org  ls
220 GSI FTP door ready
200 User fnalgrid logged in
drwx------  1 fnalgrid   fnalgrid            512 Jan 26  2010 some_dir
[user@client ~]$uberftp ce.opensciencegrid.org  "ls some_dir"
220 GSI FTP door ready
200 User fnalgrid logged in
-r--------  1 fnalgrid   fnalgrid             15 Jan 26  2010 some_file
[user@client ~]$uberftp ce.opensciencegrid.org  "cat some_dir/some_file"
220 GSI FTP door ready
200 User fnalgrid logged in
Some text from some_file

File Transfer using LCG-Utils

LCG-Utils is a set of programs that can transfer files from a GridFTP or SRM Storage Element.

  1. ls
    [user@client ~]$ lcg-ls -D srmv2 -b srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/
    /mnt/hadoop/Trash
    /mnt/hadoop/backups
    /mnt/hadoop/chukwa
    /mnt/hadoop/dropfiles
    /mnt/hadoop/hello_world
    /mnt/hadoop/images
    /mnt/hadoop/logs
    /mnt/hadoop/lost+found
    /mnt/hadoop/public
    /mnt/hadoop/scratch
    /mnt/hadoop/system
    /mnt/hadoop/tmp
    /mnt/hadoop/user
    
  2. Transfer
    [user@client ~]$ lcg-cp -D srmv2 -b srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world file://`pwd`/hello_world
    [user@client ~]$ cat hello_world
    hello world!
    [user@client ~]$ rm hello_world 
    

SRM-Fermi

SRM-Fermi is a set of programs that can transfer files from a GridFTP or SRM Storage Element.

  1. ls
    [user@client ~]$ srmls srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/
      /mnt/hadoop//
          /mnt/hadoop/Trash/
          /mnt/hadoop/backups/
          /mnt/hadoop/chukwa/
          /mnt/hadoop/dropfiles/
          /mnt/hadoop/hello_world
          /mnt/hadoop/images/
          /mnt/hadoop/logs/
          /mnt/hadoop/lost+found/
          /mnt/hadoop/public/
          /mnt/hadoop/scratch/
          /mnt/hadoop/system/
          /mnt/hadoop/tmp/
          /mnt/hadoop/user/ 
    
  2. Transfer
    [user@client ~]$ srmcp srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world file:///`pwd`/hello_world
    [user@client ~]$ cat hello_world 
    hello world!
    [user@client ~]$ rm hello_world 
    

SRM LBNL

SRM-LBNL is a set of programs that can transfer files from a GridFTP or SRM Storage Element. These are similar to SRM-Fermi and very verbose (click on the link to see the output).

  1. ls
    [user@client ~]$ srm-ls srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/ 
    ...see long output below...
    
    srm-ls   2.2.2.1.0   Mon Jul 11 10:31:14 PDT 2011
    BeStMan and SRM-Clients Copyright(c) 2007-2011,
    Lawrence Berkeley National Laboratory. All rights reserved.
    Support at SRM@LBL.GOV and documents at http://sdm.lbl.gov/bestman
    
     
    BUILT  Fri Jul 15 13:24:22 EDT 2011  on  glidein.unl.edu
    SRM-CLIENT: Connecting to serviceurl httpg://red-srm1.unl.edu:8443/srm/v2/server
    
    SRM-DIR: Mon Jul 25 18:59:23 CDT 2011 Calling srmLsRequest
    
    SRM-DIR: ..........................
    	Status    : SRM_SUCCESS
    	Explanation : null
    	Request token=null
    
    	SURL=/mnt/hadoop/
    	Bytes=null
    	FileType=DIRECTORY
    	StorageType=null
    	Status=SRM_SUCCESS
    	Explanation=Read from disk..
    	FileLocality=ONLINE
    
    	   SURL=/mnt/hadoop/Trash
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/backups
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/chukwa
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/dropfiles
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/hello_world
    	   Bytes=13
    	   FileType=FILE
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/images
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/logs
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/lost+found
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/public
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/scratch
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/system
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/tmp
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    	   SURL=/mnt/hadoop/user
    	   Bytes=null
    	   FileType=DIRECTORY
    	   StorageType=null
    	   Status=SRM_SUCCESS
    	   Explanation=Read from disk..
    
    SRM-DIR: Printing text report now ...
    SRM-CLIENT*REQUEST_STATUS=SRM_SUCCESS
    SRM-CLIENT*SURL=/mnt/hadoop/
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*FILELOCALITY=ONLINE
    SRM-CLIENT*SURL=/mnt/hadoop/Trash
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/backups
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/chukwa
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/dropfiles
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/hello_world
    SRM-CLIENT*BYTES=13
    SRM-CLIENT*FILETYPE=FILE
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/images
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/logs
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/lost+found
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/public
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/scratch
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/system
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/tmp
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    SRM-CLIENT*SURL=/mnt/hadoop/user
    SRM-CLIENT*FILETYPE=DIRECTORY
    SRM-CLIENT*FILE_STATUS=SRM_SUCCESS
    SRM-CLIENT*FILE_EXPLANATION=Read from disk..
    
  2. Transfer
    [user@client ~]$ srm-copy srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world file:///`pwd`/hello_world 
    ...see long output below...
    [user@client ~]$ cat hello_world
    hello world! 
    [user@client ~]$ rm hello_world 
    
    srm-copy   2.2.2.1.0   Mon Jul 11 10:31:14 PDT 2011
    BeStMan and SRM-Clients Copyright(c) 2007-2011,
    Lawrence Berkeley National Laboratory. All rights reserved.
    Support at SRM@LBL.GOV and documents at http://sdm.lbl.gov/bestman
    
     
    BUILT  Fri Jul 15 13:24:22 EDT 2011  on  glidein.unl.edu
    SRM-CLIENT: Tue Jul 26 12:01:28 CDT 2011 Connecting to httpg://red-srm1.unl.edu:8443/srm/v2/server
    
    SRM-CLIENT: Tue Jul 26 12:01:29 CDT 2011 Calling SrmPrepareToGet Request now ...
    request.token= get:1034871
    
    Request.status=SRM_SUCCESS
    Request.explanation=null
    
    SRM-CLIENT: RequestFileStatus for SURL=srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world is Ready.
    SRM-CLIENT: received TURL=gsiftp://red-gridftp6.unl.edu:2811//mnt/hadoop/dropfiles/hello_world
    
    SRM-CLIENT: Tue Jul 26 12:01:33 CDT 2011 start file transfer
    SRM-CLIENT:Source=gsiftp://red-gridftp6.unl.edu:2811//mnt/hadoop/dropfiles/hello_world
    SRM-CLIENT:Target=file:////home/dweitzel/hello_world
    
    SRM-CLIENT: Tue Jul 26 12:01:36 CDT 2011 end file transfer for srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world
    
    SRM-CLIENT: Tue Jul 26 12:01:36 CDT 2011 Calling releaseFile
    
    SRM-CLIENT:  ...Calling srmReleaseFiles...
    	status=SRM_SUCCESS
    	explanation=null
    	status=SRM_SUCCESS
    	explanation=null
    
    SRM-CLIENT: Request completed with success
    
    SRM-CLIENT: Printing text report now ...
    
    SRM-CLIENT*REQUESTTYPE=get
    SRM-CLIENT*TOTALFILES=1
    SRM-CLIENT*TOTAL_SUCCESS=1
    SRM-CLIENT*TOTAL_FAILED=0
    SRM-CLIENT*REQUEST_TOKEN=get:1034871
    SRM-CLIENT*REQUEST_STATUS=SRM_SUCCESS
    SRM-CLIENT*SOURCEURL[0]=srm://red-srm1.unl.edu:8443/srm/v2/server?SFN=/mnt/hadoop/dropfiles/hello_world
    SRM-CLIENT*TARGETURL[0]=file:////home/dweitzel/hello_world
    SRM-CLIENT*TRANSFERURL[0]=gsiftp://red-gridftp6.unl.edu:2811//mnt/hadoop/dropfiles/hello_world
    SRM-CLIENT*ACTUALSIZE[0]=13
    SRM-CLIENT*FILE_STATUS[0]=SRM_FILE_PINNED
    

https://twiki.grid.iu.edu/bin/view/Trash/ReleaseDocumentationValidateClients

Test Discovery Tools

The OSG Discovery Tools query OSG information system, BDII, to discover information about Compute Elements and Storage Elements.

[user@client ~]$ get_os_versions --vo Engage --match "ScientificSLF Lederman"

Site Name           Compute Element ID                                          OS Version                    
FNAL_FERMIGRID      fermigridosg1.fnal.gov:2119/jobmanager-condor-default       ScientificSLF Lederman 5.5    
FNAL_GPGRID_1       fnpcosg1.fnal.gov:2119/jobmanager-condor-default            ScientificSLF Lederman 5.3    
FNAL_GPGRID_1       fnpcosg1.fnal.gov:2119/jobmanager-condor-group_engage       ScientificSLF Lederman 5.3    
Found OS ScientificSLF Lederman 5.5 for Engage VO at site FNAL_FERMIGRID 
[user@client ~]$ get_surl --vo Engage --show_site_name

SITE NAME                     SURL                                                                                                
UCSDT2                        srm://bsrm-1.t2.ucsd.edu:8443/srm/v2/server?SFN=/hadoop/engage/TESTFILE                             
UCR-HEP                       srm://charm.ucr.edu:10443/srm/v2/server?SFN=/data/bottom/cms/TESTFILE             
CIT_CMS_T2                    srm://cit-se.ultralight.org:8443/srm/v2/server?SFN=/mnt/hadoop/osg/engage/TESTFILE                  
GLOW                          srm://cmssrm.hep.wisc.edu:8443/srm/v2/server?SFN=/osg/vo/engage/TESTFILE                            
..

Other Information System Tools

There are many other tools that can query different components of the OSG information system. The following examples are directed the OSG-ITB repositories (osg-ress-4.fnal.gov, the production one is osg-ress-1.fnal.gov). More information can be found in find available resources.

ReSS (here a Web page) can be queried using Condor and ClassAds:

[user@client ~]$ condor_status -pool osg-ress-4.fnal.gov -format '%s\n' GlueSiteName | sort | uniq
CIT_ITB_1
ITB_INSTALL_TEST_2
ITB_INSTALL_TEST_3
CMS-BURT-ITB
...

BDII can be queried with ldapsearch:

  1. If you have no ldapsearch, you can install openldap-clients it with yum:
    [user@client ~]$ yum install openldap-clients
    
  2. Query:
    [user@client ~]$ ldapsearch -x -LLL -p 2170 -h is-itb.grid.iu.edu -b mds-vo-name=LBNL_VTB,mds-vo-name=local,o=grid
    dn: mds-vo-name=LBNL_VTB,mds-vo-name=local,o=grid
    objectClass: GlueTop
     
    dn: GlueSEUniqueID=osp1.lbl.gov,mds-vo-name=LBNL_VTB,mds-vo-name=local,o=grid
    ...
    

LCG tools (lcg-info and lcg-infosites) can be used for queries to the BDII as well:

[user@client ~]$ lcg-info --list-ce --bdii is-itb.grid.iu.edu:2170 --vo osg
- CE: cithep201.ultralight.org:2119/jobmanager-condor-osg
- CE: cms-xen1.fnal.gov:2119/jobmanager-condor-osg
....

[user@client ~]$ lcg-info --list-se --bdii is-itb.grid.iu.edu:2170 --vo osg
- SE: cit-se.ultralight.org
- SE: cms-xen1.fnal.gov
... 
 
[user@client ~]$ lcg-infosites --vo osg -f ce  --is is-itb.grid.iu.edu 
valor del bdii: is-itb.grid.iu.edu:2170
#CPU    Free    Total Jobs      Running Waiting ComputingElement
----------------------------------------------------------
  40      40       0              0        0    osp1.lbl.gov:2119/jobmanager-pbs-batch
   2       0       0              0        0    tb10.grid.iu.edu:2119/jobmanager-condor-osg
1042       2       0              0        0    itb.rcac.purdue.edu:2119/jobmanager-condor-osg
...

[user@client ~]$ lcg-infosites --vo osg -f se  --is is-itb.grid.iu.edu 
Avail Space(Kb) Used Space(Kb)  Type    SEs
----------------------------------------------------------
125             2               n.a     osp1.lbl.gov
28824440        10638628        n.a     tb10.grid.iu.edu
37              242             n.a     itb.rcac.purdue.edu
...

References

Comments

Topic revision: r34 - 07 Feb 2017 - 19:38:25 - BrianBockelman
Hello, TWikiGuest!
Register

 
TWIKI.NET

TWiki | Report Bugs | Privacy Policy

This site is powered by the TWiki collaboration platformCopyright by the contributing authors. All material on this collaboration platform is the property of the contributing authors..