naregi middleware ss · administrator’s guide naregi middleware ss user’s guide group ¾...

Administrator's Guide

NAREGI Middleware SS

(Super Scheduler)

October, 2008

National Institute of Informatics

Administrator’s Guide NAREGI Middleware SS

Documents List

◆ Administrator’s Guide Group Administrator’s Guide, NAREGI Middleware

IS(Distributed Information Service) Administrator’s Guide, NAREGI Middleware

IS(Distributed Information Service) - LRPSConfig - Administrator’s Guide, NAREGI Middleware SS(Super Scheduler) Administrator’s Guide, NAREGI Middleware

GridVM(Grid Virtual Machine) Administrator’s Guide, NAREGI Middleware Portal Administrator’s Guide, NAREGI Middleware

PSE(Problem Solving Environment) Administrator’s Guide, NAREGI Middleware

WFT(GUI Workflow Tool) Administrator’s Guide, NAREGI Middleware

GVS (Grid Visualization System) Administrator’s Guide, NAREGI Middleware DataGrid Administrator’s Guide, NAREGI Middleware CA(Certification Authority) Administrator’s Guide, NAREGI Middleware

UMS(User Management Server) Administrator’s Guide, NAREGI Middleware Authorization Service Administrator’s Guide, NAREGI Middleware Renewal Service Administrator’s Guide, NAREGI Middleware

SBC(Synchronous Data Transfer Library) Administrator’s Guide, NAREGI Middleware Mediator

i


◆ User’s Guide Group User’s Guide, NAREGI Middleware IS(Distributed Information Service) User’s Guide, NAREGI Middleware Portal User’s Guide, NAREGI Middleware PSE(Problem Solving Environment) User’s Guide, NAREGI Middleware

PSE(Problem Solving Environment) - Command line Interface - User’s Guide, NAREGI Middleware WFT(GUI Workflow Tool) Programming Guide, NAREGI Middleware WFT(GUI Workflow Tool) User’s Guide, NAREGI Middleware

GVS(Grid Visualization System) - Client Module - User’s Guide, NAREGI Middleware

GVS(Grid Visualization System) - Parallel Visualization Module - User’s Guide, NAREGI Middleware CA(Certification Authority) User’s Guide, NAREGI Middleware UMS(User Management Server) User’s Guide, NAREGI Middleware Authorization Service User’s Guide, NAREGI Middleware Renewal Service User’s Guide, NAREGI Middleware

SBC (Synchronous Data Transfer Library) User’s Guide, NAREGI Middleware Mediator

This file or a portion of this file is licensed under the terms of the NAREGI Public License, found at

http://www.naregi.org/download/. If you redistribute this file, with or without modifications, you must

include this notice in the file.

Copyright© 2004-2008 National Institute of Informatics, Japan. All rights reserved.

ii

http://www.naregi.org/download/


Table of Contents

1. Introduction ........................................................................................................... 1 1.1. Overview of Instruction.................................................................................. 1

1.1.1. SS Glossary............................................................................................................ 1 1.1.2. SuperScheduler Components ............................................................................... 2

1.2. System Architecture Summary ...................................................................... 3 1.2.1. Single SS System Architecture............................................................................. 3 1.2.2. Multiple SS System Architecture (Centralized RCS model) .............................. 4 1.2.3. Multiple SS System Architecture ( Distributed RCS model) (NOT Supported

Currently) ............................................................................................................................. 5 1.2.4. Exampled of mixed Local Scheduler .................................................................... 6

1.3. Product Requirements.................................................................................... 8 1.3.1. Hardware requirement ......................................................................................... 8 1.3.2. Software Requirement .......................................................................................... 8

2. SuperScheduler Installation.................................................................................10 2.1. Installation User ...........................................................................................10 2.2. Before Installation.........................................................................................10

2.2.1. Create Install Directory...................................................................................... 10 2.2.2. Configuration of Environment Variables........................................................... 10

2.3. Installation Procedure...................................................................................11 2.3.1. SS Server Installation Procedure....................................................................... 11 2.3.2. SS Client Installation Procedure ....................................................................... 13

2.4. Coping process if installer failed. ..................................................................14 3. Configuration SuperScheduler .............................................................................15

3.1. Setup User .....................................................................................................15 3.2. Configuration Environment Variables ..........................................................15 3.3. Create and Edit Configuration Files.............................................................16

3.3.1. Create gridss-global.env file. .............................................................................. 16 3.3.2. Configuration Multiple SS.................................................................................. 18 3.3.3. Create gridss-local.env File ................................................................................ 19

3.4. Edit Constitutive Configuration File ............................................................21 3.4.1. Edit gridss.conf.in.mod ....................................................................................... 22 3.4.2. Edit config-ssls.xml.in......................................................................................... 24

3.5. Execute gridss-mkconf ..................................................................................24

iii


3.6. Tune System Parameter................................................................................26 3.6.1. Configure Max number of enable open files...................................................... 26 3.6.2. Configure Max Length of Socket Queue Waiting For Connection ................... 27

3.7. Configuration To Use Naregi Distributed Information Service....................28 3.7.1. Check Accessing Data Base ................................................................................ 29 3.7.2. Preparation for using IS Access Tool ................................................................. 29 3.7.3. Aggregate Resource Information by IS Access Tool .......................................... 30 3.7.4. Delete Aggregated Resource Information by IS Access Tool ............................ 32

3.8. Configure Workflow Tracking Function........................................................33 3.8.1. Configure Log Directory ..................................................................................... 33 3.8.2. Generate LRPS’s EPR......................................................................................... 34 3.8.3. Configure LRPS’s grid-mapfile........................................................................... 35 3.8.4. JLOGD Logrotation ............................................................................................ 35

3.9. Configure Service Status Notification Function ...........................................36 3.9.1. Generate LRPS’s EPR......................................................................................... 36 3.9.2. Configure LRPS’s grid-mapfile........................................................................... 36 3.9.3. SS-Statd Logrotation .......................................................................................... 37

3.10. Configuration To Run GridMPI Job ..............................................................37 3.11. How to set Computing Resource where IMPI-SERVER runs.......................37

3.11.1. Procedure To Edit Configuration File................................................................ 38 3.11.2. Configuration Parameter and Environment Variable ...................................... 38 3.11.3. Example of config-wwm3.xml.in.mod(1)............................................................ 41

3.12. Configure restriction to receive jobs by the number of activities .................42 3.12.1. Procedure To Edit Configuration File ...........................................................43 3.12.2. Setting parameter .........................................................................................43 3.12.3. Example of config-wwm3.xml.in.mod (2) ......................................................43 3.13. Configuration for Long Running Job. ...........................................................44 3.14. Configure start-up script...............................................................................45 3.15. How To Configure Logrotation ......................................................................45

3.15.1. Configuration File ............................................................................................... 45 3.15.2. Configure gridss-logrotate .................................................................................. 46 3.15.3. Configure gridss-logrotate .................................................................................. 46 3.15.4. How To Restart SS Server .................................................................................. 48 3.15.5. How to check logrotation .................................................................................... 48 3.15.6. Notanda ............................................................................................................... 48 3.15.7. Reference ............................................................................................................. 49

iv


3.16. How To Configure SS Client..........................................................................49 3.16.1. How To Set Configuration File of SS JAVA API ................................................ 49 3.16.2. Configuration of MyProxy .................................................................................. 50 3.16.3. Configure System Property ................................................................................ 51 3.16.4. Add SS Java API Jar File to CLASSPATH........................................................ 52 3.16.5. Configure Log File............................................................................................... 53

4. Start and Stop SuperScheduler ............................................................................54 4.1. How To Execute SuperScheduler ..................................................................54 4.2. How To Stop SuperScheduler........................................................................54

5. Uninstall SuperSchedler.......................................................................................55 6. Upgrade SuperScheduler......................................................................................56

6.1. Upgrade Procedure from old edition to multiple SS version ........................56 6.2. How to upgrade multiple SS version.............................................................56

6.2.1. How to upgrade SS Server.................................................................................. 57 6.2.2. Upgrade Procedure of SS Client ........................................................................ 58

Appendix A. Operation Check by Sample Program.....................................................60 A.1. Preparation to use sample program..............................................................60

A.1.1. Build Sample Program ....................................................................................... 60 A.1.2. Preparation of TEST WFML .............................................................................. 60 A.1.3. Get Proxy Certificate .......................................................................................... 61

A.2. Execute Sample Program..............................................................................62 A.2.1. Submit Workflow................................................................................................. 62 A.2.2. Check Workflow Status....................................................................................... 62 A.2.3. Destroy Workflow................................................................................................ 63

Appendix B. Reference of Configuration file.............................................................64 B.1. gridss.conf......................................................................................................65 B.2. config-ssls.xml ...............................................................................................72 B.3. config-dlg3.xml ..............................................................................................78 B.4. config-jms3.xml..............................................................................................80 B.5. config-eps3.xml ..............................................................................................81 B.6. config-csg3.xml ..............................................................................................82 B.7. config-asc3.xml ..............................................................................................87 B.8. config-rcs3.xml...............................................................................................88 B.9. config-vsc3.xml ..............................................................................................90 B.10. config-fsc3.xml ...............................................................................................93 B.11. config-bwe3.xml .............................................................................................96

v


B.12. bwe-sc0b.pdd .................................................................................................97 B.13. config-wwm3.xml...........................................................................................99 B.14. gridis-lrps-sslconf.xml .................................................................................101 B.15. gridss-status.xml .........................................................................................103

Appendix C. Notanda.................................................................................................105

vi


1. Introduction This document explains how to install NAREGI SuperScheduler software (hereinafter, this

document often abbreviates SuperScheduler as SS.), how to change the configuration file,

and how to start / stop SuperScheduler.

Please refer to “Functional Overview Document” and “System Design Document

(Overview, Detail)” to know the detail of each component of SS and system structure of

SS.

1.1. Overview of Instruction AS summary of installation of SS, we explain terminology on this document and show

summary of components within SS, brief overview of system components on system

installation, and operating environment as below.

1.1.1. SS Glossary We describe the below terminology in this document.

Term Comment

SS Server It‘s SuperScheduler Server part. It includes JM, DS, EPS, CSG,

ASC, RCS, VSC, FSC, BWE, WWM, and JLOGD.

SS Client It represents SuperScheduler client part.

SS JAVA API library Java library provides interface between SS Client and Naregi

upper module that is Workflow tool, PSE and etc. using

SuperScheduler.

BPEL Business Process Execution Language for Web Services

ex1-main http/soap Server It‘s SS server which have http/soap connection library.

JM(Job Manager) It’s a server to manage job execution.

DS(Delegation Service)

It’s Delegation Server and the other related services.

EPS(Execution Planning Service) It’s job execution planning service.

CSG(Candidate Set Generator) It’s SS service to search Resource Candidate.

ASC(Aggregation Service Container) It’s aggregation service.

RCS(Reservation Cache Service) It’s SS service to process reservation.

RSS(Random Selection Service) It’s SS service to choose resources in random order.

VSC(Virtual Service Container) It’s is Job Execution Dedicated Service container.

FSC(File Service Container) It’s File Transfer Dedicated Service.

1


BWE(Bpel Workflow Engine) It’s service managing BPEL workflow.

WWM(Wfml Workflow Manager) It’s service to manage WFML.

JLOGD（Workflow Tracking Daemon） It’s daemon that register status of workflow to NAREGI

Distributed Information Service.

SS-Stated （ SS Service status

monitoring Daemon）

It’s daemon which notify status of SuperScheduler to NAREGI

Distributed Information Service.

SS package Super Scheduler installer package. It includes binary, source and

etc.

IS Access Tool It’s tool to access and use NAREGI Distributed Information

Service.

Table 1：SS Glossary

1.1.2. SuperScheduler Components Here is SuperScheduler structure.

SS Server

SS Client

FSC

VSC

DS

CSG

JLOGD

WWM

BWE

SS Statd

RSS RCS

ASC

JM

EPS

MyProxy

IS

GridVM/GRAM

2


Figure 1： SS Architecture Diagram

NOTICE)

IS (NAREGI Distributed Information Service), GridVM/GRAM, MyProxy is NOT included

in SS Server.

1.2. System Architecture Summary Before installing SS, you have to know Summary of VO structure, and mixed environment

where various type of Local Scheduler exists. Variation of VO structure makes SS

installation node or SS installation component change. Please consider VO structure

before installing SuperScheduler.

Please refer to the other component documents to know the detail of the components

except for SuperScheduler.

1.2.1. Single SS System Architecture Here is single SS System Overview. “VO1” assumes some Virtual Organization.

“SiteA” assumes some Real Organization. As example of Virtual Organization, it

corresponds to college student body, its subsystem, industry entity, and Its department or

particular research area organization/group which straddle more than one research lab or

university.

As example of Real Organization, It corresponds to set of computing machines owned by

university, research institution, and computer center. Single SS environment shares

NAREGI Upper middleware (i.e. SS Server or IS or etc.) on multiple VO.

Single SS System Architecture requires NAREGI lower middleware in each Site. Single

SS System environment is suitable for small grid environment. Please install one SS

Server and one SS Client within grid environment when you install SuperScheduler.

“1.2.2Multiple SS System Architecture (Centralized RCS model)” is recommended to

share SS Server load in large-scale grid system, because SS server has limitation on

processable jobs.

3


Figure 2：Single SS System Architecture

1.2.2. Multiple SS System Architecture (Centralized RCS model) We show an example of multi SS system architecture as below. VO1 and VO2 show

different virtual organization. The example assumes that SiteA and SiteB are different

Real Organization.

As example of Real Organization, It represents set of computing machines owned by

university, research institution or computer center. Multiple SS system architecture can

compose large-scale grid environment because multi SS Server can share load ion each

virtual organization.

Each VO requires NAREGI upper middleware (i.e. SS Server, IS and etc.) to construct

multi SS Architecture. Each site requires NAREGI lower middleware (GridVM etc). Then

Centralized RCS (Reservation Cache Service) model has to put one RCS to

accommodate Resource Reservation in each VO.

SS Administrator has to install SS server and SS client to each VO system to construct

SiteA

VO1

SS

Server

GridVM (VO1)

GridVM (VO1)

GridVM (VO1)

SS

Client

IS

SiteB GridVM (VO1)

GridVM (VO1)

4


SuperScheduler system. RCS has to locate on SS Server or the other host

SiteA

VO2

VO1

SS

Server SS

Server

RCS

GridVM (VO1)

GridVM (VO1/2)SiteB GridVM (VO2)

GridVM (VO2) GridVM (VO1)

IS IS

SS

Client

SS

Client

Figure 3：Multiple SS System Architecture (Centralized RCS model)

1.2.3. Multiple SS System Architecture ( Distributed RCS model) (NOT Supported Currently)

The following is multiple SS System Architecture which use distributed RCS (Reservation

Cache Service). RCS runs on each SS server in case of Distributed RCS mode. This

architecture can distribute load to each SS for reserving resources, if each SS submits

jobs to unshared computing resources. If jobs are submitted to and runs on computing

resource shared by each VO, performance overhead may increase because each SS

server have to intermediate reservations.

5


SiteA

VO2

VO1

SS

Server SS

Server

RCS

GridVM (VO1)

GridVM (VO1/2)SiteB GridVM (VO2)

GridVM (VO2) GridVM (VO1)

IS IS

SS

Client

SS

Client

RCS

Figure 4：Multiple SS System Architecture（Distributed RCS model）

NOTICE) This architecture is NOT supported currently. Please construct Centralized RCS

model in case of Multiple SS System Architecture.

1.2.4. Exampled of mixed Local Scheduler Although SuperScheduler can also make use of WS GRAM, Pre-WS GRAM except for

NAREGI Grid Middleware GridVM. Note that WS GRAM and Pre-WS GRAM can deal

with non-reserved Job. Either single VO architecture or multiple VO architecture can have

mixed Local Schedulers.

6


SiteA

VO1

SS

Server

GridVM (VO1)

WS GRAM

Pre-WS GRAM

IS

SS

Client

SiteB Pre-WS GRAM

GridVM (VO1)

Figure 5：Example of Mixed Local Schedulers

7


1.3. Product Requirements This section describes requirement for SuperScheduler.

NOTICE) Both SS Sever and SS Client have the same product requirement, because

installing only client package is not supported currently.

1.3.1. Hardware requirement Hardware requirement is below.

CPU: IA-32, x86_64 processor

RAM: 1GB or more

Hard Disk: 30GB or more

1.3.2. Software Requirement (a) Required Software before installing SS.

SS Server and SS client requires the following software.

OS：Linux (RedHat 9.0)

GCC

Java J2SE 1.4.2 or 1.5（1.6 is not supported）

Globus Toolkit 4.0.3

apache ant (1.6 and more)

SS server requires below software.

Jwsdp 1.6

naregi-infoservice-client（NAREGI Distributed Information Service Package）

NOTICE)

