The Glidein Frontend will match user jobs with glidein factory ads. It is responsible for the submission of new glideins.
The VO frontend also keeps part of the configuration of a glidein, and can also provide the glidein Factory with the pilot proxies.
Note: if you are installing only the frontend and planning to connect to the OSG factory, please refer to this section: Connecting to OSG Factory
This machine needs a fast CPU and a moderate amount of memory (1GB should be enough).
The disk needed is just for binaries, config files and log files (20GB should be enough)
|Software||Notes||Install Before glideinWMS|
|Linux OS||A reasonably recent Condor-supported OS Linux OS (RH/SL4 and RH/SL5 tested at press time).||X|
|Python interpreter||v2.3.4 or above||X|
|The perl-Time-HiRes rpm.||This rpm may already be included in perl, depending on the perl version||X|
|The OSG client software.||This can be installed prior to glideinWMS, but the installer can install it inline with the glideinWMS install|
|A HTTP server, like Apache or TUX.||This should be installed prior to glideinWMS (see below)||X|
|The Condor distribution as a tarball.||The installer will use the tarball to install and configure Condor inline|
|The RRDTool package||v1.2.18 or later (see additional install notes)||X|
|The M2Crypto python library||v0.17 or later (see additional install notes)||X|
|The glideinWMS software.|
- Condor version v7.3.1 has a known issue with incorrect return/exit codes of condor_status and condor_q
If you are using Condor version v7.3.2 disable VOMS checking in condor_config file used by Condor daemons other
than that used by user schedd. VOMS checking adds unrequired overhead. To do so, set
USE_VOMS_ATTRIBUTES = Falseor for individual condor daemons like collector
COLLECTOR.USE_VOMS_ATTRIBUTES = False
The glidein Frontend needs a HTTP server, like Apache or TUX. The server should be installed on the same node, but a different node can be used as long as the web area is writable from this one. Servers often come pre-installed with HTTP server software, so if you have one running, just reuse it. Otherwise, the installer can help you install one (as root). (See GlideinWMS Component Install)
The installer will ask you for several non-privileged users during the install process. These should be created prior to running the glideinWMS installer.
|Vo Frontend User||
The Glidein Frontend should be installed as a non-priviliged user.
Note:If you are not re-using an existing condor client and instead installing a condor client specific for the frontend, you should install it as this user as well.
Each service in the GlideinWMS will use a x509 certificate in order to identify itself using GSI authentication (see the Quick Reference Guide" for an overview. The installer will ask for several DNs for GSI authentication. You have the option of using a service certificate or a proxy. These should be created and put in place before running the installer. The following is a list of DNs the installer will ask for:
- WMS Collector cert/proxy DN
- User Pool Collector cert/proxy DN
- User Submitter cert/proxy DN
- Glidein Frontend Condor cert/proxy DN (cannot use a cert here)
Note 2: The installer will ask if these are trusted Condor Daemons. Answer 'y'.
When installing the Glidein Frontend you will be presented with a question asking for the directory location for various items. The example below puts many of them in /var. All the directories in /var have to be created as root. Therefore, if you intend on using /var, you will have to create the directories ahead of time.
Note: The web data must be stored in a directory served by the HTTP Server.
Where will the web data be hosted?: [/var/www/html/glidefactory] /var/www/html/glidefactory
At some point the installer will prompt you for the OSG VDT Client location or if you want to install it. The installer will install the client for you. (See GlideinWMS Component Install)
When asked if you want OSG_VDT_BASE defined globally? Answer 'y' unless you want to force your users to find and hard code the location.
By default, match authentication will be used. If you have a reason not to use it, be sure to set to False the USE_MATCH_AUTH attribute in both in both the Factory and Frontend configuration files.
The Glidein Frontend will need the the Condor binaries. You can reuse an existing installation, if available, like if you host the Glidein Frontend on the a submitter node.
Else you need to install a local copy. The suggested way is to install as the same non privileged Glidein Frontend user (see below). The whole process is managed by a install script described below.
You will be presented with this screen:
What do you want to install?
(May select several options at one, using a , separated list)
 glideinWMS Collector
 Glidein Factory
 pool Collector
 Schedd node
 Condor for Glidein Frontend
 Glidein Frontend
Now follow the instructions. Additional description is below:
Where do you have the Condor tarball?
Where do you want to install it?
|Though the frontend does not actually start any Condor processes, it needs a condor installation in order to use Condor tools and commands. For this, you will need a condor distribution and a location to install to. It will also prompt for a administrator email.|
|GSI Security||Where can I find the directory with the trusted CAs?||
GSI security is based on x509 certificates.
First, you will need a list of trusted certificates. VDT comes with a list of certificates, so, if you install that now (or have installed it previously), you can install that now. Note that you may have to update your certificates if you have an old VDT installation.
You will next need a certificate or proxy for the VO frontend. See the previous section for more information on required certificates and proxies.
|Collector||What node is the collector running (i.e. CONDOR_HOST)?||The installer will ask, "What node is the collector running (i.e. CONDOR_HOST)?". The collector referred to by this question is the user pool collector. Answer with the fqdn of the user pool collector. You will need to open all port(s) that the collector will use on the firewall.|
The Glidein Frontend needs a x509 proxy to communicate with the glidein Factory. You need to create such proxy before starting a VO
Frontend and then keep it valid for the life of the frontend. If used for job submission (i.e. if it is passed to the glidein
Factory), this proxy must at any point in time have a validity of at least the longest expected job being run by the glideinWMS
(and not less than 12 hours).
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.
The VO frontend can also host the x509 proxies used for glidein submission. If you do use this (recommended) method, you need to keep these proxies valid at all time, as you do for the main frontend proxy.
The Glidein Frontend should be installed as a non privileged user. The provided installer can be used to create the configuration file, although some manual tunning will probably be needed.
Before starting the installation of the Glidein Frontend make sure that the WMS Collector is started and running.
Note that the OSG client is required, but it is not recommended to actually source the setup.sh before installation. This can cause problems with conflicting python versions. VDT sometimes installs its own version of python which will not have rrdtool or M2Crypto. You can determine if this will be a problem by sourcing the VDT setup script and then doing a 'type python' or 'which python' to see which python is being used.
To begin the installation procedure:
You will be presented with the service selection screen. Follow the instructions. Further detail and a walk-through is presented below:
Where will you host your config files?
Where will the web data be hosted?
What Web URL will you use?
Where will you host your log files?
You will have to give the directories where the frontend will store its files.
By default, some of these directories are in /var, and, if you want to keep them there,
you will need to create them first as root. The web data should be stored in a directory
served by your web server.
You may want to consider putting them in a directory other than a user home directory.
|VO Configuration||Give a name to this Glidein Frontend
Give a name to this Glidein Frontend instance?
|IMPORTANT: When the installer asks, "Give a name to this Glidein Frontend?", you must provide the name that you gave to the installer for the Factory when it asked, "Frontend security name". Otherwise, the factory will reject requests from the frontend.|
|WMS Collector||What node is the WMS collector (i.e. the gfactory) running?
What is the classad identity of the glidein factory?
What is the WMS collector DN (i.e. subject)?
At this point, the location (fqdn) as well as the DN for the WMS collector is needed.
The installer will ask you for the classad identity of the glidein factory. This should be the be the username the factory was installed as. It should be in this format: <username>@<factoryfqdn>. You will need
to make sure all ports are open on any firewalls for these machines.
For a visual guide to the configuration options that need to match in the frontend and factory, see this color coded chart.
|GSI Configuration||Where is your proxy located?
What is the mapped name?
|To use the Glidein Frontend you need a valid GSI proxy. Glidein Frontend will use this proxy to talk to the WMS Collector and User Schedd Make sure this DN is in the WMS collector condor_mapfile. The installer will ask, "What is the mapped name?". If you are using privilege separation, answer with the username of the user you created for the VO frontend on the Factory. The answer should have the following format: <username>@<factory fqdn>|
|Pool Collector||What is the pool collector DN (i.e. subject)?
List and secondary pool collector the glideins should use.
|This will be used to contact the pool collector to query jobs. You will need to match the DN used in the condor mapfile.|
|Job monitoring||What kind of jobs do you want to monitor?
Give a name to the main group:
This is a condor expression for which jobs you'd like reported in the web-based tool.
The default is:
(JobUniverse==5)&&(GLIDEIN_Is_Monitor =!= TRUE)&&(JOB_Is_Monitor =!= TRUE)This tranlates to all vanilla universe jobs that are not monitoring processes. This should be fine unless a more restrictive set is desired.
|Job Matching||What expression do you want to use to match glideins to jobs?||
You will need to specify the selection and matching criteria for the user jobs. The suggested values:
jobs_constraint = (JobUniverse==5)&&(DESIRED_Sites=!=UNDEFINED)should be fine for some basic matchmatching, providing that your user jobs add
+DESIRED_Sites = "site1,site2,...siteN"
|Proxy Configuration||VO frontend proxy = 'XXXX'
Do you want to use is to submit glideins?
Please add all the proxies that this glidein will use
|A proxy is required to submit jobs to the glideins. Find more on this in the previous section.|
|Other DNs||Please add all the DNs that this glidein will connect to||These DNs will be put in the condor mapfile so that they are authorized to talk to the frontend. This is for security purposes.|
Do you want to expose the Grid env. to the user jobs?
Do you want to create the Glidein Frontend instance?
Exposing the grid environment to user jobs will export shell variables to the user job
running on the glidein. Saying 'n' will keep the environment cleaner. Most configurations
use 'y' so the user jobs can use those variables if needed.
Creating the instance will generate scripts and configurations for the VO frontend. Otherwise, you will need to manually run a creation command post-install.
Here a possible set of answers is presented; your setup will probably be slightly different:
If you followed the example above, you ended up with a configuration file in
Edit this file to suit your needs and than create the frontend instance with:
6.1. Starting the Glidein Frontend
Use the startup script:
export X509_USER_PROXY=<Proxy that this frontend instance should use>
cd <install dir>
The same script can be used to stop, reconfig and restart the Glidein Frontend.
6.2. Reconfiguring the Glidein Frontend
The files in the frontend working directory must never be changed by hand after the directory structure has been created.
The proper procedure to update the frontend configuration is to make a copy of the official configuration file (i.e. frontend.xml) as a backup. Then edit the config file and run
<frontend working directory>/frontend_startup reconfig config_copy_fname
This will update the directory tree and restart the frontend and group dameons. (If the frontend wasn't running at the time of reconfig it will only update the directory tree.)
Please notice that if you make any errors in the new configuration file, the reconfig script will throw an error and do nothing. If you executed the reconfig command while the frontend was running, it will revert to the last config file and restart with those settings. As long as you use this tool, you should never corrupt the installation tree.
The frontend_startup script contains a default location for the frontend configuration and is set to the location used for the initial install. This allows you to not have to specify the config location when doing a reconfig. To change the default location in the file, run the command:
<frontend working directory>/frontend_startup reconfig config_copy_fname update_default_cfg
NOTE: The reconfig tool does not kill the frontend in case of errors. It is also recommended that you disable any groups that will not be used. Never remove them from the config file.