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/
|