GT 3.9.5: Command Line Client Guide

• Introduction
• GUIs
• Using command line clients
• Command line clients
  • Common Runtime Components
    • Java WS Core
    • C WS Core
    • XIO
    • C Common Libraries
  • Security
    • WS A&A
      • Authorization Framework
      • CAS
      • Delegation Service
      • Message/Transport-level Security
    • Credential Management
      • MyProxy
      • SimpleCA
    • Utilities
      • GSI-OpenSSH
    • Pre-WS A&A
  • Data Management
    • GridFTP
    • RFT
    • RLS
  • Information Services
    • WS MDS (MDS4)
      • Index Service
      • Trigger Service
      • Aggregator
    • Pre-WS MDS (MDS2)
  • Execution Management
  • WS GRAM
  • Pre-WS GRAM

Introduction

[user-friendly introduction to using the GT. this is intended to provide context for using the human-driven interfaces in the toolkit]

Using command line clients

[includes easy-to-follow instructions for general things end users should do for ALL command line clients, such as Setting your environment and how to generate command line clients...]

Command line clients

The following are links to information on each component's command line clients:

Common Runtime Components: Java WS Core

• globus-start-container
• globus-stop-container
• wsrf-destroy
• wsrf-set-termination-time
• wsrf-query
• wsrf-get-property
• wsrf-get-properties
• wsrf-insert-property
• wsrf-delete-property
• wsrf-update-property
• wsn-get-current-message
• wsn-pause-subscription
• wsn-resume-subscription
• wsn-subscribe
• globus-deploy-gar
• globus-undeploy-gar

The above command line tools are available on Unix and Windows platforms and will work in the same way (of course within the platform rules - the path syntax, variable definitions, etc.).

The wsrf-* and wsn-* clients should work against any service that supports the given WSRF or WSN operations.

globus-start-container

Tool description

Starts a standalone container. By default a secure container is started on port 8443 and is accessible via HTTPS. On successful startup a list of services will be displayed on the console. By default the non secure (HTTP) container is started on port 8080.

Command syntax

globus-start-container [options]

globus-stop-container

Tool description

Stops a standalone container. By default this command will attempt to stop a container running on localhost:8443 and perform a soft shutdown.

The globus-stop-container command invokes a ShutdownService running in the container. By default that service is configured to perform self authorization and therefore the globus-stop-container must be executed with the same credentials as the container is running with. Alternatively, the service can be configured with a gridmap file to allow a subset of users (with their own credentials) to invoke the service (please see the service security deployment descriptor for details).

Command syntax

globus-stop-container [options] ['soft' | 'hard']

Where:

'soft'

This option lets the threads die naturally

'hard'

This option forces an immediate JVM shutdown.

Example:

$ globus-stop-container soft

wsrf-destroy

wsrf-destroy [options]

Example:

$ wsrf-destroy -s http://localhost:8080/wsrf/services/CounterService \
   -k "{http://counter.com}CounterKey" 123

wsrf-set-termination-time

wsrf-set-termination-time [options] <seconds> | 'infinity' 

Example:

$ wsrf-set-termination-time -s http://localhost:8080/wsrf/services/CounterService \
   -k "{http://counter.com}CounterKey" 123 30

wsrf-query

wsrf-query [options] [query expression] [dialect]

Example:

$ wsrf-query -s http://localhost:8080/wsrf/services/ContainerRegistryService \
   "/*/*/*/*[local-name()='Address']"

wsrf-get-property

wsrf-get-property [options] <property>

The <property> is a QName of the resource property in the string form: {namespaceURI}localPart.

Example:

$ wsrf-get-property -s http://localhost:8080/wsrf/services/CounterService \
   -k "{http://counter.com}CounterKey" 123 \
  "{http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd}CurrentTime"

wsrf-get-properties

wsrf-get-properties [options] <property1> [<property2>... <propertyN>]

Each <propertyN> is a QName of the resource property in the string form: {namespaceURI}localPart.

Example:

$ wsrf-get-properties -s http://localhost:8080/wsrf/services/CounterService \
  -k "{http://counter.com}CounterKey" 123 \ 
  "{http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd}CurrentTime" \
  "{http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd}TerminationTime"

wsrf-insert-property

wsrf-insert-property [options] <propertyValueFile>

The <propertyValueFile> is an XML file that contains the value of the resource property. The QName of the property is the outer most element.

Example:

Contents of in.xml:

 <doc>
   <ns1:foo xmlns:ns1="http://widgets.com">
     Value1
   </ns1:foo>
   <ns1:foo xmlns:ns1="http://widgets.com">
     Value2
   </ns1:foo>
 </doc>

$ wsrf-insert-property -s http://localhost:8080/wsrf/services/WidgetService \
   -k "{http://www.globus.org/namespaces/2004/06/core}WidgetKey" 123 \
   in.xml

wsrf-update-property

wsrf-update-property [options] <propertyValueFile>

The <propertyValueFile> is an XML file that contains the value of the resource property. The QName of the property is the outermost element.

Example:

Contents of in.xml:

 <doc>
   <ns1:foo xmlns:ns1="http://widgets.com">
     Value
   </ns1:foo>
 </doc>

$ wsrf-update-property -s http://localhost:8080/wsrf/services/WidgetService \
   -k "{http://www.globus.org/namespaces/2004/06/core}WidgetKey" 123 \
   in.xml

wsrf-delete-property

wsrf-delete-property [options] <property>

The <property> is a QName of the resource property in the string form: {namespaceURI}localPart.

Example:

$ wsrf-delete-property -s http://localhost:8080/wsrf/services/WidgetService \
   -k "{http://www.globus.org/namespaces/2004/06/core}WidgetKey" 123 \
   "{http://widgets.com}foo"

wsn-get-current-message

wsn-get-current-message [options] <topic>

The <topic> is a QName of the resource property in the string form: {namespaceURI}localPart.

Example:

$ wsn-get-current-message -s http://localhost:8080/wsrf/services/CounterService \
   -k "{http://counter.com}CounterKey" 123 \ 
   "{http://counter.com}Value"

wsn-pause-subscription

wsn-pause-subscription [options]

Example:

$ wsn-pause-subscription -s http://localhost:8080/wsrf/services/SubscriptionManagerService \
   -k "{http://www.globus.org/namespaces/2004/06/core}acc271c0-4df9-11d9-ab19-87da3bc7cf28"

wsn-resume-subscription

wsn-resume-subscription [options]

Example:

$ wsn-resume-subscription -s http://localhost:8080/wsrf/services/SubscriptionManagerService \
   -k "{http://www.globus.org/namespaces/2004/06/core}acc271c0-4df9-11d9-ab19-87da3bc7cf28"

wsn-subscribe

wsn-subscribe [options] <topic>

The <topic> is a QName of the resource property in the string form: {namespaceURI}localPart.

The following are subscribe-specific options in addition to the common options:

Example:

$ wsn-subscribe -s http://localhost:8080/wsrf/services/CounterService \
   -k "{http://counter.com}CounterKey" 123 \ 
   "{http://counter.com}Value"

globus-deploy-gar

globus-deploy-gar <gar.file> [options]

The <gar.file> is an path to the GAR file to be deployed. The -profile option can be used to specify the profile name under which the configuration files in the GAR will be deployed. Please see Configuration Profiles for details.

Example:

$ globus-deploy-gar /tmp/gars/globus_wsrf_core_samples_counter.gar

The globus-deploy-gar invokes Ant task. The above example is equivalent to running:

$ ant -f $GLOBUS_LOCATION/share/globus_wsrf_common/build-packages.xml deployGar \
      -Dgar.name=/tmp/gars/globus_wsrf_core_samples_counter.gar

The profile name can be passed using -Dprofile Ant option. Make sure to use absolute path name for the gar file when using Ant directly.

globus-undeploy-gar

globus-undeploy-gar <gar.id>

$ globus-undeploy-gar globus_wsrf_core_samples_counter

$ ant -f $GLOBUS_LOCATION/share/globus_wsrf_common/build-packages.xml undeployGar \
      -Dgar.id=globus_wsrf_core_samples_counter

Common Command syntax

-k "{http://www.globus.org}MyKey" 123

Common Runtime Components: C WS Core

globus-wsc-container

Tool description

This command starts the C WS container, allowing WS and WSRF-enabled services to be invoked. globus-wsc-container must be running to invoke services written using the C WS core.

Features

• The container can be run in the background with the -bg option, and -pidfile allows the pid of the process to written to a specified file. This is useful for scripting the command, especially when running tests, or when the container process is expected to have a short lifetime.
• Supports HTTPS by default. In order to turn off HTTPS, use the -nosec argument

Limitations

• The C container does not have a shutdown command (the Java container has globus-stop-container). To shutdown the C container, you can either CRTL-C the process, or kill the process with the process ID (use -pidfile)

Command syntax

Run: globus-wsc-container -help

globus-wsrf-cgen

Tool description

This tool generates C bindings from a set of WSDL schema files. The tool is able to generate client bindings, service bindings, just types, or all three. The WSDL to C mapping document gives more information on how WSDL is mapped to the C programming language.

Command syntax

Run: globus-wsrf-cgen -help

Limitations

• Only generates bindings from document/literal style WSDL schemas. For more information on WSDL schema styles, go here.
• Only generates ANSI-C bindings. C++ bindings are not supported.

