 |
 |
Hi Any, many thanks for the clarification - I think I have a clearer picture now ;) So, 'full' third party copies are initiated with '--tpc delegate', i.e., requesting a token from the source/sink and delegating it to the sink/source, so that it can initate the actual transefr. With '--tpc' only it is closer to a direct server-client copy and the token is just used to authorize against the pool but the transfer is server-client? And 'only' acts for both as ratchet against falling back to pre-tpc. I hope that I got this right ;) Cheers and thanks, Thomas On 04/04/2020 01.36, Andrew Hanushevsky wrote: > Hi Thomas, > > Just to clarify; when you say "--tpc delegate only" that applies to the > "tpc" part not the "delegate" part. So, if delegation fails, the client > tries to do a standard TPC. We did it that way to keep backward > compatability. > > Andy > > > On Fri, 3 Apr 2020, Thomas Hartmann wrote: > >> Hi all, >> >> we are currently updating the dCache instances in Wupeprtal and >> DESY-HH to be xrootd TPC ready. >> >> We started with Wupeprtal and experience some problems where third >> party copies 'in one direction' work but fail in the other. >> >> From the debug output, I assume that the difference between >> --tpc only >> and >> --tpc delegate only >> is like for HTTP TPC PUT vs. GET, i.e., if the Source or the Sink >> create the proxy and the other end point uses the proxy info to copy >> to/from, or? >> >> The working copy >> Wuppertal --> DESY-HH with --tpc delegate only >> https://desycloud.desy.de/index.php/s/R2ZoQfENEqe8ixD/download >> seems a bit odd, as first an authz handshake with the DESY-HH node >> seems to fail due to a denied permission. >> And then falls back to "a third party fall back copy job", where it >> seems to request a TPC token from the Wupeprtal node. At the DESY-SE >> the client gets properly redirected to the pool dcache-dot18.desy.de, >> which has a 'TPC lite' support - what does that mean actually ?? >> After whcih the transfer is actually started >> >> >> The failing copy >> Wuppertal --> DESY-HH with --tpc only >> https://desycloud.desy.de/index.php/s/kGtefD6qN2H8qGR/download >> starts apparently also handshaking with the DESY-HH node first - >> before it also(??) falls back to a "third party copy job" but mentions >> "We are NOT using delegation" ? . >> The client again is redirected to a sink pool dcache-dot23.desy.de but >> fails then due to a" Permission denied". >> >> Is this permission denied due to the token not being accepted by >> dcache-dot23.desy.de or because the client authz fails to request the >> actual token? (but then why does the client mentions that it is not >> using delegation? ?) >> >> Long story short: at which end of the two instances do we have an >> autghz(?) problem >> >> Cheers and thansk for any ideas, >> Thomas >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-L list, click the following link: >> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 >> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1