v. 1.3 (rev. 3)
Installation Guide
11 August 2005
v. 1.3 (rev. 3)
Installation Guide
11 August 2005
Copyright © Members of the EGEE Collaboration.
2004.
See http://eu-egee.org/partners for details on the copyright holders.
EGEE (“Enabling Grids for EsciencE in Europe”) is a project funded by the European Union. For more information on the project,
its partners and contributors please see http://www/.eu-egee.org.
You are permitted to copy and distribute verbatim copies of this document
containing this copyright notice, but modifying this document is not allowed.
You are permitted to copy this document in whole or in part into other
documents if you attach the following reference to the copied elements:
“Copyright © 2004. Members of the EGEE Collaboration. http://www.eu-egee.org”
The information contained in this document represents the views of EGEE as of the date they are published. EGEE does not guarantee that any information contained herein is errorfree, or up to date.
EGEE MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, BY PUBLISHING THIS
DOCUMENT.
Table of Content
2.2. Standard Deployment Model
3. GLITE Packages AND doWNLOADS
4. The gLite Configuration Model
4.1. The gLite Configuration Scripts
4.2. The gLite Configuration Files
4.2.1. Configuration Parameters Scope
4.2.2. The Local Service Configuration Files
4.2.3. The Global Configuration File
4.2.4. The Site Configuration File
4.2.7. Default Environment Variables
4.2.8. Configuration Overrides
5.2. Installation Pre-requisites
5.3. Security Utilities Installation
5.4. Security Utilities Configuration
6. Information and Monitoring System (r-gma)
6.1.3. R-GMA deployment modules
6.1.4. R-GMA Deployment strategy
6.2. R-GMA Server deployment module
6.2.1. R-GMA Server deployment module overview
6.2.2. Installation Pre-requisites
6.2.3. R-GMA Server Installation
6.2.4. R-GMA Server Configuration
6.3. R-GMA Client deployment module
6.3.2. Installation Pre-requisites
6.3.3. R-GMA Client Installation
6.3.4. R-GMA Client Configuration
6.4. R-GMA servicetool deployment module
6.4.2. Installation Pre-requisites
6.4.3. R-GMA servicetool installation
6.4.4. R-GMA Servicetool Configuration
6.5. R-GMA GadgetIN (GIN) deployment module
6.5.2. Installation Pre-requisites
6.5.3. R-GMA GadgetIN installation
6.5.4. R-GMA GadgetIN Configuration
7.2. Installation Pre-requisites
7.3. Service Discovery Installation
7.4. SERVICE DISCOVERY Configuration
8. VOMS Server and Administration Tools
8.2. Installation Pre-requisites
8.4. VOMS Server Configuration
8.5. VOMS Administrators Registration
9. Logging and Bookkeeping Server
9.2. Installation Pre-requisites
9.4. Logging and Bookkeeping Server Installation
9.5. Logging and Bookeeping Server Configuration
9.6. Logging and Bookkeeping Configuration Walkthrough
9.8. Starting the LB Services at Boot
9.9. Publishing LB Services to R-GMA
10.2. Installation Pre-requisites
10.3. WORKLOAD MANAGER SYSTEM Installation
10.4. WORKLOAD MANAGEMENT SYSTEM Configuration
10.5. WORKLOAD MANAGEMENT SYSTEM Configuration Walkthrough
10.6. Managing the WMS Services
10.7. Starting the WMS Services at Boot
10.8. Publishing WMS Services to R-GMA
11. The torque Resource Manager
11.1.1. TORQUE Server Overview
11.1.2. TORQUE Client Overview
11.2. Installation Pre-requisites
11.3.1. TORQUE Server Installation
11.3.2. TORQUE Server Service Configuration
13.1.1. TORQUE Server Configuration Walkthrough
13.1.2. Managing the TORQUE Server Service
13.2.1. TORQUE Client Installation
13.2.2. TORQUE Client Configuration
13.2.3. TORQUE Client Configuration Walkthrough
13.2.4. Managing the TORQUE Client
14.2. Installation Pre-requisites
14.2.3. Resource Management System
14.3. Computing Element Service Installation.
14.4. Computing Element Service Configuration
14.5. Computing Element Configuration Walkthrough
14.6. Managing the CE Services
14.7. Starting the CE Services at Boot
14.8. Workspace Service Tech-Preview
15.2. Installation Pre-requisites
15.2.3. Resource Management System
15.3. Worker Node Installation
15.4. Worker Node Configuration
16.2. Installation Pre-requisites
16.3. Single Catalog Installation
16.4. Single Catalog Configuration
16.5. Single Catalog Configuration Walkthrough
16.6. Publishing Catalog Services to R-GMA
17. FILE Transfer Service ORACLE
17.2. Installation Pre-requisites
17.2.4. Oracle Database Configuration
17.3.1. File Transfer Service Installation
17.3.2. File Transfer Service ORACLE Configuration
17.3.3. FILE Transfer Service ORACLE Configuration Walkthrough
17.3.4. Publishing FILE TRANSFER Services to R-GMA
17.4.2. Installation pre-requisites
17.4.3. File Transfer Client installation
17.4.4. File Transfer Client Configuration
18.2. Data Transfer Agents Installation
18.3. Data Transfer Agents Oracle Configuration
18.4. Data Transfer Agents ORACLE Configuration Walkthrough
19. FILE Placement Service ORACLE
19.2. Installation Pre-requisites
19.2.4. Oracle Database Configuration
19.3.1. File Placement Service Installation
19.3.2. File Placement Service ORACLE Configuration
19.3.3. FILE Placement Service ORACLE Configuration Walkthrough
19.3.4. Publishing File Placement Services to R-GMA
19.4.2. Installation pre-requisites
19.4.3. File Placement Client installation
19.4.4. File Placement Client Configuration
20.2. Installation Pre-requisites
20.3. Metadata Catalog Installation
20.4. Metadata Catalog Configuration
20.5. Metadata Catalog Configuration Walkthrough
21.1.2. Installation pre-requisites
21.1.3. gLite I/O Server installation
21.1.4. gLite I/O Server Configuration
21.1.5. gLite I/O Server Configuration Walkthrough
21.2.2. Installation pre-requisites
21.2.3. gLite I/O Client installation
21.2.4. gLite I/O Client Configuration
22.2. Installation Pre-requisites
22.5. Configuration for the UI users
23. The gLite Functional Test Suites
23.2.1. Test suite description
23.2.2. Installation Pre-requisites
23.3.1. Test suite description
23.3.2. Installation Pre-requisites
23.4.1. Test suite description
23.4.2. Installation Pre-requisites
23.5. WMS validation test suite
23.5.1. Test suite description
23.5.2. Installation Pre-requisites
23.6.1. Test suite description
23.6.2. Installation Pre-requisites
24. Appendix A: Service Configuration File Example
25. Appendix B: Site Configuration File Example
This document describes how to install and configure the EGEE middleware known as gLite. The objective is to provide clear instructions for administrators on how to deploy gLite components on machines at their site.
Glossary
|
CE |
Computing Element |
|
FTA |
File Transfer Agents |
|
FTS |
File Transfer Service |
|
LB |
Logging and Bookkeping |
|
R-GMA |
Relational Grid Monitoring Architecture |
|
SC |
Single Catalog |
|
SD |
Service Discovery |
|
UI |
User Interface |
|
VOMS |
Virtual Organization Membership Service |
|
WMS |
Workload Management System |
|
WN |
Worker Node |
Definitions
|
Service |
A single high-level unit of functionality |
|
Node |
A computer where one or more services are deployed |
The gLite middleware is a Service Oriented Grid middleware providing services for managing distributed computing and storage resources and the required security, auditing and information services.
The gLite system is composed of a number of high level services that can be installed on individual dedicated computers (nodes) or combined in various ways to satisfy site requirements. This installation guide follows a standard deployment model whereby most of the services are installed on dedicated computers. However, other examples of valid node configuration are also shown.
The following high-level services are part of this release of the gLite middleware:
Figure 1 shows the standard deployment model for these services. Each site has to provide the local services for job and data management as well as information and monitoring:
Figure 1: gLite Service Deployment Scenario
The figure shows the proposed mapping of services onto physical machines. This mapping will give the best performance and service resilience. Smaller sites may however consider mapping multiple services onto the same machine. This is in particular true for the CE and package manager and for the SC and the LTS.
Instead of the distributed deployment of the catalogs (a local catalog and a global catalog) a centralized deployment of just a global catalog can be considered as well. This is actually the configuration supported in the gLite 1.2.
The VO services act on the Grid level and comprise the Security services, Workload Management services, Information and Monitoring services. Each VO should have an instance of these services, physical service instances can mostly be shared among VOs. For some services, even multiple instances per VO can be provided as indicated below:
· Security services
o The Virtual Organization Membership Service (VOMS) is used for managing the membership and member rights within a VO. VOMS also acts as attribute authority.
o myProxy is used as secure proxy store
· Workload Management services
o The Workload Management Service (WMS) is used to submit jobs to the Grid.
o The Logging and Bookkeeping service (LB) keeps track of the job status information.
The WMS and the LB can be deployed independently but due to their tight interactions it is recommended to deploy them together. Multiple instances of these services may be provided for a VO.
· Information and Monitoring services
o The R-GMA Registry Servers and Schema Server are used for binding information consumers and producers. There can be more than one Registry Server that can be replicated for resilience reasons.
· Single Catalog (SC)
o The single catalog is used for browsing the LFN space and to find out the location (sites) where files are stored. This is in particular need by the WMS.
· User Interface
o The User Interface (UI) combines all the clients that allow the user to directly interact with the Grid services.
In the rest of this guide, installation instructions for the individual modules are presented. The order of chapters represents the suggested installation order for setting up a gLite grid.
The gLite middleware is currently published in the form of RPM packages and installation scripts from the gLite web site at:
../../../../../../glite-web/egee/packages
Required external dependencies in RPM format can also be obtained from the gLite project web site at:
../../../../../../glite-web/egee/packages/externals/bin/rhel30/RPMS
Deployment modules for each high-level gLite component are provided on the web site and are a straightforward way of downloading and installing all the RPMs for a given component. A configuration script is provided with each module to configure, deploy and start the service or services in each high-level module.
Installation and configuration of the gLite services are kept well separated. Therefore the RPMS required to install each service or node can be deployed on the target computers in any suitable way. The use of dedicated RPMS management tools is actually recommended for production environments. Once the RPMS are installed, it is possible to run the configuration scripts to initialize the environment and the services.
gLite is also distributed using the APT package manager. More details on the apt cache address and the required list entries can be found on the main packages page of the gLite web site (../../../../../../glite-web/egee/packages/APT.asp).
gLite is also available in the form of source and binary tarballs from the gLite web site and from the EGEE CVS server at:
jra1mw.cvs.cern.ch:/cvs/jra1mw
The server support authenticated ssh protocol 1 and Kerberos 4 access and anonymous pserver access (username: anonymous).
Each gLite deployment module contains a number of RPMS for the necessary internal and external components that make up a service or node (RPMS that are normally part of standard Linux distributions are not included in the gLite installer scripts). In addition, each module contains one or more configuration RPMS providing configuration scripts and files.
Each module contains at least the following configuration RPMS:
|
Name |
Definition |
|
glite-config-x.y.z-r.noarch.rpm |
The glite-config RPM contains the global configuration files and scripts required by all gLite modules |
|
glite-<service>-config-x.y.z-r.noarch.rpm |
The glite-<service>-config RPM contains the configuration files and scripts required by a particular service, such as ce, wms or rgma |
In addition, a mechanism to load remote configuration files from URLs is provided. Refer to the Site Configuration section later in this chapter (4.2.4).
All configuration scripts are installed in:
$GLITE_LOCATION/etc/config/scripts
where $GLITE_LOCATION is the root of the gLite packages installation. The default setting is
$GLITE_LOCATION = /opt/glite.
The scripts are written in python and follow a naming convention. Each file is called:
glite-<service>-config.py
where <service> is the name of the service they can configure.
In addition, the same scripts directory contains the gLite Installer library (gLiteInstallerLib.py) and a number of helper scripts used to configure various applications required by the gLite services (globus.py, mysql.py, tomcat.py, etc).
The gLite Installer library and the helper scripts are contained in the glite-config RPM. All service scripts are contained in the respective glite-<service>-config RPM.
All scripts have a number of command line switches to perform different actions. The usage instructions can be printed on screen with the command:
glite-<service>-config.py --help
The configuration steps for all services and clients, except the User Interface, are executed by running the command:
glite-<service>-config.py --configure
The services and daemons are started and stopped with:
glite-<service>-config.py --start
glite-<service>-config.py --stop
The status of the services and daemons can be verified with:
glite-<service>-config.py --status
The status switch causes a few status lines to be printed on screen and return 0 if all services are running and 1 if at least one service is not running.
Individual scripts may have additional options.
The User Interface script does not have a --configure switch. Running the command
glite-ui-config.py
by itself configures the user interface and its various clients and tools.
All parameters in the gLite configuration files are categorised in one of three categories:
The gLite configuration files are XML-encoded files containing all the parameters required to configure the gLite services. The configuration files are distributed as templates and are installed in the $GLITE_LOCATION/etc/config/templates directory.
The configuration files follow a similar naming convention as the scripts. Each file is called:
glite-<service>.cfg.xml
Each gLite configuration file contains a global section called <parameters/> and may contain one or more <instance/> sections in case multiple instances of the same service or client can be configured and started on the same node (see the configuration file example in Appendix A). In case multiple instances can be defined for a service, the global <parameters/> section applies to all instances of the service or client, while the parameters in each <instance/> section are specific to particular named instance and can override the values in the <parameters/> section.
The configuration files support variable substitution. The values can be expressed in term of other configuration parameters or environment variables by using the ${} notation (for example ${GLITE_LOCATION}).
The templates directory can also contain additional service templates used by the configuration scripts during their execution (like for example the gLite I/O service templates).
Note: When using a local configuration model, before running the configuration scripts the corresponding configuration files must be copied from the templates directory to $GLITE_LOCATION/etc/config and all the user-defined parameters must be correctly instantiated (refer also to the Configuration Parameters Scope paragraph later in this section). This is not necessary if using the site configuration model (see below)
The global configuration file glite-global.cfg.xml contains all parameters that have gLite-wide scope and are applicable to all gLite services. The parameters in this file are loaded first by the configuration scripts and cannot be overridden by individual service configuration files.
Currently the global configuration file defines the following parameters:
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
site.config.url |
|
The URL of the Site Configuration file for this node. The values defined in the Site Configuration file are applied first and are be overridden by values specified in the local configuration files. Leave this parameter empty or remove it to use local configuration only. |
|
Advanced Parameters |
||
|
GLITE_LOCATION |
/opt/glite |
|
|
GLITE_LOCATION_VAR |
/var/glite |
|
|
GLITE_LOCATION_LOG |
/var/log/glite |
|
|
GLITE_LOCATION_TMP |
/tmp/glite |
|
|
GLOBUS_LOCATION |
/opt/globus |
Environment variable pointing to the Globus package. |
|
GPT_LOCATION |
/opt/gpt |
Environment variable pointing to the GPT package. |
|
JAVA_HOME |
/usr/java/j2sdk1.4.2_08 |
Environment variable pointing to the SUN Java JRE or J2SE package. |
|
CATALINA_HOME |
/var/lib/tomcat5 |
Environment variable pointing to the Jakarta Tomcat package |
|
host.certificate.file |
/etc/grid-security/hostcert.pem |
The host certificate (public key) file location |
|
host.key.file |
/etc/grid-security/hostkey.pem |
The host certificate (private key) file location |
|
ca.certificates.dir |
/etc/grid-security/certificates |
The location where CA certificates are stored |
|
user.certificate.path |
.certs |
The location of the user certificates relative to the user home directory |
|
host.gridmapfile |
/etc/grid-security/grid-mapfile |
Location of the grid mapfile |
|
host.gridmap.dir |
/etc/grid-security/gridmapdir |
The location of the account lease information for dynamic allocation |
|
host.groupmapfile |
/etc/grid-security/groupmapfile |
Location
of the groupmapfile |
|
host.groupmap.dir |
/etc/grid-security/groupmapdir |
The
location of the group lease information for dynamic allocation |
|
X509_VOMS_DIR |
/etc/grid-security/vomsdir |
The
directory when VOMS Server certificates are stored.
[Example=/etc/grid-security/vomsdir][Type='string'] |
|
System Parameters |
||
|
installer.export.filename |
/etc/glite/profile.d/glite_setenv.sh |
Full path of the script containing environment definitions This file is automatically generated by the configuration script. If it exists, the new values are appended |
|
modify.user.env |
true |
If this parameter is set to true, the user environment files are modified to source the glite_setenv.sh script. Otherwise no modification is done. Possible values are true or false. Default is true [NEW IN 1.2] |
|
tomcat.user.name |
tomcat4 |
Name of the user account used to run tomcat. |
|
tomcat.user.group |
tomcat4 |
Group of the user specified in the parameter ‘tomcat.user.name’ |
Table 1: Global Configuration Parameters
All gLite configuration scripts implement a mechanism to load configuration information from a remote URL. This mechanism can be used to configure the services from a central location for example to propagate site-wide configuration.
The URL of the configuration file can be specified as the site.config.url parameter in the global configuration file of each node or as a command-line parameter when launching a configuration script, for example:
glite-ce-config.py --siteconfig=http://server.domain.com/sitename/siteconfig.xml
In the latter case, the site configuration file is only used for running the configuration scripts once and all values are discarded afterwards. For normal operations it is necessary to specify the site configuration URL in the glite-gobal.cfg.xml file.
The site configuration file can contain a global section called <parameters/> and one <node/> section for each node to be remotely configured (see the configuration file example in Appendix B). Each <node/> section must be qualified with the host name of the target node, for example:
<node name=”lxb1428.cern.ch”>
…
</node>
where the host name must be the value of the $HOSTNAME environment variable on the node. The <parameters/> section contains parameters that apply to all nodes referencing the site configuration file.
The <node/> sections can contain the same parameters that are defined in the local configuration files. If more than one service is installed on a node, the corresponding <node/> section can contain a combination of all parameters of the individual configuration files. For example if a node runs both the WMS and the LB Server services, then the corresponding <node/> section in the site configuration file may contain a combination of the parameters contained in the local configuration files for the WMS and the LB Server modules.
If a user-defined parameter is defined in the site configuration file, the same parameter doesn’t need to be defined in the local file (it can therefore keep the token value ‘changeme’ or be removed altogether). However, if a parameter is defined in the local configuration file, it overrides whatever value is specified in the site configuration file. If a site configuration file contains all necessary values to configure a node, it is not necessary to create the local configuration files. The only configuration file that must always be present locally in the /opt/glite/etc/config/ directory is the glite-global.cfg.xml file, since it contains the parameter that specify the URL of the site configuration file.
This mechanism allows distributing a site configuration for all nodes and at the same time gives the possibility of overriding some or all parameters locally in case of need.
New configuration information can be easily propagated simply by publishing a new configuration file and rerunning the service configuration scripts.
In addition, several different models are possible. Instead of having a single configuration file contains all parameters for all nodes, it’s possible for example to split the parameters in several file according to specific criteria and point different services to different files. For example is possible to put all parameters required to configure the Worker Nodes in one file and all parameters for the servers in a separate files, or have a separate file for each node and so on.
Several configuration files can also be managed as a single file by using the XML inclusion mechanism. Using this standard mechanism, it is possible to include by reference one or more files in a master file and point the gLite services configuration scripts to the master file. In order to use this mechanism, the <siteconfig> tag in the master file must be qualified with the XInclude namespace as follows:
<siteconfig xmlns:xi="http://www.w3.org/2001/XInclude">
The individual files can then be included using the tag:
<xi:include href="glite-xxx.cfg.xml" />
where the value of the href attribute is a file path relative to the location of the master file. The content of the referenced file is included “as-is” in the master document when it is downloaded from the web server. The gLite service gets a single XML file where all the <xi:include> tags are replaced with the content of the referenced files.
The configuration scripts and files described above represent the common configuration interfaces of all gLite services. However, since the gLite middleware is a combination of various old and new services, not all services can natively use the common configuration model. Many service come with their configuration files and formats. Extensive work is being done to make all services use the same model, but until the migration is completed, the common configuration files must be considered as the public configuration interfaces for the system. The configuration scripts do all the necessary work to map the parameters in the public configuration files to parameters in service specific configuration files. In addition, many of the internal configuration files are dynamically created or modified by the public configuration scripts.
The goal is to provide the users with a consistent set of files and scripts that will not change in the future even if the internal behaviour may change. It is therefore recommended whenever possible to use only the common configuration files and scripts and do not modify directly the internal service specific configuration files.
When any gLite configuration script is run, it creates or modifies a general configuration file called glite_setenv.sh (and glite_setenv.csh) in /etc/glite/profile.d (the location can be changed using a system-level parameter in the global configuration file).
This file contains all the environment definitions needed to run the gLite services. This file is automatically added to the .bashrc file of users under direct control of the middleware, such as service accounts and pool accounts. In addition, if needed the .bash_profile file of the accounts is modified to source the .bashrc file and to set BASH_ENV=.bashrc. The proper environment is therefore created every time an account logins in various ways (interactive, non-interactive or script).
Other users not under control of the middleware can manually source the glite_setenv.sh file as required.
In case a gLite service or client is installed using a non-privileged user (if foreseen by the service or client installation), the glite_setenv.sh file is created in $GLITE_LOCATION/etc/profile.d.
By default the gLite configuration files and scripts define the following environment variables:
|
GLITE_LOCATION |
/opt/glite |
|
GLITE_LOCATION_VAR |
/var/glite |
|
GLITE_LOCATION_LOG |
/var/log/glite |
|
GLITE_LOCATION_TMP |
/tpm/glite |
|
PATH |
/opt/glite/bin:/opt/glite/externals/bin:$PATH |
|
LD_LIBRARY_PATH |
/opt/glite/lib:/opt/glite/externals/lib:$LD_LIBRARY_PATH |
The first four variables can be modified in the global configuration file or exported manually before running the configuration scripts. If these variables are already defined in the environment they take priority on the values defined in the configuration files
It is possible to override the values of the parameters in the gLite configuration files by setting appropriate key/value pairs in the following files:
/etc/glite/glite.conf
~/.glite/glite.conf
The first file has system-wide scope, while the second has user-scope. These files are read by the configuration scripts before the common configuration files and their values take priority on the values defined in the common configuration files.
The gLite Security Utilities module contains the CA Certificates distributed by the EU Grid PMA. In addition, it contains a number of utilities scripts needed to create or update the local grid mapfile from a VOMS server and periodically update the CA Certificate Revocation Lists. This module is presented first, since it is used by almost all other modules. However, it is not normally installed manually by itself, but automatically as part of the other modules.
The CA Certificate are installed in the default directory
/etc/grid-security/certificates
This is not configurable at the moment. The installation script downloads the latest available version of the CA RPMS from the gLite software repository.
The glite-mkgridmap script is used to update the local grid mapfile and its configuration file glite-mkgridmap.conf are installed respectively in
$GLITE_LOCATION/sbin
and
$GLITE_LOCATION/etc
The script is normally run automatically for all services that need it (defined by setting the install.mkgridmap.cron parameter to true in the service configuration file). It can also be run manually of course. However, running glite-mkgridmap doesn’t preserve the existing grid-mapfile. However, a wrapper script is provided in
$GLITE_LOCATION/etc/config/scripts/mkgridmap.py
to update the grid-mapfile preserving any additional entry in the file not downloaded by glite-mkgridmap.
The Security Utilities module configuration script also installs a crontab file in /etc/cron.d that executes the mkgridmap.py script every night at 02:00. The installation of this cron job and the execution of the mkgridmap.py script during the configuration are optional and can be enabled using the provided configuration parameter (see the configuration walkthrough for more information).
Some services need to run the mkgridmap.py script as part of their initial configuration (this is currently the case for example of the WMS). In this case the installation of the cron job and execution of the script at configuration must be enabled. This is indicated in each case in the appropriate chapter.
The fetch-crl script is used to update the CA Certificate Revocation Lists. This script is provided by the EU GridPMA organization. It is installed in:
/usr/bin
The Security Utilities module configuration script installs a crontab file in /etc/cron.d that executes the glite-fetch-crl every four hours. The CRLs are installed in the same directory as the CA certificates, /etc/grid-security/certificates. The module configuration file (glite-security-utils.cfg.xml) allows specifying an e-mail address to which the errors generated when running the cron job are sent.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The gLite Security Utilities module is normally not installed by itself, but as part of another module. However, in case the functionality provided by this module is required separately from the other gLite modules, it is possible to install it as follows:
1. Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite Security Utility by executing
apt-get install glite-security-utils-config
2. Installation via gLite installer scripts
a. Download from the gLite web site the latest version of the the gLite Security Utilities installation script glite-security-utils_installer.sh. Make the file executable (chmod u+x glite-security-utils_installer.sh) and execute it.
b. Run the installation script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-security-utils next to the installation script and the installation procedure is started. If some RPMS are already installed, they upgraded if necessary. Check the screen output for errors or warnings.
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
CA Certificates in /etc/grid-security/certificates
The fetch.crl and mkgridmap cron jobs are installed in /etc/cron.d (depending on the selected options).
The security utils configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-security-utils -config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
As the module is normally not installed manually by itself, but automatically as part of the other modules, you will only need to do steps 1 to 3. Step 4 and 5 are only required if you have installed the module standalone yourself – otherwise these steps are executed automatically by the module that uses the security utils module.
cd /opt/glite/etc/config
cp templates/* .
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-security-utils.cfg.xml contains the security utils related configuration values. Table 2 It shows the list of parameters that can be set.
Note: Step 1, 2 and 3 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
cd /opt/glite/etc/config/scripts
./glite-rgma-server-config.py
|
Parameter |
Default value |
Description |
|
|
User-defined Parameters |
|||
|
cron.mailto |
|
E-mail address to which the stderr of the installed cron jobs is sent |
|
|
Advanced Parameters |
|||
|
glite.installer.verbose |
True |
Produce verbose output when running the script |
|
|
glite.installer.checkcerts |
True |
Activate a check for host certificates and stop the script if not available. The certificates are looked for in the location specified by the global parameters host.certificate.file and host.key.file |
|
|
fetch-crl.cron.tab |
00 */4 * * *
|
The cron tab to use for the fetch-crl cron job. |
|
|
install.fetch-crl.cron |
True |
Install the glite-fetch-crl cron job. Possible values are 'true' (install the cron job) or 'false' (do not install the cron job) |
|
|
install.mkgridmap.cron |
False |
Install the glite-mkgridmap cron job. Possible values are 'true' (install the cron job) or 'false' (do not install the cron job) |
|
|
mkgridmap.cron.tab |
15 */4 * * * |
The cron tab to use for the mkgridmap cron job |
|
|
mkgridmap.script |
${GLITE_LOCATION}/sbin/glite-mkgridmap |
The full path of the mkgridmap script. [NEW IN 1.2] |
|
|
mkgridmap.conf |
${GLITE_LOCATION}/etc/glite-mkgridmap.conf |
The full path of the mkgridmap config file. [NEW IN 1.2] |
|
|
System Parameters |
|||
Table 2: Security Utilities Configuration Parameters
The R-GMA (Relational Grid Monitoring Architecture) is the Information and Monitoring Service of gLite. It is based on the Grid Monitoring Architecture (GMA) from the Grid Global Forum (GGF), which is a simple Consumer-Producer model that models the information infrastructure of a Grid as a set of consumers (that request information), producers (that provide information) and a central registry which mediates the communication between producers and consumers. R-GMA offers a global view of the information as if each Virtual Organisation had one large relational database.
Producers contact the registry to announce their intention to publish data, and consumers contact the registry to identify producers, which can provide the data they require. The data itself passes directly from the producer to the consumer: it does not pass through the registry.
R-GMA adds a standard query language (a subset of SQL) to the GMA model, so consumers issue SQL queries and receive tuples (database rows) published by producers, in reply. R-GMA also ensures that all tuples carry a time-stamp, so that monitoring systems, which require time-sequenced data, are inherently supported.
The gLite R-GMA Server is normally the first module installed as part of a gLite grid, since all services require it to publish service information.
The R-GMA Server is divided into four components:
The client part of R-GMA contains the producer and consumers of information. There is one generic client and a set of four specialized clients to deal with a certain type of information:
Client to make the data from the R-GMA site-publisher, servicetool and GIN constantly available. By default the glue and service tables are archived, however this can be configured.
Figure 2 gives an overview of the R-GMA
architecture and the distribution of the different
R-GMA components.
Figure 2 R-GMA components
In order to facilitate the installation of the information system R-GMA, the different components of the server and clients have been combined into one R-GMA server deployment module and several client sub-deployment modules that are automatically installed together with the corresponding gLite deployment modules that use them. Table 1 gives a list of R-GMA deployment modules, their content and/or the list of gLite deployment modules that install/use them.
|
Deployment module |
Contains |
Used / included by |
|
R-GMA server |
R-GMA server R-GMA registry server R-GMA schema server R-GMA browser R-GMA site publisher R-GMA data archiver R-GMA servicetool |
|
|
R-GMA client |
RGMA client APIs |
User Interface (UI) Worker Node (WN) |
|
R-GMA servicetool |
R-GMA servicetool |
Computing Element (CE) File Transfer Service (Oracle) Data Single Catalog (MySQL) Data Single Catalog (Oracle) I/O-Server Logging & Bookkeeping (LB) R-GMA server Torque Server VOMS Server Workload Management System (WMS) |
|
R-GMA GIN |
R-GMA GadgetIN |
Computing Element (CE) |
Table 3: R-GMA deployment modules
In order to use the information system R-GMA, you first have to install the R-GMA server on one node. If you want, you can install further R-GMA servers on other nodes. The following rules have to be taken into account when installing a single or multiple servers and enabling/disabling the different options of the server(s):
Next, you can install the different services, e.g. the Computing Element. All necessary R-GMA components needed by a service are automatically downloaded and installed together with the service. You will only need to configure the corresponding parts of R-GMA by modifying the corresponding configuration files accordingly.
There is one
common R-GMA configuration file (glite-rgma-common.cfg.xml) that is used
by all R-GMA components to handle common R-GMA settings and that is shipped
with each
R-GMA component. In addition, each R-GMA component comes with its own
configuration file (see the following sections for details).
The R-GMA server is the central server of the R-GMA service infrastructure. It contains the four R-GMA server parts – server, schema, registry and browser (see section 6.1.1) as well as the R-GMA clients – R-GMA servicetool, site publisher and data archiver (see section 6.1.2):
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The R-GMA server needs the list of Certificate Authorities as well as a host certificate:
A special security module called glite-security-utils (gLite Security Utilities) is installed and configured automatically when installing and configuring the R-GMA Server (refer to Chapter 5 for more information about the Security Utilities module). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl, glite-mkgridmap and mkgridmap.py scripts and sets up cron jobs that periodically check for updated revocation lists and grid-mapfile entries if required).
The Java JRE or JDK are required to run the R-GMA Server. This release requires v. 1.4.2 revision 08. The JDK/JRE version to be used is a parameter in the gLite global configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
It is possible to install the R-GMA server as follows:
1. Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite R-GMA server by executing
apt-get install glite-rgma-server-config
2. Installation via gLite installer scripts
1. Download the latest version of the R-GMA server installation script
glite-rgma-server_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
2. Make the script executable
chmod u+x glite-rgma-server_installer.sh
and execute it or execute it with
sh glite-rgma-server_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
This will the following deployment modules:
· R-GMA server
· R-GMA servicetool (see section 6.4 for details)
· Security utils (see chapter 5 for details)
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite
($GLITE_LOCATION)
gLite-essentials- java in $GLITE_LOCATION/externals/share
MySQL-server in /usr
MySQL-client in /usr
Tomcat in /var/lib/tomcat5
The gLite R-GMA server configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-rgma-server-config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
cd /opt/glite/etc/config
cp templates/* .
For the configuration of the R-GMA server you don’t need the
configuration file
glite-rgma-servicetool-serviceName.cfg.xml that is installed together
with the R-GMA server as part of the R-GMA servicetool. You can either delete
it from the present directory or ignore it in the following instructions as it
will not be taken into account.
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-rgma-common.cfg.xml contains the common R-GMA configuration values.Table 4 shows the configuration values that can be set.
· The file glite-rgma-server.cfg.xml contains the R-GMA server specific configuration values. Table 5 shows the configuration values that can be set.
· The file glite-rgma-servicetool.cfg.xml contains the R-GMA servicetool specific configuration values. Refer to Table 7 for the list of parameters that can be set and section 6.4 for the description of the R-GMA servicetool.
· The file glite-security-utils.cfg.xml contains the security utils specific configuration values. Refer to Table 2 for the list of parameters and section 5 for the description of the security utils.
Again, the glite-rgma-servicetool-serviceName.cfg.xml that is installed together with the R-GMA server as part of the R-GMA servicetool is not needed and can be either deleted or ignored.
|
Parameter |
Default value |
Description |
|
User-defined parameters |
||
|
rgma.server.hostname |
|
Hostname of the R-GMA server. [Type: ‘string’] |
|
rgma.schema.hostname |
|
Host name of the R-GMA schema service. [Type: ‘string’] Example: lxb1420.cern.ch (See also configuration parameter ‘rgma.server.run_schema_service’ in the R-GMA server configuration file in case you install a server) |
|
rgma.registry.hostname |
|
Host name(s) of the R-GMA registry service. You must specify at least one and you can specify several if you want to use several registries. This is an array parameter. [Type: ‘string’] Example: lxb1420.cern.ch (See also configuration parameter ‘rgma.server.run_registry_service’ in the R-GMA server configuration file in case you install a server). |
|
Advanced Parameters |
||
|
rgma.secure.mode |
true |
Run R-GMA clients in secure mode (true|false). If you want to run the R-GMA clients in unsecure mode, make sure the R-GMA server is able to accept requests on the unsecure port by setting the corresponding 'allow.unsecure.port' to 'true' in the R-GMA server configuration. [Type: ‘boolean’] Example: true |
|
System Parameters |
||
|
rgma.user.name |
rgma |
Name of the user account used to run the R-GMA gLite services. [Type: ‘string’] Example: rgma |
|
rgma.user.group |
rgma |
Group of the user specified in the parameter ‘rgma.user.name’. [Type: ‘string’] Example: rgma |
Table 4: R-GMA common configuration parameters
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
rgma.server. |
|
MySQL root password. [Type: ‘string’] Example: verySecret |
|
rgma.server. |
|
Run a schema server by yourself (yes|no). If you want to run it on your machine set ‘yes’ and set the parameter ‘rgma.schema.hostname’ to the hostname of your machine otherwise set it to ‘no’ and set the ‘rgma.schema.hostname’ to the host name of the schema server you want to use. [Type: ‘string’] Example: yes |
|
rgma.server.
|
|
Run a registry server by yourself (yes|no). If you want to run it on your machine set ‘yes’ and add your hostname to the parameter list ‘rgma.registry.hostname’ otherwise set it to ‘no’. [Type: ‘string’] Example: yes |
|
rgma.server.
|
|
Run an R-GMA browser (yes|no). Running a browser is optional but useful. [Type: ‘string’] Example: yes |
|
rgma.server. |
|
Run the R-GMA data archiver (yes|no). Running an
archiver makes the data from the site-publisher, servicetool and GadgetIN
constantly available. If you turn on this option, by default the glue and
service tables are archived. To change the archiving behaviour, you have to
create/change the archiver configuration file and point the parameter
‘rgma.server. Example: yes |
|
rgma.server. |
|
Run the R-GMA site-publisher (yes|no). Running the site-publisher publishes your site to R-GMA. [Type: ‘string’] Example: yes |
|
rgma.site-publisher. |
|
Contact email address of the site system administrator.
[Type: ‘string’] Example: systemAdministrator@mysite.com |
|
rgma.site-publisher. |
|
Contact email address of the user support.
[Type: ‘string’] Example: userSupport@mysite.com |
|
rgma.site-publisher. |
|
Contact email address of the site security responsible. Example: security@mysite.com |
|
rgma.site-publisher. |
|
Latitude of your site. Please go to 'http://www.multimap.com/' to find the correct value for your site. [Type: ‘Float’] Example: 46.2341 |
|
rgma.site-publisher. |
|
Longitude of your site. Please go to 'http://www.multimap.com/' to find the correct value for your site. [Type: ‘Float’] Example: 6.0447 |
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output. [Type: ‘boolean’] Example : true |
|
rgma.server.
|
1000 |
Maximum number of threads that are created for the tomcat http connector to process requests. This, in turn specifies the maximum number of concurrent requests that the connector can handle. [Type: ‘integer’] Example: 1000 |
|
rgma.server. |
true |
Set to true if you want calls to request.getRemoteHost() to perform DNS lookups in order to return the actual host name of the remote client. Set to false to skip the DNS lookup and return the IP address in String form instead (thereby improving performance). [Type: ‘boolean’] Example: true |
allow.unsecure.port |
false |
Enable using the unsecure port 8080. It can be true or false. [Type: ‘boolean’] Example: false |
|
rgma.site-publisher. |
${HOSTNAME} |
Hostname of the site. It has to be a DNS entry owned by the site and does not have to be shared with another site (i.e it uniquely identifies the site). It normally defaults to the DNS name of the R-GMA Server running the Site Publisher service. [Type: ‘string’] Example: lxb1420.cern.ch |
|
rgma.server. |
${GLITE_LOCATION}/etc/rgma-flexible-archiver/glue-config.props |
Configuration file to be used
to setup the flexible-archiver database to select which tables are supposed to be backuped. By
default, the glue and service tables are selected. (See also parameter
‘rgma.server. [Type: ‘string’] Example: '/my/path/my_config_file.props' |
|
System Parameters |
||
|
rgma.server.
|
R-GMA |
Path under which R-GMA server should be deployed. [Type: ‘string’] Example: R-GMA |
|
rgma.server. |
R-GMA.war |
Name of war file for R-GMA server. [Type: ‘string’] Example: R-GMA.war |
Table 5: R-GMA server Configuration Parameters
Note: Step 1,2 and 3 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
cd /opt/glite/etc/config/scripts
./glite-rgma-server-config.py --configure
Running the configuration script will automatically configure the security utils as well as the R-GMA servicetool so there is no need to run these configuration scripts as well.
Check if any error message is displayed and if necessary fix the parameters values and restart the script. If the configuration is successful you should see at the end the message:
The gLite R-GMA Server was successfully configured.
./glite-rgma-server-config.py --start
Check if any error message is displayed and if necessary fix the parameters values and restart the script.
./glite-rgma-server-config.py --status
or by connecting to the R-GMA Browser with your Internet browser at the address
https://your.host.name:8443/R-GMA/
In the browser you should see the different R-GMA services and 1 site (if you enabled the site publisher) registered.
The R-GMA Server is completely configured and running.
The R-GMA Client module is a set of client API in C, C++, Java and Python to access the information and monitoring functionality of the R-GMA system. The client is automatically installed as part of the User Interface and Worker Node.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils (gLite Security Utilities) is installed and configured automatically when installing and configuring the R-GMA Client (refer to Chapter 15 for more information about the Security Utilities module). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl, glite-mkgridmap and mkgridmap.py scripts and sets up cron jobs that periodically check for updated revocation lists and grid-mapfile entries if required).
The Java JRE or JDK are required to run the R-GMA client java API. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
If you install the client as part of another deployment module (e.g. the UI or WN), the R-GMA client is installed automatically and you can continue with the configuration description in the next section. Otherwise, the R-GMA client can be installed via the following methods:
a) Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite R-GMA client by executing
apt-get install glite-rgma-client-config
b) Installation via gLite installer scripts
glite-rgma-client_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
chmod u+x glite-rgma-client_installer.sh
and execute it or execute it with
sh glite-rgma-client_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-client next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
This will install the following deployment modules:
· R-GMA client
· Security utils (see section 5 for details)
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
gLite-essentials- java in $GLITE_LOCATION/externals/share
gLite-essentials- cpp in $GLITE_LOCATION/externals/
swig-runtime in $GLITE_LOCATION/externals/
The gLite R-GMA configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-rgma-client-config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
If you install the client as part of another deployment module (e.g. the UI or WN), the R-GMA client is configured automatically together with the other deployment module. In this case you only need to do steps 1 to 3 before executing the configuration script of the other deployment module.
cd /opt/glite/etc/config
cp templates/* .
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-rgma-common.cfg.xml contains the common R-GMA configuration values. Table 4 shows the configuration values that can be set.
· The file glite-rgma-client.cfg.xml contains the R-GMA client specific configuration values. Table 6 shows the configuration values that can be set.
· The file glite-security-utils.cfg.xml contains the security utils specific configuration values. Refer to Table 2 for the list of parameters and section 5 for the description of the security utils.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output. [Type: ‘boolean’] Example: true |
|
System Parameters |
||
|
set.proxy.path |
false |
If this parameter is true, the configuration script sets the GRID_PROXY_FILE and X509_USER_PROXY environment variables to the default value /tmp/x509up_u`id -u`. The parameter is set to false by default, since these environment variables are normally handled by other modules (like the gLite User Interface and the CE job wrapper on the Worker Nodes) and setting them here may create conflicts. It may be however necessary to let the R-GMA client set the variables for stand-alone use [Type: 'boolean'] Example: false |
Table 6: R-GMA Client Configuration Parameters
Note: Step 1,2 and 3 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
cd /opt/glite/etc/config/scripts
./glite-rgma-client-config.py –configure
Running the configuration script will automatically configure the security utils so there is no need to run the configuration script of security utils as well.
Check if any error message is displayed and if necessary fix the parameters values and restart the script. If the configuration is successful you should see at the end the message:
The gLite R-GMA client was successfully configured.
c) To verify that the R-GMA client is running correctly, you can run
/opt/glite/bin/rgma-client-check
In order to have the correct environment set up to run this command, you can either source
/etc/glite/profile.d/glite_setenv.sh
or logout and login to your shell for the automatic update to take place.
The R-GMA Client is completely configured.
The R-GMA servicetool is an R-GMA client tool to publish information about the services it knows about and their current status. The tool is divided into three parts:
A daemon monitors regularly configuration files containing information about the services a site has installed. At regular intervals, this information is published to the ServiceTable. Each service specifies a script that needs to be run to obtain status information. The scripts are run by the daemon at the specified frequency and the results are inserted into the ServiceStatus table.
The second part of the tool is a command line program that modifies the configuration files to add delete and modify services. It does not communicate with the daemon directly but the next time the daemon scans the configuration file the changes will be published.
The third part of the tool is a command line program to query the service tables for status information.
This service is normally installed automatically with other modules and doesn’t need to be installed independently.
You can publish both gLite and non-gLite services to R-GMA. If you publish gLite services, the R-GMA servicetool is installed together with the corresponding service, if you want to publish a non-gLite service, you have to install the R-GMA servicetool deployment module separately.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils (gLite Security Utilities) is installed and configured automatically when installing and configuring the R-GMA Servicetool (refer to Chapter 15 for more information about the Security Utilities module). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl, glite-mkgridmap and mkgridmap.py scripts and sets up cron jobs that periodically check for updated revocation lists and grid-mapfile entries if required).
The Java JRE or JDK are required to run the R-GMA servicetool. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
If you install the R-GMA servicetool as part of another deployment module (e.g. the single catalog), the R-GMA servicetool is installed automatically and you can continue with the configuration description in the next section. Otherwise, the R-GMA servicetool can be installed in the following ways:
a) Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite R-GMA servicetool by executing
apt-get install glite-rgma-servicetool-config
b) Installation via gLite installer scripts
glite-rgma-servicetool_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
chmod u+x glite-rgma-servicetool_installer.sh
and execute it or execute it with
sh glite-rgma-servicetool_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-servicetool next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
The script will install the following deployment modules:
· R-GMA servicetool
· Security utils (see section 5 for details)
If the installation is performed successfully, the following components are installed:
gLite
in /opt/glite ($GLITE_LOCATION)
gLite-essentials java in $GLITE_LOCATION/externals/share
The gLite R-GMA servicetool configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-rgma-servicetool-config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
If you install the R-GMA servicetool as part of another deployment module (e.g. the single catalog), the R-GMA servicetool is configured automatically together with the other deployment module. In this case you only need to do steps 1 to 3 before executing the configuration script of the other deployment module.
cd /opt/glite/etc/config
cp templates/* .
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-rgma-common.cfg.xml contains the common R-GMA configuration values. Table 4 shows the configuration values that can be set.
· The file glite-rgma-servicetool.cfg.xml contains the R-GMA client specific configuration values. Table 7 shows the configuration values that can be set.
· The file glite-security-utils.cfg.xml contains the security utils specific configuration values. Refer to Table 2 for the list of parameters and section 5 for the description of the security utils.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
rgma.servicetool.sitename
|
|
DNS name of the site for the published services (in general the hostname). [Type: 'string'] Example: lxb2029.cern.ch |
|
Advanced Parameters |
||
|
glite.installer.verbose |
True |
Enable verbose output. [Type: 'boolean'] Example : true |
|
rgma.servicetool.activate |
True |
Turn on/off servicetool for the node. [Type: 'boolean'] Example : true |
|
System Parameters |
||
Table 7: R-GMA servicetool configuration parameters
If the rgma.servicetool.activate parameter is set to false, then the servicetool daemon is not started and no service publishing occurs. This can be used on gLite nodes in case R-GMA Server is not used. It is possible to prevent individual services from being published by setting the rgma.servicetool.enable parameter to false in the service instance.
a) Publishing a gLite service
I. Configuring the servicetool:
You will find the necessary configuration parameters in the configuration file of the service (e.g. for the single catalog in the file glite-data-single-catalog.cfg.xml) as separate <instance> parameter lists.
In order to
configure the service to publish its information and state via the
R-GMA servicetool, you have to modify for each of these ‘instance parameter
list’ the parameters. Table 7 shows the list of parameters for each service
that you have to set accordingly.
You do not need to run the configuration script as this is done automatically by the configuration script of the deployment module that contains the corresponding services.
II. Starting the R-GMA servicetool:
The servicetool is automatically started together with service when you start the service. You don’t need to start it separately.
III. Verify that the installation is successful by running
./glite-rgma-servicetool-config.py –status
after you have started your service.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
rgma.servicetool.enable |
true |
Publish this service via the R-GMA servicetool. If this varaiable set to false the other values below are not taken into account. Example: true |
|
rgma.servicetool. |
|
The type of the service: · Unique string in reversed domain name structure. · For all gLite software the structure is org.glite.<subsystem>.<component> where § <subsystem> is the name of the subsystem § <component> is the name of the individual component · For all external software corresponding prefixes can be chosen (e.g. following their package domain names). Example: org.glite.data.FiremanCatalog |
|
rgma.servicetool.name |
|
The name of the service: · Globally unique string including hostname and VO name (if available). · For all gLite software the structure is <hostname>_<VOname>_<service-type> where § <hostname> is the fully qualified DNS hostname (e.g. lxb1212.cern.ch) § <VO-name> is the name of the VO the service is serving (only specified if VO specific service) § <service-type> is the string used for the ‘Service Type’ above. Examples: lxn5463.cern.ch_org.glite.data.io-server or lxb1270.cern.ch_EGEE_org.glite.rgma.RgmaServer |
|
rgma.servicetool.
|
|
URI to contact the service at. This is a service specific string. If no URL is available a string Example: https://{$HOSTNAME}:8443/EGEE/glite-data-catalog-service-meta/services/MetadataCatalog |
|
rgma.servicetool. |
|
The version of the service in the form ‘major.minor.patch’. For the moment we recommend to use the version of the deployment scripts. Example: 1.2.3 |
|
rgma.servicetool. |
3600 |
How often to publish the service details (like endpoint, version etc). in seconds. Example: 3600 |
|
rgma.servicetool. |
30 |
How often check and publish service status (running/not running) in seconds. Example: 30 |
|
rgma.servicetool. |
|
Script to run to determine the service status. This script should return an exit code of 0 to indicate the service is OK, other values should indicate an error. The first line of the standard output should be a brief message describing the service status (e.g. ‘Accepting connections’ Example: /opt/glite/bin/myService/serviceStatus |
|
rgma.servicetool.url_wsdl |
|
URL of a WSDL document for the service. This is a service specific string. If no URL is available a string ‘not available’ should be set. Example: https://{$HOSTNAME}:8443/EGEE/glite-data-catalog-service-meta/services/MetadataCatalog?wsdl |
|
rgma.servicetool. |
|
URL of a document containing a detailed description of the service and how it should be used. This is a service specific string. If no URL is available a string ‘not available’ should be set. Example: http://egee-jra1-dm.web.cern.ch/egee-jra1-dm/ |
|
Advanced Parameters |
||
|
System Parameters |
||
Table 8: R-GMA servicetool configuration parameters for
a service to be published via the R-GMA servicetool
b) Publishing a non gLite service
I. Create the service specific configuration file(s)
A template configuration file for a non-gLite service can be found at
/opt/glite/etc/config/templates/glite-rgma-servicetool-serviceName.cfg.xml
Copy this file to the directory
/opt/glite/etc/config
and rename it by replacing serviceName with the unique name of your service (e.g. call it /glite-rgma-servicetool-globusService.cfg.xml).
Create one file like that for each service that you want to publish
via the
R-GMA servicetool.
II. Customize all the configuration files by replacing the ‘changeme’ value in all user defined parameters with the proper value. Table 8 shows the list of parameters for each service that you have to set accordingly.
III. Change to the script directory
cd /opt/glite/etc/config/scripts/
IV. Add the service specific configuration values (for each service) to the R-GMA servicetool. To do this, run the R-GMA servicetool configuration script
./glite-rgma-servicetool-config.py --service=serviceName
passing the option --service=serviceName where serviceName is the name that you used in step I for your filename (globusService for our example):
Repeat this for each service that you want to publish.
V. Configure the R-GMA servicetool by running the R-GMA servicetool configuration script with the option --configure
./glite-rgma-servicetool-config.py –configure
VI. Start the R-GMA servicetool:
./glite-rgma-server-config.py --start
Check if any error message is displayed and if necessary fix the parameters values and restart the script.
VII. Verify that the installation is successful by running
./glite-rgma-server-config.py --status
The R-GMA Servicetool is completely configured.
Note: Step 1, 2, 3 and 4a can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
The R-GMA GadgetIN (GIN) is an R-GMA client to extract information from MDS and to republish it to R-GMA. The R-GMA GadgetIN is installed and used by the Computing Element (CE) to publish its information and does not need to be installed independently.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils (gLite Security Utilities) is installed and configured automatically when installing and configuring the R-GMA Servicetool (refer to Chapter 15 for more information about the Security Utilities module). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl, glite-mkgridmap and mkgridmap.py scripts and sets up cron jobs that periodically check for updated revocation lists and grid-mapfile entries if required).
The Java JRE or JDK are required to run the R-GMA GadgetIN. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
If you install the R-GMA GadgetIN as part of another deployment module (e.g. the Computing element), the R-GMA GadgetIN is installed automatically and you can continue with the configuration description in the next section. Otherwise, the R-GMA GadgetIn can be installed in the following ways:
a) Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite R-GMA GadgetIN by executing
apt-get install glite-rgma-gin-config
b) Installation via gLite installer scripts
glite-rgma-gin_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
chmod u+x glite-rgma-gin_installer.sh
and execute it or execute it with
sh glite-rgma-gin_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
This will install the following deployment modules:
· R-GMA GIN
· Security utils (see section 5 for details)
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
gLite-essentials- java in $GLITE_LOCATION/externals/share
The gLite R-GMA gin configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-rgma-gin-config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
If you install the R-GMA GIN as part of another deployment module (e.g. the CE), the R-GMA GIN is configured automatically together with the other deployment module. In this case you only need to do steps 1 to 3 before executing the configuration script of the other deployment module.
cd /opt/glite/etc/config
cp templates/* .
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-rgma-common.cfg.xml contains the common R-GMA configuration values. Table 4 shows the configuration values that can be set.
· The file glite-rgma-gin.cfg.xml contains the R-GMA client specific configuration values. Table 9 shows the configuration values that can be set.
· The file glite-security-utils.cfg.xml contains the security utils specific configuration values. Refer to Table 2 for the list of parameters and section 5 for the description of the security utils.
Note: Step 1,2 and 3 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
The following steps are only necessary if you have installed GIN separately and not as part of another gLite deployment module. Otherwise the other deployment module will take care about these steps:
cd /opt/glite/etc/config/scripts
./glite-rgma-server-config.py --configure
Running the configuration script will automatically configure the security utils as well so there is no need to run the configuration script of the security utils as well.
Check if any error message is displayed and if necessary fix the parameters values and restart the script. If the configuration is successful you should see at the end the message:
The gLite R-GMA GIN was successfully configured.
./glite-rgma-gin-config.py --start
Check if any error message is displayed and if necessary fix the parameters values and restart the script.
./glite-rgma-gin-config.py --status
The R-GMA GIN is completely configured and running.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
rgma.gin.run_generic_info_provider |
|
Run generic information provider (gip) backend (yes|no). Within LCG this comes with the ce and se Example: no |
|
rgma.gin.run_fmon_provider
|
|
Run fmon backend (yes|no). This is used by LCG for gridice. Example: no |
|
rgma.gin.run_ce_provider |
|
Run ce backend (yes|no). Example: yes |
|
Advanced Parameters |
||
|
glite.installer.verbose |
True |
Enable verbose output. Example : true |
|
System Parameters |
||
Table 9: R-GMA GadgetIN configuration parameters
The Service Discovery module is the counterpart to the information system. It allows the different gLite modules to discover the endpoint of other gLite modules they are interested in. The Service Discovery module can use several information systems
or any combination of these systems to discover the corresponding services.
The gLite Service Discovery module is installed together with the gLite modules that are using Service Discovery – you do no need to install it separately.
The following modules presently use Service Discovery:
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the Java API of the Service Discovery. This release requires v. 1.4.2 revision 08. The JDK/JRE version to be used is a parameter in the gLite global configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
Normally the Service Discovery is automatically installed as part of another deployment module (e.g. the User Interface) and you can continue with the configuration description in the next section. Otherwise, the installation steps are:
1. Download the latest version of the Service Discovery installation script
glite-service-discovery_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
2. Make the script executable
chmod u+x glite-service-discovery _installer.sh
and execute it or execute it with
sh glite-service-discovery_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-service-discovery next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
3. The script will install the following deployment modules:
· Service Discovery
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
4. The gLite Service Discovery configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-service-discovery --config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
The service discovery is configured automatically together with the other deployment module that it was downloaded with and that uses Service Discovery. You will only need to adapt the configuration:
cd /opt/glite/etc/config
cp templates/* .
· The file glite-global.cfg.xml contains global configuration values. Refer to Table 1 for the values that can be set and section 4.2.3 for the description about the general configuration.
· The file glite-service-discovery.cfg.xml contains the Service Discovery specific configuration values. Table 10 shows the configuration values that can be set.
|
Parameter |
Default value |
Description |
|
User-defined parameters |
||
|
service-discovery.type |
|
Service discovery implementation to be used. Possible values are: · file use (static) file base service discovery · rgma use (dynamic) R-GMA based service discovery · bdii use (dynamic) BDII based service discovery Several implementations can be specified that will be tried/used in the specified order. [Type: string] Example: file |
|
service-discovery.site |
|
Site name to be used to find a service nearby. This parameter must match the specified site name of the services that have to be discovered. Leave the parameter empty if you don't want to specify a site. [Type: 'string'] Example: cern.ch |
|
service-discovery.vo |
|
Default VO to be used to find a friendly VO. Leave the parameter empty if you don't want to specify a default VO. [Type: 'string'] Example: EGEE |
|
Configuration
for BDII based service discovery: |
||
|
service-discovery.bdii.provider |
|
Host and port of the BDII service for service discovery. Leave empty or remove parameter if you do not use BDII as information provider. [Type: 'string'] Example: lxb1386.cern.ch:2170 |
|
Advanced Parameters |
||
|
glite.installer.verbose |
True |
Enable verbose output. [Type: ‘boolean’] Example : true |
|
System Parameters |
||
Table 10: Service Discovery common configuration parameters
You will find the necessary configuration parameters in the configuration file of the service (e.g. for the File Transfer Client in the file glite-file-transfer-service-client.cfg.xml) as separate <instance> parameter lists of type ‘service-discovery.file’. You will have to modify for each of these ‘instance parameter list’ the parameters. Table 11 shows the list of parameters for each service that has to be discovered via file based service discovery that you have to set accordingly.
|
Parameter |
Default value |
Description |
|
User-defined parameters |
||
|
service-discovery.file. |
|
The globally unique name of the service. The convention is 'service_host'_'vo_name'_'service_type'. [Type’ ‘string’] Example: my.hostname.com_myVO_org.glite.FiremanCatalog |
|
service-discovery.file.url_endpoint description |
|
URL endpoint of the service. [Type: 'string'] Example: http://my.hostname.com:8443/myVO/glite-data-catalog-service-fr/services/FiremanCatalog |
|
service-discovery.file.service_version description |
|
Service version in the form 'major.minor.patch' of the used service. [Type: ‘string’] Example: 1.2.3 |
|
Advanced Parameters |
||
|
service-discovery.file.service_type description |
|
The service type of the used service. This must match the type used to publish the corresponding service. (see 'rgma.servicetool.service_type' for the corresponding service for R-GMA as information source) [Type: 'string'] Example: org.glite.FiremanCatalog |
|
System Parameters |
||
Table 11: Service Discovery configuration parameters
for file based information service
Note: Step 1, 2, 3 and 4 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
You do not need to run the configuration script as this is done automatically by the configuration script of the deployment module that uses service discovery
VOMS serves as a central repository for user authorization information, providing support for sorting users into a general group hierarchy, keeping track of their roles, etc. Its functionality may be compared to that of a Kerberos KDC server. The VOMS Admin service is a web application providing tools for administering member databases for VOMS, the Virtual Organization Membership Service.
VOMS Admin provides an intuitive web user interface for daily administration tasks and a SOAP interface for remote clients. (The entire functionality of the VOMS Admin service is accessible via the SOAP interface.) The Admin package includes a simple command-line SOAP client that is useful for automating frequently occurring batch operations, or simply to serve as an alternative to the full blown web interface. It is also useful for bootstrapping the service.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
1. Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org) the script glite-security-utils_installer.sh (Chapter 5). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists
2. Install the server host certificate hostcert.pem and key hostkey.pem in /etc/grid-security
The Java JRE or JDK are required to run the R-GMA Server. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
It is possible to install the VOMS server as follows:
3. Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite VOMS server by executing
apt-get install glite-voms-server-config
4. Installation via gLite installer scripts
1. Download the latest version of the VOMS server installation script
glite-voms-server_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
2. Make the script executable
chmod u+x glite-voms-server_installer.sh
and execute it or execute it with
sh glite-voms-server_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
This will the following deployment modules:
If the installation is performed successfully, the following components are installed:
gLite in /opt/glite
Tomcat in /var/lib/tomcat5
MySQL in /usr/bin/mysql
The gLite VOMS Server and VOMS Admnistration configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-voms-server-config.py.
A template configuration file is installed in
$GLITE_LOCATION/etc/config/templates/glite-voms-server.cfg.xml
1. Change to the configuration directory:
cd /opt/glite/etc/config
2. Copy the configuration file templates from the templates directory
cp templates/* .
3. Customize the configuration files by replacing the ‘changeme’ value in all user-defined parameters with the proper value:
· The file glite-global.cfg.xml contains global configuration values. Refer to 4.2.3 for the values that can be set and section Table 1 for the description about the general configuration.
· The file glite-rgma-common.cfg.xml contains the common R-GMA configuration values. Refer to chapter 6 for the description and Table 4 for the configuration values that can be set.
· The file glite-rgma-servicetool.cfg.xml contains the R-GMA servicetool specific configuration values. Refer to Table 7 for the list of parameters that can be set and section 6.4 for the description of the R-GMA servicetool.
· The file glite-security-utils.cfg.xml contains the security utils specific configuration values. Refer to Table 2 for the list of parameters and section 5 for the description of the security utils.
·
The file glite-voms-server.cfg.xml contains
the VOMS server specific configuration files. Since multiple instances
of the VOMS Server can be installed on the same node (one per VO), some of the
parameters refer to individual instances. Each instance is contained in a
separate name <instance/> tag. A default instance is already defined and
can be directly configured. Additional instances can be added by simply copying
and pasting the <instance/> section, assigning a name and changing the
parameters values as desired. Table 12 shows the list of parameters that can be
set.
|
Parameter |
Default value |
Description |
||
|
VO Instances parameters |
||||
|
voms.vo.name |
|
Name of the VO associated with the VOMS instance |
||
|
voms.port.number |
|
Port number of the VOMS instance |
||
|
vo.admin.e-mail |
|
E-mail address of the VO admin |
||
|
vo.ca.URI |
|
URI from where the CRIs are downloaded |
||
|
User-defined Parameters |
||||
|
voms.mysql.passwd |
|
Password (in clear) of the root user of the MySQL server used for VOMS databases |
||
|
Advanced Parameters |
||||
|
glite.installer.verbose |
true |
Enable verbose output |
||
|
glite.installer.checkcerts |
true |
Enable check of host certificates |
||
|
voms.db.type |
mysql |
Defines the database type to be used |
||
|
System Parameters |
||||
|
voms-admin.install |
true |
Install the VOMS Admin interface on this server |
||
|
voms.db.mysql.library |
${GLITE_LOCATION}/lib/libvomsmysql.so |
Defines the Mysql library location |
||
Table 12: VOMS Configuration Parameters
Note: Step 1, 2, 3 and 4 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
cd /opt/glite/etc/config/scripts
./glite-voms-server-config.py --configure
Running the configuration script will automatically configure the security utils as well so there is no need to run the configuration script of the security utils as well.
Check if any error message is displayed and if necessary fix the parameters values and restart the script. If the configuration is successful you should see at the end the message:
The gLite VOMS server was successfully configured.
./glite-voms-server-config.py --start
Check if any error message is displayed and if necessary fix the parameters values and restart the script.
./glite-voms-server-config.py --status
The VOMS server is completely configured and running.
After the installation and configuration of the VOMS Server and Admin Tools, it is necessary to register at least one administrator for each registered VO running the following command on the VOMS server:
$GLITE_LOCATION/bin/vomsadmin --vo <VO name> create-user <certificate.pem> assign-role VO VO-Admin <certificate.pem>
where <VO name> is the name of the registered VO for which to register the administrator and <certificate.pem> is the path to the public certificate of the administrator. For more information, please refer to the VOMS Administrative Tools guide on the gLite web site.
The Logging and Bookkeeping service (LB) tracks jobs in terms of events (important points of job life, e.g. submission, finding a matching CE, starting execution etc.) gathered from various WMS components as well as CEs (all those have to be instrumented with LB calls).
The events are passed to a physically close component of the LB infrastructure (locallogger) in order to avoid network problems. This component stores them in a local disk file and takes over the responsibility to deliver them further.
The destination of an event is one of Bookkeeping Servers (assigned statically to a job upon its submission). The server processes the incoming events to give a higher level view on the job states (e.g. Submitted, Running, Done) which also contain various recorded attributes (e.g. JDL, destination CE name, job exit code, etc.).
Retrieval of both job states and raw events is available via legacy (EDG) and WS querying interfaces.
Besides querying for the job state actively, the user may also register for receiving notifications on particular job state changes (e.g. when a job terminates). The notifications are delivered using an appropriate infrastructure. Within the EDG WMS, upon creation each job is assigned a unique, virtually non-recyclable job identifier (JobId) in an URL form.
The server part of the URL designates the bookkeeping server which gathers and provides information on the job for its whole life.
LB tracks jobs in terms of events (e.g. Transfer from a WMS component to another one, Run and Done when the jobs starts and stops execution). Each event type carries its specific attributes. The entire architecture is specialized for this purpose and is job-centric: any event is assigned to a unique Grid job. The events are gathered from various WMS components by the LB producer library, and passed on to the locallogger daemon, running physically close to avoid any sort of network problems.
The locallogger's task is storing the accepted event in a local disk file. Once it's done, confirmation is sent back and the logging library call returns, reporting success.
Consequently, logging calls have local, virtually non-blocking semantics. Further on, event delivery is managed by the interlogger daemon. It takes the events from the locallogger (or the disk files on crash recovery), and repeatedly tries to deliver them to the destination bookkeeping server (known from the JobId) until it succeeds finally.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the R-GMA Servicetool service. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from the Sun Java web site and install it if you have not yet installed it.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
glite.user.name |
|
The account used to run the LB daemons |
|
glite.user.group |
|
Group of the user specified in the 'glite.user.name' parameter. Leave it empty of comment it out to use the same as 'glite.user.name' |
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output |
|
glite.installer.checkcerts |
true |
Enable check of host certificates |
|
lb.database.name |
lbserver20 |
The mySQL database name to create for storing LB data. In this version it must be set to the given value. |
|
lb.database.username |
lbserver |
The username to be used to access the local mySQL server. Now it must be set to the default value |
|
lb.index.list |
owner location destination |
Definitions of indices on all the currently supported indexed system attributes |
|
System Parameters |
||
Table 13: LB Configuration Parameters
i. Log Server
Again, you find the necessary steps
described in section 6.4.
Note: Step 1, 2 and 3 can also be performed by means of the
remote site configuration file or a combination of local and remote
configuration files
After installing the gLite LB module as described in this chapter, proceed as follows.
Step 1: Install the Java run-time libraries (obtained from the Sun Java web site):
rpm –ivh j2re-1_4_2_08-linux-i586.rpm
Step 2: Change to the configuration directory:
cd /opt/glite/etc/config
Step 3: Copy the configuration templates from the templates directory:
cp templates/* .
Step 4: Customize the configuration files by replacing the changeme values with appropriate parameters according to the following table.
|
File name: glite-lb.cfg.xml |
||
|
glite.user.name |
<define your own, must be the same as in the WMS module if istalled on the same host> |
|
|
glite.user.group |
<define your own, must be the same as in the WMS module if istalled on the same host> |
|
|
|
|
|
|
File name: glite-global.cfg.xml |
|
|
|
site.config.url |
<empty> |
|
|
|
|
|
|
File name: glite-rgma-common.cfg.xml |
|
|
|
rgma.server.hostname |
<your R-GMA Server> |
|
|
rgma.schema.hostname |
<your R-GMA Schema Server> |
|
|
rgma.registry.hostname |
<your R-GMA Registry Server> |
|
|
|
|
|
|
File name: glite-rgma-servicetool.cfg.xml |
|
|
|
rgma.servicetool.sitename |
<your site name as registered in R-GMA> |
|
|
|
|
|
|
File name: glite-security-utils.cfg.xml |
|
|
|
cron.mailto |
<your own address> |
|
Step
5: Change to the scripts directory and execute the
glite-lb-config.py script
./glite-lb-config.py --configure
Check if any error message is displayed and if necessary fix the parameters
values and restart the script. If the configuration is successful you should
see at the end the message:
The gLite Logging and bookkeeping Server configuration was successfully completed
Step 6:
Start the LB services
./glite-lb-config.py --start
Check if any error message is displayed and if necessary take any corrective
action as reported. If the operation is successful you should see at the end
the message:
The gLite Logging and bookkeeping Server was successfully started
Step 7: Verify that the LB service have been correctly published by connecting to your R-GMA Browser with your Internet browser
https://<your R-GMA browser>:8443/R-GMA
You should see your LB service registered in the Services list
The LB configuration script can be run with the following command-line parameters to manage the services:
|
glite-lb-config.py --configure |
Configures all LB services |
|
glite-lb-config.py --start |
Starts all LB services (or restart them if they are already running) |
|
glite-lb-config.py –stop |
Stops all LB services |
|
glite-lb-config.py --status |
Verifies the status of all services. The exit code is 0 if all services are running, 1 in all other cases |
When the LB configuration script is run, it installs the gLite script in the /etc/inet.d directory and activates it to be run at boot. The gLite script runs the glite-lb-config.py --start command and makes sure that all necessary services are started in the correct order.
The LB services are published to R-GMA using the R-GMA Servicetool service. The Servicetool service is automatically installed and configured when installing and configuring the LB module. The LB configuration file contains a separate configuration section (an <instance/>) for each LB sub-service. The required values must be filled in the configuration file before running the configuration script.
For more details about the R-GMA Service Tool service refer to section 6.4 in this guide.
The Workload Management System (WMS) comprises a set of grid middleware components responsible for the distribution and management of tasks across grid resources, in such a way that applications are conveniently, efficiently and effectively executed.
The core component of the Workload Management System is the Workload Manager (WM), whose purpose is to accept and satisfy requests for job management coming from its clients. For a computation job there are two main types of request: submission and cancellation.
In particular the meaning of the submission request is to pass the responsibility of the job to the WM. The WM will then pass the job to an appropriate Computing Element for execution, taking into account the requirements and the preferences expressed in the job description. The decision of which resource should be used is the outcome of a matchmaking process between submission requests and available resources.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the R-GMA Servicetool service. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from the Sun Java web site and install it if you have not yet installed it.
The Information System currently used by the Workload Management System is not RGMA, given that the integration between these two components is not yet available. In the next future the provisioning of the WMS RGMA purchaser will allow the full exploitation of RGMA. At this stage, however, WMS is making use of a fake BD-II, where information is filled in by non automated procedures (instead of information providers), and there is no dynamic information available.
BD-II is a well known component of existing GRID middleware (e.g. LCG). Please, consult LCG guides for documentation on how to install and configure the BD-II.
BD-II is required if the gLite WMS needs to be configured in "push mode", where the information on available resources is taken from the BD-II and shipped to the WMS Information Cache by the LDAP purchaser. Other modes of operation for the information flow (synchronous and asynchronous pull mode), do no strictly require the usage of the BD-II.
If WMS is used in push mode, all the CE information has to be filled in according to the current used Glue Schema inside it.
For this reason the current deployment module foresees the insertion of the BD-II contact hostname, port and base DN as optional parameters.
Another case in which the BD-II is mandatory is when users want to make use of InputData-driven match making.
If a user in fact uses the InputData filed and its associated StorageIndex contact in the JDL file, then all available Storage Element information goes in the BD-II to allow matching.
|
Parameter |
Default value |
Description |
||
|
User-defined Parameters |
||||
|
glite.user.name
|
|
Name of the user account used to run the gLite services on this WMS node |
||
|
glite.user.group
|
|
Group of the user specified in the 'glite.user.name' parameter. This group must be different from the pool account group specified by the parameter ‘pool.account.group’. |
||
|
voms.voname |
|
The names of the VOs that this WMS node can serve (array parameter) |
||
|
voms.vomsnode |
|
The full hostname of the VOMS server responsible for each VO. Even if the same server is responsible for more than one VO, there must be exactly one entry for each VO listed in the 'voms.voname' parameter. Example: host.domain.org |
||
|
voms.vomsport |
|
The port on the VOMS server listening for request for each VO This is used in the vomses configuration file Example: 15000 |
||
|
voms.vomscertsubj |
|
The subject of the host certificate of the VOMS server for each VO. Example: /C=ORG/O=DOMAIN/OU=GRID/CN=host.domain.org |
||
|
pool.account.basename
|
|
The prefix of the set of pool account to be created. Existing pool accounts with this prefix are not recreated |
||
|
pool.account.group
|
|
The group name of the pool accounts to be used. This group must be different from the WMS service account group specified by the parameter ‘glite.user.group’. |
||
|
pool.account.number
|
|
The number of pool accounts to create. Each account will be created with a username of the form prefixXXX where prefix is the value of the pool.account.basename parameter. If matching pool accounts already exist, they are not recreated. The range of values for this parameter is 1-999 |
||
|
wms.cemon.port |
|
The port number on which this WMS server is listening for notifications from CEs when working in pull mode. Leave this parameter empty or comment it out if you don't want to activate pull mode for this WMS node. Example: 5120 |
||
|
wms.cemon.endpoints |
|
The endpoint(s) of the CE(s) that this WMS node should query when working in push mode. Leave this parameter empty or comment it out if you don't want to activate push mode for this WMS node. Example: 'http://lxb0001.cern.ch:8080/ce-monitor/services/CEMonitor' |
||
|
information.index.host
|
|
Host name of the Information Index node. Leave this parameter empty or comment it out if you don't want to use a BD-II for this WMS node |
||
|
cron.mailto |
|
E-mail address for sending cron job notifications |
||
|
condor.condoradmin
|
|
E-mail address of the condor administrator |
||
|
Advanced Parameters |
||||
|
glite.installer.verbose |
True |
Sets the verbosity of the configuration script output |
||
|
glite.installer.checkcerts
|
True |
Switch on/off the checking of the existence of the host certificate files |
||
|
account.discovery |
False |
Automatically discover pool accounts using pool account base names. If this parameter is set to true, the script will look for accounts starting with one of the base names set in the pool.account.basename parameter and followed by a valid numeral. No attempt to create additional accounts is done, but the discovered accounts will be configured |
||
|
wms.config.file |
${GLITE_LOCATION}/etc/glite_wms.conf |
Location of the wms configuration file |
||
|
lb.locallogger |
${HOSTNAME}:9002 |
Host name and port of the local Logging and Bookkeeping logger to be used by the Workload Manager Proxy. This is normally running on the WMS server itself. Example: lxb0001.cern.ch:9000 |
||
|
lb.server |
<empty> |
Host name and port of the Logging and Bookkeeping Server to be used by the Workload Manager Proxy. The port is normally 9000. If LB is installed on this node together with WMS, you can leave this parameter empty or comment it out. Example: lxb0001.cern.ch:9000 |
||
|
GSIWUFTPPORT
|
2811 |
Port where the globus ftp server is listening |
||
|
GSIWUFTPDLOG
|
${GLITE_LOCATION_LOG}/gsiwuftpd.log |
Location of the globus ftp server log file |
||
|
condor.scheddinterval |
10 |
Condor scheduling interval |
||
|
condor.releasedir |
/opt/condor-6.7.6 |
Condor installation directory |
||
|
condor.CLASSAD_LIFETIME |
60 |
How often should the collector check for machines that don't have ClassAds from the condor_master and send email about it? |
||
|
condor.NEGOTIATOR_UPDATE_INTERVAL |
20 |
condor_negotiator update interval |
||
|
condor.MASTER_UPDATE_INTERVAL |
20 |
condor_master update interval |
||
|
condor.UPDATE_INTERVAL
|
20 |
Default update interval |
||
|
condor.NEGOTIATOR_INTERVAL |
30 |
The time interval, in seconds, at which the negotiator daemon updates the status of jobs |
||
|
condor.HIGHPORT |
50000 |
Specifies a higher limit of given port numbers for Condor to use |
||
|
condor.LOWPORT |
1500 |
Specifies a lower limit of given port numbers for Condor to use |
||
|
CONDOR_CONFIG |
${condor.releasedir}/etc/condor_config |
Condor global configuration fil |
||
|
condor.blahpollinterval
|
10 |
How often should blahp poll for new jobs? |
||
|
information.index.port |
2170 |
Port number of the Information Index |
||
|
information,index.base_dn |
mds-vo-name=local, o=gris |
Base DN of the information index LDAP server |
||
|
disable.gris.purchasing |
True |
If this parameter is set to to true, the WMS will not try to poll all CEs listed in the BD-II information service to validate them [Example: true] [Type: boolean] |
||
|
GLOBUS_FLAVOR_NAME
|
gcc32dbg |
The Globus libraries flavour to be used |
||
|
System Parameters |
||||
|
condor.localdir |
/var/local/condor |
Condor local directory |
||
|
condor.daemonlist |
MASTER, SCHEDD, COLLECTOR, NEGOTIATOR |
List of the condor daemons to start. This must a comma-separated list of services as it would appear in the Condor configuration file |
||
Table 14: WMS Configuration Parameters
i. Local Logger
ii. Proxy Renewal Service
iii. Log Monitor Service
iv. Job Controller Service
v. Network Server
vi. Workload Manager
Again, you find the necessary steps
described in section 6.4.
Note: Step 1, 2 and 3 can also be performed by means of the
remote site configuration file or a combination of local and remote
configuration files
After installing the gLite WMS module as described in this chapter, proceed as follows.
Step 1: Install the Java run-time libraries (obtained from the Sun Java web site):
rpm –ivh j2re-1_4_2_08-linux-i586.rpm
Step 2: Change to the configuration directory:
cd /opt/glite/etc/config
Step 3: Copy the configuration templates from the templates directory:
cp templates/* .
Step 4: Customize the configuration files by replacing the changeme values with appropriate parameters according to the following table.
|
File name: glite-wms.cfg.xml |
||
|
glite.user.name |
<specify an account name> |
|
|
glite.user.group |
<specify a group name or leave empty to use the same as account name> |
|
|
voms.voname |
<your VOMS server hostname> |
|
|
voms.vomsport |
15000 |
|
|
voms.vomscertsubj |
<your VOMS server certificate subject> |
|
|
pool.account.basename |
<define your own> |
|
|
pool.account.group |
<define your own> |
|
|
pool.account.number |
<as many as you like> |
|
|
wms.cemon.port |
5120 |
|
|
information.index.host |
<your BD-II server host name or empty not to use it> |
|
|
wms.cemon.endpoint |
<enter a list of CE hostnames that you want to send jobs requests to (push mode) or set just one empty value to disable push mode> |
|
|
cron.mailto |
<your email address> |
|
|
condor.condoradmin |
<your email address> |
|
|
|
||
|
File name: glite-global.cfg.xml |
||
|
site.config.url |
<empty> |
|
|
|
||
|
File name: glite-rgma-common.cfg.xml |
||
|
rgma.server.hostname |
<your R-GMA Server> |
|
|
rgma.schema.hostname |
<your R-GMA Schema Server> |
|
|
rgma.registry.hostname |
<your R-GMA Registry Server> |
|
|
|
||
|
File name: glite-rgma-servicetool.cfg.xml |
||
|
rgma.servicetool.sitename |
<your site name as registered in R-GMA> |
|
|
|
||
|
File name: glite-security-utils.cfg.xml |
||
|
cron.mailto |
<your own address> |
|
|
install.mkgridmap.cron |
true |
|
Step 5: Change to the scripts directory:
cd /opt/glite/etc/config/scripts
Step 6: Execute
the glite-wms-config.py script:
./glite-wns-config --configure
Check if any error message is displayed and if necessary fix the parameters
values and restart the script. If the configuration is successful you should
see at the end the message:
The gLite WMS Service configuration was successfully completed
Step 7: Start the
WMS services:
./glite-wns-config --start
Check if any error message is displayed and if necessary take any corrective
action as reported and restart the script. If the operation is successful you
should see at the end the message:
The gLite WMS Service was successfully started
Step 8: Verify that the LB service have been correctly published by connecting to your R-GMA Browser with your Internet browser
https://<your R-GMA browser>:8443/R-GMA
You should see your LB service registered in the Services list
The WMS configuration script can be run with the following command-line parameters to manage the services:
|
glite-wms-config.py –configure |
Configures all WMS services |
|
glite-wms-config.py --start |
Starts all WMS services (or restart them if they are already running) |
|
glite-wms-config.py --stop |
Stops all WMS services |
|
glite-wms-config.py --status |
Verifies the status of all services. The exit code is 0 if all services are running, 1 in all other cases |
|
glite-wms-config.py --startservice=xxx |
Starts the WMS xxx subservice. xxx can be one of the following: condor = the Condor master and daemons ftpd = the Grid FTP daemon lm = the gLite WMS Logger Monitor daemon wm = the gLite WMS Workload Manager daemon ns = the gLite WMS Network Server daemon jc = the gLite WMS Job Controller daemon pr = the gLite WMS Proxy Renewal daemon lb = the gLite WMS Logging & Bookkeeping client |
|
glite-wms-config.py --stopservice=xxx |
Stops the WMS xxx subservice. xxx can be one of the following: condor = the Condor master and daemons ftpd = the Grid FTP daemon lm = the gLite WMS Logger Monitor daemon wm = the gLite WMS Workload Manager daemon ns = the gLite WMS Network Server daemon jc = the gLite WMS Job Controller daemon pr = the gLite WMS Proxy Renewal daemon lb = the gLite WMS Logging & Bookkeeping client |
When the WMS configuration script is run, it installs the gLite script in the /etc/inet.d directory and activates it to be run at boot. The gLite script runs the glite-wms-config.py --start command and makes sure that all necessary services are started in the correct order.
The WMS services are published to R-GMA using the R-GMA Servicetool service. The Servicetool service is automatically installed and configured when installing and configuring the WMS module. The WMS configuration file contains a separate configuration section (an <instance/>) for each WMS sub-service. The required values must be filled in the configuration file before running the configuration script.
For more details about the R-GMA Service Tool service refer to section 6.4 in this guide.
TORQUE (Tera-scale Open-source Resource and QUEue manager) is a resource manager providing control over batch jobs and distributed compute nodes. It is a community effort based on the original PBS project and has incorporated significant advances in the areas of scalability and fault tolerance.
The torque system is composed by a pbs_server which provides the basic batch services such as receiving/creating a batch job or protecting the job against system crashes. The pbs_mom (second service) places the job into execution when it receives a copy of the job from a Server. The mom_server creates a new session as identical to a user login session as if possible. It also has the responsibility for returning the job’s output to the user when directed to do so by the pbs_server. The job scheduler is another daemon which contains the site’s policy controlling which job is run and where and when it is run. The scheduler appears as a batch Manager to the server. The scheduler being used by the torque module is maui.
This deployment module contains and configures the pbs_server (server configuration, queues creation, etc …) and maui services. It is also responsible for registering both services into RGMA via the servicetool deployment module.
The sshd configuration required for the torque clients to copy their output back to the torque server is also carried out in this module.
The Torque Server can be configured to run the BLAHP log parser daemon. This daemon will be responsible to provide the logs to BLAHP. By default this option is activated.
A Torque Server (the Computing Element node) could easily work as a Torque Client (the Worker Node) by including and configuring the pbs_mom service. By design the Torque Server deployment module does not include the RPMS and configuration necessary to make it work as a Torque Client. The only additional task to make a Torque Server be also a Torque Client is the installation and configuration of the Torque Client deployment module.
This deployment module configures the pbs_mom service aimed at being installed in the worker nodes. It’s also responsible for the ssh configuration to allow copying the job output back to the Torque Server (Computing Element).
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
1. Download from the gLite web site the latest version of the Torque Server installation script glite-torque-server_installer.sh. It is recommended to download the script in a clean directory
2. Make the script executable (chmod u+x glite-torque-server_install.sh).
3. Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-torque-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
4.
If the installation is performed successfully,
the following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
torque in /var/spool/pbs
5. The gLite torque-server configuration script is installed in $GLITE_LOCATION/etc/config/scripts/glite-torque-server-config.py. A template configuration file is installed in $GLITE_LOCATION/etc/config/templates/glite-torque-server.cfg.xml
6. The gLite torque-server installs the R-GMA servicetool to publish its information to the information system R-GMA. The details of the installation of the R-GMA servicetool are described in section 6.4.
12. Copy the
global configuration file template
$GLITE_LOCATION/etc/config/template/glite-global.cfg.xml
to
$GLITE_LOCATION/etc/config
open it and modify the parameters if required (see Table
)
13. Copy the configuration file template from
$GLITE_LOCATION/etc/config/templates/glite-torque-server.cfg.xml
to
$GLITE_LOCATION/etc/config/glite-torque-server.cfg.xml
and modify the parameters values as necessary. Some
parameters have default values, others must be changed by the user. All
parameters that must be changed have a token value of changeme. The parameters
that can be set can be found in Table . The R-GMA servicetool related
parameters can be found in Table 7.
The parameters in the file can be divided into two categories:
<instance name="changeme"
service="wn-torque">
….
</instance>
At least one worker node instance must be defined. If
you want to use multiple clients, create a separate instance for each client by
copying/pasting the <instance> section in this file.
Next, change the name of each client instance from ‘changeme’ to the client
name and adapt the parameters of each instance accordingly.
c.
Queues (third
part of Table )
For every queue to be created in the Torque Server the configuration file
contains the list of parameters grouped by the tag
<instance name="xxxx "
service="pbs-queue">
…
</instance>
where xxxx is the name of the queue. Adapt the parameters of each instance
accordingly. If you want to configure more queues please add a separate
instance by copying/pasting the <instance> section in this file for each
queue.
By default, the configuration file defines three queues (short, long and infinite) with different values and with acl_groups disabled. It’s up to the users to customize their queues depending on their requirements.
|
Common parameters
|
||
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
torque-server.force |
|
This parameter specifies the behaviour of the pbs_server setting parameters and queue creation.In case it is True it will take the whole control of the queue creation/deletion. That means that if it's specified a queue in the config file and latter removed from the configuration file it will also be removed in the pbs_server configuration, on the contrary, no queue removal will be performed. |
|
use.log.parser |
true |
This option must be set to true to run the BLAHP log parser daemon in the port specified by the pbs.log.parser.port variable. Valid values for this parameter are true or false |
|
Advanced Parameters |
||
|
glite.installer.verbose
|
true |
Enable verbose output. |
|
pbs.log.parser.port |
33332 |
This is the port where the log parser is listening for log requests. [Example: 33332] [Type: integer] |
|
torque-server.name |
${HOSTNAME} |
Name of the machine where the job server is running, it usually corresponds to the Computing Element: Example: ${HOSTNAME}. |
|
torque-server.scheduling |
True |
When the attribute scheduling is set to true, the server will call the job scheduler, if false the job scheduler is not called. The value of scheduling may be specified on the pbs_server command line with the -a option. |
|
torque-server.acl-host.enable |
False |
Enables the server host access control list. Values True,False. |
|
torque-server.acl-host.list |
|
List of hosts which may request services from this server. This list contains the network name of the hosts.Local requests, i.e. from the server host itself, are always accepted even if the host is not included in the list. Format: [+|-] hostname.domain[,...]; default value: all hosts |
|
torque-server.default.queue |
short |
The queue which is the target queue when a request does not specify a queue name, must be set to an existing queue. |
|
torque-server.log.events |
511 |
A bit string which specifies the type of events which are logged, Default value 511 (all events). |
|
torque-server.query.other-jobs |
True |
The setting of this attribute controls if general suers, other than job owner, are allowd to query the status of or select the job. |
|
torque-server.scheduler.interaction |
600 |
The time, in seconds, between iterations of attempts by the batch server to schedule jobs.On each iteration, the server examines the available resources and runnable jobs to see if a job can be initiated.This examination also occurs whenever a running batch job terminates or a new job is placed in the queued state in an execution queue. |
|
torque-server.default.node |
glite |
A node specification to use if there is no other supplied. specification. This attribute is only used by servers where a nodes file exist in the server_priv directory providing a list of nodes to the server. If the nodes file does does a single node. |
|
torque-server.node.pack |
False |
Controls how multiple processor nodes are allocated to jobs. If this attribute is set to true, jobs will be assigned to the multiple processor nodes with the fewest free processors.This packs jobs into the fewest possible nodes leaving multiple processor nodes free for jobs which need many processors on a node. If set to false, jobs will be scattered across nodes reducing conflicts over memory between jobs.If unset, the jobs are packed on nodes in the order that the nodes are declared to the server (in the nodes file) nodes reducing conflicts over memory between jobs. |
|
maui.server.port |
40559 |
Port on which the Maui server will listen for client connections, by default 40559. |
|
maui.server.mode |
NORMAL |
Secifies how Maui interacts with the outside world. Possible values NORMAL, TEST AND SIMULATION. |
|
maui.defer.time |
00:01:00 |
Specifies amount of time a job will be held in the deferred state before being released back to the Idle job queue. Format [[[DD:]HH:]MM:]SS |
|
maui.rm.poll.interval |
00:00:10 |
Maui will refresh its resource manager information every 10 seconds. Ths parameter specifies the global poll interval for all resource managers. |
|
maui.log.filename |
${GLITE_LOCATION_LOG}/maui.log |
Name of the maui log file |
|
maui.log.max.size |
10000000 |
Maximum allowed size (in bytes) the log file before it will be rolled. |
|
maui.log.level |
1 |
Specifies the verbosity of Maui logging where 9 is the most verbose (NOTE: each logging level is approximately an order of magnitude more verbose than the previous level. Values [0..9]" |
|
System Parameters |
||
|
Worker node instances
|
||
|
Torque-wn.name |
|
Worker Node name to be used by the torque server. It can also be the CE itself. Example: lxb1426.cern.ch. [Type: string]. |
|
torque-wn.number.processors |
|
Number of virtual processors of the machine. Example: 1,2 , .... [Type: string]. |
|
torque-wn.attribute |
glite |
Attribute that can be used by the server for different purposes (for example to establish a default node. [Type: string]. |
|
Queue instances
|
||
|
queue.name |
|
Queue name |
|
queue.type |
Execution |
Must be set to either Execution or Routing. If a queue is from routing type the jobs will be routed
to another server (route_destinations attributed). |
|
queue.resources.max.cpu.time |
|
Maximum amount of CPU time used by all processes in the job. Format: seconds, or [[HH:]MM:]SS. |
|
queue.max.wall.time |
|
Maximum amount of real time during which the job can be in the running state. Format: seconds, or [[HH:]MM:]SS. |
|
queue.enabled |
True |
Defines if the queue will or will not accept new jobs. When false the queue is disabled and will not accept jobs. |
|
queue.started |
True |
It set to true, jobs in the queue will be processed, either routed by the server if the queue is a routing queue or scheduled by the job scheduler if an execution queue. When False, the queue is considered stopped. |
|
queue.acl.group.enable |
False |
Attribute which when true directs the server to use the queue group access control list acl_groups. |
|
queue.acl.groups |
|
List which allows or denies enqueuing of jobs owned by members of the listed groups. The groups in the list are groups on the server host, not submitting hosts. Syntax: [+|-]group_name[,...].Example: +test authorizes the test group users to submit jobs to this queue. |
Table 13: TORQUE Server configuration parameters
1. Configure the R-GMA servicetool. For this you have to configure the
servicetool itself as well as configure the sub-services of Torque server for
the publishing via the R-GMA servicetool:
2. R-GMA servicetool configuration:
Copy the R-GMA servicetool configuration file template
$GLITE_LOCATION/etc/config/templates/glite-rgma-servicetool.cfg.xml
to
$GLITE_LOCATION/etc/config
and modify the parameters values as necessary. Some
parameters have default values; others must be changed by the user. All
parameters that must be changed have a token value of changeme. Table 1
shows a list of the parameters that can be set. More details can be found in
section 4.2.3.
3. Service Configuration for the R-GMA servicetool:
Modify the R-GMA servicetool related configuration
values that are located in the Toque configuration file
glite-torque-server.cfg.xml
that was mentioned before. In this file, you will
find for each service that should be published via the R-GMA servicetool one
instance of a set of parameters that are grouped by the tag
<instance name="xxxx"
service="rgma-servicetool">
Where xxxx is the name of corresponding subservice. Table 8 shows the general list of parameters for each service for
the publishing via the R-GMA servicetool.
For Torque-server the following sub-services are published via the R-GMA
servicetool and need to be updated accordingly:
vii. Torque PBS server
viii. Torque maui
Again, you find the necessary steps
described in section 6.4.
Note: Step 1,2 and 3 can also be performed by means of the
remote site configuration file or a combination of local and remote
configuration files
4. As root run the Torque Server Configuration script (with the –configure option in order to configure the service) /opt/glite/etc/config/scripts/glite-torque-server-config.py --configure.
Once the services have been properly configured (no service will be running) it will be necessary to start them all. To do so, follow the next step.
5. As root start the Torque Server services by running the configuration script with the –start option.
/opt/glite/etc/config/scripts/glite-torque-server-config.py --start
Once
reached this point the Torque Server Service is ready and the Torque Clients have
to be properly installed and configured.
The Torque Server configuration script performs the following steps:
1. Load the Torque Server configuration file $GLITE_LOCATION/etc/config/glite-torque-server.cfg.xml
2. Stop the services that are running
3. Add the torque and maui ports to /etc/services.
4. Create the /var/spool/pbs/server_name file containing the torque server hostname.
5. Create the list with the torque clients under /var/spool/pbs/server_priv/nodes.
6. Create the pbs_server configuration.
7. Start the pbs_server.
8. Look for changes in the pbs_server configuration since the last time the Torque Server was configured.
9. Establish the server configuration performing the necessary updates.
10. Create the queues configuration. It will check if any new queue has been defined in the configuration file, if any queue has been removed and depending on the value of the value torque-server.force it will behave in a different way (see torque-server.force parameter description).
11. Execute the defined queues configuration
12. Create the /opt/edg/etc/edg-pbs-shostsequiv.conf file used by the script edg-pbs-shostsequiv. This file includes the list of nodes that will included in the /etc/ssh/shosts file to allow HostbasedAuthentication.
13. Create the edg-pbs-shostsequiv script. This file contains a crontab entry to call periodically the /opt/edg/sbin/edg-pbs-shostsequiv script. This file is then added to the /etc/cron.d/ directory.
14. Run the /opt/edg/sbin/edg-pbs-shostsequiv script.
15. Look for duplicated key entries in /etc/ssh/ssh_known_hosts.
16. Create the configuration file /opt/edg/etc/edg-pbs-knownhosts.conf. This file contains the nodes which keys will be added to the /etc/ssh/ssh_known_hosts file apart from the torque client nodes (which are taken directly from the torque server via the pbsnodes –a command).
17. Create the edg-pbs-knownhosts script. This script contains a crontab entry to call periodically the /opt/edg/sbin/edg-pbs-knownhosts script. This file is then added to the /etc/cron.d/ directory.
18. Run /opt/edg/sbin/edg-pbs-knownhosts to add the keys to /etc/ssh/ssh_known_hosts.
19. Create the required sshd configuration (modifying the /etc/ssh/sshd_config file) to allow the torque clients (Worker Nodes) copying their output directly to the Torque Server via HostBasedAuthentication.
20. Restart the sshd daemon to take the changes into account.
21. Stop the pbs_server.
22. Create the maui configuration file in /var/spool/maui/maui.cfg.
23. Configure the servicetool to register the torque services defined in the configuration file.
The TORQUE SERVER configuration script can be run with the following command-line parameters to manage the services:
|
glite-torque-server-config.py –configure |
Configures all TORQUE SERVER services (pbs_server, maui, BLAHP log server and servicetool) |
|
glite-torque-server-config.py –start |
Starts all TORQUE CLIENT services (or restart them if they are already running, pbs_mom) |
|
glite-torque-server-config.py –stop |
Stops all TORQUE SERVER services (pbs_server, maui and servicetool) |
|
glite-torque-server-config.py –status |
Checks the status of the TORQUE SERVER services |
1. Download from the gLite web site the latest version of the torque-server installation script glite-torque-client_installer.sh. It is recommended to download the script in a clean directory.
2. Make the script executable (chmod u+x glite-torque-client_install.sh).
3. Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-torque-client next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
4.
If the installation is performed successfully, the
following components are installed:
gLite in /opt/glite ($GLITE_LOCATION)
Torque client in /var/spool/pbs
5. The gLite torque-client configuration script is installed in $GLITE_LOCATION/etc/config/scripts/glite-torque-client-config.py. A template configuration file is installed in $GLITE_LOCATION/etc/config/templates/glite-torque-client.cfg.xml.
1. Copy the global configuration file template $GLITE_LOCATION/etc/config/template/glite-global.cfg.xml to $GLITE_LOCATION/etc/config, open it and modify the parameters if required (see Table)
2.
Copy the configuration file template from $GLITE_LOCATION/etc/config/templates/glite-client-server.cfg.xml
to $GLITE_LOCATION/etc/config/glite-torque-client.cfg.xml and modify the
parameters values as necessary. Some parameters have default values, others
must be changed by the user. All parameters that must be changed have a token
value of changeme. The following parameters can be set:
Note:
Step 1 and 2 can also be performed by means of the remote site configuration file
or a combination of local and remote configuration files
|
Parameter |
Default value |
Description |
||
|
User-defined Parameters |
||||
|
torque-server.name |
|
Name of the machine where the job server is running, it usually corresponds to the Computing Element: Example: ${HOSTNAME}. |
||
|
mpi.copy.enable
|
|
When using MPI it may be necessary to copy information between worker nodes. This variable activates HostBasedAuthentication if set to True. Possible values: True and False |
||
|
Advanced Parameters |
||||
|
glite.installer.verbose |
True |
Enable verbose output. |
||
|
mom-server.logevent |
255 |
Sets the mask that determines which event types are logged by pbs_mom. |
||
|
mom-server.loglevel |
4 |
Specifies the verbosity of logging with higher numbers specifying more verbose logging. Values may range between 0 and 7 |
||
|
System Parameters |
||||
3. As root run the Torque Client Configuration file with the –configure option
/opt/glite/etc/config/scripts/glite-torque-client-config.py --configure.
Once the services have been properly configured (no service will be running) it will be necessary to start them all. To do so, follow the next step.
4. As root start the Torque Client services by running the Torque Client Configuration File:
/opt/glite/etc/config/scripts/glite-torque-client-config.py --start
The Torque Client configuration script performs the following steps:
The TORQUE CLIENT configuration script can be run with the following command-line parameters to manage the services:
|
glite-torque-client-config.py --configure |
Configures all TORQUE CLIENT services |
|
glite-torque-client-config.py --start |
Starts all TORQUE CLIENT services (or restart them if they are already running, pbs_mom) |
|
glite-torque-client-config.py --stop |
Stops all TORQUE CLIENT services (pbs_mom) |
|
glite-torque-client-config.py --status |
Checks the status of the TORQUE CLIENT services |
The Computing Element (CE) is the service representing a computing resource. Its main functionality is job management (job submission, job control, etc.). The CE may be used by a generic client: an end-user interacting directly with the Computing Element, or the Workload Manager, which submits a given job to an appropriate CE found by a matchmaking process. For job submission, the CE can work in push model (where the job is pushed to a CE for its execution) or pull model (where the CE asks the Workload Management Service for jobs). Besides job management capabilities, a CE must also provide information describing itself. In the push model this information is published in the information Service, and it is used by the match making engine which matches available resources to queued jobs. In the pull model the CE information is embedded in a ``CE availability'' message, which is sent by the CE to a Workload Management Service. The matchmaker then uses this information to find a suitable job for the CE.
The CE uses the R-GMA servicetool to publish information about its services and states to the information services R-GMA. See chapter 5 for more details about R-GMA and the R-GMA servicetool.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the CE Monitor. This release requires v. 1.4.2 (revision 04 or greater). The Java version to be used is a configuration parameter in the glite-global-cfg.xml file. Please change it according to your version and location.
The Resource Management System must be installed on the CE node or on a separate dedicated node before installing and configuring the CE module. This release of the CE module supports PBS, Torque and LSF. A gLite deployment module for installing Torque and Maui as RMS are provided, please refer to chapter 11 for more information.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
voms.voname |
|
The names of the VOs that this CE node can serve |
|
voms.vomsnode |
|
The full hostname of the VOMS server responsible for each VO. Even if the same server is reponsible for more than one VO, there must be exactly one entry for each VO listed in the 'voms.voname' parameter. For example: 'host.domain.org' |
|
voms.vomsport |
|
The port on the VOMS server listening for request for each VO. This is used in the vomses configuration file. For example: '15000' |
|
voms.vomscertsubj |
|
The subject of the host certificate of the VOMS server for each VO. For example: ‘/C=ORG/O=DOMAIN/OU=GRID/CN=host.domain.org' |
|
pool.account.basename |
|
The prefix of the set of pool accounts to be created for each VO. Existing pool accounts with this prefix are not recreated |
|
pool.account.group |
|
The group name of the pool accounts to be used for each VO. For some batch systems like LSF, this group may need a specific gid. The gid can be set using the pool.lsfgid parameter in the LSF configuration section |
|
pool.account.number |
|
The number of pool accounts to create for each VO. Each account will be created with a username of the form prefixXXX where prefix is the value of the pool.account.basename parameter. If matching pool accounts already exist, they are not recreated. The range of values for this parameter is from 1 to 999 |
|
cemon.wms.host
|
|
The hostname of the WMS server(s) that receives notifications from this CE |
|
cemon.wms.port |
|
The port number on which the WMS server(s) receiving notifications from this CE is listening |
|
cemon.wms.host.subject |
|
Array of the host certificate subjects of the WMS server(s) that are allowed to query the CE Monitor service on this CE |
|
cemon.lrms |
|
The type of Local Resource Management System. It can be 'lsf' or 'pbs'. If this parameter is absent or empty, the default type is 'pbs' |
|
cemon.lrms.version |
|
The version of Local Resource Management System |
|
cemon.cetype |
|
The type of Computing Element. It can be 'condorc' or 'gram'. If this parameter is absent or empty, the default type is 'condorc' |
|
cemon.cluster |
|
The cluster entry point host name. Normally this is the CE host itself |
|
cemon.cluster-batch-system-bin-path |
|
The path of the lrms commands. For example: '/usr/pbs/bin' or '/usr/local/lsf/bin'. This value is also used to set the PBS_BIN_PATH or LSF_BIN_PATH variables depending on the value of the 'cemon.lrms' parameter |
|
cemon.cesebinds |
|
The CE-SE bindings for this CE node. The format is: 'queue[|queue]' se se_entry point A ‘.’ character for the queue list means all queues. Example: '.' EGEE::SE::Castor /tmp |
|
cemon.queues |
|
A list of queues defined on this CE node. Examples are: long, short, infinite, etc. |
|
pool.lsfgid |
|
The gid of the groups to be used for the pool accounts on some LSF installations, on per each pool account group. This parameter is an array of values containing one value for each VO served by this CE node. The list must match the corresponding lists in the VOMS configuration section. If this is not required by your local LSF system remove this parameter or leave the values empty |
|
use.log.parser |
|
Use a separate log parser. If the LRMS is installed on this CE node, then you can use the log parser (recommended) or let BLAHP access the logs directly. If the LRMS is installed on a separate server, then this option must be set to true to instruct BLAHP to connect to the remote log parser. Also, in this case the BLAHP log parser demon must be running on the LRMS server and listening on the same port as specified in the pbs.log.parser.port or lsf.log.parser.port parameters in the Advanced Parameters section. Valid values for this parameter are true or false. |
|
log.parser.address |
|
The IP address of the remote LRMS server running the log parser daemon. Leave this parameter empty or comment it out if the LRMS is running on this CE server or if the log parser is not used. |
|
lb.user |
|
The account name of the user that runs the local logger daemon. If the user doesn't exist it is created. In the current version, the host certificate and key are used as service certificate and key and are copied in this user's home in the directory specified by the global parameter 'user.certificate.path' in the glite-global.cfg.xml file |
|
iptables.chain |
|
The name of the chain to be used for configuring the local firewall. If the chain doesn't exist, it is created and the rules are assigned to this chain. If the chain exists, the rules are appended to the existing chain |
|
Advanced Parameters |
||
|
glite.installer.verbose
|
True |
Enable verbose output |
|
glite.installer.checkcerts |
True |
Enable check of host certificates |
|
account.discovery |
false |
Automatically discover pool accounts using pool account base names. |
|
notifications.condition |
GlueCEStateWaitingJobs<3 |
"An expression using Glue schema objects that is evaluated to instruct CE Monitor how to notify the WMS servers of its availability. If the expression evaluates to true, availability notifications are sent and the CE is added to the WMS ISM cache. If the expression evaluates to false, expiration notifications are sent and the CE is removed from the WMS ISM cache. |
|
PBS_SPOOL_DIR |
/var/spool/PBS |
The PBS spool directory |
|
LSF_CONF_PATH |
/etc |
The directory where the LSF configuration file is located |
|
pbs.log.parser.port |
33332 |
The port where the log parser is listening for log request on the PBS server. |
|
lsf.log.parser.port |
33333 |
The port where the log parser is listening for log request on the LSF server. |
|
globus.osversion |
<empty> |
The kernel id string identifying the system installed on this node. For example: '2.4.21-20.ELsmp'. This parameter is normally automatically detected, but it can be set here |
|
globus.hostdn |
<empty> |
The host distinguished name (DN) of this node. This is mormally automatically read from the server host certificate. However it can be set here. For example: 'C=ORG, O=DOMAIN, OU=GRID, CN=host/server.domain.org' |
|
condor.version |
6.7.9 |
The version of the installed Condor-C libraries |
|
condor.user |
condor |
The username of the condor user under which the Condor daemons must run |
|
condor.releasedir |
/opt/condor-6.7.9 |
The location of the Condor package. This path is internally simlinked to /opt/condor-c. This is currently needed by the Condor-C software |
|
CONDOR_CONFIG |
${condor.releasedir}/etc/condor_config |
Environment variable pointing to the Condor configuration file |
|
condor.scheddinterval |
10 |
How often should the schedd send an update to the central manager? |
|
condor.localdir |
/var/local/condor |
Where is the local condor directory for each host? This is where the local config file(s), logs and spool/execute directories are located |
|
condor.blahgahp |
${GLITE_LOCATION}/bin/blahpd |
The path of the gLite blahp daemon |
|
condor.daemonlist |
MASTER, SCHEDD |
The Condor daemons to configure and monitor |
|
condor.blahpollinterval |
120 |
How often should blahp poll for new jobs? |
|
gatekeeper.port |
2119 |
The gatekeeper listen port |
|
rgma.gin.run_ce_provider |
yes |
Run the CE backend for R-GMA Gin
|
|
lcg.providers.location |
/opt/lcg |
The location where the LCG providers are installed. |
|
System Parameters |
||
|
ce-monitor.DOCBASE |
${GLITE_LOCATION}/share/webapps/ce-monitor.war |
Location of the ce-monitor.war file. |
Table 15: CE Configuration Parameters
i. Local Logger
ii. Gatekeeper
iii. CE Monitor
Again, you find the necessary steps
described in section 6.4.
Note:
Step 1, 2 and 3 can also be performed by means of the remote site configuration
file or a combination of local and remote configuration files
Once the services have been properly configured (no service will be running) it will be necessary to start them all. To do so, follow the next step.
7. As root start the CE services by running the CE configuration file with the –start option:
/opt/glite/etc/config/scripts/glite-ce-config.py --start
The CE configuration script performs the following steps:
The CE configuration script can be run with the following command-line parameters to manage the services:
|
glite-ce-config.py --configure |
Configure the CE services |
|
glite-ce-config.py --start |
Starts all CE services (or restart them if they are already running) |
|
glite-ce-config.py --stop |
Stops all CE services |
|
glite-ce-config.py --status |
Verifies the status of all services. The exit code is 0 if all services are running, 1 in all other cases |
When the CE configuration script is run, it installs the gLite script in the /etc/inet.d directory and activates it to be run at boot. The gLite script runs the glite-ce-config.py --start command and makes sure that all necessary services are started in the correct order.
This release of the gLite Computing Element module contains a tech-preview of the Workspace Service developed in collaboration with the Globus GT4 team. This service allows a more dynamic usage of the pool accounts with the possibility of leasing an account and releasing it when it’s not needed anymore.
To use this service, an alternative configuration script has been provided:
/opt/glite/etc/config/scripts/glite-ce-wss-config.py
It requires Ant to be properly installed and configured on the server.
No specific usage instructions are provided for the time being. More information about the Workspace Service and its usage can be found at the bottom of the following page from point 8 onwards (the installation and configuration part is done by the glite-ce module):
http://www.nikhef.nl/grid/lcaslcmaps/install_wss_lcmaps_on_lxb2022
The gLite Standard Worker Node is a set of clients required to run jobs sent by the gLite Computing Element via the Local Resource Management System. It currently includes the gLite I/O Client, the Logging and Bookeeping Client, the R-GMA Client and the WMS Checkpointing library. The gLite Torque Client module can be installed together with the WN module if Torque is used as a batch system.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org/) the script glite-security-utils_installer.sh (Chapter 15). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists.
The Java JRE or JDK are required to run the R-GMA Client in the Worker Node. This release requires v. 1.4.2 (revision 04 or greater). The Java version to be used is a configuration parameter in the glite-global-cfg.xml file. Please change it according to your version and location.
The Resource Management System client must be installed on the WN before installing and configuring the WN module. This release of the CE module supports the following Resource Management Systems:
It is possible to install the Worker Node as follows:
5. Installation via APT
Install APT if not yet installed following the instructions at
../../../../../../glite-web/egee/packages/APT.asp
and install the gLite R-GMA server by executing
apt-get install glite-wn-config
6. Installation via gLite installer scripts
1. Download the latest version of the Worker Node installation script
glite-wn_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
2. Make the script executable
chmod u+x glite-wn_installer.sh
and execute it or execute it with
sh glite-wn_installer.sh
Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-rgma-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
This will install the following deployment modules:
· Worker Node
· R-GMA client (see section 6.3 for details)
· File Transfer Service Client (see section 17 for details)
· File Placement Service Client (see section 19 for details)
· Service Discovery (see section 7 for details)
· Security utils (see section 5 for details)
If the installation is performed successfully, the following components are installed:
gLite
I/O Client in /opt/glite
gLite LB Client in /opt/glite
glite R-GMA Client in /opt/glite
gLite WMS Checkpointing in /opt/glite
gLite FTS client in /opt/glite
gLite FPS client in /opt/glite
gLite Service Discovery in /opt/glite
Globus in /opt/globus
The gLite Worker Node configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-wn-config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
Since the WN is a collection of clients, the individual configuration scripts and files are also installed and they must be run. Please refer to the appropriate chapters in this guide to install and configure the clients. This chapter only deals with WN general issues.
1. Change to the configuration directory:
cd /opt/glite/etc/config
2. Copy the configuration file templates from the templates directory
cp templates/* .
3. Customize the configuration files by replacing the ‘changeme’ value in all user-defined parameters with the proper value:
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
voms.voname |
|
The names of the VOs that this WN node can serve |
|
pool.account.basename
|
|
The prefix of the set of pool account to be created. Existing pool accounts with this prefix are not recreated |
|
pool.account.group
|
|
The group name of the pool accounts to be used |
|
pool.account.number
|
|
The number of pool accounts to create. Each account will be created with a username of the form prefixXXX where prefix is the value of the pool.account.basename parameter. If matching pool accounts already exist, they are not recreated. The range of values for this parameter is 1-999 |
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output |
|
System Parameters |
||
|
wn.ServiceList
|
· glite-file-transfer-service-client · glite-file-placement-service-client · glite-io-client · glite-rgma-client |
The gLite services, clients or applications that compose this worker node. This parameter takes a comma-separated list of service names.
|
Table 16: WN Configuration Parameters
Note: Step 1,2 and 3 can also be performed by means of the
remote site configuration file or a combination of local and remote
configuration files
4. Change to the script directory:
cd /opt/glite/etc/config/scripts
5. Configure the Worker Node by executing the Worker Node configuration script:
./glite-wn-config.py --configure
Running the configuration script will automatically configure the security utils, the service discovery as well as the different clients, so there is no need to run these configuration scripts as well.
Check if any error message is displayed and if necessary fix the parameters values and restart the script. If the configuration is successful you should see at the end the message:
The gLite Worker Node was successfully configured.
6. Start the Worker Node:
./glite-wn-config.py --start
Check if any error message is displayed and if necessary fix the parameters values and restart the script.
7. Verify that the installation is successful by either running
./glite-wn-config.py --status
The Worker Node is completely configured and running.
On the Grid, the user identifies files using Logical File Names (LFN).
The LFN is the key by which the users refer to their data. Each file may have several replicas, i.e. managed copies. The management in this case is the responsibility of the File and Replica Catalog.
The replicas are identified by Site URLs (SURLs). Each replica has its own SURL, specifying implicitly which Storage Element needs to be contacted to extract the data. The SURL is a valid URL that can be used as an argument in an SRM interface (see section [*]). Usually, users are not directly exposed to SURLs, but only to the logical namespace defined by LFNs. The Grid Catalogs provide mappings needed for the services to actually locate the files. To the user the illusion of a single file system is given.
Currently gLite provides two different modules for installing the catalog on MySQL or on Oracle. The names of the modules are:
|
gilte-data-single-catalog |
è |
MySQL version |
|
gilte-data-single-catalog-oracle |
è |
Oracle version |
In what follows the installation instructions are given for a generic single catalog version. Whenever the steps or requirements differ for MySQL and Oracle it will be noted. Replace glite-data-single-catalog with glite-data-single-catalog-oracle to use the Oracle version.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JDK is required to run the Single Catalog Server. This release requires v. 1.4.2 (revision 04 or greater). The Java version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
The Oracle Instant Client is required to run the File Transfer Service. Due to license reasons, we cannot redistribute it. Version 10.1.0.3-1 can be downloaded from the Oracle Web Site.
Note that depending on the catalog you are using (Oracle or MySQL) the templates may have the oracle prefix (glite-data-single-catalog-oracle.cfg.xml for the oracle template and glite-data-single-catalog-oracle-config.py for the oracle python script). Though in the the following instructions this prefix is ommitted it should be taken into account.
|
Parameter |
Default value |
Description |
||
|
User-defined Instance Parameters per each VO |
||||
|
catalog-service-fr-mysql.VONAME |
|
Name of the Virtual Organisation which is served by the catalog instance |
||
|
catalog-service-fr-mysql.DBNAME |
|
Database name used for a catalog service |
||
|
catalog-service-fr-mysql.DBUSER |
|
Database user name owning the catalog database |
||
|
catalog-service-fr-mysql.DBPASSWORD |
|
Password for acessing the catalog database |
||
|
System Parameters |
||||
|
catalog-service-fr-mysql.DBURL |
jdbc:mysql://localhost:3306/${catalog-service-fr-mysql.DBNAME}?zeroDateTimeBehavior=convertToNull |
URL of the database |
||
Table 17: Single Catalog for MySQL Configuration Parameters for each VO instance
|
User-defined Parameters |
||
|
mysq.root.password |
|
The root password of this MySQL installation. Leave this parameter empty or remove it if no password is required. If you set this parameter, it is recommended to define it in the local service configuration file on the node, not on the public site configuration file. Example: verySecret [Type: 'string'] |
|
Advanced Parameters |
||
|
glite.installer.verbose |
True |
Enable verbose output |
|
glite.installer.checkcerts |
True |
Enable check of host certificates |
|
allow.unsecure.port |
False |
Enable using the unsecure port 8080. It can be true or false. Example: false |
|
db.force.create |
False |
If the catalog mysql database has already been created on this node, running the configuration script will drop and recreate it if this parameter is set to true. If the parameter is set to false the database will be created only if it doesn't exist. The default value is false [Type: boolean] |
|
System Parameters |
||
|
Catalog-service-fr-mysql.DOCBASE |
${GLITE_LOCATION}/share/java/glite-data-catalog-service-fr-mysql.war |
Location of the glite-data-catalog-service-fr-mysql.war file |
|
Catalog-service-fr-mysql.DBDRIVERCLASS |
org.gjt.mm.mysql.Driver |
JDBC driver classname |
|
Catalog-service-fr-mysql.MODULE.NAME |
glite-data-catalog-service-fr-mysql |
Catalog service module name |
|
catalog-service-fr-mysql.MESSAGINGON |
False |
If 'true', then a connection to the specified messaging system is attempted and messages will be produced. |
|
catalog-service-fr-mysql.MESSAGINGJNDIHOST |
|
The host of the JNDI server that contains the messaging system connetion factories and topic/queue objects. |
|
catalog-service-fr-mysql.MESSAGINGJNDIPORT |
|
The port of the JNDI server that contains the messaging system connetion factories and topic/queue objects. |
|
catalog-service-fr-mysql.MESSAGINGJMSNAME |
|
The JNDI name of the 'local' messaging server to connect to. |
|
catalog-service-fr-mysql.MESSAGINGTOPIC |
|
The JNDI name of the topic that the messages should be produced on. |
|
rgma.servicetool.activate |
True |
Turn on/off servicetool for the node. [Example: true ] [Type: 'boolean']" |
|
catalog-service-fr-mysql.httpconnector_maxThreads |
150 |
Maximum number of threads that are created for the tomcat http connector to process requests. This, in turn specifies the maximum number of concurrent requests that the Connector can handle. |
|
catalog-service-fr-mysql.httpconnector_minSpareThreads |
25 |
The number of request processing threads that will be created when this Connector is first started. The connector will also make sure it has the specified number of idle processing threads available. This attribute should be set to a value smaller than that set for maxThreads |
|
catalog-service-fr-mysql.httpconnector_maxSpareThreads |
75 |
The maximum number of unused request processing threads that will be allowed to exist until the thread pool starts stopping the unnecessary threads |
|
catalog-service-fr-mysql.httpconnector_acceptCount |
100 |
The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused |
|
catalog-service-fr-mysql.httpconnector_connectionTimeout |
600000 |
The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented |
Table 18: Single Catalog MYSQL Common Configuration Parameters
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
catalog-service-fr.VONAME |
|
Name of the Virtual Organisation which is served by the catalog instance |
|
catalog-service-fr.DBUSER |
|
Database user name owning the catalog database |
|
catalog-service-fr.DBPASSWORD |
|
Password for acessing the catalog database |
|
catalog-service-fr.DBHOST |
|
Hostname of the Oracle server ex: lxfs5502.cern.ch |
|
catalog-service-fr.DBSERVICENAME |
|
The database service name to connect to. |
|
Advanced Parameters |
||
|
catalog-service-fr.DBPORT |
1521 |
TCP port of the Oracle database. |
|
catalog-service-fr.DBURL |
Jdbc:oracle:thin:@${catalog-service-fr.DBHOST}:${catalog-service-fr.DBPORT}:${catalog-service-fr.DBSERVICENAME} |
URL of the database. Example: jdbc:oracle:thin:@lxfs5502.cern.ch:1521:devegee3 |
Table 19: Single Catalog for Oracle Configuration Parameters for each VO instance
|
Advanced Parameters |
||
|
glite.installer.verbose |
True |
Enable verbose output |
|
glite.installer.checkcerts |
True |
Enable check of host certificates |
|
allow.unsecure.port |
False |
Enable using the unsecure port 8080. It can be true or false. Example: false |
|
catalog-service-fr.MESSAGINGON |
False |
If 'true', then a connection to the specified messaging system is attempted and messages will be produced. |
|
catalog-service-fr.MESSAGINGJNDIHOST |
|
The host of the JNDI server that contains the messaging system connetion factories and topic/queue objects. |
|
catalog-service-fr.MESSAGINGJNDIPORT |
|
The port of the JNDI server that contains the messaging system connetion factories and topic/queue objects. |
|
catalog-service-fr.MESSAGINGJMSNAME |
|
The JNDI name of the 'local' messaging server to connect to. |
|
catalog-service-fr.MESSAGINGTOPIC |
|
The JNDI name of the topic that the messages should be produced on. |
|
System Parameters |
||
|
catalog-service-fr.DOCBASE |
${GLITE_LOCATION}/share/java/glite-data-catalog-service-fr.war |
Location of the glite-data-catalog-service-fr-mysql.war file |
|
catalog-service-fr.DBDRIVERCLASS |
oracle.jdbc.driver.OracleDriver |
JDBC driver classname |
|
catalog-service-fr.MODULE.NAME |
glite-data-catalog-service-fr |
Catalog service module name |
|
catalog-service-fr.oracle-jdbc.classpath |
${CATALINA_HOME}/common/lib |
Path to the Oracle JDBC drivers |
|
catalog-service-fr.oracle-instantclient.location |
/usr/lib/oracle/10.1.0.3/client/ |
Location of the Oracle Instantclient installation |
|
rgma.servicetool.activate |
True |
Turn on/off servicetool for the node |
Table 20: Single Catalog for Oracle Common Configuration Parameters
$GLITE_LOCATION/etc/config/scripts/glite-data-single-catalog-config.py –start
The Single Catalog configuration script performs the following steps:
The Fireman Catalog services are published to R-GMA using the R-GMA Service Tool service. The Service Tool service is automatically installed and configured when installing and configuring the Catalog modules. The Catalogs configuration file contains a separate configuration section (an <instance/>) for each Catalog sub-service. The required values must be filled in the configuration file before running the configuration script.
For more details about the R-GMA Service Tool service refer to the RGMA section in this guide.
The data movement services of gLite are responsible to securely transfer files between Grid sites. The transfer is performed always between two gLite Storage Elements having the same transfer protocol available to them (usually gsiftp). The gLite Local Transfer Service is composed of two separate services, the File Transfer Service and the File Placement Service, and a number of transfer agents.
The File Transfer Service is responsible for the actual transfer of the file between the SEs. It takes the source and destination names as arguments and performs the transfer. The FTS is managed by the site administrator, i.e. there is usually only one such service serving all VOs. The File Placement Service performs the catalog registration in addition to the copy. It makes sure that the catalog is only updated if the copy through the FTS was successful. The user will see this as a single atomic operation. The FPS is instantiated per VO. If a single node must support multiple VOs, then multiple instances of the FPS can be installed and configured.
The Data Transfer Agents perform data validation and scheduling operation. There are currently three agents, the Checker, the Fetcher and the Data Integrity Validator. They are instantiated per VO.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the R-GMA Server. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
The Oracle Instant Client is required to run the File Transfer Service. Due to license reasons, we cannot redistribute it. Version 10.1.0.3-1 can be downloaded from the Oracle Web Site.
Before installing the File Transfer Service module, it is necessary to create users in Oracle and assign specific privileges. To create a new user with the necessary privileges, do the
following as DBA:
create user <DBUSER> identified by '<DBPASSWORD>';
grant resource to <DBUSER>;
grant create session to <DBUSER>;
grant create synonym to <DBUSER>;
grant connect to <DBUSER>;
grant create any procedure to <DBUSER>;
grant create any sequence to <DBUSER>;
grant create trigger to <DBUSER>;
grant create type to <DBUSER>;
You may otionally grant debugging privileges:
grant debug any procedure to <DBUSER>;
grant debug connect session to <DBUSER>;
Per instance Parameters
|
Parameter |
Default value |
Description |
|
|
|
|||
|
User-defined Parameters |
|||
|
file-transfer.VONAME |
|
Name of the VO for a given instance. It must be the same as the corresponding FTA VO name |
|
|
file-transfer.DBHOST |
|
Hostname of the transfer database |
|
|
file-transfer.DBUSER |
|
Name of the database user owning the transfer database |
|
|
file-transfer.DBPASSWORD |
|
Password for accessing the transfer database |
|
|
file-transfer.DBSERVICENAME |
|
The database service name to connect to. It must be the same as the corresponding FTA DB service name |
|
|
Advanced Parameters |
|||
|
file-transfer.DBPORT |
1521 |
TCP port of the Oracle database
|
|
|
file-transfer.DBURL |
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=${file-transfer.DBHOST})(PORT=${file -transfer.DBPORT}))(CONNECT_DATA=(SERVICE_NAME=${file-transfer.DBSERVICENAME}))) |
|
|
|
file-transfer.SECURITY_ENABLED |
true |
If set to 'false', no authorization will be made at all,regardless of the attribute settings below and regardless of whether a secure connector is used or not. Setting to 'true' will requires the use of a secure connector and the use of an appropriately authorized certificate. |
|
|
file-transfer.SUBMIT_VOMS_ATTRIBUTES |
|
Any user with these voms attributes may submit to the service
[NEW IN 1.3] |
|
|
file-transfer.SUBMIT_MAPFILE |
${GLITE_LOCATION}/etc/glite-data-transfer-submit-mapfile |
If a client's certificate subject name is listed in this file, a client may submit jobs to the service |
|
|
file-transfer.ADMIN_VOMS_ATTRIBUTES |
|
If a user's certificate contains this VOMS attribute, they are additionally permitted to do any operation upon the service including manage channels [NEW IN 1.3] |
|
|
file-transfer.ADMIN_MAPFILE |
${GLITE_LOCATION}/etc/glite-data-transfer-manager-mapfile |
If a client's certificate subject name is listed in this file, they are additionally permitted to do any operation upon the service including manage channels. [NEW IN 1.3] |
|
file-transfer.VETO_MAPFILE
|
${GLITE_LOCATION}/etc/glite-data-${file-transfer.VONAME}-veto-mapfile
|
Path to a file containing a list of client DNs to veto. The file should contain one DN per line. [NEW IN 1.3] |
|
|
System Parameters |
|||
file-transfer-fts.DOCBASE
|
${GLITE_LOCATION}/share/java/glite-data-transfer-fts.war |
Location of the FTS WAR file |
|
|
file-transfer-fts.DBDRIVERCLASS |
oracle.jdbc.driver.OracleDriver |
Java class name of the JDBC driver |
|
|
watchdog.fts.check-command |
${GLITE_LOCATION}/bin/glite-transfer-channel-list -s https://${HOSTNAME}:8443/${file-t ransfer.VONAME}/glite-data-transfer-fts/services/ChannelManagement %%%%%%%% |
The command to be executed by the watchdog daemon to check the component status |
|
|
watchdog.fts.return-string |
list: getChannel: Channel name '%%%%%%%%' does not exist |
The expected return code from the watchdog command |
|
Table 21: File Transfer Service Oracle Configuration Parameters (per instance)
Global Parameters
|
Default value |
Description |
||
|
|
|||
|
User-defined Parameters |
|||
|
|
|
|
|
|
Advanced Parameters |
|||
|
|
|
|
|
|
glite.installer.verbose |
true |
Enable verbose output |
|
|
glite.installer.checkcerts |
true |
Enable check of host certificates |
|
|
allow.unsecure.port |
false |
Enable using the unsecure port 8080. It can be true or false. Example: false |
|
|
watchdog.enable |
true |
Flag to enable or disable the watchdog cron job |
|
|
System Parameters |
|||
|
file-transfer.oracle-instantclient.location |
/usr/lib/oracle/10.1.0.3/client/ |
Location of the Oracle Instantclient installation |
|
|
rgma.servicetool.activate |
true |
Turn on/off servicetool for the node |
|
Note that the following configuration variables have been removed from the previous version (1.2):
- file-transfer.DBINDEXNAME
- file-transfer.QUERY_ATTRIBUTE
- file-transfer.QUERY_MAPFILE
- file-transfer.CANCEL_ATTRIBUTE
- file-transfer.CANCEL_MAPFILE
The following configuration variables have been renamed:
- file-transfer.SUBMIT_ATTRIBUTE to file-transfer.SUBMIT_VOMS_ATTRIBUTES - file-transfer.MANAGER_ATTRIBUTE to file-transfer.ADMIN_VOMS_ATTRIBUTES
- file-transfer.ADMIN_MAPFILE to file-transfer.ADMIN_MAPFILE
"/C=CH/O=CERN/OU=GRID/CN=Maite Barroso Lopez 5660" .egtest
$GLITE_LOCATION/etc/config/scripts/glite-file-transfer-service-oracle-config.py –configure
$GLITE_LOCATION/etc/config/scripts/glite-file-transfer-service-oracle-config.py –start
The File Transfer Service configuration script performs the following steps:
The FTS services are published to R-GMA using the R-GMA Service Tool service. The Service Tool service is automatically installed and configured when installing and configuring the FTS module. The FTS configuration file contains a separate configuration section (an <instance/>) for each FTS sub-service. The required values must be filled in the configuration file before running the configuration script.
For more details about the R-GMA Service Tool service refer to the RGMA section in this guide.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org/) the script glite-security-utils_installer.sh (Chapter 15). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
|
|
|
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable configuration script verbose output |
|
System Parameters |
||
|
|
|
|
Table 22: File Transfer Client configuration parameters
This service provides the agents that perform the actions concerning the DataTransfers. We distinguished two different kinds of agent: the Channel Agent and the VO Agent. The Channel Agent is responsible to manage all the file transfers through a channel, i.e. the entity that represent the phisical, monodirectional link between two sites: this agent will fetch the files transfers’ requests from a Queue and submit them to the configured TransferService. The other type of agent, the VO Agent, is in charge to perform all the action that are related toa VO specific Virtual Organization, which involves applying VO policies, Catalog interaction and running VO custom actions. Moreover, we dustinguish between two possible VO Agent deployment types:
- File Transfer Service (FTS): The agent would manage job where the source and destination contains Physical File Names (SURLs or TURLs). No catalog interaction is foreseen
- File Placement Service (FPS): Extend the previous model adding the interaction with a Catalog Service, in order to retrieve the source and destination physical file names from the Logical File Names (LFNs and GUIDs) and source and destination sites. Once a transfer is completed, the new replicas are registered to the appropriate catalog.
One Channel Agent is needed for each channel available on the site, and one VO Agent is needed for each VO that what to perfoms data transfer requests. All of these agents share the same Queue, but the FTA frameworks guarantees that they interact each other in the proper way: a VO Agent is allowed to see just the jobs (and related information) that belongs to itself, in the same way a Channel Agent is not able to process requests belonging to a different channel. You can imagine that each agent act on a view of the entire Queue:
/---------------\
| Queue |
\---------------/
|-------- |
VO_1 || Vo_1 | |
Agent =====> View |-------|
|-------- Ch_1 || Channel_1
| | View <===== Agent
|-------- ||
VO_2 || Vo_2 |-------|
Agent =====> View |-------|
|-------- Ch_2 || Channel_2
| | View <===== Agent
|-------- ||
VO_3 || Vo_2 |-------|
Agent =====> View | |
|-------- |
\---------------/
The way of the Channel and the VO Agent work is the same: they periodically run some action in order to perform the step required to transfer data. The Channel Agent actions are:
- Fetch: Submit new File transfer request to the TransferService
- Check: Check the state of all the active File transfer requests and update the Queue with the retrieved information
- Cancel: Revoke active file transfers marked as canceling on the Queue
The VO Agent actions are:
- File Transfer Service:
o Allocate: Allocate a transfer job to a channel based on the source and destination of the related files
o Retry: Reschedule failed transfers that are in waiting state
o Cancel: Revoke pending (i.e. not yet processed by the Channel Agent) files transfers marked as canceling on the Queue.
- File Placement Service: adds the following actions to the FTS ones:
o Resolve: Resolve the source Logical File Names into an SURL and generate the destination SURL looking at the information provided by the Service Discovery
o Register: When a Transfer Job is completed, register the new replicas on the Catalog Service
In addition, the VO Agent allows the possibility to schedule additional custom actions that the VO may want to provide in order to perform VO-apecific tasks.
The GLite Data Transfer Agents module provides a default action for all of these types, but it would also allow extending the behavior of an agent by configuring different actions.
1. Copy the global configuration file template $GLITE_LOCATION/etc/config/template/glite-global.cfg.xml to $GLITE_LOCATION/etc/config, open it and modify the parameters if required (Table 1)
2. Copy the configuration file template from $GLITE_LOCATION/etc/config/templates/glite glite-data-transfer-agents-oracle.cfg.xml to $GLITE_LOCATION/etc/config/ glite-data-transfer-agents-oracle.cfg.xml and modify the parameters values as necessary (Table 22)
3.
Some parameters have default values; others must
be changed by the user. All parameters that must be changed have a token value
of changeme.
The following parameters can be set:
There are 3 types of instances; FTS and FPS instances (per VO), and channel instances.
Note: there are a number of system parameters defined between comments, do not change or uncomment these ones; they will be removed in the next version.
Per instance Parameters
|
Parameter |
Default value |
Description |
|
|
fts instance |
|||
|
User-defined Parameters |
|||
|
transfer-vo-agent.Name |
|
Name of the VO for a given instance. It must be the same as the corresponding FTA VO name |
|
|
|
|
|
|
|
Advanced Parameters |
|||
|
transfer-vo-agent.DefaultInterval |
3 |
The default interval, in seconds, for scheduling the VO actions |
|
|
transfer-agent.log.Priority |
WARN |
|
|
|
transfer-agent.log.Filename |
${GLITE_LOCATION_LOG}/glite-transfer-agent-${transfer-agent-vo.DeploymentType}-${file-transfer.VON AME}.log |
The location of the log file |
|
|
file-transfer.DBPORT |
1521 |
TCP port of the Oracle server |
|
|
transfer-agent-vo-actions.MaxFailures |
3 |
The maximum number of failures before moving the file to Hold |
|
|
transfer-agent-vo-actions.ResubmitDelay |
600 |
The delay in second before a Waiting transfer is resubmitted |
|
|
System Parameters |
|||
|
transfer-agent-dao-oracle.VOView |
TRUE |
Enable the VO View DAO Factory |
|
|
transfer-agent-dao-oracle.ChannelView |
FALSE |
Enable the Channel View DAO Factory |
|
|
transfer-vo-agent.DeploymentType |
fts |
The deployment type of the agent. It could be fts in case the agent should act as File Transfer Service or fps in case it should ac t as File Placement Service |
|
|
transfer-vo-agent.Allocate_Interval |
|
The interval, in seconds, to be used for scheduling the Allocate action |
|
|
transfer-vo-agent.Retry_Interval |
|
The interval, in seconds, to be used for scheduling the Retry action |
|
|
transfer-vo-agent.Cancel_Interval |
|
The interval, in seconds, to be used for scheduling the Cancel action |
|
|
transfer-agent-vo-actions.EnableUnknownSource |
false |
Enable Unknown Source Site |
|
|
transfer-agent-vo-actions.EnableUnknownDest |
false |
Enable Unknown Source Site |
|
|
transfer-agent-vo-actions.EnableUnknownDest |
false |
Enable Unknown Destination Site |
|
|
transfer-vo-agent.DisableDelegationForTransfers |
false |
If that parameter is set to true, the transfers will be performed using the related Channel Agent service credentails, otherwise they will use the client proxy certificate downloaded from MyProxy |
|
|
transfer-vo-agent.Allocate_Type |
glite:Allocate |
The name of the action type that provides the logic to allocate a transfer job to a channel |
|
|
transfer-vo-agent.Retry_Type |
glite:BasicRetry |
The name of the action type that provides the logic to retry failed transfers |
|
|
transfer-vo-agent.Cancel_Type |
glite:CancelPending |
The name of the action type that provides the logic to cancel pending (i.e. not yet processed by a channel) file transfers |
|
|
|
|
|
|
|
|
|
|
|
|
fps instance |
|
|
|
|
User-defined Parameters |
|
|
|
|
transfer-vo-agent.Name |
transfer-vo-agent.Name |
transfer-vo-agent.Name |
|
|
|
|
|
|
|
Advanced Parameters |
|
|
|
|
transfer-agent-dao-oracle.VOView |
TRUE |
Enable the VO View DAO Factory |
|
|
transfer-agent-dao-oracle.ChannelView |
FALSE |
Enable the Channel View DAO Factory |
|
|
transfer-vo-agent.DeploymentType |
fps |
The deployment type of the agent. It could be fts in case the agent should act as File Transfer Service or fps in case it should ac t as File Placement Service |
|
|
transfer-vo-agent.DefaultInterval |
3 |
The default interval, in seconds, for scheduling the VO actions |
|
|
transfer-agent.log.Priority |
WARN |
|
|
|
transfer-agent.log.Filename |
${GLITE_LOCATION_LOG}/glite-transfer-agent-${transfer-agent-vo.DeploymentType}-${file-transfer.VON AME}.log |
The location of the log file |
|
|
System Parameters |
|
|
|
|
transfer-agent-vo-actions.MaxFailures |
3 |
The maximum number of failures before moving the file to Hold |
|
|
transfer-agent-vo-actions.ResubmitDelay |
600 |
The delay in second before a Waiting transfer is resubmitted |
|
|
transfer-agent-vo-actions.EnableUnknownSource |
false |
Enable Unknown Source Site |
|
|
transfer-agent-vo-actions.EnableUnknownDest |
false |
Enable Unknown Destination Site |
|
|
transfer-vo-agent.DisableDelegationForTransfers |
false |
If that parameter is set to true, the transfers will be performed using the related Channel Agent service credentails, otherwise they will use the client proxy certificate downloaded from MyProxy |
|
|
transfer-vo-agent.Allocate_Type |
glite:Allocate |
The name of the action type that provides the logic to allocate a transfer job to a channel |
|
|
transfer-vo-agent.Retry_Type |
glite:BasicRetry |
The name of the action type that provides the logic to retry failed transfers |
|
|
transfer-vo-agent.Cancel_Type |
glite:CancelPending |
The name of the action type that provides the logic to cancel pending (i.e. not yet processed by a channel) file transfers |
|
|
transfer-vo-agent.Resolve_Type |
glite:Resolve |
The name of the action type that provides the logic to resolve source and destination physical file names starting from a logical na me (LFN or GUID) and the source and destination sites |
|
|
transfer-vo-agent.Register_Type |
glite:Resolve |
The name of the action type that provides the logic to register the new replicas into a Catalog Service when the file transfer are completed |
|
|
transfer-vo-agent.Allocate_Interval |
|
The interval, in seconds, to be used for scheduling the Allocate action |
|
|
transfer-vo-agent.Retry_Interval |
|
The interval, in seconds, to be used for scheduling the Retry action |
|
|
transfer-vo-agent.Cancel_Interval |
|
The interval, in seconds, to be used for scheduling the Cancel action |
|
|
transfer-vo-agent.Resolve_Interval |
|
The interval, in seconds, to be used for scheduling the Name Resolution action |
|
|
transfer-vo-agent.Register_Interval |
|
The interval, in seconds, to be used for scheduling the Replica Registration action |
|
|
|
|
|
|
|
Channel agent instance |
|
|
|
|
User-defined Parameters |
|
|
|
|
transfer-channel-agent.Name |
|
The name of the Channel which the agent is responsible for |
|
|
Advanced Parameters |
|
|
|
|
transfer-agent-dao-oracle.VOView |
false |
Enable the VO View DAO Factory |
|
|
transfer-agent-dao-oracle.ChannelView |
true |
Enable the Channel View DAO Factory |
|
|
transfer-agent-ts-urlcopy.MaxTransfers |
10 |
The maximum number of transfer request that the Transfer Service can process simultaneously |
|
|
transfer-agent-ts-urlcopy.LogLevel |
DEBUG |
The Log Level for the Glite URL Copy Transfer. Allowed values are: DEBUG, INFO, WARN, and ERROR |
|
|
transfer-agent.log.Priority |
WARN |
WARN, DEBUG, INFO |
|
|
transfer-agent.log.Filename |
${GLITE_LOCATION_LOG}/glite-transfer-agent-channel-agent-${transfer-channel-agent.Name }.log |
The location of the log file |
|
|
System Parameters |
|
|
|
|
|
|
|
|
Table 21: Data Transfer Agents Oracle Configuration Parameters (per instance)
Global Parameters
|
Parameter |
Default value |
Description |
|
|
|
|||
|
User-defined Parameters |
|||
|
init.username |
|
The username of the user running the agents daemons |
|
|
init.groupname |
|
The groupname of the user running the agents daemons |
|
|
init.uid |
|
The userid of the user running the agents daemons |
|
|
init.gid |
|
The gid of the user running the agent daemons |
|
|
(file-transfer.VONAME) |
|
This parameter should be removed from the template. Do not include it in your configuration files. Bug #10055 |
|
|
file-transfer.DBHOST |
|
Hostname of the transfer database |
|
|
file-transfer.DBUSER |
|
Name of the database user owning the transfer database |
|
|
file-transfer.DBPASSWORD |
|
Password for accessing the transfer database |
|
|
file-transfer.DBSERVICENAME |
|
The database service name to connect to |
|
|
Advanced Parameters |
|||
|
|
|
|
|
|
glite.installer.verbose |
true |
Enable verbose output |
|
|
glite.installer.checkcerts |
true |
Enable check of host certificates |
|
|
watchdog.enable |
true |
Flag to enable or disable the watchdog cron job |
|
|
service.certificates.type |
host |
This parameter is used to specify if service or host certificates should be used for the services |
|
|
service.certificate.file |
|
The service certificate (public key) file location |
|
|
service.key.file |
|
The service certificate (private key) file location |
|
|
user.certificate.path |
.globus |
The location of the user certificates relative to the user home directory |
|
|
file-transfer.DBPORT |
1521 |
TCP port of the Oracle server |
|
|
transfer-agent-dao-oracle.User |
${file-transfer.DBUSER} |
DAO database user |
|
|
transfer-agent-dao-oracle.Password |
${file-transfer.DBPASSWORD} |
Password for accessing the transfer database |
|
|
transfer-agent-dao-oracle.ConnectString |
${file-transfer.DBHOST}:${file-transfer.DBPORT}/${file-transfer.DBSERVICENAME} |
The Oracle ConnectString identifying the DB |
|
|
transfer-agent-scheduler.CheckInterval |
60 |
The time interval (in seconds) used to schedule the Action Check |
|
|
file-transfer.oracle-instantclient.location |
/usr/lib/oracle/10.1.0.3/client/ |
Location of the Oracle Instantclient installation |
|
|
rgma.servicetool.activate |
true |
Turn on/off servicetool for the node |
|
|
System Parameters |
|||
|
|
|
|
|
$GLITE_LOCATION/etc/config/scripts/ glite-data-transfer-agents-oracle-config.py –configure
$GLITE_LOCATION/etc/config/scripts/ glite-data-transfer-agents-oracle-config.py –start
The Data Transfer Agents configuration script performs the following steps:
The data movement services of gLite are responsible to securely transfer files between Grid sites. The transfer is performed always between two gLite Storage Elements having the same transfer protocol available to them (usually gsiftp). The gLite Local Transfer Service is composed of two separate services, the File Transfer Service and the File Placement Service, and a number of transfer agents.
The File Placement Service is responsible for the actual transfer of the file between the SEs. It takes the source and destination names as arguments and performs the transfer. The FPS is managed by the site administrator, i.e. there is usually only one such service serving all VOs. The File Placement Service performs the catalog registration in addition to the copy (which is the main different with regards to the FTS). It makes sure that the catalog is only updated if the copy through the FPS was successful. The user will see this as a single atomic operation. The FPS is instantiated per VO. If a single node must support multiple VOs, then multiple instances of the FPS can be installed and configured.
The Data Transfer Agents perform data validation and scheduling operation. There are currently three agents, the Checker, the Fetcher and the Data Integrity Validator. They are instantiated per VO.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
The Java JRE or JDK are required to run the R-GMA Server. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
The Oracle Instant Client is required to run the File Transfer Service. Due to license reasons, we cannot redistribute it. Version 10.1.0.3-1 can be downloaded from the Oracle Web Site.
Before installing the File Transfer Service module, it is necessary to create users in Oracle and assign specific privileges. To create a new user with the necessary privileges, do the
following as DBA:
create user <DBUSER> identified by '<DBPASSWORD>';
grant resource to <DBUSER>;
grant create session to <DBUSER>;
grant create synonym to <DBUSER>;
grant connect to <DBUSER>;
grant create any procedure to <DBUSER>;
grant create any sequence to <DBUSER>;
grant create trigger to <DBUSER>;
grant create type to <DBUSER>;
You may otionally grant debugging privileges:
grant debug any procedure to <DBUSER>;
grant debug connect session to <DBUSER>;
Per instance Parameters
|
Parameter |
Default value |
Description |
|
|
|
|||
|
User-defined Parameters |
|||
|
file-transfer.VONAME |
|
Name of the VO for a given instance. It must be the same as the corresponding FTA VO name |
|
|
file-transfer.DBHOST |
|
Hostname of the transfer database |
|
|
file-transfer.DBUSER |
|
Name of the database user owning the transfer database |
|
|
file-transfer.DBPASSWORD |
|
Password for accessing the transfer database |
|
|
file-transfer.DBSERVICENAME |
|
The database service name to connect to. It must be the same as the corresponding FTA DB service name |
|
|
Advanced Parameters |
|||
|
file-transfer.DBPORT |
1521 |
TCP port of the Oracle database
|
|
|
file-transfer.DBURL |
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=${file-transfer.DBHOST})(PORT=${file -transfer.DBPORT}))(CONNECT_DATA=(SERVICE_NAME=${file-transfer.DBSERVICENAME}))) |
|
|
|
file-transfer.SECURITY_ENABLED |
true |
If set to 'false', no authorization will be made at all,regardless of the attribute settings below and regardless of whether a secure connector is used or not. Setting to 'true' will requires the use of a secure connector and the use of an appropriately authorized certificate. |
|
|
file-transfer.SUBMIT_VOMS_ATTRIBUTES |
|
Any user with these voms attributes may submit to the service
|
|
|
file-transfer.SUBMIT_MAPFILE |
${GLITE_LOCATION}/etc/glite-data-transfer-submit-mapfile |
If a client's certificate subject name is listed in this file, a client may submit jobs to the service |
|
|
file-transfer.ADMIN_VOMS_ATTRIBUTES |
|
If a user's certificate contains this VOMS attribute, they are additionally permitted to do any operation upon the service including manage channels. |
|
|
file-transfer.ADMIN_MAPFILE |
${GLITE_LOCATION}/etc/glite-data-transfer-manager-mapfile |
If a client's certificate subject name is listed in this file, they are additionally permitted to do any operation upon the service including manage channels. |
|
file-transfer.VETO_MAPFILE
|
${GLITE_LOCATION}/etc/glite-data-${file-transfer.VONAME}-veto-mapfile
|
Path to a file containing a list of client DNs to veto. The file should contain one DN per line. |
|
|
System Parameters |
|||
file-transfer-fps.DOCBASE
|
${GLITE_LOCATION}/share/java/glite-data-transfer-fps.war |
Location of the FPS WAR file |
|
|
file-transfer-fps.DBDRIVERCLASS |
oracle.jdbc.driver.OracleDriver |
Java class name of the JDBC driver |
|
|
watchdog.fps.check-command |
${GLITE_LOCATION}/bin/glite-transfer-channel-list -s https://${HOSTNAME}:8443/${file-t ransfer.VONAME}/glite-data-transfer-fts/services/ChannelManagement %%%%%%%% |
The command to be executed by the watchdog daemon to check the component status. |
|
|
watchdog.fps.return-string |
list: getChannel: Channel name '%%%%%%%%' does not exist |
The expected return code from the watchdog command |
|
Table 2: File Placement Service Oracle Configuration Parameters (per instance)
Global Parameters
|
Parameter |
Default value |
Description |
|
|
|
|||
|
User-defined Parameters |
|||
|
|
|
|
|
|
Advanced Parameters |
|||
|
|
|
|
|
|
glite.installer.verbose |
true |
Enable verbose output |
|
|
glite.installer.checkcerts |
true |
Enable check of host certificates |
|
|
allow.unsecure.port |
false |
Enable using the unsecure port 8080. It can be true or false. Example: false |
|
|
watchdog.enable |
true |
Flag to enable or disable the watchdog cron job |
|
|
System Parameters |
|||
|
file-transfer.oracle-instantclient.location |
/usr/lib/oracle/10.1.0.3/client/ |
Location of the Oracle Instantclient installation |
|
|
rgma.servicetool.activate |
true |
Turn on/off servicetool for the node |
|
"/C=CH/O=CERN/OU=GRID/CN=Maite Barroso Lopez 5660" .egtest
$GLITE_LOCATION/etc/config/scripts/glite-file-placement-service-oracle-config.py –configure
$GLITE_LOCATION/etc/config/scripts/glite-file-placement-service-oracle-config.py –start
The File Transfer Service configuration script performs the following steps:
The FPS services are published to R-GMA using the R-GMA Service Tool service. The Service Tool service is automatically installed and configured when installing and configuring the FPS module. The FPS configuration file contains a separate configuration section (an <instance/>) for each FPS sub-service. The required values must be filled in the configuration file before running the configuration script.
For more details about the R-GMA Service Tool service refer to the RGMA section in this guide.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org/) the script glite-security-utils_installer.sh (Chapter 15). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
|
|
|
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable configuration script verbose output |
|
System Parameters |
||
|
|
|
|
Table 22: File Placement Client configuration parameters
Metadata is in general a notion of 'data about data'. There are many aspects of metadata, like descriptive metadata, provenance metadata, historical metadata, security metadata, etc. Whatever is its nature, metadata is associated with items, named to be unique within the catalog.
The gLite Metadata Catalog makes no assumption on what each of these items represents (a file, a job on the grid ...). To each of these items a user may associate two sets of information:
The functionality offered allows the user to manage the schemas, set and get values of attributes, perform queries using metadata values and manage the access permissions on each individual item.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
1. Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org) the script glite-security-utils_installer.sh (Chapter 5). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists
2. Install the server host certificate hostcert.pem and key hostkey.pem in /etc/grid-security
The Java JRE/JDK is required to run the Metadata Catalog Server. This release requires v. 1.4.2 (revision 04 or greater). The Java version to be used is a parameter in the configuration file. Please change it according to your version and location.
Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
1. Download from the gLite web site the latest version of the MC installation script glite-data-metadata-catalog_install.sh. It is recommended to download the script in a clean directory
2. Make the script executable (chmod u+x glite-data-metadata-catalog_installer.sh) and execute it or execute it with sh glite-data-metadata-catalog_install.sh
3. Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-data-local-transfer-service next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
4. If the installation is performed successfully, the following
components are installed:
gLite in
/opt/glite ($GLITE_LOCATION)
MySQL-server in /usr
MySQL-client in /usr
Tomcat in /var/lib/tomcat5
5. The gLite MC configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-data-metadata-catalog-config.py.
A template configuration file is installed in
$GLITE_LOCATION/etc/config/templates/glite-data-metadata-catalog.cfg.xml
1. Copy the global configuration file template
$GLITE_LOCATION/etc/config/template/glite-global.cfg.xml
to
$GLITE_LOCATION/etc/config,
open it and modify the parameters if required (Table 1)
2. Copy the configuration file templates from
$GLITE_LOCATION/etc/config/templates/glite-data-metadata-catalog.cfg.xml
$GLITE_LOCATION/etc/config/templates/glite-security-utilities.cfg.xml
$GLITE_LOCATION/etc/config/templates/glite-rgma-common.cfg.xml
$GLITE_LOCATION/etc/config/templates/glite-rgma-gin.cfg.xml
to
$GLITE_LOCATION/etc/config
and modify the parameters values as necessary. Some
parameters have default values; others must be changed by the user. All
parameters that must be changed have a token value of changeme.
3. There are three parts in the configuration file:
First modify the common metadata catalog configuration parameters
that are not VO specific. Table 21 shows a list of the global metadata catalog configuration
variables that can be set:
Table 23: Common Metadata Catalog Configuration Parameters
Next, configure the VO specific metadata catalog configuration
parameters: In the configuration file you find a set of parameters for an
instance called ‘changeme’ grouped by the tag
<instance name=”changeme”>
Create one set of parameters for each VO you want the
metadata catalog support (by copying the corresponding <instance>
enclosed parameters and by changing the instance name for each of these
instances to the corresponding VO name.
Next adapt the parameters inside each instance accordingly. All the values with
a token value of ‘changeme’ must be changed. Table 224: VO specific instance
Metadata Catalog Configuration Parameters shows a list of variables that can be
set:
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
data.metadata-catalog.VO |
|
Name of the Virtual Organisation which is served by the catalog instance. |
|
data.metadata-catalog.DBNAME |
|
Name of Database used for the catalog service. |
|
data.metadata-catalog.DBUSER |
|
Database user name to access the catalog database. |
|
data.metadata-catalog. |
|
Password of database user specified in 'data.metadata-catalog.DBUSER'. |
|
Advanced Parameters |
||
|
System Parameters |
||
|
Data.metadata-catalog. |
jdbc:mysql://${HOSTNAME}:3306/ |
URL of the database |
|
Data.metadata-catalog. |
/${data. |
Path to the web application
|
Table 224: VO specific instance Metadata Catalog
Configuration Parameters
The next point will discuss the configuration of the R-GMA and the R-GMA related configuration parameters. Please refer to the Security Utilities chapter for a description of the parameters used by this module.
4. Configure the R-GMA servicetool:
For this you have to configure the servicetool itself as well as configure the sub-services of the Metadata catalog for the publishing via the R-GMA servicetool:
a. R-GMA servicetool configuration
Modify the common configuration parameters of R-GMA that can be found in the
file
glite-rgma-common.cfg.xml
Some parameters have default values; others must be
changed by the user. All parameters that must be changed have a token value of changeme.
Table 7 shows a list of the parameters that can be set. More details can be
found in section 6.4.
b. Service Configuration for the R-GMA
servicetool
Modify the R-GMA servicetool related configuration
values that are located in the metadata catalog configuration file
glite-data-metadata-catalog.cfg.xml
that was mentioned before.
In this file, you will find one instance of a set of
the rgma servicetool parameters for one VO that are grouped by the tag
<instance name="Metadata Catalog for
VO changeme"
service="rgma-servicetool">
Create one instance (grouped parameters) per VO that
your metadata catalog is supporting, replace the ‘changeme’ in the instance
name (see above) by the name of your VO and set the parameter
‘vo.name’
also to the name of your VO. The other parameters in
the instance have default values and don’t need to be changed. Table 8 on shows the general list of parameters for each instance
for the publishing via the R-GMA servicetool. Again, you find the necessary
steps described in section 6.4
Note:
Step 1, 2 and 3 can also be performed by means of the remote site configuration
file or a combination of local and remote configuration files
5. As root run the Metadata Catalog configuration file with the
–configure option in order to configure the services
$GLITE_LOCATION/etc/config/scripts/glite-data-metadata-catalog-config.py
–configure
6. As root run the Metadata Catalog configuration file with the –start
option so that all the services are started
$GLITE_LOCATION/etc/config/scripts/glite-data-metadata-catalog-config.py
–start
7. The Metadata Catalog is now ready.
The Metadata Catalog configuration script performs the following steps:
1. Reads the following environment variables if set in the environment
or in the global gLite configuration file $GLITE_LOCATION/etc/config/glite-global.csf.xml:
GLITE_LOCATION_VAR [default is /var/glite]
GLITE_LOCATION_LOG [default is /var/log/glite]
GLITE_LOCATION_TMP [default is /tmp/glite]
2. Sets the following environment variables if not already set using
the values set in the global and R-GMA configuration files:
GLITE_LOCATION [=/opt/glite if not set
anywhere]
CATALINA_HOME to the location specified in the global
configuration file
[default is
/var/lib/tomcat5/]
JAVA_HOME to the location specified in
the global
configuration file
3. Configures the gLite Security Utilities module
4. Verifies the JAVA installation
5. Checks the configuration values
6. Stops MySQL server if it is running
7. Starts mySQL server
8. Sets the MySQL root password
9. Stops Tomcat
10. Configures Tomcat
11. Configures the different VO instances inside Tomcat:
12. Creates the DB user in MySQL
13. Configures the context.xml in Tomcat
14. Installs the web service for the VO
15. Configures the R-GMA servicetool and servicetool instances
16. Stops MySQL server
GLite I/O server consists basically on the server of the AliEn aiod project, modified to support GSI authentication, authorization and name resolution plug-ins, together with other small features and bug fixes.
It includes plug-ins to access remote files using the dcap or the rfio client library.
It can interact with the FiReMan Catalog, the Replica Metadata Catalog and Replica Location Service, with the File and Replica Catalogs or with the Alien file catalog.
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
4. Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils (gLite Security Utilities) can be installed by downloading and running from the gLite web site (http://www.glite.org/) the script glite-security-utils_installer.sh (Chapter 5). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl, glite-mkgridmap and mkgridmap.py scripts and sets up cron jobs that periodically check for updated revocation lists and grid-mapfile entries
5. Customize the mkgridmap configuration file $GLITE_LOCATION/etc/glite-mkgridmap.conf by adding the required VOMS server groups. The information in this file is used to run the glite-mkgridmap script during the Security Utilities configuration to produce the /etc/grid-security/grid-mapfile
6. Install the server host certificate hostcert.pem and key hostkey.pem in /etc/grid-security
With some configuration of the Castor SRM, it is necessary to register the host DN of the gLite I/O Server in the Castor SRM server gridmap-file.
1. Download from the gLite web site the latest version of the gLite I/O server installation script glite-io-server_installer.sh. It is recommended to download the script in a clean directory
7. Make the script executable (chmod u+x glite-io-server_installer.sh) and execute it or execute it with sh glite-io-server_installer.sh
8. Run the script as root. All the required RPMS are downloaded from the gLite software repository in the directory glite-io-server next to the installation script and the installation procedure is started. If some RPM is already installed, it is upgraded if necessary. Check the screen output for errors or warnings.
9. If the installation is performed successfully, the following
components are installed:
10. gLite I/O Server in /opt/glite
11. Globus in /opt/globus
12. The
gLite I/O server configuration script is installed in
$GLITE_LOCATION/etc/config/scripts/glite-io-server-config.py.
A template configuration file is installed in
$GLITE_LOCATION/etc/config/templates/glite-io-server.cfg.xml
13. The gLite I/O server installs the R-GMA servicetool to publish its information to the information system R-GMA. The details of the installation of the R-GMA servicetool are described in section 6.4.
14.
|
Common parameters
All parameters defined in this table are common to all instances.
|
||
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
I/O Daemon initialization parameters |
||
|
init.username |
|
The username of the user running the I/O Daemon. If using a astor with a castor SRM, in some configurations this user must be a valid user on the Castor server. If the user doesn't exist on this I/O Server, it will be created. The uid specified in the 'init.uid' parameters may be used. |
|
init.groupname |
|
The groupname of the user running the I/O Daemon. If using a Castor SRM, in some configurations this group must be a valid user on the Castor server. If the group doesn't exist I/O Server, it will be created. The gid specified in the 'init.gid' parameters may be used. |
|
init.uid |
|
The userid of the user running the I/O Daemon. If using a Castor SRM, in some configurations the same uid of the Castor user specified in the 'init.username' parameter must be set. Leave this parameter empy or comment it out to use a system assigned uid. |
|
init.gid |
|
The gid of the user running the I/O Daemon. If using a Castor SRM, in some configurations the same gid of the Castor group specified in the 'init.groupname' parameter must be set. Leave this parameter empy or comment it out to use a system assigned gid. |
|
voms.voname |
|
The names of the VOs that this I/O Server node can serve. |
|
voms.vomsnode |
|
The full hostname of the VOMS server responsible for each VO. Even if the same server is reponsible for more than one VO, there must be exactly one entry for each VO listed in the 'voms.voname' parameter. Example: host.domain.org |
|
Advanced Parameters |
||
|
General gLite initialization parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output |
|
glite.installer.checkcerts |
true |
Enable check for host certificate |
|
Security Utilities parameters |
||
|
install.mkgridmap.cron |
true |
Install the glite-mkgridmap cron job and run it once. Possible values are 'true' (install the cron job) or 'false' (do not install the cron job) |
|
SSL Configuration parameters |
||
|
service.certificates.type |
host |
This parameter is used to specify if service or host certificates should be used for the services. If this value is 'host', the existing host certificates are copied to the service user home in the directory specified by the 'user.certificate.path' parameter; the 'service.certificate.file' and 'service.key.file' parameters are ignored. If the value is 'service' the service certificates must exist in the location specified by the 'service.certificate.file' and 'service.key.file' parameters |
|
service.certificate.file |
|
The service certificate (public key) file location. |
|
service.key.file |
|
The service certificate (private key) file location. |
|
user.certificate.path |
|
The location of the user certificates relative to the user home directory. This parameter overrides the global one set in the glite-global.cfg.xml file |
|
I/O Daemon parameters |
||
|
io-daemon.MaxTransfers |
20 |
The maximum number of concurrent transfers |
|
io-resolve-common.SePort |
8443 |
The port of the remote file operation server |
|
io-resolve-common.RootPathRule |
abs_dir |
The rule to be applied to define the path for creating new files. Allowed values are: * abs_dir: The file name will be created by appending the file name to the path specified by RootPath configuration parameter * user_home_dir: the file name will be created by appending the file name to a path specified by the RootPath configuration parameter, a directory with the user name first letter and then the complete user name. [Note: Since at the moment the user name that is retrieved is the distinguished name, using that option is not suggested] |
|
io-authz-fas.FileOwner |
<empty> |
When checking the credentials, perform an additional check on that name to verify it was the user's name. Default value is an empty string, that means that this additional test is not performed |
|
io-authz-fas.FileGroup |
<empty> |
When checking the credentials, perform an additional check on that name to verify it was one of the user's groups. Default value is an empty string, that means that this additional test is not performed |
|
io-resolve-fireman.OverwriteOwnership |
false |
Overwrite the ownership of the file when creating it. If set to true, the newly created file will have as owner the values set by the FileOwner and FileGroup configuration parameters. |
|
io-resolve-fireman.FileOwner |
<empty> |
The name of the group that will own any newly created file. This parameter is meaningful only if OverwriteOwnership is set to true. In case this parameter is not set, the Replica Catalog default will apply. Default value is an empty string. |
|
io-resolve-fireman.FileGroup |
<empty> |
The name of the group of any newly created file. This parameter is meaningful only if OverwriteOwnership is set to true. In case this parameter is not set, the Replica Catalog default will apply. Default value is an empty string. |
|
io-resolve-fr.OverwriteOwnership |
false |
Overwrite the ownership of the file when creating it. If set to true, the newly created file will have as owner the values set by the FileOwner and FileGroup configuration parameters. Default value is false. |
|
io-resolve-fr.FileOwner |
|
The name of the user that will own any newly created file. This parameter is meaningful only if OverwriteOwnership is set to true. In case this parameter is not set, the Replica Catalog default will apply. Default value is an empty string. |
|
io-resolve-fr.FileGroup |
|
The name of the group of any newly created file. This parameter is meaningful only if OverwriteOwnership is set to true. In case this parameter is not set, the Replica Catalog default will apply. Default value is an empty string |
|
System Parameters |
||
|
I/O Daemon parameters |
||
|
io-daemon.EnablePerfMonitor |
false |
Enable the Performace Monitor. If set to true, a process will be spawned to monitor the performance of the server and create some of the statistics. |
|
io-daemon.PerfMonitorPort |
9998 |
The Performace Monitor port |
|
io-daemon.CacheDir |
<empty> |
The directory where cached files should be stored |
|
io-daemon.CacheDirSize |
0 |
The maximum size of the directory where cached files should be stored |
|
io-daemon.PreloadCacheSize |
5000000 |
The size of the preloaded cache |
|
io-daemon.CacheLevel |
0 |
The gLite I/O Cache Level |
|
io-daemon.ResyncCache |
false |
Resynchronize the cache when the daemon starts |
|
io-daemon.TransferLimit |
100000000 |
The maximum bitrate expressed in b/s that should be used |
|
io-daemon.CacheCleanupThreshold |
90 |
When a cache clean up is performed, the cache will be clean up to that value. It should be intended as percentage, i.e. a value of 70 means that after a cleanup, the cache will be filled up to 70% of its maximum size |
|
io-daemon.CacheCleanupLimit |
90 |
Represent the limit that, when reached, triggers a cache clean up. It should be intended in percentage, i.e. a value of 90 means that when the 90% of cache is filled, the cached will be cleaned up up to the value specified by the CacheCleanupThreshold configuration parameter |
|
io-daemon.RedirectionList |
<empty> |
The redirection list that should be used in the Cross-Link Cache Architecture |
|
io-resolve-common.DisableDelegation |
true |
Don't use client's delegated credentials to contact the Web Services |
|
io-authz-catalogs.DisableDelegation |
true |
Don't use client's delegated credentials to contact the RMC Service |
|
io-authz-fas.DisableDelegation |
true |
Don't use client's delegated credentials to contact the FAS service |
|
io-resolve-fr.DisableDelegation |
true |
Don't use client's delegated credentials to contact the RMC Service |
|
VO dependant gLite I/O Server instances
A separate gLite I/O Server instance can be installed for each VO that this server must support. The values in this table (‘<instance>’ section in the configuration file) are specific to that instance. At least one instance must be defined. Create additional instance sections for each additional VO you want to support on this node. |
||
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
vo.name |
|
The name of the VO served by this instance. |
|
io-daemon.Port |
|
The port to be used to contact the server. Please note that this port is only used for authentication and session establishment messages. When the real data transfer will be performed using a QUANTA parallel TCP stream a pool of sockets are opened on the server side binding a tuple of available ports from 50000 to 51000. This port should not be higher than 9999 and different I/O server instances should not run on contigous ports (for example set one to 9999 and another one to 9998) |
|
init.CatalogType |
|
The type of catalog to use: - 'catalogs' (EDG Replica Location Service and Replica Metadata Catalog), - 'fireman' (gLite Fireman Catalog), - 'fr' (File and Replica Catalog) The parameters not used by the chosen catalog type can be removed or left empty |
|
io-resolve-common parameters are required by all types of catalogues |
||
|
io-resolve-common.SrmEndPoint |
|
The endpoint of the SRM Server. If the value starts with httpg://, GSI authentication will be used (using the CGSI GSOAP plugin), if it starts with https://, pure SSL authentication is performed, otherwise no authentication is requested. Please note that in case of a CASTOR SRM, you've always to use httpg, while in case of dCache https is required. Example: httpg://gridftp05.cern.ch:8443/srm/managerV1 |
|
io-resolve-common.SeHostname |
|
The name of the Storage Element where the files are staged. It's the hostname of the remote file operation server. At the moment this must be set to the hostname of the SRM defined in the io-resolve-common.SrmEndPoint parameter. Example: gridftp05.cern.ch |
|
io-resolve-common.RootPath |
|
The path that should be prefixed to the filename when creating new files. Example: /castor/cern.ch/user/g/glite/VO-NAME/SE/ |
|
io-resolve-common.SeProtocol |
|
The protocol to be used to contact the remote file operation server. Currently the supported values are: * rfio: use the remote file io (rfio) protocol to access remotely the file * gsidcap: for secure access to a dCache SE * dcap: for unsecure access to a dCache SE * file: use normal posix operations to access a local file (useful only for testing purposes) |
|
EDG RLS/RM parameters The parameters are only required when using the EDG catalogs. Leave them empty or comment them if not used. |
||
|
io-authz-catalogs.RmcEndPoint |
|
The endpoint of the RMC catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. This is also the value of the 'io-resolve-catalogs.RmcEndpoint' parameter. Example: https://lxb2028:8443/VO-NAME/edg-replica-metadata-catalog/services/edg-replica-metadata-catalog |
|
io-resolve-catalogs.RlsEndpoint |
|
The endpoint of the Rls catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. Example: https://lxb2028:8443/VO-NAME/edg-local-replica-catalog/services/edg-local-replica-catalog |
|
Parameters required by the Fireman and FR catalogs. |
||
|
io-authz-fas.FasEndpoint |
|
The endpoint of the Fas catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. Examples: http://lxb2024.cern.ch:8080/glite-data-catalog-service-fr/services/FAS (for FR) http://lxb2024.cern.ch:8080/glite-data-catalog-service-fr/services/FiremanCatalog (for Fireman) |
|
Fireman parameters |
||
|
io-resolve-fireman.FiremanEndpoint |
|
The endpoint of the FiReMan catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. Example: http://lxb2024.cern.ch:8080/glite-data-catalog-service-fr/services/FiremanCatalog |
|
FR parameters |
||
|
io-resolve-fr.ReplicaEndPoint |
|
The endpoint of the Replica catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. Example: http://lxb2024.cern.ch:8080/glite-data-catalog-service-fr/services/ReplicaCatalog |
|
io-resolve-fr.FileEndPoint |
|
The endpoint of the File catalog. If that value starts with httpg:// the GSI authentication will be used (using the CGSI GSOAP plugin); if it starts with https:// the SSL authentication will be used, using the CGSI GSOAP plugin in SSL compatible mode), otherwise no authentication is requested. If that value is not set, the File Catalogs will not be contacted and the io-resolve-fr plug-in will managed only GUIDs. Example: http://lxb2024.cern.ch:8080/glite-data-catalog-service-fr/services/FileCatalog |
|
Advanced Parameters |
||
|
Logging parameters |
||
|
log.Priority |
DEBUG |
The log4cpp log level. Possible values are: DEBUG, INFO, WARNING, ERROR, CRITICAL, ALERT, FATAL |
|
log.FileName |
$GLITE_LOCATION_LOG/glite-io-server-${vo.name}-${ init.CatalogType }.log |
The location of the log file for this instance |
Table 25: gLite I/O Server Configuration Parameters
15.
Note: Step 1,2 and 3 can also be performed by means of the remote site configuration file or a combination of local and remote configuration files
5.
As run the gLite I/O server configuration
file with the –start option so that all the services are started
$GLITE_LOCATION/etc/config/scripts/glite-io-server-config.py –start
The gLite I/O server configuration script performs the following steps:
GLOBUS_LOCATION [default is /opt/globus]
The gLite I/O Client provides some APIs (both posix and not) for accessing remote files using glite-io. It consists basically on a C wrapper of the AlienIOclient class provided by the org.glite.data.io-base module.
Install one or more Certificate Authorities certificates in /etc/grid-security/certificates. The complete list of CA certificates can be downloaded in RPMS format from the Grid Policy Management Authority web site (http://www.gridpma.org/). A special security module called glite-security-utils can be installed by downloading and running from the gLite web site (http://www.glite.org/) the script glite-security-utils_installer.sh (Chapter 15). The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs the glite-fetch-crl script and sets up a crontab that periodically check for updated revocation lists
|
VO dependant gLite I/O Client instances
A separate gLite I/O Client instance can be installed for each VO that this client must support. The values in this table (‘<instance>’ section in the configuration file) are specific to that instance. At least one instance must be defined. Create additional instance sections for each additional VO you want the client to support |
||
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
vo.name |
|
The name of the VO for this instance. |
|
io-client.ServerPort |
|
The port that the gLite I/O Server is listening at for this VO |
|
log.FileName |
$${HOME}/.glite-io-client-${vo.name}.log |
The location of the log file. (Note that the double $$ means that the ${HOME} variable is not expanded to its real value, but it's left as it is) |
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
io-client.Server |
changeme |
The hostname where the gLite I/O Server is running |
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable configuration script verbose output |
|
io-client.EncryptName |
true |
Enable encryption of the file name when sending a remote open request |
|
io-client.EncryptData |
false |
Enable encryption of the data block send and received |
|
log.Priority |
DEBUG |
The log4cpp log level. Possible values are: 'DEBUG', 'INFO', 'WARNING', 'ERROR', 'CRITICAL', 'ALERT', 'FATAL’ |
|
System Parameters |
||
|
io-client.CacheLevel |
7 |
The AliEn aiod Cache Level value |
|
io-client.NumberOfStreams |
1 |
Number of QUANTA tcp parallel streams |
Table 26: gLite I/O Client configuration parameters
The gLite user Interface is a suite of clients and APIs that users and applications can use to access the gLite services. The gLite User Interface includes the following components:
· Data Catalog command-line clients and APIs
· Data Transfer command-line clients and APIs
· gLite I/O Client and APIs
· R-GMA Client and APIs
· VOMS command-line tools
· Workload Managemenet System clients and APIs
· Logging and bookkeeping clients and APIs
These installation instructions are based on the RPMS distribution of gLite. It is also assumed that the target server platform is Red Hat Linux 3.0 or any binary compatible distribution, such as Scientific Linux or CentOS. Whenever a package needed by gLite is not distributed as part of gLite itself, it is assumed it can be found in the list of RPMS of the original OS distribution.
A security module called glite-security-utils is installed and configured automatically by http://www.glite.org/ by the UI installer. The module contains the latest version of the CA certificates plus a number of certificate and security utilities. In particular this module installs (for the root install) the fetch-crl script using the fetch-crl RPM from the EU-GridPMA and sets up a crontab that periodically check for updated revocation lists. In case of the non-privileged user installation the CRL update is left to the decision of the user and adding it into the user's crontab is a manual step to do.
The Java JRE or JDK are required to run the UI. This release requires v. 1.4.2 (revision 04 or greater). The JDK/JRE version to be used is a parameter in the configuration file. Please change it according to your version and location. Due to license reasons, we cannot redistribute Java. Please download it from http://java.sun.com/ and install it if you have not yet installed it.
The gLite User Interface can be installed as root or as non-privileged user. The installation procedure is virtually identical. The root installation installs by default the UI RPMS in the standard location /opt/glite.
The location of the gLite RPMS can be changed by means of the prefix command line switch.
The non-privileged user installation does not differ from the root one. The user installation is still based on the services provided by the rpm program (dependency checking, package removal and upgrade), but uses a copy of the system RPM database created in user space and used for the local user installation. This approach allows performing a non-privileged user installation and still keeping the advantages of using a package manager.
The location of the gLite UI installed by the non-privileged user is by default set to `pwd`/glite_ui (glite_ui directory in the current working directory).
The destination directory of both root and user installations can be modified by using of the basedir=<path> option of the ui installer script, where the <path> MUST be an absolute path.
The installation steps are the same in both the root and no-root installation cases:
glite-ui_installer.sh
from the gLite web site. It is recommended to download the script in a clean directory.
chmod u+x glite-ui_installer.sh
and execute it or execute it with
sh glite-ui_installer.sh
If needed, pass the basedir=<path> option to specify the target installation directory.
a)
Root installation
gLite in /opt/glite (=
GLITE_LOCATION)
Globus in /opt/globus (= GLOBUS_LOCATION)
GPT in
/opt/gpt (=
GPT_LOCATION)
b) User installation
gLite, Globus and GPT (unless already installed) are installed in the tree from `pwd`/glite_ui by removing the /opt/[glite, globus, gpt] prefix.
The GLITE_LOCATION, GLOBUS_LOCATION and GPT_LOCATION variables are set to the `pwd`/glite_ui value. If Globus and GPT are already installed before installing the gLite UI, they are not reinstalled and the existing GLOBUS_LOCATION and GPT_LOCATION can be used.
· Worker Node
· R-GMA client (see section 6.3 for details)
· File Transfer Service Client (see section 17.4 for details)
· File Placement Service Client (see section 17.4 for details)
· Service Discovery (see section 7 for details)
· Security utils (see section 5 for details)
If the installation is performed successfully, the following components are installed:
gLite
I/O Client in
/opt/glite
gLite LB Client in /opt/glite
glite R-GMA Client in /opt/glite
gLite WMS Checkpointing in /opt/glite
gLite FTS client in /opt/glite
gLite FPS client in /opt/glite
gLite Service Discovery in /opt/glite
Globus in /opt/globus
$GLITE_LOCATION/etc/config/scripts/glite-worker-node --config.py.
All the necessary template configuration files are installed into
$GLITE_LOCATION/etc/config/templates/
The next section will guide you through the different files and necessary steps for the configuration.
1. Change to the configuration directory:
cd /opt/glite/etc/config
2. Copy the configuration file templates from the templates directory
cp templates/* .
3. Customize the configuration files by replacing the ‘changeme’ value in all user-defined parameters with the proper value:
· one common <parameters> section used for all Vos. Table 24 shows the common configuration values that can be set.
· one or more <set> sections, one per each VO that the UI must be configured for. Table 23 shows the parameters per VO.
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
Name |
|
Name of set |
|
ui.VirtualOrganisation |
|
Name of the VO corresponding to this set |
|
ui.NSAddresses |
|
Array of the WMS Network Servers for this VO |
|
ui.LBAddresses |
|
Array of Logging and Bookkeeping servers corresponding to each NS server |
|
ui.MyProxyServer |
|
MyProxy server to use |
|
ui.voms.server |
|
VOMS server name for this VO |
|
ui.voms.port |
|
VOMS server port number |
|
ui.voms.cert.subject |
|
DN of the VOMS server's certificate |
|
py-ui.requirements |
|
Requirements for job matchmaking for this VO |
Table 23: UI
VO specific configuration parameters –
defined in one or several <set> sections
|
Parameter |
Default value |
Description |
|
User-defined Parameters |
||
|
py-ui.DefaultVo |
|
Default VO to connect |
|
Advanced Parameters |
||
|
glite.installer.verbose |
true |
Enable verbose output |
|
glite.installer.checkcerts |
false |
Switch on/off the checking of the existence of the host certificate files |
|
py-ui.rank |
- other.GlueCEStateEstimatedResponseTime |
Matchmaking rank.
|
|
py-ui.RetryCount |
3 |
Number of retries. |
|
py-ui.OutputStorage |
“/tmp” |
Storage of the errors. |
|
py-ui.ListenerStorage |
“/tmp” |
Storage of the outputs. |
|
py-ui.LoggingTimeout |
10 |
Timeout for logging. |
|
py-ui. |
10 |
Timeout for logging synchronization. |
|
py-ui.NSLoggerLevel |
1 |
Level of the NS Loggger. |
|
py-ui. |
1 |
Default status level. |
|
py-ui. |
1 |
Default level of logging. |
|
ui.ClientList |
· glite-file-placement-service-client · glite-file-transfer-service-client · glite-io-client · glite-rgma-client |
The gLite clients or applications that compose this user interface. [Type: ‘string’] Example: glite-rgma-client |
|
System Parameters |
||
Table 24: UI common configuration parameters
4. Run the UI configuration file
$GLITE_LOCATION/etc/config/scripts/glite-ui-config.py
The gLite User Interface is now ready.
To get the environment configured correctly, each gLite UI user MUST run the
$GLITE_LOCATION/etc/config/scripts/glite-ui-config.py
configuration script before using the glite UI for the first time.
The value of the GLITE_LOCATION variable MUST be previously communicated by the administrator of the UI installation. In this case the script creates the copy of the
$GLITE_LOCATION/etc/vomses
file in the
$HOME/.vomses
file (required by the VOMS client) and sets up the automatic sourcing of the UI instance parameters.
To assure the correct functionality of the gLite UI after the execution of the glite-ui-config.py script, it is necessary either:
1) to source the glite_setenv.[sh|csh] file in /etc/glite/profile.d/ or $HOME/.glite directory depending on the type of installation
2) log off and log in. The file with UI environment variables will be sourced automatically.
There are four suites described in this section, gLite I/O, Catalog, WMS and R-GMA.
The I/O test suite covers basic gLite I/O functionality (open file, create a file, read a file, write to a file, get info associated with a handle, close a file), some regression tests and cycles of glite-put and glite-get of several files.
The gLite IO test suite depends on glite-data-io-client, so it is recommended to install and execute the IO tests from a UI machine. The IO test suite depends on CppUnit too, that should also be installed in the machine.
This test suite is installed using glite-testsuites-data-io-server that can be obtained from the gLite web site using wget plus the URL of the rpm. The installation of the rpm will deploy the tests under $GLITE_LOCATION/test/bin directory.
Before running the test suite, check the following points:
· The user account that runs the tests must have these environment variables set:
GLITE_LOCATION (usually under /opt/glite)
GLOBUS_LOCATION (usually under /opt/globus)
LD_LIBRARY_PATH (including: $GLITE_LOCATION/lib:$GLOBUS_LOCATION/lib)
PATH (including: $GLITE_LOCATION/bin:$GLOBUS_LOCATION/bin)
· The user distinguish name that runs the tests must be included in the '/etc/grid-security/grid-mapfile' file of the gLite I/O server machine. This should be already the case if the configuration of your io-client is pointing to a valid io-server.
· Also, the user must have a voms-proxy before running the tests, typing: voms-proxy-init –voms your_vo_name
· If you use TestManager to run the tests, you have to modify the following parameters in the configuration file, /opt/glite/test/etc/glite-data-io-server/ioServerTests.xml:
Note: if all the tests that you try to run fail, check if the problem is in the configuration of your io-client, io-server or catalog. If all is correctly configured, you should be able to put a file in a SE using the glite-put command.
You can run the tests from the command line or using TestManager:
a) From the command line, you can execute the binaries that are located at $GLITE_LOCATION/test/bin, so you can run them executing: $GLITE_LOCATION/test/bin/gLite-io-****
These tests check the basic IO functionality: open a remote file, create a remote file, read a file, write to a file, set a file read/write pointer, get information about the file associated with the given handle and close a file. There are also 5 regression tests that check some of the bugs reported in Savannah. Apart from those tests, you can also run a Perl test 'run_gliteIO_test.pl' to do cycles of glite-put and glite-get of several files. As an example, to do a glite-put and glite-get of 1000 files of a maximum size of 1MB in
1000 cycles (only one file per cycle), you should type:
$GLITE_LOCATION/test/bin/run_gliteIO_test.pl -l /tmp -c 1 -f 1M -n 1 -s 1000M -o your_vo_name
Where -l specifies the log directory, -c the number of cycles to run, -f the maximal file size, -n the number of files to be transferred in a cycle, and -s the maximal total file size.
b) Using TestManager:
- If you don't have TestManager installed in your machine, you can download
the RPM from the gLite web site.
- Python version 2.2.0 or higher.
python /opt/TestManager-1.3.0/testtools/TestManager.py /opt/glite/test/etc/glite-data-io-server/ioServerTests.xml
(TestManager.py comes in the TestManager package, and ioServerTests.xml should be under $GLITE_LOCATION/test/etc/glite-data-io-server directory)
a) From the command line:
The test results can be visualized in stdout or in an XML file generated in the directory where the tests are called tests.xml
b) Using TestManager:
Load form your preferred browser the index.html file that has been created under the 'report' directory.
The Catalog test suite covers the creation and removal of directories, list entries in a directory, and the creation of entries in a directory through single and bulk operations. Additionally it includes file permission tests against the catalog secure interface.
The gLite Catalog test suite depends on the glite-data-catalog-interface and glite-data-catalog-fireman-api-c RPMs, so it is recommended to install and
execute the tests from a UI machine.
This test suite is installed using the glite-testsuites-data-catalog-fireman rpm that can be obtained from the gLite web site using wget plus the URL of the rpm. The installation of the rpm will deploy the tests under $GLITE_LOCATION/test/bin directory.
Before running the test suite, check the following points:
· The user account that runs the tests must have these environment variables set:
GLITE_LOCATION (usually under /opt/glite)
GLOBUS_LOCATION (usually under /opt/globus)
LD_LIBRARY_PATH (including: $GLITE_LOCATION/lib:$GLOBUS_LOCATION/lib)
PATH (including: $GLITE_LOCATION/bin:$GLOBUS_LOCATION/bin)
· The user must have a voms-proxy before running the tests, typing: voms-proxy-init –voms your_vo_name
· If you use TestManager to run the tests, you have to modify the following parameters in the configuration file, /opt/glite/test/etc/glite-data-catalog-fireman/ catalogsTests.xml:
You can run the tests from the command line or using TestManager:
a) From the command line, you can execute the binaries that are located at $GLITE_LOCATION/test/bin
The gLite-fireman-create-test creates a number of entries in the catalog in one single operation. This binary accepts the following parameters:
An example of calling this test may be:
$GLITE_LOCATION/test/bin/gLite-fireman-create-test -e "http://lxb2081.cern.ch:8080/egtest/glite-data-catalog-service-fr-mysql/services/FiremanCatalog" -n 1000 -p "/TestsDir/02_"
On the other hand, the gLite-fireman-create-bulk-test creates entries in bulk operations. The parameters accepted are:
As an example, we could execute:
$GLITE_LOCATION/test/bin/gLite-fireman-create-bulk-test -l -e "http://lxb2081.cern.ch:8080/egtest/glite-data-catalog-service-fr-mysql/services/FiremanCatalog" -n 1000 -s 100 -p "/TestsDir/01_"
Note: For both tests, it is supposed that the ‘TestsDir’ directory already exists in the catalog.
b) Using TestManager:
- If you don't have TestManager installed in your machine, you can download
the RPM from the gLite web site.
- Python version 2.2.0 or higher.
python /opt/TestManager-1.3.0/testtools/TestManager.py /opt/glite/test/etc/glite-data-io-server/catalogsTests.xml
(TestManager.py comes in the TestManager package, and catalogsTests.xml should be under $GLITE_LOCATION/test/etc/glite-data-catalog-fireman directory)
a) From the command line:
The test results can be visualized in stdout.
b) Using TestManager:
Check the index.html file that has been created under the 'report' directory.
The WMS test suite contains 10 tests:
You need to have access to a gLite UI in order to install the testsuite RPM
This test suite is installed using the glite-testsuites-wms-2.0.1 rpm that can be obtained from the gLite web site (e.g. ../../../../../../glite-web/egee/packages/**release**/bin/rhel30/i386/RPMS).
The installation of the rpm will deploy the tests under $GLITE_LOCATION/test/glite-wms directory.
This test suite should be run from the UI.
Before running the test suite, check the following points:
· Export the variable GSI_PASSWORD to the value of the actual password for your proxy file (required during the creation of the proxy)
bash: export GSI_PASSWORD=myPerSonalSecreForProxy1243
tcsh setenv GSI_PASSWORD myPerSonalSecreForProxy1243
· Export the variable REFVO to the name of the reference VO you want to use for the test
bash: export REFVO=egtest
tcsh: setenv REFVO egtest
· Define the Regression Test file (regressionTest.reg). A template of this file is provided at
/opt/glite/test/glite-wms/opt/edg/tests/etc/config_tests_conf/regressionTest.reg. You should modify it accordingly to your testbed setup. The CE name should be changed in the –site parameter, and the –forcingVO parameter set to the VO to be used to run the tests.
· Customize the machine names for the specific roles (CE, WMS, WNs, SE ,MyProxy) of the testbed nodes inside the file
$GLITE_LOCATION /test/glite-wms/opt/edg/tests/etc/test_site-LocalTB.conf.
Before running the tests, you should be placed in the directory $GLITE_LOCATION /test/glite-wms.
Run the set of tests by launching the MainScript (located at $GLITE_LOCATION /test/glite-wms/opt/edg/bin/MainScript) with the following options:
opt/edg/bin/MainScript --forcingVO=egtest --verbose
--regFile=/opt/glite/test/glitewms/opt/edg/tests/etc/config_tests_conf
/regressionTest.reg RTest
To keep the log in a file you can also do:
opt/edg/bin/MainScript --forcingVO=egtest --verbose
--regFile=/opt/glite/test/glitewms/opt/edg/tests/etc/config_tests_conf
/regressionTest.reg RTest | tee MyLogFile
The output of the test suite is written under /tmp/<username> in a file specified by the suite itself.
The name of the actual index.html and the tarzipped file with all required HTML for all tests is stated at the end of the test execution in the standard output.
For example the suite shows the following 2 lines at the end of its execution:
HTML in: /tmp/reale/050401-003320_LocalTB/index.html
TarBall in: lxb1409.cern.ch /tmp/reale/050401-003320_LocalTB/tarex.tgz
Normally this needs to be put in the doc root of your Web Server, and to be unzipped and untared there.
The log file of the execution should normally be copied to the “annex” subdir of the directory structure you get by unzipping and untaring the tarex.tgz, and be renamed there as “MainLog".
The HTML output allows for the monitor of the test execution, examination of the test log files, contains a detailed description of each test performed and displays the time required for the execution of the test itself.
The WMS validation test suite currently consists of a single regression test for bug number 8663.
The WMS test suite depends on the VOMS and WMS client being there, and has been designed to be executed from a UI machine.
This test suite is installed using glite-testsuites-wms-validation rpm that can be obtained from the gLite web site using wget plus the URL of the rpm. The installation of the rpm will deploy the test under $GLITE_LOCATION/test/bin directory.
Before running the test suite, check the following points:
The user account that runs the tests must have these environment variables set:
GLITE_LOCATION (usually under /opt/glite)
LD_LIBRARY_PATH (including: $GLITE_LOCATION/lib:$GLOBUS_LOCATION/lib)
PATH (including: $GLITE_LOCATION/bin:$GLOBUS_LOCATION/bin)
The user should be authorized to execute a job on the grid.
Also, the user must have a voms-proxy to run the tests in batch mode, typing: voms-proxy-init –voms your_vo_name. If a voms proxy cannot be found the test will try to create one, prompting for the certificate passphrase.
You can run the tests from the command line, executing the binary:
$GLITE_LOCATION/test/bin/job-list-match-bug-8663-test.sh [OPTIONS]
The test will perform a series of glite-job-list-match for a configurable amount of time, with a configurable time step.
The parameters that can be set from the command line are:
· the time one wants the test to last (with -t)
· the time one wants the test to sleep between successive matches (with -s)
· the VO name (with -v)
· the parent directory where one wants the directory containing the results (with -d, this parameter is optional, the default being the directory from which the test is executes)
The test tries to find a computing element for a very simple jdl, with no requirements, it is just the echo of “Hello World”, and so the match returns the list of all CEs available at that time.
The result of the test is a pdf file showing a plot of the available Ces during the time of the test. It also stores the file called “matched_sites.out” on which the plot is based showing the number of matching Ces as a function of time, and a file called “matched_sites.txt” giving the names of the Ces with attached queues as a function of time.
This test suite implements the test plan described at:
https://edms.cern.ch/document/568064
The tests implemented are:
test1: Creates a CONTINUOUS Primary Producer and Consumer locally, inserts one
tuple and checks it can be consumed.
test2: Creates a LATEST Primary Producer and Consumer locally, inserts one
tuple and checks it can be consumed.
test3: Creates a HISTORY Primary Producer and Consumer locally, inserts one
tuple and checks it can be consumed.
test4A: Creates a CONTINUOUS Primary Producer and Consumer locally, inserts
1000 tuples and checks they can be consumed (MEMORY storage).
test4B: Creates a LATEST Primary Producer and Consumer locally, inserts 1000
tuples and checks they can be consumed (DATABASE storage).
test4C: Creates a HISTORY Primary Producer and Consumer locally, inserts 1000
tuples and checks they can be consumed (DATABASE storage).
test5: Submits a job to the Grid to create a HISTORY Primary Producer and
insert 1000 tuples. Waits for job to complete, then creates a HISTORY
consumer locally to check the tuples can be consumed (DATABASE storage).
test6: As test5, but with 10 jobs each publishing 100 tuples.
test7: Creates a HISTORY Primary Producer locally and inserts 1000 tuples,
then submits a job to the Grid to create a HISTORY Consumer to check
the tuples can be consumed (DATABASE storage).
test8: As test 7, but with 10 jobs each consuming the 1000 tuples.
test9: (will only do this if time)
test10: Checks retention periods and termination intervals are respected.
test11: (not sure this is possible from a UI as a standard user)
test12: Checks a (configurable) list of tables for reasonable content.
NB. For test4, these are the only three combinations of query type and storage that are supported by the RC1 server code. Tests for the remaining other combinations will be added when the server supports them (RC2?).
These tests are designed to be run on a gLite UI machine with the Workload Management System and R-GMA client (C++ API) software installed.
This test suite is installed using the glite-testsuites-rgma RPM that can be obtained from the gLite web site (e.g. ../../../../../../glite-web/egee/packages/**release**/bin/rhel30/i386/RPMS).
The installation of the rpm will deploy the tests under $GLITE_LOCATION/test/rgma directory.
The GLITE_LOCATION environment variable must be defined (so you should source glite_setenv.sh before running these tests). The RGMA_HOME environment variable will default to GLITE_LOCATION if it is not set explicitly.
You must have a valid Grid proxy certificate to run these tests (e.g. by running voms-proxy-init). The X509_USER_PROXY environment variable will default to /tmp/x509up_u${UID} if it is not set explicitly.
You must also have set up the gLite Grid job submission environment, i.e. the commands glite-job-submit, glite-job-status and glite-job-output must work.
There are some user-configurable parameters in "testprops.txt"; one of them, TEST_API, selects the R-GMA API source code to use. The valid values are CPP, C (default) and JAVA. There are additional parameters to allow timings to be adjusted if tests fail due to very slow systems causing timeouts. You should not normally need to change these.
To run the tests, change to a working directory (e.g. /tmp) and run the script (with no parameters, e.g. /home/.../test1.sh). The script will create a sub-directory named after the test and process id in the current directory and place any working files there. All diagnostics (including test success or failure messages) will be written to standard error. All tests return 0 on success of 1 on error.
The script will create a sub-directory named after the test and process id in the current directory and place any working files there. All diagnostics (including test success or failure messages) will be written to standard error. All tests return 0 on success of 1 on error.
This is an example of local service configuration file for a Computing Element node using PBS as batch system.
<!-- Default configuration parameters for the gLite CE Service -->
<config>
<parameters>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- User-defined parameters - Please change them -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- VOs configuration
These parameters are matching arrays of values containing one value
for each VO served by this CE node -->
<voms.voname
description="The names of the VOs that this CE node can serve">
<value>EGEE</value>
</voms.voname>
<voms.vomsnode
description="The full hostname of the VOMS server responsible for each VO.
Even if the same server is reponsible for more than one VO, there must
be exactly one entry for each VO listed in the 'voms.voname' parameter.
For example: 'host.domain.org'">
<value>lxb000.cern.ch</value>
</voms.vomsnode>
<voms.vomsport
description="The port on the VOMS server listening for request for each VO
This is used in the vomses configuration file
For example: '15000'">
<value>17001</value>
</voms.vomsport>
<voms.vomscertsubj
description="The subject of the host certificate of the VOMS
server for each VO. For example: '/C=ORG/O=DOMAIN/OU=GRID/CN=host.domain.org'">
<value>/C=CH/O=CERN/OU=GRID/CN=lxb000.cern.ch'</value>
</voms.vomscertsubj>
<!-- Pool accounts configuration
The following parameters must be set for both LSF and PBS/Torque systems
The pool accounts are created and configured by default if these parameters
are defined. You can remove these parameters to skip pool accounts configuration,
however it is better to configure the parameters and let the script verify
the correctness of the installation.
These parameters are matching arrays of values containing one value
for each VO served by this CE node. The list must match
the corresponding lists in the VO configuration section -->
<pool.account.basename
description="The prefix of the set of pool accounts to be created for each VO.
Existing pool accounts with this prefix are not recreated">
<value>egee</value>
</pool.account.basename>
<pool.account.group
description="The group name of the pool accounts to be used for each VO.
For some batch systems like LSF, this group may need a specific gid. The gid can be
set using the pool.lsfgid parameter in the LSF configuration section">
<value>egeegr</value>
</pool.account.group>
<pool.account.number
description="The number of pool accounts to create for each VO. Each account
will be created with a username of the form prefixXXX where prefix
is the value of the pool.account.basename parameter. If matching pool accounts already
exist, they are not recreated.
The range of values for this parameter is from 1 to 999">
<value>40</value>
</pool.account.number>
<!-- CE Monitor configuration
These parameters are required to configure the CE Plugin for the
CE Monitor web service. More information about the following
parameters can be found in $GLITE_LOCATION/share/doc/glite-ce-ce-plugin/ce-info-readme.txt
or in the CE chapter of the gLite User Manual -->
<cemon.wms.host
description="The hostname of the WMS server that receives notifications from this CE"
value="lxb0001.cern.ch"/>
<cemon.wms.port
description="The port number on which the WMS server receiving notifications from this CE
is listening"
value="8500"/>
<cemon.lrms
description="The type of Local Resource Managment System. It can be 'lsf' or 'pbs'
If this parameter is absent or empty, the default type is 'pbs'"
value="pbs"/>
<cemon.cetype
description="The type of Computing Element. It can be 'condorc' or 'gram'
If this parameter is absent or empty, the default type is 'condorc'"
value="condorc"/>
<cemon.cluster
description="The cluster entry point host name. Normally this is the CE host itself"
value="lxb0002.cern.ch"/>
<cemon.static
description="The name of the configuration file containing static information"
value="${GLITE_LOCATION}/etc/glite-ce-ce-plugin/ce-static.ldif"/>
<cemon.cluster-batch-system-bin-path
description="The path of the lrms commands. For example: '/usr/pbs/bin' or '/usr/local/lsf/bin'
This value is also used to set the PBS_BIN_PATH or LSF_BIN_PATH variables depending on the value
of the 'cemon.lrms' parameter"
value="/usr/pbs/bin"/>
<cemon.cesebinds
description="The CE-SE bindings for this CE node. There are three possible format:
configfile
'queue[|queue]' se
'queue[|queue]'se se entry point
A . character for the queue list means all queues
Example: '.' EGEE::SE::Castor /tmp">
<value>'.' EGEE::SE::Castor /tmp </value>
</cemon.cesebinds>
<cemon.queues
description="A space-separated list of the queues defined on this CE node
Example: blah-pbs-egee-high"
value=" blah-pbs-egee-high "/>
<!-- <!-- LSF configuration
The following parameters are specific to LSF. They may have to be set
depending on your local LSF configuration.
If LSF is not used, remove this section -->
<pool.lsfgid
description="The gid of the groups to be used for the pool accounts on some LSF installations,
on per each pool account group. This parameter is an array of values containing one value
for each VO served by this CE node. The list must match
the corresponding lists in the VOMS configuration section
If this is not required by your local LSF system remove this parameter or leave the values empty">
<value>changeme</value>
</pool.lsfgid>
-->
<!-- Condor configuration -->
<condor.wms.user
description="The username of the condor user under which
the Condor daemons run on the WMS nodes that this CE serves"
value="wmsegee"/>
<!-- Logging and Bookkeeping -->
<lb.user
description="The account name of the user that runs the local logger daemon
If the user doesn't exist it is created. In the current version, the
host certificate and key are used as service certificate and key and are
copied in this user's home in the directory specified by the global
parameter 'user.certificate.path' in the glite-global.cfg.xml file"
value="lbegee"/>
<!-- Firewall configuration -->
<iptables.chain
description="The name of the chain to be used for configuring the local firewall.
If the chain doesn't exist, it is created and the rules are assigned to this chain.
If the chain exists, the rules are appended to the existing chain"
value="EGEE-DEFAULT-INPUT"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- Advanced parameters - Change them if you know what you're doing -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- gLite configuration -->
<glite.installer.verbose
description="Enable verbose output"
value="true"/>
<glite.installer.checkcerts
description="Enable check of host certificates"
value="true"/>
<!-- PBS configuration
The following parameters are specific to PBS. They may have to be set
depending on your local PBS configuration.
If PBS is not used, remove this section -->
<PBS_SPOOL_DIR
description="The PBS spool directory"
value="/usr/spool/PBS"/>
<!-- LSF configuration
The following parameters are specific to LSF. They may have to be set
depending on your local LSF configuration.
If LSF is not used, remove this section -->
<LSF_CONF_PATH
description="The directory where the LSF configuration file is located"
value="/etc"/>
<!-- Globus configuration -->
<globus.osversion
description="The kernel id string identifying the system installed on this node.
For example: '2.4.21-20.ELsmp'. This parameter is normally automatically detected,
but it can be set here"
value=""/>
<globus.hostdn
description="The host distinguished name (DN) of this node. This is mormally automatically
read from the server host certificate. However it can be set here. For example:
'C=ORG, O=DOMAIN, OU=GRID, CN=host/server.domain.org'"
value=""/>
<!-- Condor configuration -->
<condor.version
description="The version of the installed Condor-C libraries"
value="6.7.3"/>
<condor.user
description="The username of the condor user under which
the Condor daemons must run"
value="condor"/>
<condor.releasedir
description="The location of the Condor package. This path is internally simlinked
to /opt/condor-c. This is currently needed by the Condor-C software"
value="/opt/condor-6.7.3"/>
<CONDOR_CONFIG
description="Environment variable pointing to the Condor
configuration file"
value="${condor.releasedir}/etc/condor_config"/>
<condor.scheddinterval
description="How often should the schedd send an update to the central manager?"
value="10"/>
<condor.localdir
description="Where is the local condor directory for each host?
This is where the local config file(s), logs and
spool/execute directories are located"
value="/var/local/condor"/>
<condor.blahgahp
description="The path of the gLite blahp daemon"
value="$GLITE_LOCATION/bin/blahpd"/>
<condor.daemonlist
description="The Condor daemons to configure and monitor"
value="MASTER, SCHEDD"/>
<condor.blahpollinterval
description="How often should blahp poll for new jobs?"
value="120"/>
<gatekeeper.port
description="The gatekeeper listen port"
value="2119"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- System parameters - You should leave these alone -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
</parameters>
</config>
This is an example of site configuration file for the same CE node as in Appendix A. In order to propagate the full configuration from the central configuration server, the configuration file in Appendix A can be simply replaced with the following single line:
<config/>
Alternatively, any parameter left in local service file and properly defined in the case of user-defined parameters will override the values set in the site configuration file. The following file also contains a default parameters section with the parameters required by the gLite Security Utilities module. This default section is inherited by all nodes.
<!-- Default configuration parameters for the gLite CE Service -->
<siteconfig>
<parameters>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- User-defined parameters - Please change them -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<cron.mailto
description="E-mail address for sending cron job notifications"
value="egee-admin@cern.ch"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- Advanced parameters - Change them if you know what you're doing -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- Installer configuration -->
<glite.installer.verbose
description="Enable verbose output"
value="true"/>
<install.fetch-crl.cron
description="Install the glite-fetch-crl cron job. Possible values are
'true' (install the cron job) or 'false' (do not install the cron job)"
value="true"/>
<install.mkgridmap.cron
description="Install the glite-mkgridmap cron job and run it once.
Possible values are 'true' (install the cron job) or 'false' (do
not install the cron job)"
value="false"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- System parameters - You should leave these alone -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
</parameters>
<node name="lxb0002.cern.ch">
<parameters>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- User-defined parameters - Please change them -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- VOs configuration
These parameters are matching arrays of values containing one value
for each VO served by this CE node -->
<voms.voname
description="The names of the VOs that this CE node can serve">
<value>EGEE</value>
</voms.voname>
<voms.vomsnode
description="The full hostname of the VOMS server responsible for each VO.
Even if the same server is reponsible for more than one VO, there must
be exactly one entry for each VO listed in the 'voms.voname' parameter.
For example: 'host.domain.org'">
<value>lxb0000.cern.ch</value>
</voms.vomsnode>
<voms.vomsport
description="The port on the VOMS server listening for request for each VO
This is used in the vomses configuration file
For example: '170001'">
<value>15001</value>
</voms.vomsport>
<voms.vomscertsubj
description="The subject of the host certificate of the VOMS
server for each VO. For example: '/C=ORG/O=DOMAIN/OU=GRID/CN=host.domain.org'">
<value>/C=CH/O=CERN/OU=GRID/CN=lxb0000.cern.ch </value>
</voms.vomscertsubj>
<!-- Pool accounts configuration
The following parameters must be set for both LSF and PBS/Torque systems
The pool accounts are created and configured by default if these parameters
are defined. You can remove these parameters to skip pool accounts configuration,
however it is better to configure the parameters and let the script verify
the correctness of the installation.
These parameters are matching arrays of values containing one value
for each VO served by this CE node. The list must match
the corresponding lists in the VO configuration section -->
<pool.account.basename
description="The prefix of the set of pool accounts to be created for each VO.
Existing pool accounts with this prefix are not recreated">
<value>egee</value>
</pool.account.basename>
<pool.account.group
description="The group name of the pool accounts to be used for each VO.
For some batch systems like LSF, this group may need a specific gid. The gid can be
set using the pool.lsfgid parameter in the LSF configuration section">
<value>egeegr</value>
</pool.account.group>
<pool.account.number
description="The number of pool accounts to create for each VO. Each account
will be created with a username of the form prefixXXX where prefix
is the value of the pool.account.basename parameter. If matching pool accounts already
exist, they are not recreated.
The range of values for this parameter is from 1 to 999">
<value>40</value>
</pool.account.number>
<!-- CE Monitor configuration
These parameters are required to configure the CE Plugin for the
CE Monitor web service. More information about the following
parameters can be found in $GLITE_LOCATION/share/doc/glite-ce-ce-plugin/ce-info-readme.txt
or in the CE chapter of the gLite User Manual -->
<cemon.wms.host
description="The hostname of the WMS server that receives notifications from this CE"
value="lxb0001.cern.ch"/>
<cemon.wms.port
description="The port number on which the WMS server receiving notifications from this CE
is listening"
value="8500"/>
<cemon.lrms
description="The type of Local Resource Managment System. It can be 'lsf' or 'pbs'
If this parameter is absent or empty, the default type is 'pbs'"
value="pbs"/>
<cemon.cetype
description="The type of Computing Element. It can be 'condorc' or 'gram'
If this parameter is absent or empty, the default type is 'condorc'"
value="condorc"/>
<cemon.cluster
description="The cluster entry point host name. Normally this is the CE host itself"
value="lxb0002.cern.ch"/>
<cemon.static
description="The name of the configuration file containing static information"
value="${GLITE_LOCATION}/etc/glite-ce-ce-plugin/ce-static.ldif"/>
<cemon.cluster-batch-system-bin-path
description="The path of the lrms commands. For example: '/usr/pbs/bin' or '/usr/local/lsf/bin'
This value is also used to set the PBS_BIN_PATH or LSF_BIN_PATH variables depending on the value
of the 'cemon.lrms' parameter"
value="/usr/pbs/bin"/>
<cemon.cesebinds
description="The CE-SE bindings for this CE node. There are three possible format:
configfile
'queue[|queue]' se
'queue[|queue]'se se entry point
A . character for the queue list means all queues
Example: '.' EGEE::SE::Castor /tmp">
<value>'.' EGEE::SE::Castor /tmp</value>
</cemon.cesebinds>
<cemon.queues
description="A space-separated list of the queues defined on this CE node
Example: blah-pbs-egee-high"
value="blah-pbs-egee-high"/>
<!-- LSF configuration
The following parameters are specific to LSF. They may have to be set
depending on your local LSF configuration.
If LSF is not used, remove this section -->
<!-- <pool.lsfgid
description="The gid of the groups to be used for the pool accounts on some LSF installations,
on per each pool account group. This parameter is an array of values containing one value
for each VO served by this CE node. The list must match
the corresponding lists in the VOMS configuration section
If this is not required by your local LSF system remove this parameter or leave the values empty">
<value></value>
</pool.lsfgid>
-->
<!-- Condor configuration -->
<condor.wms.user
description="The username of the condor user under which
the Condor daemons run on the WMS nodes that this CE serves"
value="wmsegee"/>
<!-- Logging and Bookkeeping -->
<lb.user
description="The account name of the user that runs the local logger daemon
If the user doesn't exist it is created. In the current version, the
host certificate and key are used as service certificate and key and are
copied in this user's home in the directory specified by the global
parameter 'user.certificate.path' in the glite-global.cfg.xml file"
value="lbegee"/>
<!-- Firewall configuration -->
<iptables.chain
description="The name of the chain to be used for configuring the local firewall.
If the chain doesn't exist, it is created and the rules are assigned to this chain.
If the chain exists, the rules are appended to the existing chain"
value="EGEE-DEFAULT-INPUT"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- Advanced parameters - Change them if you know what you're doing -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- gLite configuration -->
<glite.installer.verbose
description="Enable verbose output"
value="true"/>
<glite.installer.checkcerts
description="Enable check of host certificates"
value="true"/>
<!-- PBS configuration
The following parameters are specific to PBS. They may have to be set
depending on your local PBS configuration.
If PBS is not used, remove this section -->
<PBS_SPOOL_DIR
description="The PBS spool directory"
value="/usr/spool/PBS"/>
<!-- LSF configuration
The following parameters are specific to LSF. They may have to be set
depending on your local LSF configuration.
If LSF is not used, remove this section -->
<LSF_CONF_PATH
description="The directory where the LSF configuration file is located"
value="/etc"/>
<!-- Globus configuration -->
<globus.osversion
description="The kernel id string identifying the system installed on this node.
For example: '2.4.21-20.ELsmp'. This parameter is normally automatically detected,
but it can be set here"
value=""/>
<!-- Condor configuration -->
<condor.version
description="The version of the installed Condor-C libraries"
value="6.7.3"/>
<condor.user
description="The username of the condor user under which
the Condor daemons must run"
value="condor"/>
<condor.releasedir
description="The location of the Condor package. This path is internally simlinked
to /opt/condor-c. This is currently needed by the Condor-C software"
value="/opt/condor-6.7.3"/>
<CONDOR_CONFIG
description="Environment variable pointing to the Condor
configuration file"
value="${condor.releasedir}/etc/condor_config"/>
<condor.scheddinterval
description="How often should the schedd send an update to the central manager?"
value="10"/>
<condor.localdir
description="Where is the local condor directory for each host?
This is where the local config file(s), logs and
spool/execute directories are located"
value="/var/local/condor"/>
<condor.blahgahp
description="The path of the gLite blahp daemon"
value="$GLITE_LOCATION/bin/blahpd"/>
<condor.daemonlist
description="The Condor daemons to configure and monitor"
value="MASTER, SCHEDD"/>
<condor.blahpollinterval
description="How often should blahp poll for new jobs?"
value="10"/>
<gatekeeper.port
description="The gatekeeper listen port"
value="2119"/>
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
<!-- System parameters - You should leave these alone -->
<!-- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -->
</parameters>
</node>
</siteconfig>