Common Runtime Components: XIO

XIO is strictly a library; there is no command line tool for XIO.

Common Runtime Components: C Common Libraries

There is no support for this type of interface.

Security: WS A&A: Authorization Framework

There is no support for this type of interface.

Security: WS A&A: CAS

• CAS User Clients
  • cas-proxy-init
  • cas-wrap
• CAS Administration Clients
  • Enrolling and Unenrolling Trust Anchors
  • Enrolling and Unenrolling Users
  • Enrolling and Unenrolling Namespaces
  • Enrolling and Unenrolling Objects
  • Enrolling and Unenrolling Service Type
  • Maintaining Service Types
  • Maintaining User Groups
  • Maintaining Object Groups
  • Maintaining Service/Action Groups
  • Maintaining Service/Action Groups
• CAS Query Clients
  • Getting user's CAS identity
  • Getting object list
  • Getting CAS object
  • Getting group memebers
  • Getting policy information
• CAS Client common options

CAS User Clients

These are clients that a user would use to get a signed CAS assertion and have it embedded in the user proxy. A script is also provided for the user to use the proxy with the CAS assertion to run arbitraty command.

cas-proxy-init

        cas-proxy-init [options] [ -t tag | -p proxyfile ]

    http://Host:Port/ogsa/services/base/cas/CASService
  

Getting specific CAS rights using cas-proxy-init

It is possible to request specific permissions from the CAS server using the -f option. This option causes cas-proxy-init to read a set of requested rights from a file.

This file should contain one or more resource identifiers:

        Resource: ResourceNamesapce|ResourceName 

For each resource, one or more actions identifers:

        serviceType action 

For example, if the client needed assertions for "file/read" service/action for resource "ftp://sample.org" and "ftp://sample3.org", both in "FTPNamespace" and "directory/read" and "directory/write" permissions on the former resource only, the policy file should have the following entries:

        Resource: FTPNamespace|ftp://sample1.org
        file read
        directory read
        directory write
        Resource: FTPNamespace|ftp://sample3.org
        file read

To indicate any resource, the following wildcard notation should be used.

uri:samlResourceWildcard

To indicate any action, the following wildcard notation for serviceType and action should be used. Note that this should be the first (and clearly the only action) in the list of action specified. All other actions in the list are ignored and if it is not the first, it is not treated as wildcard.

uri:samlActionNSWildcard uri:samlActionWildcard

For example, if the client needs assertions for all resources and all actions the policy file should look like.

       Resource: uri:samlResourceWildcard
       uri:samlActionNSWildcard uri:samlActionWildcard

If the client needs assertions for all actions on resource "FTPNamespace|ftp://sample1.org", the policy file should be as follows

       Resource: FTPNamespace|ftp://sample1.org
       uri:samlActionNSWildcard uri:samlActionWildcard

cas-wrap

The cas-wrap program runs a grid-enabled program, causing it to use previously-generated CAS credentials.

        cas-wrap [-t tag | -p proxyfile ] command args

cas-wrap invokes the given command with the given argument using the specified previously-generated CAS credential. For example:

        % cas-wrap -t my-community gsincftp myhost.edu

will look for a credential generated by a previous execution of:

        % cas-proxy-init -t my-community

and then set the environment to use that credential while running the command

        % gsincftp myhost.edu

The second form should be used if cas-proxy-init was run with the -p option; for example,

        % cas-wrap -p /path/to/my/cas/credential gsincftp myhost.edu

will look for a credential generated by a previous execution of:

        % cas-proxy-init -p /path/to/my/cas/credential

and then set the environment to use that credential while running the command

        % gsincftp myhost.edu

CAS Administrator Clients

The CAS administrator clients can be used to manipulate and maintain the data in CAS database. It allows one to enroll (and unenroll) CAS Objects, create (and delete) groups, add (and remove) members from groups, add (and remove) service type and action mappings. Typically these operation are performed by the CAS Administrator.

All enroll operations involve granting cas/grantAll permission on the enrolled object to some user group (to which the user may belong to or otherwise).

All operations require that the user have specific permissions to perform the operation. Permissions and policies are given and applied to user groups. Hence a user is said to have permission to perform an operation if one of the user groups that the user belongs to has permission to perform that operation.

If some user group to which the user belongs to, has permission "superuser" on cas server object, then they may perform any operation, even if they donot have specific rights that are outlined below for each operation.

If a user has cas/grantAll permission on any object, then the user is permitted to perform any operations on that object.

Enrolling and Unenrolling Trust Anchors

