OK. Thank you very much (as usual).

So, for some more interesting user-mapping configurations, one has to 
forget YAIM (taking care not to break SAM tests --maybe not only ops, 
but VO-specific...). That's anyway true for other dCache aspects, I'd say.

Cheers,

  Antonio.


> Antonio Delgado Peris wrote:
>
>> So, just to be sure, the recommended configuration for dCache (or the 
>> one production sites are using) is that all roles are mapped to the 
>> same user, right?
>>   .ops and .opssgm both to ops001
>>   .cms, .cmssgm and .cmsprd all to cms001
>
> Ever since dCache was introduced in the LCG release, YAIM has 
> configured it
> like that.  Big dCache installations do _not_ use YAIM to make 
> dcache.kpwd,
> because they do want to map the DNs of production managers to accounts 
> that
> have write access to directories where the default account for the VO 
> only
> has read access (at most).
>
>> And I understand this should be the same whether dcache.kpwd or 
>> grid-vorolemap is used for the mapping.
>
> With the grid-vorolemap there are more possibilities, but at the moment
> there is no YAIM function to configure it at all.
>
>> So, there'll be no problems when accessing files within a VO (all 
>> users read/write everywhere), but also there's no way to implement 
>> any restrictions depending on roles, e.g. for special users. And, if 
>> I'm right, this is the way it has been up to now also.
>>
>> I wonder if dCache 1.8 will bring any changes on how this is handled...
>
> The way YAIM sets up the dcache.kpwd file is a historical hack that 
> allows
> one to operate a dCache SE in a simple manner, with known limitations.
> As new functionality like the grid-vorolemap becomes available, YAIM
> should be adapted to start using it.  A boundary condition would be that
> the SAM tests should not fail because some DNs are mapped to ops001 while
> others are mapped, say, to opssgm001.  So, either we use the same account
> at least for the "ops" VO, or we make the relevant directories writable
> for both GIDs (corresponding to the "ops" and "opssgm" groups).