 |
 |
Hi Marcus, what I see is that XrdHttp correctly decoded who you are and your voms roles. I'd say that your setup is loading some other plugin that applies authorization (and refuses it) Are you loading other plugins ? Did you configure the XrdAcc authorization ? Is this a redirector or a data server ? f On 03/16/2017 05:29 PM, Marcus Ebert wrote: > Hi all, > > I tried to update to the latest xrootd version from epel-testing and the latest version of xrdhttpvoms. However, there is no > change in the result: > > > xrdcp xroot://gridpp09.ecdf.ed.ac.uk:1094//lsst/testfile . > ---------------------------------------------------------- > works > > > > davix-get -P grid https://gridpp09.ecdf.ed.ac.uk:1094/lsst/testfile > --------------------------------------------------------------------- > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: Setting host: 92.40.249.75.threembb.co.uk > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: Entering SSL_accept... > 170316 16:15:13 7210 XrdSched: running main accept inq=0 > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: SSL_accept returned :1 > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: SSL_get_verify_result returned :0 > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: Extracting auth info. > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: SSL_get_peer_certificate returned :0x7f414400cb70 > 170316 16:15:13 7211 ?:[log in to unmask] sysXrdHttp: Setting link name: > /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=proxy/CN=proxy > 170316 16:15:13 7211 [log in to unmask] SSL_get_peer_certificate returned :0x7f414400cb70 > 170316 16:15:13 7211 [log in to unmask] SSL_get_verify_result returned :0 > 170316 16:15:13 7211 [log in to unmask] SSL_get_peer_cert_chain :0x7f414400e930 > 170316 16:15:13 7211 [log in to unmask] fqan :/lsst/Role=NULL/Capability=NULL > 170316 16:15:13 7211 [log in to unmask] Setting VO: lsst roles :/lsst/Role=NULL/Capability=NULL > 170316 16:15:13 7211 sysXrdHttp: getDataOneShot BuffAvailable: 1048576 maxread: 1048576 > 170316 16:15:13 7211 sysXrdHttp: getDataOneShot sslavail: 1048576 > 170316 16:15:13 7211 sysXrdHttp: read 195 of 1048576 bytes > 170316 16:15:13 7211 sysXrdHttp: rc:31 got hdr line: HEAD //lsst/testfile > HTTP/1.1 > > 170316 16:15:13 7211 sysXrdHttp: rc:40 got hdr line: User-Agent: libdavix/0.6.0 neon/0.0.29 > > 170316 16:15:13 7211 sysXrdHttp: rc:14 got hdr line: Keep-Alive: > > 170316 16:15:13 7211 sysXrdHttp: rc:24 got hdr line: Connection: Keep-Alive > > 170316 16:15:13 7211 sysXrdHttp: rc:14 got hdr line: TE: trailers > > 170316 16:15:13 7211 sysXrdHttp: rc:35 got hdr line: Host: gridpp09.ecdf.ed.ac.uk:1094 > > 170316 16:15:13 7211 sysXrdHttp: rc:35 got hdr line: Accept: application/metalink4+xml > > 170316 16:15:13 7211 sysXrdHttp: rc:2 got hdr line: > > 170316 16:15:13 7211 sysXrdHttp: rc:2 detected header end. > 170316 16:15:13 7211 XrootdBridge: /C=UK/O=.16:[log in to unmask] login as > /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=proxy/CN=proxy > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] sysXrdHttp: Process. lp:0x7f4150001d68 reqstate: 0 > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] XrootdProtocol: 0000 Bridge req=3017 dlen=15 blen=15 > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] sysXrdHttp: Process is exiting rc:1 > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] ofs_stat: fn=/lsst/testfile > 170316 16:15:13 7211 ofs_stat: /C=UK/O=.16:[log in to unmask] Unable to locate /lsst/testfile; permission denied > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] XrootdProtocol: 0000 rc=-1 stat /lsst/testfile > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] XrootdResponse: 0000 sending err 3010: Unable to locate > /lsst/testfile; permission denied > 170316 16:15:13 7211 sysXrdHttp: XrdHttpReq::Error > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] sysXrdHttp: PostProcessHTTPReq req: 3 reqstate: 0 > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] sysXrdHttp: Sending resp: 404 len:10 > 170316 16:15:13 7211 sysXrdHttp: Sending 46 bytes > 170316 16:15:13 7211 sysXrdHttp: Sending 10 bytes > 170316 16:15:13 7211 sysXrdHttp: XrdHttpReq request ended. > 170316 16:15:13 7211 sysXrdHttp: Cleanup > 170316 16:15:13 7211 sysXrdHttp: SSL_shutdown failed > 170316 16:15:13 7211 sysXrdHttp: Reset > 170316 16:15:13 7211 sysXrdHttp: XrdHttpReq request ended. > 170316 16:15:13 7211 XrootdXeq: /C=UK/O=.16:[log in to unmask] disc 0:00:00 (send failure) > 170316 16:15:13 7211 /C=UK/O=.16:[log in to unmask] XrdPoll: FD 7 detached from poller 0; num=0 > > > Anyone any ideas what could be the reason that it doesn't work through davix-get? > In the config I have for http: > if exec xrootd > xrd.protocol http /usr/lib64/libXrdHttp.so > fi > http.cadir /etc/grid-security/certificates > http.cert /etc/grid-security/xrd/xrdcert.pem > http.key /etc/grid-security/xrd/xrdkey.pem > http.secxtractor /usr/lib64/libXrdHttpVOMS.so > http.listingdeny no > http.desthttps no > > (gridpp09 is just a single server, not going through a redirector for now to have a simple situation until it works) > > Cheers, > Marcus > > > On Fri, 10 Mar 2017, Marcus Ebert wrote: > >> Hi, >> >> Ah right, http needs it's own debug. I now enabled >> http.trace all >> >> And at least it shows now that the VO is detected: >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: received dlen: 16 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: received dump: 22 03 01 01 20 01 00 01 16 03 03 88 -62 -29 >> -126 00 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: This does not look like http at pos 0 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: This may look like https >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Protocol matched. https: 1 >> 170310 17:33:53 14501 XrdProtocol: matched protocol http >> 170310 17:33:53 14501 ?:[log in to unmask] XrdPoll: FD 7 attached to poller 0; num=1 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Process. lp:0x7fba5c001c68 reqstate: 0 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Setting host: 94.197.120.127.threembb.co.uk >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Entering SSL_accept... >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: SSL_accept returned :1 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Extracting auth info. >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: SSL_get_peer_certificate returned :0x7fba60034dd0 >> 170310 17:33:53 14501 ?:[log in to unmask] sysXrdHttp: Setting link name: >> /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=3266599870 >> 170310 17:33:53 14501 [log in to unmask] SSL_get_peer_certificate returned :0x7fba60034dd0 >> 170310 17:33:53 14501 [log in to unmask] SSL_get_verify_result returned :0 >> 170310 17:33:53 14501 [log in to unmask] SSL_get_peer_cert_chain :0x7fba6003a0e0 >> 170310 17:33:53 14501 [log in to unmask] fqan :/lsst/Role=NULL/Capability=NULL >> 170310 17:33:53 14501 [log in to unmask] Setting VO: lsst roles >> :/lsst/Role=NULL/Capability=NULL >> 170310 17:33:53 14501 [log in to unmask] sysXrdHttp: SSL_get_verify_result returned :0 >> >> but then later it says: >> 170310 17:33:53 14501 XrootdBridge: /C=UK/O=.17:[log in to unmask] login as >> /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=3266599870 >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] sysXrdHttp: Process. lp:0x7fba5c001c68 reqstate: 0 >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] XrootdProtocol: 0000 Bridge req=3017 dlen=15 blen=15 >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] sysXrdHttp: Process is exiting rc:0 >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] ofs_stat: fn=/lsst/testfile >> 170310 17:33:53 14501 ofs_stat: /C=UK/O=.17:[log in to unmask] Unable to locate /lsst/testfile; permission denied >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] XrootdProtocol: 0000 rc=-1 stat /lsst/testfile >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] XrootdResponse: 0000 sending err 3010: Unable to locate >> /lsst/testfile; permission denied >> 170310 17:33:53 14501 sysXrdHttp: XrdHttpReq::Error >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] sysXrdHttp: PostProcessHTTPReq req: 2 reqstate: 0 >> 170310 17:33:53 14501 /C=UK/O=.17:[log in to unmask] sysXrdHttp: Sending resp: 404 len:15 >> 170310 17:33:53 14501 sysXrdHttp: Sending 46 bytes >> 170310 17:33:53 14501 sysXrdHttp: Sending 15 bytes >> 170310 17:33:53 14501 sysXrdHttp: XrdHttpReq request ended. >> 170310 17:33:53 14501 sysXrdHttp: Cleanup >> 170310 17:33:53 14501 sysXrdHttp: SSL_shutdown failed >> 170310 17:33:53 14501 sysXrdHttp: Reset >> 170310 17:33:53 14501 sysXrdHttp: XrdHttpReq request ended. >> 170310 17:33:53 14501 XrootdXeq: /C=UK/O=.17:[log in to unmask] disc 0:00:00 (send failure) >> >> >> So it find's the VO but still shows a permission denied. Or can it not find the file? >> filename that >> works : root://dev2.gridpp.ecdf.ed.ac.uk:1094//lsst/testfile doesn't work : >> https://dev2.gridpp.ecdf.ed.ac.uk:1094/lsst/tesfile >> >> (you probably can also access /atlas/testfile through xrdcp) >> >> Cheers, >> Marcus >> >> On Fri, 10 Mar 2017, Fabrizio Furano wrote: >> >>> Hi, >>> >>> > > > - Was your server (the machine, not xrootd) configured to recognize > > gridpp or lsst proxies ? >>> > > [ it's the stuff in /etc/grid-security/vomsdir plus the > > ca-policy-egi-core package ] >>> > > > Yes, it was configured for atlas, gridpp, lsst, lhcb, dteam. This also > works when using xrdcp/xrdfs. >>> > When going through xrdcp, I see in my logs: >>> > 170310 15:04:14 21760 secgsiVOMS_Fun: proxy: > /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=3266599870 >>> > 170310 15:04:14 21760 secgsiVOMS_Fun: adding cert: > /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert >>> > 170310 15:04:15 21760 secgsiVOMS_Fun: retrieval successful >>> > 170310 15:04:15 21760 secgsiVOMS_Fun: found VO: lsst >>> > 170310 15:04:15 21760 secgsiVOMS_Fun: ---> group: '/lsst', role: > 'NULL', cap: 'NULL' >>> > 170310 15:04:15 21760 secgsiVOMS_Fun: ---> fqan: > '/lsst/Role=NULL/Capability=NULL' >>> > > Something similar is not in the log files when going through https. >>> >>> >>> This is what you should look for in the logs when running xrootd in debug >>> mode. What do you get ? >>> >>> 170310 16:15:52 22616 ?:[log in to unmask] sysXrdHttp: Extracting auth >>> info. >>> 170310 16:15:52 22616 ?:[log in to unmask] sysXrdHttp: >>> SSL_get_peer_certificate returned :0x7f7cf403c150 >>> 170310 16:15:52 22616 ?:[log in to unmask] sysXrdHttp: Setting link >>> name: /DC=ch/DC=cern/OU=Organic >>> Units/OU=Users/CN=furano/CN=644746/CN=Fabrizio Furano/CN=172241399 >>> 170310 16:15:52 22616 [log in to unmask] >>> SSL_get_peer_certificate returned :0x7f7cf403c150 >>> 170310 16:15:52 22616 [log in to unmask] >>> SSL_get_verify_result returned :0 >>> 170310 16:15:52 22616 [log in to unmask] >>> SSL_get_peer_cert_chain :0x7f7cf403bc30 >>> 170310 16:15:52 22616 [log in to unmask] fqan >>> :/atlas/Role=NULL/Capability=NULL >>> 170310 16:15:52 22616 [log in to unmask] fqan >>> :/atlas/lcg1/Role=NULL/Capability=NULL >>> 170310 16:15:52 22616 [log in to unmask] Setting >>> VO: atlas roles :/atlas/Role=NULL/Capability=NULL >>> >>> >>> >>> >>> >>> >>> > > BTW:I think when you tried the error was because I had on the server > still denied listing. It's allowed now and I >>> also put >>> > atlas/testfile which should work to get? >>> >>> >>> Ehm no, still 404. >>> >>> Cheers >>> f >>> >>> >>> >>> >>> >>> > > Cheers, >>> > Marcus >>> > > > Cheers >>> > > Fabrizio >>> > > > > > > > > On 03/10/2017 02:36 PM, Marcus Ebert wrote: >>> > > > Ok, getting the davix-tools was easier than I thought. They are > > > available through a GridPP CernVM. >>> > > > However, doing so I get the output: >>> > > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> >>> > > > <html xmlns="http://www.w3.org/1999/xhtml"> >>> > > > <head> >>> > > > <meta http-equiv="content-type" content="text/html;charset=utf-8"/> >>> > > > <link rel="stylesheet" type="text/css" > > > href="/static/css/xrdhttp.css"/> >>> > > > <link rel="icon" type="image/png" href="/static/icons/xrdhttp.ico"/> >>> > > > <title>/</title> >>> > > > </head> >>> > > > <body> >>> > > > <h1>Listing of: /</h1> >>> > > > <div id="header"><table id="ft"> >>> > > > <thead><tr> >>> > > > <th class="mode">Mode</th><th class="flags">Flags</th><th > > > class="size">Size</th><th >>> class="datetime">Modified</th><th >>> > > > class="name">Name</th></tr></thead> >>> > > > <tr><td class="mode">d--rwx</td><td class="mode">51</td><td > > > class="size">4096</td><td class="datetime">Wed, 26 >>> Nov 2014 15:28:25 >>> > > > GMT</td><td class="name"><a href="atlas">atlas</a></td></tr><tr><td > > > class="mode">d--rwx</td><td >>> class="mode">51</td><td >>> > > > class="size">4096</td><td class="datetime">Thu, 27 Nov 2014 16:34:50 > > > GMT</td><td class="name"><a >>> > > > href="dynafeds_demo">dynafeds_demo</a></td></tr><tr><td > > > class="mode">d--rwx</td><td class="mode">51</td><td >>> > > > class="size">167936</td><td class="datetime">Tue, 28 Feb 2017 > > > 16:44:54 GMT</td><td class="name"><a >>> > > > href="georgios_test">georgios_test</a></td></tr></table></div><br><br><hr > > > size=1><p><span >>> id="requestby">Request by >>> > > > /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert/CN=157025827 ( > > > DN: >>> /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus >>> > > > ebert/CN=157025827 ) ( 94.197.120.22.threembb.co.uk )</span></p> >>> > > > <p>Powered by XrdHTTP v20170305-55a66d2 (CERN IT-SDC)</p> >>> > > > > > > > > > Which doesn't say anything about the VO. I tried with an LSST and > > > GridPP proxy. >>> > > > voms info gives for example for gridpp VO: >>> > > > subject : /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus > > > ebert/CN=157025827 >>> > > > issuer : /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert >>> > > > identity : /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert >>> > > > type : RFC compliant proxy >>> > > > strength : 1024 bits >>> > > > path : /tmp/x509up_u501 >>> > > > timeleft : 11:59:33 >>> > > > key usage : Digital Signature, Key Encipherment, Data Encipherment >>> > > > === VO gridpp extension information === >>> > > > VO : gridpp >>> > > > subject : /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus ebert >>> > > > issuer : > > > /C=UK/O=eScience/OU=Manchester/L=HEP/CN=voms.gridpp.ac.uk >>> > > > attribute : /gridpp/Role=NULL/Capability=NULL >>> > > > timeleft : 11:59:33 >>> > > > uri : voms.gridpp.ac.uk:15000 >>> > > > > > > > > > Cheers, >>> > > > Marcus >>> > > > > > > On Fri, 10 Mar 2017, Marcus Ebert wrote: >>> > > > > > > > Thanks Fabrizio! >>> > > > > > > > > I'll try to get the davix-tools made available first. >>> > > > > > > > > Cheers, >>> > > > > Marcus >>> > > > > > > > > On Fri, 10 Mar 2017, Fabrizio Furano wrote: >>> > > > > > > > > > Hi, >>> > > > > > > > > > > sorry, I missed the other questions, here they are... >>> > > > > > > > > > > On 03/10/2017 11:08 AM, Marcus Ebert wrote: >>> > > > > > > Unfortunaely, I don't have davix-get available on the local > > > > > > desktop. Is > there any lsetup mode >>> for Atlas to make that >>> > > > > > available >>> > > > > > > (or any other cvmfs path)? >>> > > > > > > > > > > You can get davix from all the major Linux distributions with > > > > > their own >>> > > > > > tools, apt, yum, ... >>> > > > > > > > > > > cvmfs certainly has it because it's used, but I cannot help you > > > > > there, I >>> > > > > > have no idea (others may chime in) >>> > > > > > > > > > > > > Do you get any similar output if you do this with > > > > > > > > >>> https://dev2.gridpp.ecdf.ed.ac.uk:1094 ? >>> > > > > > > > > > > > It gives to me 404 on the root directory, which is a sign of > > > > > server >>> > > > > > misconfiguration (despite xrootd or http) >>> > > > > > > > > > > > > > > > > If I do so in a browser for your test server, it displays: >>> > > > > > > Request by /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus > > > > > > ebert ( DN: > >>> /C=UK/O=eScience/OU=Edinburgh/L=NeSC/CN=marcus >>> > > > > > ebert ) ( >>> > > > > > > 94.197.120.22.threembb.co.uk ) >>> > > > > > > > Powered by XrdHTTP v20170305-55a66d2 (CERN IT-SDC) >>> > > > > > > > but no VO identification (probably because there is no > > > > > > > voms-proxy > available to the browser >>> and it doesn't do a > > > > > > > lockup in >>> > > > > > > grid-mapfile?) >>> > > > > > > > > > > Browsers do not support Grid proxies. >>> > > > > > The historical workaround for that is the use of a mapfile, as > > > > > you cite. >>> > > > > > Xrdhttp uses the same mapfile >>> > > > > > of the rest of the xrootd framework, which is a bit original if > > > > > one is >>> > > > > > used to the ones used e.g. by DPM. >>> > > > > > > > > > > Anyway I would not go further that way until you have > > > > > troubleshoot your >>> > > > > > client setup. You must be able >>> > > > > > to get from my server the same kind of output that I get. >>> > > > > > > > > > > You can use curl, but it's more complex and less reliable. > > > > > Please do an >>> > > > > > attempt at getting davix. >>> > > > > > > > > > > Please let me know >>> > > > > > Fabrizio >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> >> >> > ######################################################################## 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