To enroll a trust anchor, the user must have cas/enroll_trustAnchor permission on that cas server object(that is, must have permission to perform the enroll_trustAnchor action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The nickname should be unique across the CAS database and is used to refer to this trust anchor.

  casAdmin$ cas-enroll [options] trustAnchor userGpName nickname authMethod authData

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• nickname : trust anchor nickname
• authMethod : authentication method used by the trust anchor
• authData : data used for authentication, typically the DN

To unenroll a trust anchor, the user must have cas/unenroll permission on that trust anchor. The trust anchor must also be unused, that is there may not be any users in the database that have this trust anchor or it may not be a part of any object group.

  casAdmin$ cas-remove [options] trustAnchor nickname

• options : client options
• nickname : nickname of the trust anchor to be unenrolled

If the trust anchor nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that trust anchor is purged.

Enrolling and Unenrolling Users

To enroll a user, the user must have cas/enroll_user permission (that is, must have permission to perform the enroll_user action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The enrolled user also gets all the privileges granted to the community. The nickname should be unique across the CAS database and is used to refer to this user.

  casAdmin$ cas-enroll [options] user userGpName nickname subjectName trustAnchorNick

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• nickname : user nickname
• subjectName: subject name from the user's credentails.
• trustAnchorNick: Name of the user's trust anchor. (Must exist in the CAS database)

To unenroll a user, the user must have cas/unenroll permission on that user. The user must also be unused, that is, there may not be any user groups in the database that have this user as a member.

  casAdmin$ cas-remove [options] 
	  user nickname

• options : client options
• nickname : nickname of the user to be unenrolled

If the user nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that user is purged.

Enrolling and Unenrolling Namespaces

To enroll a namespace, the user must have cas/enroll_namespace permission (that is, must have permission to perform the enroll_namespace action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The comparison algorithm specified should be the name of the Comparison class that needs to be used to compare objects that belong to this namespace. The nickname should be unique across the CAS database and is used to refer to this user.

casAdmin$ cas-enroll [options] namespace userGpName nickname basename comparisonAlg

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• nickname : namespace nickname
• basename : base URL for the name space
• comparisonAlg : Comparison algorithm to be used. Unless the standard comparison algorithms described below are used, the fully qualified name of the class that needs to be used should be given. The class needs to extend from the abstract class org.globus.ogsa.impl.base.cas.server.ObjectComparison.

• ExactComparison : This class does a case-sensitive exact comparison of the object names. If comparisonAlg in the above method is set to "ExactComparison", the class in the distribution is loaded and used.
• WildcardComparison: This class does wild card matching as described in "CAS Simple Policy Language". (FIXME link to that doc) It assumes that the wild card character is "*" and "/" is file separator. If comparisonAlg in the above method is set to "WildCardComparison", the class in the distribution is loaded and used.

Also two namespaces are added to the CAS database at bootup time, other than the inherent CAS Namespace.

• FTPDirectoryTree : Uses the WildCardComparison Algorithm and has the base URL set to current directory.
• FTPExact : Uses the ExactComparison Algorithm and has the base URL set to current directory.

To unenroll a namespace, the user must have cas/unenroll permission on that namespace. The namespace must also be unused, that is, there may not be any object in the database that belongs to this namespace.

  casAdmin$ cas-remove [options] namespace nickname

• options : client options
• nickname : nickname of the namespace to be unenrolled

If the namespace nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that namespace is purged.

Enrolling and Unenrolling Objects

To enroll a object, the user must have cas/enroll_object permission (that is, must have permission to perform the enroll_object action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The name of the object and the the namespace this object belongs to identifies an object in the database and should be unique across the CAS database.

  casAdmin$ cas-enroll [options] object userGpName objectName namespaceNick

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• objectName : name of the object
• namespaceNick: nickname of the namespace this object belongs to.

To unenroll a object, the user must have cas/unenroll permission on that object. The object must also be unused, that is, there may not be any object group in the database that this object belongs to

casAdmin$ cas-remove [options] object objName namespaceNick

• options : client options
• objName : name of the object to be unenrolled
• namespaceNick: nickname of the namespace this object belongs to

If the object specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that object is purged.

Enrolling and Unenrolling Service Type

To enroll a service type, the user must have cas/enroll_serviceType permission (that is, must have permission to perform the enroll_serviceType action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled service type. The service type name should be unique across the CAS database.

  casAdmin$ cas-enroll [options] serviceType userGpName serviceTypeName

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• serviceTypeName: service type name

To unenroll a service type, the user must have cas/unenroll permission on that service type. The service type must also be unused, that is, there may not have any service type to action mapping.

  casAdmin$ cas-remove [options] serviceType serviceTypeName

• options : client options
• serviceTypeName: service type name

If the service type specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that service type is purged.

Maintaining Service Types

To add an action mapping to a service type, the user must have cas/create_group_entry permission on the service type.

  casAdmin$ cas-action [options] add serviceTypeName actionName

• options : client options
• serviceTypeName: service type name
• actionName: action name

To remove a service type action mapping, the user must have cas/delete_group_entry permission on the service type.

  casAdmin$ cas-action [options] remove serviceTypeName actionName

• options : client options
• serviceTypeName: service type name
• actionName: action name

If the group member being removed does not exist, an error is not thrown.

Maintaining User Groups

To create a new user group, the user must have cas/create_user_group permission(thats is, must have permission to perform create_user_group action on cas service type). The user group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created user group. If the user group that is chosen to have cas/grantAll permission is the new group created, then the user making this request is added to the new group.

  casAdmin$ cas-group-admin [options] user create userGpName groupName

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• groupName : name of the user group being created

To add to a user to a user group, the user must have cas/add_group_entry permission on that particular user group. Only user nicknames that exist in the CAS database can be valid members.

  casAdmin$ cas-group-add-entry [options] user groupName nickname

• options : client options
• groupName : user group name to which the memeber needs to be added
• nickname : nickname of the user to be added to this group.

To remove a user from a user group, the user must have cas/remove_group_entry permission on that particular user group.

  casAdmin$ cas-group-remove-entry [options] user groupName nickname

• options : client options
• groupName : user group name to which the memeber needs to be added
• nickname : nickname of the user to be added to this group.

If the group member being removed does not exist, an error is not thrown.

To delete a user group, the user must have cas/delete_user_group entry permission on that user group. The group must be empty and also not be referenced from other entities in the database(for example should not be a memeber of some object group and such).

  casAdmin$ cas-group-admin [options] user delete groupName

• options : client options
• groupName : name of the user group to be deleted

If the user group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Object Groups

To create a new object group, the user must have cas/create_object_group permission(thats is, must have permission to perform create_object_group action on cas service type). The object group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created object group.

  casAdmin$ cas-group-admin [options] object create userGpName groupName

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• groupName : name of the user group being created

To add to a member, (an object group can have the following CasObjects as members, object, user, user group, service type, namespace or trust anchor) to a object group, the user must have cas/add_group_entry permission on that particular object group.

  casAdmin$ cas-group-add-entry [options] object groupName objectSpecDesc objcetSpec

• options : client options
• groupName : object group name to which the memeber needs to be added
• objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type)
• objectSpec : the identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName)

To remove an object from a object group, the user must have cas/remove_group_entry permission on that particular object group:

  casAdmin$ cas-group-remove-entry [options] object groupName objectSpec objectSpecDesc

• options : client options
• groupName : user group name to which the memeber needs to be added
• objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type
• objectSpec : the identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName)

If the group member being removed does not exist, an error is not thrown.

To delete a object group, the user must have cas/delete_user_group entry permission on that object group. The group must be empty.

  casAdmin$ cas-group-admin [options] object delete groupName

• options : client options
• groupName : name of the object group to be deleted

If the object group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Service/Action Groups

To create a new service/action group, the user must have cas/create_serviceAction_group permission(that is, must have permission to perform create_serviceAction_group action on cas service type). The serviceAction group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created serviceAction group.

  casAdmin$ cas-group-admin [options] serviceAction create userGpName groupName

• options : client options
• userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
• groupName : name of the serviceAction group being created

To add to a service/Action to a serviceAction group, the user must have cas/add_group_entry permission on that particular serviceAction group (that is, must have permission to perform add_group_entry action on that service action group)

  casAdmin$ cas-group-add-entry [options] serviceAction groupName serviceTypeName actionName

• options : client options
• groupName : user group name to which the member needs to be added
• serviceTypeName : service type name part of mapping to be added to group
• actionName : action name part of mapping to be added to group

To remove a service/Action from a serviceAction group, the user must have cas/remove_group_entry permission on that particular serviceAction group.

  casAdmin$ cas-group-remove-entry [options] serviceAction groupName serviceTypeName actionName

• options : client options
• groupName : user group name to which the memeber needs to be added
• serviceTypeName : service type name part of mapping to be added to group
• actionName : action name part of mapping to be added to group

To delete a serviceAction group, the user must have cas/delete_user_group entry permission on that serviceAction group. The group must be empty and also must not be referenced from any other entity in the database. (for example should not be a memeber of some object group and such)

  casAdmin$ cas-group-admin [options] serviceAction delete groupName

• options : client options
• groupName : name of the user group to be deleted

If the service action group specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that serviceAction group is purged.

Maintaining Permissions

The user may grant permissions to a user group, on a object or object group to perform a service action or service action group (that is to perform any action that is a member of the service action group to which permission is granted), provided the user has has both:

• cas/grant permission on the object or object group
• permission to perform the service action or service action group on the object or object group.

  casAdmin$ cas-rights-admin [options] grant userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec

• options : client options
• userGroupName : the user group to grant permission for.
• objectSpec : identifier for object or object group
• objectSpecDesc : type (object or objectGroup)
• actionSpec : identifier for action or action group
• actionSpecDesc : type (serviceAction or serviceActionGp)

The user may revoke a policy in the CAS database provided the user has cas/revoke permission on the object or object group on whch the policy is defined.

  casAdmin$ cas-rights-admin [options] revoke userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec

• options : client options
• userGroupName : the user group to grant permission for.
• objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) serviceType (or) userGroup (or)
• objectSpec : identifier for object or object group
• actionSpec : identifier for action or action group
• actionSpecDesc : type (serviceAction or serviceActionGp)

CAS Query Clients

The CAS Query commands donot alter the state of the database and any CAS user who has cas/query permissions may use the commands to retrieve data from the CAS server.

The following queries can be run against the CAS server. These are typically used by CAS clients (who may not be administrators).

The user need cas/query permissions to perform these operations, that is the user must have permission to query on the cas server object.

Getting user's CAS identity

  casUser$ cas-whoami [options]

• options : client options

Getting object list

  casUser$ cas-list-object [options] type

• options : client options
• type : trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) objectGroup (or) namespace (or) serviceType (or) serviceAction (or) serviceActionGp

Getting CAS object

  casUser$ cas-get-object [options] type name

• options : client options
• type : trustAnchor (or) user (or) object (or) namespace (or) service Type
• name : nickname (or) nickname (or) objectNamesapce objectName (or) nickname (or) serviceTypeName (corresponding to the type)

Getting group memebers

  casUser$ cas-group-list-entries [options] type name

• options : client options
• type : Type of group. user (or) object (or) serviceAction
• name : Name of group

Getting policy information

  casUser$ cas-find-policies [-c cas-url] type name

• [-c cas-url] : the URL of the CAS service
• type : trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) namespace (or) service Type (or) serviceAction (or) serviceActionGroup
• name : nickname (or) nickname (or) groupName (or) objectNamespace|objectName (or) groupName (or) nickname (or) serviceTypeName (or) serviceType/Action (or) groupName (corresponding to the type)

CAS Client common options

 [-debug -help -v -c cas-url -s server-identity -m mechanism -p protection] 

• CAS Service URL: The -c cas-url option can be used to set CAS Service instance, where cas-url is the URL of the CAS service instance. Alternatively, an environment variable can be set as shown here.

  The instance URL typically looks like http://Host:Port/ogsa/services/base/cas/CASService, where Host and Port are host and port where container with CAS service is running.

• CAS Service Identity:

  The -s server-identity option can be used to set the expected CAS server identity, where server-identity is the identity of the CAS service. Alternatively, an environment variable can be set as shown here. If neither is set, host authorization is done and the expected server credential is cas/<fqdn>, where <fqdn> is the fully qualified domain name of the host on which the CAS service is up.

• Debug: To run the client with debug message traces and error stack traces, -debug flag must be used
• Usage: The -help flag prints the usage message for the client.
• Version number: The -v flag prints the version number.
• Security Mechanism: The -m flag is used to set the chosen security mechanism. It can be set to 'msg' for Secure Message, 'conv' for Secure Conversation and 'trans' for Transport security. If not set and the server URL starts with 'https', Transport Security is used, else Secure Message is used.
• Protection type: The -p flag is used to set the protection type required with the security mechanism. Can be set to 'sig' or 'enc' to indicate signature or encryption. Defaults to signature.

Security: WS A&A: Delegation Service

Two command line clients are available as a part of this component:

• globus-credential-delegate
• globus-credential-refresh

globus-credential-delegate

Tool description

Used to contact delegation service and store a delegated credential. A delegated credential is created, stored in a delegation service and the Endpoint Referecne(EPR) of the credetial is written out to a file for further use.

Command syntax

globus-credential-delegate [options]

globus-credential-refresh

Tool description

Used to refresh delegated credentials pointed to be specified EPR. A new credential is generated and the one the delegation service is overwritten.

Command syntax

globus-credential-refresh [options]

Security: WS A&A: Message/Transport-level Security

This component has no command-line tools.

Security: Credential Management: MyProxy

• myproxy-init
• myproxy-info
• myproxy-get-delegation
• myproxy-destroy
• myproxy-change-pass-phrase
• myproxy-admin-adduser
• myproxy-admin-change-pass
• myproxy-admin-query
• myproxy-admin-load-credential
• myproxy-server

myproxy-init

Tool description