To run CSG service, which is one of SS Service on operation environment, Jwsdp

and naregi-infoservice-client is required on it.

(b) Required Software included in SS package

SuperScheduler installer installs the following software with SuperScheduler itself.

These programs are included in SS package.

8


e2fsprogs-libs

libxml2

libxslt

xmlsec1

openssl

zlib

postgresql

Notes) Because only SuperScheduler can use these software, the other software can’t

use them.

9


2. SuperScheduler Installation You have to install SS package on each SS Server node and SS client node, then

configure them.

If you install SS Server and SS client into the same computer by SS Package, you have to

configure both of them. You can also install each component into separate computers.

In this case you have to install SS package into each computer and configure them on

each computer.

Notes) To Install only client package is NOT supported currently.

2.1. Installation User User who runs SuperScheduler must be Globus Toolkit administrator (globus user)

because he needs to read Globus Toolkit service container certificate and key file. So

please install SuperScheduler with Globus Toolkit administrator.

$ su - globus

2.2. Before Installation This section explains necessary preparatory work before installing SS package.

2.2.1. Create Install Directory Please create the installation directory as root, then chown it to the globus user

Here is an example as below.

# mkdir /usr/naregi/SS

# chown globus /usr/naregi/SS

2.2.2. Configuration of Environment Variables Please set following environment variables according to installation environment.

NAREGI_MIDDLEWARE

SuperScheduler install directory is $NAREGI_MIDDLEWARE/SS, if this environment

variable is set. You can also set installation directory by installer option. If you don’t

specify both of them, installation directory will be $HOME/inst/gridss-usr-local as

10


default value.

ANT_HOME JAVA_HOME GLOBUS_LOCATION

These environment variables are required when you Install Java package (i.e. SS

Java API and IS Access Tool) included in SS package. Please set them, when you

install Java package.

INFO_SV_API_LOCATION The environment variable specifies directory where client library of Naregi Distributed

Information Service is installed. IS Access Tool of SS package requires it.

JWSDP_LOCATION The environment variable specifies installation directory of Java Web Services

Developer Pack. It’s required to Install IS Access Tool of SS package.

NOTICE1) Java package is installed if specifying installer option.

NOTICE2) Please install IS Access Tool to host where CSG Service is installed and run,

because only CSG Service uses IS Access Tool.

2.3. Installation Procedure This section explains 2 types of installation procedure. At first it explains how to install SS

server, and next it explains how to install SS client.

Comment) Each component of SS Server can run on different hosts. In case of this,

please install SS Server on each host.

2.3.1. SS Server Installation Procedure The following shows how to install SS Server.

Hereinafter we assume that each environment variable is shown in “2.2.2.Configuration of

Environment Variables” is set as below.

NAREGI_MIDDLEWARE /usr/naregi

ANT_HOME /usr/naregi/ant

JAVA_HOME /usr/lib/jdk-1.5.0_13

11


GLOBUS_LOCATION /usr/naregi/gt4

INFO_SV_API_LOCATION /usr/naregi/IS/naregi-infoservice-client

JWSDP_LOCATION /usr/lib/jwsdp-2.0

We assume that install user creates /var/tmp/work directory as temporary area and place

SS package under /var/tmp/work.

The following is an example. In this example, package version is shown <version>. When

you install SS Server, you should execute install with –with-java-utils=”IS” option to install

IS Access Tool.

$ export NAREGI_MIDDLEWARE=/usr/naregi

$ export ANT_HOME=/usr/naregi/ant $ export JAVA_HOME=/usr/lib/jdk-1.5.0_13 $ export GLOBUS_LOCATION=/usr/naregi/gt4 $ export INFO_SV_API_LOCATION=/usr/naregi/IS/naregi-infoservice-client $ export JWSDP_LOCATION=/usr/lib/jwsdp-2.0 $ mkdir /var/tmp/work $ cp gridss-pack-<version>.tar.gz /var/tmp/work $ cd /var/tmp/work $ tar zxf gridss-pack-<version>.tar.gz $ sh OPENDIST.sh --with-java-utils="is" Making a GridSS run-time environment in /usr/naregi/SS/ ... Mon Jul 23 13:20:30 JST 2007 pcfg...done Mon Jul 23 13:21:22 JST 2007 zlib...done Mon Jul 23 13:21:26 JST 2007 icnv...done Mon Jul 23 13:22:11 JST 2007 uuid...done Mon Jul 23 13:22:36 JST 2007 xml2...done Mon Jul 23 13:25:33 JST 2007 xslt...done Mon Jul 23 13:26:26 JST 2007 ossl...done Mon Jul 23 13:28:41 JST 2007 xsec...done Mon Jul 23 13:29:51 JST 2007 pgre...done Mon Jul 23 13:33:43 JST 2007 gss0...done Mon Jul 23 13:40:04 JST 2007 $

Please execute the following command line and confirm that it returns “0”.

$ echo $?

0

12


2.3.2. SS Client Installation Procedure The following shows installation procedure of SS Client.

We assume that environment variable shown “2.2.2.Configuration of Environment

Variables” is configured as follow.

NAREGI_MIDDLEWARE /usr/naregi

ANT_HOME /usr/naregi/ant



We also assume that install user creates /var/tmp/work directory as temporary area and

place SS Package under /var/tmp/work.

The following is an example. Package version in the example represents <version>.

Please execute installer with “-with-java-utils=”api”” option when user installs SS Client.

$ export NAREGI_MIDDLEWARE=/usr/naregi

$ export ANT_HOME=/usr/naregi/ant $ export JAVA_HOME=/usr/lib/jdk-1.5.0_13 $ export GLOBUS_LOCATION=/usr/naregi/gt4 $ mkdir /var/tmp/work $ cp gridss-pack-<version>.tar.gz /var/tmp/work $ cd /var/tmp/work $ tar zxf gridss-pack-<version>.tar.gz $ sh OPENDIST.sh --with-java-utils="api" Making a GridSS run-time environment in /usr/naregi/SS/ ... Mon Jul 23 13:20:30 JST 2007 pcfg...done Mon Jul 23 13:21:22 JST 2007 zlib...done Mon Jul 23 13:21:26 JST 2007 icnv...done Mon Jul 23 13:22:11 JST 2007 uuid...done Mon Jul 23 13:22:36 JST 2007 xml2...done Mon Jul 23 13:25:33 JST 2007 xslt...done Mon Jul 23 13:26:26 JST 2007 ossl...done Mon Jul 23 13:28:41 JST 2007 xsec...done Mon Jul 23 13:29:51 JST 2007 pgre...done Mon Jul 23 13:33:43 JST 2007 gss0...done Mon Jul 23 13:40:04 JST 2007 $

Please execute the following command line and confirm that it returns “0”.

$ echo $?

0

13


2.4. Coping process if installer failed. Please remove SuperScheduler install directory and temporary area where SS package

was extracted, after resolving the cause that SS installer failed. Then please install SS

again.

$ rm –rf $NAREGI_MIDDLEWARE/SS

$ rm –rf /var/tmp/work

14


3. Configuration SuperScheduler

This chapter shows configuration process for SS. If you configure SS server, please refer

from section ”3.1” to section “3.15" If you configure SS client, refer from section “3.16”.

3.1. Setup User Install User should be Globus Toolkit administrator (globus user), because

SuperScheduler reads Globus Toolkit service container certificate and key file. So install

SuperScheduler as Globus Toolkit administrator (globus user).

$ su - globus

3.2. Configuration Environment Variables Please set the following environment variables.

GRIDSS_LOCATION Please specify SS installation directory.

JAVA_HOME Please specify as the same value to environment variables as you specified when

you installed SS.

PATH Please add $JAVA_HOME/bin and $GRIDSS_LOCATIO/bin to PATH environment

variable.

We assume that these environment variables are set as below.

GRIDSS_LOCATION /usr/naregi/SS


Here is an example of configuration.

$ export GRIDSS_LOCATION=/usr/naregi/SS

$ export JAVA_HOME=/usr/lib/jdk-1.5.0_13

$ export PATH=$GRIDSS_LOCATION/bin:$JAVA_HOME/bin:$PATH

15


3.3. Create and Edit Configuration Files You have to create and edit the following files to configure SS Server.

gridss-global.env This configuration file is for remote host information like host name and port number

where each component runs. gridss-mkconf(1) reads this file.

gridss-local.env This configuration file has local host information like installation directory of

SuperScheduler, Globus Toolkit or etc. gridss-mkconf(1) uses it as input-file.

The following is how to create these files.

3.3.1. Create gridss-global.env file. Please copy the template file into gridss-global.env file as below.

$ cd $GRIDSS_LOCATION/etc/gridss/

$ cp gridss-global.env.tmpl gridss-global.env

Please change the following parameters in gridss-global.env to suit operating

environment where SuperScheduler runs.

MYPROXY_SERVER This parameter is for setting FQDN of Myproxy+ server. But you don’t need to

configure it, because it is not used as normal setting.

MYPROXY_SERVER_PORT This parameter is used for Myproxy+ server port number. You don’t need to configure

it, because it is not used for normal setting.

GRIDIS_PG_SERVER This parameter specifies FQDN of PostgreSQL Server which NAREGI distributed

Information Service has.

GRIDIS_PG_SERVER_PORT

16


This parameter specifies port number of Posters Server which NAREGI distributed

information service use. If NAREGI IS uses default port number 5432, you don’t need

set this parameter.

GRIDIS_PG_DBNAME This parameter specifies node database name of PostgreSQL which NAREGI

distributed information service uses.

GRIDIS_PG_USERNAME

This parameter specifies user name which NAREGI distributed Information Service

accesses PostgreSQL as.

GRIDSS_PG_PASSWORD

This parameter specifies password that NAREGI distributed information service

accesses PostgreSQL Server as.

URLH A common part of URL (i.e. host name and port number) should be set into this

parameter, if each component of SuperScheduler runs on same host.

WARNING) Please be careful of file permission, if GRID_PG_PASSWORD

parameter is set.

Here is an example of gridss-global.env. Each parameter is set as below.

MYPROXY_SERVER localhost.localdomain

MYPROXY_SERVER_PORT 7512

GRIDIS_PG_SERVER pfg2042.naregi.org

GRIDIS_PG_SERVER_PORT 5432

GRIDIS_PG_DBNAME node

GRIDIS_PG_USERNAME naregiss

GRIDIS_PG_PASSWORD naregiss

URLH https://pfg2041.naregi.org:8080

MYPROXY_SERVER=localhost.localdomain MYPROXY_SERVER_PORT=7512 GRIDIS_PG_SERVER= localhost.localdomain → pfg2042.naregi.org

17


GRIDIS_PG_SERVER_PORT=5432 GRIDIS_PG_DBNAME=node GRIDIS_PG_USERNAME=naregiss GRIDIS_PG_PASSWORD=naregiss # scheme ":" "//" authority (do NOT contains "Path" part) URLH=https://localhost.localdomain:8080 → pfg2041.naregi.org:8080 URLH_DFS=${URLH} URLH_DLG=${URLH_DFS} URLH_UPS=${URLH_DFS} URLH_JMS=${URLH} URLH_EPS=${URLH} URLH_CSG=${URLH} URLH_ASC=${URLH} URLH_RCS=${URLH} URLH_VSC=${URLH} URLH_FSC=${URLH} URLH_FVM=${URLH} URLH_BWE=${URLH} URLH_WWM=${URLH} URLH_RSS=${URLH}

NOTES) Each component of SuperScheduler can runs on different hosts. In this case

please specify each URL in each component.

3.3.2. Configuration Multiple SS Please specify location of centralized RCS in gridss-global.env, if you construct multiple

SS Architecture.

NOTES) Please refer to “1.2.2.Multiple SS System Architecture (Centralized RCS

model)” according to centralized RCS.

Please change the following parameters so as to match operation environment where

SuperScheduler runs.

URLH_RCS Please configure hostname where RCS runs and port number of RCS service.

The following is an example of gridss-global.env. This example assumes that

URLH_RCS is the following.

URLH_RCS https://png2045.naregi.org:8080

MYPROXY_SERVER=localhost.localdomain MYPROXY_SERVER_PORT=7512 GRIDIS_PG_SERVER=png1048.naregi.org

18


GRIDIS_PG_SERVER_PORT=5432 GRIDIS_PG_DBNAME=node GRIDIS_PG_USERNAME=naregiss GRIDIS_PG_PASSWORD=naregiss # scheme ":" "//" authority (do NOT contains "Path" part) URLH=https://png1047.naregi.org:8080 URLH_DFS=${URLH} URLH_DLG=${URLH_DFS} URLH_UPS=${URLH_DFS} URLH_JMS=${URLH} URLH_EPS=${URLH} URLH_CSG=${URLH} URLH_ASC=${URLH} URLH_RCS=${URLH} → https://png2045.naregi.org:8080 URLH_VSC=${URLH} URLH_FSC=${URLH} URLH_FVM=${URLH} URLH_BWE=${URLH} URLH_WWM=${URLH} URLH_RSS=${URLH}

3.3.3. Create gridss-local.env File Please copy the template file of gridss-local.env and edit gridss-locale.env.


$ cp gridss-local.env.tmpl gridss-local.env

Please change the following parameter to fit operation environment where

SuperScheduler runs.

GRIDSS_LOCATION SuperScheduler installation directory

GLOBUS_LOCATION GlobusToolkit installation directory

GRID_SECURITY_DIR Please specify the directory where Globus Toolkit service container certificate is

located.

GRIDSS_SIGNER_DIR Please specify the directory where signer certificate of SuperScheduler Delegation

Service is located.

19


JAVA_HOME Please specify the same JAVA_HOME directory as you specified to install SS.

PSE_XSLT_USING This parameter specifies whether PSE Executable Path extension function is

effective or not. Please set either true (validation) or false (invalidation). Default

configuration is invalidation.

XSLT_RESERVE_ONLY Please specify whether NAREGI Distributed Information Service has old resource

schema information (i.e. NRG_ClusterJobQueue in schema class doesn’t have

Reservable parameter). Please specify true (i.e. old: schema in IS doesn’t have

Reservable parameter.) or false (i.e. new :schema in IS has Reservable parameter.)

default setting is true.

The following is en example of gridss-local.env. We assume that each parameter is the

following.

GRIDSS_LOCATION /usr/naregi/SS


GRID_SECURITY_DIR /etc/grid-security

GRIDSS_SIGNER_DIR ${GRID_SECURITY_DIR}


PSE_XSLT_USING true

XSLT_RESERVE_ONLY false

GRIDSS_USER globus

GRIDSS_LOCATION=/usr/naregi/SS GLOBUS_LOCATION=/usr/naregi/gt4 GRID_SECURITY_DIR=/etc/grid-security GRIDSS_SIGNER_DIR=${GRID_SECIRITY_DIR} JAVA_HOME=/usr/java/j2sdk1.4.2_11 → /usr/lib/jdk-1.5.0_13 PSE_XSLT_USING=true XSLT_RESERVE_ONLY=false GRIDSS_USER=globus

20


3.4. Edit Constitutive Configuration File Each component needs constitutive configuration files and these are template files whose

name consists of “.in” extension. gridss-mkconf(1) generates constitutive configuration

files from template files, but now you have to configure a few template files before

gridss-mkconf(1) runs. We describe how to configure template file for system

configuration file as below.

Here are the template files to configure.

$GRIDSS_LOCATION/etc/gridss/gridss.conf.in $GRIDSS_LOCATION/etc/gridss/config-ssls.xml.in

We explain how to configure template files taking gridss.conf.in as example.

① Create Configuration File To Edit.

There are template files, whose name consists of “.in” extension, corresponding to

each system configuration file. For example, template file for gridss.conf is

gridss.conf.in. Please copy this template file to create configuration file. You should

rename the name of configuration file to “*.in.mod”. The following is an example.


$ cp gridss.conf.xml.in gridss.conf.xml.in.mod

To create configuration file makes grids-mkconf(1) read configuration file prior than

template file.

② Edit Configuration files

Please edit configuration file created according to procedure ①. We explain changes

of configuration file hereinafter.

$ vi gridss.conf.in.mod

NOTICE) Please DON’T directly edit your system configuration files (*.confine) or

template files (.conf).

The following shows the changes in configuration file. Please follow an instruction in each

section and edit .in.mod file which is copied from template file.

21

3.4.1. Edit gridss.conf.in.mod Please uncomment the following parameters which are commented out as default.

/configure/rlimit/@name=’nofile’ /configure/wsif-base/ws-sec/ignore-gt2-proxy-error /configure/soap-base/soap-user-endpont/backlog

Here are changes of constitution configuration files.

