Print

---

Hello (again),
I am sorry in advance if this is very long and convoluted, touching (too) many topics.
I decided not to attach any log yet, since there are too many cases.
If you agree, we can address case by case at your convenience.

I am testing XRootD HEAD (compiled as of July 16th, 2020) and without http.selfhttps2http and http.secretkey to avoid bias from #1251 discussion.
I am testing it against 4.12.3-1.el7, with only xrdcl-http.x86_64 being 4.12.2-1.el7.

Using the same Authfile (/afs/cern.ch/user/r/rdimaria/public/Authfile-testing) for both 5.0.0 and 4.12.3, the cfg of 5.0.0 (/afs/cern.ch/user/r/rdimaria/public/xrootd-xcache.cfg-testing) differs to 4.12.3 by having:
xrd.tls /etc/grid-security/hostcert.pem /etc/grid-security/hostkey.pem xrd.tlsca certdir /etc/grid-security/certificates
instead of:
http.cadir /etc/grid-security/certificates http.cert /etc/grid-security/hostcert.pem http.key /etc/grid-security/hostkey.pem

I performed tests using:

• ESCAPE VO cert, meaning, 3 attributes in the VO extension
• CMS proxy, having only the default attribute in the VO extension
  and this somewhat changes the results for some specific requests (I explicitly point this out in the following when this happens).

1. "xrdcp" requests

• Requesting an ATLAS file with a CMS cert:
  xrdcp -f -v xroot://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//atlas/atlas_origin6.txt_1024_0 /dev/null
  succeeds for 5.0.0 (NOT expected), whereas fails (as expected) for 4.12.3.
  Using an ESCAPE cert does not show this issue.

• Requesting a CMS file with either certs:
  xrdcp -f -v xroot://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//cms/cms_origin6.txt_1024_0 /dev/null
  succeeds for 5.0.0, whereas fails (NOT expected) for 4.12.3.

• Requesting an ESCAPE file with an ESCAPE cert:
  xrdcp -f -v xroot://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//escape/escape_origin100.txt_1024_0 /dev/null
  succeeds for 5.0.0, whereas fails (NOT expected) for 4.12.3.

2. "davix-get -P grid" requests

• Requesting an ATLAS file with a CMS cert:
  davix-get -P grid https://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//atlas/atlas_origin6.txt_1024_0
  succeeds for 5.0.0 (NOT expected), whereas fails (as expected) for 4.12.3.
  Using an ESCAPE cert does not show this issue (but be careful of https to reach the cache - see later...). same as 1.

• Requesting a CMS file with either certs:
  davix-get -P grid https://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//cms/cms_origin6.txt_1024_0
  succeeds for 5.0.0, whereas fails (NOT expected) for 4.12.3. same as 1.

• Requesting an ATLAS file with an ESCAPE cert (see above - here using http to reach the cache):
  davix-get -P grid http://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//atlas/atlas_origin333.txt_1024_0
  succeeds for 5.0.0 (NOT expected), whereas fails (as expected) for 4.12.3.

3. "curl -L -H "Authorization: Bearer $TOKEN" -k -XGET" requests - should be able to read only CMS:

• Requesting an ATLAS file:
  curl -L -H "Authorization: Bearer $TOKEN" -k -XGET https://escape-wp2-puppet-xcache-level0-02.cern.ch:1094//https://escape-wp2-puppet-mockdata-server.cern.ch:1213//atlas/atlas_origin6.txt_1024_0
  succeeds for 5.0.0 (NOT expected), whereas fails (as expected) for 4.12.3.

Again, sorry.
Please let me know what I could provide to start with.

Best,
Riccardo

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1