The myproxy-init command uploads a credential to a myproxy-server for later retrieval. In the default mode, the command first prompts for the user's Grid pass phrase (if needed), which is used to create a proxy credential. The command then prompts for a MyProxy pass phrase, which will be required to later retrieve the credential. The MyProxy pass phrase must be entered a second time for confirmation. A credential with a lifetime of one week (by default) is then delegated to the myproxy-server and stored with the given MyProxy pass phrase. Proxy credentials with default lifetime of 12 hours can then be retrieved by myproxy-get-delegation using the MyProxy passphrase. The default behavior can be overridden by options specified below.

The myproxy-init command can also upload a credential to a myproxy-server to support credential renewal. Renewal allows a trusted service (for example, a batch job scheduler) to obtain a new credential for a user before the existing credential it has for that user expires. The -R argument to myproxy-init configures the credential for renewal by the specified service. Renewal requires two authentications. The renewing service must authenticate with its own credentials, matching the distinquished name specified by the -R argument, and must also authenticate with an existing credential that matches the distinguished name of the stored credential, to retrieve a new credential.

A credential may be used either for retrieval or renewal but not both. If both are desired, upload a different credential for each use, with a different name using the -k option.

The hostname where the myproxy-server is running must be specified by either defining the MYPROXY_SERVER environment variable or the -s option.

Command syntax

myproxy-init [ options ]

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s hostname, --pshost hostname

Specifies the hostname of the myproxy-server. This option is required if the MYPROXY_SERVER environment variable is not defined. If specified, this option overrides the MYPROXY_SERVER environment variable.

-p port, --psport port

Specifies the TCP port number of the myproxy-server. Default: 7512

-l, --username

Specifies the MyProxy account under which the credential should be stored. By default, the command uses the value of the LOGNAME environment variable. Use this option to specify a different account username on the MyProxy server. The MyProxy username need not correspond to a real Unix username.

-c hours, --cred_lifetime hours

Specifies the lifetime of the credential stored on the myproxy-server in hours. Specify 0 for the maximum possible life- time, i.e., the lifetime of the original credential. Default: 1 week (168 hours)

-t hours, --proxy_lifetime hours

Specifies the maximum lifetime of credentials retrieved from the myproxy-server using the stored credential. Default: 12 hours

-d, --dn_as_username

Use the certificate subject (DN) as the default username, instead of the LOGNAME environment variable.

-a, --allow_anonymous_retrievers

Allow credentials to be retrieved with just pass phrase authen- tication. By default, only entities with credentials that match the myproxy-server.config default retriever policy may retrieve credentials. This option allows entities without existing credentials to retrieve a credential using pass phrase authentication by including "anonymous" in the set of allowed retrievers. The myproxy-server.config server-wide policy must also allow "anonymous" clients for this option to have an effect.

-A, --allow_anonymous_renewers

Allow credentials to be renewed by any client. Any client with a valid credential with a subject name that matches the stored credential may retrieve a new credential from the MyProxy repos- itory if this option is given. Since this effectively defeats the purpose of proxy credential lifetimes, it is not recom- mended. It is included only for sake of completeness.

-r dn, --retrievable_by dn

Allow the specified entity to retrieve credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "Jim Basney"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=Jim Basney") instead.

-R dn, --renewable_by dn

Allow the specified entity to renew credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "condorg/modi4.ncsa.uiuc.edu"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=condorg/modi4.ncsa.uiuc.edu") instead. This option implies -n since passphrase authentication is not used for cre- dential renewal.

-x, --regex_dn_match

Specifies that the DN used by options -r and -R will be matched as a regular expression.

-X, --match_cn_only

Specifies that the DN used by options -r and -R will be matched against the Common Name (CN) of the subject.

-k name, --credname name

Specifies the credential name.

-K description

--creddesc description

Specifies credential description.

-S, --stdin_pass

By default, the command prompts for a passphrase and reads the passphrase from the active tty. When running the command non- interactively, there may be no associated tty. Specifying this option tells the command to read passphrases from standard input without prompts or confirmation.

myproxy-info

Tool description

The myproxy-info command displays information about a user's creden- tials stored on a myproxy-server. The user must have a valid proxy credential as generated by grid-proxy-init or retrieved by myproxy-get-delegation when running this command.

Command syntax

myproxy-info [ options ]

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s hostname, --pshost hostname

Specifies the hostname of the myproxy-server. This option is required if the MYPROXY_SERVER environment variable is not defined. If specified, this option overrides the MYPROXY_SERVER environment variable.

-p port, --psport port

Specifies the TCP port number of the myproxy-server. Default: 7512

-l name, --username name

Specifies the MyProxy account to query. By default, the command uses the value of the LOGNAME environment variable. Use this option to specify a different account username on the MyProxy server. The MyProxy username need not correspond to a real Unix username.

-d, --dn_as_username

Use the certificate subject (DN) as the default username, instead of the LOGNAME environment variable.

myproxy-get-delegation

Tool description

The myproxy-get-delegation command retrieves a credential from the myproxy-server that was previously stored using myproxy-init. In the default mode, the command prompts for the MyProxy pass phrase asso- ciated with the credential to be retrieved and stores the retrieved credential in the standard location ( /tmp/x509up_u<uid> ).

Command syntax

myproxy-get-delegation [ options ]

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s hostname, --pshost hostname

Specifies the hostname of the myproxy-server. This option is required if the MYPROXY_SERVER environment variable is not defined. If specified, this option overrides the MYPROXY_SERVER environment variable.

-p port, --psport port

Specifies the TCP port number of the myproxy-server. Default: 7512

-l, --username

Specifies the MyProxy account under which the credential to retrieve is stored. By default, the command uses the value of the LOGNAME environment variable. Use this option to specify a different account username on the MyProxy server. The MyProxy username need not correspond to a real Unix username.

-d, --dn_as_username

Use the certificate subject (DN) as the default username, instead of the LOGNAME environment variable. When used with the -a option, the certificate subject of the authorization creden- tial is used. Otherwise, the certificate subject of the default credential is used.

-t hours, --proxy_lifetime hours

Specifies the lifetime of credentials retrieved from the myproxy-server using the stored credential. The resulting lifetime is the shorter of the requested lifetime and the life- time specified when the credential was stored using myproxy-init. Default: 12 hours

-o file, --out file

Specifies where the retrieved proxy credential should be stored. If this option is not specified, the proxy credential will be stored in the default location (/tmp/x509up_u<uid>).

-a file, --authorization file

Specifies a credential to be used for authorizing the request instead of a passphrase. When renewing a credential, use this option to specify the existing, valid credential that you want to renew. Renewing a credential generally requires two certifi- cate-based authentications. The client authenticates with its identity, using the credential in the standard location or spec- ified by X509_USER_PROXY or X509_USER_CERT and X509_USER_KEY in addition to authenticating with the existing credential, in the location specified by this option, that it wants to renew.

-k name, --credname name

Specifies the name of the credential that is to be retrieved or renewed.

-S, --stdin_pass

By default, the command prompts for a passphrase and reads the passphrase from the active tty. When running the command non- interactively, there may be no associated tty. Specifying this option tells the command to read passphrases from standard input without prompts or confirmation.

myproxy-destroy

Tool description

The myproxy-destroy command removes a credential from the myproxy-server that was previously stored using myproxy-init. The user must have a valid proxy credential as generated by grid-proxy-init or retrieved by myproxy-get-delegation when running this command.

Command syntax

myproxy-destroy [ options ] 

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s hostname, --pshost hostname

Specifies the hostname of the myproxy-server. This option is required if the MYPROXY_SERVER environment variable is not defined. If specified, this option overrides the MYPROXY_SERVER environment variable.

-p port, --psport port

Specifies the TCP port number of the myproxy-server. Default: 7512

-l, --username

Specifies the MyProxy account under which the credential to destroy is stored. By default, the command uses the value of the LOGNAME environment variable. Use this option to specify a different account username on the MyProxy server. The MyProxy username need not correspond to a real Unix username.

-d, --dn_as_username

Use the certificate subject (DN) as the default username, instead of the LOGNAME environment variable.

-k name, --credname name

Specifies name of the credential to be destroyed.

myproxy-change-pass-phrase

Tool description

The myproxy-change-pass-phrase command changes the passphrase under which a credential is protected in the MyProxy repository. The command first prompts for the current passphrase for the credential, then prompts twice for the new passphrase. Only the credential owner can change a credential's passphrase. The user must have a valid proxy credential as generated by grid-proxy-init or retrieved by myproxy-get-delegation when running this command.

Command syntax

myproxy-change-pass-phrase [ options ] 

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s hostname, --pshost hostname

Specifies the hostname of the myproxy-server. This option is required if the MYPROXY_SERVER environment variable is not defined. If specified, this option overrides the MYPROXY_SERVER environment variable.

-p port, --psport port

Specifies the TCP port number of the myproxy-server. Default: 7512

-l, --username

Specifies the MyProxy account under which the credential should be stored. By default, the command uses the value of the LOG-NAME environment variable. Use this option to specify a differ- ent account username on the MyProxy server. The MyProxy user- name need not correspond to a real Unix username.

-d, --dn_as_username

Use the certificate subject (DN) as the default username, instead of the LOGNAME environment variable.

-k name, --credname name

Specifies the credential name.

-S, --stdin_pass

By default, the command prompts for a passphrase and reads the passphrase from the active tty. When running the command non- interactively, there may be no associated tty. Specifying this option tells the command to read passphrases from standard input without prompts or confirmation.

