# GlideinWMS The Glidein-based Workflow Management System

- Home
- Download
- Glidein Frontend
- Corral Frontend
- WMS Factory
- Components
- FAQ

Loading

## Search Results

## Components

- Overview
- Prerequisites
- User Collector
- User Schedd
- GSI
- Condor

### GSI Authentication

Jump to:

1. Quick Reference
2. Required software
3. Installation

- GSI Quick Color-coded Guide

## 1. Quick Reference Guide to GSI Authentication Setup

glideinWMS uses GSI for authentication/authorization of services and clients. Each service requires a certificate (or proxy in some cases) to communicate with each other. This allows the services to communicate securely with the correct services. The table below acts as a quick reference guide for configuring GSI in glideinWMS.

Service | Certs Needed | What Installer Configures
glideinWMS Collector | Server Certificate for WMS Collector services (not needed if connecting to OSG factory) | condor_config: GSI_DAEMON_NAME contains DN of glideinWMS Collector. condor mapfile: Contains DNs of WMS Collector, Glidein Frontend, Glidein Factory.
Glidein Pool Collector | Server certificate to run user pool collector services | condor_config: GSI_DAEMON_NAME contains DNs of Glidein Pool Collector, User Schedd Nodes, glidein startd. condor mapfile: Contains DNs of Glidein Pool Collector, User Schedd Nodes, glidein startd, Glidein Frontend
User Schedd | Service certificate for submit node(s) | condor_config: GSI_DAEMON_NAME contains DNs of Glidein Pool Collector, User Schedd Node itself, Glidein Frontend, glidein startd. condor mapfile: Contains DNs of Glidein Pool Collector, User Schedd Nodes, glidein Frontend, glidein startd.
Glidein Frontend | VO frontend certificate to communicate with the glideinWMS collector and user pool components | DN of Glidein Frontend should be in the gridmapfile of glideinWMS Collector, Glidein Pool Collector and User Schedd.
Glidein proxy | Cert or Proxy for glidein submission. Should have over 24 hours before expiration and be trusted by grid entry points. For OSG, usually a VO-proxy from voms-proxy-init. | condor mapfile to be used by glidein startd will contain DN of user schedds and Glidein Pool Collector. This condor mapfile is not used by the factory itself but transferred to the glidein via staging area.
User Job Proxy | Proxy for user job | If using glExec, then some jobs will require a user proxy. This will be specified in the x509userproxy attribute of your job.

NOTE: Newer version of glideinWMS does not require factory to have proxy. Glideins can run using credentials supplied by frontend (prefered mode) but can also be configured to run with factory credentials. If the factory is configured to not use any gsi credentials, exclude factory from the list of condor_config and GSI_DAEMON_NAME in the table above.

For a visual guide to the configuration options that need to match in the frontend and factory, see this color coded chart.

The installer configures the above for you, but the below procedure explains how to configure Condor for GSI authentication by hand.

## 2. Required software

- Any Condor-supported OS .
- The OSG client software.
- The Condor distribution.

## 3. Installation instructions

The installation will assume you have installed Condor v7.0.5 or newer. The install directory is /opt/glidecondor. If you want to use a different setup, make the necessary changes.

Unless explicity mentioned, all operations are to be done as root.

### 3.1 Install OSG client

If you have not installed the OSG client in /opt/vdt already, do it now.
(Note: An EGEE/gLite Grid User Interface will work as well, but you need to replace /opt/vdt with whatever is appropriate for that installation)

To install OSG 0.6.0 client, as of the time of writing, you would execute the following as root
(please be aware that you will need gcc, g++ and python-devel installed, and that you may need -pretend-platform packman option on some systems):

> mkdir /opt/vdt
> cd /opt/vdt
> wget http://physics.bu.edu/pacman/sample_cache/tarballs/pacman-3.19.tar.gz
> tar --no-same-owner -xzvf pacman-3.19.tar.gz
> cd pacman-3.19
> source setup.sh
> cd ..
> pacman -trust-all-caches -get OSG:client
> #Do you agree to the licenses? [y/n] y
> #Would you like to enable the Condor batch system to run automatically? n
> #Would you like to setup daily rotation of VDT log files? y
> #Do you want to update the CA certification revocation lists (CRLs) automatically? [y/n] y
> #Where would you like to install CA files? r
> pacman -remove Condor
> # ignore error messages
> source setup.sh
> vdt-control --on

PS: The most up-to-date instructions can be found on https://twiki.grid.iu.edu/twiki/bin/view/ReleaseDocumentation/ClientInstallationGuide.

(Please notice that those installation instructions tell you to install in ~/client_directory, please use /opt/vdt instead)

### 3.2 Prepare the security directories and files

Create /opt/glidecondor/certs

> mkdir /opt/glidecondor/certs
> chmod a+rx /opt/glidecondor/certs

