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
|