myproxy-admin-adduser

Tool description

The myproxy-admin-adduser command creates a new credential for a user and loads it into the MyProxy repository. It is a perl script that runs grid-cert-request (a standard Globus Toolkit program) and grid-ca- sign (from the Globus Simple CA package) to create the credential and then runs myproxy-admin-load-credential to load the credential into the MyProxy repository. The command prompts for the common name to be included in the new cer- tificate (if the -c argument is not specified), the Globus Simple CA key password for signing the certificate, the MyProxy username (if the -l or -d arguments are not specified), and the MyProxy passphrase for the credential. Most of the command-line options for this command are passed directly to the myproxy-admin-load-credential command. The Globus Simple CA must be configured before using this command.

Command syntax

myproxy-admin-adduser [ options ] 

Command options

-h

Displays command usage text and exits.

-u

Displays command usage text and exits.

-c cn

Specifies the Common Name for the new credential (for example: "Jim Basney").

-s dir

Specifies the location of the credential storage directory. The directory must be accessible only by the user running the myproxy-server process for security reasons. Default: /var/myproxy or $GLOBUS_LOCATION/var/myproxy

-l username

Specifies the MyProxy account under which the credential should be stored.

-t hours

Specifies the maximum lifetime of credentials retrieved from the myproxy-server using the stored credential. Default: 12 hours

-n

Disables passphrase authentication for the stored credential. If specified, the command will not prompt for a passphrase, the credential will not be encrypted by a passphrase in the reposi- tory, and the credential will not be retrievable using passphrase authentication with myproxy-get-delegation. This option is used for storing renewable credentials and is implied by -R.

-d

Use the certificate subject (DN) as the username.

-a

Allow credentials to be retrieved with just pass phrase authen- tication. By default, only entities with credentials that match the myproxy-server.config default retriever policy may retrieve credentials. This option allows entities without existing credentials to retrieve a credential using pass phrase authentication by including "anonymous" in the set of allowed retrievers. The myproxy-server.config server-wide policy must also allow "anonymous" clients for this option to have an effect.

-A

Allow credentials to be renewed by any client. Any client with a valid credential with a subject name that matches the stored credential may retrieve a new credential from the MyProxy repos- itory if this option is given. Since this effectively defeats the purpose of proxy credential lifetimes, it is not recom- mended. It is included only for sake of completeness.

-r dn

Allow the specified entity to retrieve credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "Jim Basney"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=Jim Basney") instead.

-R dn

Allow the specified entity to renew credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "condorg/modi4.ncsa.uiuc.edu"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=condorg/modi4.ncsa.uiuc.edu") instead. This option implies -n since passphrase authentication is not used for cre- dential renewal.

-x

Specifies that the DN used by options -r and -R will be matched as a regular expression.

-X

Specifies that the DN used by options -r and -R will be matched against the Common Name (CN) of the subject.

-k name

Specifies the credential name.

-K description

Specifies credential description.

myproxy-admin-change-pass

Tool description

The myproxy-admin-change-pass command changes the passphrase used to encrypt a credential in the MyProxy repository. The command first prompts for the current passphrase for the credential, then prompts twice for the new passphrase. If an empty passphrase is given, the credential will not be encrypted. It accesses the repository directly and must be run on the machine where the myproxy-server is installed from the account that owns the repository.

Command syntax

myproxy-admin-change-pass [ options ] 

Command options

-h

Displays command usage text and exits.

-u

Displays command usage text and exits.

-s dir

Specifies the location of the credential storage directory. The directory must be accessible only by the user running the myproxy-server process for security reasons. Default: /var/myproxy or $GLOBUS_LOCATION/var/myproxy

-l username

Specifies the MyProxy account under which the credential should be stored.

-k name

Specifies the credential name.

-S, --stdin_pass

By default, the command prompts for a passphrase and reads the passphrase from the active tty. When running the command non- interactively, there may be no associated tty. Specifying this option tells the command to read passphrases from standard input without prompts or confirmation.

myproxy-admin-query

Tool description

The myproxy-admin-query command displays information about the creden- tials stored in the MyProxy repository. It can also be used to remove credentials from the repository. It accesses the repository directly and must be run on the machine where the myproxy-server is installed from the account that owns the repository.

Command syntax

myproxy-admin-query [ options ] 

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-l name, --username name

Return information on credentials for a single username. By default, the command returns information on all credentials for all usernames.

-k name, --credname name

Return information on the credentials with the specified name.

-e hours, --expiring_in hours

Return information on credentials with remaining lifetime less than the specified number of hours. For example, -e 0 will return all expired credentials.

-t hours, --time_left hours

Return information on credentials with remaining lifetime greater than the specified number of hours.

-s dir, --storage dir

Specifies the location of the credential storage directory. The directory must be accessible only by the user running the myproxy-server process for security reasons. Default: /var/myproxy or $GLOBUS_LOCATION/var/myproxy

-r, --remove

Remove the credentials matching the query from the repository. For example, myproxy-admin-query -e 0 -r will remove all expired credentials from the repository.

-L msg, --lock msg

Places the credentials matching the query under an administrative lock and specifies a message to be returned on access attempts.

-U, --unlock

Removes any administrative locks for the credentials matching the query.

myproxy-admin-load-credential

Tool description

The myproxy-admin-load-credential command stores a credential directly in the local MyProxy repository. It must be run from the account that owns the repository. Many of the options are similar to myproxy-init. However, unlike myproxy-init, myproxy-admin-load-credential does not create a proxy from the source credential but instead directly loads a copy of the source credential into the repository. The pass phrase of the source credential is unchanged. Use myproxy-admin-change-pass to change the pass phrase after the credential is stored if desired. Proxy credentials with default lifetime of 12 hours can then be retrieved by myproxy-get-delegation using the MyProxy passphrase. The command's behavior is controlled by the following options.

Command syntax

myproxy-admin-load-credential [ options ] 

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-s dir, --storage dir

Specifies the location of the credential storage directory. The directory must be accessible only by the user running the myproxy-server process for security reasons. Default: /var/myproxy or $GLOBUS_LOCATION/var/myproxy

-c filename, --certfile filename

Specifies the filename of the source certificate. This is a required parameter.

-y filename, --keyfile filename

Specifies the filename of the source private key. This is a required parameter.

-l username, --username username

Specifies the MyProxy account under which the credential should be stored. By default, the command uses the value of the LOGNAME environment variable. Use this option to specify a differ- ent account username on the MyProxy server. The MyProxy user- name need not correspond to a real Unix username.

-t hours, --proxy_lifetime hours

Specifies the maximum lifetime of credentials retrieved from the myproxy-server using the stored credential. Default: 12 hours

-d, --dn_as_username

Use the certificate subject (DN) as the username.

-a, --allow_anonymous_retrievers

Allow credentials to be retrieved with just pass phrase authentication. By default, only entities with credentials that match the myproxy-server.config default retriever policy may retrieve credentials. This option allows entities without existing credentials to retrieve a credential using pass phrase authentication by including "anonymous" in the set of allowed retrievers. The myproxy-server.config server-wide policy must also allow "anonymous" clients for this option to have an effect.

-A, --allow_anonymous_renewers

Allow credentials to be renewed by any client. Any client with a valid credential with a subject name that matches the stored credential may retrieve a new credential from the MyProxy repos- itory if this option is given. Since this effectively defeats the purpose of proxy credential lifetimes, it is not recom- mended. It is included only for sake of completeness.

-r dn, --retrievable_by dn

Allow the specified entity to retrieve credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "Jim Basney"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=Jim Basney") instead.

-R dn, --renewable_by dn

Allow the specified entity to renew credentials. By default, the argument will be matched against the common name (CN) of the client (for example: "condorg/modi4.ncsa.uiuc.edu"). Specify -x before this option to match against the full distinguished name (DN) (for example: "/C=US/O=National Computational Science Alliance/CN=condorg/modi4.ncsa.uiuc.edu") instead.

-x, --regex_dn_match

Specifies that the DN used by options -r and -R will be matched as a regular expression.

-X, --match_cn_only

Specifies that the DN used by options -r and -R will be matched against the Common Name (CN) of the subject.

-k name, --credname name

Specifies the credential name.

-K description, --creddesc description

Specifies credential description.

myproxy-server

Tool description

The myproxy-server is a server that runs on a trusted, secure host and manages a database of security credentials for use from remote sites. The myproxy-init program stores credentials with associated policies that specify credential lifetimes and who is authorized to retrieve credentials. The myproxy-server.config file sets server-wide policies that are used in conjunction with the policies set by myproxy-init to control who is authorized to store and retrieve credentials.

Command syntax

myproxy-server [ options ]

Command options

-h, --help

Displays command usage text and exits.

-u, --usage

Displays command usage text and exits.

-v, --verbose

Enables verbose debugging output to the terminal.

-V, --version

Displays version information and exits.

-d, --debug

Run the server in debug mode. In this mode, the server will run in the foreground, will accept one connection, write log mes- sages to the terminal while processing the incoming request, and exit after completing one request.

-p port, --port port

Specifies the TCP port number that the myproxy-server should listen on. Default: 7512

-c file, --config file

Specifies the location of the myproxy-server configuration file. Default: /etc/myproxy-server.config or $GLOBUS_LOCA- TION/etc/myproxy-server.config

