Hi John,
Are you still using the kpwd method for authorisation?
Greig
On 10/03/08 13:33, John Bland wrote:
> Greig Alan Cowan wrote:
>> Hi John,
>>
>> Are you saying that using the LinkGroupAuthorisation file below does
>> not work, or are you asking if this is the correct approach to try?
>
> Both. This was on a friday evening so I didn't want to mess with it too
> much but the config below was failing SAM tests for sgmops01.
>
> But also should we be mapping sgm/prd accounts differently, or using
> some other form of authorisation/space management to keep prd/sgm data
> separate to user data? The dcache.kpwd file we have been using was
> generated by the grid-mapfile2dcache-kpwd script (hacked to work with
> pool accounts).
>
> John
>
>> Cheers,
>> Greig
>>
>> On 10/03/08 09:32, John Bland wrote:
>>> Hi,
>>>
>>> We're in the process of setting up reservations for VOs on our dcache
>>> system but ran into a problem with standard and prd/sgm accounts.
>>>
>>> Our current account mapping system maps standard accounts to VO001,
>>> prd accounts to prdVO01 and sgm accounts to sgmVO01.
>>>
>>> The reservation linkgroupauthorisations, however, are just for the
>>> standard account and the examples shown in previous threads by other
>>> sites don't have any mention of sgm/prd accounts in them. This leads
>>> to sgmops jobs being unable to write to the dteam/ops reservation.
>>>
>>> LinkGroup dteam-linkGroup
>>> dteam001/Role=*
>>> /dteam/Role=*
>>> ops001/Role=*
>>> /ops/Role=*
>>> sgmops01/Role=*
>>> /ops/Role=*
>>>
>>> LinkGroup lhcb-linkGroup
>>> lhcb001/Role=*
>>> /lhcb/Role=*
>>>
>>> LinkGroup atlas-linkGroup
>>> atlas001/Role=*
>>> /atlas/Role=*
>>>
>>>
>>> Are we mapping our accounts incorrectly for dcache or is there a
>>> recommended way of authorising them for reservations (the sgmops
>>> entry above didn't work)?
>>>
>>> Thanks,
>>>
>>> John
>>>
>
>
|