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