-s dir, --storage dir

Specifies the location of the credential storage directory. The directory must be accessible only by the user running the myproxy-server process for security reasons. Default: /var/myproxy or $GLOBUS_LOCATION/var/myproxy

Security: Credential Management: SimpleCA

• grid-ca-sign

grid-ca-sign

Tool description

Command syntax

[list and describe command-line args here]

Limitations

[describe limitations of the tool here]

Security: Utilities: GSI-OpenSSH

The gsissh, gsiscp, and gsisftp commands provide the same interfaces as the standard OpenSSH ssh, scp, and sftp commands, respectively, with the added ability to perform X.509 proxy credential authentication and delegation.

gsissh

Tool description

Use the gsissh command to securely login to a remote machine.

Command syntax

gsissh [-l login_name] hostname | user@hostname [command]

gsiscp

Tool description

Use the gsiscp command to securely copy files to or from a remote machine.

Command syntax

gsiscp [-P port] [[user@]host1:]file1 [...] [[user@]host2:]destfile

gsisftp

Tool description

The gsisftp command provides an interactive interface for transferring files to and from remote machines.

Command syntax

gsisftp [[user@]host[:dir[/]]]

Security: Pre-WS A&A

• grid-cert-info
• grid-cert-request
• grid-default-ca
• grid-change-pass-phrase
• grid-proxy-init
• grid-proxy-destroy
• grid-proxy-info
• grid-mapfile-add-entry
• grid-mapfile-check-consistency
• grid-mapfile-delete-entry

grid-cert-info

Tool description

grid-cert-info displays information contained in a X.509 certificate.

Command syntax

grid-cert-info [-help] [-file certfile] [-all] [-subject] [...]

Displays certificate information. Unless the optional -file argument is given, the default location of the file containing the certficate is assumed:

• The location pointed to by the X509_USER_CERT.
• If X509_USER_CERT not set, /home/meder/.globus/usercert.pem.

Several options can be given. The output of

grid-cert-info -subject -issuer

is equivalent to that of

grid-cert-info -subject ; grid-cert-info -issuer

Options

General options:

-help, -usage

Display usage

-version

Display version

-file certfile |-f

Use 'certfile' at non-default location

Options determining what to print from certificate:

-all

Whole certificate

-subject |-s

Subject string of the cert

-issuer |-i

Issuer

-startdate  |-sd

Validity of cert: start date

-enddate |-ed

Validity of cert: end date

Limitations

Nothing applicable

grid-cert-request

Tool description

grid-cert-request generates a X.509 certificate request.

Command syntax

grid-cert-request [-help] [ options ...]

Example Usage:

Creating a user certificate:

 grid-cert-request

Creating a host or gatekeeper certifcate:

 grid-cert-request -host [my.host.fqdn]

Creating a LDAP server certificate:

 grid-cert-request -service ldap -host [my.host.fqdn]

Options:

-version

Display version

-?, -h, -help

Display help.

-usage

Display usage

-cn <name>, -commonname <name>

Common name of the user

-service <service>

Create certificate for a service. Requires the -host option and implies that the generated key will not be password protected (ie implies -nopw).

-host <FQDN>

Create certificate for a host named <FQDN>

-dir <dir_name>

Changes the directory the private key and certificate request will be placed in. By default user certificates are placed in home/meder/.globus, host certificates are placed in /etc/grid-security and service certificates are place in /etc/grid-security/<service>.

-prefix <prefix>

Causes the generated files to be named <prefix>cert.pem, <prefix>key.pem and <prefix>cert_request.pem

-nopw, -nodes, -nopassphrase

Create certificate without a passwd

-verbose

Don't clear the screen

-int[eractive]

Prompt user for each component of the DN

-force

Overwrites preexisting certificates

-ca

Will ask which CA is to be used (interactive)

-ca <hash>

Will use the CA with hash value <hash>

Limitations

Nothing applicable

grid-default-ca

Tool description

grid-default-ca allows the setting of the default CA to be used by tools such as grid-cert-request.

Command syntax

grid-default-ca [-help] [ options ...]

Options:

-help

Display this message.

-dir <dir_name>

The security config directory (defaults to /etc/grid-security/).

-list

List the available CAs to use and the current default.

-ca <ca hash>

Set the default CA non-interactively.

Limitations

Nothing applicable

grid-change-pass-phrase

Tool description

grid-change-pass-phrase allows one to change the passphrase that protects the private key.

Command syntax

grid-change-pass-phrase [-help] [-version] [-file private_key_file]

Changes the passphrase that protects the private key. Note that this command will work even if the original key is not password protected. If the -file argument is not given, the default location of the file containing the private key is assumed:

• The location pointed to by X509_USER_KEY
• If X509_USER_KEY not set, /home/meder/.globus/userkey.pem

Options

help, -usage

Displays usage

-version

Displays version

-file location

Change passphrase on key stored in the file at the non-standard location 'location'.

Limitations

Nothing applicable

grid-proxy-init

Tool description

grid-proxy-init generates X.509 proxy certificates.

Command syntax

 grid-proxy-init [-help][-pwstdin][-limited][-valid H:M] ...

Options

-help, -usage

Displays usage.

-version

Displays version.

-debug

Enables extra debug output.

-q

Quiet mode, minimal output.

-verify

Verifies certificate to make proxy for.

-pwstdin

Allows passphrase from stdin.

-limited

Creates a limited globus proxy.

-independent

Creates a independent globus proxy.

-old

Creates a legacy globus proxy.

-valid <h:m>

Proxy is valid for h hours and m minutes (default:12:00).

-hours <hours>

Deprecated support of hours option.

-bits  <bits>

Number of bits in key {512|1024|2048|4096}

-policy <policyfile>

File containing policy to store in the ProxyCertInfo extension.

-pl <oid>, -policy-language <oid>

OID string for the policy language used in the policy file.

-path-length <l>

Allow a chain of at most l proxies to be generated from this one.

-cert <certfile>

Non-standard location of user certificate.

-key <keyfile>

Non-standard location of user key.

-certdir <certdir>

Non-standard location of trusted cert directory.

-out <proxyfile>

Non-standard location of new proxy cert.

Limitations

Nothing applicable

grid-proxy-destroy

Tool description

grid-proxy-destroy removes X.509 proxy certificates.

Command syntax

grid-proxy-destroy [-help][-dryrun][-default][-all][--] [file1...]

Options

-help, -usage

Displays usage.

-version

Displays version.

-debug

Display debugging information.

-dryrun

Prints what files would have been destroyed.

-default

Destroys file at default proxy location.

-all

Destroys any user (default) and delegated proxies that are found.

--

Ends processing of options.

file1 file2 ...

Destroys files listed.

Limitations

Nothing applicable

grid-proxy-info

Tool description

grid-proxy-info extracts information from X.509 proxy certificates.

Command syntax

grid-proxy-info [-help][-f proxyfile][-subject][...][-e [-h H][-b B]]

Options

-help, -usage

Displays usage.

-version

Displays version.

-debug

Displays debugging output.

-file <proxyfile> (-f)

Non-standard location of proxy.

[printoptions]

Use the following options to print information about proxy:

-subject (-s)

Distinguished name (DN) of subject.

-issuer (-i)

DN of issuer (certificate signer).

-identity

DN of the identity represented by the proxy.

-type

Type of proxy (full or limited).

-timeleft

Time (in seconds) until proxy expires.

-strength

Key size (in bits).

-all

All above options in a human readable format.

-text

All of the certificate.

-path

Pathname of proxy file.

-exists [options] (-e)

Returns 0 if valid proxy exists, 1 otherwise. If none of the following options are given, H = B = 0 are assumed:

-valid H:M (-v)

Time requirement for proxy to be valid.

-hours H (-h)

Time requirement for proxy to be valid (deprecated, use -valid instead).

-bits B (-b)

Strength requirement for proxy to be valid.

Limitations

Nothing applicable

grid-mapfile-add-entry

Tool description

grid-mapfile-add-entry adds entries to grid mapfiles.

Command syntax

grid-mapfile-add-entry -dn DN -ln LN  [-help] [-d] [-f mapfile FILE]

Options:

-help, -usage

Displays help.

-version

Displays version.

-dn DN

Distinguished Name (DN) to add. Remember to quote the DN if it contains spaces.

-ln LN1 [LN2...]

Local login name(s) to which the DN is mapped.

-dryrun, -d

Shows what would be done but will not add the entry.

-mapfile FILE, -f FILE

Path of Grid map file to be used.

Limitations

Nothing applicable.

grid-mapfile-check-consistency

Tool description

grid-mapfile-check-consistency checks that the given grid mapfile conforms to the expected format as well as checking for common subject name problems.

Command syntax

grid-mapfile-check-consistency [-help] [-mapfile FILE]

Options:

-help, -usage

Displays help.

-version

Displays version.

-mapfile FILE, -f FILE

Path of gridmap to be used.

Limitations

Nothing applicable

grid-mapfile-delete-entry

Tool description

grid-mapfile-delete entry deletes a grid mapfile entry from the given file.

Command syntax

grid-mapfile-delete-entry [-help] [-dn <DN>] [-ln <local name>] [-d] [-f file]

Options:

-help, -usage

Displays help.

-version

Displays version.

