Hi Marteen,

>> Dear All,
>>
>> I'm having a very strange problem regarding some specific biomed 
>> users... Basically, there are 2 biomed users (up to now) which fail to 
>> run jobs here at LIP in biomed queue.
>> VOMS authentication is failing and they are mapped to other queues, 
>> according to the grid-mapfile, since they also belong to other VOs.
>>     
>
> First, you may want to reorder the list of VOs in your site-info.def
> and rerun the config_mkgridmap function.  When DNs appear in multiple
> VOs it usually is impossible to get everyone's preferred VO first,
> but at least catch-all/test VOs like "dteam" can be pushed to the end.
>
>   

I didn't knew that the order was important... It's important to know this.
>> For example, in the logs, I see that the system tries to authenticate 
>> one of this guys via VOMS but it fails with the message:
>>
>> LCMAPS 5: 2007-08-20.15:52:27.625102.0000003081.0000075535 : LCMAPS 
>> credential mapping request
>> LCMAPS 0: 2007-08-20.15:52:27.625102.0000003081.0000075535 : 
>> lcmaps.mod-runPlugin(): found plugin 
>> /opt/edg/lib/lcmaps/modules/lcmaps_voms.mod
>> LCMAPS 0: 2007-08-20.15:52:27.625102.0000003081.0000075535 : 
>> lcmaps.mod-runPlugin(): running plugin 
>> /opt/edg/lib/lcmaps/modules/lcmaps_voms.mod
>> LCMAPS 0: 2007-08-20.15:52:27.625102.0000003081.0000075535 :    
>> lcmaps_plugin_voms-plugin_run(): VOMS extensions missing from 
>> certificate (failure)!
>>     
>
> This really means the VOMS extensions were absent.  This can happen when
> one uses a VOMS proxy to submit jobs through a Resource Broker _and_ one
> registered a proxy on the RB's MyProxy server: that combination will fail
> sooner or later.
>   

I don't know if this is indeed the case. I'll have to check with the users.
> The problem is that the standard RB is not aware of VOMS extensions:
> when it renews the proxy of some job, it becomes a plain grid proxy.
> Next, the RB has a single condor_gridmanager process per DN to handle
> all the jobs submitted by that DN.  That process needs a valid proxy
> to be able to communicate with the CEs: it typically uses the latest
> proxy available for that DN, which may be a proxy that was renewed for
> one of the jobs.  So, even when it started with a VOMS proxy, sooner
> or later it will be using a plain grid proxy and probably fail.
>
> Work-arounds:
>
> 1. The user should not register a proxy on the MyProxy server,
>    but use a long VOMS proxy instead.  This means the admin of the
>    VOMS server would have to raise the lifetime limit (default 24h).
>
> 2. Install the modifications Valentin Vidic developed for SEEGRID,
>    then the RB will also renew the VOMS extensions:
>
>        http://www.irb.hr/users/vvidic/seegrid/
>   
I do not have control regarding the RBs users are using but I can 
implement this in my RB. I checked Valentic Vidic webpage and there are 
several rpms there. I guess the one you are refering to is 
http://www.irb.hr/users/vvidic/seegrid/voms-renewd-0.2-3.noarch.rpm.

Thanks for the suggestions
Cheers
Goncalo



> 3. Use a WMS.  The current gLite 3.0 WMS has various problems, but
>    the gLite 3.1 WMS currently in certification is a big step forward.
>