Installation of a VO Frontend
The VO 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.
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 VO Frontend should be installed as a non-privilged user. Note: It is recommended that you install Condor as this user as well.|
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
- VO 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 VO 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.
When asked if you want to enable Match authentication, if you are using Condor 7.1.3 or later, answer 'y' unless you have a reason not to.
The VO Frontend will need the the Condor binaries. You can reuse an existing installation, if available, like if you host the VO 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 VO 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 VO Frontend
 VO 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
The user pool collector is part of the Condor pool that will actually run the user's jobs.
This will be the server that you will submit jobs to. This piece of the install will configure
the collector to work with the submitted glideins.
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.|
The VO 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 VO 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 VO Frontend make sure that the WMS Collector is started and running.
Assuming VDT is installed in $VDT_LOCATION, source VDT's setup as follows
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 VO Frontend
Give a name to this VO Frontend instance?
|IMPORTANT: When the installer asks, "Give a name to this VO 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>|
|GSI Configuration||Where is your proxy located?
What is the mapped name?
|To use the VO Frontend you need a valid GSI proxy. VO 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.|
|Final Config||Do you want to use the more efficient Match authentication?
Do you want to expose the Grid env. to the user jobs?
Do you want to create the VO Frontend instance?
Match authentication is more efficient and used in newer versions of Condor.
This is recommended unless using an older version of Condor.
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 VO 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 VO Frontend.
6.2. Reconfiguring the VO Frontend
If you make changes to the configuration file /home/frontend/frontstage/instance_v1.cfg/frontend.xml from above after creating glidein, run reconfig_frontend tool to propagate the changes to the frontend configuration.
glideinWMS/creation/reconfig_frontend -writeback yes /home/frontend/frontstage/instance_v1.cfg/frontend.xml
If you make changes to the frontend.xml configuration file in the <install dir> use following command to propagate the changes
7. VO Frontend monitoring>>>>>>> 126.96.36.199
There are several ways to monitor the Vo Frontend:
- Using the Web monitoring
- Using the WMS tools
- Looking at the VO frontend log files
- Checking the WMS collector ads
You can either monitor the frontend as a whole, or just a single entry point.
The frontend monitoring is located at a URL like the one below
Moreover, each frontend group has its own history on the Web.
Assuming you have a main group, it can be monitored at
You can get the equivalent of the Web page snaphot by using
./wmsXMLView.py -pool gfactory1.my.org
The vo frontend writes two log files per entry point frontend_info.YYYYMMDD.log and frontend_err.YYYYMMDD.log.
Assuming you have a main group, the log files are in
All errors are reported in the frontend_err.YYYYMMDD.log. file, while frontend_info.YYYYMMDD.log contains entries about what the VO frontend is doing.
The VO frontned also advertises summary information in the WMS collector.
condor_status -pool gfrontend1.my.org -any
and look for glideclient ads.
glideinWMS support: email@example.com