This directory will host the grid-mapfile and eventual service proxy (see below).

Now you need to select what proxy or certificate you will be used for authentication. You have essentially three options:

1. You use the host certificates located in /etc/grid-security
2. You request a service certificate for use with Condor, and put it in /opt/glidecondor/certs
3. You create and maintain a valid proxy, obtained from a personal or service certificate, in /opt/glidecondor/certs. How you keep this proxy valid (via MyProxy, kx509, voms-proxy-init from a local certificate, scp from other nodes, or other methods), is beyond the scope of this document.

Most of my test installations used option(3), but you may be better served with (1) or (2) for a large production pool.

Anyhow, most of the examples in this collection will assume you use (3), with the proxy being named /opt/glidecondor/certs/x509_service_proxy.

Note: The proxy and/or the certificate key must bereadable by the owner only! If it is either group or world readable (and/or writable), Condor will refuse to use it (since it could have been stolen and/or compromised by now).

Once you have the proxy or the certificate, you need to create /opt/glidecondor/certs/grid-mapfile and insert the DN of the proxy/cert followed by a symbolic name.

Assuming the DN of the proxy/cert to be "/DC=org/DC=doegrids/OU=Service/CN=mycondor345", you would insert:

> "/DC=org/DC=doegrids/OU=Service/CN=mycondor345" condor

The symbolic name is not really important, it has no meaning in Unix space. It is just a nickname you will use in configuration and log files.

In addition to its own DN, the grid-mapfile must contain also the DNs of all the clients and servers that will ever talk to this Condor installation:

- The DNs of other Condor nodes, i.e. the Condor Central Manager, the Condor Submit nodes and the Condor Execute nodes.
- If this is a Submit node or Execute node and your users use GSI authentication, you also need to list all the users' DNs.

Again, you will need to add nicknames to those DNs. In the case of a Submit node or Execute node running as root, the user nicknames must represent actual Unix account.

In all other cases, the nicknames have no special meanin, and are there just for use in configuration and log files.

For example, assuming this is the Central Manager, and it has two Submit nodes, with DNs "/DC=org/DC=doegrids/OU=Service/CN=schedd34" and "/DC=org/DC=doegrids/OU=Service/CN=schedd98", while all the Execute nodes are glideins, and thus share the same DN "/DC=org/DC=doegrids/OU=Service/CN=work12", the /opt/glidecondor/certs/grid-mapfilecould be:

> "/DC=org/DC=doegrids/OU=Service/CN=mycondor345" condor
> "/DC=org/DC=doegrids/OU=Service/CN=schedd34" scondor1
> "/DC=org/DC=doegrids/OU=Service/CN=schedd98" scondor2
> "/DC=org/DC=doegrids/OU=Service/CN=work12" gcondor

### 3.3 Configure Condor security

Force GSI authentication in /etc/condor/condor_config, by adding:

> ############################################################
> ## Security config
> ############################################################
> ############################
> # Authentication settings
> ############################
> SEC_DEFAULT_AUTHENTICATION = REQUIRED
> SEC_DEFAULT_AUTHENTICATION_METHODS = FS,GSI
> SEC_READ_AUTHENTICATION = OPTIONAL
> SEC_CLIENT_AUTHENTICATION = OPTIONAL
> # Grid Certificate directory
> GSI_DAEMON_TRUSTED_CA_DIR=/opt/vdt/globus/TRUSTED_CA
> ############################
> # Privacy settings
> ############################
> SEC_DEFAULT_ENCRYPTION = OPTIONAL
> SEC_DEFAULT_INTEGRITY = REQUIRED
> SEC_READ_INTEGRITY = OPTIONAL
> SEC_CLIENT_INTEGRITY = OPTIONAL
> SEC_READ_ENCRYPTION = OPTIONAL
> SEC_CLIENT_ENCRYPTION = OPTIONAL
> ############################
> # Set daemon cert location
> ############################
> GSI_DAEMON_DIRECTORY = /opt/glidecondor/certs
> # Keep this if you use a proxy
> GSI_DAEMON_PROXY = $(GSI_DAEMON_DIRECTORY)/x509_service_proxy
> # If you use a Certificate, uncomment below, pointing it to the right place, and comment the proxy line
> #GSI_DAEMON_CERT = /etc/grid-security/hostcert.pem
> #GSI_DAEMON_KEY = /etc/grid-security/hostkey.pem
> ############################
> # Where to find DN->uid mappings
> ############################
> GRIDMAP=$(GSI_DAEMON_DIRECTORY)/grid-mapfile

Since all the security is now GSI based, we don't rely on IP checks anymore. Change HOSTALLOW_WRITE in /etc/condor/condor_config, to:

> # do not use IP based controls
> HOSTALLOW_WRITE = *