GlideinWMS The Glidein-based Workflow Management System

Search Results

WMS Factory Design

Factory Internals

Program flow

The main tasks of the Factory Daemon are the startup up the Entry Daemons and the aggregation of statistics from the entries.
See picture below for an overview.

The only non trivial operation in the statistics aggregation. The Factory Daemon reads the XML files produced by the Factory Daemons, aggregates them, and writes out an aggregate XML file. It also updates the RRD files used to keep the history and creates the rrdtool graphs and HTML pages for human consumption.
See picture below for an overview.

Source code distribution

The Factory Daemon is implemented as a series of python scripts, and it does not need to be pre-compiled.

The code is spread over several python modules, some specific to the factory other shared between different parts of the glideinWMS. There are also an external dependency on the rrdtool python libraries.

The picture below shows the dependency tree.

glideFactory.py is executable.

The glideinWMS common libraries are in glideinWMS/lib directory.

Configuration files

The Factory daemon reads a single configuration file:

glidein.descript

It is located in the root of the factory configuration tree.

Only two elements of this configuration file are used:

  • Entries - The list of entries, used to launch the Entry Daemons.
  • LoopDelay - How long should it sleep between iterations.

Warning: The configuration file should never be changed by hand. It is generated and maintained by a dedicated tool.

Encryption Overview

The glidenWMS Factory creates an RSA public/private keypair. The public key is advertised so that the Frontend can use it.

When the Frontend advertises requests and credentials, it performs the following steps:

  1. Create a symmetric key for each classad
  2. Encrypt all applicable information using the symmetric key
  3. Encrypt the symmetric key with the Factory public key
  4. Advertise the classad
The Factory performs the following steps to decrypt the Frontend values:
  1. Extract the Frontend symmetric key by decrypting it using the Factory private key
  2. Use the Frontend symmetric key to decrypt all remaining encrypted parameters
Specific code modules that handle these functions can be found below.

glideFactory.main()

  • Creates glideFactoryConfig.GlideinKey with recreate == True
  • glideFactoryConfig.GlideinKey creates a new RSA private/public keypair
  • It is assumed that the Frontend symmetric key can be loaded using the symCrypto.AutoSymKey class
glideFactoryInterface.findwork and the glideFactoryCredentials module share similar logic for decrypting classads:
  • Get classads
  • For each classad:
    • Extract the Frontend symmetric key using the Factory private key
    • Use the symmetric key to decrypt the 'ReqEncIdentity' field
    • Compare 'ReqEncIdentity' to 'AuthenticatedIdentity'
      • 'AuthenticatedIdentity' is the identity that Condor places in the classad.
      • The two must match to prove that someone isn't spoofing the classad
    • Compare 'ReqEncIdentity' to the expected identity listed in the frontend.descript (to check that the Frontend advertising is authorized by the Factory)
    • Loop through the encrypted parameters and decrypt them