dCache supports both HTTP and xrootd third-party transfers.

HTTP

HTTP third-party transfer (TPC) is available in all currently supported versions of dCache. It is also available in some unsupported versions of dCache.

To enable HTTP TPC, your dCache cluster must run at least one webdav service and must run at least one transfermanagers service.

In addition, it is recommended that your dCache cluster also run one (or more) srm service and one (or more) srmmanager service. For this to be useful, external clients MUST be able to establish TCP connections to the (normally unused) SSL port. The port number is controlled by the srm.net.ssl-port property, with the default port being 8445. Please check your firewall settings!

It is currently NOT required to support IPv6 for this testbed. However, you must have a consistent IPv6 deployment. If you have a DNS AAAA record for nodes hosting your WebDAV doors, then those nodes must accept TCP connections using the advertised IPv6 address.

To be useful, you must configure your dCache cluster so that macaroons are enabled. This is controlled by the dcache.enable.macaroons configuration property (or webdav.enable.macaroons when configuration targets just WebDAV doors). Macaroon support is enabled by default.

You must not configure the WebDAV doors so that they require the client to authenticate via X.509. This is controlled by the webdav.authn.require-client-cert property. The default value for this property is false, so the default configuration is compatible with HTTP TPC.

The following chart contains the baseline versions for various services in dCache. The minimum versions are given for all currently supported versions dCache (v3.2, v4.0, v4.1 and v4.2). Running an earlier version of any service is not recommended as this risks experiencing problems that are known and already fixed. The version of services not listed should not matter.

Service v3.2 v4.0 v4.1 v4.2 v5.0
webdav 3.2.39 4.0.31 4.1.25 4.2.17 5.0.0
srmmanager 3.2.38 4.0.30 4.1.24 4.2.16 5.0.0
pnfsmanager 3.2.36 4.0.28 4.1.22 4.2.14 5.0.0
transfermanagers 3.2.36 4.0.28 4.1.22 4.2.14 5.0.0
pool 3.2.37 4.0.29 4.1.23 4.2.15 5.0.0

All tests are conducted with the dteam VO. This means that you must provide write access for this VO.

All pools participated in HTTP TPC transfers must have the IGTF trust store installed. Typically, this is installed from packages (RPM or deb) with the files located in `/etc/grid-security/certificates` directory. They also require up-to-date CRLs, which is normally achieved using the 'fetch-crl' script.

Some sites run 'srm' and 'srmmanager' on separate machines. Such sites must configure the srmmanager.net.host to be the FQDN of the 'srm' endpoint.

A current limitation of GridSite is that a site runs a single 'srmmanager' instance.

xrootd

xrootd third-party copy (TPC) is supported with dCache v4.2

TPC transfers may be done either in unauthenticated mode, or with GSI (X509) authentication.

TPC from dCache to another xrootd server

Very few changes in the dCache door were needed to accomplish this. If dCache is merely to serve as file source, then all that is needed is to update to version 4.2+ on the nodes running the xrootd doors.

TPC from another xrootd server to dCache, or between dCache instances

As per the protocol, the destination pulls/reads the file from the source and writes it locally to a selected pool. This is achieved by an embedded third-party client which runs on the pool. Hence, using dCache as destination means the pools must also be running dCache 4.2+.

Changes to dCache configuration for authenticated (GSI) transfers

For dCache as source, gPlazma configuration is identical to that needed for normal two-party reads and writes, with the caveat that the necessary destination DNs must be mapped on the dCache end. This will depend upon the nature of the proxy credential being used by the source.

To use dCache as TPC destination, some additional steps need to be taken.

First, for all pools that will receive files through xrootd TPC, the GSI service provider plugin must be loaded by including this in the configuration or layout:

         pool.mover.xrootd.tpc-authn-plugins=gsi

Second, until the generally agreed upon solution for proxy delegation is adopted and implemented, there are two ways of providing authentication capability to these pools.

  • Generate a proxy from a credential that will be recognized by the source, and arrange to have it placed (and periodically refreshed) on each pool that may be the recipient of files transfered via xrootd TPC. The proxy path must be indicated to dCache by setting this property:

         xrootd.gsi.tpc.proxy.path={path-to-proxy}

  • If this property is left undefined, dCache will auto-generate a proxy from the hostcert.pem/hostkey.pem of the node on which the pool is running. While this solution means no cron job is necessary to keep the proxy up to date, it is also rather clunky in that it requires the hostcert DNs of all the pools to be mapped on the source server end.

Signed hash verification (kXR_sigver) support

The embedded third-party client will honor signed hash verification if the source server indicates it must be observed.

Starting with dCache 5.0, the dCache door/server will also provide the option to enable signed hash verification.

However, there is a caveat here. Since dCache redirects reads from the door to a selected pool, and since the subsequent connection to the pool is unauthenticated (this has always been the case; the connection fails if the opaque id token dCache gives back to the client is missing), the only way to get signed hash verification on the destination-to-pool connection is to set the kXR_secOFrce flag. This means that the pool will then require unix authentication from the destination and that it will expect unencrypted hashes.

While the usefulness of unencrypted signed hash verification is disputable, the specification nevertheless provides for it, and this was the only way, short of encumbering our pool interactions with yet another GSI handshake, to allow for sigver on the dCache end at all, since the main subsequent requests (open, read, etc.) are made to the pool, not the door.

dCache 5.0 will provide the following properties to control security level and force unencrypted signing:

          dcache.xrootd.security.level={0-4}
          dcache.xrootd.security.force-signing={true,false}

In the case that the latter is set to true, and one anticipates there will be xrootd TPC transfers between two dCache instances or two dCache doors, one also would need to include the unix service provider plugin in all the relevant pool configurations:

          pool.mover.xrootd.tpc-authn-plugins=gsi,unix

-- PaulMillarExCern - 2018-10-29

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2019-10-16 - PaulMillar1
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback