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
|