GlideinWMS The Glidein-based Workflow Management System

Loading

Search Results

GlideinWMS

Installation Overview

Jump to:
  1. Installation Process
  2. Possible Configurations
  3. Using the OSG Factory
  4. Configuration-based Installer
  5. glideinWMS ini file
  6. manage_glidens script
  7. Additional documents
Installation at a glance:
  1. Pre-requisites
  2. WMS Collector and Factory
  3. User Pool Collector
  4. User Pool Schedd
  5. Glidein Frontend
Upgrade Guide

Installation Process

Installation of glideinWMS is a multi-step process and depending on your intended use, will require you installing several services. The following must be installed in the correct sequence, follow the links for the details on how to install:

  1. Components and Pre-requisites and set up GSI certificates.
  2. The glidein WMS Collector and collocated glidein Factory node
  3. The glidein pool Collector node
  4. One or more scheduler nodes for user submission
  5. The Glidein Frontend
  6. Submitting a job

Services have dependencies between them. Prior to actually doing the install, it is suggested you use the manage_glideins script to validate the configuration on all nodes to resolve any errors affecting dependencies.

The configuration based installer does NOT modify any scripts that set a user environment upon log in, e.g., .bashrc file, /etc/profile.d files, et al. Instead, an environment script is created for each service in its respective "home" location. If inclusion of these scripts is required at a location, it will need to be performed manually. The only exception to this is when privilege separation is in effect, in which case, the /etc/condor/privsep_config file is created. This location is hard-coded in Condor and cannot be changed. For each of the glideinsWMS services, the scripts for setting the environment are:

  • wmscollector, usercollector, submit: condor_location/condor.sh
  • factory: install_location/factory.sh
  • vofrontend: install_location/frontend.sh

For glideinWMS services using Condor, the CONDOR_LOCATION/config.d directory will contain the Condor attributes required for that service.

If you are upgrading services already installed, please see here.

Possible Configurations

The following are recommended configurations for installing glideinWMS. If you are installing a Factory, note that only configurations with the WMS collector and Factory on the same node are supported. Also note that worker nodes must be able to access the web server on the factory and frontend nodes in order to download necessary files.

It should be noted that it is possible to install the glideinWMS across administrative boundaries (i.e. you will only install part of the glideinWMS infrastructure). See the OSG section below for an example.

Several possible configurations are below:

Two Server configuration (recommended minimum):

Three Server configuration (recommended for 1000+ glideins)

One Server configuration (Use only for test installs)

OSG Factory configuration

Members of the Open Science Grid can use the OSG factory at UCSD. In this case, only the following services are necessary:

An rpm is available to install these services and connect to the UCSD factory only. See OSG Glidein Factory for more details on how to use this setup. You will also need a proxy for the frontend to communicate and (at least) one proxy for the glideins for submission.

Note that these components are installed by default if you install the GlideinWMS VO Frontend RPM. This RPM is maintained by the Open Science Grid and is located in the OSG repository. More information on how to install it can be found at the OSG GlideinWMS VO Frontend RPM Installation guide

RPM based installer

The Open Science Grid (OSG) maintains two sets of RPMs to install the GlideinWMS VO Frontend and Factory. These RPMs install a default version of b installation but with the option to manually edit settings for more complicated configurations. Instructions can be found here:

Configuration based installer

GlideinWMS is installed with a configuration file (ini format) based installer. All information needed by the services is listed in this file before installation, with a few exceptions. For example, the factory entry details are still provided in a Q&A format during the installation process. You may also need to manually add configuration information after installation, just as you did with the Q&A version.

There are several advantages to this type of install. In addition to having all the details documented, it performs the actual installation faster and allows for re-installs more quickly. Since you have all the information in this file, you can also reproduce the same installation as needed.

As of v3.0, the Q&A installer is no longer supported (but still available in v2+). Installation is done through the manage_glideins script, located in glideinWMS/install/, and uses the ini file described above. This script offers several additional features as well, see below for more information.

NOTE: If you get an error during installation or validation that requires a change to the ini file, it is recommended that you go back and re-install ALL services. You may affect one of the dependencies that will not be validated for the current node.

glideinWMS ini configuration file

The ini file determines the installation and configuration of the various services. All ini file attributes are required. However, in several cases the value may be left empty. See the service-specific documentation for the details for each attribute.

The configuration based installer requires that the same ini file be used for all service installations. There are several areas where data is required from other services. Since most services can be installed on separate hosts, the installer can only validate data for the node being installed.

