search

cern-fts / gfal2

Multi-protocol data management library
https://dmc-docs.web.cern.ch/dmc-docs/
Other
7 stars 13 forks source link

IPv6 flag does not have an affect with xrootd as protocol #3

Open thdesy opened 3 years ago

thdesy commented 3 years ago

Hi,

it seems that with gfal-copy version [1] the IP version switch does not have an affect.

We are currently debugging a routing problem and have noticed, that even with explicitly requirering IPv4 the IPv6 route is used E.g.,

> gfal-copy -f -4 -vv root://dcache-door-cms20.desy.de:1094/store/foo/baz  /tmp/hartmath.1

resolving the A/AAAA records explicitly takes the expected protocol, i.e.,

> gfal-copy -f  -vv root://131.169.191.216:1094/store/foo/baz  /tmp/hartmath.1
> gfal-copy -f  -vv root://[2001:638:700:10bf::1:d8]::1094/store/foo/baz  /tmp/hartmath.1

the problem appears to be similar with the xrd-tools (v4.11.3), e.g.,

xrdcp --debug 3 root://[2001:638:700:10bf::1:d8]:1094///store/foo/baz /tmp/hartmath.1 (where xrd-tools seem to have no IP version switch)

Cheers, Thomas

[1]

gfal-copy --version gfal2-util version 1.5.3 (gfal2 2.17.2) dcap-2.17.2 file-2.17.2 gridftp-2.17.2 http-2.17.2 lfc-2.17.2 rfio-2.17.2 sftp-2.17.2 srm-2.17.2 xrootd-2.17.2 from /cvmfs/grid.cern.ch/centos7-umd4-ui-4_200423/usr/bin/gfal-copy

thdesy commented 3 years ago

addendum: I just noticed, that the behaviour is inconsistent between the transfer protocols and the using explicitly IPv4/IPv6 addresses. For WebDAV and gsiFTP apparently the handshake fails with the host cert DN, i.e., the FQDN, does not match the given address, i.e., the IP

> gfal-copy -f -vv davs://[2001:638:700:10bf::1:d8]:2880/pnfs/foo/baz  /tmp/hartmath.1
 INFO     Davix: Impossible to Recover with Metalink: (Neon): Server certificate verification failed: certificate issued for a different hostname
gfal-copy error: 112 (Host is down) - Could not stat the source: Result (Neon): Server certificate verification failed: certificate issued for a different hostname after 1 attempts

> gfal-copy -f  -vv root://[2001:638:700:10bf::1:d8]::1094/store/foo/baz  /tmp/hartmath.1
 INFO     Event triggered: BOTH xroot TRANSFER:ENTER root://[2001:638:700:10bf::1:d8]:1094///store/foo/baz?xrd.gsiusrpxy=/tmp/x509up_u26551 => file://localhost///tmp/hartmath.1?xrd.gsiusrpxy=/tmp/x509up_u26551
event: [1603460504727] BOTH   xroot TRANSFER:TYPE   streamed
INFO     Event triggered: BOTH xroot TRANSFER:TYPE streamed

I guess, it is probably related to the xrootd security model?

andrea-manzi commented 3 years ago

Hi Thomas, if i remember correctly this is a known issue and the flags work only with srm and gsiftp protocol, maybe @mpatrascoiu can have a look a the Jira for the related open issue. As a workaround for Xrootd you can specify the XRD_NETWORKSTACK var,

XRD_NETWORKSTACK=ipv4 gfal-copy -f -vv root://dcache-door-cms20.desy.de:1094/store/foo/baz /tmp/hartmath.1

cheers Andrea

mpatrascoiu commented 3 years ago

Hello Thomas,

The discussion on IPv4/6 is picking up within DOMA.

Right now, only the GridFTP plugin offers support for changing the IP stack. I'm working on making Gfal2 offer better support for the XRootD and HTTP plugins as well.

Cheers, Mihai

mpatrascoiu commented 3 years ago

Hello Thomas,

For Gfal2 XRootd plugin, I have opened this issue: https://github.com/xrootd/xrootd/issues/1472

Cheers, Mihai