 |
 |
Hi Fabrizio, On Thu, 16 Mar 2017, Fabrizio Furano wrote: > 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 ? The authorization part in the config is: xrootd.seclib /usr/lib64/libXrdSec-4.so acc.authdb /etc/xrootd/auth_file sec.protparm gsi -d:3 -vomsfun:/usr/lib64/libXrdSecgsiVOMS-4.so -vomsfunparms:certfmt=raw|grpfmt=<g>|vos=gridpp,atlas,lsst,dteam,lhcb|grps=/gridpp,/atlas,/lsst,/dteam,/lhcb|dbg -vomsat:2 sec.protocol /usr/lib64 gsi -ca:1 -crl:3 #sec.protocol /usr/lib64 unix #needed later for read access by everyone to etc xrootd.fslib /usr/lib64/libXrdOfs.so xrootd.async off ofs.authorize 1 > Is this a redirector or a data server ? > That's just a data server. I use the server behind the redirector directly for now to have a simpler setup until it works. Cheers, Marcus > 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>> >>> >> > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ######################################################################## 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