On 21/11/11 15:14, David Grellscheid wrote:
> Hello everyone,
>
> I've been following this thread with interest, since it is exactly the
> same issue that Phenogrid have been seeing on and off for a year now. It
> seems to sort itself out once in a while, but then breaks again. We are
> not able to reliably run jobs that are longer than the 24 hours maximum
> on VOMS extensions.
Does it _ever_ work if things last longer than 24 hours?
>
> On 18/11/11 15:07, Mingchao Ma wrote:
>> In order for a renew service to be able to renew a proxy on behalf of
>> an end
>> user, two conditions must be met (actually two authentications occur
>> behind
>> the scene):
>>
>> - the host certificate of the renew service must be trusted by the
>> myproxy
>> server (myproxy server can be configured to trust a list of WMSs or
>> the user
>> can tell the myproxy server to trust a specific server with "-R dn"
>> option,
>> e.g. myproxy-init -n -d -R mytrusted.wms.rl.ac.uk)
>>
>> - a valid non-expired user proxy certificate must be presented when renew
>>
>> Clearly if a proxy certificate was compromised, one could not renew it
>> unless one also compromised a server trusted by myproxy server.
>
> Thanks, Mingchao, for this explanation. I still don't see where in this
> sequence the VOMS part of the proxy comes in? The proxy renewal itself
> usually works fine, but the VOMS extension does not get renewed.
>
If your issue is that the VOMS part of the certificate doesn't get
renewed, then Stuart Wakefield posted the following explanation of how
CMS does this - in response to t2k issues with myproxy and FTS:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1108&L=TB-SUPPORT&F=&S=&P=54
Chris
|