 |
 |
Hi Dirk, No, you are not misinterpreting the docs. The docs don't tell you that what is true for a regular client isn't the case for a proxy server. What you need for a proxy is: 1) a valid poxy cert (e.g. in the voms case voms-proty-init). 2) simply configure just like you would have configured a client to forward proxies. The proxy server acts just like a client when contacting another server. Now, what I am somewhat confused (please be patient) is what you are concerned about prozy forwards at all. The only place it makes a differnnce is in TPC as that is the only time we need a proxy cert from the client. However, if you are doing tpc then it should be done at the proxy server not the destination. If done at the proxy server it should all be relatively transparent. Andy On Mon, 14 Jun 2021, Dirk Sammel wrote: > 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] 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