When the credentials of the service account and the job submitter are different (multi user mode), then GRAM will prepend a call to sudo to the local adapter callout command. Important: If sudo is not configured properly, the command and thus job will fail.

As root, here are the two lines to add to the /etc/sudoers file for each GLOBUS_LOCATION installation, where /opt/globus/GT4.2.0 should be replaced with the GLOBUS LOCATION for your installation:

# Globus GRAM entries
globus  ALL=(username1,username2) 
NOPASSWD: /opt/globus/GT4.2.0/libexec/globus-gridmap-and-execute \
    -g /etc/grid-security/grid-mapfile \
    /opt/globus/GT4.2.0/libexec/globus-job-manager-script.pl *
globus  ALL=(username1,username2) 
NOPASSWD: /opt/globus/GT4.2.0/libexec/globus-gridmap-and-execute \
    -g /etc/grid-security/grid-mapfile \
    /opt/globus/GT4.2.0/libexec/globus-gram-local-proxy-tool *

The globus-gridmap-and-execute program is used to ensure that GRAM only runs programs under accounts that are in the grid-mapfile. In the sudo configuration, it is the first program called. It looks up the account in the grid-mapfile and then runs the requested command. It is redundant if sudo is properly locked down. This tool could be replaced with your own authorization program.

The GRAM4 scheduler adapters included in the release tarball are: PBS, Condor and LSF. To install, follow these steps (shown for pbs):

% configure --prefix=$GLOBUS_LOCATION --enable-wsgram-pbs ...
% make
% make install

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

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

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

The last thing is to define the GRAM and GridFTP file system mapping for PBS. A default mapping in this file is created to allow simple jobs to run. However, the actual file system mappings for your compute resource should be entered to ensure:

Done! You have added the PBS scheduler adapters to your GT installation.

To run the container using just a user proxy, instead of host creds, edit the $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml file, and either comment out the credentials section...

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
<!--
<credential>
<key-file value="/etc/grid-security/containerkey.pem"/>
<cert-file value="/etc/grid-security/containercert.pem"/>
<credential>
-->
<gridmap value="/etc/grid-security/grid-mapfile"/>
<securityConfig>

or replace the credentials section with a proxy file location...

<?xml version="1.0" encoding="UTF-8"?>
<securityConfig xmlns="http://www.globus.org">
<proxy-file value="<PATH TO PROXY FILE>"/>
<gridmap value="/etc/grid-security/grid-mapfile"/>
<securityConfig>

Running in personal mode (user proxy), another GRAM configuration setting is required. For GRAM to authorize the RFT service when performing staging functions, it needs to know the subject DN for verification. Here are the steps:

% cd $GLOBUS_LOCATION/setup/globus
% ./setup-gram-service-common --staging-subject=
"/DC=org/DC=doegrids/OU=People/CN=Stuart Martin 564720"

You can get your subject DN by running this command:

% grid-cert-info -subject
            

By default, the GridFTP server is assumed to run as root on localhost:2811. If this is not true for your site then change it by editing the GridFTP host and/or port in the GRAM and GridFTP file system mapping config file: $GLOBUS_LOCATION/etc/globus_wsrf_gram/globus_gram_fs_map_config.xml.

By default, the globus services will assume 8443 is the port the Globus container is using. However the container can be run under a non-standard port, for example:

% globus-start-container -p 4321

If you wish to specify a non-standard gridmap file in a multi-user installation, two basic configurations need to be changed:

Example: global_security_descriptor.xml

...
<gridmap value="/opt/grid-mapfile"/>
...

sudoers

...
# Globus GRAM entries
globus  ALL=(username1,username2) 
NOPASSWD: /opt/globus/GT4.2.0/libexec/globus-gridmap-and-execute \
    -g /opt/grid-mapfile \
    /opt/globus/GT4.2.0/libexec/globus-job-manager-script.pl *
globus  ALL=(username1,username2) 
NOPASSWD: /opt/globus/GT4.2.0/libexec/globus-gridmap-and-execute \
    -g /opt/grid-mapfile \
    /opt/globus/GT4.2.0/libexec/globus-gram-local-proxy-tool *...

RFT is used by GRAM to stage files in and out of the job execution environment. In the default configuration, RFT is hosted in the same container as GRAM and is assumed to have the same service path and standard service names. This need not be the case. For example, the most likely alternative scenario is that RFT would be hosted seperately in a container on a different machine. In any case, both the RFT and the Delegation Service endpoints need to be adjustable to allow this flexibility. The following options can be passed to the setup-gram-service-common script to affect these settings:

--staging-protocol=<protocol> \
--staging-host=<host> \
--staging-port=<port> \
--staging-service-path=<RFT and Delegation factory service path> \
--staging-factory-name=<RFT factory service name> \
--staging-delegation-factory-name=<name of Delegation factory service used by RFT>

For example:

    % setup-gram-service-common \
    --staging-protocol=https
    --staging-host=machine.domain.net
    --staging-delegation-factory-name=machine.domain.net
        

