 |
 |
just to be sure - with xrootd tpc we do or do *not* need host certs on all pool nodes in addition to front end SE/doors? On 03/04/2020 15.59, Thomas Hartmann wrote: > 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 ######################################################################## 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