WMS SW Admin and User Guide - Istituto Nazionale di Fisica ...server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0118-1_2.doc · Web viewThe –logfile option allows

WMS SW Admin and User Guide

DataGrid

WP1 - WMS Software Administrator and User Guide

Document identifier:

DataGrid-01-TEN-0118-1_2

Date:

24/11/2003

Work package:

WP1

Partner:

Datamat SpA

Document status

Deliverable identifier:

Abstract: This note provides the administrator and user guide for the WP1 WMS software.

Delivery Slip

Name

Partner

Date

Signature

From

Fabrizio Pacini

Datamat SpA

24/11/2003

Verified by

Stefano Beco

Datamat SpA

24/11/2003

Approved by

Document Log

Issue

Date

Comment

Author

0_0

21/12/2001

First draft

Fabrizio Pacini

0_1

14/01/2002

Draft

Fabrizio Pacini

0_2

24/01/2002

Draft

Fabrizio Pacini

0_3

05/02/2002

Draft

Fabrizio Pacini

0_4

15/02/2002

Draft

Fabrizio Pacini

0_5

08/04/2002

Draft

Fabrizio Pacini

0_6

13/05/2002

Fabrizio Pacini

0_7

19/07/2002

Fabrizio Pacini

0_8

16/09/2002

Fabrizio Pacini

0_9

03/12/2002

Fabrizio Pacini

1_0

13/06/2003

First issue for Release 2.0

Fabrizio Pacini,

Massimo Sgaravatto

1_1

04/09/2003

Fabrizio Pacini

1_2

24/11/2003

Fabrizio Pacini

Document Change Record

Issue

Item

Reason for Change

0_1

General update

· Take into account changes in the rpm generation procedure.

· Add missing info about daemons (RB/JSS/CondorG) starting accounts

· Some general corrections

0_2

General Update

· Add Cancelling and Cancel Reason information.

· Add OUTPUTREADY job state.

· Add new profile rpms.

· Remove /etc/workload* shell scripts.

· Add summary map table (user / daemon).

· Add CEId format check.

· Add new job cancel notification.

0_3

General Update

· Modified RB/JSS start-up procedure

· Add gridmap-file users/groups issues

· Add proxy certificate usage by daemons

· Job attribute CEId changed to SubmitTo

· Add DGLOG_TIMEOUT setting

· Add workload-profile and userinterface-profile rpms

0_4

General Update

· Add configure option –enable-wl for system configuration files

· Add installation checking option –with-globus for Globus to the Workload configure

· Add new Information Index configure options

· Remove edg-profile and edg-user-env rpms from II and UI dependencies

· Add security configuration rpm’s for all the Certificate Authorities to UI dependencies

· Add new parameters to RB configuration file

· Add new Job Exit Code field to the returned job status info

· Remove dependence from SWIG in the userinterface binary rpm

0_5

General Update

· Modify command options syntax (getopt-like style)

· Add MyProxy server and client package installation/utilisation

· Modify job cancel notification

· Add Userguide rpm

0_6

General Update

· Modify configure options for the various components

· UI commands modified to use python2 executable

· Clarify myproxy usage

· Explain how RB/LB addresses in the UI config file are used by the commands

· Add –logfile option to the UI commands

0_7

General Update

· Modify configure options for the various components

· Clarify UI commands –notify option usage

· Add make test target for UI

0_8

General Update

· Specified dependencies of profile rpms

· Update needed env vars for UI

· Explain how to include default constraints in the job requirements

· Explain that the lc field in the ReplicaCatalog address is now mandatory

· Explain how to specify wildcards and special chars in "Arguments" in the JDL expression

0_9

General Update

· Defaults for Rank and Requirements in the UI config file

· Added reference to the “.BrokerInfo” file document

· other.CEId in Requirements vs --resource option

· Explain MyProxy Server configuration

· Added description of new parameters in RB configuration file

· RB/JSS databases clean-up procedure added

· Explain usage of RetryCount JDL attribute

· Better explain how to specify wildcards and special chars in "Arguments" in the JDL expression

· Updated reference to JDL Attributes note

· Added Annex on Submission failures analysis

1_0

General Update

· Refer to WMS release 2

1_1

General Update

· Description of new UI commands options for interactive jobs (--nogui, --nolisten)

· Added annexes section on job re-submission

1_2

General Update

· Add voms client APIs rpms among WMS components dependencies

· Update commands description due to the integration with VOMS

· Remove proxy credential creation from UI commands

· Remove --hours option from UI edg-job-submit command

Files

Software Products

User files

Word 2000

DataGrid-01-TEN-0118-1_2.doc

Acrobat Exchange 5.0

DataGrid-01-TEN-0118-1_2.pdf

Content

101. Introduction

101.1. Objectives of this document

101.2. Application area

101.3. Applicable documents and reference documents

121.4. Document evolution procedure

121.5. Terminology

142. Executive summary

153. workload management system overvieW

173.1. Deployment of the WMS software

204. Installation and Configuration

204.1. Logging and Bookkeeping services

204.1.1. Required software

204.1.1.1. LB local-logger and LB APIs

204.1.1.2. LB Server

214.1.2. Configuration

224.1.2.1. LB Local-Logger

224.1.2.2. LB Server

224.1.3. Environment Variables

244.2. services running in the “rb node”: Ns, wm, jc, lm


244.2.1.1. Globus installation and configuration

244.2.1.1.1. Condor-G installation and configuration

254.2.1.2. ClassAd installation and configuration

254.2.1.3. Boost installation and configuration

254.2.1.4. Replica Manager installation and configuration


264.2.2.1. Configuration of the “common” attributes

274.2.2.2. NS configuration

294.2.2.3. WM configuration

314.2.2.4. JC configuration

324.2.2.5. LM configuration

334.2.3. Environment variables

344.2.4. Other requirements and configurations for the “RB node”

344.2.4.1. Customized Gridftp server

354.2.4.2. Grid-mapfile

354.2.4.3. Disk Quota

364.3. Security Services

364.3.1. MyProxy Server

374.3.2. Proxy renewal service

374.3.2.1. Required software

374.3.2.2. Configuration

384.3.2.3. Environment variables

384.4. Grid accounting services


394.4.1.1. Creating the MySQL databases for the HLR server

394.4.1.2. Creating the MySQL database for the PA server


404.4.2.1. Configuring the HLR server

414.4.2.2. Configuring the PA server

414.4.2.3. Configuring the ATM client software


434.5. User Interface


434.5.1.1. Python Command Line Interface

454.5.1.2. C++ API

454.5.1.3. Java API

464.5.1.4. Java GUI

484.5.2. RPM installation


494.5.2.2. C++ API

494.5.2.3. Java API

504.5.2.4. Java GUI



554.5.3.2. Java GUI



594.5.4.2. Java GUI

605. Operating the System

605.1. LB local-logger

605.1.1. Starting and stopping daemons

615.1.2. Troubleshooting

625.2. LB Server

625.2.1. Starting and stopping daemons

635.2.2. Creating custom indices

655.2.3. Purging the LB database

655.2.4. Experimental R-GMA Interface


665.3. SERVICES RUNNING in the “rb node”: ns, wm, jc, lm

665.3.1. Starting and stopping NS, WM, JC and LM daemons

665.3.2. NS, WM, JC, LM troubleshooting

665.4. Proxy renewal

665.4.1. Starting and stopping daemon


675.5. Purger

695.6. GRID ACCOUNTING

695.6.1. Starting and stopping daemon

695.6.1.1. HLR server

695.6.1.2. PA Server

705.6.2. HLR server administration

715.6.2.1. Creating a Fund account

725.6.2.2. Creating a Group account

735.6.2.3. Creating a User account

745.6.2.4. Creating a Resource account

755.6.2.5. Deleting accounts


755.7. User Interface (Java GUI)


806. User Guide

806.1. User interface

806.1.1. Security

816.1.1.1. MyProxy

816.1.1.1.1. MyProxyClient

836.1.2. Common behaviours

856.1.2.1. The --input option

876.1.3. Commands description

876.1.3.1. edg-job-submit

986.1.3.2. edg-job-get-output

986.1.3.3. edg-job-list-match

986.1.3.4. edg-job-cancel

986.1.3.5. edg-job-status

986.1.3.6. edg-job-get-logging-info

986.1.3.7. edg-job-attach

986.1.3.8. edg-job-get-chkpt

987. ANNEXES

987.1. JDL Attributes

987.2. Job Status Diagram

987.3. Job Event Types

987.4. Submission Failures Analysis

987.5. job Resubmission and RetryCount

987.6. wildcard patterns

987.7. The Match Making Algorithm

987.7.1. Direct Job Submission

987.7.2. Job submission without data-access requirements

987.7.3. Job submission with data-access requirements

1. Introduction

This document provides a guide to the installation, configuration and usage of the WP1 WMS software released within the DataGrid project.

1.1. Objectives of this document

Goal of this document is to describe the complete process by which the WP1 WMS software can be installed and configured on the DataGrid test-bed platforms.

Guidelines for operating the whole system and accessing provided functionalities are also provided.

1.2. Application area

Administrators can use this document as a basis for installing, configuring and operating WP1 WMS software. Users can refer to the User Guide chapter for accessing provided services through the User Interface.

1.3. Applicable documents and reference documents

Applicable documents

[A1]

