 |
 |
Hi, with XRootD protocol destination is active party in TPC where client delegate credentials used by destination storage to access source storage. Currently DESY-HH fails as destination but Wuppertal seems to be configured OK *[vokac@ui1 tpc]$ gfal-copy root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M root://dcache-atlas-xrootd-wan.desy.de:1094/pnfs/desy.de/atlas/dq2/atlasscratchdisk/SAM/1M***Copying root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M [FAILED] after 3s gfal-copy error: 42 (No message of desired type) - Error on XrdCl::CopyProcess::Run(): [ERROR] Server responded with an error: [4003] Authentication to golias100.farm.particle.cz:1094 failed; all protocols have been tried. *[vokac@ui1 tpc]$ gfal-copy root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M root://grid-se.physik.uni-wuppertal.de:1094/pnfs/physik.uni-wuppertal.de/data/atlas/atlasscratchdisk/SAM/1M***Copying root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M [DONE] after 1s Petr On 4/3/20 2:02 PM, 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