<configure> <rlimit name="nofile">10240</rlimit>  <moduledir>@GRIDSS_LOCATION@/libexec</moduledir> <sock-base> <sock-http-proxy>  </sock-http-proxy> <secure-socket-layer> <module conf="@GRIDSS_LOCATION@/etc/gridss/config-ssls.xml" sslx="/" >default-SSL-security-context</module> </secure-socket-layer> </sock-base> <http-base> <http-message-coder> <module>mod-http-0len.la</module> <module>mod-http-clen.la</module> <module>mod-http-chnk.la</module> </http-message-coder> <http-content-coder /> </http-base> <wsif-base> <ws-sec> <host-key>@GRIDSS_SIGNER_DIR@/containerkey.pem</host-key> <host-cert>@GRIDSS_SIGNER_DIR@/containercert.pem</host-cert> <internal-actions> <internal-action>http://www.naregi.org/ss/namespaces/2006/09/userproxy/UserProxyPortType/GetCertificate</internal-action> <internal-action>http://www.naregi.org/ss/namespaces/2006/09/userproxy/UserProxyPortType/GetRawCertificate</internal-action> <internal-action>http://www.naregi.org/ws/ogsa/ems/rss/eps3/ExecutionPlanningServicePT/SelectResourcesRequest</internal-action> <internal-action>http://www.naregi.org/ws/ogsa/ems/rss/eps3/ExecutionPlanningServicePT/SelectAndReserveResourcesRequest</internal-action> <internal-action>http://www.naregi.org/ws/ogsa/ems/rss/csg3/CandidateSetGeneratorPT/GenerateCandidateSetRequest</internal-action>

22

<internal-action>http://www.naregi.org/ws/ogsa/ems/rss/ces/1/CoallocationExecutionServicePT/MakeReservationsRequest</internal-action> <internal-action>http://www.naregi.org/ws/ogsa/ems/rss/ces/1/CoallocationExecutionServicePT/CommitReservationsRequest</internal-action> </internal-actions> <ignore-gt2-proxy-error/> </ws-sec> </wsif-base> <soap-base> <soap-one-way-timeout>60</soap-one-way-timeout> <soap-http-endpoint> <module>mod-soap-http.la</module> </soap-http-endpoint> <soap-header-module /> <soap-user-endpoint> <backlog>10240</backlog> <module url="@URLH_DFS@/" sslx="/" >DelegationFactoryService_skel.la</module> <module url="@URLH_DLG@/" sslx="/" >DelegationService_skel.la</module> <module url="@URLH_UPS@/" sslx="/" >UserProxyService_skel.la</module> <module url="@URLH_JMS@/" sslx="/" >JobManagerService_skel.la</module> <module url="@URLH_EPS@/" sslx="/" >ExecutionPlanningService_skel.la</module> <module url="@URLH_CSG@/" sslx="/" >CandidateSetGenerator_skel.la</module> <module url="@URLH_ASC@/" sslx="/" >AggregateServiceContainer_skel.la</module> <module url="@URLH_RCS@/" sslx="/" >ReservationCacheService_skel.la</module> <module url="@URLH_FSC@/" sslx="/" >FileServiceContainer_skel.la</module> <module url="@URLH_VSC@/" sslx="/" >VirtualServiceContainer_skel.la</module> <module url="@URLH_BWE@/" sslx="/" >BpelWFEngine_skel.la</module> <module url="@URLH_WWM@/" sslx="/" >WfmlWFManager_skel.la</module>    <!-- <module url="@URLH_FVM@/" sslx="/" conf="@GRIDSS_LOCATION@/etc/gridss/config-dlg3-fvm.xml" >DelegationFactoryService_skel.la</module> <module url="@URLH_FVM@/" sslx="/" conf="@GRIDSS_LOCATION@/etc/gridss/config-dlg3-fvm.xml" >DelegationService_skel.la</module> <module url="@URLH_FVM@/" sslx="/" conf="@GRIDSS_LOCATION@/etc/gridss/config-dlg3-fvm.xml" >UserProxyService_skel.la</module> <module url="@URLH_FVM@/" sslx="/" >ManagedJobFactory_skel.la</module> <module url="@URLH_FVM@/" sslx="/" >ManagedJobService_skel.la</module> <module url="@URLH_FVM@/" sslx="/"

23

>GridVMJobFactory_skel.la</module> <module url="@URLH_FVM@/" sslx="/" >GridVMJobService_skel.la</module> --> </soap-user-endpoint> </soap-base> </configure>

3.4.2. Edit config-ssls.xml.in Please change the content of “/configure/SSLVerifyPeer” parameter as below.

Before Change: require

After Change: none

Here are changes in constitution configuration file.

<configure> <SSLProtocol>SSLv3</SSLProtocol> <SSLOptions /> <SSLCipherSuite>NULL-MD5:ALL</SSLCipherSuite> <SSLCertificateFile>@GRID_SECURITY_DIR@/containercert.pem</SSLCertificateFile>  <SSLCertificateKeyFile>@GRID_SECURITY_DIR@/containerkey.pem</SSLCertificateKeyFile>   <SSLCACertificatePath>@GRID_SECURITY_DIR@/certificates:@GRID_SECURITY_DIR@/vomsdir</SSLCACertificatePath>    <SSLVerifyPeer>none</SSLVerifyPeer> <SSLVerifyDepth>16</SSLVerifyDepth> <SSLVerifyOptions>X509_V_FLAG_CB_ISSUER_CHECK</SSLVerifyOptions>     <SSLVerifyOptions>X509_V_FLAG_X509_STRICT</SSLVerifyOptions> <SSLVerifyOptions>X509_V_FLAG_ALLOW_PROXY_CERTS</SSLVerifyOptions>      </configure>

3.5. Execute gridss-mkconf Please execute gridss-mkconfig (1), it creates constitution configuration file. Here is an

operation example as below.

24


$ gridss-mkconf

setting postgresql client...

generating from gridss.conf.xml.in.mod...

generating from config-ssls.xml.in.mod...

generating from config-dlg3.xml.in...

generating from config-jms3.xml.in.mod...

generating from config-eps3.xml.in...

generating from config-csg3.xml.in...

generating from config-asc3.xml.in...

generating from config-rcs3.xml.in...

generating from config-vsc3.xml.in...

generating from config-fsc3.xml.in...

generating from config-fvm3.xml.in...

generating from config-bwe3.xml.in...

generating from bwe-sc0b.pdd.in...

generating from bwe-sc0b.wsdl.in...

generating from config-www3.xml.in.mod...

generating from config-rss3.xml.in...

generating from gridis-lrps-sslconf.xml.in...

generating from gridss-status.xml.in...

generating from jins2sql.xsl.in...

generating from qres2jins.xsl.in...

$

Please execute the following command and confirm gridss-mkconf(1) returns “0” as exit

code.

$ echo $?

0

Here is a list of constitution configuration files generated by gridss-mkconf(1).

Component Name File Name

$GRIDSS_LOCATION/etc/gridss/gridss.conf ex1-main http/soap Server

$GRIDSS_LOCATION/etc/gridss/config-ssls.xml

25


DS（Delegation Service） $GRIDSS_LOCATION/etc/gridss/config-dlg3.xml

JM（Job Manager） $GRIDSS_LOCATION/etc/gridss/config-jms3.xml

EPS（Execution Planning Service） $GRIDSS_LOCATION/etc/gridss/config-eps3.xml

CSG（Candidate Set Generator） $GRIDSS_LOCATION/etc/gridss/config-csg3.xml

ASC（Aggregation Service Container） $GRIDSS_LOCATION/etc/gridss/config-asc3.xml

RCS（Reservation Cache Service） $GRIDSS_LOCATION/etc/gridss/config-rcs3.xml

RSS(Random Selection Service) $GRIDSS_LOCATION/etc/gridss/config-rss3.xml

VSC（Virtual Service Container） $GRIDSS_LOCATION/etc/gridss/config-vsc3.xml

FSC（File Service Container） $GRIDSS_LOCATION/etc/gridss/config-fsc3.xml

$GRIDSS_LOCATION/etc/gridss/config-bwe3.xml

$GRIDSS_LOCATION/etc/gridss/bwf-sc0b.pdd BWE（Bpel Workflow Engine）

$GRIDSS_LOCATION/etc/gridss/bwf-sc0b.wsdl

WWM（Wfml Workflow Manager） $GRIDSS_LOCATION/etc/gridss/config-wwm3.xml

JLOGD（Workflow Tracking Daemon）

SS-Statd (SS Service status monitoring

Daemon)

$GRIDSS_LOCATION/etc/gridss/gridis-lrps-sslconf.xml

SS-Statd (SS Service status monitoring

Daemon) $GRIDSS_LOCATION/etc/gridss/gridss-status.xml

Table 2：List of constitution configuration files

3.6. Tune System Parameter You need to tune the following 2 parameters among parameters in section “3.4.1.Edit

gridss.conf.in.mod”. Edit gridss.conf.in”.

/configure/rlimit/@name=’nofile’ /configure/soap-base/soap-user-endpont/backlog

We describe how to configure them.

3.6.1. Configure Max number of enable open files Please set the following parameters to enable the value of

“/configure/rlimit/@name=’nofile’” parameter as system administrator.

NOTICE) We assume that SS Server is executed as globus user.

26


① Expanding user limitation

Edit the following files.

/etc/security/limits.conf

Here is setting values. #<domain> <type> <item> <value> globus soft nofile 10240 globus hard nofile 20480

NOTES) Above example is recommended value. Please specify suitable value

according to operating environment.

NOTICE) Please logout after configuring above parameters and login again to enable

the limits value.

② Configure Kernel parameter

Please run the following command.

# echo 20480 > /proc/sys/fs/file-max

NOTICE) Please specify suitable value depending on the situation, as above example

is recommended value.

Please configure the following files to enable this parameter after rebooting system.

/etc/sysctl.conf

Please add the following value.

fs.file-max = 20480

NOTICE) AS above example is recommended value, specify suitable value

depending on the situation.

3.6.2. Configure Max Length of Socket Queue Waiting For Connection Please set the followings as system administrator to enable

“/configure/soap-base/soap-user-endpont/backlog” parameter.

27


① Configure kernel parameter

Please execute the following commands.

# echo 10240 > /proc/sys/net/ipv4/tcp_max_syn_backlog

# echo 0 > /proc/sys/net/ipv4/tcp_syncookies

# echo 0 > /proc/sys/net/ipv4/tcp_abort_on_overflow

# echo 16 > /proc/sys/net/ipv4/tcp_syn_retries

# echo 10240 > /proc/sys/netc/core/netdev_max_backlog

# echo 4096 > /proc/sys/net/core/somaxconn

NOTICE) Above examples are recommend values. Please specify suitable value

according to your operating environment.

Please edit the following file to enable those configurations after rebooting system.

/etc/sysctl.conf

Please add the following content.

net.ipv4.tcp_max_syn_backlog = 10240 net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_syn_retries = 16 net.core.netdev_max_backlog = 10240 net.core.somaxconn = 4096

Notice) Please specify suitable value according to your operation environment, because

above value is recommended value.

3.7. Configuration To Use Naregi Distributed Information Service

This section shows configuration procedure to select resources in NAREGI Distributed

Information Service by IS Aces stool which SuperScheduler provides. The following figure

shows relation between SS and NAREGI Distributed Information Service on multi SS

architecture.

28


VO1

Figure 6：Relationship with NAREGI Distributed Information Service

3.7.1. Check Accessing Data Base Please check access to PostgreSQL Data Base which Naregi Distributed Information

Service use.

psql -d <DataBase Name> -h <Server Name> -p <Port num> -U <DB user> -c “¥q”

Arguments of –d, –h, –p and –U option are corresponding to the following parameters

which are set at “3.3.1.Create gridss-global.env file.”

GRIDIS_PG_DBNAME： -d <DataBase Name>

GRIDIS_PG_SERVER： -h <Server Name>

GRIDIS_PG_SERVER_PORT： -p <Port Number>

GRIDIS_PG_USERNAME： -U <DB User Name>

Here is an example.

$ psql –d node –h pfg2042.naregi.org –p 5432 –U naregiss –c “¥q”

$ echo $?

0

Please confirm no error and return code is “0”.

3.7.2. Preparation for using IS Access Tool Please set the following before using IS Access Tool.

① Configuring grid-mapfile in NAREGI Distributed Information Service

Please register Subject, which is included in Globus Service Container certificat

e of SS Server, to grid-mapfile on host where Naregi Distributed Information Se

IS (NAS)

VO2

SS IS (NAS) SS

29


rvice runs. User mapped to Subject should be Administrator of GlobusToolkit.

grid-cert-info(1) can show Subject name. Here is an example.

$ grid-cert-info –s –f /etc/grid-security/containercert.pem

/C=JP/O=National Research Grid Initiative/OU=CGRD/CN=host/pfg2041.naregi.org

The following is an example of registered grid-mapfile.

“/C=JP/O=National Research Grid Initiative/OU=CGRD/CN=host/pfg2041.naregi.org” globus

Comment) Please refer to Naregi Distributed Information Service Administrator

Guide etc. to know path name of grid-mapfile.

② Confirming Naregi Distributed Information Service running.

Please check that container process of NAREGI Distributed Information Service runs.

3.7.3. Aggregate Resource Information by IS Access Tool Please execute info_service_create(1) to set aggregation of resource information to

Naregi Information Service. The following is usage of info_service_create(1).

info_service_create [-h <IS host>] [-p <IS port>] [-f <handle file>] [-c <aggregate list>]

The following is an example.

$ $GRIDSS_LOCATION/java/bin/info_service_create

It is preparing it just now...

Info service URL = https://png2046.naregi.org:8443/wsrf/services/org

/naregi/infoservice/aggregator/node/factory/NAFS

Handler file = /usr/naregi/SS/etc/gridss/gridis-handle

Use specified Cred to Access to Info Service.

Add aggregate: NRG_ClusterJobQueue

Refresh Frequency: 1 minute

Add aggregate: NRG_VomsAccountOnClusterJobQueue

30



Add aggregate: NRG_AccountOnJobQueue


Add aggregate: NRG_VomsAccount


Add aggregate: NRG_QueueForSAP


Add aggregate: NRG_ServiceAccessPath


Add aggregate: CIM_ServiceAccessBySAP


Add aggregate: NRG_GridService


Add aggregate: CIM_ServiceAccessURI


Add aggregate: CIM_UnitaryComputerSystem


Add aggregate: NRG_OperatingSystem


Add aggregate: CIM_Processor


Add aggregate: NRG_PSESoftwareElement


Add aggregate: CIM_ExecuteProgram

31



Add aggregate: CIM_SoftwareElementActions


Add aggregate: CIM_InstalledSoftwareElement


Add aggregate: NRG_PSEApplicationSharingDirectory


Create handler is completed.

$

Please execute the following command and check that info_service_create(1) returns “0”.

$ echo $?

0

3.7.4. Delete Aggregated Resource Information by IS Access Tool Please delete old aggregated resource information, if you create new aggregated

resource information or you don’t need to use the old aggregated resource information.

Please execute info_service_delete(1) to delete the aggregated resource information.

The following is a usage.

info_service_delete [-h <IS host>] [-p <IS port>] [-f <handle file>]

Here is an example.

$ $GRIDSS_LOCATION/java/bin/info_service_delete

It is preparing it just now... Info service URL = https://png2046.naregi.org:8443/wsrf/services/org/naregi/infoservice/aggregator/node/factory/NAFS Handler file = /usr/naregi/SS/etc/gridss/gridis-handle Use specified Cred to Access to Info Service. Destroy handler start Destroy handler is completed. $

Please execute the following command and check that info_service_delete(1) returns “0”.

32


$ echo $?

0

3.8. Configure Workflow Tracking Function This chapter explains how to configure accessing of LRPS for workflow tracking function

demon (JLOGD). You don’t need to configure it, if SS don’t utilize workflow tracking

function.

Comment) LRPS (Local Resource Provider Service) is one of component consisting of

NAREGI Distributed Information Service.

3.8.1. Configure Log Directory You have to configure the following system configuration file to set log directory which

work flow tracking daemon uses.

$GRIDSS_LOCATION/etc/gridss/config-jms3.xml

Here is a modification procedure.

① Edit config-jms3.xml.in.mod

Please edit config-jms3.xml.in.mod, referring “3.4.Edit Constitutive Configuration File”.

$ cd $GRIDSS_LOCATION/etc/gridss

$ cp config-jms3.xml.in config-jms3.xml.in.mod

$ vi config-jms3.xml.in.mod

The following is an example of modification. Please uncomment

“/configure/LogDirectory” parameter, since it is commented out.

<configure> <LogDirectory>@GRIDSS_LOCATION@/var/log/gridss/jms</LogDirectory> <Service name="EPS"> <URL>@URLH_EPS@/wsrf/services/ExecutionPlanningService3</URL> </Service> <Service name="WWM"> <URL>@URLH_WWM@/wsrf/services/WfmlWFManager3</URL> </Service> <Service name="BWE"> <URL>@URLH_BWE@/wsrf/services/BpelWFEngine</URL> </Service>

33