JDL Attributes - DataGrid-01-TEN-0142-0_0 – 13/06/2003

(http://www.infn.it/workload-grid/docs/DataGrid-01-TEN-0142-0_0.{doc,pdf})

[A2]

Definition of the architecture, technical plan and evaluation criteria for the resource

co-allocation framework and mechanisms for parallel job partitioning

(http://www.infn.it/workload-grid/docs/DataGrid-01-D1.4-0127-1_0.{doc, pdf})

[A3]

DataGrid Accounting System - Architecture v 1.0

(http://www.infn.it/workload-grid/docs/DataGrid-01-TED-0126-1_0.pdf)

[A4]

Logging and Bookkeeping Architecture – DataGrid-01-TED-0141

(http://lindir.ics.muni.cz/dg_public/lb_draft2_formatted.pdf)

[A5]

Job Description Language HowTo – DataGrid-01-TEN-0102-02 – 17/12/2001

(http://www.infn.it/workload-grid/docs/DataGrid-01-TEN-0102-0_2.pdf)

[A6]

The Glue CE Schema

(http://www.cnaf.infn.it/~sergio/datatag/glue/v11/CE/index.htm)

Reference documents

[R1]

The Resource Broker Info file – DataGrid-01-TEN-0135-0_0

(http://www.infn.it/workload-grid/docs/DataGrid-01-TEN-0135-0_0.{doc,pdf})

[R2]

LB-API Reference Document – DataGrid-01-TED-0139-0_0

(http://lindir.ics.muni.cz/dg_public/lb_api.pdf)

[R3]

Job Partitioning and Checkpointing – DataGrid-01-TED-0119-0_3

(https://edms.cern.ch/file/347730/1/DataGrid-01-TED-0119-0_3.pdf)

1.4. Document evolution procedure

The content of this document will be subjected to modification according to the following events:

· Comments received from Datagrid project members,

· Changes/evolutions/additions to the WMS components.

1.5. Terminology

Definitions

Condor

Condor is a High Throughput Computing (HTC) environment that can manage very large collections of distributively owned workstations

Globus

The Globus Toolkit is a set of software tools and libraries aimed at the building of computational grids and grid-based applications.

Glossary

class-ad

Classified advertisement

CE

CLI

Computing Element

Command Line Interface

DB

DGAS

EDG

Data Base

Datagrid Grid Accounting Service

European DataGrid

FQDN

Fully Qualified Domain Name

GIS

Grid Information Service, aka MDS

GSI

GUI

HLR

IS

Grid Security Infrastructure

Graphical User Interface

Home Location Register

Information Service

job-ad

JA

JC

Class-ad describing a job

Job Adapter

Job Controller

JDL

Job Description Language

LB

LM

Logging and Bookkeeping Service

Log Monitor

LRMS

Local Resource Management System

MDS

Metacomputing Directory Service, aka GIS

MPI

NS

OS

PA

Message Passing Interface

Network Server

Operating System

Price Authority

PID

Process Identifier

PM

Project Month

RB

Resource Broker

SE

Storage Element

SI00

Spec Int 2000

SMP

Symmetric Multi Processor

TBC

To Be Confirmed

TBD

To Be Defined

UI

VO

VOMS

WM

WMS

User Interface

Virtual Organisation

Virtual Organisation Membership server

Workload Manager

Workload Management System

WP

Work Package

2. Executive summary

This document comprises the following main sections:

Section 3: Workload management System Overview

Briefly introduces the new revised Workload Management System architecture, and discusses about the deployment of the WMS components.

Section 4: Installation and Configuration

Describes changes that need to be made to the environment and the steps to be performed for installing the WMS software on the test-bed target platforms. The resulting installation tree structure is detailed for each system component.

Section 5: Operating the System

Provides actual procedures for starting/stopping WMS components processes and utilities.

Section 6: User Guide

Describes in a Unix man pages style all User Interface component commands allowing the user to access WMS provided services.

Section 7: Annexes

Deepens arguments introduced in the User Guide section that are considered useful for the user to better understand system behaviour.

3. workload management system overvieW

The revised (release 2) architecture of the EDG Workload Management System (WMS), which is described in detail in [A2], is represented in

Figure 1.

Figure 1: UML diagram describing the new (rel. 2) WMS architecture

The User Interface (UI) is the component that allows users to access the functionalities offered by the Workload Management System.

The Network Server (NS) is a generic network daemon, responsible for accepting incoming requests from the UI (e.g. job submission, job removal), which, if valid, are then passed to the Workload Manager.

The Workload Manager (WM) is the core component of the Workload Management System. Given a valid request, it has to take the appropriate actions to satisfy it. To do so, it may need support from other components, which are specific to the different request types.

All these components that offer support to the Workload Manager provide a class whose interface is inherited from a Helper class. Essentially the Helper, given a JDL expression, returns a modified one, which represents the output of the required action. For example, if the request was to find a suitable resource for a job, the input JDL expression will be the one specified by the user, and the output will be the JDL expression augmented with the CE choice.

The Resource Broker (RB) or Matchmaker is one of these classes offering support to the Workload Manager. It provides a matchmaking service: given a JDL expression (e.g. for a job submission), it finds the resources that best match the request. It interacts with the Information Service and with the data management services.

The Job Adapter (JA) is responsible for making the final “touches” to the JDL expression for a job, before it is passed to CondorG for the actual submission. So, besides preparing the CondorG submission file, this module is also responsible for creating the wrapper script, and for creating the appropriate execution environment in the CE worker node (this includes the transfer of the input and of the output sandboxes).

CondorG is the module responsible for performing the actual job management operations (job submission, job removal, etc.), issued on request of the Workload Manager.

The Log Monitor (LM) is responsible for “watching” the CondorG log file, intercepting interesting events concerning active jobs, that is events affecting the job state machine (e.g. job done, job cancelled, etc.), and therefore triggering appropriate actions.

For what concerns the Logging and Bookkeeping (LB) service, it stores logging and bookkeeping information concerning events generated by the various components of the WMS. Using this information, the LB service keeps a state machine view of each job.

As described in section 4.3, a proxy renewal mechanism is available to assure that, for all the lifetime of a job, a valid user proxy exists within the WMS, and this proxy renewal service relies on the MyProxy software.

The DataGrid Accounting System (DGAS) is another functionality offered by the WMS, described in detail in [A3]. DGAS has two main purposes:

· Economic accounting for Grid Users and Resources

The users pay for resource usage while the resources earns virtual credits executing user jobs

· Economic Brokering

Help the Resource Broker in choosing the most suitable resource for a given job according to the current price of a resource and a pre-defined economic policy.

The HLR (Home Location Register) server is responsible of implementing the first item in the list. The second is covered by the Price Authority (PA) service. The suggested configuration is to have a HLR server and a PA server per VO.

3.1. Deployment of the WMS software

For what concerns the deployment of the WMS software, it is possible to identify the following types of “boxes”:

· The User Interface machine, which is used to interact with the functionalities of the WMS: the WMS User Interface software has to be installed on this machine; moreover on this machine part of the DGAS HLR client software (the DGAS job-auth client software) and the LB C and C++ API have to be installed

· The “RB node”, where the Network Server, the Workload Manager and its helpers (Matchmaker and Job Adapter), the Job Controller, CondorG, the Log Monitor, the LB local logger, the LB C API, the Proxy Renewal components have to be installed

· The LB server, where the LB software has to be installed

· The Computing Elements (CEs): on the gatekeeper node of each CE the LB local logger software and part of the DGAS HLR client software (the DGAS ATM client software) have to be installed. On the WNs it is necessary to install the checkpointing API and the C and sh LB APIs.

· The MyProxy server host

· The HLR server, where the HLR server and the PA client software have to be installed

· The PA server, where the PA server software has to be installed

These are the EDG WP1 RPMs needed in the various “machines”

User Interface machine:

edg-wl-common-api-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-common-api-java-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-dgas-hlr-ui-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-logging-api-c-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-logging-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-ui-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-ui-api-java-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-ui-cli-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-ui-gui-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-chkpt-api-X.Y.Z-K_gcc3_2_2

edg-wl-config-X.Y.Z-K_gcc3_2_2

edg-wl-bypass-X.Y-Z.i486.rpm

“RB node”:


edg-wl-config-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-interactive-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-locallogger-X.Y.Z-K_gcc3_2_2.i486.rpm


edg-wl-proxyrenewal-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-wm-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-dgas-hlr-jobAuthClient-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-globus-gridftp-X.Y.Z-gxx3_2_2.i486.rpm

edg-wl-bypass-X.Y-Z.i486.rpm

LB server:


edg-wl-lbserver-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-lbserver-rgma-X.Y.Z-K_gcc3_2_2.i486.rpm

Gatekepeer of CE:


edg-wl-dgas-hlr-ATMClient-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-locallogger-X.Y.Z-K_gcc3_2_2.i486.rpm

WN of CE:

edg-wl-chkpt-api-X.Y.Z-K_gcc3_2_2.i486.rpm


edg-wl-logging-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-logging-api-sh-X.Y.Z-K_gcc3_2_2.i486.rpm


DGAS HLR server:

edg-wl-dgas-hlr-server-X.Y.Z-K_gcc3_2_2.i486.rpm

edg-wl-dgas-hlr-server-admin-X.Y.Z-K_gcc3_2_2.i486.rpm

DGAS PA server:

edg-wl-dgas-pa-server-X.Y.Z-K_gcc3_2_2.i486.rpm

Note that in this list only RPMs concerning EDG WP1 software have been specified (i.e. no sw needed by these RPMs has been specified: details can be found in section 4).

It is not strictly needed that these different types of services have to be installed on different machines. A machine can in fact host different services (for example, the PA server and the HLR server could run o the same machine).

4. Installation and Configuration

This section deals with the procedures for installing and configuring the WP1 WMS components on the target platforms. For each of them, before starting with the installation procedure which is described through step-by-step examples, is reported the list of dependencies i.e. the software required on the same machine by the component to run. Moreover a description of needed configuration items and environment variables settings is also provided. It is important to remark that since the RPMs are generated using gcc 3.2 and RPM 4.0.2 it is expected to find the same configuration on the target platforms.

4.1. Logging and Bookkeeping services

From the installation point of view LB services can be split in three main components:

· The LB services responsible for accepting messages from their sources and forwarding them to the logging and/or bookkeeping servers, which we will refer as LB local-logger services.

· The LB services responsible for accepting messages from the LB local-logger services, saving them on their permanent storage and supporting queries generated by the consumer API, that we will refer as LB server services.

· The LB APIs (C, C++, sh)

The LB local-logger services must be installed on all the machines hosting processes pushing information into the LB system, i.e. the “RB node” and the gatekeeper machines of the CEs. An exception is the submitting machine (i.e. the machine running the User Interface) on which this component can be installed but is not mandatory.

The LB server services need instead to be installed only on a server machine.

The LB APIs should be installed on the UI machine (C and C++ APIs), “RB node” (C and C++ APIs) and on the CE worker nodes (C and sh APIs).


4.1.1.1. LB local-logger and LB APIs

For the installation of the LB local-logger and LB APIs the only software required is the Globus Toolkit 2.2 (actually only GSI rpms are needed). Globus 2.2 RPMs are available at http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/

4.1.1.2. LB Server

For the installation of the LB local-logger the only software required is the Globus Toolkit 2.2 (actually only GSI RPMs are needed). Globus 2.2 RPMs are available at

http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/

Besides the Globus Toolkit, for the LB server to work properly it is also necessary to install MySQL Distribution 4.0.1 or higher.

Packages and documentation about MySQL can be found at: http://www.mysql.org.

Anyway the MySQL RPMs for pc-linux-gnu (i686) is available at http://datagrid.in2p3.fr/distribution/external/RPMS/. At least packages MySQL-4.0.x and MySQL-client-4.0.x have to be installed for creating and configuring the LB database.

LB server stores the logging data in a MySQL database that must hence be created. The following assumes the database and the server daemon (edg-wl-bkserverd) runs on the same machine, which is considered to be secure, i.e. no database authentication is used. In a different set-up the procedure has to be adjusted accordingly as well as a secure database connection (via ssh tunnel etc.) established.

The action list below contains placeholders DB_NAME and USER_NAME: real values have to be substituted. They form the database connection string required on some LB daemons invocation. Suggested value for DB_NAME is ‘lbserver20’ and for USER_NAME is `lbserver'. These values are also the compiled-in defaults (i.e. when used, the database connection string needn't be specified at all).

The following needed steps require MySQL root privileges:

1. Create the database:

mysqladmin -u root -p create DB_NAME

where DB_NAME is the name of the database.

2. Create a dedicated LB database user:

mysql -u root -p -e 'grant create,drop, alter,index, \

select,insert, update,delete on DB_NAME.* to \ USER_NAME@localhost'

where USER_NAME is the name of the user running the LB server daemon.

3. Create the database tables:

mysql -u USER_NAME DB_NAME < server.sql

where server.sql is a file containing sql commands for creating needed tables. server.sql can be found in the directory “/etc” created by the LB server rpm installation.

For the LB server it is also necessary to install expat (recommended release is 1.95.2 or higher), which can be downloaded from: http://datagrid.in2p3.fr/distribution/external/RPMS/.


4.1.2.1. LB Local-Logger

The LB local logger has no configuration file.

4.1.2.2. LB Server

The LB server has no configuration file.

By default the LB server is configured with only very few indices so that a limited set of queries is supported. Upon installation the server administrator may decide to create additional indices to support further expected user query types. See section 5.2.2 for details.

4.1.3. Environment Variables

All LB components recognize the following environment variables in the same way GSI handles them:

· X509_USER_KEY

· X509_USER_CERT

· X509_CERT_DIR

· X509_USER_PROXY

However, in case of LB daemons, the recommended way for specifying security files locations is using --cert, --key, --CAdir options explicitly: GSI searches through various default locations and finding a wrong credential file in some of them may cause unexpected behaviour.

The Logging library i.e. the library that is linked into UI, NS, WM, JC, LM, and called from the job-wrapper script recognizes the following environment variables (besides the X509_* ones listed above):

· GLOBUS_HOSTNAME

Hostname that will appear as the source of logged events

· EDG_WL_LOG_DESTINATION

: of the local-logger to use

· EDG_WL_LOG_TIMEOUT

Timeout for standard (asynchronous) logging

· EDG_WL_LOG_SYNC_TIMEOUT

Timeout for synchronous logging

· EDG_WL_QUERY_SERVER

Default server to query (prefix in JobId overrides this setting)

· EDG_WL_QUERY_TIMEOUT

Timeout for queries

All them has reasonable defaults and needn’t be set in normal operation (details can be found in [R2].

On the submitting machine if the variable EDG_WL_LOG_DESTINATION is not set, it is dynamically assigned by the UI referring to the machine where the NS runs. The Logging library functions timeout is automatically increased with respect to the default value (recommended for non-locals logging).

4.2. services running in the “rb node”: Ns, wm, jc, lm

As introduced in section 3, the Network Server (NS), the Workload Manager (WM), the Job Controller (JC) and the Log Monitor (LM) are dealt with together since they always reside on the same host (the “RB node”) and consequently are distributed by means of a single rpm.


For the installation of NS, WM, JC and LM, the following products are expected to be installed:

· Globus

· Condor-G

· ClassAd library

· Boost

· LB local logger (whose installation and configuration is discussed in section 4.1)

· ReplicaManager from the EDG WP2 distribution

4.2.1.1. Globus installation and configuration

For what concerns Globus, the required release is 2.2. The Globus software can be downloaded from: http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/.

Please note that the “RB node” should run a gridftp server (actually a “customized” one: see section 4.2.4.1), while it should not run a globus gatekepeer.

4.2.1.1.1. Condor-G installation and configuration

Condor-G release required is CondorG 6.5.1, which can be found at the following URL:

http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/condor/RPMS/.

Moreover some additional configuration steps have to be performed in the Condor configuration file pointed to by the CONDOR_CONFIG environment variable set during installation. In the $CONDOR_CONFIG file the following attributes need to be modified:

RELEASE_DIR = /opt/condor

LOCAL_DIR = $ENV(GLOBUS_LOCATION)/var/condor

CONDOR_ADMIN =

and the following entries need to be added:

AUTHENTICATION_METHODS

= CLAIMTOBE

ENABLE_GRID_MONITOR

= TRUE

GRID_MONITOR

= $(SBIN)/grid_monitor.sh

4.2.1.2. ClassAd installation and configuration

The ClassAd software required is a “customized” classads-0.9.4 release, available in rpm format (to be installed as root) at:

http://datagrid.in2p3.fr/distribution/external/RPMS.

The ClassAd library documentation can be found at the following URL:

http://www.cs.wisc.edu/condor/classad.

4.2.1.3. Boost installation and configuration

The Boost C++ libraries release required is 1.29 (or higher).

The boost documentation can be found at the following URL:

http://www.boost.org

whilst it is available in rpm format (to be installed as root) at:

http://datagrid.in2p3.fr/distribution/external/RPMS

4.2.1.4. Replica Manager installation and configuration

The Replica Manager RPMs that must be installed are:

edg-gsoap-base-1.0.3-1.i386.rpm

edg-replica-location-client-c++-1.2.8-1.i386.rpm

edg-replica-optimization-client-c++-1.2.9-1.i386.rpm

edg-replica-metadata-catalog-client-c++-1.2.8-1.i386.rpm

edg-replica-manager-client-c++-1.0.6-1.i386.rpm

After the RPM installation, it is then needed to configure the configuration files for the various VOs in /etc/edg-replica-manager (please refer to WP2 documentation for details).


Once the rpm installation has been performed, the NS, WM, JC and LM services must be properly configured. This can be done editing the file ${EDG_WL_CONFIG_DIR}/edg_wl.conf file. If $EDG_WL_CONFIG_DIR hasn’t been defined, the edg_wl.conf file is looked for first in /opt/edg/etc, then in /etc, and then in /usr/local/etc.

This configuration file has the following structure (ClassAd based):

[

Common = [

…

…

];

NetworkServer = [

…

…

];

WorkloadManager = [

…

…

];

JobController = [

…

…

];

LogMonitor = [

…

…

];

]

Therefore the configuration file is composed of 5 parts:

· one for the “common” (i.e. “used” by all services) attributes

· one for the configuration of the NS

· one for the configuration of the WM

· one for the configuration of the JC

· one for the configuration of the LM

4.2.2.1. Configuration of the “common” attributes

As introduced in the previous section, it is necessary first of all to edit the:

Common = [

…

…

];

part of the configuration file, in order to set the attributes “used” by all the services.

The only “common” attribute that must be specified is:

· DGUser refers to the user name account running the NS, WM, JC and LM services. E.g.:

DGUser = “${EDG_WL_USER}”;

4.2.2.2. NS configuration

Configuration of the Network Server is accomplished editing the configuration file and setting opportunely the attributes in the:

NetworkServer = [

…

…

];

section.

They are listed hereafter grouped according to the functionality they are related with:

· II_Contact, II_Port, II_DN and II_Timeout refer to the II service and respectively represent the hostname where this service is running, the port number, the base DN (which represents the distinguished name to use as a starting place for searches in the information service) to be used when querying the II, and the timeout in seconds to consider when the II is queried. E.g.:

II_Contact = "grid001f.cnaf.infn.it";

II_Port = 2170;

II_DN = "mds-vo-name=local, o=grid";

II_Timeout = 60;

· Gris_Port, Gris_DN and GRIS_Timeout respectively represent the port number where the GRISes run, the base DN to be used when querying the GRISes, and the timeout in seconds when the GRISes are queried.

Actually the port and the base DN to be used are specified in the information service schema, and the NS relies on these values: the GRIS_Port and GRIS_DN attributes specified in the configuration file are considered only if, for some reasons, they are not published in the information service.

E.g.:

Gris_Port = 2135;

Gris_DN = "mds-vo-name=local, o=grid";

Gris_Timeout = 20;

· ListeningPort is the port used by the NS to listen for requests coming from the User Interface. Default value for this parameter is:

ListeningPort = 7772;

· MasterThreads defines the maximum number of simultaneous connections with User Interfaces. Default value is:

MasterThreads = 8;

· DispatcherThreads defines the maximum number of simultaneous connections (to forward the incoming requests) with the Workload Manager. Default value is:

DispatcherThreads = 10;

· SandboxStagingPath represents the pathname of the root sandboxes directory, i.e. the complete pathname referring to the directory where the RB creates both input/output sandboxes directories and stores the “.Brokerinfo” file. Please take care that this directory must not have the sticky bit (o+t).

E.g.:

SandboxStagingPath = "/disk/sandbox”;

· EnableQuotaManagement is a Boolean attribute which specifies if the user quota has to be checked to control if there is enough space to store the input sandbox (see section 4.2.4.3)

E.g.:

EnableQuotaManagement = true;

· MaxInputSandboxSize defines the maximum size (in bytes) for the input sandbox allowed per job. If the size of the input sandbox for a given job is greater than MaxInputSandboxSize, then the job is refused.

E.g.

MaxInputSanboxSize = 10000000;

· EnableDynamicQuotaAdjustment and QuotaAdjustmentAmount refer to “dynamic” quota (see section 4.2.4.3). If EnableDynamicQuota is true, than if for the considered user a disk quota hasn’t been set by the system administrator, than a virtual quota equal to QuotaAdjustmentAmount is added for that user for each submitted job, and it is released when the job has completed its execution.

E.g.:

EnableDynamicQuotaAdjustment = true;

QuotaAdjustmentAmount = 10000;

· QuotaInsensibleDiskPortion represents the percentage of the disk storing the sandboxes directories that the administrator wants to keep unassigned. So if the free disk space is less than the specified percentage, no new jobs can’t be accepted (see section 4.2.4.3).

E.g.:

QuotaInsensibleDiskPortion = 2.0;

· LogFile and LogLevel refer to the NS log file. LogFile is the name of this file, while LogLevel allows to specify the verbosity of the information the NS records in its log file: 0 is the minimum value (no debug information is written in the log file), while 6 is the maximum value (full debug). E.g.:

LogFile = “${EDG_WL_TEMP}/NetworkServer/log”;

LogLevel = 6;

4.2.2.3. WM configuration

Configuration of the Workload Manager is accomplished editing the configuration file and setting opportunely the attributes in the:

WorkloadManager = [

…

…

];

section.


· PipeDepth defines the maximum size of the buffer between the dispatcher and the worker threads. E.g.:

PipeDepth = 10;

· NumberOfWorkerThreads represents the size of the worker threads pool. The default value is:

NumberOfWorkerThreads = 1;

· DispatcherType defines the type of the input queue of requests. There shouldn’t be any reasons to change the provided default value (“filelist”).

· Input refers to the WM input “queue” of requests. There shouldn’t be reasons to change the provided default value. E.g.:

Input = “"${EDG_WL_TMP}/workload_manager/input.fl";

· MaxRetryCount allows specifying the maximum number of times the WM has to try to re-schedule and re-submit the job in case the submission to the CE failed (e.g. globus down on the CE, network problems, etc.).

When a job is submitted specifying the RetryCount attribute in the JDL, the submission retries attempted by the WM are at most the minimum value between RetryCount and MaxRetryCount. The default value for this configuration parameter is:

MaxRetryCount = 10;

· LogFile and LogLevel refer to the WM log file. LogFile is the name of this file, while LogLevel allows specifying the verbosity of the information the WM records in its log file: 0 is the minimum value (no debug information is written in the log file), while 6 is the maximum value (full debug). E.g.:

LogFile = “${EDG_WL_TEMP}/manager/log/events.log”;

LogLevel = 6;

Please note that all directories specified in the WM configuration file are supposed to already exist, i.e. as the WM does not create directories, if they are not already there, they have to be created at installation time.

4.2.2.4. JC configuration

Configuration of the Job Controller is accomplished editing the configuration file and setting opportunely the attributes in the:

JobController = [

…

…

];

section.


· CondorSubmit CondorRemove, CondorQuery CondorSubmitDag CondorRelease respectively specify the pathname of the condor_submit, condor_rm, condor_q, condor_submit_dag and condor_release Condor-G commands.

· SubmitFileDir defines the directory where the temporary files (the CondorG submit file and the job wrapper scripts) are created.

E.g.:

SubmitFileDir = "${EDG_WL_TMP}/jobcontrol/submit";

· OutputFileDir defines the directory where the standard output and standard error files of CondorG are temporarily saved.

E.g.:

OutputFileDir = "${EDG_WL_TMP}/jobcontrol/condorio";

· Input refers to the JC input “queue” of requests. There shouldn’t be any reasons to change the default value

· LogFile and LogLevel refer to the JC log file. LogFile is the name of this file, while LogLevel allows specifying the verbosity of the information the JC records in its log file: 0 is the minimum value (no debug information is written in the log file), while 6 is the maximum value (full debug). E.g.:

LogFile = “${EDG_WL_TEMP}/jobcontrol/log/events.log”;

LogLevel = 6;

· ContainerRefreshThreshold represents the number of jobs after which the JC has to re-read the IdRepositoryName LM file (see section 4.2.2.5). There shouldn’t be any reasons to change the provided default value:

ContainerRefreshThreshold = 1000;

· UseFakeForProxy and UseFakeForReal are used for debug purposes. Therefore there shouldn’t be any reasons to modify the default values:

UseFakeForProxy = false;

UseFakeForReal = false;

4.2.2.5. LM configuration

Configuration of the Log Monitor is accomplished editing the configuration file and setting opportunely the attributes in the:

LogMonitor = [

…

…

];

section.


· CondorLogDir defines the directory name where the CondorG log files (i.e. the files where the events for the submitted jobs are recorded) are created.

E.g.:

CondorLogDir = "${EDG_WL_TMP}/LM/CondorGlog";

· JobsPerCondorLog represents the number of jobs whose events are recorded for each single CondorG log file. So every JobsperCondorLog jobs, the CondorG log file is changed.

E.g.:

JobsperCondorLog = 1000;

· MainLoopDuration defines when the LM reads the CondorG log files: every MainLoopDuration seconds, the LM reads the CondorG log files.

E.g.:

MainLoopDuration = 10;

· CondorLogRecycleDir defines the directory name where the already read (by LM) CondorG log files are stored.

E.g.:

CondorLogRecycleDir = "${EDG_WL_TMP}/LM/RecCondorGlog";

· MonitorInternalDir is the directory where some files needed for the LM service by internal purposes are created and stored.

E.g.:

MonitorInternalDir = "${EDG_WL_TMP}/LM/internal";

· IdRepositoryName is the name of a file used by LM for internal purposes (where the dgjobid – Condorid correspondences are kept).

E.g.:

IdRepositoryName = "irepository.dat";

· AbortedJobsTimeout represents the timeout (in seconds) to have a cancelled job forgot by the LM (useful when the job is hang in the CondorG queue).

E.g.:

AbortedJobsTimeout = 600;

· LogFile and LogLevel refer to the LM log file. LogFile is the name of this file, while LogLevel allows specifying the verbosity of the information the LM records in its log file: 0 is the minimum value (no debug information is written in the log file), while 6 is the maximum value (full debug). E.g.:

LogFile = “${EDG_WL_TEMP}/LM/log/events.log”;

LogLevel = 6;


Environment variables that have to be set (or can be set) for the NS, WM, JC and LB services are listed hereafter:

· EDG_WL_LOG_DESTINATION

The Logging library i.e. the library providing APIs for logging job events to the LB reads its immediate logging destination from the environment variable EDG_WL_LOG_DESTINATION (see section 4.1.3).

· CONDOR_CONFIG

This variable has to refer to the CondorG configuration file, usually /opt/condor/etc/condor_config (see section 4.2.1.1.1).

· EDG_WL_CONFIG_DIR

As explained in section 4.2.2, this variable refers to the directory where the configuration file for the WMS services running on the “RB node” (edg_wl.conf) is available.

· GRIDMAP

This variable must refer to the grid-mapfile (usually /etc/grid-secury/grid-mapfile)

· LD_LIBRARY_PATH

Should include $GLOBUS_LOCATION/lib, the Boost lib directory and the gcc 3.2 lib directory

· EDG_LOCATION

Should refer to the EDG software installation directory (usually /opt/edg): needed for the WP2 services used by the RB

Then of course, if some environment variables are used in the NS/WM/JC/LM configuration sections, they have of course to be set as well.

Anyway, all variables that must be defined for the proper execution of the WMS services, are set by the relevant start-up scripts.

4.2.4. Other requirements and configurations for the “RB node”

4.2.4.1. Customized Gridftp server

To assure the “security” of the input and output sandboxes a “customized” Gridftp server has to run on the “RB node”.

With this “patched” Gridftp server, the sandbox files are transferred in the “RB node” belonging to the group of the user running the NS, WM, JC and LM services (usually edguser) and rwxrwx--- as mask. In this way a user cannot access sandbox files belonging to other users.

In order to install this “customized” Gridftp server, the following RPM has to be installed:

edg-wl-globus-gridftp-X.Y.Z-K.i486.rpm

By default this rpm installs the software in the “/opt/edg” directory

After having installed the software, it may be necessary to modify the line:

magicgroup edguser all

in the file:

/etc/ftpaccess

if edguser is not the group for the user running the WMS services in the “RB node”.

To start/stop this patched gridftp server, the following command has to be issued:

/etc/rc.d/init.d/edg-wl-ftpd start/stop

4.2.4.2. Grid-mapfile

The Globus grid-mapfile (usually located in /etc/grid-security) on the “RB node” must be filled with the certificate subjects of all the users allowed to use the WMS functionalities. Users being mapped into the gridmap-file have to belong to groups which, for security reasons, have to be different than the group for the dedicated user (e.g. edguser) running the NS, WM, JC, LM services.

4.2.4.3. Disk Quota

When a job is submitted to the WMS, first of all the NS checks if there is enough space to store its input sandbox files.

Moreover, as explained in section 4.2.2.2, the NS checks that the input sandbox size is not greater than the value specified as MaxInputSandboxSize in the NS configuration section, otherwise the job is refused.

As introduced in section 4.2.2.2, it is also possible enabling a disk quota check (by setting EnableQuotaManagement=true in the NS configuration section). In this case, when a user submits a job, the NS checks the disk quotas for that particular local account (the one defined in the grid-mapfile), to see if it is possible to move the input sandbox files in the “RB node”. So, if the disk quota check has been enabled in the NS configuration file, the disk quota option had to be enabled, and disk quotas had to be set for the various users allowed to submit jobs to the WMS (i.e. the ones defined in the grid-mapfile).

If the NS configuration parameter EnableDynamicQuota is set to true, than if for the considered user a disk quota hasn’t been set by the system administrator, than a “dynamic” quota equal to QuotaAdjustmentAmount (an other NS configuration parameter) is added for that user for each submitted job, and it is released when the job has completed its execution.

It is also possible to define (via the QuotaInsensibleDiskPortion NS configuration parameter) a portion of disk. If the free space of the disk used for storing input and output sandboxes is less than this percentage value, than no new jobs can be submitted.

4.3. Security Services

The EDG WMS software relies on the GSI mechanisms for what concerns authentication. This means that, for all the lifetime of a job, a valid user proxy must exist within the WMS (not necessarily in the UI) for all the lifetime of a job.

A secure way for achieving this (instead of considering long time proxy) is to exploit the proxy renewal (PR) mechanisms, which rely on the MyProxy package. The underlying idea is that the user registers in a MyProxy server a valid long-term certificate proxy that will be used by the WMS to perform a periodic credential renewal for the submitted job; in this way the user is no longer obliged to create very long lifetime proxies when submitting jobs lasting for a great amount of time.

The MyProxy credential repository system consists of a server and a set of client tools that can be used to delegate and retrieve credentials to and from a server. Normally, a user would start by using the myproxy_init client program along with the permanent credentials necessary to contact the server and delegate a set of proxy credentials to the server along with authentication information and retrieval restrictions.

The Proxy Renewal (PR) service maintains users' proxy certificates and, by periodically contacting the Myproxy server, keeps the certificates valid. The service communicates only through a local unix socket, so it must be installed on the same machine where services registering proxies run (i.e. on the “RB node”).

Therefore:

· In the “RB node” it is necessary to deploy (via the edg-wl-proxyrenewal-X.Y.Z-K.i486.rpm RPM) the PR software and the Myproxy libraries (as discussed in the section 4.3.2)

· In the “Myproxy server” node it is necessary to deploy the Myproxy Server software, discussed in section 4.3.1

The MyProxy Toolkit is available at the following URL: http://myproxy.ncsa.uiuc.edu/

MyProxy version v0.5.3 is recommended for the Datagrid environment.

4.3.1. MyProxy Server

myproxy-server is a daemon that runs on a trusted, secure host and manages a database of proxy credentials for use from remote sites. Proxies have a lifetime that is controlled by the myproxy-init program. When a proxy is requested from the myproxy-server, via the myproxy-get-delegation command, further delegation insures that the lifetime of the new proxy is less than the original to enforce greater security.

A configuration file is responsible for maintaining a list of trusted portals and users that can access this service. To configure a Myproxy server, one must restrict the users that are allowed to store credentials within the Myproxy server and, more importantly, which clients are allowed to retrieve credentials from the Myproxy server. To do that, it is necessary to edit a configuration file (/etc/myproxy-server.conf) and add specific services allowed to carry out proxy renewal. An example of myproxy-server.conf is below:

accepted_credentials "/C=CZ/O=CESNET/*"

accepted_credentials "/C=IT/O=INFN/*"

authorized_renewers \

"/O=Grid/O=CERN/OU=cern.ch/CN=host/lxshare0380.cern.ch"

authorized_renewers \

"/C=IT/O=INFN/OU=gatekeeper/L=CNAF/CN=grid010g.cnaf.infn.it/[email protected]"

As it is possible to see, it contains the subject names of all the resources who are allowed to renew credentials (the recognized “RB nodes”) and the prefixes of the subject names of the users that are allowed to store proxies in the repository.

In order to launch the myproxy-server daemon, it is necessary to run the binary /sbin/myproxy-server. The program will start up and background itself. It accepts connections on TCP port 7512, forking off a separate child to handle each incoming connection.

It logs information via the syslog service. A Starting script (/etc/init.d/myproxy) is provided to run the service on reboot.

4.3.2. Proxy renewal service

4.3.2.1. Required software

Globus 2.2 (which can be downloaded from http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/) and the Myproxy libraries (version v0.5.3 recommended) are needed for the Proxy Renewal services.

4.3.2.2. Configuration

The PR daemon has no configuration file.

4.3.2.3. Environment variables

The PR daemon recognizes the following environment variables in the same way the GSI handles them:

· X509_USER_KEY

· X509_USER_CERT

· X509_CERT_DIR

· X509_USER_PROXY

4.4. Grid accounting services


As introduced in section 3, for what concerns the DGAS services, it is necessary to install:

· The HLR server software plus the PA client software on a HLR server machine

· The PA server software on a PA server machine

· The DGAS job-auth client software on the UI machine

· The ATM client software on the gatekeeper node of the CE

For the DGAS software, the Globus Toolkit 2.2 software is required (actually only GSI RPMs are needed). Globus 2 RPMs are available at http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/.

Besides Globus Toolkit, for both PA and HLR servers it is also necessary to install MySQL Distribution 4.0.1 or higher.

Packages and documentation about MySQL can be found at: http://www.mysql.org

Anyway the MySQL RPMs for pc-linux-gnu (i686) is available at http://datagrid.in2p3.fr/distribution//external/RPMs.

The MySQL database can be executed basically in two ways, as a daemon waiting both for remote TCP calls and local Unix-socket calls, or waiting for local calls only.

DGAS doesn't need MySQL to wait for incoming TCP calls, so if this feature is not needed for other purposes, it is strongly suggested to instruct MYSQL listening Unix-socket only. In order to skip networking in MySQL, the following line:

skip-networking

has to be added in the MySQL configuration file (usually /etc/my.conf) under the daemon part of the configuration file (i.e. [mysqld]).

4.4.1.1. Creating the MySQL databases for the HLR server

The HLR stores its data in two databases that needs to be installed and configured. The file needed to install the databases can be found under /etc and are:

· hlr.sql

Main DB used by the HLR engine.

· hlr_tmp.sql

DB where the HLR stores temporary data.

In order to install the HLR DBs, it is first necessary to create them:

# mysqladmin create hlr

# mysqladmin create hlr_tmp

and then the previous listed files have to be used to create the tables in the databases:

# mysql hlr < hlr.sql

# mysql hlr_tmp < hlr_tmp.sql

4.4.1.2. Creating the MySQL database for the PA server

The PA stores its data in one database that needs to be installed and configured. The file needed to install the database can be found under /etc, and is:

· pa.sql

Main DB used by the PA engine.

In order to install the PA DB, first of all it has to be created:

# mysqladmin create pa

and then the previous mentioned file can be used to create the tables in the database:

# mysql pa < pa.sql


4.4.2.1. Configuring the HLR server

The main options for the HLR server daemon can be set up in its configuration file, which can be referenced when starting the daemon (see section 5.6.1.1). The file is usually found in $EDG_WL_LOCATION/etc

The configuration file accepts parameters in the form:

item = "value"

with an item-value pair per line.

These are the parameters that can be specified in the HLR configuration file:

· hlr_sql_server

The host where the HLR databases are installed (usually it is the localhost)

· hlr_sql_user

The user running the HLR database

· hlr_sql_password

The HRL database user password

· hlr_sql_dbname

The HLR database name

· hlr_tmp_sql_dbname

The HRL tmp database name

· hlr_port

The HLR server listening port

· hlr_log

The HLR log file name

4.4.2.2. Configuring the PA server

The main options for the PA server daemon can be set up in its configuration file, which can be referenced when starting the daemon (see section 5.6.1.2). The file is usually found in /etc.

These are the parameters that can be specified in the PA configuration file:

· pa_sql_server

The host where the PA database is installed (usually it is the localhost)

· pa_sql_user

The user running the PA database

· pa_sql_password

The PA database user password

· pa_sql_dbname

The PA database name

· pa_port

The PA server listening port

· pa_log

The PA log file name

4.4.2.3. Configuring the ATM client software

As mentioned before, in the gatekeeper node of each CE, the DGAS ATM client software has to be installed and configured. It is necessary to specify, via a configuration file, the full contact string for the Resource PA and HLR.

This configuration file, referenced by the DGAS ATM Client API, should usually be /etc/ edg-wl-ATMClient-dgas.conf and it has to specify the two following attributes:

· res_acct_PA_id

The resource PA, in the format:

Res_acct_OA_id= "hostname:portnumber:X509CertSubject"

· res_acct_bank_id

The resource HLR, in the format:

res_acct_bank_it= "hostname:portnumber:X509CertSubject"


The grid accounting services don’t rely on any environment variables.

4.5. User Interface

This section describes the steps needed to install and configure the User Interface, which is the software module of the WMS allowing the user to access main services made available by the components of the scheduling sub-layer.

The UI software is distributed in 4 different packages:

· The python command line interface

· The C++ API

· The Java API

· The Java GUI


All the above listed packages have a dependency on the Globus Toolkit software. The required release is 2.2 from the VDT distribution. It can be downloaded from http://datagrid.in2p3.fr/distribution/globus/vdt-1.1.8/globus/RPMS/. The needed rpms are listed here below:

· vdt_globus_essentials-EDGVDT1.1.8-5.i386.rpm

· vdt_globus_sdk-EDGVDT1.1.8-5.i386.rpm

· vdt_compile_globus_core-EDGVDT1.1.8-1.i386.rpm

· globus-initialization-2.2.4-2.noarch.rpm

Moreover the set of security configuration rpm’s for all the Certificate Authorities in Testbed2 available at http://datagrid.in2p3.fr/distribution/datagrid/security/RPMS/ have to be installed together with the rpm to be used for renewing your certificate for your CA. This is available at http://datagrid.in2p3.fr/distribution/datagrid/security/RPMS/local/.

Lastly the MyProxy package should be installed on the UI node in order to allow users to take advantage of the proxy-renewal feature for long running jobs. The corresponding rpm can be fount at http://datagrid.in2p3.fr/distribution/external/RPMS and is named as follows:

· myproxy-gcc32dbg-client-0.5.3-1.i386.rpm


In order to install the CLI, apart form the proper user interface rpm:

· edg-wl-ui-cli-X.Y.Z-K_gcc3_2_2.i486.rpm

the common UI configuration rpm:

· edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm

· edg-wl-config-X.Y.Z-K_gcc3_2_2.i486.rpm

and the configuration LCFGng objects:

· edg-lcfg-cliconfig

· edg-lcfg-uicmnconfig

the following WMS and third-party packages are needed:

· edg-wl-common-api-X.Y.Z-K_gcc3_2_2.i486.rpm (WMS common lib)

· edg-wl-logging-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm (LB consumer C++ API)

· edg-wl-logging-api-c-X.Y.Z-K_gcc3_2_2.i486.rpm (LB client C API)

· edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm

(Condor bypass)

Moreover the VOMS client C++ API rpm:

· voms-api_gcc3_2_2-1.1.39-1_RH7.3

available at

http://datagrid.in2p3.fr/distribution/autobuild/i386-rh7.3-gcc3.2.2/wp6/RPMS/

is needed on the UI, together with the VO specific rpm containing the credentials of the VOMS server for the given VO (one rpm per VO is needed):

· edg-voms-vo--X.Y-Z.noarch.rpm

available at http://datagrid.in2p3.fr/distribution/datagrid/security/RPMS/ .

Lastly, the Python interpreter, version 2.2.2 must also be installed on the submitting machine. The rpm for this package is available at http://datagrid.in2p3.fr/distribution/redhat-7.3/updates/RPMS as:

· python2-2.2.2-11.7.3.i386.rpm

· tkinter2-2.2.2-11.7.3.i386.rpm

Information about python and the package sources can be found at www.python.org.

4.5.1.2. C++ API

The UI C++ API is distributed within the following rpm:

· edg-wl-ui-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

Moreover the following WMS and third-party packages are needed:




· edg-wl-chkpt-api-X.Y.Z-K_gcc3_2_2.i486.rpm (Checkpointing API)


(Condor bypass)

The VOMS client C++ API rpm:

· voms-api_gcc3_2_2-1.1.39-1_RH7.3

available at

http://datagrid.in2p3.fr/distribution/autobuild/i386-rh7.3-gcc3.2.2/wp6/RPMS/

is also needed on the UI, together with the VO specific rpm containing the credentials of the VOMS server for the given VO (one rpm per VO is needed):

· edg-voms-vo--X.Y-Z.noarch.rpm

available at http://datagrid.in2p3.fr/distribution/datagrid/security/RPMS/ .

Lastly, the following external rpms, all available at the following URL: http://datagrid.in2p3.fr/distribution/external/RPMS need to be installed on the UI node.

They are the customised Condor classads library (see 4.2.1.2 for details):

· classads-g3-0.9.4-vh8.i486.rpm

and the The Boost C++ libraries (see 4.2.1.3 for details):

· boost-g3-1.29.1-vh6.i486.rpm

4.5.1.3. Java API

The UI Java API is distributed within the following rpm:

· edg-wl-ui-api-java-X.Y.Z-K.i486.rpm

Moreover the following WMS and third-party packages are needed:


· edg-wl-common-api-java-X.Y.Z-K.i486.rpm

(requestAd jar)




(Condor bypass)

Lastly, the following external rpms all available at http://datagrid.in2p3.fr/distribution/external/RPMS need to be installed on the UI node. They are the customised Condor classads java library version 1.1:

· classads-jar-1.1-2.i386.rpm

the Java 2 Development Kit version 1.4 (or greater):

· j2sdk-1.4.1_01-fcs.i586.rpm

· j2sdk_profile-1.4.1_01-1.noarch.rpm

the Globus Java CoG Kit version 1.0 alpha:

· cog-jar-1.0-1_alpha.i386.rpm

the Log4J package version 1.2.6:

· log4j-1.2.6-1jpp.noarch.rpm

and the EDG Java Security API:

· bouncycastle-jdk14-1.19-2

· edg-java-security-1.4.1-1

4.5.1.4. Java GUI

In order to install the Java Graphical User Interface, apart form the proper GUI rpm:

· edg-wl-ui-gui-X.Y.Z-K.i486.rpm

the Java API rpm:

· edg-wl-ui-api-java-X.Y.Z-K.i486.rpm

the common UI configuration rpm:

· edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm

· edg-wl-config-X.Y.Z-K_gcc3_2_2.i486.rpm

and the configuration LCFGng objects:

· edg-lcfg-guiconfig

· edg-lcfg-uicmnconfig

the following WMS and third-party packages are needed:


· edg-wl-common-api-java-X.Y.Z-K.i486.rpm

(requestAd jar)




(Condor bypass)

Moreover, the following external rpms all available at http://datagrid.in2p3.fr/distribution/external/RPMS need to be installed on the UI node. They are the customised Condor classads java library version 1.1:

· classads-jar-1.1-2.i386.rpm

the Java 2 Development Kit version 1.4 (or greater):

· j2sdk-1.4.1_01-fcs.i586.rpm

· j2sdk_profile-1.4.1_01-1.noarch.rpm

the Globus Java CoG Kit version 1.0 alpha:

· cog-jar-1.0-1_alpha.i386.rpm

the Log4J package version 1.2.6:

· log4j-1.2.6-1jpp.noarch.rpm

and the EDG Java Security API:

· bouncycastle-jdk14-1.19-2

· edg-java-security-1.4.1-1

4.5.2. RPM installation

All the needed rpms can be downloaded with the command

wget -nd –r /

and installed with

rpm –ivh

As stated at the beginning of section 4.5.1 all UI packages requires the installation of the Globus Toolkit software release 2.2 from the VDT distribution and the MyProxy package.

It is important to remark that since the RPMs are generated using gcc 3.2 and RPM 4.0.2 it is expected to find the same configuration on the target platforms.

Hereafter are reported details for each UI package.


In order to install the python command line User Interface, the following commands have to be issued with root privileges:

rpm –ivh edg-wl-common-api-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-logging-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-logging-api-c-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-config-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-ui-cli-X.Y.Z-K_gcc3_2_2.i486.rpm

By default the rpms install the software in the “/opt/edg” directory.

Moreover the VOMS API rpms have to be installed as follows:

rpm –ivh voms-api_gcc3_2_2-1.1.39-1_RH7.3

rpm –ivh edg-voms-vo--X.Y-Z.noarch.rpm

Of course the python2.2 rpms have to be installed too if they are not present on the machine (should be included in the RH 7.3 distribution).

4.5.2.2. C++ API

In order to install the UI C++ API, the following commands have to be issued with root privileges:




rpm –ivh edg-wl-chkpt-api-X.Y.Z-K_gcc3_2_2.i486.rpm


rpm –ivh edg-wl-ui-api-cpp-X.Y.Z-K_gcc3_2_2.i486.rpm

By default the rpms install the software in the “/opt/edg” directory.

Moreover the VOMS API and the classads and boost libraries have to be installed as follows:

rpm –ivh voms-api_gcc3_2_2-1.1.39-1_RH7.3

rpm –ivh edg-voms-vo--X.Y-Z.noarch.rpm

rpm –ivh classads-g3-0.9.4-vh8.i486.rpm

rpm –ivh boost-g3-1.29.1-vh6.i486.rpm

4.5.2.3. Java API

In order to install the UI Java API, the following commands have to be issued with root privileges:

rpm –ivh j2sdk-1.4.1_01-fcs.i586.rpm

rpm –ivh j2sdk_profile-1.4.1_01-1.noarch.rpm

rpm –ivh classads-jar-1.1-2.i386.rpm

rpm –ivh cog-jar-1.0-alpha-1.0-1_alpha.i386.rpm

rpm –ivh log4j-1.2.6-1jpp.noarch.rpm

rpm –ivh bouncycastle-jdk14-1.19-2

rpm –ivh edg-java-security-1.4.1-1





rpm –ivh edg-wl-common-api-java-X.Y.Z-K.i486.rpm

rpm –ivh edg-wl-ui-api-java-X.Y.Z-K.i486.rpm

By default the WMS rpms install the software in the “/opt/edg” directory.

4.5.2.4. Java GUI

In order to install the Java GUI, the following commands have to be issued with root privileges:

rpm –ivh j2sdk-1.4.1_01-fcs.i586.rpm

rpm –ivh j2sdk_profile-1.4.1_01-1.noarch.rpm

rpm –ivh classads-jar-1.1-2.i386.rpm

rpm –ivh cog-jar-1.0-alpha-1.0-1_alpha.i386.rpm

rpm –ivh log4j-1.2.6-1jpp.noarch.rpm

rpm –ivh bouncycastle-jdk14-1.19-2

rpm –ivh edg-java-security-1.4.1-1





rpm –ivh edg-wl-common-api-java-X.Y.Z-K.i486.rpm

rpm –ivh edg-wl-ui-api-java-X.Y.Z-K.i486.rpm

rpm –ivh edg-wl-config-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-ui-gui-X.Y.Z-K.i486.rpm

By default the WMS rpms install the software in the “/opt/edg” directory.


The User Interface C++ and Java API packages have no configuration.

The Python command line interface and the GUI have instead a common configuration section that allows setting VO-specific parameters. This information is provided within file edg_wl_ui.conf. There is one such file for each of the supported EDG VOs. These files are located in the directory

$EDG_WL_LOCATION/etc//

i.e. there is one directory per VO . The VO name is lower case.

These directories are created by the LCFGng object called edg-lcfg-uicmnconfig, so if the installation is not performed using LCFGng, after having installed the common configuration rpm (edg-wl-ui-config-X.Y.Z-K_gcc3_2_2.i486.rpm) that creates the directory:

$EDG_WL_LOCATION/etc/vo_template

containing the file edg_wl_ui.conf, you must create in $EDG_WL_LOCATION/etc a directory for each needed VO and copy in it the file

$EDG_WL_LOCATION/etc/vo_template/edg_wl_ui.conf

opportunely updated.

The edg_wl_ui.conf file is a classad containing the following fields:

· VirtualOrganisation

this is a string representing the name of the virtual organisation the file refers to. It should match with the name of the directory containing the file. This parameter is mandatory.

· NSAddresses

this is a string or a list of strings representing the address or list of addresses (:) of the Network Servers available for the given VO. Job submission is performed towards the first NS in the list and in case of failure it is retried on each listed NS until succes or the end of the list is reached. This parameter is mandatory.

· LBAddresses

this is a string or a list of strings representing the address or list of addresses (:) of the LB servers available for the given VO. When job submission is performed, the UI choses randomly one LB server within the list and uses it for generating the job identifier so that all information related with that job will be managed by the chosen LB server. This allows distributing load on several LB servers. This parameter is mandatory.

· HLRLocation

this is a string representing the address (::) of the HLR for the given VO. HLR is the service responsible for managing the economic transactions and the accounts of user and resources. This parameter is not mandatory. It is not present in the file by default. If present, it makes the UI automatically add to the job description the HLRLocation JDL attribute (if not specified by the user) and this enables accounting.

· MyProxyServer

this is a string representing the MYProxy server address () for the given VO. This parameter is not mandatory. It is not present in the file by default. If present, it makes the UI automatically add to the job description the MyProxyServer JDL attribute (if not specified by the user) and this enables proxy renewal. If the myproxy client package is installed on the UI node, then this parameter should be set equal to the MYPROXY_SERVER environment variable.

Herafter is provided an example of configuration file for the “atlas” Virtual Organisation. The file path will hence be $EDG_WL_LOCATION/etc/atlas/edg_wl_ui.conf

[

VirtualOrganisation = "atlas";

NSAddresses = {

"ibm139.cnaf.infn.it:7772",

"grid013f.cnaf.infn.it:9772",

"grid012f.cnaf.infn.it:9772",

"grid004f.cnaf.infn.it:7771"

};

LBAddresses = {

"ibm139.cnaf.infn.it:9000",

"fox.to.infn.it:9000"

};

HLRLocation = "lilith.to.infn.it:56568:/C=IT/O=INFN/OU=Personal Certificate/L=Torino/CN=Andrea Guarise/[email protected]";

MyProxyServer = "skurut.cesnet.cz";

]


Configuration of the Command line User Interface is accomplished through the file

$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf

This file is installed by the LCFGng object edg-lcfg-cliconfig, so if the installation is not performed using LCFGng, after having installed the UI rpm (edg-wl-ui-cli-X.Y.Z-K_gcc3_2_2.i486.rpm) that creates the file:

$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf.template

you must copy it in :

$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf

and update the content of the latter file opportunely.

The edg_wl_ui_cmd_var.conf file is a classad containing the following fields:

· requirements

this is an expression representing the default value for the requirements expression in the JDL job description. This parameter is mandatory. The value of this parameter is assigned by the UI to the requirements attribute in the JDL if not specified by the user. If the user has instead provided an expression for the requirements attribute in the JDL, the one specified in the configuration file is added (in AND) to the existing one. E.g. if in the edg_wl_ui_cmd_var.conf configuration file there is:

requirements = other.GlueCEStateStatus == "Production" ;

and in the JDL file the user has specified:

requirements = other.GlueCEInfoLRMSType == "PBS";

then the job description that is passed to the NS contains

requirements = (other.GlueCEInfoLRMSType == "PBS") && (other.GlueCEStateStatus == "Production");

Obviously the setting TRUE for the requirements in the configuration file does not have any impact on the evaluation of job requirements as it would result in:

requirements = (other.GlueCEInfoLRMSType == "PBS") && TRUE ;

· rankthis is an expression representing the default value for the rank expression in the JDL job description. The value of this parameter is assigned by the UI to the rank attribute in the JDL if not specified by the user. This parameter is mandatory.

· RetryCountthis is an integer representing the default value for the number of submission retries for a job upon failure due to some grid component (i.e. not to the job itself). The value of this parameter is assigned by the UI to the RetryCount attribute in the JDL if not specified by the user.

· DefaultVothis is a string representing the name of the virtual organisation to be taken as the user’s VO (VirtualOrganisation attribute in the JDL) if not specified by the user neither in the credentials VOMS extension, nor directly in the job description nor through the --vo option. This attribute can be either set to “unspecified” or not included at all in the file to mean that no default is set for the VO.

· ErrorStorage this is a string representing the path of the directory where the UI creates log files. This directory is not created by the UI, so It has to be an already existing directory. Default for this parameter is /tmp.

· OutputStorage this is a string defining the path of the directory where the job OutputSandbox files are stored if not specified by the user through commands options. This directory is not created by the UI, so It has to be an already existing directory. Default for this parameter is /tmp.

· ListenerStorage this is a string defining the path of the directory where are created the pipes where the edg_grid_console_shadow process saves the job standard streams for interactive jobs. Default for this parameter is /tmp.

· LoggingDestination this is a string defining the address (:[

· LoggingTimeout this is an integer representing the timeout in seconds for asynchronous logging function called by the UI when logging events to the LB. Recommended value for UI that are non-local to the logging service (edg-wl-logd logging daemon) is not less than 30 seconds.

· LoggingSyncTimeout this is an integer representing the timeout in seconds for synchronous logging function called by the UI when logging events to the LB. Recommended value is not less than 30 seconds.

· DefaulStatusLevel this is an integer defining the default level of verbosity for the edg-job-status command. Possible values are 0,1 and 2. 0 is the default and means minimum verbosity. Default for this parameter is 0.

· DefaultLogInfoLevel this is an integer defining the default level of verbosity for the edg-job-get-logging-info command. Possible values are 0,1 and 2. 0 is the default and means minimum verbosity. Default for this parameter is 0.

· NSLoggerLevel this is an integer defining the quantity of information logged by the NS client. Possible values range from 0 to 6. 0 is the defaults and means that no information is logged. Default for this parameter is 0.

Hereafter is provided an example of the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf configuration file.

[


rank = - other.GlueCEStateEstimatedResponseTime ;

RetryCount = 3 ;

ErrorStorage= "/var/tmp" ;

OutputStorage="/tmp";

ListenerStorage = "/tmp"

LoggingTimeout = 30 ;

LoggingSyncTimeout = 45 ;

LoggingDestination = "ibm139.cnaf.infn.it:9002" ;

DefaultStatusLevel = 1 ;

DefaultLogInfoLevel = 0;

NSLoggerLevel = 2;

DefaultVo = "cms";

]

The files:

$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_err.conf

and

$EDG_WL_LOCATION/etc/edg_wl_ui_cmd_help.conf

contain respectively the error codes and error messages retyurned by the UI and the text describing the commands usage.

4.5.3.2. Java GUI

The Java GUI is composed by three components:

· JobSubmitter

· JobMonitor

· JDLEditor

Configuration of the Java GUI is accomplished through the file

$EDG_WL_LOCATION/etc/edg_wl_ui_gui_var.conf

This file is installed by the LCFGng object edg-lcfg-guiconfig, so if the installation is not performed using LCFGng, after having installed the UI rpm (edg-wl-ui-gui-X.Y.Z-K.i486.rpm) that creates the file:

$EDG_WL_LOCATION/etc/edg_wl_ui_gui_var.conf.template

you must copy it in :

$EDG_WL_LOCATION/etc/edg_wl_ui_gui_var.conf

and update the content of the latter file opportunely.

The edg_wl_ui_gui_var.conf file is a classad containing the following fields:

· JDLEDefaultSchema this is a string representing the default schema used by the JDLEditor for building the rank and requirements expressions in the JDL job description. This should be the schema of the Information Service describing the resources targeted by the job submissions.

The following three attributes -- requirements, rank and rankMPI -- are elements of a sub-classad that has the name of the schema (see example below):

· requirements

this is an expression representing the default value for the requirements expression in the JDL job description. This parameter is mandatory. The value of this parameter is assigned by the UI to the requirements attribute in the JDL if not specified by the user. If the user has instead provided an expression for the requirements attribute in the JDL, the one specified in the configuration file is added (in AND) to the existing one. E.g. if in the edg_wl_ui_gui_var.conf configuration file there is:


and in the JDL file the user has specified:

requirements = other.GlueCEInfoLRMSType == "PBS";

then the job description that is passed to the RB will contain

requirements = (other.GlueCEInfoLRMSType == "PBS") && (other.GlueCEStateStatus == "Production");

Obviously the setting TRUE for the requirements in the configuration file does not have any impact on the evaluation of job requirements as it would result in:

requirements = (other.GlueCEInfoLRMSType == "PBS") && TRUE ;

This parameter is repeated in the configuration file once per each supported schema (see example below).

· rankthis is an expression representing the default value for the rank expression in the JDL job description. The value of this parameter is assigned by the UI to the rank attribute in the JDL if not specified by the user. This parameter is mandatory. This parameter is repeated in the configuration file once per each supported schema (see example below).

· rankMPIthis is an expression representing the default value for the rank expression for MPI jobs (JobType = “MPICH”) in the JDL job description. The value of this parameter is assigned by the UI to the rank attribute in the JDL if not specified by the user. This parameter is repeated in the configuration file once per each supported schema (see example below). If this parameter is not present in the configuration file then the GUI takes as default the expression specified for the rank parameter also for MPI jobs. This parameter is repeated in the configuration file once per each supported schema (see example below).

· RetryCountthis is an integer representing the default value for the number of submission retries for a job upon failure due to some grid component (i.e. not to the job itself). The value of this parameter is assigned by the UI to the RetryCount attribute in the JDL if not specified by the user.

· ErrorStorage this is a string representing the path of the directory where the JDLEditor component creates parsing errors log files. This directory is not created by the GUI component, so it has to already exists on the machine. Default for this parameter is /tmp.

· LoggingDestination this is a string defining the address (:[

· LoggingTimeout this is an integer representing the timeout in seconds for asynchronous logging function called by the UI when logging events to the LB. Recommended value for UI that are non-local to the logging service (edg-wl-logd logging daemon) is not less than 30 seconds.

· LoggingSyncTimeout this is an integer representing the timeout in seconds for synchronous logging function called by the UI when logging events to the LB. Recommended value is not less than 30 seconds.

· NSLoggerLevel this is an integer defining the quantity of information logged by the NS client. Possible values range from 0 to 6. 0 is the defaults and means that no information is logged. Default for this parameter is 0.

Hereafter is provided an example of the $EDG_WL_LOCATION/etc/edg_wl_ui_gui_var.conf configuration file. In the following example supported schemas are Glue and the old EDG one.

[

JDLEDefaultSchema = "Glue" ;

Glue = [

rank = - other.GlueCEStateEstimantedResponseTime ;

rankMPI = other.GlueCEStateFreeCPUs;

requirements = other.GlueCEStateStatus == "Production";

] ;

EDG = [

rank = - other.EstimatedTraversalTime ;

rankMPI = other.FreeCPUs;

requirements = other.Active;

] ;

RetryCount = 3 ;

ErrorStorage= "/tmp" ;

LoggingTimeout = 30 ;

LoggingSyncTimeout = 60 ;

LoggingDestination = "ibm139.cnaf.infn.it:9002" ;

NSLoggerLevel = 0;

]

Additional files installed in $EDG_WL_LOCATION/etc are the Information Service schema definition files:

· edg_wl_ui_jdle_.xml (Glue and EDG are currently supported)

the condor dtd for parsing job description written in classad/xml format

· condor.dtd

and lastly the Log4j properties file (see 5.7.1)

· edg_wl_ui_gui_log4j.properties


Environment variables that have to be set for the User Interface are listed hereafter:

· X509_USER_KEY

the user private key file path. Default value is

$HOME/.globus/userkey.pem

· X509_USER_CERT

the user certificate file path.Default value is

$HOME/.globus/usercert.pem

· X509_CERT_DIR

the trusted certificate directory and ca-signing-policy

directory. Default value is /etc/grid-security/certificates

· X509_USER_PROXYthe user proxy certificate file path. Default value is

/tmp/x509up_u where UID is the user identifier on the machine as required by GSI.

These variables are used by the GSI layer to establish the security context.

Moreover there are:

· GLOBUS_LOCATIONThe Globus rpms installation path. It defaults to /opt/globus

· EDG_WL_LOCATIONThe User Interface installation path. It has to be set only if installation has been made in a non-standard location. It defaults to /opt/edg

· EDG_WL_LOG_DESTINATIONaddress (:[

· EDG_WL_LOG_TIMEOUTthe timeout in seconds for asynchronous logging function called by the UI when logging events to the LB. Recommended value for UI that are non-local to the logging service (edg-wl-logd logging daemon) is not less than 30 seconds. This variable takes precedence with respect to the value set into the UI configuration.

· EDG_WL_LOG_SYNC_TIMEOUT this is an integer representing the timeout in seconds for synchronous logging function called by the UI when logging events to the LB. Recommended value is not less than 30 seconds. This variable takes precedence with respect to the value set into the UI configuration.


· EDG_WL_UI_CONFIG_VARNon-standard location of the command line interface configuration file edg_wl_ui_cmd_var.conf. This variable points to the file absolute path.

· EDG_WL_UI_CONFIG_VONon-standard location of the vo-specific UI configuration file edg_wl_ui.conf. This variable points to the file absolute path.

4.5.4.2. Java GUI

· EDG_WL_GUI_CONFIG_VARNon-standard location of the command line interface configuration file edg_wl_ui_gui_var.conf. This variable points to the file absolute path.

· EDG_WL_GUI_CONFIG_VO Non-standard location of the vo-specific GUI configuration file edg_wl_ui.conf. This variable points to the file absolute path.

The GUI components also require setting of the following environment variables if the corresponding packages are not installed in the standard location (/usr/share/java)

· JAVA_INSTALL_PATH the installation path of Java 2 Development Kit

· COG_INSTALL_PATHthe installation path of the Globus Java CoG Kit

· LOG4J_INSTALL_PATHthe installation path the Log4J package

· CLASSADJ_INSTALL_PATHinstallation path of the the customised Condor classads java library

5. Operating the System

For security purposes all the WMS daemons run with proxy certificates. These certificates are generated from the start-up scripts that are described in the following section, before the applications are started. Lifetime of proxies created by the start-up scripts is 24 hours. In o

Documents

WMS SW Admin and User Guide - Istituto Nazionale di Fisica ...server11.infn.it/workload-grid/docs/DataGrid-01-TEN-0118-1_2.doc · Web viewThe –logfile option allows