istituto nazionale di fisica...

DataGr id

W P 1 - W M S S O F T W A R E A D M I N I S T R A T O R A N D U S E R G U I D E

Document identifier: DataGrid-01-TEN-0118-1_0

Date: 03/06/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.

IST-2000-25182 PUBLIC 1 / 185

WP1 - WMS SOFTWARE ADMINISTRATOR AND USER GUIDE

Doc. Identifier:

DataGrid-01-TEN-0118-1_0

Date: 29/05/2003

Delivery Slip

Name Partner Date Signature

From Fabrizio Pacini Datamat SpA 03/06/2003

Verified by Stefano Beco Datamat SpA 03/06/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_6 13/05/2002 Fabrizio Pacini




1_0 03/06/2003 First issue for Release 2.0Fabrizio Pacini,

Massimo Sgaravatto

IST-2000-25182 PUBLIC 2 / 185


Doc. Identifier:


Date: 29/05/2003

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

IST-2000-25182 PUBLIC 3 / 185


Doc. Identifier:


Date: 29/05/2003


Issue Item Reason for Change

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

IST-2000-25182 PUBLIC 4 / 185


Doc. Identifier:


Date: 29/05/2003


Issue Item Reason for Change 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

Files

Software Products User files

Word 2000 document.doc.doc

Acrobat Exchange 5.0 document.doc.pdf

IST-2000-25182 PUBLIC 5 / 185


Doc. Identifier:


Date: 29/05/2003

Content

1. Introduction......................................................................................................................................... 9

1.1. OBJECTIVES OF THIS DOCUMENT........................................................................................................91.2. APPLICATION AREA............................................................................................................................ 91.3. APPLICABLE DOCUMENTS AND REFERENCE DOCUMENTS......................................................................91.4. DOCUMENT EVOLUTION PROCEDURE.................................................................................................101.5. TERMINOLOGY................................................................................................................................. 10

2. EXECUTIVE SUMMARY.................................................................................................................. 12

3. WORKLOAD MANAGEMENT SYSTEM OVERVIEW.....................................................................133.1. DEPLOYMENT OF THE WMS SOFTWARE............................................................................................15

4. BUILD PROCEDURE....................................................................................................................... 164.1. REQUIRED SOFTWARE..................................................................................................................... 164.2. BUILD INSTRUCTIONS....................................................................................................................... 17

4.2.1. Environment Variables........................................................................................................174.2.2. Compiling the code.............................................................................................................19

4.3. RPM INSTALLATION......................................................................................................................... 29

5. INSTALLATION AND CONFIGURATION.......................................................................................325.1. LOGGING AND BOOKKEEPING SERVICES............................................................................................32

5.1.1. Required software...............................................................................................................325.1.1.1. LB local-logger...............................................................................................................................325.1.1.2. LB Server.......................................................................................................................................32

5.1.2. RPM installation.................................................................................................................. 335.1.3. The installation tree structure..............................................................................................34

5.1.3.1. LB local-logger...............................................................................................................................345.1.3.2. LB Server.......................................................................................................................................35

5.1.4. Configuration...................................................................................................................... 355.1.4.1. LB Local-Logger............................................................................................................................355.1.4.2. LB Server.......................................................................................................................................35

5.1.5. Environment Variables........................................................................................................365.2. SERVICES RUNNING IN THE “RB NODE”: NS, WM, JC, LM......................................................................38

5.2.1. Required software...............................................................................................................385.2.1.1. Globus installation and configuration............................................................................................385.2.1.2. ClassAd installation and configuration..........................................................................................395.2.1.3. Boost installation and configuration...............................................................................................395.2.1.4. Replica Manager installation and configuration.............................................................................40

5.2.2. RPM installation.................................................................................................................. 405.2.3. The Installation Tree structure............................................................................................405.2.4. Configuration...................................................................................................................... 45

5.2.4.1. Configuration of the “common” attributes......................................................................................465.2.4.2. NS configuration............................................................................................................................475.2.4.3. WM configuration...........................................................................................................................495.2.4.4. JC configuration.............................................................................................................................505.2.4.5. LM configuration............................................................................................................................52

5.2.5. Environment variables........................................................................................................535.2.6. Other requirements and configurations for the “RB node”..................................................54

5.2.6.1. Customized Gridftp server.............................................................................................................545.2.6.2. Grid-mapfile...................................................................................................................................555.2.6.3. Disk Quota.....................................................................................................................................55

5.3. SECURITY SERVICES........................................................................................................................ 565.3.1. Myproxy Server................................................................................................................... 565.3.2. Proxy renewal service.........................................................................................................57

IST-2000-25182 PUBLIC 6 / 185


Doc. Identifier:


Date: 29/05/2003

5.3.2.1. Required software.........................................................................................................................575.3.2.2. RPM installation.............................................................................................................................585.3.2.3. The installation tree structure........................................................................................................585.3.2.4. Configuration.................................................................................................................................585.3.2.5. Environment variables...................................................................................................................58

5.4. GRID ACCOUNTING SERVICES...........................................................................................................595.4.1. Required software...............................................................................................................59

5.4.1.1. Creating the MySQL databases for the HLR server......................................................................605.4.1.2. Creating the MySQL database for the PA server..........................................................................60

5.4.2. RPM installation.................................................................................................................. 615.4.3. The installation tree structure..............................................................................................615.4.4. Configuration...................................................................................................................... 61

5.4.4.1. Configuring the HLR server...........................................................................................................615.4.4.2. Configuring the PA server.............................................................................................................625.4.4.3. Configuring the ATM client software.............................................................................................62

5.4.5. Environment variables........................................................................................................635.5. USER INTERFACE............................................................................................................................. 64

5.5.1. Required software...............................................................................................................645.5.1.1. Python Command Line Interface...................................................................................................645.5.1.2. C++ API.........................................................................................................................................655.5.1.3. Java API........................................................................................................................................665.5.1.4. Java GUI........................................................................................................................................67

5.5.2. RPM installation.................................................................................................................. 685.5.2.1. Python Command Line Interface...................................................................................................685.5.2.2. C++ API.........................................................................................................................................765.5.2.3. Java API........................................................................................................................................835.5.2.4. Java GUI........................................................................................................................................89

5.5.3. Configuration...................................................................................................................... 955.5.3.1. Python Command Line Interface...................................................................................................975.5.3.2. Java GUI........................................................................................................................................99

5.5.4. Environment variables......................................................................................................1025.5.4.1. Python Command Line Interface.................................................................................................1035.5.4.2. Java GUI......................................................................................................................................103

6. OPERATING THE SYSTEM..........................................................................................................1056.1. LB LOCAL-LOGGER........................................................................................................................ 105

6.1.1. Starting and stopping daemons........................................................................................1056.1.2. Troubleshooting................................................................................................................106

6.2. LB SERVER................................................................................................................................... 1076.2.1. Starting and stopping daemons........................................................................................1076.2.2. Creating custom indices...................................................................................................1086.2.3. Purging the LB database..................................................................................................1106.2.4. Experimental R-GMA Interface.........................................................................................1106.2.5. Troubleshooting................................................................................................................111

6.3. SERVICES RUNNING IN THE “RB NODE”: NS, WM, JC, LM.............................................................1116.3.1. Starting and stopping NS, WM, JC and LM daemons.......................................................1116.3.2. NS, WM, JC, LM troubleshooting......................................................................................112

6.4. PROXY RENEWAL........................................................................................................................... 1126.4.1. Starting and stopping daemon..........................................................................................1126.4.2. Troubleshooting................................................................................................................112

6.5. PURGER........................................................................................................................................ 1126.6. GRID ACCOUNTING.................................................................................................................. 114

6.6.1. Starting and stopping daemon..........................................................................................1146.6.1.1. HLR server..................................................................................................................................1146.6.1.2. PA Server....................................................................................................................................115

6.6.2. HLR server administration................................................................................................1166.6.2.1. Creating a Fund account.............................................................................................................116

IST-2000-25182 PUBLIC 7 / 185


Doc. Identifier:


Date: 29/05/2003

6.6.2.2. Creating a Group account...........................................................................................................1176.6.2.3. Creating a User account..............................................................................................................1186.6.2.4. Creating a Resource account......................................................................................................1196.6.2.5. Deleting accounts........................................................................................................................120

6.6.3. Troubleshooting................................................................................................................1216.7. USER INTERFACE (JAVA GUI)........................................................................................................121

7. USER GUIDE................................................................................................................................. 1227.1. USER INTERFACE........................................................................................................................... 122

7.1.1. Security............................................................................................................................. 1227.1.1.1. MyProxy.......................................................................................................................................124

7.1.2. Common behaviours.........................................................................................................1257.1.3. Commands description.....................................................................................................129

7.1.3.1. edg-job-submit.............................................................................................................................1297.1.3.2. edg-job-get-output.......................................................................................................................1427.1.3.3. edg-job-list-match........................................................................................................................1467.1.3.4. edg-job-cancel.............................................................................................................................1517.1.3.5. edg-job-status..............................................................................................................................1567.1.3.6. edg-job-get-logging-info..............................................................................................................1627.1.3.7. edg-job-attach.............................................................................................................................1677.1.3.8. edg-job-get-chkpt........................................................................................................................169

8. ANNEXES...................................................................................................................................... 1728.1. JDL ATTRIBUTES........................................................................................................................... 1728.2. JOB STATUS DIAGRAM................................................................................................................... 1728.3. JOB EVENT TYPES......................................................................................................................... 1758.4. SUBMISSION FAILURES ANALYSIS...................................................................................................1778.5. WILDCARD PATTERNS..................................................................................................................... 1798.6. THE MATCH MAKING ALGORITHM...................................................................................................181

8.6.1. Direct Job Submission......................................................................................................1818.6.2. Job submission without data-access requirements...........................................................1818.6.3. Job submission with data-access requirements................................................................183

IST-2000-25182 PUBLIC 8 / 185


Doc. Identifier:


Date: 29/05/2003

1. INTRODUCTIONThis document provides a guide to the building, installation and usage of the WP1 WMS software released within the DataGrid project.

1.1. OBJECTIVES OF THIS DOCUMENTGoal 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 AREAAdministrators 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 ser-vices through the User Interface.

1.3. APPLICABLE DOCUMENTS AND REFERENCE DOCUMENTS Applicable documents[A1] JDL Attributes - DataGrid-01-NOT-0101-0_7 – 03/12/2002

(http://www.infn.it/workload-grid/docs/DataGrid-01-NOT-0101-0_7.{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 Service – 0705/2001(http://www.infn.it/workload-grid/docs/20010508-lb_draft-ruda.pdf)

[A5][A6][A7] 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)

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] ***[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)

IST-2000-25182 PUBLIC 9 / 185

Ales Krenek, 01/03/-1,

Add a formal reference here.


Doc. Identifier:


Date: 29/05/2003

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. TERMINOLOGYDefinitionsCondor Condor is a High Throughput Computing (HTC) environment that can

manage very large collections of distributively owned workstationsGlobus The Globus Toolkit is a set of software tools and libraries aimed at the

building of computational grids and grid-based applications.

Glossaryclass-ad Classified advertisementCECLI

Computing ElementCommand Line Interface

DBDGASEDG

Data BaseDatagrid Grid Accounting ServiceEuropean DataGrid

FQDN Fully Qualified Domain NameGIS Grid Information Service, aka MDSGSIGUIHLR

Grid Security InfrastructureGraphical User InterfaceHome Location Register

job-adJAJC

Class-ad describing a jobJob AdapterJob Controller

JDL Job Description LanguageLBLM

Logging and Bookkeeping ServiceLog Monitor

LRMS Local Resource Management SystemMDS Metacomputing Directory Service, aka GISMPINSOS

Message Passing InterfaceNetwork ServerOperating System

IST-2000-25182 PUBLIC 10 / 185


Doc. Identifier:


Date: 29/05/2003

PA Price AuthorityPID Process Identifier

PM Project MonthRB Resource BrokerSE Storage ElementSI00 Spec Int 2000SMP Symmetric Multi ProcessorTBC To Be ConfirmedTBD To Be DefinedUIVOWMWMS

User InterfaceVirtual OrganisationWorkload ManagerWorkload Management System

WP Work Package

IST-2000-25182 PUBLIC 11 / 185


Doc. Identifier:


Date: 29/05/2003

2. EXECUTIVE SUMMARYThis 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: Build ProcedureOutlines the software required to build the system and the actual process for building it and generating rpms for the WMS components; a step-by-step guide is included.

Section 5: Installation and ConfigurationDescribes 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 6: Operating the SystemProvides actual procedures for starting/stopping WMS components processes and utilities.

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

Section 8: AnnexesDeepens arguments introduced in the User Guide section that are considered useful for the user to better understand system behaviour.

IST-2000-25182 PUBLIC 12 / 185


Doc. Identifier:


Date: 29/05/2003

3. WORKLOAD MANAGEMENT SYSTEM OVERVIEWThe revised (release 2) architecture of the EDG Workload Management System (WMS), which is described in detail in [A2], is represented in .

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

IST-2000-25182 PUBLIC 13 / 185


Doc. Identifier:


Date: 29/05/2003

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, responsible 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 5.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 re-lies on the MyProxy software.

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

Economic accounting for Grid User and ResourcesThe users pay for resource usage while the resources earns virtual credits executing user jobs

Economic Brokering

IST-2000-25182 PUBLIC 14 / 185


Doc. Identifier:


Date: 29/05/2003

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 described elsewhere. The suggested configuration is to have a HLR server and a PA server per VO.

3.1. DEPLOYMENT OF THE WMS SOFTWAREFor 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) has 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 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

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

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).

IST-2000-25182 PUBLIC 15 / 185


Doc. Identifier:


Date: 29/05/2003

4. BUILD PROCEDUREIn the following section we give detailed instructions for the installation of the WP1 WMS software package. We provide a source code distribution as well as a binary distribution and explain installation procedures for both cases.

4.1. REQUIRED SOFTWAREThe WP1 software runs and has been tested on platforms running Globus Toolkit 2.0 Beta Release 21 on top of Linux RedHat 6.2. Hereafter are listed the software packages, apart from WP1 software version 1.0, that are required to be installed locally on a given site in order to be able to build the WP1 WMS on it. They are:

