 |
 |
Hey Wei, Ok, thanks a lot for the explanation! Our next steps are then the creation of a CERN service account and the request for a robot certificate. With this, the authentication at external sites should be possible. Thanks again for all the replies. Cheers Dirk On 6/14/21 8:36 PM, Yang, Wei wrote: > > Hi Dirk, > > Thanks for the explanation. I think my previous comment was targeting > this use case. In addition to reasons I mentioned (unable to have an > isolated thread environment to use a delegated x509 proxy), there is > also a caching effectiveness issue. Suppose client A and client B both > want the same piece of data, in your model, does the cache keeps two > copies, one for each user, or does the cache keep one copy? If the > design is to share data among all users (to maximize the cache > effectiveness), then a common x509 proxy (delegated or pre-generated) > is the way to go. > > 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 2:23 AM > *To: *Andrew Hanushevsky > <[log in to unmask]>, "Yang, > Wei" <[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 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]><mailto:[log in to unmask]> > <mailto:[log in to unmask]> | 650-926-3338(O) > > From: <[log in to unmask]> > <mailto:[log in to unmask]> on behalf of Dirk Sammel > <[log in to unmask]> <mailto:[log in to unmask]> > Date: Monday, June 14, 2021 at 12:51 AM > To: Andrew Hanushevsky > <[log in to unmask]> > <mailto:[log in to unmask]> > > Cc: Petr Vokac <[log in to unmask]> > <mailto:[log in to unmask]>, xrootd-l > <[log in to unmask]> > <mailto:[log in to unmask]>, Michael Boehler > <[log in to unmask]> > <mailto:[log in to unmask]>, "Schwarz, > Kilian Dr." <[log in to unmask]> <mailto:[log in to unmask]>, > Serhat Atay <[log in to unmask]> > <mailto:[log in to unmask]>, "[log in to unmask]" > <mailto:[log in to unmask]> <[log in to unmask]> > <mailto:[log in to unmask]>, "[log in to unmask]" > <mailto:[log in to unmask]> <[log in to unmask]> <mailto:[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 > <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]><mailto: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 > <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 > <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 > <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 > <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 > <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 > <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 > <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