Baseline version

Version: DPM should be upgraded to the latest version available from EPEL (1.10.4) and the DOME component must be activated in order to support all the features that are needed for these activities. Please refer to the DPM documentation for further information on this: https://twiki.cern.ch/twiki/bin/view/DPM/DpmSetup

The TPC activities assume the availability of the xrootd and HTTP interfaces, and the fact that they should be reachable from other sites (firewall).

HTTP

TPC is enabled with the NSFlags Write RemoteCopy and DiskFlags Write RemoteCopy (disk server only) config in /etc/httpd/conf.d/zlcgdm-dav.conf.

For good HTTP TPC performance, ensure that the data flow is not encrypted. You need NSSecureRedirect Off in /etc/httpd/conf.d/zlcgdm-dav.conf. Note that this is not an insecure option as access is still authorised via a token, it just means that the data will not go over https.

Enabling TPC token authorization

Since the version 0.19 of its lcgdm-dav frontend, DPM supports macaroons as an experimental authorization feature.

Enabling macaroons in DPM (Aug 2018) can be done either using puppet or manually editing the Apache config file:

• puppet command line setup: in the manifest set the parameter "dmlite::dav::params::ns_macaroon_secret" to your preferred secret string, longer than 64 characters
• manual Apache tinkering:
  • Edit the file /etc/httpd/conf.d/zlcgdm-dav.conf and add the line NSMacaroonSecret <your_secret_string_longer_then_64_chars> to the already existing section <LocationMatch "^/dpm/.*">
  • Make sure that the ssl section says SSLVerifyClient optional

Verifying Apache configuration

You should verify the Apache configuration on disk pools. This is achieved with the command:

grep _dav /proc/`pgrep http | head -1`/maps

You should see only mod_lcgdm_dav.so listed in the results. If you see mod_dav.so then your Apache daemon is wrongly configured.

xroot

If you have ipv6, ensure that you have a consistent setup. We have noticed that inaccessible ipv6 addresses and lack of reverse lookups can lead to authorisation problems. An ipv4-only configuration is fine.

Checksum support will be available in DPM 1.11 when used with xrootd 4.9.

Authentication and Authorisation for TPC

DPM's default configuration uses only the TPC key to authorise the transfer.

DPM as source

default

DPM as a source requires no X509 credential from the destination, only a valid TPC key.

with credential

To require a credential, remove the line sec.protocol /usr/lib64 unix from /etc/xrootd/xrootd-dpmdisk.cfg. Note (see below) that the default DPM configuration, when functioning as a destination, does not present such a credential.

DPM as destination

default

A destination DPM uses xrdcp to pull the file from the source. In the default configuration there is no X509 credential for it to use, but this is fine when getting data from another DPM (see above).

with credential

DPM invokes xrdcp which will automatically use a proxy if it finds one in the usual place /tmp/x509up_u<dpmmgr uid>. This means you can configure a cron job on each disk server to create this proxy regularly as the dpmmgr user and it will be used (use /usr/bin/grid-proxy-init -cert /etc/grid-security/dpmmgr/dpmcert.pem -key /etc/grid-security/dpmmgr/dpmkey.pem). This would allow a destination DPM to authenticate to systems which require any valid X509 credential, but not to those which require dteam membership. For that you need to enrol the host certificate in dteam and use voms-proxy-init to create the proxy. The creation of the proxy is not part of the default configuration and must be configured manually.

When X509 delegation support arrives with xrootd 4.9 DPM will be able to use this credential with a small reconfiguration on the disk server - https://twiki.cern.ch/twiki/bin/view/DPM/DpmSetupManualInstallation#etc_xrootd and https://twiki.cern.ch/twiki/bin/view/DPM/DpmSetupPuppetInstallation#X509_Delegation_for_XrootD_TPC ( needs DPM 1.12)