Globus Toolkit 2.0 Beta 21 or higher (download at http://datagrid.in2p3.fr/distribution/globus/beta-21)

Python 2.1.1 (download at http://datagrid.in2p3.fr/distribution/config/external.html)

Swig 1.3.9 (download at http://datagrid.in2p3.fr/distribution/config/external.html)

Expat 1.95.1 (download at http://datagrid.in2p3.fr/distribution/config/external.html)

Expat-devel 1.95.1 (download at http://datagrid.in2p3.fr/distribution/config/external.html)

MySQL Version 9.38 Distribution 3.22.32, for pc-linux-gnu (i686) (download at http://datagrid.in2p3.fr/distribution/config/external_services.html)

MySQL Version 11.15 Distribution 3.23.42, for pc-linux-gnu (i686)(download at http://datagrid.in2p3.fr/distribution/external/RPMS/). Hereafter the needed rpms:

MySQL-shared-3.23.42-1MySQL-client-3.23.42-1MySQL-3.23.42-1MySQL-devel-3.23.42-1

Postgresql 7.1.3 (http://datagrid.in2p3.fr/distribution/config/external_services.html)

Classads library (download at http://datagrid.in2p3.fr/distribution/external/RPMS/classads-0.0-edg2.i386.rpm)

IST-2000-25182 PUBLIC 16 / 185

http://datagrid.in2p3.fr/distribution/external/RPMS/classads-0.0-edg2.i386.rpm

http://datagrid.in2p3.fr/distribution/config/external_services.html

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

http://datagrid.in2p3.fr/distribution/config/external_services.html

http://datagrid.in2p3.fr/distribution/config/external.html




http://datagrid.in2p3.fr/distribution/globus/alpha-15


Doc. Identifier:


Date: 29/05/2003

CondorG 6.3.1 for INTEL-LINUX-GLIBC21 (download at http://datagrid.in2p3.fr/distribution/external/RPMS/CondorG-6.3.1-edg5.i386.rpm)

Perl IO Stty 0.02, Perl IO Tty 0.04 (download at http://datagrid.in2p3.fr/distribution/config/external.html )

MyProxy-0.4.4 (download at http://datagrid.in2p3.fr/distribution/external/RPMS/). Hereafter the needed rpms:

myproxy-server-0.4.4-edg6.i386.rpm (for the MyProxy Server machine)myproxy-client-0.4.4-edg6.i386.rpm (for the UI machine)

Perl 5 (download at http://datagrid.in2p3.fr/distribution/config/external.html)

gcc version 2.95.2

GNU make version 3.78.1 or higher

GNU autoconf version 2.13

GNU libtool 1.3.5

GNU automake 1.4

GNU m4 1.4 or higher

RPM 3.0.5

sendmail 8.11.6

4.2. BUILD INSTRUCTIONSThe following instructions deal with the building of the WMS software and hence apply to the source code distribution.

4.2.1. Environment VariablesBefore starting the compilation, some environment variables related to the WMS components can be set or configured by means of the configure script. This is needed only if package defaults are not suitable. Involved variables are listed below:

IST-2000-25182 PUBLIC 17 / 185




http://datagrid.in2p3.fr/distribution/external/RPMS/CondorG-6.3.1-edg5.i386.rpm


Doc. Identifier:


Date: 29/05/2003

- GLOBUS_LOCATION base directory of the Globus installationThe default path is /opt/globus.

- MYSQL_INSTALL_PATH base directory of the MySQL installationThe default path is /usr.

- EXPAT_INSTALL_PATH base directory of the Expat installation.The default path is /usr.

- GDMP_INSTALL_PATH base directory of the Gdmp installationThe default path is /opt/edg.

- PGSQL_INSTALL_PATH base directory of the Pgsql installation. The default path is /usr.

- CLASSAD_INSTALL_PATH base directory of the Classad library installation. The default path is /opt/classads.

- CONDORG_INSTALL_PATH base directory of the Condor installation. The default path is /opt/CondorG.

- PYTHON_INSTALL_PATH base directory of the Python installation.The default path is /usr.

- SWIG_INSTALL_PATH base directory of the Swig installation .The default path is /usr/local.

- MYPROXY_INSTALL_PATH base directory of the MyProxy installation .The default path is /usr/local.

In order to build the whole WP1 package, all the environment variables in the previous list must be set. Instead for building the User Interface module, the environment variables that need to be set are the following:

- GLOBUS_LOCATION- CLASSAD_INSTALL_PATH- PYTHON_INSTALL_PATH- SWIG_INSTALL_PATH- EXPAT_INSTALL_PATH

IST-2000-25182 PUBLIC 18 / 185


Doc. Identifier:


Date: 29/05/2003

If you plan to build the Job Submission and Resource Broker module, variable to set are:

- GLOBUS_LOCATION- MYSQL_INSTALL_PATH- EXPAT_INSTALL_PATH- GDMP_INSTALL_PATH- PGSQL_INSTALL_PATH- CLASSAD_INSTALL_PATH- CONDORG_INSTALL_PATH

If you plan to build the Proxy module, variables to set are:- GLOBUS_LOCATION- MYPROXY_INSTALL_PATH

Whilst the LB server and Local Logger modules, to be built need the following environment variables:

- GLOBUS_LOCATION- MYSQL_INSTALL_PATH- EXPAT_INSTALL_PATH

Finally, the LB library module needs:

- GLOBUS_LOCATION- EXPAT_INSTALL_PATH

and the Information Index module only:

- GLOBUS_LOCATION

4.2.2. Compiling the codeAfter having unpacked the WP1 source distribution tar file, or having downloaded the code directly from the CVS repository, change your working directory to be the WP1 base directory, i.e. the Workload directory, and run the following command:

./recursive-autogen.sh

At this point the configure command can be run. The configure script has to be invoked as follows:

IST-2000-25182 PUBLIC 19 / 185


Doc. Identifier:


Date: 29/05/2003

./configure <options>

The list of options that are recognized by configure is reported hereafter:

---help

--prefix=<installation path> It is used to specify the Workload installation dir. The default installation dir is /opt/edg.

--enable-allIt is used to enable the build of the whole WP1 package. By default this option is turned on.

--enable-userinterface It is used to enable the build of the User Interface module with Logging/Client, Broker/Client, Broker/Socket++ and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-userinterface_profile

It is used to enable the installation of the User Interface profile. By default this option is turned off.

--enable-jss_rbIt is used to enable the build of the Job Submission and Resource Broker modules with Logging/Client, Common, test, Proxy/Dgpr, and ThirdParty/trio/src submodules. By default this option is turned off.

--enable-jss_profileIt is used to enable the installation of the Job Submission and Resource Broker profile with JobSubmission/utils, and Broker/utils sub modules. By default this option is turned off.

--enable-lbserverIt is used to enable the build of the LB Server service with Logging/Client, Logging/etc, Logging/Server, Logging/InterLogger/Net, Logging/InterLogger/SSL, Logging/InterLogger/Error, Logging/InterLogger/Lbserver and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-locallogger

IST-2000-25182 PUBLIC 20 / 185


Doc. Identifier:


Date: 29/05/2003

It is used to enable the build of the LB Local Logger service with Logging/Client, Logging/InterLogger/Net, Logging/InterLogger/SSL, Logging/InterLogger/Error, Logging/InterLogger/InterLogger, Logging/LocalLogger, man and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-locallogger_profile

It is used to enable the installation of the LB LocalLogger profile. By default this option is turned off.

--enable-logging_devIt is used to enable the build of the LB Client Library with Logging/Client and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-information

It is used to enable the build of the Information Index module.By default this option is turned off.

--enable-information_profile

It is used to enable the installation of the Information Index profile with InformIndex/utils sub module. By default this option is turned off.

--enable-wl

It is used to enable the installation of system configuration files that are in the Workload/etc directory. By default this option is turned off.

--enable-proxyIt is used to enable the build of the Proxy module. By default this option is turned off.

--with-globus-install=<dir>It allows specifying the Globus installation directory without setting the environment variable GLOBUS_LOCATION.

--with-pgsql-install=<dir>It allows specifying the Pgsql installation directory without setting the environment variable PGSQL_INSTALL_PATH.

--with-gdmp-install=<dir>It allows specifying the GDMP installation directory without setting the environment variable GDMP_INSTALL_PATH.

IST-2000-25182 PUBLIC 21 / 185


Doc. Identifier:


Date: 29/05/2003

--with-expat-install=<dir>It allows specifying the Expat installation directory without setting the environment variable EXPAT_INSTALL_PATH.

--with-mysql-install=<dir>It allows to specify the MySQL installation directory without setting the environment variable MYSQL_INSTALL_PATH.

--with-myproxy-install=<dir>

It allows to specify the MyProxy installation directory without setting the environment variable MYPROXY_INSTALL_PATH

During the configure step, 12 spec files (i.e. wl-userinterface.spec, wl-locallogger.spec, wl lbserver.spec, wl-logging_dev.spec, wl-jss_rb.spec, wl-information.spec, wl-userinterface-profile.spec, wl-jss_rb-profile.spec, wl-information-profile.spec, wl-lbserver-profile.spec and wl-locallogger-profile.spec, wl-workload-profile.spec) are created in the following source sub-directories to produce a flavour specific version:

- Workload/UserInterface- Workload/Proxy- Workload/Logging- Workload/JobSubmission- Workload/InformIndex- Workload

Once the configure script has terminated its execution, check that the make from the GNU distribution is in your path and then always in the Workload source code directory run:

make

then:

make apidoc

and then:

make check

IST-2000-25182 PUBLIC 22 / 185


Doc. Identifier:


Date: 29/05/2003

to build the test code. If the two previous steps complete successfully, the installation of the software can be performed. In order to install the package in the installation directory specified either by the --prefix option of the configure script or by the default value (i.e. /opt/edg), you can now issue the command:

make install

It is possible to run "make clean" to remove object files, executable files, library files and all the other files that are created during ”make” and “make check”. The command:

make -i dist

can be used to produce in the workload-X.Y.Z directory, located in the Workload's base directory, a binary gzipped tar ball of the Workload distribution. This tar ball can be both transferred on other platforms and used as source for the RPM creation.For creating the RPMs for Workload 1.0 (according to the configure options you have used) make sure that your PATH is set in such a way that the GNU autotools, make and the gcc compiler can be used and edit the file $HOME/.rpmmacros (if this file does not exist in your home directory, then you have to create it) to set the following entry:

%_topdir <your home dir>/rpm/redhat

Then you can issue the command:

make rpm

that generates the RPMs in $(HOME)/rpm/redhat/RPMS.For example if before building the package you have used the configure as follows:

./configure –-enable-all

then the make rpm command creates the directories:

$(HOME)/rpm/redhat/SOURCES$(HOME)/rpm/redhat/SPECS$(HOME)/rpm/redhat/BUILD$(HOME)/rpm/redhat/RPMS$(HOME)/rpm/redhat/SRPMS

IST-2000-25182 PUBLIC 23 / 185


Doc. Identifier:


Date: 29/05/2003

and copies the previously created tar ball workload-X.Y.Z/Workload.tar.gz in $(HOME)/rpm/redhat/SOURCES. Moreover it copies the generated spec files:

JobSubmission/wl-jss_rb.specJobSubmission/wl-jss_rb-profile.specUserInterface/wl-userinterface.specUserInterface/wl-userinterface.specInformIndex/wl-information.specInformIndex/wl-informationpthr.specInformIndex/wl-information-profile.specLogging/wl-lbserver.specLogging/wl-lbserver-profile.specLogging/wl-locallogger.specLogging/wl-locallogger-profile.specLogging/wl-logging_dev.specProxy/wl-proxy.specWorkload/wl-workload-profile.specWorkload/wl-userguide.spec

in $(HOME)/rpm/redhat/SPECS and finally executes the following commands:

rpm -ba wl-userinterface.specrpm –ba wl-userinterface-profile.specrpm -ba wl-locallogger.specrpm -ba wl-locallogger-profile.specrpm -ba wl-lbserver.specrpm -ba wl-lbserver-profile.specrpm -ba wl-logging_dev.specrpm -ba wl-jss_rb.specrpm -ba wl-jss_rb-profile.specrpm -ba wl-information.specrpm -ba wl-informationpthr.specrpm -ba wl-information-profile.specrpm -ba wl-proxy.specrpm –ba wl-workload-profile.specrpm -ba wl-userguide.spec

IST-2000-25182 PUBLIC 24 / 185


Doc. Identifier:


Date: 29/05/2003

generating respectively the following rpms in the $(HOME)/rpm/redhat/RPMS directory:

- userinterface-X.Y.Z-K.i386.rpm- userinterface-profile-X.Y.Z-K.i386.rpm- locallogger- X.Y.Z-K.i386.rpm- locallogger-profile- X.Y.Z-K.i386.rpm- lbserver- X.Y.Z-K.i386.rpm- lbserver-profile- X.Y.Z-K.i386.rpm- logging_dev- X.Y.Z-K.i386.rpm- jobsubmission- X.Y.Z-K.i386.rpm- jobsubmission-profile- X.Y.Z-K.i386.rpm- informationindex- X.Y.Z-K.i386.rpm- informationindexpthr-X.Y.Z-K.i386.rpm- informationindex-profile- X.Y.Z-K.i386.rpm- proxy-X.Y.Z-K.i386.rpm- workload-profile-X.Y.Z-K.i386.rpm- userguide-X.Y.Z-K.i386.rpm

where X.Y.Z-K indicates the rpms release. If you have instead built only the User Interface, i.e. used:

./configure --disable-all --enable-userinterface

the make rpm command will copy only the file UserInterface/wl-userinterface.spec and the file UserInterface/wl-userinterface-profile.spec in $(HOME)/rpm/redhat/SPECS and will create only the User Interface rpms (userinterface-X.Y.Z-K.i386.rpm and userinterface-profile-X.Y.Z-K.i386.rpm).The User Interface has an additional make target to install the userinterface test suite allowing the performing of unit tests (i.e. without contacting any external component). You have to run the following commands in Worklaod/UserInterface:

./autogen.sh

./configure –disable-all –enable-testsmake tests

and you will find the commands ready to run together with the test files in Workload/UserInterface/test.An alternative procedure can be followed to build the II and Logging packages. To do this, move in the Workload/InformIndex dir and run the following commands:

IST-2000-25182 PUBLIC 25 / 185


Doc. Identifier:


Date: 29/05/2003

./autogen.sh

./configure [option]

where the recognised options are:

--prefix=<install path>It is used to specify the Information Index installation dir. The default installation dir is /opt/edg

--with-globus-install=<dir>

It allows to specify the Globus install directory without setting the environment variable GLOBUS_LOCATION.

Then issue:makemake install

Afterwards move into the Workload/Logging directory and run the following commands:

./autogen.sh

./configure [option]

where the recognised options are:--enable-all

It is used to enable the build of the Logging and Bookkeeping package.By default this option is turned on.

--enable-userinterfaceIt is used to enable the build of the Client sub module. By default this option is turned off.

--enable-graphical_userinterfaceIt is used to enable the build of the Client sub module. By default this option is turned off.

--enable-jss_rb

It is used to enable the build of the Client sub module. By default this option is turned off.

IST-2000-25182 PUBLIC 26 / 185


Doc. Identifier:


Date: 29/05/2003

--enable-lbserverIt is used to enable the build of the Logging And Bookkeeping Server service with Client, etc, Server, InterLogger/Net, InterLogger/SSL, InterLogger/Error, InterLogger/Lbserver and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-lbserver_profileIt is used to enable the installation of the LB Server profile with Logging/utils sub module. By default this option is turned off.

--enable-locallogger

It is used to enable the build of the Logging And Bookkeeping Local Logger service with Client, InterLogger/Net, InterLogger/SSL, InterLogger/Error, InterLogger/InterLogger, LocalLogger, Apidoc, and ThirdParty/trio/src sub modules. By default this option is turned off.

--enable-logging_dev

It is used to enable the build of the Logging And Bookkeeping Client Library with Client and ThirdParty/trio/src sub modules. By default this option is turned off.

--prefix=<install path>

It is used to specify the Logging installation dir. The default installation dir is /opt/edg

--with-globus-install=<dir>It allows specifying the Globus install directory without setting the environment variable GLOBUS_LOCATION.

--with-expat-install=<dir>

It allows specifying the Expat install directory without setting the environment variable EXPAT_INSTALL_PATH

--with-mysql-install=<dir>It allows specifying the MySQL install directory without setting the environment variable MYSQL_INSTALL_PATH.

Then issue:makemake apidoc

IST-2000-25182 PUBLIC 27 / 185


Doc. Identifier:


Date: 29/05/2003

make checkmake install

Summarising, in relation to the WMS module you want to build, the configure script has to be run with the following options:

- all./configure

- userinterface ./configure --disable-all --enable-userinterface

- information./configure --disable-all --enable-information

- lbserver./configure --disable-all --enable-lbserver

- locallogger./configure --disable-all --enable-locallogger

- logging for developers./configure --disable-all --enable-logging_dev

- jobsubmission and broker./configure --disable-all --enable-jss_rb

- wl./configure –disable-all –enable-wl

- proxy./configure --disable-all --enable-proxy

- userinterface profile ./configure --disable-all --enable-userinterface_profile

- information profile./configure --disable-all --enable-information_profile

IST-2000-25182 PUBLIC 28 / 185


Doc. Identifier:


Date: 29/05/2003

- information pthread./configure --disable-all --enable-information --with-globus-

flavor=gcc32dbgpthr

- lbserver profile./configure --disable-all --enable-lbserver_profile

- locallogger profile./configure --disable-all --enable-locallogger_profile

- jobsubmission and broker profile./configure --disable-all --enable-jss_profile

4.3. RPM INSTALLATIONIn order to install the WP1 RPMs on the target platforms, the following commands have to be executed as root:

rpm -ivh workload-profile.X.Y.Z-K.i386.rpmrpm –ivh userinterface-profile-X.Y.Z-K.i386.rpmrpm -ivh userinterface-X.Y.Z-K.i386.rpmrpm -ivh informationindex-profile-X.Y.Z-K.i386.rpmrpm -ivh informationindex-X.Y.Z-K.i386.rpmrpm –ivh informationindexpthr-X.Y.Z-K.i386.rpmrpm -ivh jobsubmission-profile-X.Y.Z-K.i386.rpmrpm -ivh jobsubmission-X.Y.Z.i386.rpmrpm -ivh locallogger-profile-X.Y.Z-K.i386.rpmrpm -ivh locallogger-X.Y.Z-K.i386.rpmrpm -ivh lbserver-profile-X.Y.Z-K.i386.rpmrpm -ivh lbserver-X.Y.Z-K.i386.rpmrpm -ivh logging_dev-X.Y.Z-K.i386.rpmrpm -ivh proxy-X.Y.Z-K.i386.rpmrpm -ivh userguide-X.Y.Z-k.i386.rpm

By default all the rpms install the software in the /opt/edg directory, but the profile rpms (i.e. informationindex-profile, jobsubmission-profile, locallogger-profile and lbserver-profile) that install instead in /etc/rc.d/init.d.

IST-2000-25182 PUBLIC 29 / 185


Doc. Identifier:


Date: 29/05/2003

All the profile rpms depend on the workload-profile rpm that in turn only depends on the bash rpm (whose version shoul be less than 2). Each component’s rpm then depends on the corresponding profile rpm (e.g. userinterface x.y.z depends on userinterface-profile-x.y.z that depends on workload-profile-x.y.z).If you install one of the following rpms:

- jobsubmission-X.Y.Z-K.i386.rpm- locallogger-X.Y.Z-K.i386.rpm- lbserver-X.Y.Z-K.i386.rpm- informationindex-X.Y.Z-K.i386.rpm- informationindexpthr-X.Y.Z-K.i386.rpm

you will have all needed files installed in /opt/edg and it is necessary to install the configuration and start-up files also in /etc/rc.d/init.d additionally installing the corresponding profile rpms. Namely using the rpms:

- jobsubmission-profile-X.Y.Z-K.i386.rpm- locallogger-profile-X.Y.Z-K.i386.rpm- lbserver-profile-X.Y.Z-K.i386.rpm- informationindex-profile-X.Y.Z-K.i386.rpm

the following scripts are respectively installed in /etc/rc.d/init.d- broker and jobsubmission- locallogger- lbserver- information_index

The administrator (with root privileges) has then to issue from /etc/rc.d/init.d the command:$ <script> start

to start the desired component. All start-up scripts accept the start, stop, restart and status options but the information_index that only supports start/stop.The workload-profile-X.Y.Z-K.rpm installs some scripts common to all services of the workload management:

/etc/sysconfig/edg_workload/etc/sysconfig/edg_workload.csh<install-path>/etc/workload.sh<install-path>/etc/workload.csh

They are needed to define and export some variables for the startup script environment. Above all, the PATH and the LD_LIBRARY_PATH needed to correctly run all the software.The jobsubmission-profile-X.Y.Z-K.i386.rpm as premised, additionally installs the wl-jss_rb-env.sh configuration file in /opt/edg/etc, that is read by the broker and jobsubmission startup files when they are launched as root. The /opt/edg/etc/wl-jss_rb-env.sh file contains setting for the following variables: CONDORG_INSTALL_PATH the CondorG installation path. Default value is

IST-2000-25182 PUBLIC 30 / 185


Doc. Identifier:


Date: 29/05/2003

/home/dguser/CondorG CONDOR_IDS this is needed by condor to know under which

user it has to run. Value for this variable has to be set in the format uid.gid where uid is the user identifier and gid is the group identifier. This value has to be set by the system administrator.

JSSRB_USER the user running RB and JSS processes. Generally the value of this variable is the user name corresponding to the uid.gid set for the CONDOR_IDS variable.

Details on the installation and configuration and of each of the listed rpms are provided in section 5 of this document. For further information about RPM please consult the man pages or http://www.rpm.org.

IST-2000-25182 PUBLIC 31 / 185

http://www.rpm.org/


Doc. Identifier:


Date: 29/05/2003

5. INSTALLATION AND CONFIGURATIONThis 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.

5.1. LOGGING AND BOOKKEEPING SERVICES From the installation point of view LB services can be split in two 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 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.

5.1.1. Required software

5.1.1.1. LB local-loggerFor 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/

5.1.1.2. LB ServerFor 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.

IST-2000-25182 PUBLIC 32 / 185

http://www.mysql.org/

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



Doc. Identifier:


Date: 29/05/2003

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 “<install path>/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/.

5.1.2. RPM installationIn order to install the LB local-logger and the LB server services, the following command have to be respectively issued with root privileges:

rpm -ivh workload-profile.X.Y.Z-K.i386.rpm

IST-2000-25182 PUBLIC 33 / 185




Doc. Identifier:


Date: 29/05/2003

rpm –ivh locallogger-X.Y.Z-K.i386.rpmrpm -ivh locallogger-profile-X.Y.Z-K.i386.rpmrpm -ivh lbserver-X.Y.Z-K.i386.rpmrpm -ivh lbserver-profile-X.Y.Z-K.i386.rpm

By default the locallogger-X.Y.Z-K.i386.rpm and lbserver-X.Y.Z-K.i386.rpm rpms install the software in the “/opt/edg” directory whilst the remaining two in “/etc/rc.d/init.d”.

5.1.3. The installation tree structure

5.1.3.1. LB local-loggerWhen the LB local-logger RPMs are installed, the following directory tree is created:

<install-path>/info<install-path>/info/interlogger.info<install-path>/lib<install-path>/man<install-path>/man/man1<install-path>/man/man1/interlogger.1<install-path>/man/man3<install-path>/man/man3/_dgLBJobStat.3<install-path>/man/man3/_dgLBQueryRec.3<install-path>/man/man3/dgLBEvent.3<install-path>/man/man3/dglbevents.3<install-path>/man/man3/dglog.3<install-path>/man/man3/dgssl.3<install-path>/man/man3/dgxferlog.3<install-path>/man/man3/escape.3<install-path>/man/man3/lbapi.3<install-path>/sbin<install-path>/sbin/dglogd<install-path>/sbin/interlogger<install-path>/sbin/locallogger<install-path>/share<install-path>/share/doc<install-path>/share/doc/Workload<install-path>/share/doc/Workload/Logging<install-path>/share/doc/Workload/Logging/html<install-path>/share/doc/Workload/Logging/html/annotated.html<install-path>/share/doc/Workload/Logging/html/class__dgLBJobStat-include.html<install-path>/share/doc/Workload/Logging/html/class__dgLBJobStat-members.html<install-path>/share/doc/Workload/Logging/html/class__dgLBJobStat.html<install-path>/share/doc/Workload/Logging/html/class__dgLBQueryRec-include.html<install-path>/share/doc/Workload/Logging/html/class__dgLBQueryRec-members.html<install-path>/share/doc/Workload/Logging/html/class__dgLBQueryRec.html<install-path>/share/doc/Workload/Logging/html/class_dgLBEvent-include.html<install-path>/share/doc/Workload/Logging/html/class_dgLBEvent.html

IST-2000-25182 PUBLIC 34 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/share/doc/Workload/Logging/html/doxygen.gif<install-path>/share/doc/Workload/Logging/html/files.html<install-path>/share/doc/Workload/Logging/html/functions.html<install-path>/share/doc/Workload/Logging/html/globals.html<install-path>/share/doc/Workload/Logging/html/headers.html<install-path>/share/doc/Workload/Logging/html/index.html<install-path>/share/doc/Workload/Logging/html/null.gif<install-path>/share/doc/Workload/Logging/refman.ps

/etc/rc.d/init.d/etc/rc.d/init.d/locallogger

The sbin directory contains all the LB local-logger daemons executables. The script locallogger contained in “/etc/rc.d/init.d “ has to be used for starting daemons. In the man directory can be found the man page for the inter-logger daemon.

5.1.3.2. LB ServerWhen the LB server RPMs are installed, the following directory tree is created:

<install-path>/etc<install-path>/etc/server.sql<install-path>/lib<install-path>/sbin<install-path>/sbin/bkpurge<install-path>/sbin/bkserver<install-path>/sbin/ileventd<install-path>/sbin/lbserver

/etc/rc.d/init.d/etc/rc.d/init.d/lbserver

where the sbin directory contains all the LB server daemons executables. The script lbserver contained in “/etc/rc.d/init.d “ has to be used for starting daemons.

5.1.4. Configuration

5.1.4.1. LB Local-LoggerThe LB local logger has no configuration file.

5.1.4.2. LB ServerThe LB server has no configuration file.

IST-2000-25182 PUBLIC 35 / 185


Doc. Identifier:


Date: 29/05/2003

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 6.2.2 for details.

5.1.5. Environment VariablesAll 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_HOSTNAMEHostname that will appear as the source of logged events

EDG_WL_LOG_DESTINATIONHostname:port of the local-logger to use

EDG_WL_LOG_TIMEOUTTimeout for standard (asynchronous) logging

EDG_WL_LOG_SYNC_TIMEOUTTimeout for synchronous logging

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

EDG_WL_QUERY_TIMEOUTTimeout for queries

IST-2000-25182 PUBLIC 36 / 185


Doc. Identifier:


Date: 29/05/2003

All them has reasonable defaults and needn’t be set in normal operation (details can be found in [LB-API-REFERENCE-DOCUMENT]).

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).

IST-2000-25182 PUBLIC 37 / 185

Ales Krenek, 01/03/-1,

Add a formal reference here.


Doc. Identifier:


Date: 29/05/2003

5.2. SERVICES RUNNING IN THE “RB NODE”: NS, WM, JC, LMAs 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.

5.2.1. Required softwareFor 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 5.1) ReplicaManager from the EDG WP2 distribution

5.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 5.2.6.1), while it should not run a globus gatekepeer.

5.2.1.1.1. Condor-G installation and configurationCondor-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/.Che si fa per la configuration ??

http://www.cs.wisc.edu/condor/downloads/condorg.license.html. whilst it is available in rpm format (to be installed as root) at:http://datagrid.in2p3.fr/distribution/external/RPMS Installation and configuration are quite straightforward and for details the reader can refer to the README file included in the Condor-G package. Main steps to be performed after having unpacked the package as root are: become dguser (su – dguser) make sure the directory where you are going to install CondorG is owned by dguser

IST-2000-25182 PUBLIC 38 / 185

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

http://www.cs.wisc.edu/condor/downloads/condorg.license.html

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



Doc. Identifier:


Date: 29/05/2003

make sure the Globus Toolkit 2.0 has been installed on the platform run the /opt/CondorG/setup.sh installation script remove the link ~dguser/.globus/certificates created by the installation script 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 = $(CONDORG_INSTALL_PATH)CONDOR_ADMIN = <a valid e-mail address of the Condor-G administrator>UID_DOMAIN = < the domain of the machine (e.g. pd.infn.it)>FILESYSTEM_DOMAIN = < the domain of the machine (e.g. pd.infn.it)>HOSTALLOW_WRITE = *CRED_MIN_TIME_LEFT = 0GLOBUSRUN = $(GLOBUS_LOCATION)/bin/globusrun

and the following entries need to be added:

SKIP_AUTHENTICATION = YESAUTHENTICATION_METHODS = CLAIMTOBEDISABLE_AUTH_NEGOTIATION = TRUEGRIDMANAGER_CHECKPROXY_INTERVAL = 600GRIDMANAGER_MINIMUM_PROXY_TIME = 180

The environment variable CONDORG_INSTALL_PATH is also set during installation and points to the path where the Condor-G package has been installed.The current version of Condor-G for working properly requires file /etc/grid-security/certificates/ca-signing-policy.conf that has been instead eliminated from the Globus Toolkit 2.0 distribution and must hence be created by the administrator. This need will be removed with next release of Condor-G that will be fully Globus Toolkit 2.0 compliant.

5.2.1.2. ClassAd installation and configurationThe 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.

5.2.1.3. Boost installation and configurationThe Boost C++ libraries release required is 1.29 (or higher).

IST-2000-25182 PUBLIC 39 / 185


Doc. Identifier:


Date: 29/05/2003

The boost documentation can be found at the following URL:http://www.boost.orgwhilst it is available in rpm format (to be installed as root) at:http://datagrid.in2p3.fr/distribution/external/RPMS

5.2.1.4. Replica Manager installation and configurationThe Replica Manager release required is ** (or higher) that is available in rpm format (to be installed as root) at:http://datagrid.in2p3.fr/distribution/wp2/**RPMS

5.2.2. RPM installation In order to install the NS-WM-JC-LM services, the following command has to be issued with root privileges: rpm -ivh edg-wl-wm-X.Y.Z-K.i486.rpm

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

5.2.3. The Installation Tree structureWhen the jobsubmission rpms have been installed, the following directory tree is created:

<install-path>/bin<install-path>/bin/RBserver<install-path>/bin/jssparser<install-path>/bin/jssserver<install-path>/etc<install-path>/etc/jss.conf<install-path>/etc/rb.conf<install-path>/etc/wl-jss_rb-env.sh<install-path>/lib<install-path>/man<install-path>/man/man3<install-path>/man/man3/BROKER_INFOstruct.3<install-path>/man/man3/CannotConfigure.3<install-path>/man/man3/CannotReadFile.3<install-path>/man/man3/ConfSchema.3

IST-2000-25182 PUBLIC 40 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/man/man3/DeletePointer.3<install-path>/man/man3/GDMP_ReplicaCatalog.3<install-path>/man/man3/InvalidURL.3<install-path>/man/man3/JSSConfiguration.3<install-path>/man/man3/JobWrapper.3<install-path>/man/man3/JssClient.3<install-path>/man/man3/LDAPConnection.3<install-path>/man/man3/LDAPSynchConnection.3<install-path>/man/man3/LogManager.3<install-path>/man/man3/MalformedFile.3<install-path>/man/man3/RBJobRegistry.3<install-path>/man/man3/RBMaster.3<install-path>/man/man3/RBReplicaCatalog.3<install-path>/man/man3/RBReplicaCatalogEx.3<install-path>/man/man3/RBjob.3<install-path>/man/man3/URL.3<install-path>/man/man3/brokerinfo.3<install-path>/man/man3/do_CloseSEs_supply_CE_with_nfiles.3<install-path>/man/man3/jsscommon.3<install-path>/man/man3/jssthreads.3<install-path>/man/man3/matchmaking.3<install-path>/man/man3/rbargs_t.3<install-path>/man/man3/rbhandlers.3<install-path>/man/man3/rbthreads.3<install-path>/man/man3/select_CE_on_files.3<install-path>/sbin<install-path>/sbin/broker<install-path>/sbin/jobsubmission<install-path>/share<install-path>/share/doc<install-path>/share/doc/Workload<install-path>/share/doc/Workload/Broker<install-path>/share/doc/Workload/Broker/COPYING<install-path>/share/doc/Workload/Broker/NEWS<install-path>/share/doc/Workload/Broker/README<install-path>/share/doc/Workload/Broker/html<install-path>/share/doc/Workload/Broker/html/annotated.html<install-path>/share/doc/Workload/Broker/html/class_BROKER_INFOstruct-include.html

IST-2000-25182 PUBLIC 41 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/share/doc/Workload/Broker/html/class_BROKER_INFOstruct-members.html<install-path>/share/doc/Workload/Broker/html/class_BROKER_INFOstruct.html<install-path>/share/doc/Workload/Broker/html/class_ConfSchema-include.html<install-path>/share/doc/Workload/Broker/html/class_ConfSchema-members.html<install-path>/share/doc/Workload/Broker/html/class_ConfSchema.html<install-path>/share/doc/Workload/Broker/html/class_GDMP_ReplicaCatalog-include.html<install-path>/share/doc/Workload/Broker/html/class_GDMP_ReplicaCatalog-members.html<install-path>/share/doc/Workload/Broker/html/class_GDMP_ReplicaCatalog.gif<install-path>/share/doc/Workload/Broker/html/class_GDMP_ReplicaCatalog.html<install-path>/share/doc/Workload/Broker/html/class_LDAPConnection-include.html<install-path>/share/doc/Workload/Broker/html/class_LDAPConnection-members.html<install-path>/share/doc/Workload/Broker/html/class_LDAPConnection.gif<install-path>/share/doc/Workload/Broker/html/class_LDAPConnection.html<install-path>/share/doc/Workload/Broker/html/class_LDAPSynchConnection-include.html<install-path>/share/doc/Workload/Broker/html/class_LDAPSynchConnection-members.html<install-path>/share/doc/Workload/Broker/html/class_LDAPSynchConnection.gif<install-path>/share/doc/Workload/Broker/html/class_LDAPSynchConnection.html<install-path>/share/doc/Workload/Broker/html/class_RBJobRegistry-include.html<install-path>/share/doc/Workload/Broker/html/class_RBJobRegistry-members.html<install-path>/share/doc/Workload/Broker/html/class_RBJobRegistry.html<install-path>/share/doc/Workload/Broker/html/class_RBMaster-include.html<install-path>/share/doc/Workload/Broker/html/class_RBMaster-members.html<install-path>/share/doc/Workload/Broker/html/class_RBMaster.html<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalog-include.html<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalog-members.html<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalog.gif<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalog.html<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalogEx-include.html<install-path>/share/doc/Workload/Broker/html/class_RBReplicaCatalogEx.html<install-path>/share/doc/Workload/Broker/html/class_RBjob-include.html<install-path>/share/doc/Workload/Broker/html/class_RBjob-members.html<install-path>/share/doc/Workload/Broker/html/class_RBjob.html<install-path>/share/doc/Workload/Broker/html/class_do_CloseSEs_supply_CE_with_nfiles-include.html<install-path>/share/doc/Workload/Broker/html/class_do_CloseSEs_supply_CE_with_nfiles-members.html<install-path>/share/doc/Workload/Broker/html/class_do_CloseSEs_supply_CE_with_nfiles.gif

IST-2000-25182 PUBLIC 42 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/share/doc/Workload/Broker/html/class_do_CloseSEs_supply_CE_with_nfiles.html<install-path>/share/doc/Workload/Broker/html/class_select_CE_on_files-include.html<install-path>/share/doc/Workload/Broker/html/class_select_CE_on_files-members.html<install-path>/share/doc/Workload/Broker/html/class_select_CE_on_files.gif<install-path>/share/doc/Workload/Broker/html/class_select_CE_on_files.html<install-path>/share/doc/Workload/Broker/html/doxygen.gif<install-path>/share/doc/Workload/Broker/html/files.html<install-path>/share/doc/Workload/Broker/html/functions.html<install-path>/share/doc/Workload/Broker/html/globals.html<install-path>/share/doc/Workload/Broker/html/group_ReplicaCatalog.html<install-path>/share/doc/Workload/Broker/html/headers.html<install-path>/share/doc/Workload/Broker/html/hierarchy.html<install-path>/share/doc/Workload/Broker/html/index.html<install-path>/share/doc/Workload/Broker/html/modules.html<install-path>/share/doc/Workload/Broker/html/null.gif<install-path>/share/doc/Workload/Broker/refman.ps<install-path>/share/doc/Workload/Common<install-path>/share/doc/Workload/Common/html<install-path>/share/doc/Workload/Common/html/annotated.html<install-path>/share/doc/Workload/Common/html/class_DeletePointer-include.html<install-path>/share/doc/Workload/Common/html/class_DeletePointer-members.html<install-path>/share/doc/Workload/Common/html/class_DeletePointer.html<install-path>/share/doc/Workload/Common/html/class_InvalidURL-include.html<install-path>/share/doc/Workload/Common/html/class_InvalidURL.html<install-path>/share/doc/Workload/Common/html/class_URL-include.html<install-path>/share/doc/Workload/Common/html/class_URL-members.html<install-path>/share/doc/Workload/Common/html/class_URL.html<install-path>/share/doc/Workload/Common/html/doxygen.gif<install-path>/share/doc/Workload/Common/html/files.html<install-path>/share/doc/Workload/Common/html/functions.html<install-path>/share/doc/Workload/Common/html/group_Common.html<install-path>/share/doc/Workload/Common/html/headers.html<install-path>/share/doc/Workload/Common/html/index.html<install-path>/share/doc/Workload/Common/html/modules.html<install-path>/share/doc/Workload/Common/html/null.gif<install-path>/share/doc/Workload/Common/refman.ps<install-path>/share/doc/Workload/JobSubmission

IST-2000-25182 PUBLIC 43 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/share/doc/Workload/JobSubmission/AUTHORS<install-path>/share/doc/Workload/JobSubmission/COPYING<install-path>/share/doc/Workload/JobSubmission/NEWS<install-path>/share/doc/Workload/JobSubmission/README<install-path>/share/doc/Workload/JobSubmission/html<install-path>/share/doc/Workload/JobSubmission/html/annotated.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotConfigure-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotConfigure-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotConfigure.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotReadFile-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotReadFile-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_CannotReadFile.html<install-path>/share/doc/Workload/JobSubmission/html/class_JSSConfiguration-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_JSSConfiguration-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_JSSConfiguration.html<install-path>/share/doc/Workload/JobSubmission/html/class_JobWrapper-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_JobWrapper-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_JobWrapper.html<install-path>/share/doc/Workload/JobSubmission/html/class_JssClient-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_JssClient-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_JssClient.html<install-path>/share/doc/Workload/JobSubmission/html/class_LogManager-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_LogManager-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_LogManager.html<install-path>/share/doc/Workload/JobSubmission/html/class_MalformedFile-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_MalformedFile-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_MalformedFile.html<install-path>/share/doc/Workload/JobSubmission/html/class_rbargs_t-include.html<install-path>/share/doc/Workload/JobSubmission/html/class_rbargs_t-members.html<install-path>/share/doc/Workload/JobSubmission/html/class_rbargs_t.gif<install-path>/share/doc/Workload/JobSubmission/html/class_rbargs_t.html<install-path>/share/doc/Workload/JobSubmission/html/doxygen.gif<install-path>/share/doc/Workload/JobSubmission/html/files.html<install-path>/share/doc/Workload/JobSubmission/html/functions.html<install-path>/share/doc/Workload/JobSubmission/html/globals.html<install-path>/share/doc/Workload/JobSubmission/html/group_JobWrapper.html

IST-2000-25182 PUBLIC 44 / 185


Doc. Identifier:


Date: 29/05/2003

<install-path>/share/doc/Workload/JobSubmission/html/group_JssClient.html<install-path>/share/doc/Workload/JobSubmission/html/group_JssConfigure.html<install-path>/share/doc/Workload/JobSubmission/html/group_JssError.html<install-path>/share/doc/Workload/JobSubmission/html/group_JssParser.html<install-path>/share/doc/Workload/JobSubmission/html/group_JssThreads.html<install-path>/share/doc/Workload/JobSubmission/html/headers.html<install-path>/share/doc/Workload/JobSubmission/html/hierarchy.html<install-path>/share/doc/Workload/JobSubmission/html/index.html<install-path>/share/doc/Workload/JobSubmission/html/modules.html<install-path>/share/doc/Workload/JobSubmission/html/null.gif<install-path>/share/doc/Workload/JobSubmission/refman.ps

/etc/rc.d/init.d/etc/rc.d/init.d/broker/etc/rc.d/init.d/jobsubmission

The directory bin contains all the RB and JSS server process executables Rbserver, jssserver and jssparser. In etc are stored the configuration files (see below Section 5.2.4.2 and section Error: Reference source not found). The scripts to start and stop the RB and JSS processes are contained in “/etc/rc.d/init.d”.

5.2.4. ConfigurationOnce the rpm has been installed, 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 = [

… …

];

IST-2000-25182 PUBLIC 45 / 185


Doc. Identifier:


Date: 29/05/2003

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

5.2.4.1. Configuration of the “common” attributesAs 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}”;

IST-2000-25182 PUBLIC 46 / 185


Doc. Identifier:


Date: 29/05/2003

5.2.4.2. NS configurationConfiguration 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:

IST-2000-25182 PUBLIC 47 / 185


Doc. Identifier:


Date: 29/05/2003

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 5.2.6.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 5.2.6.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.:

IST-2000-25182 PUBLIC 48 / 185


Doc. Identifier:


Date: 29/05/2003

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 5.2.6.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;

5.2.4.3. WM configurationConfiguration of the Workload Manager is accomplished editing the configuration file and setting opportunely the attributes in the:

WorkloadManager = [……

];


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:

IST-2000-25182 PUBLIC 49 / 185


Doc. Identifier:


Date: 29/05/2003

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.

5.2.4.4. JC configurationConfiguration of the Job Controller is accomplished editing the configuration file and setting opportunely the attributes in the:

JobController = [……

];

IST-2000-25182 PUBLIC 50 / 185


Doc. Identifier:


Date: 29/05/2003


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 5.2.4.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;

IST-2000-25182 PUBLIC 51 / 185


Doc. Identifier:


Date: 29/05/2003

5.2.4.5. LM configurationConfiguration of the Log Monitor is accomplished editing the configuration file and setting opportunely the attributes in the:

LogMonitor = [……

];


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.

IST-2000-25182 PUBLIC 52 / 185


Doc. Identifier:


Date: 29/05/2003

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;

5.2.5. 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_DESTINATIONThe 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 5.1.5).

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

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

IST-2000-25182 PUBLIC 53 / 185


Doc. Identifier:


Date: 29/05/2003

GRIDMAPThis 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 GLOBUS_LOCATION=/opt/globusCONDORG_INSTALL_PATH=/opt/condorEDG_WL_TMP=/var/tmpX509_USER_PROXY=/tmp/release2.proxyX509_HOST_CERT=/etc/grid-security/hostcert.pemX509_HOST_KEY=/etc/grid-security/hostkey.pem

GLOBUS_LOCATION

Altro ? GLOBUS_PATH ? X509_HOST_CERT ? the user certificate file path X509_HOST_KEY ? the user private key file path X509_USER_PROXY ? the user proxy certificate file path GRIDMAP ?

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.

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

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

IST-2000-25182 PUBLIC 54 / 185


Doc. Identifier:


Date: 29/05/2003

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 command has to be issued with root privileges: rpm -ivh 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:<INSTALL-PREFIX>/etc/ftpaccess

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

To start/stop …

5.2.6.2. Grid-mapfileThe 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.

5.2.6.3. Disk QuotaWhen 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 5.2.4.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.

IST-2000-25182 PUBLIC 55 / 185


Doc. Identifier:


Date: 29/05/2003

As introduced in section 5.2.4.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.

5.3. SECURITY SERVICESThe 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 the PR software and the Myproxy libraries (as discussed in the section 5.3.2)

In the “Myproxy server” node it is necessary to deploy the Myproxy Server software, discussed in section 5.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.

IST-2000-25182 PUBLIC 56 / 185

http://myproxy.ncsa.uiuc.edu/


Doc. Identifier:


Date: 29/05/2003

5.3.1. Myproxy Servermyproxy-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 <prefix>/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.

5.3.2. Proxy renewal service

5.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.The Myproxy libraries can be downloaded from: **

IST-2000-25182 PUBLIC 57 / 185




Doc. Identifier:


Date: 29/05/2003

5.3.2.2. RPM installationIn order to install the PR service, the following commands has to be issued with root privileges: rpm -ivh edg-wl-proxyrenewal-X.Y.Z-K.i486.rpm

By default the first rpm installs the software in the "/opt/edg" directory

5.3.2.3. The installation tree structure When the proxyrenewal rpms are installed, the following directory tree is created:

<install-path>/bin/edg-wl-renew<install-path>/etc/rc.d/init.d/edg-wl-proxyrenewal<install-path>/sbin/edg-wl-renewd<install-path>/share/doc/edg-wl-proxyrenewal-2.0.0/LICENSE<install-path>/share/doc/edg-wl-proxyrenewal-2.0.0/README

<install-path>/var<install-path>/var/spool<install-path>/var/spool/edg-wl-renewd

/etc/rc.d/init.d/etc/rc.d/init.d/renewald

The sbin directory contains the PR daemon executable, the bin directory contains the command-line program for contacting the daemon, the /var/spool/edg-wl-renewd directory is used by the daemon to store registered proxies. The script renewald in /etc/rc.d/init.d has to be used for starting daemon.

5.3.2.4. ConfigurationThe PR daemon has no configuration file.

5.3.2.5. Environment variablesThe PR daemon recognizes the following environment variables in the same way the GSI handles them:

X509_USER_KEY

IST-2000-25182 PUBLIC 58 / 185


Doc. Identifier:


Date: 29/05/2003

X509_USER_CERT X509_CERT_DIR X509_USER_PROXY

5.4. GRID ACCOUNTING SERVICES

5.4.1. Required softwareAs 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.orgAnyway 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, MySQL-devel-4.0.x and MySQL-client-4.0.x have to be installed.

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]).

IST-2000-25182 PUBLIC 59 / 185

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

http://www.mysql.org/




Doc. Identifier:


Date: 29/05/2003

5.4.1.1. Creating the MySQL databases for the HLR serverThe 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 <install-prefix>/etc and are:

hlr.sqlMain DB used by the HLR engine.

hlr_tmp.sqlDB 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

5.4.1.2. Creating the MySQL database for the PA serverThe 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 <install-path>/etc, and is:

pa.sqlMain 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

IST-2000-25182 PUBLIC 60 / 185


Doc. Identifier:


Date: 29/05/2003

5.4.2. RPM installationPer tutte le varie parti

5.4.3. The installation tree structureE3

5.4.4. Configuration

5.4.4.1. Configuring the HLR serverThe 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 6.6.1.1). The file is usually found in $<install-path>/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_userThe user running the HLR database

hlr_sql_password The HRL database user password

hlr_sql_dbname The HLR database name

hlr_tmp_sql_dbnameThe HRL tmp database name

hlr_port

The HLR server listening port

IST-2000-25182 PUBLIC 61 / 185


Doc. Identifier:


Date: 29/05/2003

hlr_log

The HLR log file name

5.4.4.2. Configuring the PA serverThe 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 6.6.1.2). The file is usually found in <install-path>/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_userThe 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

5.4.4.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 <install-path>/etc/ edg-wl-ATMClient-dgas.conf and it has to specify the two following attributes:

res_acct_PA_id

IST-2000-25182 PUBLIC 62 / 185


Doc. Identifier:


Date: 29/05/2003

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"

5.4.5. Environment variablesThe grid accounting services don’t rely on any environment variables.

IST-2000-25182 PUBLIC 63 / 185


Doc. Identifier:


Date: 29/05/2003

5.5. USER INTERFACEThis 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

5.5.1. Required softwareAll 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

5.5.1.1. Python Command Line InterfaceIn order to install the CLI, apart form the proper user interface rpm:

edg-wl-ui-cli-2.0.4-1_gcc3_2_2.i486.rpm

the common UI configuration rpm:

IST-2000-25182 PUBLIC 64 / 185


http://datagrid.in2p3.fr/distribution/datagrid/security/RPMS/local/

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



Doc. Identifier:


Date: 29/05/2003

edg-wl-ui-config-2.0.4-1_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-2.0.4-1_gcc3_2_2.i486.rpm (WMS common lib) edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm (LB client API) edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm (dgas job auth. client API) edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm (Condor bypass)

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.

edg-lcfg-cliconfig (per il conf file della command line)edg-lcfg-uicmnconfig (per il conf file a comune tra le due UI.. vienecreato il file per ogni VO che e' lower case)

5.5.1.2. C++ APIThe UI C++ API is distributed within the following rpm:

edg-wl-ui-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm

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

edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpm (WMS common lib) edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm (LB client API) edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm (dgas job auth. client API)

IST-2000-25182 PUBLIC 65 / 185

http://www.python.org/

http://datagrid.in2p3.fr/distribution/redhat-7.3/updates/RPMS


Doc. Identifier:


Date: 29/05/2003

edg-wl-chkpt-api-2.0.4-1_gcc3_2_2.i486.rpm (Checkpointing API) edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm (Condor bypass)

5.5.1.3. Java APIThe UI Java API is distributed within the following rpm:

edg-wl-ui-api-java-2.0.4-1.i486.rpm

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

edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpm (WMS common lib) edg-wl-common-api-java-2.0.4-1.i486.rpm (requestAd jar) edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm (LB client API) edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm (dgas job auth. client 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

and the Log4J package version 1.2.6:

log4j-1.2.6-1jpp.noarch.rpm

IST-2000-25182 PUBLIC 66 / 185



Doc. Identifier:


Date: 29/05/2003

5.5.1.4. Java GUIIn order to install the Java Graphical User Interface, apart form the proper GUI rpm:

edg-wl-ui-gui-2.0.6-1.i486.rpm

the Java API rpm:

edg-wl-ui-api-java-2.0.6-1.i486.rpm

the common UI configuration rpm:

edg-wl-ui-config-2.0.6-1_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-2.0.6-1_gcc3_2_2.i486.rpm (WMS common lib) edg-wl-common-api-java-2.0.6-1.i486.rpm (requestAd jar) edg-wl-logging-api-cpp-2.0.6-1_gcc3_2_2.i486.rpm (LB client API) edg-wl-dgas-hlr-jobAuthClient-2.0.6-1.i486.rpm (dgas job auth. client 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:

IST-2000-25182 PUBLIC 67 / 185



Doc. Identifier:


Date: 29/05/2003

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

and the Log4J package version 1.2.6:

log4j-1.2.6-1jpp.noarch.rpm

5.5.2. RPM installationAll the needed rpms can be downloaded with the command

wget -nd –r <URL>/<rpm name>

and installed with

rpm –ivh <rpm name>

As stated at the beginning of section 5.5.1 all UI packages requires the installation of the Globus Toolkit software release 2.2 from the VDT distribution and the MyProxy package.Hereafter are reported details for each UI package.

5.5.2.1. Python Command Line InterfaceIn order to install the python command line User Interface, the following command have to be issued with root privileges:

rpm –ivh edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpmrpm –ivh edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm rpm –ivh edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-ui-config-2.0.4-1_gcc3_2_2.i486.rpmrpm –ivh edg-wl-ui-cli-2.0.4-1_gcc3_2_2.i486.rpm

By default the rpms install the software in the “/opt/edg” directory.Of course the python2.2 rpm have to be installed too if they are not present on the machine (should be included in the RH 7.3 distribution).

5.5.2.1.1. The tree structureAfter all the rpms for the command line UI have been installed, the following directory tree is created (/opt/edg is the default installation dir, otherwise check in $EDG_WL_LOCATION):

IST-2000-25182 PUBLIC 68 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/bin/Job.py/opt/edg/bin/Job.pyc/opt/edg/bin/JobAdv.py/opt/edg/bin/JobAdv.pyc/opt/edg/bin/Listener.py/opt/edg/bin/Listener.pyc/opt/edg/bin/UIchecks.py/opt/edg/bin/UIchecks.pyc/opt/edg/bin/UIutils.py/opt/edg/bin/UIutils.pyc/opt/edg/bin/edg-job-attach/opt/edg/bin/edg-job-cancel/opt/edg/bin/edg-job-get-chkpt/opt/edg/bin/edg-job-get-logging-info/opt/edg/bin/edg-job-get-output/opt/edg/bin/edg-job-list-match/opt/edg/bin/edg-job-status/opt/edg/bin/edg-job-submit

/opt/globus/bin/myproxy-change-pass-phrase/opt/globus/bin/myproxy-destroy/opt/globus/bin/myproxy-get-delegation/opt/globus/bin/myproxy-info/opt/globus/bin/myproxy-init

/opt/edg/bin/edg-wl-grid-console-shadow

/opt/edg/etc/edg_wl_ui_cmd_err.conf/opt/edg/etc/edg_wl_ui_cmd_help.conf/opt/edg/etc/edg_wl_ui_cmd_var.conf.template/opt/edg/etc/vo_template/edg_wl_ui.conf/opt/edg/etc/<VO name>/edg_wl_ui.conf/opt/edg/etc/profile.d/edg-wl-ui-env.csh/opt/edg/etc/profile.d/edg-wl-ui-env.sh

/opt/edg/include/edg/workload/userinterface/common/AdWrapper.h/opt/edg/include/edg/workload/userinterface/common/LbWrapper.h

IST-2000-25182 PUBLIC 69 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/userinterface/common/LogWrapper.h/opt/edg/include/edg/workload/userinterface/common/NsWrapper.h

/opt/edg/include/edg/workload/common/common_namespace.h/opt/edg/include/edg/workload/common/configuration/CommonConfiguration.h/opt/edg/include/edg/workload/common/configuration/Configuration.h/opt/edg/include/edg/workload/common/configuration/JCConfiguration.h/opt/edg/include/edg/workload/common/configuration/LMConfiguration.h/opt/edg/include/edg/workload/common/configuration/ModuleType.h/opt/edg/include/edg/workload/common/configuration/NSConfiguration.h/opt/edg/include/edg/workload/common/configuration/WMConfiguration.h/opt/edg/include/edg/workload/common/configuration/confbase.h/opt/edg/include/edg/workload/common/configuration/cwrapper.h/opt/edg/include/edg/workload/common/configuration/exceptions.h/opt/edg/include/edg/workload/common/configuration/initializer.h/opt/edg/include/edg/workload/common/jobid/JobId.h/opt/edg/include/edg/workload/common/jobid/JobIdExceptions.h/opt/edg/include/edg/workload/common/jobid/JobIdn.h/opt/edg/include/edg/workload/common/jobid/jobid.h/opt/edg/include/edg/workload/common/jobid/manipulation.h/opt/edg/include/edg/workload/common/jobid/strmd5.h/opt/edg/include/edg/workload/common/ldif2classad/FileStreamConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPFilterParser.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPForwardIterator.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPQuery.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPSynchConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDIF2ClassAd.h/opt/edg/include/edg/workload/common/ldif2classad/LDIFObject.h/opt/edg/include/edg/workload/common/ldif2classad/exception_codes.h/opt/edg/include/edg/workload/common/ldif2classad/exceptions.h/opt/edg/include/edg/workload/common/logger/common.h/opt/edg/include/edg/workload/common/logger/container_ts.h/opt/edg/include/edg/workload/common/logger/edglog.h/opt/edg/include/edg/workload/common/logger/logbuf.h/opt/edg/include/edg/workload/common/logger/logstream.h/opt/edg/include/edg/workload/common/logger/logstream_ts.h/opt/edg/include/edg/workload/common/logger/manipulators.h

IST-2000-25182 PUBLIC 70 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/process/process.h/opt/edg/include/edg/workload/common/process/subprocess.h/opt/edg/include/edg/workload/common/process/user.h/opt/edg/include/edg/workload/common/requestad/Ad.h/opt/edg/include/edg/workload/common/requestad/DAGAd.h/opt/edg/include/edg/workload/common/requestad/JDLAttributes.h/opt/edg/include/edg/workload/common/requestad/JdlAttributeList.h/opt/edg/include/edg/workload/common/requestad/JobAd.h/opt/edg/include/edg/workload/common/requestad/JobAdExceptions.h/opt/edg/include/edg/workload/common/requestad/JobAdManipulation.h/opt/edg/include/edg/workload/common/requestad/ManipulationExceptions.h/opt/edg/include/edg/workload/common/requestad/PrivateAdManipulation.h/opt/edg/include/edg/workload/common/requestad/PrivateAttributes.h/opt/edg/include/edg/workload/common/requestad/convert.h/opt/edg/include/edg/workload/common/requestad/exception_codes.h/opt/edg/include/edg/workload/common/requestad/jdl_attributes.h/opt/edg/include/edg/workload/common/socket++/GSISocketAgent.h/opt/edg/include/edg/workload/common/socket++/GSISocketClient.h/opt/edg/include/edg/workload/common/socket++/GSISocketServer.h/opt/edg/include/edg/workload/common/socket++/SocketAgent.h/opt/edg/include/edg/workload/common/socket++/SocketClient.h/opt/edg/include/edg/workload/common/socket++/SocketServer.h/opt/edg/include/edg/workload/common/socket++/exception_codes.h/opt/edg/include/edg/workload/common/socket++/exceptions.h/opt/edg/include/edg/workload/common/socket++/tokens.h/opt/edg/include/edg/workload/common/utilities/Exceptions.h/opt/edg/include/edg/workload/common/utilities/Extractor.h/opt/edg/include/edg/workload/common/utilities/FLExtractor.h/opt/edg/include/edg/workload/common/utilities/FileList.h/opt/edg/include/edg/workload/common/utilities/FileListIterator.h/opt/edg/include/edg/workload/common/utilities/FileListLock.h/opt/edg/include/edg/workload/common/utilities/FileLocker.h/opt/edg/include/edg/workload/common/utilities/JDLAttributes.h/opt/edg/include/edg/workload/common/utilities/JobAdManipulation.h/opt/edg/include/edg/workload/common/utilities/LineParser.h/opt/edg/include/edg/workload/common/utilities/LineParserExceptions.h/opt/edg/include/edg/workload/common/utilities/boost_fs_add.h/opt/edg/include/edg/workload/common/utilities/classad_utils.h

IST-2000-25182 PUBLIC 71 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/utilities/edgstrstream.h/opt/edg/include/edg/workload/common/utilities/exception_codes.h/opt/edg/include/edg/workload/common/utilities/filecontainer.h/opt/edg/include/edg/workload/common/utilities/fstreamlock.h/opt/edg/include/edg/workload/common/utilities/globus_ftp_utils.h/opt/edg/include/edg/workload/common/utilities/ii_attr_utils.h/opt/edg/include/edg/workload/common/utilities/mixed.h/opt/edg/include/edg/workload/common/utilities/quota.h/opt/edg/include/edg/workload/common/utilities/result_codes.h/opt/edg/include/edg/workload/common/utilities/utils.h

/opt/edg/include/auth.h/opt/edg/include/external.h/opt/edg/include/external_unix.h/opt/edg/include/grid_console.h/opt/edg/include/hashtable.h/opt/edg/include/int_sizes.h/opt/edg/include/layer.h/opt/edg/include/network.h/opt/edg/include/packet.h/opt/edg/include/pattern.h/opt/edg/include/private_malloc.h

/opt/edg/include/edg-wl-dgas-jobAuthClient.h/opt/edg/include/edg/workload/logging/client/CountRef.h/opt/edg/include/edg/workload/logging/client/Event.h/opt/edg/include/edg/workload/logging/client/Job.h/opt/edg/include/edg/workload/logging/client/JobStatus.h/opt/edg/include/edg/workload/logging/client/LoggingExceptions.h/opt/edg/include/edg/workload/logging/client/ServerConnection.h

/opt/edg/lib/_edg_wl_userinterface_common_AdWrapper.a/opt/edg/lib/_edg_wl_userinterface_common_AdWrapper.la/opt/edg/lib/_edg_wl_userinterface_common_AdWrapper.so/opt/edg/lib/_edg_wl_userinterface_common_AdWrapper.so.0/opt/edg/lib/_edg_wl_userinterface_common_AdWrapper.so.0.0.0/opt/edg/lib/_edg_wl_userinterface_common_LbWrapper.a/opt/edg/lib/_edg_wl_userinterface_common_LbWrapper.la

IST-2000-25182 PUBLIC 72 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/_edg_wl_userinterface_common_LbWrapper.so/opt/edg/lib/_edg_wl_userinterface_common_LbWrapper.so.0/opt/edg/lib/_edg_wl_userinterface_common_LbWrapper.so.0.0.0/opt/edg/lib/_edg_wl_userinterface_common_LogWrapper.a/opt/edg/lib/_edg_wl_userinterface_common_LogWrapper.la/opt/edg/lib/_edg_wl_userinterface_common_LogWrapper.so/opt/edg/lib/_edg_wl_userinterface_common_LogWrapper.so.0/opt/edg/lib/_edg_wl_userinterface_common_LogWrapper.so.0.0.0/opt/edg/lib/_edg_wl_userinterface_common_NsWrapper.a/opt/edg/lib/_edg_wl_userinterface_common_NsWrapper.la/opt/edg/lib/_edg_wl_userinterface_common_NsWrapper.so/opt/edg/lib/_edg_wl_userinterface_common_NsWrapper.so.0/opt/edg/lib/_edg_wl_userinterface_common_NsWrapper.so.0.0.0/opt/edg/lib/libedg_wl_userinterface_common_AdWrapper.a/opt/edg/lib/libedg_wl_userinterface_common_AdWrapper.la/opt/edg/lib/libedg_wl_userinterface_common_AdWrapper.so/opt/edg/lib/libedg_wl_userinterface_common_AdWrapper.so.0/opt/edg/lib/libedg_wl_userinterface_common_AdWrapper.so.0.0.0/opt/edg/lib/libedg_wl_userinterface_common_LbWrapper.a/opt/edg/lib/libedg_wl_userinterface_common_LbWrapper.la/opt/edg/lib/libedg_wl_userinterface_common_LbWrapper.so/opt/edg/lib/libedg_wl_userinterface_common_LbWrapper.so.0/opt/edg/lib/libedg_wl_userinterface_common_LbWrapper.so.0.0.0/opt/edg/lib/libedg_wl_userinterface_common_LogWrapper.a/opt/edg/lib/libedg_wl_userinterface_common_LogWrapper.la/opt/edg/lib/libedg_wl_userinterface_common_LogWrapper.so/opt/edg/lib/libedg_wl_userinterface_common_LogWrapper.so.0/opt/edg/lib/libedg_wl_userinterface_common_LogWrapper.so.0.0.0/opt/edg/lib/libedg_wl_userinterface_common_NsWrapper.a/opt/edg/lib/libedg_wl_userinterface_common_NsWrapper.la/opt/edg/lib/libedg_wl_userinterface_common_NsWrapper.so/opt/edg/lib/libedg_wl_userinterface_common_NsWrapper.so.0/opt/edg/lib/libedg_wl_userinterface_common_NsWrapper.so.0.0.0

/opt/edg/lib/libedg_wl_LDIF2ClassAd.a/opt/edg/lib/libedg_wl_LDIF2ClassAd.la/opt/edg/lib/libedg_wl_LDIF2ClassAd.so/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0

IST-2000-25182 PUBLIC 73 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0.0.0/opt/edg/lib/libedg_wl_classad_plugin.a/opt/edg/lib/libedg_wl_classad_plugin.la/opt/edg/lib/libedg_wl_classad_plugin.so/opt/edg/lib/libedg_wl_classad_plugin.so.0/opt/edg/lib/libedg_wl_classad_plugin.so.0.0.0/opt/edg/lib/libedg_wl_common_requestad.a/opt/edg/lib/libedg_wl_common_requestad.la/opt/edg/lib/libedg_wl_common_requestad.so/opt/edg/lib/libedg_wl_common_requestad.so.0/opt/edg/lib/libedg_wl_common_requestad.so.0.0.0/opt/edg/lib/libedg_wl_conf.a/opt/edg/lib/libedg_wl_conf.la/opt/edg/lib/libedg_wl_conf.so/opt/edg/lib/libedg_wl_conf.so.0/opt/edg/lib/libedg_wl_conf.so.0.0.0/opt/edg/lib/libedg_wl_conf_wrapper.a/opt/edg/lib/libedg_wl_conf_wrapper.la/opt/edg/lib/libedg_wl_conf_wrapper.so/opt/edg/lib/libedg_wl_conf_wrapper.so.0/opt/edg/lib/libedg_wl_conf_wrapper.so.0.0.0/opt/edg/lib/libedg_wl_exceptions.a/opt/edg/lib/libedg_wl_exceptions.la/opt/edg/lib/libedg_wl_exceptions.so/opt/edg/lib/libedg_wl_exceptions.so.0/opt/edg/lib/libedg_wl_exceptions.so.0.0.0/opt/edg/lib/libedg_wl_globus_ftp_util.a/opt/edg/lib/libedg_wl_globus_ftp_util.la/opt/edg/lib/libedg_wl_globus_ftp_util.so/opt/edg/lib/libedg_wl_globus_ftp_util.so.0/opt/edg/lib/libedg_wl_globus_ftp_util.so.0.0.0/opt/edg/lib/libedg_wl_gsisocket_pp.a/opt/edg/lib/libedg_wl_gsisocket_pp.la/opt/edg/lib/libedg_wl_gsisocket_pp.so/opt/edg/lib/libedg_wl_gsisocket_pp.so.0/opt/edg/lib/libedg_wl_gsisocket_pp.so.0.0.0/opt/edg/lib/libedg_wl_iiattrutil.a/opt/edg/lib/libedg_wl_iiattrutil.la

IST-2000-25182 PUBLIC 74 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_iiattrutil.so/opt/edg/lib/libedg_wl_iiattrutil.so.0/opt/edg/lib/libedg_wl_iiattrutil.so.0.0.0/opt/edg/lib/libedg_wl_jobid.a/opt/edg/lib/libedg_wl_jobid.la/opt/edg/lib/libedg_wl_jobid.so/opt/edg/lib/libedg_wl_jobid.so.0/opt/edg/lib/libedg_wl_jobid.so.0.0.0/opt/edg/lib/libedg_wl_jutil.a/opt/edg/lib/libedg_wl_jutil.la/opt/edg/lib/libedg_wl_jutil.so/opt/edg/lib/libedg_wl_jutil.so.0/opt/edg/lib/libedg_wl_jutil.so.0.0.0/opt/edg/lib/libedg_wl_logger.a/opt/edg/lib/libedg_wl_logger.la/opt/edg/lib/libedg_wl_logger.so/opt/edg/lib/libedg_wl_logger.so.0/opt/edg/lib/libedg_wl_logger.so.0.0.0/opt/edg/lib/libedg_wl_process.a/opt/edg/lib/libedg_wl_process.la/opt/edg/lib/libedg_wl_process.so/opt/edg/lib/libedg_wl_process.so.0/opt/edg/lib/libedg_wl_process.so.0.0.0/opt/edg/lib/libedg_wl_socket_pp.a/opt/edg/lib/libedg_wl_socket_pp.la/opt/edg/lib/libedg_wl_socket_pp.so/opt/edg/lib/libedg_wl_socket_pp.so.0/opt/edg/lib/libedg_wl_socket_pp.so.0.0.0/opt/edg/lib/libedg_wl_util.a/opt/edg/lib/libedg_wl_util.la/opt/edg/lib/libedg_wl_util.so/opt/edg/lib/libedg_wl_util.so.0/opt/edg/lib/libedg_wl_util.so.0.0.0

/opt/edg/lib/libedg-wl-dgas-jobAuthClient.a/opt/edg/lib/libedg-wl-dgas-jobAuthClient.la/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0

IST-2000-25182 PUBLIC 75 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0.0.0/opt/edg/libexec/edg-wl-dgas-jobAuthClient

/opt/edg/lib/libedg_wl_loggingpp.a/opt/edg/lib/libedg_wl_loggingpp.la/opt/edg/lib/libedg_wl_loggingpp.so/opt/edg/lib/libedg_wl_loggingpp.so.0/opt/edg/lib/libedg_wl_loggingpp.so.0.0.0

/opt/edg/lib/python/edg_wl_userinterface_common_AdWrapper.py/opt/edg/lib/python/edg_wl_userinterface_common_AdWrapper.pyc/opt/edg/lib/python/edg_wl_userinterface_common_LbWrapper.py/opt/edg/lib/python/edg_wl_userinterface_common_LbWrapper.pyc/opt/edg/lib/python/edg_wl_userinterface_common_LogWrapper.py/opt/edg/lib/python/edg_wl_userinterface_common_LogWrapper.pyc/opt/edg/lib/python/edg_wl_userinterface_common_NsWrapper.py/opt/edg/lib/python/edg_wl_userinterface_common_NsWrapper.pyc/opt/edg/share/doc/edg-wl-ui-cli-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-ui-cli-2.0.4/README.commandline/opt/edg/share/doc/edg-wl-ui-config-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-ui-config-2.0.4/README.config

5.5.2.2. C++ APIIn order to install the UI C++ API , the following command have to be issued with root privileges:

rpm –ivh edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm rpm –ivh edg-wl-chkpt-api-2.0.4-1_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-2.0.4-1_gcc3_2_2.i486.rpm

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

IST-2000-25182 PUBLIC 76 / 185


Doc. Identifier:


Date: 29/05/2003

5.5.2.2.1. The tree structureAfter all the rpms for the UI C++ API have been installed, the following directory tree is created (/opt/edg is the default installation dir, otherwise check in $EDG_WL_LOCATION):

/opt/edg/include/edg/workload/userinterface/client/CredentialException.h/opt/edg/include/edg/workload/userinterface/client/Job.h/opt/edg/include/edg/workload/userinterface/client/JobCollection.h/opt/edg/include/edg/workload/userinterface/client/JobExceptions.h/opt/edg/include/edg/workload/userinterface/client/Listener.h/opt/edg/include/edg/workload/userinterface/client/NotificationAd.h/opt/edg/include/edg/workload/userinterface/client/Shadow.h/opt/edg/include/edg/workload/userinterface/client/UserCredential.h/opt/edg/include/edg/workload/userinterface/client/UserJobs.h/opt/edg/include/edg/workload/userinterface/client/exception_codes.h/opt/edg/include/edg/workload/userinterface/client/userinterface_namespace.h

/opt/edg/include/edg/workload/common/common_namespace.h/opt/edg/include/edg/workload/common/configuration/CommonConfiguration.h/opt/edg/include/edg/workload/common/configuration/Configuration.h/opt/edg/include/edg/workload/common/configuration/JCConfiguration.h/opt/edg/include/edg/workload/common/configuration/LMConfiguration.h/opt/edg/include/edg/workload/common/configuration/ModuleType.h/opt/edg/include/edg/workload/common/configuration/NSConfiguration.h/opt/edg/include/edg/workload/common/configuration/WMConfiguration.h/opt/edg/include/edg/workload/common/configuration/confbase.h/opt/edg/include/edg/workload/common/configuration/cwrapper.h/opt/edg/include/edg/workload/common/configuration/exceptions.h/opt/edg/include/edg/workload/common/configuration/initializer.h/opt/edg/include/edg/workload/common/jobid/JobId.h/opt/edg/include/edg/workload/common/jobid/JobIdExceptions.h/opt/edg/include/edg/workload/common/jobid/JobIdn.h/opt/edg/include/edg/workload/common/jobid/jobid.h/opt/edg/include/edg/workload/common/jobid/manipulation.h/opt/edg/include/edg/workload/common/jobid/strmd5.h/opt/edg/include/edg/workload/common/ldif2classad/FileStreamConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPFilterParser.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPForwardIterator.h

IST-2000-25182 PUBLIC 77 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/ldif2classad/LDAPQuery.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPSynchConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDIF2ClassAd.h/opt/edg/include/edg/workload/common/ldif2classad/LDIFObject.h/opt/edg/include/edg/workload/common/ldif2classad/exception_codes.h/opt/edg/include/edg/workload/common/ldif2classad/exceptions.h/opt/edg/include/edg/workload/common/logger/common.h/opt/edg/include/edg/workload/common/logger/container_ts.h/opt/edg/include/edg/workload/common/logger/edglog.h/opt/edg/include/edg/workload/common/logger/logbuf.h/opt/edg/include/edg/workload/common/logger/logstream.h/opt/edg/include/edg/workload/common/logger/logstream_ts.h/opt/edg/include/edg/workload/common/logger/manipulators.h/opt/edg/include/edg/workload/common/process/process.h/opt/edg/include/edg/workload/common/process/subprocess.h/opt/edg/include/edg/workload/common/process/user.h/opt/edg/include/edg/workload/common/requestad/Ad.h/opt/edg/include/edg/workload/common/requestad/DAGAd.h/opt/edg/include/edg/workload/common/requestad/JDLAttributes.h/opt/edg/include/edg/workload/common/requestad/JdlAttributeList.h/opt/edg/include/edg/workload/common/requestad/JobAd.h/opt/edg/include/edg/workload/common/requestad/JobAdExceptions.h/opt/edg/include/edg/workload/common/requestad/JobAdManipulation.h/opt/edg/include/edg/workload/common/requestad/ManipulationExceptions.h/opt/edg/include/edg/workload/common/requestad/PrivateAdManipulation.h/opt/edg/include/edg/workload/common/requestad/PrivateAttributes.h/opt/edg/include/edg/workload/common/requestad/convert.h/opt/edg/include/edg/workload/common/requestad/exception_codes.h/opt/edg/include/edg/workload/common/requestad/jdl_attributes.h/opt/edg/include/edg/workload/common/socket++/GSISocketAgent.h/opt/edg/include/edg/workload/common/socket++/GSISocketClient.h/opt/edg/include/edg/workload/common/socket++/GSISocketServer.h/opt/edg/include/edg/workload/common/socket++/SocketAgent.h/opt/edg/include/edg/workload/common/socket++/SocketClient.h/opt/edg/include/edg/workload/common/socket++/SocketServer.h/opt/edg/include/edg/workload/common/socket++/exception_codes.h/opt/edg/include/edg/workload/common/socket++/exceptions.h/opt/edg/include/edg/workload/common/socket++/tokens.h

IST-2000-25182 PUBLIC 78 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/utilities/Exceptions.h/opt/edg/include/edg/workload/common/utilities/Extractor.h/opt/edg/include/edg/workload/common/utilities/FLExtractor.h/opt/edg/include/edg/workload/common/utilities/FileList.h/opt/edg/include/edg/workload/common/utilities/FileListIterator.h/opt/edg/include/edg/workload/common/utilities/FileListLock.h/opt/edg/include/edg/workload/common/utilities/FileLocker.h/opt/edg/include/edg/workload/common/utilities/JDLAttributes.h/opt/edg/include/edg/workload/common/utilities/JobAdManipulation.h/opt/edg/include/edg/workload/common/utilities/LineParser.h/opt/edg/include/edg/workload/common/utilities/LineParserExceptions.h/opt/edg/include/edg/workload/common/utilities/boost_fs_add.h/opt/edg/include/edg/workload/common/utilities/classad_utils.h/opt/edg/include/edg/workload/common/utilities/edgstrstream.h/opt/edg/include/edg/workload/common/utilities/exception_codes.h/opt/edg/include/edg/workload/common/utilities/filecontainer.h/opt/edg/include/edg/workload/common/utilities/fstreamlock.h/opt/edg/include/edg/workload/common/utilities/globus_ftp_utils.h/opt/edg/include/edg/workload/common/utilities/ii_attr_utils.h/opt/edg/include/edg/workload/common/utilities/mixed.h/opt/edg/include/edg/workload/common/utilities/quota.h/opt/edg/include/edg/workload/common/utilities/result_codes.h/opt/edg/include/edg/workload/common/utilities/utils.h/opt/edg/include/auth.h/opt/edg/include/external.h/opt/edg/include/external_unix.h/opt/edg/include/grid_console.h/opt/edg/include/hashtable.h/opt/edg/include/int_sizes.h/opt/edg/include/layer.h/opt/edg/include/network.h/opt/edg/include/packet.h/opt/edg/include/pattern.h/opt/edg/include/private_malloc.h/opt/edg/include/edg-wl-dgas-jobAuthClient.h/opt/edg/include/edg/workload/logging/client/CountRef.h/opt/edg/include/edg/workload/logging/client/Event.h/opt/edg/include/edg/workload/logging/client/Job.h

IST-2000-25182 PUBLIC 79 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/logging/client/JobStatus.h/opt/edg/include/edg/workload/logging/client/LoggingExceptions.h/opt/edg/include/edg/workload/logging/client/ServerConnection.h/opt/edg/include/edg/workload/checkpointing/client/ChkptException.h/opt/edg/include/edg/workload/checkpointing/client/checkpointing.h/opt/edg/include/edg/workload/checkpointing/client/checkpointing_namespace.h/opt/edg/include/edg/workload/checkpointing/client/error_code.h/opt/edg/include/edg/workload/checkpointing/client/jobstate.h/opt/edg/include/edg/workload/checkpointing/client/step.h/opt/edg/include/edg/workload/checkpointing/client/stepper.h

/opt/edg/lib/libedg_wl_userinterface_client.a/opt/edg/lib/libedg_wl_userinterface_client.la/opt/edg/lib/libedg_wl_userinterface_client.so/opt/edg/lib/libedg_wl_userinterface_client.so.0/opt/edg/lib/libedg_wl_userinterface_client.so.0.0.0/opt/edg/share/doc/edg-wl-ui-api-cpp-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-ui-api-cpp-2.0.4/README.client

/opt/edg/lib/libedg_wl_LDIF2ClassAd.a/opt/edg/lib/libedg_wl_LDIF2ClassAd.la/opt/edg/lib/libedg_wl_LDIF2ClassAd.so/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0.0.0/opt/edg/lib/libedg_wl_classad_plugin.a/opt/edg/lib/libedg_wl_classad_plugin.la/opt/edg/lib/libedg_wl_classad_plugin.so/opt/edg/lib/libedg_wl_classad_plugin.so.0/opt/edg/lib/libedg_wl_classad_plugin.so.0.0.0/opt/edg/lib/libedg_wl_common_requestad.a/opt/edg/lib/libedg_wl_common_requestad.la/opt/edg/lib/libedg_wl_common_requestad.so/opt/edg/lib/libedg_wl_common_requestad.so.0/opt/edg/lib/libedg_wl_common_requestad.so.0.0.0/opt/edg/lib/libedg_wl_conf.a/opt/edg/lib/libedg_wl_conf.la/opt/edg/lib/libedg_wl_conf.so/opt/edg/lib/libedg_wl_conf.so.0

IST-2000-25182 PUBLIC 80 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_conf.so.0.0.0/opt/edg/lib/libedg_wl_conf_wrapper.a/opt/edg/lib/libedg_wl_conf_wrapper.la/opt/edg/lib/libedg_wl_conf_wrapper.so/opt/edg/lib/libedg_wl_conf_wrapper.so.0/opt/edg/lib/libedg_wl_conf_wrapper.so.0.0.0/opt/edg/lib/libedg_wl_exceptions.a/opt/edg/lib/libedg_wl_exceptions.la/opt/edg/lib/libedg_wl_exceptions.so/opt/edg/lib/libedg_wl_exceptions.so.0/opt/edg/lib/libedg_wl_exceptions.so.0.0.0/opt/edg/lib/libedg_wl_globus_ftp_util.a/opt/edg/lib/libedg_wl_globus_ftp_util.la/opt/edg/lib/libedg_wl_globus_ftp_util.so/opt/edg/lib/libedg_wl_globus_ftp_util.so.0/opt/edg/lib/libedg_wl_globus_ftp_util.so.0.0.0/opt/edg/lib/libedg_wl_gsisocket_pp.a/opt/edg/lib/libedg_wl_gsisocket_pp.la/opt/edg/lib/libedg_wl_gsisocket_pp.so/opt/edg/lib/libedg_wl_gsisocket_pp.so.0/opt/edg/lib/libedg_wl_gsisocket_pp.so.0.0.0/opt/edg/lib/libedg_wl_iiattrutil.a/opt/edg/lib/libedg_wl_iiattrutil.la/opt/edg/lib/libedg_wl_iiattrutil.so/opt/edg/lib/libedg_wl_iiattrutil.so.0/opt/edg/lib/libedg_wl_iiattrutil.so.0.0.0/opt/edg/lib/libedg_wl_jobid.a/opt/edg/lib/libedg_wl_jobid.la/opt/edg/lib/libedg_wl_jobid.so/opt/edg/lib/libedg_wl_jobid.so.0/opt/edg/lib/libedg_wl_jobid.so.0.0.0/opt/edg/lib/libedg_wl_jutil.a/opt/edg/lib/libedg_wl_jutil.la/opt/edg/lib/libedg_wl_jutil.so/opt/edg/lib/libedg_wl_jutil.so.0/opt/edg/lib/libedg_wl_jutil.so.0.0.0/opt/edg/lib/libedg_wl_logger.a/opt/edg/lib/libedg_wl_logger.la

IST-2000-25182 PUBLIC 81 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_logger.so/opt/edg/lib/libedg_wl_logger.so.0/opt/edg/lib/libedg_wl_logger.so.0.0.0/opt/edg/lib/libedg_wl_process.a/opt/edg/lib/libedg_wl_process.la/opt/edg/lib/libedg_wl_process.so/opt/edg/lib/libedg_wl_process.so.0/opt/edg/lib/libedg_wl_process.so.0.0.0/opt/edg/lib/libedg_wl_socket_pp.a/opt/edg/lib/libedg_wl_socket_pp.la/opt/edg/lib/libedg_wl_socket_pp.so/opt/edg/lib/libedg_wl_socket_pp.so.0/opt/edg/lib/libedg_wl_socket_pp.so.0.0.0/opt/edg/lib/libedg_wl_util.a/opt/edg/lib/libedg_wl_util.la/opt/edg/lib/libedg_wl_util.so/opt/edg/lib/libedg_wl_util.so.0/opt/edg/lib/libedg_wl_util.so.0.0.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.a/opt/edg/lib/libedg-wl-dgas-jobAuthClient.la/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0.0.0/opt/edg/libexec/edg-wl-dgas-jobAuthClient/opt/edg/lib/libedg_wl_loggingpp.a/opt/edg/lib/libedg_wl_loggingpp.la/opt/edg/lib/libedg_wl_loggingpp.so/opt/edg/lib/libedg_wl_loggingpp.so.0/opt/edg/lib/libedg_wl_loggingpp.so.0.0.0/opt/edg/lib/libedg_wl_checkpointing.a/opt/edg/lib/libedg_wl_checkpointing.la/opt/edg/lib/libedg_wl_checkpointing.so/opt/edg/lib/libedg_wl_checkpointing.so.0/opt/edg/lib/libedg_wl_checkpointing.so.0.0.0

5.5.2.3. Java APIIn order to install the UI Java API , the following command have to be issued with root privileges:

IST-2000-25182 PUBLIC 82 / 185


Doc. Identifier:


Date: 29/05/2003

rpm –ivh j2sdk-1.4.1_01-fcs.i586.rpmrpm –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.rpmrpm –ivh log4j-1.2.6-1jpp.noarch.rpm

rpm –ivh edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm rpm –ivh edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-common-api-java-2.0.5-1.i486.rpm rpm –ivh edg-wl-ui-api-java-2.0.5-1.i486.rpm

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

5.5.2.3.1. The tree structureAfter all the rpms for the UI Java API have been installed, the following directory tree is created (/opt/edg is the default installation dir, otherwise check in $EDG_WL_LOCATION):

/opt/edg/share/doc/edg-wl-common-api-java-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-common-api-java-2.0.4/README.j/opt/edg/share/java/edg_wl_common_jrequestad.jar/opt/edg/share/java/edg_wl_userinterface_jclient.jar/opt/edg/include/edg/workload/userinterface/jcommon/edg_workload_userinterface_jclient_Api.h

/opt/edg/lib/libedg_wl_userinterface_native.a/opt/edg/lib/libedg_wl_userinterface_native.la/opt/edg/lib/libedg_wl_userinterface_native.so/opt/edg/lib/libedg_wl_userinterface_native.so.0/opt/edg/lib/libedg_wl_userinterface_native.so.0.0.0/opt/edg/share/doc/edg-wl-ui-api-java-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-ui-api-java-2.0.4/README.jclient

/opt/edg/include/edg/workload/common/common_namespace.h/opt/edg/include/edg/workload/common/configuration/CommonConfiguration.h/opt/edg/include/edg/workload/common/configuration/Configuration.h

IST-2000-25182 PUBLIC 83 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/configuration/JCConfiguration.h/opt/edg/include/edg/workload/common/configuration/LMConfiguration.h/opt/edg/include/edg/workload/common/configuration/ModuleType.h/opt/edg/include/edg/workload/common/configuration/NSConfiguration.h/opt/edg/include/edg/workload/common/configuration/WMConfiguration.h/opt/edg/include/edg/workload/common/configuration/confbase.h/opt/edg/include/edg/workload/common/configuration/cwrapper.h/opt/edg/include/edg/workload/common/configuration/exceptions.h/opt/edg/include/edg/workload/common/configuration/initializer.h/opt/edg/include/edg/workload/common/jobid/JobId.h/opt/edg/include/edg/workload/common/jobid/JobIdExceptions.h/opt/edg/include/edg/workload/common/jobid/JobIdn.h/opt/edg/include/edg/workload/common/jobid/jobid.h/opt/edg/include/edg/workload/common/jobid/manipulation.h/opt/edg/include/edg/workload/common/jobid/strmd5.h/opt/edg/include/edg/workload/common/ldif2classad/FileStreamConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPFilterParser.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPForwardIterator.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPQuery.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPSynchConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDIF2ClassAd.h/opt/edg/include/edg/workload/common/ldif2classad/LDIFObject.h/opt/edg/include/edg/workload/common/ldif2classad/exception_codes.h/opt/edg/include/edg/workload/common/ldif2classad/exceptions.h/opt/edg/include/edg/workload/common/logger/common.h/opt/edg/include/edg/workload/common/logger/container_ts.h/opt/edg/include/edg/workload/common/logger/edglog.h/opt/edg/include/edg/workload/common/logger/logbuf.h/opt/edg/include/edg/workload/common/logger/logstream.h/opt/edg/include/edg/workload/common/logger/logstream_ts.h/opt/edg/include/edg/workload/common/logger/manipulators.h/opt/edg/include/edg/workload/common/process/process.h/opt/edg/include/edg/workload/common/process/subprocess.h/opt/edg/include/edg/workload/common/process/user.h/opt/edg/include/edg/workload/common/requestad/Ad.h/opt/edg/include/edg/workload/common/requestad/DAGAd.h/opt/edg/include/edg/workload/common/requestad/JDLAttributes.h

IST-2000-25182 PUBLIC 84 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/requestad/JdlAttributeList.h/opt/edg/include/edg/workload/common/requestad/JobAd.h/opt/edg/include/edg/workload/common/requestad/JobAdExceptions.h/opt/edg/include/edg/workload/common/requestad/JobAdManipulation.h/opt/edg/include/edg/workload/common/requestad/ManipulationExceptions.h/opt/edg/include/edg/workload/common/requestad/PrivateAdManipulation.h/opt/edg/include/edg/workload/common/requestad/PrivateAttributes.h/opt/edg/include/edg/workload/common/requestad/convert.h/opt/edg/include/edg/workload/common/requestad/exception_codes.h/opt/edg/include/edg/workload/common/requestad/jdl_attributes.h/opt/edg/include/edg/workload/common/socket++/GSISocketAgent.h/opt/edg/include/edg/workload/common/socket++/GSISocketClient.h/opt/edg/include/edg/workload/common/socket++/GSISocketServer.h/opt/edg/include/edg/workload/common/socket++/SocketAgent.h/opt/edg/include/edg/workload/common/socket++/SocketClient.h/opt/edg/include/edg/workload/common/socket++/SocketServer.h/opt/edg/include/edg/workload/common/socket++/exception_codes.h/opt/edg/include/edg/workload/common/socket++/exceptions.h/opt/edg/include/edg/workload/common/socket++/tokens.h/opt/edg/include/edg/workload/common/utilities/Exceptions.h/opt/edg/include/edg/workload/common/utilities/Extractor.h/opt/edg/include/edg/workload/common/utilities/FLExtractor.h/opt/edg/include/edg/workload/common/utilities/FileList.h/opt/edg/include/edg/workload/common/utilities/FileListIterator.h/opt/edg/include/edg/workload/common/utilities/FileListLock.h/opt/edg/include/edg/workload/common/utilities/FileLocker.h/opt/edg/include/edg/workload/common/utilities/JDLAttributes.h/opt/edg/include/edg/workload/common/utilities/JobAdManipulation.h/opt/edg/include/edg/workload/common/utilities/LineParser.h/opt/edg/include/edg/workload/common/utilities/LineParserExceptions.h/opt/edg/include/edg/workload/common/utilities/boost_fs_add.h/opt/edg/include/edg/workload/common/utilities/classad_utils.h/opt/edg/include/edg/workload/common/utilities/edgstrstream.h/opt/edg/include/edg/workload/common/utilities/exception_codes.h/opt/edg/include/edg/workload/common/utilities/filecontainer.h/opt/edg/include/edg/workload/common/utilities/fstreamlock.h/opt/edg/include/edg/workload/common/utilities/globus_ftp_utils.h/opt/edg/include/edg/workload/common/utilities/ii_attr_utils.h

IST-2000-25182 PUBLIC 85 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/utilities/mixed.h/opt/edg/include/edg/workload/common/utilities/quota.h/opt/edg/include/edg/workload/common/utilities/result_codes.h/opt/edg/include/edg/workload/common/utilities/utils.h/opt/edg/include/auth.h/opt/edg/include/external.h/opt/edg/include/external_unix.h/opt/edg/include/grid_console.h/opt/edg/include/hashtable.h/opt/edg/include/int_sizes.h/opt/edg/include/layer.h/opt/edg/include/network.h/opt/edg/include/packet.h/opt/edg/include/pattern.h/opt/edg/include/private_malloc.h/opt/edg/include/edg-wl-dgas-jobAuthClient.h/opt/edg/include/edg/workload/logging/client/CountRef.h/opt/edg/include/edg/workload/logging/client/Event.h/opt/edg/include/edg/workload/logging/client/Job.h/opt/edg/include/edg/workload/logging/client/JobStatus.h/opt/edg/include/edg/workload/logging/client/LoggingExceptions.h/opt/edg/include/edg/workload/logging/client/ServerConnection.h

/opt/edg/lib/libedg_wl_LDIF2ClassAd.a/opt/edg/lib/libedg_wl_LDIF2ClassAd.la/opt/edg/lib/libedg_wl_LDIF2ClassAd.so/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0.0.0/opt/edg/lib/libedg_wl_classad_plugin.a/opt/edg/lib/libedg_wl_classad_plugin.la/opt/edg/lib/libedg_wl_classad_plugin.so/opt/edg/lib/libedg_wl_classad_plugin.so.0/opt/edg/lib/libedg_wl_classad_plugin.so.0.0.0/opt/edg/lib/libedg_wl_common_requestad.a/opt/edg/lib/libedg_wl_common_requestad.la/opt/edg/lib/libedg_wl_common_requestad.so/opt/edg/lib/libedg_wl_common_requestad.so.0/opt/edg/lib/libedg_wl_common_requestad.so.0.0.0

IST-2000-25182 PUBLIC 86 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_conf.a/opt/edg/lib/libedg_wl_conf.la/opt/edg/lib/libedg_wl_conf.so/opt/edg/lib/libedg_wl_conf.so.0/opt/edg/lib/libedg_wl_conf.so.0.0.0/opt/edg/lib/libedg_wl_conf_wrapper.a/opt/edg/lib/libedg_wl_conf_wrapper.la/opt/edg/lib/libedg_wl_conf_wrapper.so/opt/edg/lib/libedg_wl_conf_wrapper.so.0/opt/edg/lib/libedg_wl_conf_wrapper.so.0.0.0/opt/edg/lib/libedg_wl_exceptions.a/opt/edg/lib/libedg_wl_exceptions.la/opt/edg/lib/libedg_wl_exceptions.so/opt/edg/lib/libedg_wl_exceptions.so.0/opt/edg/lib/libedg_wl_exceptions.so.0.0.0/opt/edg/lib/libedg_wl_globus_ftp_util.a/opt/edg/lib/libedg_wl_globus_ftp_util.la/opt/edg/lib/libedg_wl_globus_ftp_util.so/opt/edg/lib/libedg_wl_globus_ftp_util.so.0/opt/edg/lib/libedg_wl_globus_ftp_util.so.0.0.0/opt/edg/lib/libedg_wl_gsisocket_pp.a/opt/edg/lib/libedg_wl_gsisocket_pp.la/opt/edg/lib/libedg_wl_gsisocket_pp.so/opt/edg/lib/libedg_wl_gsisocket_pp.so.0/opt/edg/lib/libedg_wl_gsisocket_pp.so.0.0.0/opt/edg/lib/libedg_wl_iiattrutil.a/opt/edg/lib/libedg_wl_iiattrutil.la/opt/edg/lib/libedg_wl_iiattrutil.so/opt/edg/lib/libedg_wl_iiattrutil.so.0/opt/edg/lib/libedg_wl_iiattrutil.so.0.0.0/opt/edg/lib/libedg_wl_jobid.a/opt/edg/lib/libedg_wl_jobid.la/opt/edg/lib/libedg_wl_jobid.so/opt/edg/lib/libedg_wl_jobid.so.0/opt/edg/lib/libedg_wl_jobid.so.0.0.0/opt/edg/lib/libedg_wl_jutil.a/opt/edg/lib/libedg_wl_jutil.la/opt/edg/lib/libedg_wl_jutil.so

IST-2000-25182 PUBLIC 87 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_jutil.so.0/opt/edg/lib/libedg_wl_jutil.so.0.0.0/opt/edg/lib/libedg_wl_logger.a/opt/edg/lib/libedg_wl_logger.la/opt/edg/lib/libedg_wl_logger.so/opt/edg/lib/libedg_wl_logger.so.0/opt/edg/lib/libedg_wl_logger.so.0.0.0/opt/edg/lib/libedg_wl_process.a/opt/edg/lib/libedg_wl_process.la/opt/edg/lib/libedg_wl_process.so/opt/edg/lib/libedg_wl_process.so.0/opt/edg/lib/libedg_wl_process.so.0.0.0/opt/edg/lib/libedg_wl_socket_pp.a/opt/edg/lib/libedg_wl_socket_pp.la/opt/edg/lib/libedg_wl_socket_pp.so/opt/edg/lib/libedg_wl_socket_pp.so.0/opt/edg/lib/libedg_wl_socket_pp.so.0.0.0/opt/edg/lib/libedg_wl_util.a/opt/edg/lib/libedg_wl_util.la/opt/edg/lib/libedg_wl_util.so/opt/edg/lib/libedg_wl_util.so.0/opt/edg/lib/libedg_wl_util.so.0.0.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.a/opt/edg/lib/libedg-wl-dgas-jobAuthClient.la/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0.0.0/opt/edg/libexec/edg-wl-dgas-jobAuthClient/opt/edg/lib/libedg_wl_loggingpp.a/opt/edg/lib/libedg_wl_loggingpp.la/opt/edg/lib/libedg_wl_loggingpp.so/opt/edg/lib/libedg_wl_loggingpp.so.0/opt/edg/lib/libedg_wl_loggingpp.so.0.0.0

5.5.2.4. Java GUIIn order to install the Java GUI, the following command have to be issued with root privileges:

IST-2000-25182 PUBLIC 88 / 185


Doc. Identifier:


Date: 29/05/2003

rpm –ivh j2sdk-1.4.1_01-fcs.i586.rpmrpm –ivh j2sdk_profile-1.4.1_01-1.noarch.rpm

rpm –ivh classads-jar-1.1-2.i386.rpmrpm –ivh cog-jar-1.0-alpha-1.0-1_alpha.i386.rpmrpm –ivh log4j-1.2.6-1jpp.noarch.rpm

rpm –ivh edg-wl-common-api-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-logging-api-cpp-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-dgas-hlr-jobAuthClient-2.0.4-1.i486.rpm rpm –ivh edg-wl-bypass-2.5.3-4_gcc3_2_2.i486.rpm

rpm –ivh edg-wl-common-api-java-2.0.4-1.i486.rpmrpm –ivh edg-wl-ui-api-java-2.0.5-1.i486.rpmrpm –ivh edg-wl-ui-config-2.0.4-1_gcc3_2_2.i486.rpm rpm –ivh edg-wl-ui-gui-2.0.4-1.i486.rpm

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

5.5.2.4.1. The tree structureAfter all the rpms for the Java GUI have been installed, the following directory tree is created (/opt/edg is the default installation dir, otherwise check in $EDG_WL_LOCATION):

/opt/edg/etc/condor.dtd/opt/edg/etc/edg_wl_ui_gui_var.conf.template/opt/edg/etc/edg_wl_ui_jdle_EDG.xml/opt/edg/etc/edg_wl_ui_jdle_GLUE.xml/opt/edg/etc/profile.d/edg-wl-ui-gui-env.csh/opt/edg/etc/profile.d/edg-wl-ui-gui-env.sh/opt/edg/etc/vo_template/edg_wl_ui.conf/opt/edg/etc/<VO name>/edg_wl_ui.conf/opt/edg/sbin/edg-wl-ui-jobsubmitter.sh/opt/edg/sbin/edg-wl-ui-jobsubmitter.csh/opt/edg/sbin/edg-wl-ui-jdleditor.sh/opt/edg/sbin/edg-wl-ui-jdleditor.csh/opt/edg/sbin/edg-wl-ui-jobmonitor.sh/opt/edg/sbin/edg-wl-ui-jobmonitor.csh/opt/edg/share/doc/edg-wl-ui-gui-2.0.4/LICENSE

IST-2000-25182 PUBLIC 89 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/share/doc/edg-wl-ui-gui-2.0.4/README.gui/opt/edg/share/java/JobUiTest.class/opt/edg/share/java/Test.class/opt/edg/share/java/TestContact.class/opt/edg/share/java/TestMulti.class/opt/edg/share/java/TestRoot.class/opt/edg/share/java/edg_wl_userinterface_gui.jar

/opt/edg/share/doc/edg-wl-common-api-java-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-common-api-java-2.0.4/README.j/opt/edg/share/java/edg_wl_common_jrequestad.jar/opt/edg/share/java/edg_wl_userinterface_jclient.jar/opt/edg/include/edg/workload/userinterface/jcommon/edg_workload_userinterface_jclient_Api.h

/opt/edg/lib/libedg_wl_userinterface_native.a/opt/edg/lib/libedg_wl_userinterface_native.la/opt/edg/lib/libedg_wl_userinterface_native.so/opt/edg/lib/libedg_wl_userinterface_native.so.0/opt/edg/lib/libedg_wl_userinterface_native.so.0.0.0/opt/edg/share/doc/edg-wl-ui-api-java-2.0.4/LICENSE/opt/edg/share/doc/edg-wl-ui-api-java-2.0.4/README.jclient

/opt/edg/include/edg/workload/common/common_namespace.h/opt/edg/include/edg/workload/common/configuration/CommonConfiguration.h/opt/edg/include/edg/workload/common/configuration/Configuration.h/opt/edg/include/edg/workload/common/configuration/JCConfiguration.h/opt/edg/include/edg/workload/common/configuration/LMConfiguration.h/opt/edg/include/edg/workload/common/configuration/ModuleType.h/opt/edg/include/edg/workload/common/configuration/NSConfiguration.h/opt/edg/include/edg/workload/common/configuration/WMConfiguration.h/opt/edg/include/edg/workload/common/configuration/confbase.h/opt/edg/include/edg/workload/common/configuration/cwrapper.h/opt/edg/include/edg/workload/common/configuration/exceptions.h/opt/edg/include/edg/workload/common/configuration/initializer.h/opt/edg/include/edg/workload/common/jobid/JobId.h/opt/edg/include/edg/workload/common/jobid/JobIdExceptions.h/opt/edg/include/edg/workload/common/jobid/JobIdn.h/opt/edg/include/edg/workload/common/jobid/jobid.h/opt/edg/include/edg/workload/common/jobid/manipulation.h

IST-2000-25182 PUBLIC 90 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/jobid/strmd5.h/opt/edg/include/edg/workload/common/ldif2classad/FileStreamConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPFilterParser.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPForwardIterator.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPQuery.h/opt/edg/include/edg/workload/common/ldif2classad/LDAPSynchConnection.h/opt/edg/include/edg/workload/common/ldif2classad/LDIF2ClassAd.h/opt/edg/include/edg/workload/common/ldif2classad/LDIFObject.h/opt/edg/include/edg/workload/common/ldif2classad/exception_codes.h/opt/edg/include/edg/workload/common/ldif2classad/exceptions.h/opt/edg/include/edg/workload/common/logger/common.h/opt/edg/include/edg/workload/common/logger/container_ts.h/opt/edg/include/edg/workload/common/logger/edglog.h/opt/edg/include/edg/workload/common/logger/logbuf.h/opt/edg/include/edg/workload/common/logger/logstream.h/opt/edg/include/edg/workload/common/logger/logstream_ts.h/opt/edg/include/edg/workload/common/logger/manipulators.h/opt/edg/include/edg/workload/common/process/process.h/opt/edg/include/edg/workload/common/process/subprocess.h/opt/edg/include/edg/workload/common/process/user.h/opt/edg/include/edg/workload/common/requestad/Ad.h/opt/edg/include/edg/workload/common/requestad/DAGAd.h/opt/edg/include/edg/workload/common/requestad/JDLAttributes.h/opt/edg/include/edg/workload/common/requestad/JdlAttributeList.h/opt/edg/include/edg/workload/common/requestad/JobAd.h/opt/edg/include/edg/workload/common/requestad/JobAdExceptions.h/opt/edg/include/edg/workload/common/requestad/JobAdManipulation.h/opt/edg/include/edg/workload/common/requestad/ManipulationExceptions.h/opt/edg/include/edg/workload/common/requestad/PrivateAdManipulation.h/opt/edg/include/edg/workload/common/requestad/PrivateAttributes.h/opt/edg/include/edg/workload/common/requestad/convert.h/opt/edg/include/edg/workload/common/requestad/exception_codes.h/opt/edg/include/edg/workload/common/requestad/jdl_attributes.h/opt/edg/include/edg/workload/common/socket++/GSISocketAgent.h/opt/edg/include/edg/workload/common/socket++/GSISocketClient.h/opt/edg/include/edg/workload/common/socket++/GSISocketServer.h/opt/edg/include/edg/workload/common/socket++/SocketAgent.h

IST-2000-25182 PUBLIC 91 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/edg/workload/common/socket++/SocketClient.h/opt/edg/include/edg/workload/common/socket++/SocketServer.h/opt/edg/include/edg/workload/common/socket++/exception_codes.h/opt/edg/include/edg/workload/common/socket++/exceptions.h/opt/edg/include/edg/workload/common/socket++/tokens.h/opt/edg/include/edg/workload/common/utilities/Exceptions.h/opt/edg/include/edg/workload/common/utilities/Extractor.h/opt/edg/include/edg/workload/common/utilities/FLExtractor.h/opt/edg/include/edg/workload/common/utilities/FileList.h/opt/edg/include/edg/workload/common/utilities/FileListIterator.h/opt/edg/include/edg/workload/common/utilities/FileListLock.h/opt/edg/include/edg/workload/common/utilities/FileLocker.h/opt/edg/include/edg/workload/common/utilities/JDLAttributes.h/opt/edg/include/edg/workload/common/utilities/JobAdManipulation.h/opt/edg/include/edg/workload/common/utilities/LineParser.h/opt/edg/include/edg/workload/common/utilities/LineParserExceptions.h/opt/edg/include/edg/workload/common/utilities/boost_fs_add.h/opt/edg/include/edg/workload/common/utilities/classad_utils.h/opt/edg/include/edg/workload/common/utilities/edgstrstream.h/opt/edg/include/edg/workload/common/utilities/exception_codes.h/opt/edg/include/edg/workload/common/utilities/filecontainer.h/opt/edg/include/edg/workload/common/utilities/fstreamlock.h/opt/edg/include/edg/workload/common/utilities/globus_ftp_utils.h/opt/edg/include/edg/workload/common/utilities/ii_attr_utils.h/opt/edg/include/edg/workload/common/utilities/mixed.h/opt/edg/include/edg/workload/common/utilities/quota.h/opt/edg/include/edg/workload/common/utilities/result_codes.h/opt/edg/include/edg/workload/common/utilities/utils.h/opt/edg/include/auth.h/opt/edg/include/external.h/opt/edg/include/external_unix.h/opt/edg/include/grid_console.h/opt/edg/include/hashtable.h/opt/edg/include/int_sizes.h/opt/edg/include/layer.h/opt/edg/include/network.h/opt/edg/include/packet.h/opt/edg/include/pattern.h

IST-2000-25182 PUBLIC 92 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/include/private_malloc.h/opt/edg/include/edg-wl-dgas-jobAuthClient.h/opt/edg/include/edg/workload/logging/client/CountRef.h/opt/edg/include/edg/workload/logging/client/Event.h/opt/edg/include/edg/workload/logging/client/Job.h/opt/edg/include/edg/workload/logging/client/JobStatus.h/opt/edg/include/edg/workload/logging/client/LoggingExceptions.h/opt/edg/include/edg/workload/logging/client/ServerConnection.h

/opt/edg/lib/libedg_wl_LDIF2ClassAd.a/opt/edg/lib/libedg_wl_LDIF2ClassAd.la/opt/edg/lib/libedg_wl_LDIF2ClassAd.so/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0/opt/edg/lib/libedg_wl_LDIF2ClassAd.so.0.0.0/opt/edg/lib/libedg_wl_classad_plugin.a/opt/edg/lib/libedg_wl_classad_plugin.la/opt/edg/lib/libedg_wl_classad_plugin.so/opt/edg/lib/libedg_wl_classad_plugin.so.0/opt/edg/lib/libedg_wl_classad_plugin.so.0.0.0/opt/edg/lib/libedg_wl_common_requestad.a/opt/edg/lib/libedg_wl_common_requestad.la/opt/edg/lib/libedg_wl_common_requestad.so/opt/edg/lib/libedg_wl_common_requestad.so.0/opt/edg/lib/libedg_wl_common_requestad.so.0.0.0/opt/edg/lib/libedg_wl_conf.a/opt/edg/lib/libedg_wl_conf.la/opt/edg/lib/libedg_wl_conf.so/opt/edg/lib/libedg_wl_conf.so.0/opt/edg/lib/libedg_wl_conf.so.0.0.0/opt/edg/lib/libedg_wl_conf_wrapper.a/opt/edg/lib/libedg_wl_conf_wrapper.la/opt/edg/lib/libedg_wl_conf_wrapper.so/opt/edg/lib/libedg_wl_conf_wrapper.so.0/opt/edg/lib/libedg_wl_conf_wrapper.so.0.0.0/opt/edg/lib/libedg_wl_exceptions.a/opt/edg/lib/libedg_wl_exceptions.la/opt/edg/lib/libedg_wl_exceptions.so/opt/edg/lib/libedg_wl_exceptions.so.0

IST-2000-25182 PUBLIC 93 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_exceptions.so.0.0.0/opt/edg/lib/libedg_wl_globus_ftp_util.a/opt/edg/lib/libedg_wl_globus_ftp_util.la/opt/edg/lib/libedg_wl_globus_ftp_util.so/opt/edg/lib/libedg_wl_globus_ftp_util.so.0/opt/edg/lib/libedg_wl_globus_ftp_util.so.0.0.0/opt/edg/lib/libedg_wl_gsisocket_pp.a/opt/edg/lib/libedg_wl_gsisocket_pp.la/opt/edg/lib/libedg_wl_gsisocket_pp.so/opt/edg/lib/libedg_wl_gsisocket_pp.so.0/opt/edg/lib/libedg_wl_gsisocket_pp.so.0.0.0/opt/edg/lib/libedg_wl_iiattrutil.a/opt/edg/lib/libedg_wl_iiattrutil.la/opt/edg/lib/libedg_wl_iiattrutil.so/opt/edg/lib/libedg_wl_iiattrutil.so.0/opt/edg/lib/libedg_wl_iiattrutil.so.0.0.0/opt/edg/lib/libedg_wl_jobid.a/opt/edg/lib/libedg_wl_jobid.la/opt/edg/lib/libedg_wl_jobid.so/opt/edg/lib/libedg_wl_jobid.so.0/opt/edg/lib/libedg_wl_jobid.so.0.0.0/opt/edg/lib/libedg_wl_jutil.a/opt/edg/lib/libedg_wl_jutil.la/opt/edg/lib/libedg_wl_jutil.so/opt/edg/lib/libedg_wl_jutil.so.0/opt/edg/lib/libedg_wl_jutil.so.0.0.0/opt/edg/lib/libedg_wl_logger.a/opt/edg/lib/libedg_wl_logger.la/opt/edg/lib/libedg_wl_logger.so/opt/edg/lib/libedg_wl_logger.so.0/opt/edg/lib/libedg_wl_logger.so.0.0.0/opt/edg/lib/libedg_wl_process.a/opt/edg/lib/libedg_wl_process.la/opt/edg/lib/libedg_wl_process.so/opt/edg/lib/libedg_wl_process.so.0/opt/edg/lib/libedg_wl_process.so.0.0.0/opt/edg/lib/libedg_wl_socket_pp.a/opt/edg/lib/libedg_wl_socket_pp.la

IST-2000-25182 PUBLIC 94 / 185


Doc. Identifier:


Date: 29/05/2003

/opt/edg/lib/libedg_wl_socket_pp.so/opt/edg/lib/libedg_wl_socket_pp.so.0/opt/edg/lib/libedg_wl_socket_pp.so.0.0.0/opt/edg/lib/libedg_wl_util.a/opt/edg/lib/libedg_wl_util.la/opt/edg/lib/libedg_wl_util.so/opt/edg/lib/libedg_wl_util.so.0/opt/edg/lib/libedg_wl_util.so.0.0.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.a/opt/edg/lib/libedg-wl-dgas-jobAuthClient.la/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0/opt/edg/lib/libedg-wl-dgas-jobAuthClient.so.0.0.0/opt/edg/libexec/edg-wl-dgas-jobAuthClient/opt/edg/lib/libedg_wl_loggingpp.a/opt/edg/lib/libedg_wl_loggingpp.la/opt/edg/lib/libedg_wl_loggingpp.so/opt/edg/lib/libedg_wl_loggingpp.so.0/opt/edg/lib/libedg_wl_loggingpp.so.0.0.0

5.5.3. ConfigurationThe 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/<VO name>/

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-2.0.4-1_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

IST-2000-25182 PUBLIC 95 / 185


Doc. Identifier:


Date: 29/05/2003

$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 (<host fqdn>:<port>) 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 (<host fqdn>:<port>) 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 (<host fqdn>:<port>:<X509contact string>) of the HLR for the given VO. HLR is the service responsible for managing the economic transactions and the accounts of user and re-sources. 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 (<host fqdn>) 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 para-meter 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",

IST-2000-25182 PUBLIC 96 / 185


Doc. Identifier:


Date: 29/05/2003

"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";]

5.5.3.1. Python Command Line InterfaceConfiguration 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-2.0.4-1_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 RB will containrequirements = (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 ;

IST-2000-25182 PUBLIC 97 / 185

mailto:Guarise/Email%[email protected]


Doc. Identifier:


Date: 29/05/2003

rank this 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.

RetryCount this 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.

DefaultVO this 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 directly in the job description nor through the --vo option.

ErrorStorage this is a string representing the path of the directory where the UI creates log files. 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. 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 (<host>:[<port]) of the logging service (edg-wl-logd logging daemon ) to be targeted when logging events. The UI first check the environment for the EDG_WL_LOG_DESTINATION variable and only if this is not set, the value of the LoggingDestination parameter is taken into account.

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" ;

IST-2000-25182 PUBLIC 98 / 185


Doc. Identifier:


Date: 29/05/2003

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.confcontain respectively the error codes and error messages retyurned by the UI and the text describing the commands usage.

5.5.3.2. Java GUIThe 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-2.0.6-1.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

IST-2000-25182 PUBLIC 99 / 185


Doc. Identifier:


Date: 29/05/2003

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.

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 containrequirements = (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).

rank this 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).

RetryCount this 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. Default for this parameter is /tmp.

LoggingDestination this is a string defining the address (<host>:[<port]) of the logging service (edg-wl-logd logging daemon ) to be targeted when logging events. The UI first check the environment for the EDG_WL_LOG_DESTINATION variable and only if this is not set, the value of the LoggingDestination parameter is taken into account.

LoggingTimeout this is an integer representing the timeout in seconds for asynchronous logging function called by the UI when logging events to the LB.

IST-2000-25182 PUBLIC 100 / 185


Doc. Identifier:


Date: 29/05/2003

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 ; requirements = other.GlueCEStateStatus == "Production"; ] ; EDG = [ rank = - other.EstimatedTraversalTime ; 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_<IS_schema>.xml (Glue and EDG are supported)the condor dtd for parsing job description written in classad/xml format

condor.dtdand lastly the Log4j properties file

edg_wl_ui_gui_log4j.properties

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

IST-2000-25182 PUBLIC 101 / 185


Doc. Identifier:


Date: 29/05/2003

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_PROXY the user proxy certificate file path. Default value is /tmp/x509up_u<UID> 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_LOCATION The Globus rpms installation path. It defaults to /opt/globus

EDG_WL_LOCATION The User Interface installation path. It has to be set only if installation has been made in a non default location. It defaults to /opt/edg

EDG_WL_LOG_DESTINATION address (<host>:[<port]) of the logging service (edg-wl-logd logging daemon ) to be targeted when logging events. This variable takes precedence with respect to the value set into the UI configuration. It defaults to localhost:9002.

EDG_WL_LOG_TIMEOUT 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. 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.

5.5.4.1. Python Command Line Interface

EDG_WL_UI_CONFIG_VAR Non standard location of the command line interface configuration file edg_wl_ui_cmd_var.conf. This variable points to the file absolute path.

IST-2000-25182 PUBLIC 102 / 185


Doc. Identifier:


Date: 29/05/2003

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

5.5.4.2. Java GUI

EDG_WL_GUI_CONFIG_VAR Non 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_PATH the installation path of the Globus Java CoG Kit LOG4J_INSTALL_PATH the installation path the Log4J package CLASSADJ_INSTALL_PATH installation path of the the customised Condor

classads java library

IST-2000-25182 PUBLIC 103 / 185


Doc. Identifier:


Date: 29/05/2003

IST-2000-25182 PUBLIC 104 / 185


Doc. Identifier:


Date: 29/05/2003

6. OPERATING THE SYSTEMFor 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 order to provide the daemons with valid proxies for all their lifetime the administrators need to ensure regular generation of new proxies. This can be achieved adding the following lines to the machine /etc/crontab:

57 2,8,14,20 * * * root service locallogger proxy57 2,8,14,20 * * * root service lbserver proxy57 2,8,14,20 * * * root service broker proxy57 2,8,14,20 * * * root service jobsubmission proxy

This will make proxies be created by cron.

6.1. LB LOCAL-LOGGER

6.1.1. Starting and stopping daemonsTo run the LB local-logger services, it suffices to issue as root the following command:

/etc/rc.d/init.d/locallogger start

if the locallogger-profile rpm has been installed. Otherwise you can use

<install path>/sbin/locallogger start

This makes both the edg-wl-logd and the edg-wl-interlogd processes start. The same can be done issuing the following commands:

<install path>/sbin/edg-wl-logd <options><install path>/sbin/edg-wl-interlogd <options>

Both daemons recognize a common set of options:

--key=<proxyfile> despites the name, this should refer to the host proxy file (this option overrides value of the environment variable X509_USER_KEY). Here below an example of option usage:--key=/tmp/hostproxy.pem

IST-2000-25182 PUBLIC 105 / 185


Doc. Identifier:


Date: 29/05/2003

--cert=<certfile> despites the name, this should refer to the host proxy file (this option overrides value of the environment variable X509_USER_CERT). Here below an example of option usage:--cert=/tmp/hostproxy.pem

--CAdir=<certdir> trusted certificate and ca-signing-policy directory (this option overrides value of the environment variable X509_CERT_DIR). Here below an example of option usage:--CAdir=/etc/grid-security/certificates

--file-prefix=<file path> Absolute path of the file where are stored locally the logged events. The default value is /tmp/dglog, which can result in risk of data loss in case of reboot. Note that the same value must be specified for both daemons.

--socket=<local socket path> Unix socket used for direct communication between the daemons.

--debug make the process run in foreground and produce diagnostics

--verbose be more verbose (makes sense with --debug only)--help display usage message and exit

edg-wl-logd recognises the following specific option:

--port=<port number> listen on a non-default port

edg-wl-interlogd should be currently invoked with the --book option. It disables sending the events to persistent log storage, which is not yet supported.

Using the options explicitly is recommended rather than relying on the correspondent environment variables.Stop of the LB local-logger services can be performed using the locallogger script with the stop option.

6.1.2. TroubleshootingIf the LB local-logger services are started in debug mode (i.e. using the –-debug option), the daemons log fatal failures with syslog().

IST-2000-25182 PUBLIC 106 / 185


Doc. Identifier:


Date: 29/05/2003

6.2. LB SERVER

6.2.1. Starting and stopping daemonsTo run the LB server services, it suffices to issue as root the following command:

/etc/rc.d/init.d/lbserver start

if the lbserver-profile rpm has been installed. Otherwise you can use

<install path>/sbin/lbserver start

This makes the edg-wl-bkserverd processes start. The same can be done issuing the following commands:

<install path>/sbin/edg-wl-bkserverd <options>

The daemon recognizes this set of options:

--key=<keyfile> despites the name, this should refer to the host proxy file (this option overrides value of the environment variable X509_USER_KEY). Here below an example of option usage:--key=/tmp/hostproxy.pem

--cert=<certfile> despites the name, this should refer to the host proxy file (this option overrides value of the environment variable X509_USER_CERT). Here below an example of option usage:--cert=/tmp/hostproxy.pem

--CAdir=<certdir> trusted certificate and ca-signing-policy directory (this option overrides value of the environment variable X509_CERT_DIR). Here below an example of option usage:--CAdir=/etc/grid-security/certificates

--debug make the process run in foreground to produce diagnostics

--port=<port number> listen on a non-default port. Note that the release 2 server listens also on <port number> + 1 for incoming events.

IST-2000-25182 PUBLIC 107 / 185


Doc. Identifier:


Date: 29/05/2003

--mysql=<database> connect to a non-default MySQL database. The database string takes the form user/password@hostname:database.

--slaves=<number> spawn that many slaves, meaning that this number of client connections can be handled in parallel.

--semaphores=<number> use that many semaphores for internal job locking. Defaults to the number of slaves and should not be changed in normal operation.

--pidfile=<filename> use non-default PID & lock file.

Using the options explicitly is recommended rather than relying on the correspondent environment variables.Stop of the LB server services can be performed using the lbserver script with the stop option.

6.2.2. Creating custom indicesBy default the LB server indexes data according to JobId only. Because the querying capabilities of LB release 2 were considerably extended, the server refuses to process a query which would not utilize any index – we prevent overloading the underlying database engine in this way. Consequently, even a trivial query “give me all my jobs” results in an error in the default setup – under certain conditions processing such query may require handling gigabytes of data. The server administrator can create and modify the set of indices and control the set of supported queries in the following way, using the edg-wl-bkindex utility. It is invoked in the following way:

edg-wl-bkindex [options] [<index file>]

where the recognised options are:

--mysql=<database> non-default database to connect to, same as for edg-wl-bkserverd

--verbose be verbose--dump dump the current settings to stdout--really really perform reindexing. Without this option the required

actions are reported but not actually done.

IST-2000-25182 PUBLIC 108 / 185


Doc. Identifier:


Date: 29/05/2003

The index file follows this syntax (subset of ClassAd syntax):

index-file ::= [ JobIndices = { index-description * } ]index-description ::= column-description | list-of-columnslist-of-columns ::= { column-description + }column-description ::= [ column-type; column-name; prefix-len ? ]column-type ::= type = “user” | type = “system”column-name ::= name = “actual column name”prefix-len ::= prefixlen = integer

The only top-level attribute JobIndices is a list (possibly empty) of index descriptions. Each index description is either a single column or a list of columns (where the order is important). The column is described by mandatory attributes type and name, and an optional attribute prefixlen. Possible values of type are “system” for LB internal attributes and “user” for user tags – arbitrary name=value pairs assigned to a job by the user.Currently supported system column names are “owner”, “destination” and “location”.Names of user tags are arbitrary as long as their length is less than 60 characters and they contain only ASCII printable characters excluding backtick (`).The prefixlen value may be used to restrict indexing of columns, which may grow rather long, to a fixed size. This becomes necessary with compound indices as MySQL limits the total size of index to 250 bytes only.The following example index file contains two indices, the first one on a single system attribute -- job owner, the second one composed from system attribute job destination and user tag called “experiment number”:

[

JobIndices = {

[ type = "system"; name = "owner" ],

{

[ type = "system"; name = "destination";

prefixlen = 100 ],

[ type = "user"; name = "experiment number";

prefixlen = 100]

}

}

]

There is a sample configuration file, edg_wl_query_index.conf, containing definitions of indices on all the currently supported indexed system attributes, i.e. “owner”, “destination”, and “location”.

IST-2000-25182 PUBLIC 109 / 185


Doc. Identifier:


Date: 29/05/2003

The edg-wl-bkindex should be run with the --really option with the LB server shut down. Depending on actual size of the database the reindexing may take rather long time. LB server becomes aware of the new index setup automatically on its startup.

6.2.3. Purging the LB databaseThe edg-wl-bkpurge process, whose executable is installed in <install path>/sbin, is not a daemon but an utility which should be run periodically (e.g. using a cron job) in order to remove inactive jobs (i.e. those that have already entered the Cleared status since a certain amount of time) from the LB database. This utility recognizes the following set of options:

--log data being purged from database are dumped to the stdout

--outfile=<file> data being purged from database are dumped in the file named <file>

--mysql=<database> name of the database to be purged. It must be the same used by edg_wl_bkserverd (this option is not required in the standard set-up

--timeout=<timeout>[smhd] removes data for all jobs that entered the “Cleared” status since more than <timeout> [seconds/minutes/hours/days].

--debug print diagnostics on the stderr--nopurge dry run mode. It doesn't really purge (useful for

debugging purposes)--aborted, -a delete from the database data also for jobs that have

entered the “Aborted” statusIf --log is specified, the data in ULM format are dumped to stdout (or <file>). Normally information is appended to the file. The file is locked with flock (_LOCK_EX) to prevent race conditions, e.g. rotating logs.An example use of this utility is the following cron line to delete all data older than 14 days from the database:

edg-wl-bkpurge --log --outfile=/var/log/dglb-data.log --timeout=14d

In general, the edg-wl-bkpurge utility may generate rather high background load on the database engine. Therefore it should not be run too frequently (once a day is appropriate), and preferably at the time of low LB server activity.

6.2.4. Experimental R-GMA InterfaceThe LB server release 2 is capable of feeding the R-GMA infrastructure with notifications on job state changes. The functionality is enabled by starting edg-wl-bkserverd with the option –-rgmaexport. In addition, the environment variables EDG_WL_RGMA_FILE and EDG_WL_RGMA_SOCK has to be set to point to a file and local UNIX socket name used for

IST-2000-25182 PUBLIC 110 / 185


Doc. Identifier:


Date: 29/05/2003

communication with the R-GMA producer. The producer itself is the Java program LBProducer. It has to be invoked with the two environment variables set to the same values. It takes no further arguments.

6.2.5. TroubleshootingIf the LB server services are started in debug mode (that is using the –-debug option) the daemons log fatal failures with syslog().

6.3. SERVICES RUNNING IN THE “RB NODE”: NS, WM, JC, LM

6.3.1. Starting and stopping NS, WM, JC and LM daemonsStartup of NS, WM, JC and LM can be achieved issuing:

/etc/rc.d/init.d/edg-wl-ns start/etc/rc.d/init.d/edg-wl-wm start/etc/rc.d/init.d/edg-wl-jc start/etc/rc.d/init.d/edg-wl-lm start

or, indirectly, using RedHat dedicated commands:

service broker startservice jobsubmission start

In the same way stopping is achieved by:

/etc/rc.d/init.d/edg-wl-ns stop/etc/rc.d/init.d/edg-wl-wm stop/etc/rc.d/init.d/edg-wl-jc stop/etc/rc.d/init.d/edg-wl-lm stop

or

service broker stopservice jobsubmission stop

The startup script for JC also starts and stops the underlying CondorG service. These scripts will start the daemons with the correct selected users (see also Error: Reference source notfound in section Error: Reference source not found). Startup scripts can also be used to

IST-2000-25182 PUBLIC 111 / 185


Doc. Identifier:


Date: 29/05/2003

know the current status of the daemons using the status option.

Moreover it is strongly recommended to set the configuration of the machine in such a way that all these services will be started at the startup of the system.

6.3.2. NS, WM, JC, LM troubleshootingThe NS, WM, LC and LM services supply with log files recording their various events. These files can be used to debug abnormal behaviors of these services. The log-file names and the level of debugging (i.e. the level of “detail”) can be changed by directly modifying the configuration file.

6.4. PROXY RENEWAL

6.4.1. Starting and stopping daemonTo run the PR daemon, it suffices to issue as root the following command:

/etc/rc.d/init.d/ edg-wl-proxyrenewal start

This makes the edg-wl-renewald process start. The same can be done issuing the following command:

The daemon recognizes the following set of options:

--debug make the process run in foreground and produce diagnostics --repository=<dir> directory where registered proxies will be stored

(/var/spool/edg-wl-renewd by default)

6.4.2. TroubleshootingIf the PR service is started in debug mode (i.e. using the --debug option), the daemon prints out fatal failures to stdout.

6.5. PURGERThe input/output sandbox directory for a given job are cleared in the “RB node” when the job retrieves the output sandbox files (with the command edg-job-get-output command), or when the job is declared as aborted.

IST-2000-25182 PUBLIC 112 / 185


Doc. Identifier:


Date: 29/05/2003

To avoid that the file system of the “RB node” get fully used, the system administrator can run the Storage Purger daemon, which is in charge to clean old input-output sandboxes, according to a policy that has to be specified The edg-wl-purgeStorage executable (the storage purger) accepts the following options:

-a=<argument> --allocated-limit=<argument>

Defines a percentage of used space in the input/output sandbox disk, if the used space is more than the specified argument, then the purging is triggered.

-b --brute-rm

If enabled, ALL the input-output sandboxes directories are removed (use this option with care).

-e --enable-progress

Enables the progress indicator bar. -f --fake-rm Does not perform any directory removal.

-l=<argument> --log-file=<argument>

Logs the purge information into the specified file. If not specified, the default file is $EDG_WL_TMP/edg-wl-purgeStorage-<date>- <time>.log

-p=<argument> --staging-path=<argument>

Defines the sandbox staging path (should be the same value specified as SandboxStagingPath in the NS configuration section (see section 5.2.4.2).If not specified the directory referenced by the $EDG_WL_TMP environment variable is considered.

-q --quiet

Does not create any log file (any settings specified with the option -l will be ignored).

IST-2000-25182 PUBLIC 113 / 185


Doc. Identifier:


Date: 29/05/2003

-t=<argument> --threshold=<argument>

The purge storage deletes the sandboxes directories for jobs which have been in DONE status or ABORTED status for at least <argument> seconds (while the sandboxes directories will be cleared for all jobs in CLEARED status). If not specified the default value is 604800 (one week)

The storage purger should be regularly invoked, for example via a cron job.These are two examples of cron rules:

edg-wl-purgeStorage-weekly.cron # Execute the "purger" command at 4:00 AM, 8:00 AM, 12:00 noon, # 4:00 PM, and 8:00 PM (0 */4) on each Sunday (sun).0 */4 * * sun $EDG_WL_LOCATION/sbin/edg-wl-purgeStorage -l$EDG_WL_LOCATION_VAR/log/edg-wl-purgeStorage.log -t 604800

edg-wl-purgeStorage-hourly.cron # Execute the "purger" command at every day except on Sunday # with a frequency of one hour if and only if the percentage of # used space is greater than 40%0 */1 * * mon-sat $EDG_WL_LOCATION/sbin/edg-wl-purgeStorage -l$EDG_WL_LOCATION_VAR/log/edg-wl-purgeStorage.log -t 604800 -a 40

6.6. GRID ACCOUNTING

6.6.1. Starting and stopping daemon

6.6.1.1. HLR serverTo run the HLR server daemon, it suffices to issue as root the following command:

/etc/rc.d/init.d/hlrd start

This makes the edg-wl-dgas-hlrd process start.


IST-2000-25182 PUBLIC 114 / 185


Doc. Identifier:


Date: 29/05/2003

--help -h Print an informative help message describing the options and then exit.

--conf -c Specifies the full path to the configuration file to be used (see section 5.4.4.1).

--port -p Specifies listening port number

--log -l

Specifies the full path for the log file

6.6.1.2. PA ServerTo run the PA server daemon, it suffices to issue as root the following command:

/etc/rc.d/init.d/pad start

This makes the edg-wl-dgas-pad process start.


--help -h Print an informative help message describing the options and then exit.

--conf -c Specifies the full path to the configuration file to be used (see section 5.4.4.2).

--port -p

Specifies listening port number

--log

IST-2000-25182 PUBLIC 115 / 185


Doc. Identifier:


Date: 29/05/2003

-l Specifies the full path for the log file

6.6.2. HLR server administrationTo use the DGAS software, it is necessary first of all to create the accounts for users and resources.

Users and resources are divided into groups. These groups can be used to collect statistics about the expenses/earnings of a given subset of the users/resources of the HLR. As example, let’s suppose that users Ua, Ub, Uc, Ud and the resources Ra, Rb belong to the group Ga. When a user (e.g. Ub) spends some credits, his group is debited of the same amount. When a resource (e.g. Ra) earns some credits, the corresponding group is credited of the same amount.

Funds are containers of groups. They can be used for example to divide users or resources belonging to different VOs on HLRs used to manage multiple VOs, or to achieve a better granularity on large HLRs.

Actually up to now this division into groups and funds has limited advantages, since it only affects the way earnings/expenses are computed, but in future releases of the software it will allow setting different priorities to the users.

The steps needed to create the accounts are:

Creating the fund accounts Creating the group accounts Creating the user/resource accounts

6.6.2.1. Creating a Fund account

The command to use is:

edg-wl-dgas-hlr-addFund [OPTIONS] -i --interactive -C --Conf <Configuration file name> -f --fid "fid" -F --Force "Force the record insertion" -d --descr "description"

IST-2000-25182 PUBLIC 116 / 185


Doc. Identifier:


Date: 29/05/2003

-t --total "total funds"

where:

-C is used to specify the conf file needed by the command to point to the HLR database-f is used to specify a fund identifier (fid) that will be used to address the fund-d is used to specify a human readable reminder of what this fund is-t is used to assign credits to the fund. You can use 0 as a default value

For example, in order to create the fund VO_2, a command such as:

edg-wl-dgas-hlr-addFund -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" \-f VO_2 -d "Virtual Organization 2 account" -t 0

should be issued.

To check if a fund has been correctly inserted, the following command can be used:

edg-wl-dgas-hlr-queryFund -C ../etc/edg-wl-dgas-hlr.conf

which should get an output like:

|VO_2|Virtual Organization 2 account|0|0|

6.6.2.2. Creating a Group account

The command to be used is:

edg-wl-dgas-hlr-addGroup [OPTIONS] -i --interactive -F --Force -C --Conf Configuration file name -g --gid "gid" -d --descr "description" -f --fid "fid" -t --total "total funds" -b --booked "booked funds" shouldn't be specified manually

IST-2000-25182 PUBLIC 117 / 185


Doc. Identifier:


Date: 29/05/2003

-s --spent "spent funds" shouldn't be specified manually

where:

-C specifies the configuration file. -g specifies a group identifier (gid) used to address this group -d is a reminder of what the group is -f is used to specify the fid of the fund to link this group with -t is the amount of credits assigned to the group, you can use 0

For example, in order to create the group Group3, it is necessary to issue a command like:

edg-wl-dgas-hlr-addGroup -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" \ -g Group3 -d "Users and resources of VO_2" -f VO_2 -t 0

To check if a Group has been correctly inserted, the following command can be used:

./edg-wl-dgas-hlr-queryGroup -C ../etc/edg-wl-dgas-hlr.conf

which should return an output like:

|Group3|Users and resources of VO_2|VO_2|0|0|0|

6.6.2.3. Creating a User account

The command to be used to create a user account is:

edg-wl-dgas-hlr-addUser [OPTIONS] -i --interactive -C --Conf Configuration file name -F --Force Force record insertion -u --uid "uid" -e --email "email" -d --descr "description" -c --cert "cert subject" -g --gid "gid" -f --fid "fid"

IST-2000-25182 PUBLIC 118 / 185


Doc. Identifier:


Date: 29/05/2003

-a --assigned "assigned funds" -b --booked "booked funds" shouldn't be specified manually -s --spent "spent funds" shouldn't be specified manually

where:

-C specifies the configuration file. -u specifies an identifier for the user (uid) (nothing to do with the Unix uid !) -d A reminder of who the user is e.g. his real name -c The User X509 cert subject -g gid of the user Group. -f fid of the user fund. -a amount of credits assigned to the user. Use 0.

For example, to create the user Ua, it is necessary to issue a command like:

edg-wl-dgas-hlr-addUser -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" \ -u Ua -e user.a@userdomain -d "UserA desc" \ -c "UserCertSubject" -g Group3 -f VO_2 -a 0

To check if a User has been correctly inserted, the command:

edg-wl-dgas-hlr-queryUser -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" -U

can be used.If everything is fine, the output should look like:

|Ua|user.a@userdomain|UserA desc|UserCertSubject|Group3|VO_2|0|0|0|

6.6.2.4. Creating a Resource account

The command used to create a resource account is:

edg-wl-dgas-hlr-addResource [OPTIONS] -i --interactive -F --Force -C --Conf Configuration file name

IST-2000-25182 PUBLIC 119 / 185


Doc. Identifier:


Date: 29/05/2003

-r --rid "rid" -e --email "email for contact person" -d --descr "description" -c --cert "cert subject" -g --gid "gid" -f --fid "fid"

where:

-C specifies the configuration file. -r specifies an identifier for the user (rid) used to address the resource -e specifies an email address of a contact person for that resource -d specifies a description of the resource -c the CeID of the assigned to this account -g the gid of the resource group -f the fid of the resource fund

For example to create the resource Ra, it is necessary to issue a command like:

edg-wl-dgas-hlr-addResource -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" \ -r Ra -e resource.administrator@domain -d "Res desc" \ -c "CeID" -g Group3 -f VO_2

To check if a Resource has been correctly inserted, the following command can be used:

edg-wl-dgas-hlr-queryResource -C "/opt/edg/etc/edg-wl-dgas-hlr.conf" -R

The output should be something like:

|Ra|resource.administrator@domain|Res desc|CeID|Group3|VO_2|0|

6.6.2.5. Deleting accounts

The commands:

edg-wl-dgas-hlr-delFund

IST-2000-25182 PUBLIC 120 / 185


Doc. Identifier:


Date: 29/05/2003

edg-wl-dgas-hlr-delGroupedg-wl-dgas-hlr-delResourceedg-wl-dgas-hlr-delUser

can be used to delete respectively fund, group, resource, user accounts.

6.6.3. TroubleshootingBoth the HLR and the PA server supply with log files, ad described in the previous sections. These files can be used to debug abnormal behaviors of the services.

6.7. USER INTERFACE (JAVA GUI)As already mentioned in section 5.5.3.2 the Java GUI encompasses three components that are:

JobSubmitter JobMonitor JDLEditor

To start the these components, it suffices to issue respectively the following commands:

$EDG_WL_LOCATION/sbin/edg-wl-ui-jobsubmitter.{sh,csh} $EDG_WL_LOCATION/sbin/edg-wl-ui-jobmonitor.{sh,csh}$EDG_WL_LOCATION/sbin/edg-wl-ui-jdleditor.{sh,csh}

where the scripts listed above are installed by the edg-wl-ui-gui-2.0.6-1.i486.rpm rpm. It is important to note that from the JobSubmitter it is possible to start the other GUI components.With the exception of the JDLEditor that does not interact with any external WMS module, before starting the GUI components, the X509_USER_KEY, X509_USER_CERT , X509_USER_PROXY environment variables have to be set if user credentials are not stored in the default locations. It is worth recalling that the GUI only needs a valid proxy certificate for working correctly.Lastly the environment variables JAVA_INSTALL_PATH, COG_INSTALL_PATH, LOG4J_INSTALL_PATH and CLASSADJ_INSTALL_PATH that are used by the scripts to set the java CLASSPATH need to be set if the corresponding packages are not installed in the standard location (/usr/share/java).

IST-2000-25182 PUBLIC 121 / 185


Doc. Identifier:


Date: 29/05/2003

7. USER GUIDEThe software module of the WMS allowing the user to access main services made available by the components of the scheduling sub-layer is the User Interface that hence represents the entry-point to the whole system. Sections 7.1.1 and 7.1.2 provide a general description of the UI, dealing with the security management, common behaviours, environment variables to be set etc. Section 7.1.3 describes the Job Submission User Interface commands in a Unix man-page style.

7.1. USER INTERFACE The Job Submission UI is the module of the WMS allowing the user to access main services made available by the components of the scheduling sub-layer. The user interaction with the system is assured by means of a JDL and a command-driven user interface providing com-mands to perform a certain set of basic operations. Main operations made possible by the UI are:

- Submit a job for execution on a remote Computing Element, also encompassing: automatic resource discovery and selection staging of the application sandbox (input sandbox)

- Find the list of resources suitable to run a specific job- Cancel one or more submitted jobs- Retrieve the output files of a completed job (output sandbox)- Retrieve and display bookkeeping information about submitted jobs- Retrieve and display logging information about submitted jobs.- Retrieve checkpoint states of a submitted checkpointable job.- Start a local listener for an interactive job.

The User Interface depends on two other Workload Management System components:- the Network Server that provides support for the job control functionality- the Logging and Bookkeeping Service that provides support for the job monitoring

functionality.

7.1.1. Security For the DataGrid to be an effective framework for largely distributed computation, users, user processes and grid services must work in a secure environment.Due to this, all interactions between WMS components, especially those that are network-separated, will be mutually authenticated: depending on the specific interaction, an entity au-thenticates itself to the other peer using either its own credential or a delegated user creden-tial or both. For example when the User Interface passes a job to the Network Server, the UI authenticates using a delegated user credential (a proxy certificate) whereas the NS uses its own service credential. The same happens when the UI interacts with the Logging and Book-keeping service. The UI uses a delegated user credential to limit the risk of compromising the original credential in the hands of the user.The user or service identity and their public key are included in a X.509 certificate signed by a EDG trusted Certification Authority (CA), whose purpose is to guarantee the association between that public key and its owner.

IST-2000-25182 PUBLIC 122 / 185


Doc. Identifier:


Date: 29/05/2003

According to what just premised, to take advantage of UI commands the user has to possess a valid X.509 certificate on the submitting machine, consisting of two files: the certificate file and the private key file. The location of the two mentioned files is assumed to be either pointed to respectively by “$X509_USER_CERT” and “$X509_USER_KEY” or by “$HOME/.globus/usercert.pem” and “$HOME/.globus/userkey.pem” if the X509 environment variables are not set. The user certificate and private key files are needed for the creation of the delegated user credentials. Indeed, as it is explained hereafter what is really needed is the user proxy certificate.All UI commands, when started, check for the existence and expiration date of a user proxy certificate in the location pointed to by “$X509_USER_PROXY” or in “/tmp/x509up_u<UID>” (<UID> is the user identifier in the submitting machine OS) if the X509 environment variable is not set. If the proxy certificate does not exist or has expired a new one with default duration of 24 hours is automatically created by the UI using the GSI services (grid-proxy-init and grid-proxy-info). The user proxy certificate is created either as “$X509_USER_PROXY” or as “/tmp/x509up_u<UID>”. Once a job has been submitted by the UI, it passes through several components of the WMS (e.g. the NS, the WM, the JC, CondorG etc.) before it completes its execution. At each step operations that are related with the job could require authentication by a certificate. For ex-ample during the scheduling phase, the RB needs to get some information about the user who wants to schedule a job and the certificate of the user could be needed to access this in-formation. Similarly, a valid user’s certificate is needed by JC/CondorG to submit a job to the CE. Moreover JC has to be able to repeat this process e.g. in case of crashing of the CE which the job is running on, therefore, a valid user’s certificate is needed for all the job life -time.A job gets a valid proxy certificate when it is submitted by the UI to NS. Validity of such a cer-tificate is usually set to 12 hours, hence problems could occur if the job spends on CE (in a queue or running) more time than lifetime of its proxy certificate.The UI edg-job-submit command (see description later in this document) supplies an option (--hours H) allowing the specification of the duration in hours of the proxy certificate that is created on behalf of the user. Due to this, it being understood that the certificates files search paths remains as before, the proxy checking mechanism for this command slightly differs from that of the other commands, i.e.: If the “--hours H” option has not been specified, the proxy certificate check is done as ex-

plained before If the “--hours H” option has been specified, then a new proxy certificate having a dura-

tion of H hours is created both when no existing proxy is found and when the existing proxy lifetime is less than H. In the latter case the existing proxy certificate is destroyed before creating the new one.

This allows the user to submit jobs running longer then the default proxy duration (12 hours).Another way for achieving this in a more secure way is to rely on the features of the MyProxy package, as introduced in section 5.3. 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. A more detailed description of this mechanism is provided in the following paragraph.

IST-2000-25182 PUBLIC 123 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.1.1. MyProxyThe 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.

7.1.1.1.1. MyProxyClientThe set of binaries provided for the client is made of the following files:

myproxy-initmyproxy-infomyproxy-destroymyproxy-get-delegation

myproxy-init command allows you to create and send a delegated proxy to a myproxy server for later retrieval; in order to launch it you have to assure you're able to execute the grid-proxy-init GLOBUS command (i.e.t he binary is visible from your $PATH environment and the required cert files are either stored in the common path or specified with the X509 variables). You can use the command as follows (you will be asked for your PEM passhprase):

myproxy-init -s <host name> -t <hours> -d –n

The myproxy-init command stores a user proxy in the repository specified by <host name> (the –s option). Default lifetime of proxies retrieved from the repository will be set to <hours> (see -t) and no password authorization is permitted when fetching the proxy from the repository (the -n option). The proxy is stored under the same username as is your subject in your certificate (-d).The myproxy-info command returns the remaining lifetime of the proxy in the repository along with subject name of the proxy owner (in our case it will be the same as in your proxy certificate). So if you want to get information about the stored proxies you can issue:

myproxy-info -s <host name> -d

where -s and -d options have already been explained in the myproy-init commandThe myproxy-destroy command simply destroys any existing proxy stored in the myproxy server. You can use it as follows:

myproxy-destroy -s <host name> -d

IST-2000-25182 PUBLIC 124 / 185


Doc. Identifier:


Date: 29/05/2003

where -s and -d options have already been explained in the myproy-init commandThe myproxy-get-delegation command is indeed used to retrieve information about the proxies stored in the myproxy server. You can use it as follows:

myproxy-get-delegation -s <host name> -d -t <hours> \-o <output file> -a <user proxy>

You should end up with a retrieved proxy in <output file>, which is valid for<hours> hours.It is worth noting that the environment variable MYPROXY_SERVER can be set to tell to all these programs the hostname where the myproxy server is running.

7.1.2. Common behavioursA User Interface installation mainly consists of four directories bin, lib, etc and share that are created under the UI installation path that is usually pointed by the EDG_WL_LOCATION environment variable. If this variable is not set or its value is not correct, default value is assumed to be “/opt/edg”.bin contains the commands executables and hence it is recommended to add it to the user PATH environment variable to allow her/him to use UI commands from whatever location. lib contains the shared libraries (wrappers of the NS/LB APIs) implementing functionalities for accessing the NS and LB services. Moreover lib contains a subdirectory named python containing some python modules also needed for accessing the underlying services. ,etc is the UI configuration area: it contains the file containing the mapping between error codes and error messages (edg_wl_ui_cmd_err.conf), the file containing the detailed description of each command (edg_wl_ui_cmd_help.conf) and the actual configuration file (edg_wl_ui_cmd_var.conf). The latter file is the only one that could need to be edited and tailored according to the user/platform characteristics and needs. It contains the following information that are read by and have influence on commands behaviour (see section 5.5.3 for details):

- default location of the local storage areas for the Output sandbox files,- default location for the UI log files,- default values for the JDL mandatory attributes,- default values for timeouts when logging events to the LB,- default logging destination,- user’s default VO,- default level of information displayed by the monitoring commands

Inside etc there is a directory for each supported EDG Virtual Organisation and named as the VO (e.g. for ATLAS we will have etc/ATLAS/) that contains a vo-specific configuration file edg_wl_ui.conf specifying the list of Network Servers and LBs accessible for the given VO.

IST-2000-25182 PUBLIC 125 / 185


Doc. Identifier:


Date: 29/05/2003

When started, UI commands first check if the EDG_WL_LOCATION is set and then search for the etc directory containing its configuration files in the following locations, in order of precedence: “$EDG_WL_LOCATION”, “/opt/edg“, “/“, “/usr/local“. If none of the locations contains needed files an error is returned to the user.Since several users on the same machine can use a single installation of the UI, people concurrently issuing UI commands share the same configuration files. Anyway for users (or groups of users) having particular needs it is possible to “customise” the UI configuration through the --config and –config-vo options supported by each UI command.Indeed every command launched specifying “--config file_path” reads its configuration settings in the file pointed by “file_path” instead of the default configuration file. The same happens for the vo-specific configuration file if the command is started using specifying “–config-vo vo_file_path”. Hence the user only needs to create such file according to her/his needs and to use the appropriate options to work under “private” settings.Moreover if the user wants to make this change in some way permanent avoiding the use for each issued command of the --config option, she/he can set the environment variable EDG_WL_UI_CONFIG_VAR to point to the non-standard path of the configuration file. Indeed if that variable is set commands will read settings from file “$EDG_WL_UI_CONFIG_VAR”. Anyway the --config option takes precedence on all other settings.Exactly the same applies to the EDG_WL_UI_CONFIG_VO environment variable and the --config-vo option.It is important to note that since the job identifiers edg_jobId (see section 7.1.3 – edg-job-submit) implicitly holds the information about the LB that is managing the corresponding job, all the commands taking the edg_jobId as input parameter do not take into account the LB addresses listed in the configuration file to perform the requested operation also if the –config-vo option has been specified.Hereafter are listed the options that are common to all UI commands:

--config file_path--noint--debug--logfile file_path--version--help

The --noint option skips all interactive questions to the user and goes ahead in the command execution. All warning messages and errors (if any) are written to the file <command_name>_<UID>_<PID>_<date_time>.log in the location specified in the configuration file instead of the standard output. It is important to note that when --noint is specified some checks on “dangerous actions” are skipped. For example if jobs cancellation is requested with this option, this action will be performed without requiring any confirmation to the user. The same applies if the command output will overwrite an existing file, so it is recommended to use the --noint option in a safe context.The --debug option is mainly thought for testing and debugging purposes; indeed it makes the commands print additional information while running. Every time an external API function

IST-2000-25182 PUBLIC 126 / 185


Doc. Identifier:


Date: 29/05/2003

call is encountered during the command execution, values of parameters passed to the API are printed to the user. The info messages are displayed on the standard output and are also written together with possible errors and warnings, to <command_name>_<UID>_<PID>_<date_time>.log. If --noint option is specified together with --debug option the debug message will not be printed on standard output.The –logfile <file_path> option allows re-location of the commands log files in the location pointed by file_path.The --version and --help options respectively make the commands display the UI current version and the command usage.Two further options that are common to almost all commands are --input and --output. The latter one makes the commands redirect the outcome to the file specified as option argument whilst the former reads a list of input items from the file given as option argument. The only exception is the edg-job-list-match command that does not have the --input option.For all commands, the file given as argument to the --input option shall contain a list of job identifiers in the following format: one edg_jobId for each line, comments beginning with a “#” or a “*” character. If the input file contains only one edg_jobId (see the description of dg-job-submit command later in this document for details about edg_jobId format), then the request is directly submitted taking the edg_jobId as input, otherwise a menu is displayed to the user listing all the contained items, i.e. something like:------------------------------------------------------------------------------------------------------------------------------------------1 : https://ibm139.cnaf.infn.it:9000/ZU9yOC7AP7AOEhMAHirG3w2 : https://ibm139.cnaf.infn.it:9000/ZU9yOC767gJOEhMAHirG3w3 : https://ibm135.cnaf.infn.it:9000/ZU9yOC7AP7A55TREAHirG3w4 : https://grid012f.cnaf.infn.it:7846/ZUHY6707AP7AOEhMAHirG3w5 : https:// grid012f.cnaf.infn.it:9000/Cde341P7AOEhMAHirG3wa : allq : quit-------------------------------------------------------------------------------------------------------------------------------------------Choose one or more edg_jobId(s) in the list - [1-10]all:

The user can choose one or more jobs from the list entering the corresponding numbers. E.g.:

2 makes the command take the second listed edg_jobId as input 1,4 makes the command take the first and the fourth listed edg_jobIds as input 2-5 makes the command take listed edg_jobIds from 2 to 5 (ends included) as

input all makes the command take all listed edg_jobIds as input q makes the command quit

Default value for the choice is all. If the –input option is used together with the --noint then all edg_jobIds contained in the input file are taken into account by the command.The only command whose --input behaviour differs from the one just described is edg-job-submit. First of all the input file contains in this case CEIds instead of edg_jobIds, moreover only one CE at a time can be the target of a submission hence the user is allowed to choose

IST-2000-25182 PUBLIC 127 / 185


Doc. Identifier:


Date: 29/05/2003

one and only one CEId. Default value for the choice is “1”, i.e. the first CEId in the list. This also the choice automatically made by the command when the --input option is used together with the --noint one.

IST-2000-25182 PUBLIC 128 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3. Commands descriptionIn this section we describe syntax and behavior of the commands made available by the UI to allow job submission, monitoring and control.In the commands synopsis the mandatory arguments are showed between angle brackets (<arg>) whilst the optional ones between square brackets ([arg]).

7.1.3.1. edg-job-submitAllows the user to submit a job for execution on remote resources in a grid.

SYNOPSISedg-job-submit [options] <jdl_file>Options: --help --version --vo <vo_name> --input, -i <file_path> --resource, -r <ce_id> --hours, -h <hours_number> --nomsg --config, -c <file_path> --config-vo <file_path> --output, -o <file_path> --chkpt <file_path> --noint --debug --logfile <file_path>

DESCRIPTIONedg-job-submit is the command for submitting jobs to the DataGrid and hence allows the user to run a job at one or several remote resources. edg-job-submit requires as input a job description file in which job characteristics and requirements are expressed by means of Condor class-ad-like expressions. While it does not matter the order of the other arguments, the job description file has to be the last argument of this command.The job description file given in input to this command is syntactically checked and default values are assigned to some of the not provided mandatory attributes in order to create a meaningful class-ad. The resulting job-ad is sent to the NS, which then forwards it to the

IST-2000-25182 PUBLIC 129 / 185


Doc. Identifier:


Date: 29/05/2003

WM, which via the RB/Matchmaker finds the job best matching resource (match-making) and then the JC submits the job to it. The match-making algorithm is described in details in Annex 8.6.Upon successful completion this command returns to the user the submitted job identifier edg_jobId (a string that identifies unambiguously the job in the whole EDG), generated by the User Interface, that can be later used as a handle to perform monitor and control operations on the job (e.g. see edg-job-status described later in this document). The format of the edg_jobId is as follows:

https://Lbserver_address[:port]/unique_string

The unique_string is a md5 string computed taking into account the following information:- IP of the User Interface machine,- timestamp,- process ID (more UI instances may occur on the same machine),- sequence or just random number (if the User Interface submits jobs in batches and

more than one per second can be submitted),The final md5 sum is encoded using modified Base64 encoding (“:” is used instead of “/”) en-suring reasonable uniqueness and compactness of job IDs.

The structure of the edg_jobId that could appear in some way complex and not easily readable, has been conceived in order to ensure uniqueness and at the same time contain information that are needed by the components of the WMS to fulfil user requests. The --vo option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this attribute has not been specified in the JDL, then the default VO specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user. With the deployment of VOMS, the VO information will be encoded in the user’s proxy certificate and this will make the described behaviour change.The --resource option can be used to target the job submission to a specific known resource identified by the provided Computing Element identifier ce_id (returned by edg-job-list-match described later in this document). The CE identifier is a string published in the IS (the GlueCEUniqueID field in the Glue schema) that univocally identifies a resource belonging to the Grid. The admitted format for CEId is:

<full-hostname>:<port-number>/jobmanager-<service>-<queue-name>

where <service> can be lsf, pbs,bqs and condor.When the --resource option is specified, the WMS skips completely the match making process and directly submits the job to the requested CE. It is important to note that in this case the “.BrokerInfo” file is not generated even if data requirements have been specified in the JDL, so jobs submitted using this option should not rely on the .BrokerInfo file information when running on the CE. The “.BrokerInfo” file is a file generated by the RB/Matchmaker during matchmaking and contains information about the location where input data specified

IST-2000-25182 PUBLIC 130 / 185


Doc. Identifier:


Date: 29/05/2003

in the JDL are physically stored, the SEs that are “close” to the CE chosen for submitting the job etc. It is shipped within the InputSandbox to the CE where the job is going to run so that it can be used at run-time to get information (through the appropriate API) for accessing data. Details about the “.BrokerInfo” file and the BrokerInfo API can be found in [R1].A way for performing direct submission to a given CE and at the same time having the “.BrokerInfo” file generated by RB and shipped to the CE is to not use the --resource option and specify the following requirements in the JDL:Requirements = other.GlueCEUniqueID == <Ce_identifier>;

(e.g. Requirements = other.GlueCEUniqueID == “lxde01.pd.infn.it:2119/jobmanager-lsf-grid01”;)It is also possible to specify the target CE to which submit the job using the --input option. With the --input option an input_file must be supplied containing a list of target CE ids. In this case the edg-job-submit command parses the input_file and displays on the standard output the list of CE Ids written in the input_file. The user is then asked to choose one CEId between the listed ones. The command will then behave exactly like already explained for the --resource option. The basic idea of this command is to use as input_file the output file generated by the edg-job-list-match command when used with the --output option (see edg-job-list-match) that contains the list of CE Ids (if any) matching the requirements specified in the jobad.jdl file. An example of a possible sequence of commands is:

>$ edg-job-list-match --output CEList.out jobad.jdl>$ edg-job-submit --input CEList.out jobad.jdl

If CEList.out contains more than one CEId then the user is prompted for choosing one Id from the list.It is possible to redirect the returned edg_jobId to an output file using the --output option. If the file already exists, a check is performed: if the file was previously created by the command edg-job-submit (i.e. it contains a well defined header), the returned edg_jobId is appended to the existing file every time the command is launched. If the file wasn’t created by the command edg-job-submit the user will be prompted to choose if overwrite the file or not. If the answer is no the command will abort.The edg-job-submit command has a particular behaviour when the job description file contains the InputSandbox attribute whose value is a list of file paths on the UI machine local disk. The purpose of the introduction of the InputSandbox attribute is to stage, from the UI to the CE, files that are needed for the execution.To better understand, let’s suppose to have a job that needs for the execution a certain set of files having a small size and available on the submitting machine. Let’s also suppose that for performance reasons it is preferable not going through the WP2 data transfer services for the staging of these files on the executing node. Then the user can use the InputSandbox attribute to specify the files that have to be staged from the submitting machine to the executing CE. All of them are indeed transferred at job submission time together with the job class-ad to the NS that will store them temporarily on its local disk. The JobWrapper will then perform the staging of these files on the executing node. The size of files to be transferred to the “RB node” should be small since overfull of RB node local storage means that no more job of this type can be submitted (see section 5.2.6.3).

IST-2000-25182 PUBLIC 131 / 185


Doc. Identifier:


Date: 29/05/2003

This mechanism can also be used to stage a job executable available locally on the UI machine to the executing CE. Indeed in this case the user has to include this file in the InputSandbox list (specifying its absolute path in the file system of the UI machine) and as Executable attribute value has only to specify the file name. On the contrary, if the executable is already available in the file system of the executing machine, the user has to specify as Executable an absolute path name for this file (if necessary using environment variables). The same argument can be applied to the standard input file that is specified through the StdInput JDL attribute.Since the InputSandbox expression can consist of a great number of file names, it is admitted the use of wildcards and environment variables to specify the value of this attribute. Syntax and allowed wildcards are described in Annex 8.5.It is important to note that since the gridftp protocol (the protocol used for the InputSanbox files staging) in general doesn't preserve the x flag, the script specified as Executable in the JDL (on which chmod +x is done automatically by the WP1 JobWrapper), should perform a chmod +x for all the files needing execution permission, that are transferred within the InputSandbox of the job.For the standard output and error of the job the user shall instead always specify just file names (without any directory path) through the StdOutput and StdError JDL attributes. To have them staged back on the UI machine it suffices to list them in the OutputSandbox and use after job completion the edg-job-get-output command described later in this document.The list of data specification JDL attributes is completed by the InputData and OutputData attributes.InputData refers to data used as input by the job that are not subjected to staging and are stored in one or more storage elements and published in replica catalogues. When the user specifies the InputData attribute then he/she also has to provide the protocol her/his application is able to “speak” for accessing data (DataAccessProtocol attribute). The InputData attribute should contain a list of Logical File Names (LFN) and/or Grid Unique Identifilers (GUID). There is no need to specify the Replica Location Service to be contacted for resolving the logical files names and GUIDs to storage files names as it is automatically determined by the WP2 software through the VO the user belongs to. This information is provided by in the VirtualOrganisation JDL attribute (filled by the UI).It is worth noting that the usage for the ranking phase of the WP2 getAccessCost (see 8.6.3) i.e. ranking CEs according to the cost for accessing data, can be triggered through the JDL by setting the rank as follows:

Rank = other.DataAccessCost;

The OutputData attribute allows instead the user to ask for the automatic upload and registration of datasets produced by the job on the WN. Through this attribute it is possible to indicate for each output file the LFN to be used for registration and the SE on which the file has to be uploaded. Both LFN and SE are optional in the sense that if no LFN is indicated then it is assigned automatically by the WP2 services (RM) and if no SE is indicated, the close SE is considered.

IST-2000-25182 PUBLIC 132 / 185


Doc. Identifier:


Date: 29/05/2003

OutputData is a list of classads, where each classad indicates the name of the file to be uploaded, the logical file to be used and the SE where the file has to be copied. E.g.:

OutputData = {[ OutputFile = "dataset_1.out "; StorageElement = "SE_1"; LogicalFileName = "LFN_1" ],[ OutputFile = "dataset_2.out "; StorageElement = "SE_2"; LogicalFileName = "LFN_2" ],] OutputFile = "dataset_3.out "; StorageElement = "SE_3"; LogicalFileName = "LFN_3" ]

};

If the attribute OutputData is found in the JDL then the JobWrapper at the end of the job calls the WP2 copyAndRegister service that copies the file from the WN onto the specified SE and registers it with the given LFN.If the specified LFN is already in use, WP2 RM registers the file with a newly generated identifier GUID (Grid Unique Identifier).During this process the JobWrapper creates a file (named “DSUpload_<unique_jobid_string>.out”) that is put automatically in the OutputSandbox attribute list by the UI and can then be retrieved by the user. This file contains the results of the upload and registration process in the following format:

<FILE_NAME> <LFN | ERROR>

e.g. in our case we could have:

dataset_1.out LFN_1dataset_2.out GUID_2dataset_3.out <error msg>

meaning that dataset_1.out was uploaded successfully and registered as LFN_1, dataset_1.out was uploaded successfully but with name GUID_2 (assigned by the ERM) since LFN_2 was already in use and upload of dataset_3.out failed for the reason specified by the reported error message.

IST-2000-25182 PUBLIC 133 / 185


Doc. Identifier:


Date: 29/05/2003

The Arguments attribute in the JDL allows the user to specify all the command line arguments needed to start the job. They have to be specified as a single string, e.g. the job sum that is started with:

$ sum N1 N2 –out result.out

is described by:

Executable = “sum”;Arguments = “N1 N2 –out result.out”;

If you want to specify a quoted string inside the Arguments then you have to escape quotes with the \ character. E.g. when describing a job like:

$ grep –i “my name” *.txt

you will have to specify:

Executable = “/bin/grep”;Arguments = “-i \”my name\” *.txt”;

Analogously, if the job takes as argument a string containing a special character (e.g. the job is the tail command issued on a file whose name contains the quotes character, say file1&file2), since on the shell line you would have to write: $ tail –f file1\&file2

in the JDL you’ll have to write:

Executable = “/usr/bin/tail”;Arguments = “-f file1\\\&file2”;

i.e. a \ for each special character.In general, special characters such as &, |, >, < are only allowed if specified inside a quoted string or preceded by triple \.The character “`” cannot be specified in the Arguments attribute of the JDL.The RetryCount attribute allows setting the number of submission retries for a job upon failure due to some grid component (i.e. not to the job itself). RetryCount has to be a positive number and the actual number of submission retries for a job is represented by the minimum value between RetryCount itself and the value of the MaxrRetryCount parameter in the WM configuration file (see section 5.2.4.3).

IST-2000-25182 PUBLIC 134 / 185


Doc. Identifier:


Date: 29/05/2003

The --hours allows the user to specify the user proxy duration H, in hours, needed for submitting the job. This option has to be used for long-lasting jobs, indeed a job when submitted needs to be accompanied by a valid proxy certificate during all its life-time and the default duration of user proxy created by UI commands is 12 hours that could in some case not be enough.It is recalled that anyway a safer way for submitting long-running jobs is to use the proxy renewal feature provided by the WMS.To do this the user should use the myproxy-init command (see section 7.1.1.1) before the edg-job-submit. The myproxy-init command registers indeed in a MyProxy server a valid long-term certificate proxy that will be used by WMS to perform a periodic credential renewal for the submitted job. When using the myproxy-init command the user has to specify either through the –s option or the MYPROXY_SERVER environment variable the host name of the MyProxy server where to store the certificate proxy.To trigger the proxy renewal mechanism, the same MyProxy server address has to be specified in the JDL through the MyProxyServer attribute (this can also be made a default behaviour through the configuration – see 5.5.3.1). An example of the JDL setting is provided hereafter:

MyProxyServer = “skurut.cesnet.cz”;

Note that the port number must not be provided.Interactive jobs are specified setting the JDL JobType attribute to “Interactive”. When an interactive job is submitted, the edg-job-submit command starts a grid console shadow process in the background that listens on a port for the job standard streams. Moreover the edg-job-submit command opens a new window where the incoming job streams are forwarded. The port on which the shadow process listens is assigned by the OS, but can be forced through the ListenerPort attribute in the JDL.Moreover for interactive jobs the UI automatically requires for the job outbound IP connectivity on the WN adding (in AND to the user defined expression) the other.GlueHostNetworkAdapterOutboundIP to the JDL Requirements expression.The --chkpt option allows the submission of a checkpointable job (JobType = “Checkpointable”) specifying as input a checkpoint state generated by a previously submitted job. This option makes the submitted job start running from the checkpoint state given in input and not from the very beginning. The initial checkpoint states to be used with this option can be retrieved by means of the edg-job-get-chkpt command (see 7.1.3.8). A checkpoint state is a JDL file as described in [R3].MPI jobs are specified setting the JDL JobType attribute to “MPICH”. When a MPI job is submitted the presence of the NodeNumber attribute (it specifies the required number of CPUs) in the JDL is mandatory and the UI automatically requires the MPICH runtime environment installed on the CE and a number of CPUs at least equal to the required number of nodes. This is done adding (in AND to the user defined expression) the following expression

IST-2000-25182 PUBLIC 135 / 185


Doc. Identifier:


Date: 29/05/2003

(other.GlueCEInfoTotalCPUs >= NodeNumber) && Member(other.GlueHostApplicationSoftwareRunTimeEnvironment,"MPICH")

to the the JDL Requirements expression.Lastly the --nomsg option makes the command display neither messages nor errors on the standard output. Only the edg_jobId assigned to the job is printed to the user if the command was successful. Otherwise the location of the generated log file containing error messages is printed on the standard output. This option has been provided to make easier use of the edg-job-submit command inside scripts in alternative to the --output option.It is important to note that the edg-job-submit is a sort of fire-and-forget command, i.e. it exits successfully once the JDL has been passed to the NS and the InputSandbox files have been transferred. It does not matter about what happens afterwards to the job. Understanding the reason of a job abort can however be accomplished by using the edg-job-status (especially looking at the “Status Reason” field) and edg-job-get-logging-info on the job identifier returned from the submission.

JOB DESCRIPTION FILEA job description file contains a description of job characteristics and constraints in a class-ad style. A general description of he class-ad language is provided in document [A7].The job description file must be edited by the user to insert relevant information about the job that is later needed by the RB to perform the match-making. Job description file entries are strings having the format attribute = expression and are terminated by the semicolon character. Comments must be preceded by a sharp character (#) or a double slash (//) at the beginning of each line.Being the class-ad an extensible language, it doesn’t exist a fixed set of admitted attributes, i.e. the user can insert in the job description file whatever attribute he believes meaningful to describe her/his jobs, anyway only the attributes that can be in some way connected with the resource ones published in the IS are taken into account by the Matchmaker/RB for the match-making process. Unrelated attributes are simply ignored except when they are used to build the Requirements expression. In the latter case they are indeed evaluated and could affect the match-making result. The attributes taken into account by the RB together with their meaning are listed in annex 8.1 and described in detail in document [A1]. That is the document that has to be followed by the user when writing the JDL description of her/his jobs.There is a small subset of JDL attributes that are compulsory, i.e. that have to be present in a job class-ad before it is sent to the Network Server in order to make possible the performing of the match making and submission. They can be grouped in two categories: some of them must be provided by the user whilst some other, if not provided, are filled by the UI with configurable default values. The following Table 1 summarises what just stated.

Attribute Mandatory Mandatory with default value (default value)

Type (Job)

JobType

IST-2000-25182 PUBLIC 136 / 185


Doc. Identifier:


Date: 29/05/2003

Attribute Mandatory Mandatory with default value (default value)

(Normal)

Executable

Requirements (other.GlueCEStateStatus ==

"Production")

Rank (other.GlueCEStateFreeCPUs

for MPICH jobs-

other.GlueCEStateEstimatedResponseTime for all other job types)

NodeNumber (only for MPICH jobs)

Table 1 Mandatory Attributes

In Table 1 the default values for Requirements and Rank can be interpreted respectively as follows:- if the user has not provided job constraints then Requirements is set to

(other.GlueCEStateStatus == "Production"), i.e. the target CE has to be active. - Since in the JDL the greater is the value of Rank the better is considered the match, if no

expression for Rank has been provided, then the resources where the jobs waits a shorter time to pass from the SCHEDULED to the RUNNING status are preferred, hence the Rank expression is set to other.GlueCEStateEstimatedResponseTime. MPICH jobs are an exception as they have as default rank other.GlueCEStateFreeCPUs meaning that the preferred resources are the ones having the higher number of free CPUs.

The default values for the Requirements and Rank attributes can be set in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf file. See section 5.5.3.1 for details on how to set these defaults.As the classad language (and hence the JDL) is an extensible language, it allows the user to freely include new attributes within the job description. These attributes are ignored by the WMS for the scheduling but are passed-through by the UI (if their syntax is correct) since they could be relevant for the submitter of for some other component processing the JDL.However if the job description file contains attributes that are unknown to the WMS, the UI will print a warning (when used with the --debug option) listing all of them.

OPTIONS--help

displays command usage.

IST-2000-25182 PUBLIC 137 / 185


Doc. Identifier:


Date: 29/05/2003

--versiondisplays UI version.

--vo vo_nameThis option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this JDL attribute hasn’t been specified, then the default VO specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user.

--resource ce_id-r ce_id

if the command is launched with this option, the job-ad sent to the RB contains a line of the type SubmitTo = ce_id and the job is submitted by the WMS to the resource identified by ce_id without going through the match-making process. Accepted format for the CEId is:<full hostname>:<port number>/jobmanager-<service>-<queue name>where valids for the <service> field are currently: lsf, pbs, condor and bqs.Note that when this option is used, the “.BrokerInfo” file is not generated.

--input file_path-i input_file

if this option is specified, the user will be asked to choose a CEId from a list of CEs contained in the file_path. Once a CEId has been selected the command behaves as explained for the --resource option. If this option is used together with the –noint one and the input file contains more than one CEId, then the first CEId in the list is taken into account for submitting the job.

--config file_path-c file_path

if the command is launched with this option, the configuration file pointed to by file_path is used instead of the standard configuration file.

--config-vo file_pathif the command is launched with this option, the vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file.

--output file_path-o file_path

IST-2000-25182 PUBLIC 138 / 185


Doc. Identifier:


Date: 29/05/2003

writes the generated edg_jobId assigned to the submitted job in the file specified by out_file. out_file can be either a simple name or an absolute path (on the submitting machine). In the former case the file out_file is created in the current working directory.

--chkpt file_pathThis option can be used only for checkpointable jobs. The state specified as input is a checkpoint state generated by a previously submitted job. This option makes the submitted job start running from the checkpoint state given in input and not from the very beginning.The initial checkpoint states to be used with this option can be retrieved by means of the edg-job-get-chkpt command (see 7.1.3.8).

--hours H-h H

allows the user to specify the user proxy duration H, in hours, needed for submitting the job. When used with this option the dg-job-submit command behaves as follows:

the command checks for user proxy existence and if the proxy does not exist a new proxy with H hours duration is created

if the proxy exists then its duration is checked against the value specified with the --hours option. If proxy duration is greater than H hours then the job is submitted with the existing proxy, otherwise the old proxy is destroyed and a new one with H hours duration is created and used for submitting the job.

This mechanism allows the user to create before submission a proxy with a suitable duration for her/his job; moreover the user is not obliged to enter the PEM pass-phrase at each submission i.e. in all those cases where the existing proxy has a validity great enough for the job.

--nomsgthis option makes the command print on the standard output only the edg_jobId generated for the job if submission was successful; the location of the log file containing massages and diagnostics is printed otherwise.

--nointif this option is specified every interactive question to the user is skipped, moreover only the dg_jobId is returned on the standard output. All warning messages and errors (if occurred) are written to the file edg-job-submit_<UID>_<PID_<timestamp>.log under the /tmp directory. Log file location is configurable.

--debug

IST-2000-25182 PUBLIC 139 / 185


Doc. Identifier:


Date: 29/05/2003

when this option is specified, information about parameters used for the API functions calls inside the command are displayed on the standard output and are written to dg-job-submit_<UID>_<PID>_<timestamp>.log file under the /tmp directory too. Log file location is configurable.

--logfile file_pathwhen this option is specified, the command log file is relocated to the location pointed by file_path

jdl_filethis is the file containing the JDL describing the job to be submitted. It must be the last argument of the command.

EXIT STATUSedg-job-submit exits with a status value of 0 (zero) upon success, and 1 (one) upon failure.

EXAMPLES1. $> edg-job-submit –vo cms myjob1.jdl

where myjob1.jdl is as follows:############################################## #

# -------- Job description file ----------# ############################################## [ JobType = "Normal" ; Executable = "$(CMS)/fpacini/exe/sum.exe"; InputData = "LF:testbed0-00019"; DataAccessProtocol = "gridftp"; Rank = other.GlueCEPolicyMaxCPUTime; Requirements = other.GlueCEInfoLRMSType == "Condor" && \

(!(RegExp("*nikhef*",other.GlueCEUniqueID)));

submits sum.exe to a resource (supposed to contain the executable file) whose LRMS is Condor and not containing the string “nikhef” in the CE identifier. The command returns the following output to the user, containing the job handle (edg_jobid):

IST-2000-25182 PUBLIC 140 / 185


Doc. Identifier:


Date: 29/05/2003

================= edg-job-submit Success ==================================The job has been successfully submitted to the Network Server. Your job is identified by (edg_jobId): https://ibm139.cnaf.infn.it:9000/ZU9yOC7AP7AOEhMAHirG3Use edg-job-status command to display current job status.======================================================================

2. $> edg-job-submit --chkpt /home/test/state10.chkpt myjob2.jdl Submits the checkpointable job described by myjob2.jdl that will start running from the initial state state10.chkpt.

SEE ALSO[A1], [A2], edg-job-list-match, edg-job-attach, edg-job-get-chkpt.

IST-2000-25182 PUBLIC 141 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3.2. edg-job-get-output This command retrieves the job output files (specified by the OutputSandbox attribute of the job-ad) from the RB node and stores them on the submitting machine local disk.

SYNOPSISedg-job-get-output [options] <job Id(s)>

Options: --help --version --input, -i <file_path> --dir <directory_path> --config, -c <file_path> --noint --debug --logfile <file_path>

DESCRIPTION The edg-job-get-output command can be used to retrieve the output files of a job that has been submitted through the edg-job-submit command with a job description file including the OutputSandbox attribute. After the submission, when the job has terminated its execution, the user can download the files generated by the job and temporarily stored on the RB machine as specified by the OutputSandbox attribute, issuing the edg-job-get-output with as input the edg_jobId returned by the edg-job-submit. It is also possible to specify a list of job identifiers when calling this command or an input file containing edg_jobIds by means of the --input option. When the --input is used, the user is requested to choose all, one or a subset of the job identifiers contained in the input file. It is important to note that the OutputSandbox of a submitted job can only be retrieved when the job has reached the Done status (see Annex 8.2) indicating that the job has successfully terminated its execution and the OutputSandbox files are ready for retrieval on the RB node. edg-job-get-output will always fail for jobs that are not yet in the Done status.The user can decide the local directory path on the UI machine where these files have to be stored by means of the --dir option, otherwise the retrieved files are put in a default location specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf configuration file (OutputStorage parameter). In both cases a sub-directory will be added to the path supplied. The name of this sub-directory is the unique string of the edg_jobId identifier (see command edg-job-submit for details on the edg_jobId structure).If the user wants to use her/his “private” configuration file, this can be done using option --config path_name. As a consequence the edg-job-get-output command looks for the file

IST-2000-25182 PUBLIC 142 / 185


Doc. Identifier:


Date: 29/05/2003

“path_name” instead of the standard configuration file. If this file does not exist the user is notified with an error message and the command is aborted.

OPTIONS

--help displays command usage.


--dir directory_pathretrieved files (previously listed by the user through the OutputSandbox attribute of the job description file) are stored in the location indicated by directory_path/<edg_jobId unique string>.



--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if occurred) are written to the file edg-job-get-output_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location of log file is configurable.

--debugwhen this option is specified, information about parameters used for the API functions calls inside the command are displayed on the standard output and are written to dg-get_job_output_<UID>_<PID>_<timestamp>.log file under the /tmp directory too. Location of log file is configurable.


edg_jobId

IST-2000-25182 PUBLIC 143 / 185


Doc. Identifier:


Date: 29/05/2003

job identifier returned by edg-job-submit. If a list of oe or more job identifiers is specified, edg_jobIds have to be separated by a blank. Job identifiers must be last argument of the command.

--input file_path-i file_path

this option makes the command return the OutputSandbox files for each edg_jobId contained in the file_path. This option can’t be used if one (or more) edg_jobIds have been already specified. The format of the input file must be as follows: one edg_jobId for each line and comment lines must begin with a “#” or a “*” character.

EXIT STATUSedg-job-get-output exits with a status value of 0 (zero) upon success, >0 upon failure and <0 upon partial failure. An example of partial failure is when more than one job identifiers has been specified and the OuputSandbox could be retrieved only for some of them.

IST-2000-25182 PUBLIC 144 / 185


Doc. Identifier:


Date: 29/05/2003

EXAMPLESLet us consider the following command:

$> edg-job-get-output https://ibm139.cnaf.infn.it:9000/CiXMLojKC_iLsvSHfEhqIQ --dir /home/dataIt retrieves the files listed in the OutputSandbox attribute of job identified by https://ibm139.cnaf.infn.it:9000/CiXMLojKC_iLsvSHfEhqIQ from the RB node and stores them locally in /home/data/CiXMLojKC_iLsvSHfEhqIQ.

IST-2000-25182 PUBLIC 145 / 185

https://grid004.it:2234/124.75.74.12/12354732109721?firefox.esrin.esa.it:4577


Doc. Identifier:


Date: 29/05/2003

7.1.3.3. edg-job-list-match Returns the list of resources fulfilling job requirements specified in the JDL job description

SYNOPSISedg-job-list-match [options] <jdl file>Options: --help --version --verbose --rank --config, -c <file_path> --config-vo <file_path> --vo <vo_name> --output, -o <file_path> --noint --debug --logfile <file_path>

edg-job-list-match displays the list of identifiers of the resources on which the user is authorized and satisfying the job requirements included in the job description file. The CE identifiers are returned either on the standard output or in a file according to the chosen command options, and are strings univocally identifying the CEs published in the IS. The returned CEIds are listed in decreasing order of rank, i.e. the one with the best (greater) rank is in the first place and so on.The --rank option makes the command also display the rank value for each found CEId.The --vo option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this JDL attribute hasn’t been specified, the default VO specified in the $EDG_WL_LOCATION/etc/ edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user. With the deployment of VOMS, the VO information will be encoded in the user’s proxy certificate and this will make the described behaviour change.edg-job-list-match requires a job description file in which job characteristics and requirements are expressed by means of a class-ad. The job description file is first syntactically checked and then used as the main command-line argument to edg-job-list-match. The Network Server is only contacted to find job compatible resources; the job is not submitted. See the edg-job-submit section 7.1.3.1 and in particular Error: Reference sourcenot found for general rules for building the job description file.

IST-2000-25182 PUBLIC 146 / 185


Doc. Identifier:


Date: 29/05/2003

If the user wants to use his “private” configuration, file this can be done using option --config path_name. The option --verbose of the dg-job-list-match command can be used to obtain on the standard output the class-ad sent to the RB generated from the job description.The --output option makes the command save the list of compatible resources into the specified file. If the provided file name is not an absolute path, then the output file is created in the current working dir.

JOB DESCRIPTION FILESee section 7.1.3.1for details.

IST-2000-25182 PUBLIC 147 / 185


Doc. Identifier:


Date: 29/05/2003

OPTIONS

OPTIONS



--verbose-v

displays on the standard output the job class-ad that is sent to the Network Server generated from the job description file. This differs from the content of the job description file since the UI adds to it some attributes that cannot be directly inserted by the user (e.g., defaults for Rank and Requirements if not provided, VirtualOrganisation etc).

--rankdisplays the “matching” CEIds and the associated ranking values.

--vo vo_nameThis option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this JDL attribute has not been specified, then the default VO specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user.



--config-vo file_pathif the command is launched with this option, the vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file.


IST-2000-25182 PUBLIC 148 / 185


Doc. Identifier:


Date: 29/05/2003

returns the CEIds list in the file specified by file_path. file_path can be either a simple name or an absolute path (on the submitting machine). In the former case the file file_path is created in the current working directory.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if any) are written to the file edg-job-list-match <UID>_<PID>_<timestamp>.log under the /tmp directory. Location of the log file is configurable.

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-list-match_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location of the log file is configurable.


jdl_filethis is the file containing the classad describing the job to be submitted. It must be the last argument of the command.

EXIT STATUSedg-job-list-match exits with a status value of 0 (zero) upon success, and a non-zero value upon failure.

EXAMPLESLet us consider the following command:$> edg-job-list-match myjob.jdlwhere the job description file myjob.jdl looks like:

######################################### # # ---- Sample Job Description File ---- #

IST-2000-25182 PUBLIC 149 / 185


Doc. Identifier:


Date: 29/05/2003

######################################### JobType = "Normal";Executable = "sum.exe";StdInput = "data.in";InputSandbox = {"/home_firefox/fpacini/exe/sum.exe","/home1/data.in"};OutputSandbox = {"data.out","sum.err"};Rank = other.GlueCEPolicyMaxCPUTime;Requirements = other.GlueCEInfoLRMSType == "Condor" && other.GlueHostArchitecturePlatformType== "INTEL" && other.GlueHostOperatingSystemName == "LINUX" &&

other.GlueCEStateFreeCPUs >= 2;

In this case the job requires CEs being Condor Pools of INTEL LINUX machines with at least 2 free Cpus. Moreover the Rank expression states that queues with higher maximum CPU time allowed for jobs are preferred. The response of such a command is something as follows:

*************************************************************************** Computing Element IDs LIST The following CE(s) matching your job requirements have been found:

*CEId* bbq.mi.infn.it:2119/jobmanager-pbs-dque skurut.cesnet.cz:2119/jobmanager-pbs-wp1***************************************************************************

$>

SEE ALSO[A1],[A2], edg-job-submit.

IST-2000-25182 PUBLIC 150 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3.4. edg-job-cancel Cancels one or more submitted jobs.

SYNOPSISedg-job-cancel [options] <job Id(s)>

Options: --help --version --all --input, -i <file_path> --config, -c <file_path> --config-vo <file_path> --vo <vo_name> --output, -o <file_path> --noint --debug --logfile <file_path>

DESCRIPTION This command cancels a job previously submitted using edg-job-submit. Before cancellation, it prompts the user for confirmation. The cancel request is sent to the Network Server that forwards it to the WM that fulfils it.edg-job-cancel can remove one or more jobs: the jobs to be removed are identified by their job identifiers (edg_jobIds returned by edg-job-submit) provided as arguments to the command and separated by a blank space. The result of the cancel operation is reported to the user for each specified edg_jobId.If the --all option is specified, all the jobs owned by the user submitting the command are removed. When the command is launched with the --all option, no edg_jobId can be specified. It has to be remarked that only the owner of the job can remove the job. When the --all option is specified the UI queries each LB listed in the vo-specific configuration file $EDG_WL_LOCATION/etc/<vo_name>/edg_wl_ui.conf for getting the identifiers of all the jobs owned by the user identified by her/his certificate subject. Afterwards the UI sends a cancellation request to the NS for each job being in a status for which the cancellation is allowed.Job states for which cancellation is allowed are:

- Submitted- Waiting

IST-2000-25182 PUBLIC 151 / 185


Doc. Identifier:


Date: 29/05/2003

- Ready - Scheduled - Running- Unknown

For all the other job states the cancellation request will result in a failure.If the user wants to use his “private” configuration file this could be done using option --config file_path.The --input option permits to specify a file (file_path) that contains the edg_jobIds to be removed. The format of the file must be as follows: one edg_jobId for each line and comment lines must begin with a “#” or a “*” character. When using this option the user is interrogated for choosing among all, one or a subset of the listed job identifiers. If the file_path does not represent an absolute path the file will be searched in the current working directory.

IST-2000-25182 PUBLIC 152 / 185


Doc. Identifier:


Date: 29/05/2003

OPTIONS



--allcancels all job owned by the user submitting the command. This option can’t be used either if one or more edg_jobIds have been specified explicitly or with the –input option.


cancels edg_jobId contained in the file_path. This option can’t be used neither if one or more edg_jobIds have been specified nor with the –all option.



--config-vo file_pathif the command is launched with this option, the vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file. This option is allowed only when used together with the --all one.

--vo vo_nameThis option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this JDL attribute hasn’t been specified, then the default VO specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user. This option is allowed only when used together with the --all one.


IST-2000-25182 PUBLIC 153 / 185


Doc. Identifier:


Date: 29/05/2003

writes the cancel results in the file specified by file_path instead of the standard output. file_path can be either a simple name or an absolute path (on the submitting machine). In the former case the file file_path is created in the current working directory.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if occurred) are written to the file edg-job-cancel_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location of the log file is configurable.

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-cancel_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location of the log file is configurable.


edg_jobIdjob identifier returned by edg-job-submit. The job identifier list must be the last argument of this command.

EXIT STATUSdg-job-cancel exits with a status value 0 if all the specified jobs were cancelled successfully, >0 if errors occurred for each specified job id and <0 in case of partial failure. An example of partial failure is when more then one job has been specified: some jobs could be successfully removed and some others could be not removed.

EXAMPLES

1. $> edg-job-cancel --input joblist.txt

IST-2000-25182 PUBLIC 154 / 185


Doc. Identifier:


Date: 29/05/2003

where joblist.txt is a file containing 3 edg_JobIds, displays the following confirmation message:Are you sure you want to remove all jobs specified? [y/n]n: y

====================== edg-job-cancel Success =========================The cancel request for the following job(s) has been successfully submitted to NS:

- https://ibm139.cnaf.infn.it:9000/nUbiIiMFmY1oIusAaWxPhg - https://ibm139.cnaf.infn.it:9000/VtMvhs8z7WGCptt92ZMPIQ - https://ibm139.cnaf.infn.it:9000/yKTKyrdSgHKQ1wwwSocJiw

======================================================================== $> In this case the command exit code is 0.

2. $> edg-job-cancel --all --noint

removes all job owned by the user submitting the command.

SEE ALSO[A2], edg-job-submit.

IST-2000-25182 PUBLIC 155 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3.5. edg-job-statusDisplays bookkeeping information about submitted jobs.

SYNOPSISedg-job-status [options] <job Id(s)>Options: --help --version --all --input, -i <file_path> --verbosity, -v <verbosity_value> --config, -c <file_path> --config-vo <file_path> --vo <vo_name> --output, -o <file_path> --noint --debug --logfile <file_path>

DESCRIPTION This command prints the status of a job previously submitted using edg-job-submit. The job status request is sent to the LB that provides the requested information. This can be done during the whole job life.edg-job-status can monitor one or more jobs: the jobs to be checked are identified by one or more job identifiers (edg_jobIds returned by edg-job-submit) provided as arguments to the command and separated by a blank space. If the --all option is specified, information about all the jobs owned by the user submitting the command is printed on the standard output. When the command is launched with the --all option, neither can an edg_jobId be specified nor can the --input option be specified. The --input option permits to specify a file (file_path) that contains the edg_jobIds to monitor. The format of the file must be as follows: one edg_jobId for each line and comment lines have to begin with a “#” or a “*” character. When using this option the user is requested for choosing among all, one or a subset of the listed job identifiers. If the file_path does not represent an absolute path, it will be searched in the current working directory.If the user wants to use his “private” configuration file, this can be done using option --config file_path. The same applies for the vo-specific configuration file and the --config-vo option.

IST-2000-25182 PUBLIC 156 / 185


Doc. Identifier:


Date: 29/05/2003

The --verbosity option allows setting the detail level of the returned information. This option can be specified with three values, 0, 1 and 2. The default level of verbosity is 0 unless otherwise specified in the UI configuration file $EDG_WL_LOCATION/etc/ edg_wl_ui_cmd_var.conf (DefaultStatusLevel parameter).Hereafter are listed the information displayed according to the verbosity level.Verbosity equal 0:

- edg_jobId (the job unique identifier)- Current Status (the job current status)- exit_code (Unix exit code – if applicable)- Status Reason (reason for being in this state)- Reached on (date/time when the job entered actual state)- destination (ID of CE where the job has been submitted – if applicable)

With verbosity equal 1, some additional information fields are added such as:

- cancelling (boolean indicating if a cancellation request for the job is in progress)

- cancelReason (Reason of cancel)- ce_node (Worker node where the job is executed) - children_hist (summary -- histogram -- of children job states)- children_num (number of subjobs) - subjob_failed (Subjob failed -- the parent job will fail too)- condorId (Id within Condor-G)- cpuTime (Consumed CPU time)- expectUpdate (Boolean indicating that some logged

information has not arrived yet)- expectFrom (Sources of the missing information)- jobtype (Type of the request: 0 = Job, 1 = DAG)- lastUpdateTime (Last known event of the job)- location (location Where the job is being processed)- network_server (Network server handling the job) - owner (certificate subject of Job owner)- resubmitted (boolean indicating that the job was resubmitted)

Lastly, with verbosity equal 2 there are the following additional fields:

- jdl (User submitted job description)

IST-2000-25182 PUBLIC 157 / 185


Doc. Identifier:


Date: 29/05/2003

- matched_jdl (Full job description after matchmaking)- condor_jdl (ClassAd passed to Condor-G for job

submission)- rsl (Job RSL sent to Globus)- stateEnterTimes (When all previous states were entered)

Information fields that are not available (i.e. not returned by the LB because not applicable for the given status) are not printed at all to the user.The job Status possible values are reported in Annex 8.2. Details on the Job Status Diagram can be found in [A4].

OPTIONS--help

displays command usage.


--alldisplays status information about all job owned by the user submitting the command. This option can’t be used either if one or more edg_jobIds have been specified or if the --input option has been specified. All LBs listed in the vo-specific UI configuration file $EDG_WL_LOCATION/etc/<vo_name>/edg_wl_ui.conf are contacted to fulfil this request.

--input input_file-i input_filedisplays bookkeeping info about dg_jobIds contained in the input_files. When using this option the user is interrogated for choosing among all, one or a subset of the listed job identifiers. This option can’t be used either if one or more dg_jobIds have been specified or if the --all option has been specified.

--verbosity verb_level--v verb_level

sets the detail level of information about the job displayed to the user. Possible values for verb_level are 0,1 and 2.

--config file_path

IST-2000-25182 PUBLIC 158 / 185


Doc. Identifier:


Date: 29/05/2003

-c file_pathif the command is launched with this option, the configuration file pointed to by file_path is used instead of the standard configuration file.

--config-vo file_pathif the command is launched with this option, the vo-specific configuration file pointed to by file_path is used instead of the standard vo-specific configuration file. This option is allowed only when used together with the --all one.

--vo vo_nameThis option allows the user to specify the Virtual Organisation she/he is currently working for. If this option is not used, then the VirtualOrganisation attribute in the JDL is considered. If this attribute hasn’t been specified, then the default VO specified in the $EDG_WL_LOCATION/etc/edg_wl_ui_cmd_var.conf (DefaultVO field) configuration file is considered. Otherwise an error is returned to the user. This option is allowed


writes the bookkeping information in the file specified by file_path instead of the standard output. file_path can be either a simple name or an absolute path (on the submitting machine). In the former case the file file_path is created in the current working directory.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if any) are written to the file edg-job-status_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location of log file is configurable.

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-status_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location of log file is configurable.


IST-2000-25182 PUBLIC 159 / 185


Doc. Identifier:


Date: 29/05/2003

edg_jobIdjob identifier returned by edg-job-submit. Job identifiers must always be provided as last arguments of the command.

EXIT STATUSedg-job-status exits with a value of 0 if the status of all the specified jobs is retrieved correctly, >0 if errors occurred for each specified job id and <0 in case of partial failure. An example of partial failure is when more then one job is specified: status info could be successfully retrieved for some jobs and not retrieved for some others.

IST-2000-25182 PUBLIC 160 / 185


Doc. Identifier:


Date: 29/05/2003

EXAMPLES$> edg-job-status –v 0 https://ibm139.cnaf.infn.it:9000/_tO6hdgToYKGCuV68q-gqQ

displays the following lines:

*************************************************************BOOKKEEPING INFORMATION:

Printing status info for the Job : https://ibm139.cnaf.infn.it:9000/_tO6hdgToYKGCuV68q-gqQCurrent Status: Scheduled Destination: bbq.mi.infn.it:2119/jobmanager-pbs-dqueStatus Reason: Job successfully submitted to Globusreached on: Tue May 6 16:14:59 2003*************************************************************

$>

SEE ALSO[A1], [A2], [A4], edg-job-submit.

IST-2000-25182 PUBLIC 161 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3.6. edg-job-get-logging-infoDisplays logging information about submitted jobs.

SYNOPSISedg-job-get-logging-info [options] <job Id(s)>Options: --help --version --input, -i <file_path> --verbosity, -v <verbosity_value> --config, -c <file_path> --output, -o <file_path> --noint --debug --logfile <file_path>

DESCRIPTION This command queries the LB persistent DB for logging information about jobs previously submitted using edg-job-submit. The job logging information are stored permanently by the LB service and can be retrieved also after the job has terminated its life-cycle, differently from the bookkeeping information that are in some way “consumed” by the user during the job existence. The edg-job-get-logging-info request is sent to the LB service that queries the DB and returns the retrieved information. Content of the logging information varies according to the type of the event they are related to. The most common information fields are:

- Event (event type - possible event types are listed in Annex 8.3)- source (WMS component which generated the event)- result (result of the attempt)- destination (destination where the job is being transferred to)- timestamp (timestamp of event generation)

The --verbosity option allows setting the detail level of the returned information. This option can be specified with three values, 0, 1 and 2. The default level of verbosity is 0 unless otherwise specified in the UI configuration file $EDG_WL_LOCATION/etc/ edg_wl_ui_cmd_var.conf (DefaultLoggingLevel parameter).

IST-2000-25182 PUBLIC 162 / 185


Doc. Identifier:


Date: 29/05/2003

The information listed above is displayed when the chosen verbosity level is 0. If the command is issued with 1 as verbosity flag, then the following additional information is shown:

- host (hostname of the machine where the event was generated)- dest_host (destination hostname)- dest_instance (instance of destination WMS component) - user (identity -- cert. subj. -- of the generator)- dest_jobid (destination internal jobid)- node (worker node where the executable is run)- ns (Network server handling the job) - nsubjobs (number of subjobs)- local_jobid (new jobId assigned by the receiving component)- queue (destination queue name)- status_code (way of job termination/classification of the cancel)

Lastly if the command is issued with verbosity level 2, additional information mostly consisting in the job description within the WMS component that has logged the event, is printed to the user:

- jdl (job description)- job (job description in receiver language)- descr (description of current job transformation -- output of helper)- classad (checkpoint state value)- seqcode (sequence code assigned to the event)- level (logging level -- system, debug, ...)

Data on several jobs can be queried by specifying a list of job identifiers separated by a blank space as arguments of the command. Moreover the --input option permits to specify a file (file_path) which contains the edg_jobIds whose information are requested. The format of the file must be as follows: one edg_jobId for each line and comment lines have to begin with a “#” or a “*” character. When using this option the user is interrogated for choosing among all, one or a subset of the listed job identifiers. If the file_path does not represent an absolute path, it will be searched in the current working directory.Each event logged in the LB has an associated log level according to “Universal Format for Logger Messages” (see draft-abela-ulm-05.txt available at http://www-didc.lbl.gov/NetLogger/draft-abela-ulm-05.txt). Default value for the log level used by WMS components is System, anyway there could be special situations in which problems investigation is needed and additional events are logged with the Debug log level. The --output option can be used to have the retrieved information written in the file identified by file_path instead of the standard output. file_path can be either a simple name or an absolute

IST-2000-25182 PUBLIC 163 / 185

http://www-didc.lbl.gov/NetLogger/draft-abela-ulm-05.txt


Doc. Identifier:


Date: 29/05/2003

path (on the submitting machine). In the former case the file file_path is created in the current working directory.If the user wants to use his “private” configuration file this could be done using option --config file_path.

OPTIONS




retrieves logging info for all edg_jobIds contained in the file_path. This option can’t be used if one or more edg_jobIds have been specified.

--verbosity verb_level--v verb_level

sets the detail level of information about the job displayed to the user. Possible values for verb_level are 0,1 and 2.




writes the logging information in the file specified by file_path instead of the standard output. file_path can be either a simple name or an absolute path (on the submitting machine). In the former case the file file_path is created in the current working directory.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if occurred) are written to the file edg-job-logging_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location for log file is configurable.

IST-2000-25182 PUBLIC 164 / 185


Doc. Identifier:


Date: 29/05/2003

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-logging_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location for log file is configurable.


edg_jobIdjob identifier returned by edg-job-submit. Job identifiers must always be provided as last arguments for this command.

EXIT STATUSedg-job-get-logging-info exits with a value of 0 if the status of all the specified jobs is retrieved correctly, >0 if errors occurred for each specified job and <0 in case of partial failure. An example of partial failure is when more then one job is specified: some job’s logging info could be successfully retrieved and some others could be not retrieved.

EXAMPLES1. $> edg-job-get-logging-info \

https://ibm139.cnaf.infn.it:9000/GMUJtnNqe6Lq7w7MfOzeQw –output mylog.txt

writes in file mylog.txt in the current working directory logging information about the job identified by https://ibm139.cnaf.infn.it:9000/GMUJtnNqe6Lq7w7MfOzeQw.

2. $> edg-job-get-logging-info –v 0 –input $HOME/myIds.txt where $HOME/myjobs.txt contains two job identifiers, displays the following output

-------------------------------------------------------------------------------------------------------1 : https://ibm139.cnaf.infn.it:9000/D4S_i25ffAsPnKB3iCqeaA2 : https://ibm139.cnaf.infn.it:9000/2qzyCbPWr7pDY3rNh9PuXAa : allq : quit-------------------------------------------------------------------------------------------------------Choose one or more edg_jobId(s) in the list - [1-2]all: 2

IST-2000-25182 PUBLIC 165 / 185


Doc. Identifier:


Date: 29/05/2003

**********************************************************************LOGGING INFORMATION:

Printing info for the Job : https://ibm139.cnaf.infn.it:9000/2qzyCbPWr7pDY3rNh9PuXA --- Event: RegJob- source = UserInterface- timestamp = Wed May 14 10:55:35 2003 --- Event: Transfer- destination = NetworkServer- result = START- source = UserInterface- timestamp = Wed May 14 10:55:36 2003 ---Event: Transfer- destination = NetworkServer- result = OK- source = UserInterface- timestamp = Wed May 14 10:55:44 2003 --- Event: Accepted- source = NetworkServer- timestamp = Wed May 14 10:56:42 2003 --- Event: EnQueued- result = OK- source = NetworkServer- timestamp = Wed May 14 10:56:45 2003

**********************************************************************……

SEE ALSO[A2], [A4], edg-job-submit.

IST-2000-25182 PUBLIC 166 / 185


Doc. Identifier:


Date: 29/05/2003

7.1.3.7. edg-job-attachThis commands starts an interactive session a previously submitted interactive job.

SYNOPSISedg-job-attach [options] <job Id>Options: --help --version --port, -p <port_num> --config, -c <file_path> --input, -i <file_path> --noint --debug --logfile <file_path>

DESCRIPTIONThis commands starts a listener process on the UI machine (grid_console_shadow) that allows attaching to the standard streams of a previously submitted interactive job and displays them on a dedicated window.The listener process and the window are started automatically by the edg-job-submit command for interactive jobs, so this command can be used for example in case a problem occurred on the UI machine that made the interactive session be lost or the user needs to follow the job from another machine or another port on the same machine (--port option).This command can only be invoked for interactive jobs.

OPTIONS



--port port_num-p port_num

make sthe command start a listener on the local machine on the specified port and logs these information to the LB associated to the job.

IST-2000-25182 PUBLIC 167 / 185


Doc. Identifier:


Date: 29/05/2003




allows the user to attach to one (just one) of the edg_jobIds contained in the file_path. This option can’t be used if one edg_jobIds has been specified.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if occurred) are written to the file edg-job-attach_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location for log file is configurable.

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-attach_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location for log file is configurable.



EXIT STATUSedg-job-attach exits with a value of 0 on success and >0 on failure.EXAMPLES$> edg-job-attach https://ibm139.cnaf.infn.it:9000/t3KwW8qhXhkYs-ZfNCFidg

displays the following information message:

********************************************************************** JOB ATTACHED:

IST-2000-25182 PUBLIC 168 / 185


Doc. Identifier:


Date: 29/05/2003

The Interactive Session Listener has been successfully launched with the following parameters: --- Host: 10.1.1.90 Port: 40713 Pid: 18575**********************************************************************

and opens a window allowing interaction with the job through the standard streams.

7.1.3.8. edg-job-get-chkptThis commands retrieves checkpoint states saved by a previously submitted checkpointable job.

SYNOPSISedg-job-get-chkpt [options] <job Id>Options: --help --version --cs <state_num> --config, -c <file_path> --input, -i <file_path> --output, -o <file_path> --noint --debug --logfile <file_path>

DESCRIPTIONThis commands allows the user to retrieve one or more checkpoint states saved by a previously submitted job. Checkpoint states are retrieved from the LB server and are saved locally into a file in JDL format. The --cs option allows the user to select the checkpoint state she/he wants to be retrieved. Indeed specifying the command with “--cs N” makes the command retrieve the last but N job checkpoint state. Last saved state is retrieved otherwise.The retrieved state is saved in a file in JDL format. The output file path can be set through the --output option of the command.This command can be used only for checkpointable jobs.

IST-2000-25182 PUBLIC 169 / 185


Doc. Identifier:


Date: 29/05/2003

OPTIONS





--cs state_numif the command is launched with this option then it retrieves the “ last but state_num” state saved by the job. Last saved state is returned if the option is not used (equivalent to state_num = 0).


allows the user to select one (just one) of the edg_jobIds contained in the file_path for retrieval of the saved checkpoint state. This option can’t be used if one edg_jobIds has been specified.


saves the retrieved state in the file specified by file_path. file_path can be either a simple name or an absolute path (on the submitting machine). In the former case the file file_path is created in the current working directory. If this option is not used the retrieved state is displayed on the standard output.

--nointif this option is specified every interactive question to the user is skipped. All warning messages and errors (if occurred) are written to the file edg-job-get-chkpt_<UID>_<PID>_<timestamp>.log under the /tmp directory. Location for log file is configurable

--debugwhen this option is specified, information about the API functions called inside the command are displayed on the standard output and are written to the file edg-job-

IST-2000-25182 PUBLIC 170 / 185


Doc. Identifier:


Date: 29/05/2003

attach_<UID>_<PID>_<timestamp>.log under the /tmp directory too. Location for log file is configurable.



EXIT STATUSedg-job-get-chkpt exits with a value of 0 on success and >0 on failure.

EXAMPLES

IST-2000-25182 PUBLIC 171 / 185


Doc. Identifier:


Date: 29/05/2003

8. ANNEXES

8.1. JDL ATTRIBUTESThe JDL is a fully extensible language (i.e. it does not rely on a fixed schema), hence the user is allowed to use whatever attribute for the description of a job without incurring in er-rors. Anyway only a certain set of attributes (that we will refer to as “supported” attributes) can be taken into account by the WMS components for scheduling a submitted job. Indeed in order to be actually used for selecting a resource, an attribute used in a job class-ad needs to have a correlation with some characteristic of the resources that are published in the GIS (aka MDS).The “supported” attributes, their meaning and the way to use them to describe a job are dealt in detail in document [A1] also available at the following URL:http://www.infn.it/workload-grid/docs/

8.2. JOB STATUS DIAGRAMThe following reports the status that a job can assume during its life cycle.

Figure 2 Job Life Cycle

Job status in Figure 2 are briefly described hereafter (see [A4] for further details):

STATUS:

- SUBMITTED: job is entered by the user to the User Interface but not yet transferred to Network Server for processing.

- WAITING: job has been accepted by NS and is waiting for Workload Manager processing or is being processed by WM Helper modules (e.g., WM is busy, no appropriate Computing Element (cluster) has been found yet, required dataset is not available, job is waiting for resource allocation).

IST-2000-25182 PUBLIC 172 / 185


Doc. Identifier:


Date: 29/05/2003

- READY: job has been processed by WM and its Helper modules (especially, appropriate Computing Element has been found) but not yet transferred to the Computing Element (local batch system queue) via Job Controller and Condor-G.

- SCHEDULED: job is waiting in the queue on the Computing Element.- RUNNING: job is running.- DONE: job exited or is considered to be in a terminal state by Condor-G (e.g., submission

to CE has failed in an unrecoverable way). - ABORTED: job processing was aborted by WMS (waiting in the Workload Manager

queue or Computing Element for too long, over-use of quotas, expiration of user credentials, etc.).

- CANCELLED: job has been successfully cancelled on user request.- CLEARED: output sandbox was transferred to the user or removed due to the timeout.

IST-2000-25182 PUBLIC 173 / 185


Doc. Identifier:


Date: 29/05/2003

8.3. JOB EVENT TYPESHereafter is reported the list of job event types that could be returned to the user by the edg-job-get-logging-info command. They are organized in several categories:

Events concerning a job transfer between components: JobTransfer A component generates this event when it tries to transfer a job to

some other component via network interface (protocol). This event contains the identification of the receiver and possibly the job description expressed in the language accepted by the receiver. The result of the transfer, i.e. success or failure, as seen by the sender is also included.

JobAccepted A component generates this event when it receives a job from another WMS component. This event contains also the locally assigned job identifier.

JobRefused Receiving component could not accept the job, the reason being a part of the event.

JobEnqueue The job is inserted into a queue, e.g., the queue holding the job after it is received by Network Server and before it is processed by Workload Manager.

JobDequeue The job is removed from queue. HelperCall Helper component is called during the job processing. The type-

specific data include the name of called Helper, whether the logging component is called or calling one, and optionally parameters passed to the Helper.

HelperReturnCall to Helper returned. Events concerning a job state change during processing within a component:

JobAbort The job processing is stopped by WMS due to error condition, the event contains the reason for abort.

JobRun The job is started on a CE. JobDone Job has exited, has been successfully cancelled or is considered to be

in terminal state by Condor-G. JobResub The result of resubmission decision after the job has failed. JobCleared The user has successfully retrieved the job results, e.g. the output files

specified in the output sandbox, or the job results has been deleted due to time limit.

JobCancel Cancel operation has been attempted on the job. JobPurge The job was purged from bookkeeping server's database. This event is

stored only in a logging server..

Events associated with the Workload Manager or Helper modules: JobMatch An appropriate match between a job and a Computing Element has

been found. The event contains the identifier of the selected CE. JobPending A match between a job and a suitable Computing Element was not

found, so the job is kept pending by the WM. The event contains the reason why no match was found.

Events used to store special information in logging and bookkeeping services:

IST-2000-25182 PUBLIC 174 / 185


Doc. Identifier:


Date: 29/05/2003

JobRegister Logged by job creator (User Interface) in order to register the job with bookkeeping server.

JobChkpt An application-specific checkpoint was created (logged by checkpointing API). Checkpoint tag and ClassAd strings should be included.

JobListener Used by UI to store listener network port information for interactive jobs. Listener port number, hostname and service name (multiple ports can be advertised) are included.

JobCurJdl This optional event can be used to report ClassAd describing the current state of job processing (output from Helper modules).

More details on job event types can be found in [A4].

IST-2000-25182 PUBLIC 175 / 185


Doc. Identifier:


Date: 29/05/2003

8.4. SUBMISSION FAILURES ANALYSISAnalysis of failed job’s state can be carried out through the check of the consistency and completeness of the job related events returned by the edg-job-get-logging-info command. A further verification if needed, should be then performed on the retrieved output files produced by the jobs (if any) and through the inspection of the log files ad debugging information traced by the various system components.As explained in section 7.1.3.6 to get the logging information about a job you need to issue the following command:

edg-job-get-logging-info <job_Identifier>

Since the output of the command could be copious we advice usage of the –output option too to redirect it to a given file:

edg-job-get-logging-info –output <my_file> <job_Identifier>

Using the –full option allows then to get more detailed information (the job descriptions at the various stages are also included):

edg-job-get-logging-info –v 2 –output <my_file> <job_Identifier>

Before using the edg-job-get-logging-info command, it is in some cases useful a check to the edg-job-status output that can contain information about the cause of a job failure. As explained in section 7.1.3.5 to get the status information about a job you need to issue the following command:

edg-job-status <job_Identifier>

As said at the beginning of this section another way for analysing submission failures is to inspect the standard output and error of the job generated on the Worker Node and retrieved on the UI machine through the edg-job-get-output command. A typical example of errors that can be detected in this way is when the users submits a script that in turn tries to start enother script or an executable. E.g. the submitted scripts is like:

#!/bin/sh# Use the coincidence file to compare the meaurementscurdir=`pwd`${curdir}/lecture_new_gome_V2_sel1_PT_10idl appli.pro

Upon job abortion, the error message received through the OutputSandbox retrieval is:

IST-2000-25182 PUBLIC 176 / 185


Doc. Identifier:


Date: 29/05/2003

./demo_june: /home/eo004/3042/lecture_new_gome_V2_sel1_PT_10: Permission denied

The reason for this error is that globus-url-copy (used for the InputSanbox files staging) in general doesn't preserve the x flag so the script specified as Executable in the JDL (on which chmod +x is done automatically by the WP1 JobWrapper), should perform a chmod +x for all the executable files (lecture_new_gome_V2_sel1_PT_10 in this example) transferred within the InputSandbox of the job.

IST-2000-25182 PUBLIC 177 / 185


Doc. Identifier:


Date: 29/05/2003

8.5. WILDCARD PATTERNSThe wildcard patterns that can be included in the InputSandbox attribute expression are used by the UI to perform file name “globbing” in a fashion similar to the UNIX csh shell. The result of the “globbing” is a list of the files whose names match any of the specified patterns. The admitted special characters together with their meaning are listed hereafter:

- * wildcard for any string- ? wildcard for any single character- [chars ] delimits a wildcard matching any of the enclosed

characters. If chars contains a sequence of the form a-b then any character between a and b (inclusive) will match. Such an expression can be negated by means of the special character “!” ([!chars] matches any character not in chars).

EXAMPLESConsider a directory where “ls –F” gives:

1file a1.f apple.o bob.o h4374.f john.o2files ab apps/ foo.c h4374.o mydir/ABS ab.f bob foo.f john stuff/a1 apple.f bob.f gh john.f

That is to say some files and directories. The examples below show the way the mentioned wildcards are expanded (the notation => indicates the result of typing the command).

1) Every two letter file name:echo ?? => a1 ab gh

2) Every two character name starting with “a“:echo a? => a1 ab

