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
|