Print

Print


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