3) Every file starting with j, o, h, or n:echo [john]* => h4374.f h4374.o john john.f john.o

4) Include a range, e.g. everything starting with an upper case letter or a digit: echo [A-Z0-9]* => 1file 2files ABS

5) Negate a range:

IST-2000-25182 PUBLIC 178 / 185


Doc. Identifier:


Date: 29/05/2003

echo [!john]*.f => a1.f ab.f apple.f bob.f foo.f

6) Every file starting in “a” and ending in .f: echo a*.f => a1.f ab.f apple.f

IST-2000-25182 PUBLIC 179 / 185


Doc. Identifier:


Date: 29/05/2003

8.6. THE MATCH MAKING ALGORITHMThe main task performed by the RB (aka Matchmaker) is to find the best suitable Computing Element where to execute the job. In order to accomplish this task the RB interacts with the other EDG components. More precisely, the Replica Location Service (RLS) and the GOUT/Information Index (II) are the two main components which supply the RB with all the information required for the actual resolution of the matches between job requirements and Computing Element capabilities (i.e. runtime environments, data access features, processing resources etc.). The following sections provide a description of the matchmaking algorithm performed by the RB. At this aim it is worth to identify three different scenarios to be dealt with separately: direct job submission, job submission without data-access requirements, job submission with data-access requirements.

