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
|