 |
 |
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