 |
 |
Hi Raul, IMO, the proper process, for any new requirement of any kind, should be: Proposal (e.g. RFC), Impact assessment, Implementation, Test, Acceptance, Rollout (with peer discussions right through. ) In this case, I consider it to be poised somewhere between "Test, Acceptance, Rollout". And yes, we should pass this through security, as part of the assessment. Cheers, Steve On 08/06/2015 11:28 AM, RAUL H C LOPES wrote: > Hi, > > Creating the pilots is not the real thing, is it? At least, if we > know which VOs will be using them. > > My main concern is safety. And I don't mean safety in terms of reading > some policy and finding out if we're respecting it or not. I'd feel > more comfortable if Linda and the security team evaluated this > /multi-VO proxy /submission and issued a statement that they don't see > any increased risks and why they do not see it. > > Of course, after that it would be helpful to have a clear statement of > exactly which VOs will be using this type of job submission. > > Thanks, raul > > > > On 06/08/15 10:28, Stephen Jones wrote: >> Hi Daniela, Simon, >> >> I've done this for Liverpool, as you asked. To re-iterate, I updated >> groups.conf, users.conf, site-info.def, the Argus policy, the Maui >> config, the PBS (qmgr) config. Then I had to do much yaiming on the >> CEs, PBS, WNs, and reload a few servers (Argus, Maui, PBS, ...) We >> don't think it impacts storage. One thing to watch - make sure to use >> unique numbers for the new users and (esp) groups. It's easy for one >> system in a cluster of service nodes and WNs to have (say) a single >> weird numbered group amongst all that, and it would take quite a bit >> of backing out if you hit one. Can you test it now? Try (say) these CEs: >> >> hepgrid2.ph.liv.ac.uk:2811/nordugrid-Condor-grid >> hepgrid5.ph.liv.ac.uk:8443/cream-pbs-long >> >> Cheers, >> >> Steve >> >> >> >> On 08/04/2015 12:33 PM, Daniela Bauer wrote: >>> Hi All, >>> >>> 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). >>> We think this is necessary as otherwise it would be feasible for >>> users to steal a copy of the pilot proxy. As this proxy is used by >>> multiple VO in principle a user might access a different VO's data >>> (or get up to other shenanigans using a proxy that isn't their own). >>> Note that we cannot enable glexec per site/VO, it has to be enabled >>> for all VOs/sites or none. That means if you do not want to enable >>> glexec for a VO, you need to stop supporting the VO altogether as >>> otherwise dirac will try and run (and fail) jobs at your site. >>> >>> Regards, >>> Daniela and Simon >>> >>> -- >>> Sent from the pit of despair >>> >>> ----------------------------------------------------------- >>> [log in to unmask] <mailto:[log in to unmask]> >>> HEP Group/Physics Dep >>> Imperial College >>> London, SW7 2BW >>> Tel: +44-(0)20-75947810 >>> http://www.hep.ph.ic.ac.uk/~dbauer/ >>> <http://www.hep.ph.ic.ac.uk/%7Edbauer/> >> >> > -- Steve Jones [log in to unmask] Grid System Administrator office: 220 High Energy Physics Division tel (int): 43396 Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396 University of Liverpool http://www.liv.ac.uk/physics/hep/