 |
 |
Hi Petr, yes, the direct copy works - but we were trying to get our head around the details of the third party copy modes, i.e., what (if) is the PUT and GET mode (triangulating from HTTP). Interestingly, two TPC attempts on our DESY-HH test instance failed somewhat differently [1] - so that it might be a problem with the token authz config at us - since the classic copy authz works. Cheers, Thomas [1] https://desycloud.desy.de/index.php/s/ApfLAWEWHKGgWxH/download https://desycloud.desy.de/index.php/s/375FjS9noWAEbcy/download On 03/04/2020 15.50, Petr Vokac wrote: > Actually your test dCache doors at DESY-HH also works > > *[vokac@ui1 tpc]$ gfal-copy > root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M > root://dcache-dot3.desy.de:1094/pnfs/desy.de/atlas/1M***Copying root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M [DONE] after 3s > > > XRootD supports only "3rd pull" with X.509 credentials delegated to the > destination. No token support yet, because to protect them XRootD needs > TLS support which comes with version 5. > > Petr > > On 4/3/20 3:24 PM, Petr Vokac wrote: >> 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 >> > ######################################################################## 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