All,
I'm adding a few more potential impacts that we have noticed at Liverpool.
These are specific for a Torque-Maui site (other set-ups vary).
Cheers,
Steve
----------------------------------
*** site-info.def ***
Our site-info.def also holds settings like these:
LONG_GROUP_ENABLE="\
alice /alice/ROLE=lcgadmin /alice/ROLE=production /alice/ROLE=pilot ....
We think the new VO roles should be placed here.
*** qmgr.conf ***
We have Torque settings like this that might need to be set up.
set queue long acl_groups += alicepil
*** maui.cfg ***
We have settings in MAUI like this:
GROUPCFG[atlaspil] FSTARGET=8+ PRIORITY=1
------------------------------ ORIGINAL MSG -----------------
> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Daniela Bauer
>
> As discussed in the ops meeting we would like sites to enable glexec for
> small VOs. The setup would be identical to CMS, Atlas and LHCb, i.e. jobs
> arrive under a pilot proxy (mapped to a pilot account) and then switch to
> a user account (using the user proxy that is shipped with the pilot).
>
Looking back at the recent changes at Oxford, I believe that the
essential requirements (assuming that a site already has basic
pilot/glExec/ARGUS support at all and that worker nodes are still
managed with YAIM) is to:
- Add a pilot entry to the VO in YAIM's groups.conf, for example:
"/gridpp/ROLE=pilot":::pilot:
"/gridpp/ROLE=lcgadmin":::sgm:
"/gridpp/ROLE=production":::prd:
"/gridpp"::::
- Add pilot pool accounts to YAIM's users.conf, e.g:
32200:grdpppilot000:4150,4100:grdpppilot,gridpp:gridpp:pilot:
32201:grdpppilot001:4150,4100:grdpppilot,gridpp:gridpp:pilot:
32202:grdpppilot002:4150,4100:grdpppilot,gridpp:gridpp:pilot:
32203:grdpppilot003:4150,4100:grdpppilot,gridpp:gridpp:pilot:
...
32001:grdppsgm:4100:gridpp:gridpp:sgm:
32002:grdppprd:4100:gridpp:gridpp:prd:
32003:grdpp001:4100:gridpp:gridpp::
32004:grdpp002:4100:gridpp:gridpp::
32005:grdpp003:4100:gridpp:gridpp::
...
- Re-YAIM the worker nodes with '-n WN -n GLEXEC_wn' which will create
the group, create the accounts, and configure glExec.
- Ensure that the matching user account/groups exist on the CEs.
Oxford's ARC CEs don't use YAIM, so I just copied the relevant bits of
/etc/{passwd,group,shadow,gshadow} from a worker node to the CEs.
- Add the VO to the 'worker node' section in the ARGUS policy file, e.g:
resource "http://authz-interop.org/xacml/resource/resource-type/wn" {
obligation
"http://glite.org/xacml/obligation/local-environment-map" {}
action "http://glite.org/xacml/action/execute" {
rule permit {pfqan = "/gridpp/Role=pilot" }
rule permit {pfqan = "/gridpp/Role=lcgadmin" }
rule permit {pfqan = "/gridpp" }
...
}
}
- And reload the new policy.
I think that's it. The vast majority of our config was generated by
cut-n-paste followed by a simple search and replace to change the copied
VO name to the new one, they all look the same. If you've got this for
anyone, then extending it to everyone is just a bit of housekeeping;
it's not exciting, but sometimes 'not exciting' is quite nice.
Ewan
|