<Service name="DLG"> <URL>@URLH_DLG@/wsrf/services/DelegationFactoryService</URL> </Service> <Service name="UPS"> <URL>@URLH_UPS@/wsrf/services/UserProxyService</URL> </Service> </configure>

② Execute grids-mkconf(1)

Please execute gridss-mkconf(1) so as to reflect changes to config-jms3.xml with

reference of 3.4.Edit Constitutive Configuration File.

$ gridss-mkconf

③ Confirmation of Result

Please confirm that exit code of grids-mkconf(1) is “0”.

$ echo $?

0

3.8.2. Generate LRPS’s EPR JLOGD refers to LRPS’s EPR to access LRPS by the URL. It is possible to generate EPR

file by executing the following shell script.

$GRIDSS_LOCATION/bin/gridss-lrps-epr-create NOTICE) Please execute grids-lrps-epr-create(1) after “3.7.Configuration To Use

Naregi Distributed Information Service”, because it needs an access handle file of

Naregi Distributed Information Service.

If you change an access handle file of Naregi Distributed Information Service except

for default, you have to change config-csg3.xml. In this case please edit

conifg-csg3.xml.in.mod with reference of “3.3.Create and Edit Configuration Files”.

The following is a usage of gridss-lrps-epr-create(1).

gridss-lrps-epr-create [<EPR file name>]

If executing the command without <EPR file name>, it generates EPR file under the

following directory.

34


$GRIDSS_LOCATION/etc/gridss/gridis-lrps-epr.xml

Please execute grids-lrps-epr-create(1) and generate EPR file.

$ gridss-lrps-epr-create

$

The following is an example of EPR format.

<wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"> <wsa:Address> https://lrps.naregi.org:8443/wsrf/services/org/naregi/admin/LRPSService </wsa:Address> </wsa:EndpointReference>

3.8.3. Configure LRPS’s grid-mapfile Please register Subject included in Globus service container certificate in SS Serve

r host into grid-mapfile of LRPS host. Please refer to URL of wsa:Address in gener

ated EPR file to know hostname of LRPS. Please specify administrator as user ma

pping Subject.

grid-cert-info(1) can get Subject name. Here is an example.

$ grid-cert-info –s –f /etc/grid-security/containercert.pem

/C=JP/O=National Research Grid Initiative/OU=CGRD/CN=host/pfg2041.naregi.org

The following is an example to register them in grid-mapfile.

“/C=JP/O=National Research Grid Initiative/OU=CGRD/CN=host/pfg2041.naregi.org” globus

NOTES) Please refer to Administrator Guide of NAREGI Distributed Information Ser

vice to know path of grid-mapfile.

3.8.4. JLOGD Logrotation Configuration file for JDLOGD logrotation is the following file.

$GRIDSS_LOCATION/etc/gridss/gridss-logrotate.conf.tmpl

35


Hrere is a default setting of the configuration file.

/usr/naregi/SS/var/log/jlogd.log { daily size 100M copytruncate notifempty missingok rotate 100 compress # If you want to back log file, uncomment the below lines. # compress # olddir /usr/naregi/SS/var/log/back # postrotate # DT=`date +%FT%R` # mv /usr/naregi/SS/var/log/jlogd.log.1.gz /usr/naregi/SS/var/log/jlogd.log-$DT.gz # endscript }

NOTICE) Path name of above log file is different of operation environment.

The configuration is valid with SS Server logrotation by conducting procedure of “3.

15.How To Configure Logrotation”. Please configure the file according to your opera

tion environment by reference of “3.15.3.Configure gridss-logrotate”.

3.9. Configure Service Status Notification Function This chapter explains how to configure Service Status Notification Function (SS-Statd)

which is a demon to notify SS service status. If you don’t use it, you don’t need to

configure.

3.9.1. Generate LRPS’s EPR SS-Statd refers to the same EPR file as JOGD refers to, to access LRPS’s URL. If you

have finished configuration about “3.8.Configure Workflow Tracking Function”,

generating EPR is no need. If you did not it, please generate EPR file to refer to

“3.8.2.Generate LRPS’s EPR”.

3.9.2. Configure LRPS’s grid-mapfile If you finished configuration about “3.8.Configure Workflow Tracking Function”, you

don’t need to configure LRPS’s grid-mapfile to refer to “3.8.3.Configure LRPS’s grid

-mapfile”. If not, please configure it.

36


3.9.3. SS-Statd Logrotation The following file is configuration file to rotate log of SS-Statd.

$GRIDSS_LOCATION/etc/gridss/gridss-logrotate.conf.tmpl

Default setting is the following.

/usr/naregi/SS/var/log/gridss-statd.log { daily size 100M copytruncate notifempty missingok rotate 100 compress # If you want to back log file, uncomment the below lines. # compress # olddir /usr/naregi/SS/var/log/back # postrotate # DT=`date +%FT%R` # mv /usr/naregi/SS/var/log/gridss-statd.log.1.gz /usr/naregi/SS/var/log/gridss-statd.log-$DT.gz # endscript }

NOTICE) Above path may be different from your operation environment.

“3.15.How To Configure Logrotation” makes this setting valid with SS Server log rot

ation. If you have to change the configuration file, please change it according to y

our operation environment to consult 3.15.3.Configure gridss-logrotate.

3.10. Configuration To Run GridMPI Job You have to set environment variable like MPIROOT to use GridMPI. Please refer to

GridMPI document to configure GridMPI.

Comment) Although shell-wrapper file for GridMPI had to be placed on each computing

resources on V1.0, it is not need on V1.1 and later.

3.11. How to set Computing Resource where IMPI-SERVER runs. In case of GridMPI job, Super Scheduler dynamically allocates computing resources

where impi-server runs. But SuperScheduler can control computing resources where

impi-server runs, if VO administrator configures requirement of computing resources

where impi-server runs in advance.

37


Please configure environment variable in configuration file of WWM that is one of

component of SS Server. It is passed to wfml2bpel(1) command which convert from

WFML to BPEL. The following explains how to set resources where impi-server runs in

the configuration file.

3.11.1. Procedure To Edit Configuration File Configuration file of WWM is set under the following directory.

$GRIDSS_LOCATION/etc/gridss/config-wwm3.xml

Here is an example of editing procedure.

① Edit config-wwm3.xml.in

“Please edit config-wwm3.xml.in.mod with reference to“3.4.Edit Constitutive Co

nfiguration File”. The parameter for resources running impi-server is described l

ater.

$ cd $GRIDSS_LOCATION/etc/gridss

$ cp config-wwm3.xml.in config-wwm3.xml.in.mod

$ vi config-wwm3.xml.in.mod

② Execute gridss-mkconf(1)

Please execute gridss-mkconf(1) to reflect changes to config-wwm3.xml by reference

of “3.5.Execute gridss-mkconf”.

$ gridss-mkconf

3.11.2. Configuration Parameter and Environment Variable The following is configuration parameter to control resources where impi-server runs.

/configure/ShellComand/Environment

The followings are environment variables to set Environment parameter and set

resources where impi-server runs.

38


WFML2BPEL_IMPI_JSDL_OSNAME Please specify value of OperatingSystemName element (OS name) in JSDL. When

SuperScheduler allocates computing resource where impi-server runs, it selects

resources among specified operating systems.

Here is an example that OS name, where impi-server runs, is LINUX.

Example 1.

<Environment name="WFML2BPEL_IMPI_JSDL_OSNAME">LINUX</Environment>

WFML2BPEL_IMPI_JSDL_RESOURCES_PATH Please specify path of XML file which includes Resources element in JSDL. When

SuperScheduler allocates computing resource where impi-server runs, it selects

resources within specified operating system.

WFML2BPEL_IMPI_JSDL_RESOURCES_PATH is given priority over

WFML2BPEL_IMPI_JSDL_OSNAME.

Example 2.

<Environment name="WFML2BPEL_IMPI_JSDL_RESOURCES_PATH">@GRIDSS_LOCATION@/etc/gridss/impi-jrsc.xml</Environment>

Please configure XML file as the following (Example is

@GRIDSS_LOCATION@/etc/gridss/impi-jrsc.xml). Example 2-1 is the same as

Example 1.

Example 2-1 <jsdl:Resources xmlns:jsdl=”http://schemas.ggf.org/jsdl/2005/11/jsdl”> <jsdl:OperatingSystem> <jsdl:OperatingSystemType> <jsdl:OperatingSystemName>LINUX</jsdl:OperatingSystemName> </jsdl:OperatingSystemType> </jsdl:OperatingSystem> </jsdl:Resources>

Example 2-2 shows configuration to use either "cluster A" or “cluster B” as computing

resource where impi-server runs.

Example 2-2 <jsdl:Resources xmlns:jsdl=”http://schemas.ggf.org/jsdl/2005/11/jsdl”>

39


<jsdl:CandidateHosts><jsdl:HostName>clusterA.naregi.org</jsdl:HostName> <jsdl:HostName>clusterB.naregi.org</jsdl:HostName> </jsdl:CandidateHosts> </jsdl:Resources>

WFML2BPEL_IMPI_JSDL_PATH Please specify path name of XML file including JobDefinition element of JSDL.

Example 3. <Environment name="WFML2BPEL_IMPI_JSDL_PATH" >@GRIDSS_LOCATION@/etc/gridss/impi-jdef.xml</Environment>

Please configure XML file (@GRIDSS_LOCATION@/etc/gridss/impi-jdef.xml ) as

following.

例3-1. <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> <JobDescription> <JobIdentification> <JobName>IMPID-Job</JobName> </JobIdentification> <Application> <POSIXApplication xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <Executable>impi-server</Executable> <Argument>-server</Argument> <Argument>1</Argument> <Argument>-verbose</Argument> <Argument>-out</Argument> <Argument>@IMPIDLOG@</Argument> <Environment name="IMPI_AUTH_NONE">0</Environment> <WallTimeLimit>@WALLTIMELIMIT@</WallTimeLimit> </POSIXApplication> </Application> <Resources> <CandidateHosts> <HostName>clusterA.naregi.org</HostName> <HostName>clusterB.naregi.org</HostName> </CandidateHosts> </Resources> </JobDescription> </JobDefinition>

NOTES) SS automatically converts @MPIDLOG into log file name. (Ex.

impid-2008-04-21T07 :24 :46.674550Z.log0) SS automaticaly converts

@WALLTIMELIMIT@ into WalltimeLimit of GridMPI job.

WFML2BPEL_IMPI_JSDL_NAMESPACE Please specify namespace of JSDL. The environment variable is omissible. If i

t’s not set, SS statically allocates namespace. The following is an example that

40


namespace is http://schemas.ggf.org/jsdl/2005/11/jsdl.

Example 4. <Environment name="WFML2BPEL_IMPI_JSDL_NAMESPACE">

http://schemas.ggf.org/jsdl/2005/11/jsdl </Environment>

3.11.3. Example of config-wwm3.xml.in.mod(1) Here is an example of config-wwm3.xml.in.mod. Please refer to B.13.

41

http://schemas.ggf.org/jsdl/2005/11/jsdl

config-wwm3.xml for the details.

<configure> <ShellCommand name="MakeReservations"> <Executable>@GRIDSS_LOCATION@/bin/wfml2bpel</Executable> <Argument>-waitsec</Argument> <Argument>15</Argument> <Argument>--wfid</Argument> <Argument>%W</Argument> <Argument>--limit-activity</Argument> <Argument>0</Argument>

<Argument>%D/%I%m</Argument> <Argument>%D/%I%M</Argument> < !-- Environment name="WFML2BPEL_IMPI_JSDL_RESOURCES_PATH">@GRIDSS_LOCATION@/etc/gridss/imip-jrsc.xml</Environment --> < !-- Environment name="WFML2BPEL_IMPI_JSDL_OSNAME">LINUX</Environment--> <Environment name="WFML2BPEL_IMPI_JSDL_PATH">@GRIDSS_LOCATION@/etc/gridss/impi-jdef.xml</Environment> < !-- Environment name="WFML2BPEL_IMPI_JSDL_NAMESPACE">http://schemas.ggf.org/jsdl/2005/11/jsdl</Environment --> </ShellCommand> <BWE_URL>@URLH_BWE@/wsrf/services/BpelWFEngine</BWE_URL>  <JMS_URL>@URLH_JMS@/wsrf/services/ManagedJobFactoryServic</JMS_URL>  </configure>

3.12. Configure restriction to receive jobs by the number of activities When server machine running SS has few memories, large amount of jobs may make

system performance slow down (ex. swap). To avoid this situation, SS can limit the

number of activities in WFML by SS configuration. Parameter of wfml2bpel(1), which is

executed and converts WFML into BPEL, in WWM ( which is one of componets of SS

Server) configuration file sets the limit number of activities. We describe how to set the

limit number of activities in WWL configuration file below.

42


3.12.1. Procedure To Edit Configuration File WWM configuration file is located as following.

$GRIDSS_LOCATION/etc/gridss/config-wwm3.xml

Please refer to 3.11.1.Procedure To Edit Configuration File.

3.12.2. Setting parameter Here is a parameter of wfml2bpel to limit the number of activities.

-l | --limit-activity <the number of activities>

If SS receives job which has more than the specified limit number of activities, SS doesn’t

accept it and return an error. If the limit number of activities is “0” or not specified, SS

doesn’t limit the number of activities.

3.12.3. Example of config-wwm3.xml.in.mod (2) Here is an example of config-wwm3.xml.in.mod. Please refer to “B.13.

43

config-wwm3.xml” for details.

<configure> <ShellCommand name="MakeReservations"> <Executable>@GRIDSS_LOCATION@/bin/wfml2bpel</Executable> <Argument>--waitsec</Argument> <Argument>15</Argument> <Argument>--wfid</Argument> <Argument>%W</Argument> <Argument>--limit-activity</Argument> <Argument>32</Argument> <Argument>%D/%I%m</Argument> <Argument>%D/%I%M</Argument> < !-- Environment name="WFML2BPEL_IMPI_JSDL_RESOURCES_PATH">@GRIDSS_LOCATION@/etc/gridss/impi-jrsc.xml</Environment --> < !-- Environment name="WFML2BPEL_IMPI_JSDL_OSNAME">LINUX</Environment--> <Environment name="WFML2BPEL_IMPI_JSDL_PATH">@GRIDSS_LOCATION@/etc/gridss/impi-jdef.xml</Environment> < !-- Environment name="WFML2BPEL_IMPI_JSDL_NAMESPACE">http://schemas.ggf.org/jsdl/2005/11/jsdl</Environment --> </ShellCommand> <BWE_URL>@URLH_BWE@/wsrf/services/BpelWFEngine</BWE_URL>  <JMS_URL>@URLH_JMS@/wsrf/services/ManagedJobFactoryServic</JMS_URL>  </configure>

3.13. Configuration for Long Running Job. Although job running long time requires long lifetime of job resource in WS-GRAM on

computing resource. A point of security view doesn’t allow extension of lifetime. SS server

can extend lifetime and run job for a long time, when client program receives requirement

of extension of certificate expiration time.

Comment) SS old edition (i.e. before v1.0) required install user to configure

gws2-commit.sh and vsc3-cmmit-walk-in.sh file. But user doesn’t need configure them,

because supporting certificate extension function.

44


3.14. Configure start-up script Please configure start-up script to execute SS Server in time of system start-up. Please

configure either one of two according to installation environment, so the following start-up

scripts are located at installation directory in SS Server.

Files application

Start-up script file for RedHat system

like CentOS. $GRIDSS_LOCATION/etc/gridss/init.d.gridss.redhat

$GRIDSS_LOCATION/etc/gridss/init.d.gridss.suse Start-up script file for OpenSuSE

Table 3：Start-up script

Please copy start-up script to /etc/init.d as system administrator and valid it by executing

chkconfig(8). The following is an example.

# cd $GRIDSS_LOCATION/etc/gridss

# cp init.d.gridss.redhat /etc/init.d/gridss # chmod 755 /etc/init.d/gridss # chkconfig --add gridss # chkconfig --list gridss gridss 0:off 1:off 2:off 3:on 5:on 6:off

3.15. How To Configure Logrotation This chapter explains how to configure logrotation for SS Server. We assume that SS

Server’s log is $GRIDSS_LOCATION/var/log/log.ss. (log output file name is configured in

start-up script.)

Please refer to manual of logrotate(1) for more details, because logrotation function of SS

Server utilizes logrotate(1).

3.15.1. Configuration File You have to configure 2 files as described below.

File Application

gridss-logrotate It’s script file that calls logrotate(1)

gridss-logrotate.conf logrotate configuration file

Table 4：configuration file

45


3.15.2. Configure gridss-logrotate Please copy $GRIDSS_LOCATION/bin/gridss-logrotate to /etc/cron.hourly and change

file permissions to 7555 as system administrator (i.e. root user)

# cp $GRIDSS_LOCATION/bin/gridss-logrotate /etc/cron.hourly

# chmod 755 /etc/cron.hourly/gridss-logrotate