8.6.1. Direct Job SubmissionThe simplest scenario is to consider the case where the JDL submitted by the UI contains a link to the resource to submit the job at, i.e. the Computing Element identifier (CEId). In this case the RB doesn’t perform any matchmaking algorithm at all, but simply the job is submitted to the specified CE.

Figure 3 - Submission with specified CEId

It should be pointed out that, if the CEId is specified then the RB neither checks whether the user who submitted the job is authorised to access the given CE, nor interacts with the RLS for the resolution of files requirements, if any. The only check performed by the RB is the JDL syntax one, while converting the JDL into a ClassAd.

8.6.2. Job submission without data-access requirementsLet’s do a little step onwards and consider the scenario where the user specifies a job with given execution requirements, but without data constraints. Once the JDL has been received by the RB and successfully converted into ClassAd (job-ad) the RB starts the actual match-making algorithm to find if the characteristics and status of Grid resources match the job requirements. The matchmaking algorithm consists of two different phases: requirements check and the rank computation.

IST-2000-25182 PUBLIC 180 / 185


Doc. Identifier:


Date: 29/05/2003

During the requirements check phase the RB contacts the GOUT/II in order to create a set of suitable CEs to execute the job at, thus compliant with user requirements and where the user is authorized to submit jobs, as well. Taking into account that all the CE attributes involved in the JDL requirements (defined by the user to express his/her needs) usually refers to “static” information, (such as operating system, installed software runtime environments, etc.), it is clear that all the information cached in the GOUT/II represent a good source for testing matches between job requirements and CE features. It is clearly more efficient than contacting each CE to find out the same information.

