if it helps we:
use a script to get a proxy from myproxy, and add voms attribute to it.
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/COMP/SITECONF/T1_CH_CERN/PhEDEx/VomsProxyRenew?revision=1.4&view=markup
and a script which delegates the proxy to fts servers.
http://cmssw.cvs.cern.ch/cgi-bin/cmssw.cgi/COMP/SITECONF/T1_CH_CERN/PhEDEx/FTSDelegationInit?revision=1.2&view=markup
and just run these in a cronjob from the machine which submits the jobs.
And submit the jobs without the myproxy option so it uses the delegation.
( I think these links are visible to all )
Cheers
Stuart
On Sun, Jul 31, 2011 at 4:15 PM, Christopher J. Walker
<[log in to unmask]> wrote:
> T2K are having problems using myproxy with FTS when transfers take place
> after the expiry of the original certificate (see GGUS 72358 and 67905 which
> looks to have been incorrectly considered as solved).
>
> As far as I can tell, the problem is that when the VOMS credentials of the
> initial certificate uploaded to the myproxy server expire, it hands out
> proxies without VOMS extensions. FTS transfers using that certificate fail
> to SEs (including, but not limited to QMUL's) that require valid VOMS
> credentials.
>
> Either
>
> 1) the myproxy server should be renewing the VOMS credentials of the proxy
> certificates it hands out, or
> or
> 2) VOMS credentials uploaded to the myproxy server should expire at the same
> time as the certificate uploaded to the myproxy server.
> or
> 3) FTS needs to bless the proxy certificate it hands out with VOMS
> credentials.
>
> Does that sound about right?
>
>
> Here's what Jonathan does (and a little bit of commentary):
>
> On 29/07/11 16:38, Jonathan Perkin wrote:
>>
>> Hi Chris, here goes....
>>
>> Every Monday morning I store a set of credentials on the myproxy server:
>> myproxy-destroy -d
>> myproxy-init -v -d -a -s $MYPROXY_SERVER --voms
>> t2k.org:/t2k.org/Role=production
>>
>> (where MYPROXY_SERVER=lcgrbp01.gridpp.rl.ac.uk)
>> specifiying a password to allow delegation of short term credentials
>> from this proxy.
>>
>> Every 12 hours cron runs a script on my UI that retrieves a fresh short
>> term proxy from the credentials stored on the myproxy server:
>> voms-proxy-destroy -debug
>> myproxy-get-delegation -v -d --stdin_pass --voms
>> t2k.org:/t2k.org/Role=production < ~/.glite/myproxy
>>
>> (where ~/.glite/myproxy is a file containing the delegation password
>> specified above)
>>
>> I then (according to the instructions here
>> :http://www.gridpp.ac.uk/deployment/users/myproxy.html) 'dress' the
>> delegated proxy with my voms attributes:
>> voms-proxy-init -debug -voms t2k.org:/t2k.org/Role=production -valid
>> 24:0 -noregen
>>
>> (though this appears to contradict the requirement to attach voms
>> attributes to the myproxy-init command above)
>>
>> With my valid short term proxy I submit FTS transfers as following:
>> glite-transfer-submit -s $FTS_SERVICE -m $MYPROXY_SERVER -p $MYPROXY_PWD
>> <FILE>
>> where
>>
>> FTS_SERVICE=https://lcgfts.gridpp.rl.ac.uk:8443/glite-data-transfer-fts/services/FileTransfer,
>> MYPROXY_SERVER=lcgrbp01.gridpp.rl.ac.uk, MYPROXY_PWD is the delegation
>> password and FILE is a list of source and destination SURLS.
>>
>> Whilst the short term credentials are valid, FTS transfers proceed
>> successfully with any combination of the -m and -p option specified.
>>
>> However, as soon as the short term proxy on my UI expires (under which
>> the transfers were submitted)
>> - if I have NOT specified the -p option the transfers fail with
>> SECURITY_ERROR
>> - if I HAVE specified the -p option the transfers fail with HTTP_TIMEOUT
>>
>> so it looks like the FTS is not successfully delegating my credentials
>> from the myproxy server.
>
> We have subsequently established that if he uploads a new proxy to the
> myproxy server with voms attributes, then transfers start working.
>
> HTTP_TIMEOUT is not a particularly helpful error message it has to be said,
> and we should also try and get that fixed, but that's a separate issue.
>
>>
>> Interestingly the myproxy delegation does seem to work on the channels
>> RALLCG2 <-> VICTORIALCG2,IN2P3CC
>
> I suspect that this is because they don't check that a certificate has VOMS
> attributes. Thus, it's a bug that these channels are working.
>
>>
>> Hope that makes some sense!
>>
>> Cheers
>>
>> Jon
>>
>>
>> ___________________________________________________________________________________
>>
>> Jonathan Perkin Department of Physics, University of Sheffield.
>> [log in to unmask] Hicks Building, Hounsfield Road, Sheffield; S3
>> 7RH.
>> +44 (0)1142 223547
>
> Chris
>
>
|