Print

Print


Hi Andy,

Ah, good to know.  Please let me know when there is a new version of the 
plugin available for testing.

Thanks,
  Marcus

On Thu, 16 Mar 2017, Andrew Hanushevsky wrote:

> Hi Marcus,
>
> This appears to be a problem with the way the http plugin constructs the 
> security context from the certificate. I will discuss this with Fabrizio next 
> week and straighten it out.
>
> Andy
>
> On Thu, 16 Mar 2017, 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
>> 
>
>
>

-- 
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