Print

Print


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