will internally cause the GRAM service code to construct the following EPR addresses.

http://machine.domain.net:8444/wsrf/services/ReliableFileTransferFactoryService
http://machine.fakedomain.net:8444/wsrf/services/DelegationFactoryService
        

	Important
	Jobs submitted by Condor-G will fail if RFT is not located in the same container as GRAM4, because Condor-G assumes that RFT is located in the same container like GRAM4.

Note that, by default, two authorization checks are done during an invocation of WS-GRAM:

The second gridmap check can be avoided by adding a system property to the environment variable GLOBUS_OPTIONS before starting the container:

export GLOBUS_OPTIONS="$GLOBUS_OPTIONS -Dorg.globus.exec.disablegge=true"

This however does not mean, that no authorization check at all is done. The container still checks if the client is authorized as defined in $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml but there's no further authorization check when calling the Perl modules. It's up to the GT4 container administrator to decide whether or not to have that additional authorization check. Note that a change in the sudo configuration is required in that case because globus-gridmap-and-execute will not be executed. /opt/globus/GT4.2.0 should be replaced with the value of $GLOBUS_LOCATION for your installation:

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

The configuration of WSRF resources and application-level service configuration not related to service deployment is contained in JNDI files. The JNDI-based GRAM configuration is of two kinds:

% ls etc | grep globus_wsrf_gram_

globus_wsrf_gram_Fork
globus_wsrf_gram_LSF
globus_wsrf_gram_Multi

<service name="ManagedJobFactoryService">
    <!-- LRM configuration:  Fork -->
    <resource
        name="ForkResourceConfiguration"
        type="org.globus.exec.service.factory.FactoryResourceConfiguration">
        <resourceParams>
            [...]
            <parameter>
                <name>
                    localResourceManagerName
                </name>
                <value>
                    Fork
                </value>
            </parameter>           
            <!-- Site-specific scratchDir
                    Default: ${GLOBUS_USER_HOME}/.globus/scratch
            <parameter>
                <name>
                    scratchDirectory
                </name>
                <value>
                    ${GLOBUS_USER_HOME}.globus/scratch
                </value>
            </parameter>           
            -->
        </resourceParams>
    </resource>
</service>

The file $GLOBUS_LOCATION/etc/globus_wsrf_gram/managed-job-factory-security-config.xml contains the Core security configuration for the GRAM ManagedJobFactory service:

The file $GLOBUS_LOCATION/etc/globus_wsrf_gram/managed-job-security-config.xml contains the Core security configuration for the GRAM job resources:

Note: GRAM does not override the container security credentials defined in $GLOBUS_LOCATION/etc/globus_wsrf_core/global_security_descriptor.xml. These are the credentials used to authenticate all service requests.

The file $GLOBUS_LOCATION/etc/globus_wsrf_gram/server-config.wsdd contains information necessary to deploy and instantiate the GRAM services in the Globus container.

Three GRAM services are deployed:

Each service deployment information contains the name of the Java service implementation class, the path to the WSDL service file, the name of the operation providers that the service reuses for its implementation of WSDL-defined operations, etc. More information about the service deployment configuration information can be found in Configuring Java WS Core.

In addition to the service configuration described above, there are scheduler-specific configuration files for the Scheduler Event Generator modules. These files consist of name=value pairs separated by newlines. These files are:

With a default GT 4.2.0 installation, the GRAM4 service is automatically registered with the default WS MDS Index Service running in the same container for monitoring and discovery purposes.

This is how auto-registration is configured:

There is a jndi resource defined in $GLOBUS_LOCATION/etc/globus_wsrf_gram/jndi-config.xml as follows :

 <resource name="mdsConfiguration"
    type="org.globus.wsrf.impl.servicegroup.client.MDSConfiguration">
    <resourceParams>
    <parameter> 
    <name>reg</name>
    <value>true</value>
    </parameter>
    <parameter> 
    <name>factory</name>
    <value>org.globus.wsrf.jndi.BeanFactory</value>
    </parameter>
    </resourceParams>
</resource>

To configure the automatic registration of GRAM4 to the default WS MDS Index Service, change the value of the parameter <reg> as follows:

<Content xsi:type="agg:AggregatorContent"
    xmlns:agg="http://mds.globus.org/aggregator/types">        
    <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
        <agg:GetResourcePropertyPollType
            xmlns:glue="http://mds.globus.org/glue/ce/1.1">
            <!-- Specifies that the index should refresh information
                    every 60000 milliseconds (once per minute) -->
            <agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
            <!-- specifies the resource property that should be
                    aggregated, which in this case is the GLUE cluster
                    and scheduler information RP -->
            <agg:ResourcePropertyName>glue:GLUECE</agg:ResourcePropertyName>  
        </agg:GetResourcePropertyPollType>
    </agg:AggregatorConfig> 
    <agg:AggregatorData/>
</Content>

If a third party needs to register an GRAM4 service manually, see Registering with mds-servicegroup-add in the WS MDS Aggregator Framework documentation.