3.15.3. Configure gridss-logrotate Please change $GRIDSS_LOCATION/etc/grids/grids-logrotate.conf on SS Server’s host

as SS Server installation user (globus user) according to ④.

① Template File of gridss-logrotate.conf

Please copy template file for grids-logrote.conf.


$ cp gridss-logrotate.conf.tmpl gridss-logrotate.conf

② Format of gridss-logrotate.conf

Here is a format of gridss-logrotate.conf.

log file name [ log file name …] {

Setting value

…

}

③ Item

The followings are major items to configure.

(1) log file name (Required) Please specify log file name which SS Server outputs as full-path.

(2) daily (Required) Log files are rotated every day.

(3) size (file size) (Required) Log files are rotated when they grow bigger than the size bytes. If size is followed

by M, the size if assumed to be in megabytes. If the k is used, the size is in

kilobytes. Please change it according to operation environment.

46


(4) copytruncate（Required） Truncate the original log file in place after creating a copy, instead of moving the

old log file and optionally creating a new one.

(5) notifempty（Required） Do not rotate the log if it is empty.

(6) missingok（Required） If the log file is missing, go on to the next one without issuing an error message.

(7) rotate count（Required） Log files are rotated <count> times before being removed. If count is

0, old versions are removed rather then rotated. Please configure it according to

operational environment.

(8) compress Old versions of log files are compressed with gzip by default.

(9) olddir directory Logs are moved into directory for rotation. The directory must be on the same

physical device as the log file being rotated. Please configure it according to

operational environment.

④ Configuration Example

The following is a sample configuration file.

This example assumes that SS Server’s log is /usr/naregi/SS/var/log/log.ss,

logrotate and cron daemon checks it every hour and logrotate rotates it to log.ss.1.gz

if it grows over 100M bytes.

/usr/naregi/SS/var/log/log.ss { daily size 100M copytruncate notifempty missingok rotate 100 compress # If you want to back log file, uncomment the below lines. # compress # olddir /usr/naregi/SS/var/log/back # postrotate # DATE=`date +%FT%R` # mv /usr/naregi/SS/var/log/log.ss.1.gz /usr/naregi/SS/var/log/log.ss.$DATE.gz # endscript }

47


3.15.4. How To Restart SS Server Please reboot SS Server by start-up script that is configured at “3.14.Configure start-up

script”, if SS Server already is running. Please execute start-up script as root user.

# /etc/init.d/gridss restart Stopping ex1-main: [ OK ] Stopping gridss-statd: [ OK ] Stopping gridss-jlogd: [ OK ] Starting gridss-jlogd: [ OK ] Starting gridss-statd: [ OK ] Starting ex1-main: [ OK ] #

3.15.5. How to check logrotation Please confirm logrotation function according to the following procedure.

① Log in Portal node and submit a job from WFT (or PSE)

② Confirm that SS Server’s log file is bigger than the size which is specified in

gridss-logrotate.conf.

③ Execute gridss-logrotate as system administrator (root user).

$ su

Password:

# /etc/cron.hourly/gridss-logrotate

④ Confirm rotation of SS Server’s log. $ cd $GRIDSS_LOCATION/var/log/

$ ls -l log.ss log.ss.1.gz

-rw-r--r-- 1 globus globus 1024 Jul 5 15:21 log.ss

-rw-r--r-- 1 globus globus 4226 Jul 5 15:21 log.ss.1.gz

NOTICE) log.ss.1.gz is generated when compress parameter is specified in

gridss-logrotate.conf.

3.15.6. Notanda Please don’t put SS Server’s log file on NFS file system, if using logrotate function.

NFS may make logrotation lose a part of SS log, when logrotation rotate log file.

New log file overwrites old one, if rotation number of times is over count. Please

configure count and size in gridss-logrotate.conf so as to save log files for a few

weeks, because log file should be saved for data for investigation.

48


Please keep disk space enough to save total size of files which logrotate rotates.

Submitting a lot of jobs within a short period may make disk full before next

rotation. In this case, please set gridss-logrotate in /etc/crontab directly and

increate rotation count in frequency instead of putting gridss-logrotate file und

er /etc/cron.hourly.

3.15.7. Reference /etc/cron.hour/gridss-logrotate

#!/bin/sh if [ -f “/usr/naregi/SS/etc/gridss/gridss-logrotate.conf” ] then /usr/sbin/logrotate /usr/naregi/SS/etc/gridss/gridss-logrotate.conf fi

3.16. How To Configure SS Client Please configure SS Client according to the following configuration, if your software uses

SS Java API libraries in SS Client.

NOTES) Please refer to “Adoption of New SS Java API in Portal node” about details of SS

Java API setting for Tomcat.

3.16.1. How To Set Configuration File of SS JAVA API Configuration file of SS JAVA API libraries is located in the following directory.

$GRIDSS_LOCATION/java/etc/ss_api.properties

Please copy it to SS JAVA API user’s home directory or /etc/ss_config with the same file

name. It is possible to set it in any directory by system property file. Priority of

configuration file is the following.

① Specified file in “org.naregi.ss.service.client.ConfigManager.PropertyFile”

② User’s $HOME/ss_api.properties. User calls SS Java API library.

③ /etc/ss_config/ss_api.properties

NOTES) We recommend to specify file name by ①, because no configuration file occurs

an error. Please specify system property to JavaVM boot option as following, if you

choice ①.

49


java ¥ -Dorg.naregi.ss.service.client.ConfigManager.PropertyFile=/etc/ss_config/ss_api.properties ¥ -classpath …

Please specify the following parameter in configuration file of SS JAVA API.

Parameter Name Setting Value

myproxy.server.host MyProxy Server host name (FQDN)

myproxy.server.port MyProxy Server’s port number (Default:7512)

myproxy.server.hostDN MyProxy Server host DN

jm.server.host SS(jm) Server host name(FQDN)

jm.server.port SS(jm) Server’s port number

Table 5：SS Java API Parameter that user should configure

NOTES1) If user directly uses proxy certificate with SS JAVA API without MyProxy,

“myproxy.server.*” parameter is NOT required. If user uses MyProxy, please

specify it.

NOTES2) “jm.server.*” parameter should be set if application calls SS JAVA API library

without SS Server hostname and port number.

Executing the following command shows install user host DN.

$ grid-cert-info -s -file /etc/grid-security/hostcert.pem

3.16.2. Configuration of MyProxy If your NAREGI system environment utilizes MyProxy, please conduct the following

configuration. Please edit configuration file on MyProxy server so that user which use SS

Java API can obtain proxy credential from MyProxy. MyProxy configuration file is located

in MyProxy Server as the following file.

$GLOBUS_LOCATION/etc/myproxy-server.config

The following shows parameter and setting value that require a change.

Parameter Name Setting Value

50


authorized_retrievers “*”

Table 6：My Proxy’s Parameter required a change

Please refer to Globus Alliance Home page for details.

http://www.globus.org/toolkit/docs/4.0/security/myproxy

3.16.3. Configure System Property Because SS Java API depends on class libraries which Globus Toolkit 4 provides,

application should be set the following system properties regarding to security of Globus

Toolkit 4 if executing Java VM.

System Property Name Setting Value

GLOBUS_LOCATION Globus Toolkit’s Install directory (Default value’s “/usr/naregi/gt4)

X509_CERT_DIR Directory of certificate like root CA

(Default value is “/etc/grid-security/certificates”)

java.endorsed.dirs endorsed directory

($GLOBUS_LOCATION/endorsed)

java.security.egd source of seed data for SecureRandom

(Please specify /dev/urandom if possible.)

Table 7：System Property required to configure

The following is an example to set above system properties to Java VM option.

java ¥ -DGLOBUS_LOCATION=/usr/naregi/gt4 ¥ -DX509_CERT_DIR=/etc/grid-security/certificates ¥ -Djava.endorsed.dirs=/usr/naregi/gt4/endorsed ¥ -Djava.security.egd=/dev/urandom ¥ -classpath …

NOTICE) Please copy $GLOBUS_LOCATION/endorsed/xalan.jar to endorsed directory

instead of setting java.endorsed.dirs to Java VM option, if Tomcat container use SS

Java API library.

$ cd $CATALINA_HOME/common/endorsed/

$ cp $GLOBUS_LOCATION/endorsed/xalan.jar .

51


3.16.4. Add SS Java API Jar File to CLASSPATH

Please add the following file path to CLASSPATH environment variable.

SS Java API jar file

$GRIDSS_LOCATION/java/lib/gridss-client-2.0.jar

Globus Toolkilt4 jar file

Comment) The following jar files are located in $GLOBUS_LOCATION/lib.

addressing-1.0.jar axis.jar axis-url.jar cog-axis.jar cog-jglobus.jar cog-url.jar commonj.jar commons-beanutils.jar commons-collections-3.0.jar commons-digester.jar commons-discovery.jar commons-logging.jar concurrent.jar cryptix32.jar cryptix-asn1.jar cryptix.jar globus_delegation_service.jar globus_delegation_stubs.jar globus_wsrf_mds_aggregator_stubs.jar globus_wsrf_rendezvous_service.jar globus_wsrf_rendezvous_stubs.jar globus_wsrf_rft_stubs.jar gram-client.jar gram-stubs.jar gram-utils.jar jaxrpc.jar jce-jdk13-133.jar jgss.jar log4j-1.2.8.jar naming-common.jar naming-factory.jar naming-java.jar naming-resources.jar opensaml.jar puretls.jar saaj.jar servlet.jar wsdl4j.jar wsrf_common.jar wsrf_core.jar wsrf_core_stubs.jar wsrf_mds_usefulrp.jar

52


wsrf_mds_usefulrp_schema_stubs.jar wsrf_provider_jce.jar wsrf_tools.jar wss4j.jar xalan.jar xercesImpl.jar xml-apis.jar xmlsec.jar

NOTICE1) Please add above jar files to application’s local directory, if container like

tomcat or etc. uses SS Java API.

NOTICE2) Please copy $GLOBUS_LOCATION/client-configwsdd to application ‘s WEB-INF/classes directory if container like Tomcat or etc. uses Globus Toolkit 4 Java API.

3.16.5. Configure Log File SS Java API prints out log by using Jakarta commons logging library as same as Global

Toolkit4 does. Please configure debug level (debug, info, warn, error, fatal) according to

center’s operation policy. Please set the following in log4j.properties used by system to

gather detail information for investigation.

SOAP Message Information Please set the following parameter to get SOAP message information that Globus

Toolkit 4 library processes.

log4j.category.org.globus.wsrf.handlers.MessageLoggingHandler=DEBUG

SS Java API Information Please set the following parameter to get SS Java API information.

log4j.category.org.naregi.ss.service.client=DEBUG

53


4. Start and Stop SuperScheduler This chapter explains how to run and stop SuperScheduler.

4.1. How To Execute SuperScheduler “Please execute SS Server by using set-up script that is set at “3.14.Configure start-up

script”.

Please execute set-up script as system administrator. Here is an example.

# /etc/init.d/gridss start

Starting gridss-jlogd: [ OK ] Starting gridss-statd: [ OK ] Starting ex1-main: [ OK ] #

Comment) Three processes, that are ex1-main (SS Server), grids-jlogd(Workflow

Tracking Daemon) and grids-statd(Service Status Information Notification Demon),

are executed, if SS Server is executed. Each process’s log file is placed at the

following as default.

ex1-main：

$GRIDSS_LOCATION/var/log/log.ss

gridss-jlogd：

$GRIDSS_LOCATION/var/log/jlogd.log

gridss-statd：

$GRIDSS_LOCATION/var/log/gridss-statd.log

4.2. How To Stop SuperScheduler Please execute set-up script that is configured at “3.14.Configure start-up script” as

system administrator to stop SS Server. The following is an example.

# /etc/init.d/gridss stop

Stopping ex1-main: [ OK ] Stopping gridss-statd: [ OK ] Stopping gridss-jlogd: [ OK ] #

54


5. Uninstall SuperSchedler Please check that ex1-main, grids-jlogd and gridss-statd is not running, and delete install

directory. Please confirm that install directory doesn’t exist.

$ ps –aef | grep ex1-main

$ ps –aef | grep gridss-jlogd $ ps –aef | grep gridss-statd $ rm –fr $GRIDSS_LOCATION $ ls $GRIDSS_LOCATION

Please disable SS Server’s set-up script as system administrator.

# chkconfig --del gridss

55


6. Upgrade SuperScheduler This chapter shows upgrade procedure of SuperScheduler. Please refer to “6.1.Upgrade

Procedure from old edition to multiple SS version”, if upgrading from single SS version.

Please refer to “6.2.How to upgrade multiple SS version”, if upgrading from multiple SS.

6.1. Upgrade Procedure from old edition to multiple SS version Because multi SS version and old edition, that is single SS version, is no compatible, if

you install multi SS version to your operation environment where old edition was installed,

please uninstall old edition and newly install multiple SS version.

$GRIDSS_LOCATION/etc/gridss/GridSS-release

Reference) The following is a procedure to uninstall old edition.

① Stop (SS Server only)

Please confirm ex1-main process by ps(1) and terminate the process by kill(1).

Please confirm ex1-main process doesn’t exist by ps(1) after the process

terminated. The following is an example. It assumes that process id of ex1-main is

<pid>.

$ ps –eo pid,comm | grep ex1-main

<pid> ex1-main

$ kill <pid>

$ ps –eo pid,comm | grep ex1-main

$

② Uninstall

Please remove old edition’s install directory. After remove it, please check that NO

install directory exists.

$ rm –fr $GRIDSS_LOCATION

$ ls $GRIDSS_LOCATION

6.2. How to upgrade multiple SS version The following is a procedure to upgrade multiple SS version. If you upgrade SS Server,

56


please refer to “6.2.1.How to upgrade SS Server”. If you upgrade SS Client, please refer

to “6.2.2.Upgrade Procedure of SS Client”.

Comment) Version number is described on the following file.

$GRIDSS_LOCATION/etc/gridss/GridSS-release

6.2.1. How to upgrade SS Server Please upgrade SS Server according to the following procedure.

① Stop

Please stop SS Server according to “4.2.How To Stop SuperScheduler” procedure.

② Backup configuration files

Please backup the following file and configuration files (*.in.mod), if you want to use

current configuration after upgrading.

File Name

（relative path from

$GRIDSS_LOCATION）

Description

etc/gridss/gridss-global.env global information for grids-mkconf

etc/gridss/gridss-local.env local information for gridss-mkconf

etc/gridss/gridss.conf ex1-main http/soap server’s configuration File

etc/gridss/config-ssls.xml SSL/TLS Security Context Definition File

etc/gridss/config-dlg3.xml Delegation Service’s configuration file

etc/gridss/config-jms3.xml Job Manager’s configuration file

etc/gridss/config-eps3.xml Execution Planning Service’s configuration file

etc/gridss/config-csg3.xml Candidate Set Generator’s configuration file

etc/gridss/config-asc3.xml Aggregation Service Container’s configuration file

etc/gridss/config-rcs3.xml Reservation Cache Service’s configuration file

etc/gridss/config-vsc3.xml Virtual Service Container’s configuration file

etc/gridss/config-fsc3.xml File Service Container’s configuration file

etc/gridss/config-bwe3.xml Bpel Workflow Engine’s configuration file

etc/gridss/bwe-sc0b.pdd Bpel Workflow Engine’s PDD file

etc/gridss/bwe-sc0b.wsdl Bpel Workflow Engine’s WSDL file

57


etc/gridss/config-wwm3.xml Wfml Workflow Manager’s configuration file

handle file to access Naregi Distributed Information S

ervice etc/gridss/gridis-handle

etc/gridss/gridis-lrps-sslconf.xml Workflow Tracking Daemon’s SSL configuration file

etc/gridss/gridss-lrps-epr.xml Workflow Tracking Daemon’s EPR file

SuperScheduler’s staus information file etc/gridss/gridss-status.xml

etc/gridss/gridss-logrotate.conf logrotate’s configuration file

etc/gridss/xsl/jins2sql.xsl CSG’s XSLT file

etc/gridss/xsl/qres2jins.xsl CSG’s XSLT file

etc/gridss/xsl/vsc3-reserve-walk-in.xsl VSC’s XSLT file

Table 8：List of Backup files

③ Uninstall

Please uninstall SS Server according to “ Chapter 5.”

④ Reinstall

Please uninstall SS Server according to “2.SuperScheduler Installation”

⑤ Restore backup files ( or setup again)

Please put files that were copied at procedure 2 on the previous directory, if you

want to use previous configuration. If you want to configure SS again, please set SS

Server again according to “Chapter 3.” procedure.

⑥ Restart

Please restart SS Server according to “4.1.How To Execute SuperScheduler”.

6.2.2. Upgrade Procedure of SS Client Please upgrade SS Client according to the following procedure.

① Backup SS Java API configuration file

Please backup configuration file, if configuration file is located in SS Client install