-dn <DN>

Distinguished Name (DN) to delete.

-ln <local name>

Local Login Name (LN) to delete.

-dryrun, -d

Shows what would be done but will not delete the entry.

-mapfile file, -f file

Path of gridmap file to be used.

Limitations

Nothing applicable.

Data Management: GridFTP

globus-url-copy for GridFTP

Tool description

globus-url-copy is a scriptable, command line tool, that can do multi-protocol data movement. It supports gsiftp:// (GridFTP), ftp://, http://, https://, and file:/// protocol specifiers in the URL. For GridFTP, globus-url-copy supports all implemented functionality. Versions from GT3.2 and later support file globbing and directory moves.

Before you begin

YOU MUST HAVE A CERTIFICATE TO USE globus-url-copy!

grid-proxy-init 

Command syntax

The basic syntax for globus-url-copy is:

globus-url-copy [optional command line switches] Source_URL Destination_URL 

where:

[optional command line switches]

<sourceURL>

<destURL>

Note: Any url specifying a directory must end with /

URL prefixes

As of GT 3.2, we support the following URL prefixes:

• file:// (on a local machine only)
• ftp://
• gsiftp://
• http://
• https://

By default, globus-url-copy is expecting the same kind of host certificates that globusrun expects from gatekeepers.

Note: We do not provide an interactive client similar to the generic FTP client provided with Linux.  See Interactive Client for information on an interactive client developed by NCSA / NMI / TeraGrid .

URL formats

URLs can be any valid URL as defined by RFC 1738 that have a protocol we support.  In general, they have the following format:

protocol://[host]:[port]/path 

For example:

gsiftp://myhost.mydomain.com:2812/data/foo.dat

http://myhost.mydomain.com/mywebpage/default.html

file:///foo.dat

file:/foo.dat

Note: For FTP URLs, it is legal to specify a user name and password in the URL as follows:

ftp://myname:mypassword@myhost.mydomain.com/foo.dat 

This is highly discouraged as you will be sending your username and password in plain text over the network.  For servers provided in the Globus Toolkit, username and password is not a permitted authentication method and so this format will result in an error.  The exception to this is anonymous FTP access (how does this work in globus-url-copy).

Command line options

• Informational
• Utility / Ease of use
• Reliability
• Performance
• Security-related

-help | -usage 

-version 

-versions 

-q | -quiet 

-vb | -verbose 

-dbg | -debugftp 

-a | -ascii 

-b | -binary

-f <filename>

<sourceURL> <destURL> 

-r | -recurse

-notpt | -no-third-party-transfers

-rst | -restart 

-rst-retries <retries>

-rst-interval <seconds>

-rst-timeout <seconds>

-tcp-bs <size> | -tcp-buffer-size <size>

-p <parallelism> | -parallel <parallelism>

-bs <block size> | -block-size <block size>

-s <subject> | -subject <subject>

-ss <subject> | -source-subject <subject>

-ds <subject> | -dest-subject <subject>

-nodcau | -no-data-channel-authentication

-dcsafe | -data-channel-safe

-dcpriv | -data-channel-private

Notes about globus-url-copy

1. A globus-url-copy using the gsiftp protocol, with no options (using all the defaults) will do a binary, stream mode (which implies no parallelism) transfer, with whatever the host default TCP buffer size is, <feel like there should be a verb here> encrypted and checksummed control channel, and authenticated data channel.
   
2. GridFTP (as well as normal FTP) defines multiple wire protocols, or MODES, for the data channel. 
   
   Most normal FTP servers only implement stream mode, i.e. the bytes flow in order over a single TCP connection.  GridFTP defaults to this mode so that it is compatible with normal FTP servers. 
   
   However, GridFTP has another MODE, called Extended Block Mode, or MODE E.  This mode sends the data over the data channel in blocks.  Each block consists of 8 bits of flags, a 64 bit integer indicating the offset from the start of the transfer, and a 64 bit integer indicating the length of the block in bytes, followed by a payload of length bytes.  Because the offset and length are provided, out of order arrival is acceptable, i..e, the 10th block could arrive before the 9th because you know explicitly where it belongs.  This allows us to use multiple TCP channels.  If you use the -p | -parallelism option, globus-url-copy automatically puts the servers into MODE E.
   
   Note: Putting -p 1 is not the same as no -p at all.  Both will use a single stream, but the default will use stream mode and -p 1 will use MODE E.
   
3. For more information on TCP buffer sizes and related information, try <here>.
   
4. If you run a GridFTP server by hand, you will need to explicitly specify the subject name to expect.  You can use the -ss flag to set the sourceURL subject, and -ds to set the destURL subject.  If you use -s alone, it will set both to be the same.  You can see an example of this usage under the Verification section of this guide.  Please note: This is the unusual case of using this client.  Most times you only need to specify both URLs.

Limitations

There are no limitations for globus-url-copy in GT 3.9.5.

Interactive clients for GridFTP

The Globus Project does not provide an interactive client for GridFTP.  Any normal FTP client will work with a GridFTP server, but it cannot take advantage of the advanced features of GridFTP.  The interactive clients listed below take advantage of the advanced features of GridFTP. 

There is no endorsement implied by their presence here.  We make no assertion as to the quality or approriateness of these tools, we simply provide this for your convenience.  We will not answer questions, accept bugs, or in any way shape or form be responsible for these tools, although they should have mechanisms of their own for such things.

UberFTP was developed at the NCSA under the auspices of NMI and TeraGrid.  It is available through NMI (a convenient place to get Globus and other tools as well, btw), or directly from NCSA:

• NMI Download: http://nsf-middleware.org/
• NCSA Uberftp only download: http://dims.ncsa.uiuc.edu/set/uberftp/download/index.html
• UberFTP User's Guide: http://teragrid.ncsa.uiuc.edu/Doc/Data/uberftp.html

Data Management: RFT

• rft
• rft-delete

Command line tool: rft for RFT transfers

Tool description

Submits a transfer to the Reliable File Transfer Service and prints out the status of the transfer on the console.

Command syntax and options

rft  [-h <host-ip of the container defaults to localhost> 
-port <port, defaults to 8080>
-l <lifetime for the resource default 60mins> 
-m <security mechanism. 'msg' for secure message or 'conv' for 
 secure conversation and 'trans' for transport. Defaults to 
   secure transport.>
-p <protection type, 'sig' signature and 'enc' encryption, 
 defaults to signature >
-z <authorization mechanism can be self or host. default self> 
-file <file to write EPR of created Reliable  File Transfer Resource]> 
-f <path to the file that contains list of transfers>