Default Section

The attributes in this section apply to all subsequent sections in the ini file unless they are overridden specifically in that section. So, if the location/value of any option in this section varies from host to host, you will need to override them in that section of the ini file. The only options in the glideinWMS.ini template will be the pacman options in the next section.

Pacman options

The 2 pacman related attributes are used to bring down the OSG/VDT client software and CA certificates if they are not already installed on the node. If you already have the OSG/VDT client and CA certificates installed on a host or you have already installed the CA certificates and are using other non-VDT client software for proxy renewals, then:

  • these options are still required but may be empty, i.e., contain no value.
  • the vdt_location option is still required but may be empty.
  • the install_vdt_client should be set to 'n'.

These are parts of the pacman related options below that should not be changed unless advised to by glideinwms-support as there may be compatiblity issues between pacman and VDT distributions. Please see below for details.

Attribute Example Description Comments
pacman_location /path-to-pacman/pacman-3.28 This will be the directory in which pacman is installed. The base level (e.g., pacman-3.28) will be used to select the pacman tarball from the pacman_url option.
The format is pacman-version.tar.gz.
The tarball will be retrieved using the pacman_url option, extracted and then removed.

You will need to specify the path to the directory, pacman-3.28. If you already have pacman-3.28 installed on your node, the installer will not attempt to bring a new pacman down. You may utitize that directory.
pacman_url http://physics.bu.edu/pacman/sample_cache/tarballs URL to retrieve pacman This is the one pacman option you should not change.

Service options

All service attributes are described in their respective install pages. Each describes what is required for validating and installing that service. For example configuration files, see here.

The manage-glideins script

This script is used to install and manage the glideinWMS services. It is located in glideinWMS/install/manage-glideins.

./manage-glideins --OPTION SERVICE --ini INIFILE [--ssh [user]] [--debug]
    This usage can be used to install, start, stop or check the status of the glidein services based on the configuration in the specified ini file.

    OPTION can be one of:
    - validate: Allows you to validate the ini file prior to installation
    - install: Install the service
    - configure: This allows you to reconfigure your service based on changes to the ini file without re-installing condor.
    For services using Condor, it will update the config.d local config files,
    For the factory and vofrontend, it will update the respective xml config files.
    - start: Start the service. Remote starting of services is possible if remote access (via ssh) is allowed.
    - stop: Stop the service. Remote starting of services is possible if remote access (via ssh) is allowed.
    - status: Return the status of the service. Remote starting of services is possible if remote access (via ssh) is allowed.

    SERVICE can be one of:
    - wmscollector
    - usercollector
    - factory
    - submit
    - vofrontend
    - rpm (Used for OSG Frontend RPM sites. Note: The 'install' action is not allowed for this service.)
    - all: can only be used with start/stop/status actions

    --ssh: allows the start/stop/status actions to be performed remotely providing the user has valid access to the other service's node via 'ssh -l' using the service's username. The '--ssh' will use the ini file specified username attribute unless an optional 'user' is specified.

    --debug: When used with start/stop/status actions, it will display the series of commands used.

./manage-glideins --install-node --ini INIFILE
    This usage allows you to install all services for the node you are installing on. There are some limitation to this.
./manage-glideins --create-entries --ini INIFILE
    This usage can be used to select new glidein entry points after the initial installation of a factory service. If will walk you through the same question and answer process querying ReSS and allowing for manual entries. It will then create a file containing the entry elements for those selected. This can then be merged with the existing Factory configuration file and a reconfiguration performed..
./manage-glideins --create-group --ini INIFILE
    This usage can be used to select new group selection criteria after the initial installation of a frontend service. If will walk you through the same question and answer process as during the installation. It will then create a file containing the group element for the criteria selected. This can then be merged with the existing frontend configuration file and a reconfiguration performed..
./manage-glideins --show-ini INIFILE
    This option allows you to view the ini file options/values. This is especially useful when the DEFAULT section is used to apply values to all sections/services.
./manage-glideins --create-template SERVICE
    This option allows you to create an ini file template for installing a single service. It contains all the required attributes for that service. It should be understood that many of the validations that would normally insure a working installation are bypassed since those validations are normally performed on the node for those services.

Additional Documents:
Banner image by Madhusudan Katti used under Creative Commons license.
Original Home URL: http://www.uscms.org/SoftwareComputing/Grid/WMS/glideinWMS. glideinWMS email support: glideinwms-support at fnal.gov