Figure 4 - Requirements checking phase

Once the RB has created the set of the suitable CEs where the job can be executed, the RB performs the second phase of the matchmaking algorithm, which allows the RB to acquire information about the “quality” of the just found suitable CEs. In the ranking phase the RB contacts directly the LDAP server (i.e the GRIS) of the involved CEs to obtain the values of those attributes appearing in the rank expression of the received JDL. It should be pointed out that conversely to the previous phase, it is better to contact each suitable CE, rather than using the GOUT/II as source of information, since the rank attributes usually refers to variables varying in time very frequently (i.e. FreeCPUs, FreeMemory).If there are two or more CEs with meet all the requirements and have the same best rank, then the CE is chosen among them in a random way (and all these CEs have the same probability to be chosen).Moreover, as explained in [A1], it is also possible to enable a “fuzzyness” in the matchmaking, by setting:

IST-2000-25182 PUBLIC 181 / 185


Doc. Identifier:


Date: 29/05/2003

FuzzyRank = true;

in the JDL expression. In this case the RB consider all the CEs meeting all the requirements, and among them the CE with the highest rank has the highest probability to be chosen.Rank computation is depicted in Figure 5.

Figure 5 – Rank computation phase

8.6.3. Job submission with data-access requirementsThe Resource Broker interacts with the WP2 Replica Management services in order to find out the most suitable Computing Element taking into account the Storage Elements where both input data sets are physically stored and output data sets should be staged on completion of job execution. Before describing the action taken by the RB upon reception of a JDL where both data-access and computing requirements are present, it is worth to recall the JDL attributes which represent a data requirement at the RB side: OutputSE, InputData and DataAccessProtocol, respectively representing the Storage Element (SE) where the output file should be staged, the input files (LFNs, GUIDs) required as input for the actual job execution and the protocol “spoken” by the application to access such files.The main two phases of the match making algorithm performed by the RB remain unchanged, but the RB executes the requirements check and ranking for each class of CEs

