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. Required software
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
254.2.2. 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
384.4.1. Required software
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. Configuration
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
424.4.3. Environment variables
434.5. User Interface
434.5.1. Required software
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
484.5.2.1. Python Command Line Interface
494.5.2.2. C++ API
494.5.2.3. Java API
504.5.2.4. Java GUI
514.5.3. Configuration
524.5.3.1. Python Command Line Interface
554.5.3.2. Java GUI
584.5.4. Environment variables
594.5.4.1. Python Command Line Interface
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.2.5. Troubleshooting
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.4.2. Troubleshooting
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.6.3. Troubleshooting
755.7. User Interface (Java GUI)
765.7.1. Troubleshooting
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-common-api-X.Y.Z-K_gcc3_2_2.i486.rpm
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-logging-api-c-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-config-X.Y.Z-K_gcc3_2_2.i486.rpm
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-config-X.Y.Z-K_gcc3_2_2.i486.rpm
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-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-logging-api-sh-X.Y.Z-K_gcc3_2_2.i486.rpm
edg-wl-common-api-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. Required software
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. Configuration
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.
4.2.1. Required software
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).
4.2.2. Configuration
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.
They are listed hereafter grouped according to the functionality they are related with:
· 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.
They are listed hereafter grouped according to the functionality they are related with:
· 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.
They are listed hereafter grouped according to the functionality they are related with:
· 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;
4.2.3. Environment variables
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
4.4.1. Required software
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. Configuration
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"
4.4.3. Environment variables
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
4.5.1. Required software
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
4.5.1.1. Python Command Line Interface
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-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-chkpt-api-X.Y.Z-K_gcc3_2_2.i486.rpm (Checkpointing API)
· edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm
(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-X.Y.Z-K_gcc3_2_2.i486.rpm (WMS common lib)
· edg-wl-common-api-java-X.Y.Z-K.i486.rpm
(requestAd jar)
· 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)
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-X.Y.Z-K_gcc3_2_2.i486.rpm (WMS common lib)
· edg-wl-common-api-java-X.Y.Z-K.i486.rpm
(requestAd jar)
· 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 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.
4.5.2.1. Python Command Line Interface
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-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-chkpt-api-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-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-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-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-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-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.
4.5.3. Configuration
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";
]
4.5.3.1. Python Command Line Interface
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.
[
requirements = other.GlueCEStateStatus == "Production" ;
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:
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 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
4.5.4. Environment variables
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.
4.5.4.1. Python Command Line Interface
· 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