This is a sample transfer file that the command-line client will be able to parse. It can also be found in $GLOBUS_LOCATION/share/globus_wsrf_rft_client/ along with other samples for directory transfers and deletes (lines starting with # are comments):

#true=binary false=ascii
true
#Block size in bytes
16000
#TCP Buffer size in bytes
16000
#Notpt (No thirdPartyTransfer)
false
#Number of parallel streams
1
#Data Channel Authentication (DCAU)
true
# Concurrency of the request
1
#Grid Subject name of the source gridftp server
/DC=org/DC=doegrids/OU=People/CN=Ravi Madduri 134710
#Grid Subject name of the destination gridftp server
/DC=org/DC=doegrids/OU=People/CN=Ravi Madduri 134710
#Transfer all or none of the transfers
false
#Maximum number of retries
10
#Source/Dest URL Pairs
gsiftp://localhost:5678/tmp/rftTest.tmp
gsiftp://localhost:5678/tmp/rftTest_Done.tmp

Limitations

This command line client is very dumb and simple and does not do any intelligent parsing of various command line options and the options in the sample transfer file. It works fine if used in the way documented here.

Command-line tool: rft-delete for RFT deletes

Tool description

This command-line tool is used to submit a list of files to be deleted.

Command and options

rft-delete [-h <host-ip of the container default localhost> 
-port <port, defaults to 8080>
-l <lifetime for the resource default 60mins> 
-m <security mechanism. 'msg' for secure message or 'conv' for 
 secure conversation and 'trans' for transport. Defaults to 
   secure transport.>
-p <protection type, 'sig' signature and 'enc' encryption, 
 defaults to signature >
-z <authorization mechanism can be self or host. default self> 
-file <file to write EPR of created Reliable  File Transfer Resource]> 
-f <path to the file that contains list of transfers>

This is a sample file that the command line client will be able to parse, it can also be found in $GLOBUS_LOCATION/share/globus_wsrf_rft_client/ along with other samples for directory transfers and deletes (lines starting with # are comments):

# Subject name (defaults to host subject)
  /DC=org/DC=doegrids/OU=People/CN=Ravi Madduri 134710
  gsiftp://localhost:5678/tmp/rftTest_Done.tmp
  gsiftp://localhost:5678/tmp/rftTest_Done1.tmp

Limitations

No limitations with this commandline tool.

Data Management: RLS

Command line tools include the Server, Admin Tool, and Client Tool.

• RLS Server
• Admin Tool
• Client Tool

RLS Server (globus-rls-server)

The RLS server (globus-rls-server) can be configured as either or both of the following:

• Location Replica Catalog (LRC) server, which manages Logical FileName (LFN) to Physical FileName (PFN) mappings in a database.
  
  Note: If globus-rls-server is configured as an LRC server, the RLI servers that it sends updates to should be added to the database using globus-rls-admin.
  
• Replica Location Index (RLI) server, which manages mappings of LFNs to LRC servers.

Clients wishing to locate one or more physical filenames associated with a logical filename should first contact an RLI server, which will return a list of LRCs that may know about the LFN. The LRC servers are then contacted in turn to find the physical filenames.

Note: RLI information may be out of date, so clients should be prepared to get a negative response when contacting an LRC (or no response at all if the LRC server is unavailable.)

This page contains the following topics:

• Synopsis
• LRC to RLI updates
• Bloom filter updates
• Log messages
• Signals
• Options

Synopsis

[ -B lrc_update_bf ] [ -b maxbackoff ] [ -C rlscertfile ] [ -c conffile ] [ -d ] [ -e rli_expire_int ] [ -F lrc_update_factor ] [ -f maxfreethreads ] [ -I true|false [ -i idletimeout ] [ -K rlskeyfile ] [ -L loglevel ] [ -l true|false ] [ -M maxconnections ] [ -m maxthreads ] [ -N ] [ -o lrc_buffer_time ] [ -p pidfiledir ] [ -r true|false ] [ -S rli_expire_stale ] [ -s startthreads ] [ -t timeout ] [ -U myurl ] [ -u lrc_update_ll ] [ -v ]

LRC to RLI Updates

Two methods exist for LRC servers to inform RLI servers of their LFNs.

• By default, the LFNs are sent from the LRC to the RLI.
  
  This can be time consuming if the number of LFNs is large, but does give the RLI an exact list of the LFNs known to the LRC, and it allows wildcard searching of the RLI.
  
• Alternatively, Bloom filters may be sent, which are highly compressed summaries of the LFNs; however they do not allow wildcard searching, and they will generate more "false positives" when querying an RLI.

Please see below for more on Bloom filters.

globus-rls-admin can be used to manage the list of RLIs that an LRC server updates. This includes partitioning LFNs among multiple RLI servers.

A softstate algorithm is used in both update modes: periodically the LRC server sends its state (LFN information) to the RLI servers it updates.

The RLI servers add these LFNs to their index, or update a timestamp if the LFNs were already known. RLI servers expire information about LFN,LRC mappings if they haven't been updated for a period longer than the softstate update interval.

The following options in the Configuration file control the softstate algorithm when an LRC updates an RLI by sending LFNs:

• rli_expire_int (seconds)
• rli_expire_stale (seconds)
• lrc_update_ll (seconds)
• lrc_update_bf (seconds)

Updates to an LRC (new LFNs or deleted LFNs) normally don't propagate to RLI servers until the next softstate update (controlled by options lrc_update_ll and lrc_update_bf.

However, by enabling "immediate update" mode (set lrc_update_immediate to true), an LRC will send updates to an RLI within lrc_buffer_time seconds.

If updates are done with LFN lists, then only the LFNs that have been added or deleted to the LRC are sent. If Bloom filters are used, then the entire Bloom filter is sent.

When immediate updates are enabled, the interval between softstate updates is multiplied by lrc_update_factor as long as no updates have failed (LRC and RLI are considered to be in sync). This can greatly reduce the number of softstate updates an LRC needs to send to an RLI.

Incremental updates are buffered by the LRC server until either 200 updates have accumulated (when LFN lists are used), or lrc_buffer_time seconds have passed since the last update.

Bloom filter updates

A Bloom filter is an array of bits. Each LFN is hashed multiple times and the corresponding bits in the Bloom filter are set.

Querying an RLI to verify if an LFN exists is done by performing the same hashes, and checking if the bits in the filter are on. If not, then the LFN is known not to exist. If they're all on, then all that's known is that the LFN probably exists.

The size of the Bloom filter (as a multiple of the number of LFNs) and the number of hash functions, control the false positive rate. The default values of 10 and 3 give a false positive rate of approximately 1%.

The advantage of Bloom filters is their efficiency. For example, if the LRC has 1,000,000 LFNs in its database, with an average length of 20 bytes, then 20,000,000 bytes must be sent to an RLI during a softstate update (assuming no partitioning). The RLI server must perform 1,000,000 updates to its database to create new LFN,LRC mappings, or update timestamps on existing entries. With Bloom filters, only 1,250,000 bytes are sent (10 x 1,000,000 bits / 8), and there are no database operations on the RLI (Bloom filters are maintained entirely in memory). A comparison of the time to perform a 1,000,000 LFN update took 20 minutes sending all the LFNs, and less than 1 second using a Bloom filter. However as noted before, Bloom filters do not support wild card searches of an RLI.

Note: An LRC server can update some RLIs with Bloom filters, and others with LFNs. However an RLI server can only be updated using one method.

The following options in the Configuration file control Bloom filter updates:

• rli_bloomfilter true|false
• rli_bloomfilter_dir none|default|pathname
• lrc_bloomfilter_numhash N
• lrc_bloomfilter_ratio N
• lrc_update_bf seconds

Log messages

globus-rls-server uses syslog to log errors and other information (facility LOG_DAEMON) when it's running in normal (daemon) mode.

If the -d option (debug) is specified, then log messages are written to stdout.

Signals

The server will reread its configuration file if it receives a HUP signal. It will wait for all current requests to complete and shut down cleanly if sent any of the following signals: INT, QUIT or TERM.

Options (globus-rls-server)

The following table describes the command line options available for globus-rls-server:

Admin Tool (globus-rls-admin) for RLS

The RLS Administration Tool (globus-rls-admin) performs administrative operations on a RLS server

• Synopsis
• Options

Synopsis

-A|-a|-C option value|-c option|-d|-e|-p|-q|-s|-t timeout|-u|-v [ rli ] [ pattern ] [ server ]

Options

Client Tool (globus-rls-cli) for RLS

The RLS Client Tool (globus-rls-cli) provides a command line interface to some of the functions supported by RLS. It also supports an interactive interface (if command is not specified). In interactive move double quotes may be used to encode an argument that contains white space.

• Synopsis
• Options
• Commands

Synopsis

command [ -c ] [ -h ] [ -l reslimit ] [ -s ] [ -t timeout ] [ -u ] [ command ] rls-server

Options

The client command tool uses getopt for command line parsing.

Note: Some versions will continue scanning for options (works that begin with a hyphen) for the entire command, line, which makes it impossible to specify negative integer or floating point value for an attribute. The workaround for this problem is to tell getopt() that there are no more options, by including 2 hyphens. For example, to specify the value -2 you must enter -- -2.

Commands

Information Services: WS MDS (MDS4): Index Service

• End-User tools
• wsrf-query
• wsrf-get-property
• wsrf-get-properties
• Administrative tools
• mds-servicegroup-add

End-user command line tools for WS MDS Index Service

The index service exposes information via service groups and is accessed using the same command-line tools used to query other WSRF services for information. These tools are documented in detail in the Java WS Core User's Guide.

• wsrf-query performs a query on a resource property document
• wsrf-get-property gets a single resource property
• wsrf-get-properties gets multiple resource properties.

Administrative command-line tools for WS MDS Index Service

mds-servicegroup-add

mds-servicegroup-add creates a set of registrations to a WS-ServiceGroup and periodically renews those registrations. It is intended primarily for registering grid resources to MDS services such as the index and trigger services.

Registrations are defined in an XML configuration file, which is documented in the Aggregator Framework System Administrator's Guide.

Command syntax

mds-servicegroup-add -s http://foo [options] config.xml

Options and Arguments

The syntax of the configuration file used by mds-servicegroup-add is described in detail in the MDS Index Public Interface Guide. In addition, the Globus Toolkit distribution includes an example configuration file $GLOBUS_LOCATION/etc/globus_wsrf_mds_aggregator/example-aggregator-registration.xml.

The simplest way to register services to an index is to edit the example file, replacing the EPRs in that file with the EPRs for your resources, and then to run mds-servicegroup-add to perform the registrations specified in that file.

Limitations

It is necessary for the tool to continue to run in order for the registrations that it maintains to be kept alive, as registrations will otherwise time out.

Information Services: WS MDS (MDS4): Trigger Service

The Trigger Service itself does not have any command-line clients for end users; instead, the trigger service is configured to run an executable program to take some action (for example, send mail to a set of users, or write a log entry to a file).

The mds-servicegroup-add command is used to configure the Trigger Service to collect information from various sources; see the Aggregator Framework documentation for more information.

Information Services: WS MDS (MDS4): Aggregator Framework

Command-line tool mds-servicegroup-add for WS MDS Aggregator

Tool description

mds-servicegroup-add creates a set of registrations to a WS-ServiceGroup and periodically renews those registrations. It is intended primarily for registering grid resources to MDS services such as the index and trigger services.

Registrations are defined in an XML configuration file, which is documented in the Aggregator Framework System Administrator's Guide.

Command syntax

mds-servicegroup-add -s http://foo [options] config.xml

Options and Arguments

The other standard toolkit options [TODO -- link to standard options page] are also supported.

Limitations

It is necessary for the tool to continue to run in order for the registrations that it maintains to be kept alive, as registrations will otherwise time out.

Information Services: Pre-WS MDS (MDS2)

See the existing information here.

Execution Management: WS GRAM

Job submission

• globusrun-ws (C version)
• managed-job-globusrun (Java version, DEPRECATED)

Execution Management: Pre-WS GRAM

See the existing information here.