IST-2000-25182 PUBLIC 182 / 185


Doc. Identifier:


Date: 29/05/2003

satisfying the data-access requirements. Additionally, the RB performs a pre-match processing to find out and classify those CEs satisfying both data-access and user authorisation requirements.During the pre-match processing phase the RB contacts the RLS in order to resolve logical file names and collect all the information about SEs containing at least one input data file. This information will be used to write down the broker-info-file, which will be shipped, within the input sandbox, to the WN where the execution will take place. At this point the RB is ready to start the CEs classification procedure, during which the RB contacts the II/GOUT in order to find the CEs satisfying both the authorization requirements and having the OutputSE “close” to them. Using the information retrieved during the file name resolution, the RB classifies those CEs depending on the number of input files stored in storage element(s) which is (are) close to the CE itself and speak at least one of the protocols specified in the DataAccessProtocol JDL attribute.

Figure 6 - CEs classification procedure

Upon completion of the CE data classification, the RB is ready for the actual match making and starts the requirements checking phase for each CE belonging to the first non-empty class of CEs, which can access the highest number of distinguished files. If a CE doesn’t

IST-2000-25182 PUBLIC 183 / 185


Doc. Identifier:


Date: 29/05/2003

satisfy the user requirements it is removed from its class. The requirements checking phase is repeated until at least a CE matching the user requirement is found.Once the requirements checking phase is completed either the RB knows a set of CEs satisfying both data-access and computing requirements having access to the maximum number of distinguished input files, or there does not exist a suitable CE matching such requirements. In the first case the RB starts the ranking phase in order to find the best CE to which submitting the job.

Figure 7 - Match-Making algorithm

A special case is when the getaccesscost method has been specified as rank (see [A1]), i.e.:

Rank = other.DataAccessCost;

IST-2000-25182 PUBLIC 184 / 185


Doc. Identifier:


Date: 29/05/2003

in this case the CE is chosen among the CEs satisfying the no-data requirements (i.e. the ones specified in the Requirements JDL expression) and where the user is allowed to submit jobs, and the choice of the “best” CE among them is delegated to the getaccesscost function.

IST-2000-25182 PUBLIC 185 / 185

istituto nazionale di fisica...

Documents