WLCG DOMA BDT Meeting
Topic: WLCG DOMA BDT Meeting (twiki)
-
-
16:30
→
16:40
News 10m
-
16:40
→
16:55
Transfers with tokens 15mSpeaker: Francesco Giacomini (INFN CNAF)
Compliance tests and site configuration for experiments
FNAL dCache with tokens
- configured with ownership inheritance
- also export data with NFS
ATLAS XCache
- only for stage-in
- involve Ilija in discussion how to use tokens with root://xcache:1094//root://source:1094/path/file
Transfers with root:// protocol
With no bearer token and just X.509 VOMS proxy I get complains while trying to access dCache 8.2.10
$ xrdfs root://xrd.farm.particle.cz:1094 ls / > /dev/null $ xrdfs root://dcache.farm.particle.cz:1094 ls / > /dev/null security protocol 'ztn' disallowed for non-TLS connections.
while there is no such error message for XRootD server. Authentication send by
- dCache: &P=ztn,0:4096:&P=gsi,v:10400,c:ssl,ca:dec71a0b&P=unix
- XRootD: &P=ztn,0:4096:&P=gsi,v:10600,c:ssl,ca:8d33f237.0|dec71a0b.0
XRootD client don't even try to find bearer token in dCache case and complain while in XRootD server case client just give up on ZTN after it realize there is no token available.
xrdfs client is asked by XRootD server to upgrade connection to TLS while dCache doesn't ask for this upgrade => first connection gets secured and that's why client doesn't show ztn security warning.
while trying to understand these differences we discovered an issue how dCache apply different xrootd.security.tls.mode configurations.
- 16:55 → 17:05
-
17:05
→
17:15
Packet marking 10mSpeakers: Marian Babik (CERN), Shawn Mc Kee (University of Michigan (US))
-
17:15
→
17:25
WebDAV Error Message Improvement Project 10m
Discuss with experts improvements in the error messages produced by failed transfers.
Speaker: Stephan Lammel (Fermi National Accelerator Lab. (US)) -
17:25
→
17:30
AOB 5m
HTTP-TPC push StoRM - GOOGLE
- discussed in GGUS:158487, related StoRM ticket STOR-1563
- GOOGLE site should be promoted to ATLAS T2 soon
- we need this issue to be fixed
FTS update
- improved logging - passive party address from RemoteConnections PerfMarker logged even without noisy debug level
- more readable log output
- deployed on fts3-devel.cern.ch
- production instances in ~ a month
Improving HTTP-TPC monitoring with active party address
- updated proposal for including both addresses (source and destination) in the PerfMarkers
Rucio DOMA testbed
- not running for a while, Monit people asked if we still need inactive message brokers topics for this testbed
- destroy everything and start from scratch in future? to be asked in Rucio meeting tomorrow...
-
16:30
→
16:40