hi Marteen and Stephen

we definitely don't want to start with hacking with the 
lcas/lcmaps/grid-mapfile
there will be one of these days that grid-mapfile will probably disapear

for the initial request/issue about the cms exercise (thanks Christoph) 
for the clear information
we will simply add a new pooled accounts for the "priorityuser" (as we 
did awhile for the atlas pilots)

we will request cms (probably also atlas) for a group named "PT or 
Portugal" (which is enough granularity)
in the voms server
this will allow to put there people that they want without our (admins) 
intervention , except configuring special priorities or shares for this 
group.


regards, and thanks for all the answers/sugestions

Mario and Goncalo

On 10/01/2009 12:09 AM, Maarten Litmaath wrote:
> On Wed, 30 Sep 2009, Stephen Burke wrote:
>
>    
>>> If this works, we can cook up YAIM post-configuration functions that
>>> will preserve the changes and maybe open an RFE in Savannah.
>>>        
>> I'm not sure we really want this as standard, it's fairly hacky. Among
>>      
> I do not like it either, but it does seem to comply with the conditions
> that were stated...
>
>    
>> other things, where do you get the list of DNs - back to the old LDAP VO
>> servers?! Really we want this kind of thing done with VOMS if possible.
>>      
> CMS may not want to create a separate VOMS group for every institute,
> whereas that would be the cleanest indeed.
>
>    
>> Also the information publishing may become unhelpful, depending on how
>> much priority the special users get and what the balance of jobs is -
>> e.g. a long queue of jobs from non-local users will push up the ERT even
>> if local user jobs would go straight in.
>>      
> Indeed.
>
>    
>>    Returning to my earlier suggestion of a separate queue, you may be
>>      
> The separate queue would be "respected" by the WMS matchmaker,
> but the matchmaker can be bypassed, so the queue could be abused
> if the privileged users are not mapped differently.
>
>    
>> able to fake it with a pseudo-VO if the WMS still lets you override the
>> VOMS proxy - e.g. put VO:xyz in the ACBR and specify "xyz" as the VO in
>> the JDL ... also rather a hack though!
>>      
> The WMS client does not let you override the VO in your proxy...
>
>