 |
 |
Hey Wei, hey Andy, The use case is caching and no tpc. Here's an explanation of what we want to achieve: Client A requests data from site A, XrdClProxyPlugin sends this request to the proxy server, the proxy server uses the x509 of client A to connect to site A, provides the data to client A and caches it. Client B requests data from site B, XrdClProxyPlugin sends this request to the proxy server, the proxy server uses the x509 of client B to connect to site B, provides the data to client B and caches it. . . and so on But it sounds like that this might be not possible? Cheers Dirk On 6/14/21 10:47 AM, Andrew Hanushevsky wrote: > Good point. I guess we need to know why there is a desire to use a > delegated proxy. I assumed that it was for tpc but you bring up the > point that it isn't for tpc. My subsequent reasoning is that it must > be the desire to have the client go via the cache to the origin with > it own cert. That is impossible for a huge number of reasons. > > Anyway, I'm not sure either of us have the use case here. Cache, no > chace, tpc, no tpc? I think we need to nail down what the desire is > before we even fathom what the solution should be. > > Andy > > On Mon, 14 Jun 2021, Yang, Wei wrote: > >> Hi Dirk, >> >> It is true that the GSI plugin itself can handle proxy delegation. >> But it is another thing to use this delegated proxy. So far, we only >> use delegated proxy in xrootd third copy because at there, each third >> party copy runs in a forked process. This forked environment then >> pickup this delegated x509 proxy for further operation. >> >> However, Xcache does not fork. It handles data fetching using >> threads. It is much harder to set up an isolate thread environment to >> use a delegate x509 proxy. So far (Matevz can clarify) we don?t have >> a good way to assign each thread a delegated x509 proxy without >> crashing Xcache. >> >> regards, >> -- >> Wei Yang | [log in to unmask]<mailto:[log in to unmask]> >> | 650-926-3338(O) >> >> From: <[log in to unmask]> on behalf of Dirk Sammel >> <[log in to unmask]> >> Date: Monday, June 14, 2021 at 12:51 AM >> To: Andrew Hanushevsky >> <[log in to unmask]> >> Cc: Petr Vokac <[log in to unmask]>, xrootd-l >> <[log in to unmask]>, Michael Boehler >> <[log in to unmask]>, "Schwarz, Kilian Dr." >> <[log in to unmask]>, Serhat Atay <[log in to unmask]>, >> "[log in to unmask]" <[log in to unmask]>, "[log in to unmask]" <[log in to unmask]> >> Subject: Re: Proxy delegation not working >> >> Hey Andy, >> >> >> Ah, a proxy server does not forward the client's credentials >> >> Then I might be misinterpreting this section in >> https://xrootd.slac.stanford.edu/doc/gsidocs/XRootDGSIProtocolSpecifications.html >> ? >> >> "For gsi the goal of the handshake is to mutually verify the >> credentials - the server verifies the client proxy certificate, the >> client verifies the server certificate, and to create a shared secret >> to encrypt the rest of the handshake and further communication. >> Optionally, after a successful handshake, a delegate client proxy >> certificate can be produced to enable further authentication >> handshakes initiated by the server on behalf of the client, for >> example in the case of a Third Party Copy." >> >> >> The best you can do it proxy the proxy's credentials and the proxy >> server needs to be configured to do that (only the client side part >> needs to enabled). >> >> Could you point me to some documentation of the required >> configuration for this? >> >> Cheers and thanks >> Dirk >> >> On 6/11/21 9:45 PM, Andrew Hanushevsky wrote: >> Hi Dirk, >> >> Ah, a proxy server does not forward the client's credentials. The >> best you can do it proxy the proxy's credentials and the proxy server >> needs to be configured to do that (only the client side part needs to >> enabled). >> >> Andy >> >> >> On Fri, 11 Jun 2021, Dirk Sammel wrote: >> >> >> Hey Petr, >> >> I'm not talking about the server configuration of the exernal site >> (Munich), but about the configuration of the forward proxy server I >> have set up in Freiburg. >> Sorry if this wasn't clear. >> >> Cheers >> Dirk >> >> On 6/11/21 6:06 PM, Petr Vokac wrote: >> >> This doesn't look like server configuration issue, because transfers >> works for me from lxplus.cern.ch with same client, e.g. >> *$ source /cvmfs/sft.cern.ch/lcg/views/setupViews.sh LCG_99 >> x86_64-centos7-gcc8-opt****$ voms-proxy-init -voms atlas***Enter GRID >> pass phrase for this identity: >> Contacting voms2.cern.ch:15001 >> [/DC=ch/DC=cern/OU=computers/CN=voms2.cern.ch] "atlas"... >> Remote VOMS server contacted succesfully. >> Created proxy in /tmp/x509up_u45277. >> Your proxy is valid until Sat Jun 12 06:01:58 CEST 2021 >> *$ which >> xrdcp***/cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp >> *$ ls -la >> /cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp***lrwxrwxrwx. >> 1 cvmfs cvmfs 85 Jan 10 23:07 >> /cvmfs/sft.cern.ch/lcg/views/LCG_99/x86_64-centos7-gcc8-opt/bin/xrdcp >> -> >> /cvmfs/sft.cern.ch/lcg/releases/xrootd/4.12.3-61acf/x86_64-centos7-gcc8-opt/bin/xrdcp >> *$ xrdcp >> root://lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root >> .***[12.16GB/12.16GB][100%][==================================================][136.9MB/s] >> >> >> Petr >> >> On 6/11/21 5:09 PM, Dirk Sammel wrote: >> >> Dear experts, >> >> I'm having trouble with using the proxy delegation feature. My setup >> is as follows: >> >> I have a client that wants to download files from an external site, >> therefore authentication is required. The request is forwarded to a >> proxy server (which is running in forwarding mode and also caches the >> files). I see the following error in the proxy server log (the full >> log is attached): >> >> ofs_open: >> ds1034.9382:[log in to unmask]<mailto:ds1034.9382:[log in to unmask]> >> Unable to open >> /root:/lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root; >> invalid exchange >> >> At one point before that, the proxy server tries to create a user >> proxy for user xrootd. If I put my userkey and usercert on the proxy >> server and manually create a user proxy for user xrootd, the >> authentication works, but this is of course not a reasonable solution. >> >> Client: >> >> XRootD version: 4.12.3 >> >> $XrdSecGSIDELEGPROXY=2 >> $XrdSecGSIPROXYDEPLEN=-1 >> $X509_USER_PROXY=/tmp/x509up_u52246 >> $X509_USER_KEY=/home/ds1034/.globus/userkey.pem >> $X509_USER_CERT=/home/ds1034/.globus/usercert.pem >> >> Server: >> >> XRootD version: 5.1.1 >> >> xrootd.seclib libXrdSec.so >> sec.protocol gsi -certdir:/etc/grid-security/certificates >> -cert:/etc/grid-security/hostcert.pem >> -key:/etc/grid-security/hostkey.pem -dlgpxy:request -d:3 >> >> >> The complete server config is attached. >> >> >> I also attached the debug logs for the client and the server when >> running >> >> xrdcp -f -d 3 >> root://lcg-lrz-rootd.grid.lrz.de:1094/pnfs/lrz-muenchen.de/data/atlas/dq2/atlasscratchdisk/rucio/user/dsammel/04/71/large.root >> . >> >> Two things I noticed: in the client log "Proxy delegation option: 0", >> in the server log "Secgsi Proxy delegation option: ignore", it seems >> that these settings are not applied? >> >> Is anything missing in my configuration or is anything wrong? >> Just tell me if I need to provide any missing information! >> >> Cheers >> Dirk >> >> ######################################################################## >> 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 >> >> ######################################################################## >> 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