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
|