# GlideinWMS The Glidein-based Workflow Management System

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

Loading

## Search Results

## WMS Factory Design

- Overview
- Install
- Configuration
- Design
- Monitoring
- Troubleshooting

### Factory Internals

Jump to:

1. Overview
2. Program flow
3. Source code distribution
4. Configuration files
5. Encryption

Factory Design Topics:

- Factory Internals
- Entry Internals
- Glidein Internals
- Data Exchange

## 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