directory.

Comment) Please refer to “3.16.1.How To Set Configuration File of SS JAVA API” to

see how to locate SS Java API configuration file.

58


② Uninstall

Please uninstall SS Client according to “5.Uninstall SuperSchedler”.

③ Re-install

Please install SS Client according to “2.SuperScheduler Installation”.

④ Restore backup files (or Setup again)

Please place files, which were copied at procedure 1, in previous directory, if you

use SS previous configuration. Please setup SS Client according to “3.16.How To

Configure SS Client” again, if you want to configure SS Client.

59


Appendix A. Operation Check by Sample Program SS Package includes SS Java API’s sample program. The following shows how to check

operation of SuperScheduler by using this sample program. We assume that

configuration of SS Java API that is shown at “3.16.How To Configure SS Client” is

finished.

A set of sample program is placed in the following directory.

$GRIDSS_LOCATION/java/etc/sample

Here is an example of table of contents.

File Name Description

Test.java Sample source program

build.sh Script file to build Test.java

test.sh Script file to execute sample program

Table 9：contents of sample program

A.1. Preparation to use sample program This section explains dead work to use sample program.

A.1.1. Build Sample Program Please execute build.sh to build Test.java. The following is an example.

$ sh build.sh

$

Please check that Test.class file is created and exit status is “0” by executing the following

command.

$ echo $?

0

A.1.2. Preparation of TEST WFML Please make up WFML file used input file for sample program. Here is an example of

WFML file.

60


<?xml version="1.0" encoding="UTF-8" ?> <definitions xmlns="http://www.naregi.org/wfml/02" name="mainstage" > <serviceProvider name="pbg1010_njs" type="NAREGI" > <locator handle="ssl://pbg1010.naregi.org:4433" type="local" /> </serviceProvider> <activityModel> <activity name="simple#3"> <jsdl> <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> <JobDescription> <Application> <POSIXApplication xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <Executable>echo</Executable> <Argument>abc</Argument> <WorkingDirectory>/tmp</WorkingDirectory> <WallTimeLimit>30</WallTimeLimit> </POSIXApplication> </Application> </JobDescription> </JobDefinition> </jsdl> </activity> </activityModel> <compositionModel> <importModel /> <exportModel> <exportedActivity> <exportedActivityInfo name="wf1" serviceName="pbg1010_njs" /> <controlModel controlIn="wf1" > <controlLink label="WFTEN" source="simple#3" /> </controlModel> </exportedActivity> </exportModel> </compositionModel> </definitions>

A.1.3. Get Proxy Certificate Get proxy certificate from Myproxy server by using mporxy-logon(1). Here is a command

usage to get proxy certificate.

myproxy-logon -s <myproxy server name> -l <myproxy account name>

The following is an example. Please enter suitable strings, so the command request

Myproxy pass phrase.

61


$ myproxy-logon -s png2044.naregi.org -l b2test19

Enter MyProxy pass phrase:

A proxy has been received for user b2test19 in /tmp/x509up_u1074.

$

A.2. Execute Sample Program The following is an example to execute sample program.

Comment) --help option shows options of sample program in detail.

A.2.1. Submit Workflow Here is a command usage to submit workflow.

test.sh submit -batch <wfml file path> -proxy <proxy file path>

Please execute sample program and submit workflow. Please save job id by redirecting

standard output, because job id is returned if submitting workflow successfully. Here is an

example.

$ sh test.sh submit -batch sample.wfml –proxy /tmp/x509up_u1074 > jobid

$

Please check that SS Java API doesn’t throw exception and job id is returned. Please

check configuration including the other components, if Exception is thrown.

A.2.2. Check Workflow Status Here is command usage to get workflow status.

test.sh status <jobID file path> -proxy <proxy file path>

Please get workflow status to execute sample program. Here is an example.

If workflow is running: $ sh test.sh status jobid –proxy /tmp/x509up_u1074

State: Active 0 ->

$

62


If workflow terminated: $ sh test.sh status jobid –proxy /tmp/x509up_u1074

State: Done 0 ->

$

Please check SS Java API library doesn’t throw and workflow status is returned. If

Exception is thrown, please check setting including the other component.

A.2.3. Destroy Workflow Here is a command usage to destroy workflow.

test.sh delete <jobID file path> -proxy <proxy file path>

Please delete workflow by execute sample program. The following is an example.

$ sh test.sh delete jobid –proxy /tmp/x509up_u1074

$

Please check SS Java API doesn’t throw exception. Please check configuration including

the other component, if exception is thrown.

63


Appendix B. Reference of Configuration file We describe the specification of configuration files that each component running on Supper

Scheduler has as the following.

ex1-main http/soap Server configuration file …gridss.conf

SSL/TLS Security context definition file …config-ssls.xml

Delegation Service configuration file …config-dlg3.xml

Job Manager configuration file …config-jms3.xml

Execution Planning Service configuration file …config-eps3.xml

Candidate Set Generator configuration file …config-csg3.xml

Aggregation Service Container configuration file …config-asc3.xml

Reservation Cache Service configuration file …config-rcs3.xml

Virtual Service Container configuration file …config-vsc3.xml

File Service Container configuration file …config-fsc3.xml

Bpel Workflow Engine configuration file …config-bwe3.xml

Bpel Workflow Engine PDD file …bwe-sc0b.pdd

Wfml Workflow Manager configuration file …config-wwm3.xml

Workflow tracking SSLconfiguration file …gridis-lrps-sslconf.xml

SuperScheduler status information file …gridss-status.xml

64


B.1. gridss.conf 【NAME】

gridss.conf － ex1-main http/soap server configuration file

【SYNOPSIS】 $GRIDSS_LOCATION/etc/gridss/gridss.conf

【DESCRIPTION】 Here is an example of gridss.conf

<configure> <rlimit name="xsd:NCName">xsd:nonNegativeInteger | "unlimited"</rlimit> * <moduledir>xsd:URI</moduledir> ? <sock-base> <moduledir>xsd:anyURI</moduledir> ? <sock-http-proxy> <http-proxy> <pattern>xsd:string</pattern> <pserver>xsd:string</pserver> </http-proxy> * <secure-socket-layer> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </secure-socket-layer> * </sock-http-proxy> * </sock-base> ? <http-base> <moduledir>xsd:anyURI</moduledir> ? <http-message-coder> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </http-message-coder> ? <http-content-coder> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </http-content-coder> ? <http-user-endpoint> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </http-user-endpoint> ? </http-base> ? <wsif-base> <ws-sec> <host-key passphrase=”xsd:string”>xsd:string</host-key> <host-cert>xsd:string</host-cert>+ <internal-actions> <internal-action>xsd:anyURI</internal-action>* </internal-actions> <cert-verify-strictly/> <cert-verify-loosely > </ws-sec> </wsif-base> <soap-base> <moduledir>xsd:anyURI</moduledir> ? <soap-http-endpoint>

65


<module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </soap-http-endpoint> <soap-header-module> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </soap-header-module> <soap-attach-module> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </soap-attach-module> <soap-user-endpoint> <backlog>xsd:nonNegativeInteger</backlog> <module conf="xsd:anyURI" url="xsd:anyURI" sslx="xsd:anyURI">xsd:anyURI</module> * </soap-user-endpoint> ? </soap-base> ? </configure>

We describe the followings elements

/configure/rlimit

This parameter calls setrlimit(2) which is command to change resource limit. It is possible

to specify “unlimited” as special value.

/configure/rlimit/@name

It specifies resource name. Resource name which user can specify is the following.

cpu (Please refer to RLIMIT_CPU of setrlimit(2))

fisze (RLIMIT_FSIZE)

data (RLIMIT_DATA)

stack (RLIMIT_STACK)

core (RLIMIT_CORE)

rss (RLIMIT_RSS)

nofile (RLIMIT_NOFILE)

as (RLIMIT_AS)

nproc (RLIMIT_NPROC)

memlock (RLIMIT_MEMLOCK)

locks (RLIMIT_LOCKS)

Don’t forget that /configure/rlimit doesn’t change resource limit if specified value is smaller

than current resource limit on your system.

NOTICE)_USE_LARGEFILE is not supported yet

/configure/moduledir

66


It is a default value in the following module elements, when you describe by the relative

path.

/configure/sock-base

It defines configuration of communication SOCKET layer.

/configure/sock-base/moduledir

It becomes a default relative path in the module element in sock-base at the

back when the value is described .

/configure/sock-base/sock-http-proxy

HTTP PROXY is set.

/configure/sock-base/sock-http-proxy/http-proxy

It specify Each entry of HTTP PROXY.

/configure/sock-base/sock-http-proxy/http-proxy/pattern

The pattern of the match is specified. The form is the following.

[positive part] ! [negative part]

The access to the host which matches it to positive part except negative part

means by way of the HTTP PROXY server specified for pserver.

In ”Positive part" and "Negative part", list of host name which is delimited by null

character (SPC or TAB), semicolon (";") or comma (“,”), or IP address which has

numeric form (for instance “10.124.102.37”) is specified.

"*.fujitsu.com" that specifies "*" that shows an arbitrary host as a special host name

and a specific domain can be specified.

Moreover, the net mask value like "10.124.102.0/24" can be specified for special

Internet Protocol address.

/configure/sock-base/sock-http-proxy/http-proxy/pserver

Specify the server of HTTP PROXY. Specify it in the form of URL like

http://host:8080/""

/configure/sock-base/secure-socket-layer

It enables connection on SSL/TLS. It enables connect with https (HTTP over

67


SSL/TLS).

/configure/sock-base/secure-socket-layer/module

SSL/TLS の各セキュリティコンテキストを定義します。

It defines each security context of SSL/TLS.

各属性への指定値について以下に説明します。

Here are descriptions about attribute’s valuables.

@conf It specifies path of SSL/TLS configuration file. Default path is

${GRIDSS_LOCATION}/etc/gridss/config-ssl3.xml.

@url 将来のために予約されており、使用してはなりません。

It’s reserved attribute for the future. Don’t use it.

@sslx It’s security context name. The default value is “/”. Specified value of the

attribute must be unique within a configuration file.

Value of module element must not be nil and if nil is set, it isn’t used.

/configure/http-base

It defines configuration relating to HTTP protocol layer.

/configure/http-base/moduledir

If relative path in module element of http-base is specified, it becomes default

value,

/configure/http-base/http-message-coder

It specifies module processing HTTP header.

/configure/http-base/http-content-coder

It specifies module processing HTTP body.

/configure/http-base/http-user-endpoint

It specifies HTTP module which access to SOCKET directly.

NOTICE) It’s used for test.

/configure/wsif-base

It defines configuration relating to wsif library.

68


/configure/wsif-base/ws-sec

It defines configuration relating to WS-Security.

/configure/wsif-base/ws-sec/host-key

It specifies the file that include SS host key, used for XML digital signature.

/configure/wsif-base/ws-sec/host-key@passphrase

Please specify password, if private key is protected by it.

/configure/wsif-base/ws-sec/host-cert

Please set the file including SS host certificate, which is used for XML digita

l signature. Please specify certificate files corresponding to certificate chain in

cluding well-known CA in order from signed certificate to signer certificate, if

Issuer of SS host certificate is not root CA or pursuant intermediate CA to b

e able to access..

/configure/wsif-base/ws-sec/internal-actions

It means begging of Action description for SS internal service.

/configure/wsif-base/ws-sec/internal-actions/internal-action

It specifies URI corresponding to (Request) Action in SS internal service. Security

information is included automatically in SOAP header to carry it between services,

when SS requests Action described here.

/configure/wsif-base/ws-sec/cert-verify-strictly

If this element is specified and SS fails to verify certificate chain for signature and

proxy certificate, SS assumes an error occurred. If this element is not specified

expressly, SS assumes that such as “cert-verify-loosely” is specified.

/configure/wsif-base/ws-sec/cert-verify-loosely

In case of this element is specified and SS fails to verify signer and proxy certificate

chain, SS outputs warning to log file, but SS doesn’t regard it as an error.

/configure/soap-base

It defines configuration for SOAP protocol layer.

69


/configure/soap-base/moduledir

It is a default value when you describe by the relative path in the module

element in soap-base at the back.

/configure/soap-base/soap-http-endpoint

Specify soap module to access HTTP directly.

/configure/soap-base/soap-header-module

It specifies module to procedure SOAP HEADER. (Not supported yet)

/configure/soap-base/soap-attach-module

It is for expanded SOAP procedure module. (Not supported yet)

/configure/soap-base/soap-user-endpoint

It specify service module which runs on SOAP.

Please refer to "How to change service URL" and “How to change file path

for configuration of each service” to be described later.

/configure/soap-base/soap-user-endpoint/backlog

It specifies max length of socket receiving queue against service request. This element

means a backlog parameter to call listen(2). The default value is 1024.

/configure/soap-base/soap-user-endpoint/module

It specifies each service module running on SOAP. Here is an explanation about values specified to each attributes.

@conf It specifies path name of configuration file for service module. Please see

specification of service module about default path.

@url It specifies service module URL. Please refer to specification of service

module about default URL.

@sslx This is the name of security context. Default value is “/”. The value specified

to the attribute must be either one in

“/configure/sock-base/secure-socket-layer/module/@sslx”.

If the value of @sslx doesn’t exist, SS fails to execute.

How to chance service URL:

install user can change service URL by specifying module/@url attribute as each

70


service module at /configure/soap-base/soap-user-endpoint/module in

configuration file.

Ex1: Change address port.

<module url="//myhost.com:8008/">JobManagerService_skel.la</module>

Ex2: Change Scheme and address port.

<module url="https://myhost.com:8008/">JobManagerService_skel.la</module>

Ex3: Change scheme address port and path <module url="https://myhost.com:8008/wfrf/services/JobManager2">JobManagerServ

ice_skel.la</module>

Notice)Current SS doesn’t check whether address port is effective or not,

when it is set at model/@url. The Later version SS check them.

Moreover, two or more services can be operated on the ex1-main server. In this

case, you can specify a different port at each service.

<module url="//localhost:8008/">JobManagerService_skel.la</module> module url="//localhost:8080/JM2">JobManagerService_skel.la</module> <module url="//localhost:8080/JM3">JobManagerService_skel.la</module>>

How to configure File path of each service Configuration file:

User can change a default configuration path of each service module by specifying

module/@conf attribute at /configure/soap-base/soap-user-endpoint/module in the

configuration file.

Exchange default configuration path into /home/ichiro/config.xml

<module conf="/home/ichiro/config.xml">JobManagerService_skel.la</module>

71


B.2. config-ssls.xml 【NAME】

config-ssls.xml － SSL/TLS Security context definition file

【SYNOPSIS】 $GRIDSS_LOCATION/etc/gridss/config-ssls.xml

【Description】 The following is format of config-ssls.xml.

<configure> <SSLProtocol>xsd:string<SSLProtocol> ? <SSLOptions>xsd:string<SSLOptions> * <SSLCipherSuite>xsd:string<SSLCipherSuite> ? <SSLCertificateFile>xsd:anyURI<SSLCertificateFile> ? <SSLCertificateChainFile>xsd:anyURI<SSLCertificateChainFile> ? <SSLCertificateKeyFile>xsd:anyURI<SSLCertificateKeyFile> ? <SSLCertificateKeyPassword>xsd:string<SSLCertificateKeyPassword> ? <SSLCACertificateFile>xsd:anyURI<SSLCACertificateFile> ? <SSLCACertificatePath>xsd:anyURI<SSLCACertificatePath> ? <SSLCARevocationFile>xsd:anyURI<SSLCARevocationFile> ? <SSLCARevocationPath>xsd:anyURI<SSLCARevocationPath> ? <SSLVerifyPeer>xsd:string<SSLVerifyPeer> ? <SSLVerifyClient>xsd:string<SSLVerifyClient> ? <SSLVerifyDepth>xsd:nonNegativeInteger<SSLVerifyDepth> ? <SSLVerifyOptions>xsd:string<SSLVerifyOptions> * </configure>

We describe the following elements.

/configure/SSLProtocol

It specifies SSL protocol and version. Settable value is either TLSv1, SSLv3,

SSLv2 or All. This value is used to select method parameter (SSL_METHOD* type)

of OpenSSL_CTX_new() function. It’s similar to SSLProtocol directive of mod_ssl.

Be aware that it’s case-sensitive, default value is TLSv1 and it’s not described as

such “Al –SSLv2” in this specification.

Example:

<SSLPrococol>SSLv3</SSLProtocol>

/configure/SSLOptions

It specifies various option for SSL protocol.

Please refer to OpenSSL_SSL_CTX_set_options(3) about settable value.

72


If SSLOptions is not specified, the following values are set.

SSL_OP_NO_SSLv2 SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS

This value is option’s argument for OpenSSL_SSL_CTX_set_options() function.

This isn’t similar to mod_ssl of SSLOptions directive.

