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)