 |
 |
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