Birmingham CAGE Test Bench
A description of Cream ce /Argus/Glexec_wn/lcg-cE (
CAGE) test installation at Birmingham.
Context
ALICE have requested Birmingham install a
CreamCE, which should be able to submit jobs to all WNs supporting the ALICE VO. ATLAS does not support
CreamCE submission yet, so the same WNs also need to accept jobs from a conventional lcg-CE.
ATLAS does support multi-user pilot jobs though, so the WNs must be able to execute glexec. Other
GridPP? sites have tested this functionality in the context of an SCAS server. This test bench makes use of ARGUS to decide on authentication requests.
Installation
Installation of all test nodes is managed by the cfengine server on epgmo1. Below are instructions for completing the installation manually.
GLEXEC_wn
ARGUS
- Setup the glite-ARGUS and lcg-CA yum repos.
- Install the following:
yum -y install lcg-CA
yum -y install jpackage-utils
yum -y install glite-ARGUS
- The node is configured with the yaim command
/opt/glite/yaim/bin/yaim -c -s /root/yaim-conf/site-info.def -n ARGUS_server
. The relevant yaim variables can be found here.
- In order for dteam to use glexec, the appropriate policies have to be defined. Full details can be found here. A simple policy could be:
resource "http://authz-interop.org/xacml/resource/resource-type/wn" {
action "http://authz-interop.org/xacml/action/action-type/execute-now" {
rule permit { vo = dteam }
}
}
which, if stored in the file dteam_policy
, can be loaded using the command pap-admin apf dteam_policy
.
- The ARGUS server should be able to communicate with itself (ie localhost) on ports 8150-8153 (INPUT only), and any node requesting authentication services on 8154 (INPUT only).
Cream CE
lcg-CE
Testing
Dteam Job Submission
A dteam
HelloWorld? job ran successfully on both the Cream and LCG CEs. OPS jobs also ran on both CEs automatically after enabling them in the GOCDB.
ATLAS Job Submission
A
HelloWorld? job ran successfully on both the Cream and LCG CEs. An LCG Ganga job was submitted to the lcg-CE, which completed successfully. Panda functionality has not been tested. The
CreamCE has not been tested.
GLExec Functionality
Renaming pool accounts
This is potentially difficult. It is assumed that pool accounts on resources (WNs, CE etc) must have the same format, UID and GID as the pool accounts on the ARGUS server in order for authentication to work.
Assuming no work is being done by a node (
GridFTP? transfers, job submission/execution etc), it is relatively simple to delete existing pool accounts, clear the grid-map files and directories from
/etc/grid-security
and create new pool accounts with yaim. The one forseeable complication is that the software areas must be readable by a particular GID.
The pool accounts defined on
BlueBEAR resources take a different format, and different IDs to those defined on local resources. As the
BlueBEAR accounts are much more difficult to change, the solution would be to redefine all local pool accounts using the same format as those used on
BlueBEAR. In addition, all files in the software areas would have to be assigned to the appropriate group. This is a potentially risky strategy, and it would require some thought before executing (
especially the day before collisions!). As it is not yet known if
BlueBEAR will support glexec functionality, and as it is not yet known if a TAR_GLEXEC_wn release will be made available, the current implementation of the ARGUS server will contain pool accounts defined in the local cluster style.
--
ChristopherCurtis - 24 Mar 2010