Example: <SSLOptions>SSL_OP_NO_SSLv2</SSLOptions> <SSLOptions>SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS</SSLOptions>

/configure/SSLCipherSuite

It specifies cipher list which should be used. “openssl ciphers –v” command is

helpful to know settable value. This value is set to str parameter of

OpenSSL_SSL_CTX_set_cipher_list() function. It’s similar to SSLCipherSuite

directive of mod_ssl.

Example:

<SSLCipherSuite>ALL:NULL-MD5</SSLCipherSuite>

/configure/SSLCertificateFile

Please specify path name of certificate file, which is PEM style, on SS. This

parameter and SSLCertificateChainFile are basically exclusive. But if both of them

are specified, SSLCertificateChainFile is priorier to the other. This value is set to

file parameter of SSL_CTX_use_certificate_file() function. This is similar to

SSLCertificateFile directive of mod_ssl.

Example:

<SSLCertificateFile>/etc/grid-security/hostcert.pem</SSLCertificateFile>

/configure/SSLCertificateChainFile

It specifies path name of PEM style certificate chain file on SS. This parameter and

SSLCertificateChainFile are exclusive. But if both of them are specifed,

SSLCertificateChainFile is priorier to the other. This value is file parameter of

OpenSSL_CTX_use_certificate_chainfile() function. this’s similer to

SSLCertificateChainFile directive of mod_ssl.

If SSLCertificateChainFile is specified and SSLCertificateKeyFile is not specified,

Be aware that SS calls OpenSSL_SSL_CTX_use_PrivateKey_file() function with

file parameter as value of SSLCertificateChainFile. It is specified to support that

certificate chain has private key information.

73


Example:

<SSLCertificateChainFile>/tmp/x509_u300</SSLCertificateChainFile>

/configure/SSLCertificateKeyFile

It specifies path name of PEM style private key file on SS corresponding to

SSLCertificateFile and SSL_CertificateChainFile. This value is file parameter for

OPENSSL_SSL_CTX_use_PrivateKey_file() function. Be aware that

SSL_CTX_usr_PrivateKey_file() gets private key information which is first found in

the file. This is similar to SSLCertificateKeyFlle directive. If private key file isn’t

encrypted, pay attention to the file permission of private file.

Example：

<SSLCertificateKeyFile>/etc/grid-security/hostkey.pem</SSLCertificateKeyFile>

/configure/SSLCertificateKeyPassword

Please specify passphrase for encrypted key file that is specified to

SSLCertificateKeyFile. Setting makes program run without prompting passphrase.

WARNING) Be aware of management of configuration file, if this parameter is set.

Example:

<SSLCertificateKeyPassword>doublewhopper2007</SSLCertificateKeyPassword>

/configure/SSLCACertificateFile

Please specify path name of CA certificate file that has PEM style.

This value is Cafile parameter for OpenSSL_SSL_CTX_load_verify_locations()

function. You can specify both of SSLCACertificateFile and SSLCACertificatePAth.

It's similar to SSLCACertificateFile directive of mod_ssl.

Example:

<SSLCACertificateFile>/etc/grid-security/CA.pem</SSLCACertificateFile>

74


/configure/SSLCACertificatePath

Please specify directory which PEM style CA certificate is stored. You may also

specify multiple directories by delimiter “:”. This value is used for CApath parameter

of OpenSSL_SSL_CTX_load_verify_locations() function. You may also specify

both of SSLCACertificateFile and SSLCACertificatePath. It’s similar into

SSLCACerficatePath directive of mod_ssl.

NOTICE) Just putting PEM style CA certificate file doesn’t make this directory

effective. You have to create symbolic file whose filename is hash value of the

certificate.

Example: <SSLCACertificatePath>/etc/grid-security/certificates:/etc/grid-security/vomsdir</SSLCACertificatePath>

/configure/SSLCARevocationFile

Please specify the path name of certificate revocation list (CRL) with PEM style.

This value is used for Cafile parameter of

OpenSSL_SSL_CTX_load_verify_locations() function.. You may also specify both

of SSLCARevocationFile and SSLCARevocationPAth. This is similar to

SSLCARevocationFile directive of mod_ssl.

Example:

<SSLCARevocationFile>/etc/grid-security/crl.pem</SSLCARevocationFile>

/configure/SSLCARevocationPath

Please specify directory where PEM style certificate revocation list (CRL) is stored.

You may specify multiple directories by “:” delimiter. This value is used for Capath

parameter of OpendSSL_SSL_CTX_load_verify_location() function. You may

specify both of SSLCARevocationFile and SSLCARevocationPath. This is slimier

into SSLCARevocationPath directive.

NOTICE) Just putting PEM style certificate revocation list file in this directory

doesn’t make it effective. You have to create symbolic file whose name is hash

value of certificate revocation list.

Example:

<SSLCARevocationPath>/etc/grid-security/revocations</SSLCARevocationPath>

75


/configure/SSLVerifyPeer

Please specify how to verify other side certificate. Settable types are the following.

none 証明書を必要としない

optional 正しい証明書ならあってもよい

require 正しい証明書が必須

optional_no_ca 正しい証明書だが、完全には検証可能でなくてもよい

none It does not require certificate

optional If certificate isn’t regular, it ignore the certificate.

But if certificate is regular, it verify.

require It require regular certificate

optional_no_ca Regular certificate is needed, but it doesn’t require the certificate

is verifiable perfectly.

Default value is “none”. (However if SSLCACertificateFile or SSLCACertificatePath

is specified, default value is “require”.) This value is passed to mod parameter of

OpenSSL_SSL_CTX_set_verify() function. This parameter is similar into

SSLVerifyClient directive of mod_ssl.

Example:

<SSLVerifyPeer>require</SSLVerifyPeer>

/configure/SSLVerifyClient

It’s the same as SSLVerifyPeer and compatible of mod_ssl.

/configure/SSLVerifyDepth

It specifies the number of deeps to CA certificate to verify other side certificate.

Default value is 9. SS doesn’t regard the certificate valid certificate, if SS can’t find

CA certificate until this deeps. This value is passed to depth parameter of

OpenSSL_SS_CTX_set_verify_depth() function. This is similar into

SSLVerifyDepth directive of mod_ssl.

Example:

<SSLVerifyDepth>16</SSLVerifyDepth>

/configure/SSLVerifyOptions

Here is a settable value. (Please refer to OpenSSL openssl/x509_vfy.h for details)

76


X509_V_FLAG_CB_ISSUER_CHECK X509_V_FLAG_USE_CHECK_TIME X509_V_FLAG_CRL_CHECK X509_V_FLAG_CRL_CHECK_ALL X509_V_FLAG_IGNORE_CRITICAL X509_V_FLAG_X509_STRICT X509_V_FLAG_ALLOW_PROXY_CERTS X509_V_FLAG_EXPLICIT_POLICY X509_V_FLAG_INHIBIT_ANY X509_V_FLAG_INHIBIT_MAP X509_V_FLAG_NOTIFY_POLICY

Here is a default value.

0 X509_V_FLAG_ALLOW_PROXY_CERTS X509_V_FLAG_CRL_CHECK (if SSLCARevocation{File,Path} exists) X509_V_FLAG_CRL_CHECK_ALL(if SSLCARevocation{File,Path} exists)

This value is passed to flags parameter of OpenSSL_X509_STORE_set_flags()

function. No directive corresponds to mod_ssl.

Example: <SSLVerifyOptions>-X509_V_FLAG_X509_STRICT</SSLVerifyOptions> <SSLVerifyOptions>+X509_V_FLAG_IGNORE_CRITICAL</SSLVerifyOptions>

77


B.3. config-dlg3.xml 【NAME】

config-dlg3.xml － Configuration of Delegation Service

【SYNOPSIS】 $GRIDSS_LOCATION/etc/gridss/config-dlg3.xml

【DESCRIPTION】 Here is a format of config-dlg3.xml.

<configure> <UserProxyService_URL>xsd:anyURI</UserProxyService_URL> <DelegationService_URL>xsd:anyURI</DelegationService_URL> <workspace>xsd:string</workspace> <myproxy-init> <Executable>xsd:string</Executable> <Environment name=”xsd:string”>xsd:string</Environment>* </myproxy-init> <myproxy-logon> <Executable>xsd:string</Executable> <Environment name=”xsd:string”>xsd:string</Environment>* </myproxy-logon> <myproxy-destroy> <Executable>xsd:string</Executable> <Environment name=”xsd:string”>xsd:string</Environment>* </myproxy-destroy> </configure>

Here is an explanation for each element.

/configure/UserProxyService_URL

It specifies UserProxy Service URL.

/configure/DelegationService_URL

It specifies Delegation Service URL.

/configure/workspace

It specifies absolute path for work space directory to save temporary data of

Delegation Service.

/configure/myproxy-init

It defines setting to execute myproxy-init(1).

/configure/myproxy-init/Executable

78


It specifies absolute path for myproxy-init(1).

/configure/myproxy-init/Environment

It specifies environment variable to run myproxy-init(1).

/configure/myproxy-init/Environment@name

It specifies environment variable name to run mporxy-init(1).

/configure/myproxy-logon

It defines setting to run myproxy-logon(1). Description under this element is the

same as under “/configure/myproxy-init”

/configure/myproxy-destroy

It defines setting to run myproxy-destroy(1). The description under this element is

the same as under “/configure/myproxy-init”.

【RELATED ITEM】 Please refer to the following URL for details relating to MyProxy.

http://www.globus.org/toolkit/docs/4.0/security/myproxy/

79


B.4. config-jms3.xml 【NAME】

config-jms3.xml － Job Manager configuration file

【SYNOPSYS】 $GRIDSS_LOCATION/etc/gridss/config-jms3.xml

【DESCRIPTION】 Here is a format of config-jms3.xml.

<configure> <--LogDirectory>xsd:anyURI</LogDirectory--> ? <Service name="xsd:token"> <URL>xsd:anyURI</URL> </Service> * </configure>

The following is an explanation for each element.

/configure/LogDirectory

It specifies path name of output directory for log file. Workflow tracking function

uses the generated log file. If specified directory doesn’t exist, SS fails to execute.

Log file is not generated because this element is commented out as default

/configure/Service

It defines location information to connect Service Container.

/configure/SC/@name

It specifies ServiceContainer type.

/configure/SC/URL

It specifies location information with URL to connect Service Container.

【RELATED ITEM】

Please refer to gridss-jlogd(1) operating instructions for details about Workflow Tracking

Function.

80


B.5. config-eps3.xml 【NAME】

config-eps3.xml － Execution Planning Service configuration file

【SYNOPSIS】 $GRIDSS_LOCATION/etc/gridss/config-eps3.xml

【DESCRIPTION】 Here is a format of config-eps3.xml

<configure>

( <CSG_URL>xsd:anyURI</CSG_URL> | <CSG_EPR>

<wsa:EndpointReference xmlns:wsa="…">…</wsa:EndpointReference> </CSG_EPR> ) ( <ASC_URL>xsd:anyURI</ASC_URL> | <ASC_EPR>

<wsa:EndpointReference xmlns:wsa="…">…</wsa:EndpointReference> </ASC_EPR> )

</configure> Here is an explanation for each element.

/configure/CSG_URL

It specifies URL format as location information of CSG. Location information of

CSG must be specified with either CSG_URL or CSG_EPR.

/configure/CSG_EPR

It specifies EndpointReference format as CSG location information. CSG location

information must be specified with either CSG_URL or CSG_EPR.

/configure/ASC_URL

It specifies ASC location information by URL format. ASC location information must

be specified with either ASC_URL or ASC_EPR.

/configure/ASC_EPR

Please specify ASC location information with EndpointReference format. ASC

location information must be specified with either ASC_URL or ASC_EPR.

81


B.6. config-csg3.xml 【NAME】

config-csg3.xml － Candidate Set Generator’s configuration file

【SYNOPSYS】 $GRIDSS_LOCATION/etc/gridss/config-csg3.xml

【Description】 Here is a config-csg3.xml format.

<configure> <Interval>xsd:nonNegativeInteger</Interval> <ExecutionCount>xsd:nonNegativeInteger</ExecutionCount> <XSLT> <Stylesheet name=”xsd:string”>xsd:string</Stylesheet> * </XSLT> <Database> <MaxConnection>xsd:nonNegativeInteger</MaxConnection> <Host>xsd:string</Host> <Port>xsd:nonNegativeInteger</Port> <DBName>xsd:string</DBName> <UserName>xsd:string</UserName> <UserPassword>xsd:string</UserPassword> ? <SSLMode>xsd:string</SSLMode> ? <Handle>xsd:string</Handle> </Database> <CommandMode/> ? <TemporaryDirectory>xsd:anyURI</TemporaryDirectory> ? <QueryLimit>xsd:nonNegativeInteger</QueryLimit> ? <QueryCommand> <CommandPaths>xsd:string</CommandPaths> <Executable>xsd:string</Executable> <Argument>xsd:string</Argument> * <Environment name="xsd:string">xsd:string</Environment> * </QueryCommand> </configure>

We explain each element as following.

/configure/Interval

It specifies interval (second) to call GenerateCanddateSetRequest. The range of

interval is from 0 to 60. If 0 is specified, timer doesn’t put off. Default value is 30.

/configure/ExecutionCount

Interval configuration specifies the number of requests is executed periodically per

1 interval. Default value is 1.

/configure/XSLT

82


It defines configuration of XSLT style sheet.

/configure/XSLT/Stylesheet

It specifies absolute path of XSLT style sheet.

/configure/XSLT/Stylesheet@name

It specifies name which stands for intended purpose. The following 2 names are

able to set.

JINS2SQL It requests PostgreSQL in distributed information service with

JobInstance document. It specifies XSLT Stylesheet file to generate SQL

statement for resource brokering. If you want to change and fix SQL

statement for resource brokering, it is reflected by changing specified file

and rebooting CSG.

QRES２JINS It specifies XSLT Style sheet file to convert resource brokering outcome

that is retrieved from PostgreSQL in distributed information service, into

XML format (CandidateContainers). If you change or fix conversion rule,

it is reflected by changing specified file and rebooting CSG.

/configure/Database

It defines configuration of database connection.

/configure/Database/ MaxConnection

It sets maximum number which connects database at once. You can set any value

under max_connections in PostgreSQL of distributed information service.

/configure/Database/Host

It sets hostname or IP address of PostgreSQL Server. You can set Ipv4 format or

Ipv6 format (if system supports it) as IP address.

/configure/Database/ Port

It sets port number of PostgreSQL Server. Default value is “5432”.

/configure/Database/DBName

It sets detabase name in PostgreSQL server. Default value is “node”.

83


/configure/Database/UserName

It sets user name to login PostgreSQL server. Default value is “naregiss”.

/configure/Database/UserPassword

It sets password to login PostgreSQL server. Please set password, if it’s required.

/configure/Database/SSLMode

It sets SS connection mode to access PostgreSQL server. This element is optional.

SSL connection (require) is a default behavior. The following 4 values are able to

set.

disable CSG tries to access without encrypted SSL connection.

allow CSG tries to access with none SSL connection. If it fails, it accesses with SSL.

prefer CSG tries to access SSL connection at first. If it fails, it accesses with non

SSL connection.

CSG accesses PostgreSQL only with SSL connection. require

Please refer to PostgreSQL online manual, if you want to know about connecting

PostgreSQL by libpq.

/configure/Database/Handle

It sets path name of handle file which access to distributed information service.

Please refer to “3.7.Configuration To Use Naregi Distributed Information Service”

about creating handle file.

/configure/CommandMode

If this element is set, command access distributed information service to search resources. This is effective way for debug. If this element doesn’t exist, following configuration is ignored.

/configure/TemporaryDirectory

It sets workspace directory to save certificates for running job. Default value is “${GRIDSS_LOCATION}/var/gridss/csg/hostname/”. Reference) hostname is the same as result of hostname(1) where service is running.

84


/configure/QueryLimit

It specifies limitation for the number of processes which CSG execute to query at a

time. Default value is “unlimited”.

Reference) 0 also means “unlimited”.

/configure/QueryCommand

It defines configuration for resource query command

/configure/QueryCommand/CommandPaths

It sets search path to execute command which is set into “/configure/QueryCommand/Executable”.

/configure/QueryCommand/Executable

It specifies command name to query resource.

/configure/QueryCommand/Argument

It sets parameter for command.

The following are rules of string extracted in this element.

%D It extends TemporaryDirectory path of configuration file.

%i It extends JobInstance file path as input. CSG outputs input JobInstance file

to “${HOME}¥%i” whose user executes server.

%j CSG extends unique strings in Query.

%o Path name of generated JobInstance is extended. CSG reads the generated

JobInstance file from “${HOME}¥%o” whose user executes server. %% It is extended to “%”.

NOTICE) In XML specification, letters which is used for tag (i.e. <, >,

&, ’(apostrophe), ”(double quotation)) must be replace to the followings.

& &

< <

> >

&quote; "

' '

