Skip to content

Xrootd Third Party Copy

Jürgen Starek edited this page Jan 22, 2019 · 14 revisions

Obsolete documentation

This wiki contains various bits of information that have meanwhile been integrated into our main body of documentation, The dCache Book. These texts will be removed from here during early 2019 in order to avoid fragmentation of the documentation.


Starting with dCache 4.2, native third-party transfers between dCache and another xrootd server (including another dCache door) are possible. These can be done either in unauthenticated mode, or with GSI (X509) authentication, using the client provided by SLAC (xrdcp or xrdcopy).

To enforce third-party copy, one must execute the transfer using

            `xrdcp --tpc only <source> <destination>`

One can also try third party and fail over to one-hop two-party (through the client) by using

            `xrdcp --tpc first <source> <destination>`

Changes to dCache configuration for authenticated (GSI) transfers

Because authentication is enforced between the source and destination servers (even though they are both holding a rendezvous token), the following must be done:

  • all dCache xrootd doors, but also write pools serving xrootd transfers, must have a valid host certificate and set of CA CRLS.

  • all dCache write pools serving xrootd transfers must be configured for the gsi client plugin; this means defining the following property, either in the dcache.conf or layout file:

             `pool.mover.xrootd.tpc-authn-plugins=gsi`
    
  • a proxy certificate must be made available to any SLAC xrootd server being used as destination (see the documentation at the XrootD site on how to configure the server for this).

  • the DNs for all the certificates communicating with dCache (e.g., host certs for dCache door nodes and pool nodes, proxy certs for SLAC server nodes) must be mapped in gPlazma.

The dCache GSI xrootd plugin automatically generates a proxy from the host certificate, but the SLAC server (which uses the SLAC client to read-write the file from the source when it is destination) needs the certificate to be generated (and renewed) externally (a common solution for this is to set up a cron job).

Incompatibilities

In order to allow the dCache door to act as source in a third-party copy, only a few modifications of the code were necessary. If all that is desired is to transfer files from dCache to a vanilla/SLAC server, then only the door version needs to be upgraded to 4.2+.

If, however, one wishes to write to dCache from an external (SLAC) server, or even write from one dCache xrootd door to another, then the pools must also be at version 4.2+.

This is because the xrootd protocol requires the destination to pull the file from the source. The dCache xrootd transfer service active on the pool thus needs to have an embedded client which can read and then write to the pool. Pools without this additional functionality will not be able to act as destination in a third-party transfer and a "tpc not supported" error will be reported if --tpc only is specified.