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.

 

Wei Yang  |  [log in to unmask]  |  650-926-3338(O)

 

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

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: [log in to unmask]">ds1034.9382:[log in to unmask][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