/configure/QueryCommand/Environment

85


It sets environment variable specifying query command.

【RELATED ITEM】 Please refer to the following URL for details about PostgreSQL.

Manual: http://www.postgresql.jp/document/pg814doc/html/index.html libpq:http://www.postgresql.jp/document/pg814doc/html/libpq.html

86


B.7. config-asc3.xml 【NAME】

config-asc3.xml － Aggregation Service Container configuration file

【SYNOPSYS】 $GRIDSS_LOCATION/etc/gridss/config-asc3.xml

【DESCRIPTION】 Here is config-asc3.xml format.

<configure>

<RetryLimit>xsd:nonNegativeInteger</RetryLimit> ? <SC name="xsd:string"> ( <URL>xsd:anyURI</URI> |

<EPR> <wsa:EndpointReference xmlns:wsa="...">...</wsa:EndpointReference>

</EPR> ) </SC> *

</configure>

We explain each element below.

/configure/RetryLimit

It defines maximum number which SS retries to make a reservation, if temporary

error occurred.

/configure/SC

It defines location information to connect Service Container such as VSC. Location

information must be set either URL or EPR.

/configure/SC/@name

Please set job execution service type.

/configure/SC/URL

It specifies location information to connect Service Container with URL format.

/configure/SC/EPR

It specifies location information to connect Service Container with

EndpointReference format.

87


B.8. config-rcs3.xml 【NAME】

config-rcs3.xml － Reservation Cache Service configuration file

【SYNOPSYS】 $GRIDSS_LOCATION/etc/gridss/config-rcs3.xml

【DESCRIPTION】 Here is a config-rcs3.xml format.

<configure> <StartOffset>xsd:integer</StartOffset> <Unit>xsd:integer</Unit> <EndOffset>xsd:timeDuration</EndOffset> <PurgePeriod>xsd:integer</PurgePeriod > <SelectionRule>xsd:string</SelectionRule> ? <authorized>

<subject>xsd:string</subject> * </authorized> </configure>

We explain each element below.

/configure/StartOffset

When SS decides start time to search reservation table, it provides offset by

second unit to add current time. It provides 60 (60 second) as default.

/configure/Unit

Start time to search reservation table is rounded by specified seconds. Default

value is 15 seconds.

/configure/EndOffset

It decides to add offset value to start time, when SS decides to the end of time to

search reservation table. Default value is P45DT (45 days).

/configure/PurgePeriod

It defines waiting time to destroy tentative reserved information, if commit is not

done (commit means that GridVMFactory notifies reservation event to SS.).

Default value is 43200 (43200 sec = 60 x 60 x 12 sec = 12 hours).

88


/configure/authorized

It defines list of authorized target. This element is commented out as default.

/configure/authorized/subject

It sets subject name which is authorized to access management interface. If

certificate chain has subject name specified in this element. The entity has

privilege to execute management interface. It can’t ignore white spaces, because

they are compared perfectly. Please set Subject which “openssl x509” command

shows. This element is commented out as Default.

/configure/SelectionRule

It defines SC’s selection algorithm as option. The following two values are settable.

default It’s default selection algorithm. RS selects SC that can execute job the fastest

in SCs. But if start time in SCs is the same, it depends on the order that CSG

has selected SC.

reverse It selects SC whose start time in spare time is the fastest among SCs as well

as default selection rule. But if start time is the same, priority reverses against

default.

89


B.9. config-vsc3.xml [NAME]

config-vsc3.xml － Configuration file of the Virtual Service Container

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/config-vsc3.xml

[Description] The schema of config-vsc3.xml is as follow.

<configure> <TemporaryDirectory>xsd:string</TemporaryDirectory> ? <GRAMPath>xsd:string</GRAMPath>

<ShellCommandSet name="xsd:string"> <ShellCommand name="xsd:string"> <CommandPaths>xsd:string</CommandPaths> <Executable>xsd:string</Executable> <Argument>xsd:string</Argument> * <Environment name="xsd:string">xsd:string</Environment> *

</ShellCommand> * </ShellCommandSet> *

</configure>

The meaning of each element is as follows.


This parameter is the working space directory for storing the certifications of running jobs. The default value is “$ ｛ GRIDSS_LOCATION ｝

/var/gridss/vsc/hostname/” reference）"Hostname" is a name of the same server host as obtaining by the hostname(1)

/configure/GRAMPath

This parameter is the URL Path of WS GRAM. This parameter is indispensable.

/configure/ShellCommandSet

This parameter defines the command set for requesting to the job execution service

of the various grid middleware..

/configure/ShellCommandSet/@name

This parameter is job execution type. The following three execution types are

defined as the default.

90


prews-gram Defining the Pre-WS GRAM command set for job execution request

ws-gram Defining the Globus 4.X GRAM(WS GRAM) command set for job

execution request

ws-gram-gridvm Defining the NAREGI GridVM command set for job execution request

ws-gram-gridss-without-reservation

Defining the NAREGI GridVM without reservation command set for

job execution request

/configure/ShellCommandSet/ShellCommand

This parameter defines the request command for job execution service.

The following three commands, MakeReservations, CommitReservations and

Destroy, definitions are indispensable.

/configure/ShellCommandSet/ShellCommand/@name

This parameter defines the type of request command for job execution service.

Currently the MakeReservations, CommitReservations, Destroy and Status are

allowed.

/configure/ShellCommandSet/ShellCommand/CommandPaths

This parameter defines the search path for specifying

the ”/configure/ShellCommand/Executable” element.

/configure/ShellCommandSet/ShellCommand/Executable

This parameter defines the executable file name path for requesting the job

execution service.

/configure/ShellCommandSet/ShellCommand/Argument

This parameter defines the arguments for executable.

The character expansion rules which are adapted in this element are as follows.

%D The TemporaryDirectory path in this config file is expanded

%I Job identified specific characters are expanded

%m The suffix of JobInstance file for MakeReservations command request is

expanded [value:.jins]

%M The suffix of JobInstance file for MakeReservations command response is

expanded [value: jins]

%c The suffix of xRLS file for CommitReservations command request is

91


expanded. [value:.xRSL]

%C The suffix of GRAM EPR file for CommitReservations command response is

expanded.[value:.gepr]

%p The suffix of the passphrase file of MyProxy is expanded. [value:.pass]

%A The account name of MyProxy (not file name) is expanded

%G The GRAM Factory URL is expanded.

%% Expanded as %

caution) It is necessary to replace characters the following on the specification of XML as

follows.

& &

< <

> >

&quote; "

' '

/configure/ShellCommandSet/ShellCommand/Environment

The environment variables passed to the executable are specified.

92


B.10. config-fsc3.xml [NAME]

config-fsc3.xml － Configuration file of the File Service Container

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/config-fsc3.xml

[Description] The schema of config-fsc3.xml is as follow.

<configure> <TemporaryDirectory>xsd:string</TemporaryDirectory> ? <DefaultScheme>xsd:string</DefaultScheme> <ShellCommand name="xsd:NCName"> <CommandPaths>xsd:string</CommandPaths> <Executable>xsd:string</Executable> <Argument>xsd:string</Argument> * <Environment name="xsd:string">xsd:string</Environment> * </ShellCommand> * </configure>



This parameter is the working space directory for storing the certifications of running jobs. The default value is “$ ｛ GRIDSS_LOCATION ｝

/var/gridss/fsc/hostname/” reference）"Hostname" is a name of the same server host as obtaining by the hostname(1)

/configure/DefaultScheme

When the URI scheme, such as the “http” of the “http://foo.com/bar”, is ”default”, it

is replaced as specified schema.

/configure/ShellCommand

This parameter defines the file operation command.

/configure/ShellCommand/@name

This parameter defines the type of the file operation.

The following two ShellCommand definitions are indispensable.

fop-3rd-party-transfer The shell command lines for the file transfer are defined.

93

http://foo.com/bar


fop-check-file-exist The shell command lines for the file existence inspection

is defined

/configure/ShellCommand/CommandPaths

This parameter defines the search path of the copy command for

“/configure/ShellCommand/Executable”

/configure/ShellCommand/Executable

This parameter defines the file operation command.

/configure/ShellCommand/Argument



%u Entire source URI

%s Schema part of source URI

%h Host part of source URI

%p Port part of source URI

%e User part of source URI

%n Path part of source URI

%q Query part of source URI

%f Fragment part of source URI

%U Entire target URI

%S Schema part of target URI

%H Host part of target URI

%P Port part of target URI

%E User part of target URI

%N Path part of target URI

%Q Query part of target URI

%F Fragment part of target URI

%% Expanded as %

Reference) Structure of URI :scheme://user@host:port/path?query#fragment


follows.

& &

< <

> >

94


&quote; "

' '

/configure/ShellCommand/Environment

The environment variables passed to the file operation command are specified.

The environment variable name is specified to @name, and the value of the

environment variable is specified to an element value.



%j Job identified specific characters are expanded


follows.

& &

< <

> >

&quote; "

' '

Special environment variable

Two environment variables with a special meaning are defined now.

MYPI_ACCT_FILE This service considers the value given to this

environment variable is a file. This service writes

My Proxy server "account name” into the file, as

job execution request people.

MYPI_PASS_FILE This service considers the value given to this

environment variable is a file. This service writes

My Proxy server “pass phrase” into

${MY_PASS_FILE} to access proxy certificate,

as job execution request.

95


B.11. config-bwe3.xml [NAME]

config-bwe3.xml － Configuration file of the Bpel Workflow Engine

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/config-bwe3.xml

[Description] The schema of config-bwe3.xml is as follow.

<configure> <RunStepByStep>xsd:string</RunStepByStep> <PDDFile>xsd:string</PDDFile> <RelocationMapFiles>xsd:string</RelocationMapFiles> </configure>


/configure/RunStepByStep

This parameter is the element for trial.

/configure/PDDFile

This parameter defines the path of the Bpel Workflow Engine

PDD(Process Deployment Descriptor ) file.

/configure/RelocationMapFiles

This parameter defines the location information.

96


B.12. bwe-sc0b.pdd [NAME]

bwe-sc0b.pdd － PDD (Process Deployment Descriptor) file for Bpel Workflow Engine

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/bwe-sc0b.pdd

[Description] The schema of config-vsc3.xml is as follow.

<process name="qname" location="relativeDeploymentLocation">

<partnerLinks> <partnerLink name="ncname">

<partnerRole endpointReference="static|dynamic|invoker|principal"> [... endpoint reference....] ?

</partnerRole>? <myRole service="name" allowedRoles="namelist"? binding="MSG|RPC"/> ? </partnerLink> +

</partnerLinks> <wsdlReferences>

<wsdl namespace="uri" location="uri"/> + </wsdlReferences> ?

</process>

The meaning of major elements are as follows.

/process/@location

Specify the WSDL file which describes usable partnerLinkType for this JobManager

service and JM service itself.

/process/partnerLinks

Enumerate the predefined partnerLinks for this JobManager service.

Ordinary, the partnerLink element is specified for obtaining the EPS

EndpointReference for JM. When the EPS URL is changed, the partnerLink

element should be changed.

/process/wsdlReferences

Enumerate the WSDL which describes the invokable portType/operation for this

JobManager service.

97


[SEE ALSO] Refer the following URL and see the “Process Deployment Descriptor (.pdd)” for the detail

of PDD file.

http://www.activebpel.org/docs/file_formats.html

98


B.13. config-wwm3.xml [NAME]

config-wwm3.xml － Configuration file of the Wfml Workflow Manager

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/config-wwm3.xml

[Description] The schema of config-wwm3.xml is as follow.

<configure> <ShellCommand name="xsd:string"> <Executable>xsd:string</Executable> <Argument>xsd:string</Argument> * <Environment name="xsd:string">xsd:string</Environment> *

</ShellCommand> * <URL>xsd:string</URL>

</configure>


/configure/ShellCommandSet/ShellCommand

This parameter defines the request command. Currently only “MakeReservations”

is the specified. This command definition is indispensable.

/configure/ShellCommandSet/ShellCommand/@name

This parameter defines the type of the request command. Currently only

“MakeReservations” is specified.

/configure/ShellCommandSet/ShellCommand/Executable

This parameter defines the executable file name for request of the handling.

/configure/ShellCommandSet/ShellCommand/Argument


The character expansion rules which are adapted in this element are as follows


%I Job identified specific characters are expanded

%m The suffix of the WFML file for wfml2bpel command request is expanded

[value: .wfml]

99


%M The suffix of the BPEL file for wfml2bpel command response is expanded

[value: .bpel].


follows.

& &

< <

> >

&quote; "

' '

/configure/ShellCommandSet/ShellCommand/Environment

The environment variables passed to the executable are specified.

/configure/SC/URL

This parameter defines the location information of the collaboration Service

Container by the URL format.

100


B.14. gridis-lrps-sslconf.xml [NAME]

gridis-lrps-sslconf.xml － Configuration file for workflow tracking by SSL

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/gridis-lrps-sslconf.xml

[Description] The schema of gridis-lrps-sslconf.xml is as follow.

<configure> <SSLProtocol>xsd:string</SSLProtocol> <SSLCertificateFile>xsd:anyURI</SSLCertificateFile> <SSLCertificateKeyFile>xsd:anyURI</SSLCertificateKeyFile> </configure>

See “B.2.

101


config-ssls.xml”for the detail of each element.

[SEE ALSO] See the gridss-jlogs(1) in the workflow tracking function.

102


B.15. gridss-status.xml [NAME]

gridss-status.xml － SuperScheduler status information file

[SYNOPSIS] $GRIDSS_LOCATION/etc/gridss/gridss-status.xml

[Description] The schema of grids-status.xml is as follow.

<sg:Add xmlns:sg="…">

<sg:MemberEPR xmlns:wsa="…"> <wsa:Address>xsd:anyURI</wsa:Address>

</sg:MemberEPR> <sg:Content xmlns:ripm="…">

<ripm:ServiceName>xsd:string</ripm:ServiceName> <ripm:ServiceVersion>xsd:string</ripm:ServiceVersion> <ripm:operationalStatus>xsd:integer</ripm:operationalStatus> <ripm:SystemName>xsd:string</ripm:SystemName> <ripm:OwnerName>xsd:string</ripm:OwnerName> ? <ripm:ownerContact>xsd:string</ripm:ownerContact> ?

</sg:Content> <sg:InitialTerminationTime>xsd:dateTime</sg:InitialTerminationTime>

</sg:Add>


/sg:Add/sg:MemberEPR/wsa:Address

This parameter defines the service URI.

/sg:Add/sg:Content/ripm:ServiceName

This parameter defines the service name.

/sg:Add/sg:Content/ripm:ServiceVersion

This parameter defines the service version.

/sg:Add/sg:Content/ripm:operationalStatus

This parameter defines the service status.

/sg:Add/sg:Content/ripm:SystemName

This parameter defines the service enable hostname in FQDN format.

103


/sg:Add/sg:Content/ripm:OwnerName

This parameter defines the service admin name in Subject DN format. This

parameter is an optional.

/sg:Add/sg:Content/ripm:ownerContact

This parameter defines the mail-address of service admin.

This parameter is an optional.

/sg:Add/sg:InitialTerminationTime

This parameter defines the time of service expired time.

104


Appendix C. Notanda We describe the SS installation and operation problems, and the solution as below.

The problem which combination of required software makes: We describe that the conditions on which combination of required software make an

error and how to deal with them.

NOTICE:

Same problem occurs on other conditions except for this one.

Symptoms: SS Server hung-up.

Detail: SS Server hung-up and doesn’t run, because grid-proxy-info, grid-proxy-init command

and so on doesn’t return on the following condition..

Operating System OpenSuSE 10.2

Globus Toolkit 4.0.5

grid-proxy-* Flavor gcc32dbgpthr

Workaround: Please use grid-proxy-info and grid-proxy-init generated by gcc32dbg Flavor. Please fix

path names as the following, because SS calls grid-proxy-info and grid-proxy-init under

$GLOBUS_LOCATION/bin directory. You don’t need to re-execute gridss-mkconf and

reboot SS Server after fixing them.

Sample of Fixing: Original $GLOBUS_LOCATION/bin/grid-proxy-info

Fixed $GLOBUS_LOCATION/bin/gcc32dbg/shared/grid-proxy-info

Original $GLOBUS_LOCATION/bin/grid-proxy-init

Fixed $GLOBUS_LOCATION/bin/ gcc32dbg/shared/grid-proxy-init

105


Directory File

${GRIDSS_LOCATION}/bin gridss-grun

gws2-commit.sh

vsc3-commit-walk-in.sh

vsc3-credential-refresh.sh

vsc3-reserve-walk-in.sh

You can verify Flavor of each commands as the following. $ ldd ${GLOBUS_LOCATION}/bin/grid-proxy-init

linux-gate.so.1 => (0xffffe000) libglobus_gsi_proxy_core_gcc32dbgpthr.so.0 => ….... ………………

106