DPM-Xrootd - Access to the DPM using the XROOTD protocol.

Client Installation and handy mini-tutorial

# yum install xrootd-client

  • Setting the environment

Just a handy variable to use in the examples below.

   # export DPM_HOST=<dpm-headnode-host>
  

Create a X509 proxy, including your VO.

   # voms-proxy-init -voms dteam
   

  • Getting and putting files

Let's start by uploading a local file into DPM storage.

   # xrdcp /tmp/somefile xroot://$DPM_HOST//dteam/file_in_dpm
   

and get it back again:

   # xrdcp xroot://$DPM_HOST//dteam/file_in_dpm /tmp/localfile
   

Puppet Configuration

This section describes how to install and configure dpm-xrootd with puppet. We assume that you have setup your machine with puppet already and are only missing the xrootd-specific options.

Puppet modules to be installed:

puppet module install lcgdm-dmlite 
puppet module install lcgdm-xrootd

DPM central server configuration on head node

# vim /etc/shift.conf
...
DPM PROTOCOLS rfio gsiftp xroot
# service dpm restart

Minimal xrootd configuration

This snippet sets up xrootd on the head node, replacing nodetype 'head' by 'disk', sets it up as a disk node.

class{"xrootd::config":
  xrootd_user  => 'dpmmgr',
  xrootd_group => 'dpmmgr'
}
$sharedkey = "32TO64CHARACTERSTRING"
class{"dmlite::xrootd":
  nodetype              => [ 'head' ],
  domain                => "cern.ch",
  dpm_xrootd_serverport => 1095,
  dpm_xrootd_debug      => true,
  dpm_xrootd_sharedkey  => $sharedkey
}

Alice file access

The xrootd-alicetokenacc has to be installed on the head node as shown below ( available in the WLCG repo). The Alice-specific options available in yaim have also been implemented for puppet

# yum install xrootd-alicetokenacc

class{"dmlite::xrootd":
  nodetype              => [ 'head' ],
  (...)
  alice_token => true,
  alice_token_conf => /etc/grid-security/xrootd/TkAuthz.Authorization,
  alice_token_libname => "libXrdAliceTokenAcc.so.0.0.0",
  alice_token_principal => "alicetoken",
  alice_fqans => "/alice"

Joining a federation

This section explains the additional steps to go if joining a federation.

The federation information is put in a variable (a hash), and consists of the entries formally in the YAIM variables DPM_XROOTD_FEDREDIRS, the DPM_XROOTD_FED__NAMELIBPFX, the DPM_XROOTD_FED__NAMELIB, and the DPM_XROOTD_FED__MISC option. A straight-forward translation should be possible. e.g. whereas YAIM might have used this value:

DPM_XROOTD_FEDREDIRS=cms-xroot.example.com:1094:1098,cms,/cms"

The puppet hash would look like the following:

  $cms_fed = {
    name            => 'cms',
    fed_host       => 'cms-xroot.example.com',
    cmsd_port     => 1213,
    local_port     => 11001,
    direct            => 'true' 
    namelib_prefix => "/dpm/<dpm domain>/home/cms",
    namelib        => "libXrdCmsTfc.so file:/etc/xrootd/storage.xml?protocol=direct",
    paths           => [ '/store' ]
  }

</verbatim>

You can see that there are some more options, which comes from the other yaim variables. There is one additional parameter not appearing in the yaim config. 'local_port' is set be yaim automatically to a port greater than 11000, here it has to be set manually. It is the port, on which the local xroot daemon for the federation listens on. Naturally, only one daemon shold be assigned to each port.

The federation information is given to the dmlite::xrootd module, again as a hash for multiple federations. Note that the names in the hash, here atlas and cms, are used for the names of the configuration and log files.

class{"dmlite::xrootd":
  nodetype              => [ 'head' ],
  domain                => "cern.ch",
  dpm_xrootd_serverport => 1095,
  dpm_xrootd_debug      => true,
  dpm_xrootd_sharedkey  => $sharedkey,
  dpm_xrootd_fedredirs   => { "atlas" => $atlas_fed, "cms" => $cms_fed },
  site_name              => 'site_name'
}

CMS federation

Install the CMS Trivial File Catalogue name2name library. You'll need version compatible with installed XRootD packages and for EPEL releases this means:

The xrootd-cmstfc package may require installation of xerces-c to satisfy the rpm dependencies, e.g. "yum install xerces-c" if necessary.

Install the storage.xml file for your site in /etc/xrootd/storage.xml (available from $VO_CMS_SW_DIR/SITECONF/local/PhEDEx/storage.xml)

Choose a new "protocol" name to use that is not already in use in your storage.xml. (e.g. it is "direct" in the example below). Add the "lfn-to-pfn" following lines to your storage.xml in the section, keeping the order of the two lines. If you are starting with a new file then you have to include the "storage-mapping" tags to create the section as shown:

<storage-mapping>
<lfn-to-pfn protocol="direct" destination-match=".*" path-match="/+store/test/xrootd/<CMS Site Name>/store/(.*)" result="/dpm/<dpm domain>/home/cms/store/$1"/>
<lfn-to-pfn protocol="direct" destination-match=".*" path-match="/+store/(.*)" result="/dpm/<dpm domain>/home/cms/store/$1"/>
</storage-mapping>

Allow incoming connections to the head node on port 11001 (you can change port number to suite site, but avoid 1094 or 1095). Open also a port 11011 internal to your cluster. ( this is needed for a second redirector which is going to fix an issue affecting AAA). In case you would like to provide WAN access via standard port to CMS files, also the 11011 port needs to be public open.

Set the puppet variable as following:

  $cms_fed = {
    name            => 'cms',
    fed_host       => '<cms-xroot.example.com>',
    cmsd_port     => <regional redirector port>,
    local_port     => 11001,
    direct            => 'true' <== NEW PARAMETER 
    namelib_prefix => "/dpm/<dpm domain>/home/cms",
    namelib        => "libXrdCmsTfc.so file:/etc/xrootd/storage.xml?protocol=direct",
    paths           => [ '/store' ]
  }

NEW: A cmslocal redirector is also needed

  $cmslocal_fed = {
    name            => 'cmslocal',
    fed_host       => '<cms-xroot.example.com>',
    xrootd_port   => <regional redirector port>, 
    local_port     => 11011,
    namelib_prefix => "/dpm/<dpm domain>/home/cms",
    namelib        => "libXrdCmsTfc.so file:/etc/xrootd/storage.xml?protocol=direct",
    paths           => [ '/store' ]
  }

ask CMS for the correct address and port of fed_host.

Both redirector configuration need to be filled in the var:

dpm_xrootd_fedredirs   => { "cms" => $cms_fed, "cmslocal" => $cmslocal_fed }

VO central monitoring

Add the following variables xrd_report and xrootd_monitor to the dmlite::xrootd class in the disknodes ( and in the headnode if it acts as a disknode as well).

  • ATLAS only
     class{"dmlite::xrootd":
       nodetype              => [ 'disk' ],
       (...)
       xrd_report            => "uct2-int.mwt2.org:9931 every 60s all -buff -poll sync",
       xrootd_monitor        => "all auth flush 30s window 5s fstat 60 lfn ops xfr 5 dest redir fstat info user uct2-int.mwt2.org:9930 dest redir fstat info user atlas-fax-eu-collector.cern.ch:9330"
     }
   

CMS only

  class{"dmlite::xrootd":
    nodetype              => [ 'disk' ],
    (...)
    xrd_report            => "xrootd.t2.ucsd.edu:9931 every 60s all sync",
    xrootd_monitor        => "all fstat 60 lfn ops ssq xfr 5 ident 5m dest fstat info user redir CMS-AAA-EU-COLLECTOR.cern.ch:9330"
  }

ATLAS and CMS

  class{"dmlite::xrootd":
    nodetype              => [ 'disk' ],
    (...)
    xrd_report            => "xrootd.t2.ucsd.edu:9931,atl-prod05.slac.stanford.edu:9931 every 60s all sync",
    xrootd_monitor        => "all flush 30s ident 5m fstat 60 lfn ops ssq xfr 5 window 5s dest fstat info user redir CMS-AAA-EU-COLLECTOR.cern.ch:9330 dest fstat info user redir atlas-fax-eu-collector.cern.ch:9330"
  }

Manual Configuration: Configuration changes between dpm-xrootd 3.5.5 and dpm-xrootd 3.6.0

The /etc/xrootd/xrootd-dpmfedredir_.cfg configuration file(s) should be changed to remove the proxy module configuration, by removing these lines:

ofs.osslib libXrdPss.so
pss.setopt ...
pss.origin ...

and replace them (i.e. keeping them within the "if exec cmsd" block) with:

oss.statlib -2 libXrdDPMStatInfo.so.3

and add (not inside any "if exec" block):

cms.cidtag <short_headnodename>

where <short_headnodename> should be a unique identifier for your site up to 16 characters long; it is suggested to use the first 16 characters of the fully qualified hostname of the head node. The new cidtag option is only recognised from xrootd 4.3.0 or later (earlier versions will ignore it), so you should also upgrade xrootd to this version.

The /etc/xrootd/xrootd-dpmdisk.cfg on the disknode should be changed to enable the xrootd async option ( previously disabled)

so change :

xrootd.async off

to

xrootd.async on

Manual Configuration: Changes with respect to early, non dmlite versions, i.e. dpm-xrootd 3.1.x

In version dpm-xrootd 3.3.x and later there is now the option of installing the vomsxrd package for extra functionality. This package should be installed unless there is a specific reason not to. See [wiki:Dpm/Xroot/vomsxrd vomsxrd options] for information about compatibility restrictions concerning the use of nodes with and without vomsxrd within a singe DPM system.

dpm-xrootd 3.3.x and later uses the dmlite library and plugins. dmlite is intended to be flexible with a plugin architecture so more configuration options are possible than what is documented on this page.

(1) the directive:

   all.sitename SITE_NAME
   

should be added to all the xrootd-*.cfg files on a node. It is suggested that SITE_NAME be set the same as the string used in the "--site" option for the dpm-listspaces information provided on the head node.

(2) add:

   xrootd.async off
   ofs.tpc pgm /usr/bin/xrdcp --server
   

to /etc/xrootd/xrootd-dpmdisk.cfg

(3) in all xrootd-*.cfg files the line specifying the gsi protocol and options should be:

    • Without vomsxrd:
            sec.protocol /usr/lib64 gsi -crl:3 -key:/etc/grid-security/dpmmgr/dpmkey.pem -cert:/etc/grid-security/dpmmgr/dpmcert.pem -md:sha256:sha1 -ca:2 -gmapopt:10 -vomsat:0
            

    • With vomsxrd:
            sec.protocol /usr/lib64 gsi -crl:3 -key:/etc/grid-security/dpmmgr/dpmkey.pem -cert:/etc/grid-security/dpmmgr/dpmcert.pem -md:sha256:sha1 -ca:2 -gmapopt:10 -vomsfun:/usr/lib64/libXrdSecgsiVOMS.so
            

  • if not using vomsxrd on the head node (see [wiki:Dpm/Xroot/vomsxrd vomsxrd options] for compatibility restrictions), write
       dpm.listvoms
       

  • if using vomsxrd on the head node (see [wiki:Dpm/Xroot/vomsxrd vomsxrd options] for compatibility restrictions), write
       dpm.nohv1
       

(4) in xrootd-dpmredir.cfg and xrootd-dpmfedredir_*.cfg files:

    • dmlite setup. Install dmlite-libs, dmlite-plugins-adapter. If this is a head node also install dmlite-plugins-mysql.
    • On disk only nodes replace /etc/dmlite.conf.d/adapter.conf (ensure the file is owned by dpmmgr:dmmgr permission 640) with:
            LoadPlugin plugin_adapter_dpm /usr/lib64/dmlite/plugin_adapter.so
            LoadPlugin plugin_fs_rfio /usr/lib64/dmlite/plugin_adapter.so
            DpmHost XXXXX
            TokenPassword YYYYY
            TokenId       ip
            TokenLife     1000
            

    • On head node replace /etc/dmlite.conf.d/adapter.conf (ensure the file is owned by dpmmgr:dmmgr permission 640) with:
            LoadPlugin plugin_fs_rfio /usr/lib64/dmlite/plugin_adapter.so
            LoadPlugin plugin_fs_pooldriver /usr/lib64/dmlite/plugin_adapter.so
            DpmHost XXXXX
            TokenPassword YYYYY
            TokenId       ip
            TokenLife     1000
            

and replace /etc/dmlite.conf.d/mysql.conf (ensure the file is owned by dpmmgr:dmmgr permission 640) with

      LoadPlugin plugin_mysql_dpm /usr/lib64/dmlite/plugin_mysql.so
      MySqlHost ZZZZZ
      MySqlUsername dpmmgr
      MySqlPassword PPPPP
      MySqlPort 0
      NsDatabase cns_db
      DpmDatabase dpm_db
      MapFile /etc/lcgdm-mapfile
      NsPoolSize 32
      

(5) On the headnode, in /etc/xrootd/xrootd-dpmredir.cfg add

   dpm.mmreqhost localhost
   

Generic Manual Configuration

dpm-xrootd uses dmlite. So dmlite needs to be configured on each dpm node as well as dpm-xrootd. See the changes summary.

shift.conf on headnode

Add "xroot" to the list of protocols, e.g. in the example below it is shown with rfio and gsiftp. Dependening on other components there may also be other protocols listed, e.g. http & https.

# vim /etc/shift.conf
...
DPM PROTOCOLS rfio gsiftp xroot
# service dpm restart
# service srmv2.2 restart

xrootd sysconfig file on every dpm node

Edit the /etc/sysconfig/xrootd file from the xrootd distribution. Replace or change to make the file do the following:

XROOTD_USER=dpmmgr
XROOTD_GROUP=dpmmgr
XROOTD_DISK_OPTIONS="-l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-dpmdisk.cfg -k fifo"
XROOTD_REDIR_OPTIONS="-l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-dpmredir.cfg -k fifo"
XROOTD_FEDREDIR_CMS_OPTIONS="-l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-dpmfedredir_cms.cfg -k fifo"
CMSD_FEDREDIR_CMS_OPTIONS="-l /var/log/xrootd/cmsd.log -c /etc/xrootd/xrootd-dpmfedredir_cms.cfg -k fifo"
XROOTD_INSTANCES="disk redir"
export DPM_HOST="setdpmname.domain"
export DPNS_HOST="setdpnsname.domain"
if [ `uname -m` = 'x86_64' ]; then
  XRDLIBDIR='lib64'
else
  XRDLIBDIR='lib'
fi
export XRDLIBDIR
export XRD_MAXREDIRECTCOUNT=1
export MALLOC_ARENA_MAX=4
export DPM_CONRETRY=0
export DPNS_CONRETRY=0

xroot redirector and disk access daemon configuration

This section describes the setup for the head node and disk nodes. Following these steps will provide multi-VO basic file access.

Head Node Spefific

Make the changes listed in "xrootd sysconfig file on every dpm node" above to /etc/sysconfig/xrootd, with the following specific setting for the head node:

# vim /etc/sysconfig/xrootd
...
XROOTD_INSTANCES="[disk] redir" (if this is also a disk node include "disk" here, otherwise not)

And also:

# vim /etc/xrootd/xrootd-dpmredir.cfg
...
dpm.defaultprefix /dpm/<dpm domain>/home   (change this to refer to the correct path)
dpm.mmreqhost localhost   (add this line)

# dd bs=1 count=32 if=/dev/random | openssl base64 | tr -d '\012' > /etc/xrootd/dpmxrd-sharedkey.dat
# chown dpmmgr:dpmmgr /etc/xrootd/dpmxrd-sharedkey.dat
# chmod 640 /etc/xrootd/dpmxrd-sharedkey.dat
# chown dpmmgr:dpmmgr /var/log/xrootd
# chkconfig xrootd on
# service xrootd restart

All Disk only Node(s) excluding head node

Make the changes listed in "xrootd sysconfig file on every dpm node" above to /etc/sysconfig/xrootd, with the following specific setting for disk node(s):

# vim /etc/sysconfig/xrootd
...
XROOTD_INSTANCES="disk"

Add the following to /etc/xrootd/xrootd-dpmdisk.cfg

xrootd.async off
ofs.tpc pgm /usr/bin/xrdcp --server
all.sitename SITE_NAME

and change the line

sec.protocol <gsi protocol and options>

where SITE_NAME is your site_name and the gsi protocol and options are as indicated in the Changes section.

Then:

# stat /etc/xrootd/dpmxrd-sharedkey.dat (must be the same as in the head node)
# chown dpmmgr:dpmmgr /var/log/xrootd
# chkconfig xrootd on
# service xrootd restart

ALICE basic file access

The following extra steps are required, on the head node only, to support the ALICE VO. Support for other VOs is not affected.

The xrootd-alicetokenacc has to be installed from the WLCG repo ( either SL6 or C7) first

http://linuxsoft.cern.ch/wlcg/centos7/x86_64/
http://linuxsoft.cern.ch/wlcg/sl6/x86_64/

# yum install xrootd-alicetokenacc

# chown dpmmgr:dpmmgr /etc/grid-security/xrootd/TkAuthz.Authorization
# chown dpmmgr:dpmmgr /etc/grid-security/xrootd/pubkey.pem
# chown dpmmgr:dpmmgr /etc/grid-security/xrootd/privkey.pem

# cat >> /etc/lcgdm-mapfile-local
"alicetoken" alice
^D
# cat >> /etc/lcgdm-mapfile
"alicetoken" alice
^D

Reset your /etc/xrootd/xrootd-dpmredir.cfg like this, but change to the relevant name and see Changes section above for :

#>>>>>>>>>>>>> Variable declarations

# Installation specific
set xrdlibdir = $XRDLIBDIR
set dpmhost = $DPM_HOST
# set xrootfedlport1 = $XROOT_FED_LOCAL_PORT_CMS
# set xrootfedlport2 = ...

#>>>>>>>>>>>>>

all.adminpath /var/spool/xrootd
all.pidpath /var/run/xrootd

xrd.network nodnr
xrootd.seclib libXrdSec.so
sec.protocol <gsi protocol and options>
sec.protocol /usr/$(xrdlibdir) unix

# with vomsxrd:
#dpm.nohv1
# or without vomsxrd:
#dpm.listvoms

ofs.cmslib libXrdDPMFinder.so.3
ofs.osslib libXrdDPMOss.so.3
ofs.authorize
ofs.forward all

dpm.xrdserverport 1095

# for any federations setup provide a reirect to federation handler
# xrootd.redirect $(dpmhost):$(xrootfedlport1) /cms/

# the following can be used to check for and if necessary add a
# prefix to file names. i.e. to allow access via names like /dteam/the_file
dpm.defaultprefix /dpm/<dpm domain>/home

#ofs.trace all
#xrd.trace all
#cms.trace all
#oss.trace all

# adjust for site name
all.sitename SITE-NAME

xrootd.export /

all.role manager

# authorization;
setenv TTOKENAUTHZ_AUTHORIZATIONFILE=/etc/grid-security/xrootd/TkAuthz.Authorization
ofs.authlib libXrdDPMRedirAcc.so.3 libXrdAliceTokenAcc.so.0.0.0
dpm.fixedidrestrict /dpm/<dpm domain>/home/alice
#
# User must be listed in lcgdm-mapfile
dpm.principal alicetoken
dpm.fqan /alice

Finally restart xrootd

# service xrootd restart

Extra Head Node daemons per xroot federation

If you would like your dpm to join xroot federations dpm-xrootd provides an integrated way to do so. It may also be possible for some VOs to use your basic redirector (i.e. setup above) via their own services to join their federations - presumably this should have no impact on the configuration of the dpm nodes.

The instructions below describe the integrated method; it requires running an extra pair of daemons on the head node, "xrootd & cmsd" per federation. The setup of the pair varies between VOs, due to the different approaches taken to name translation or token based access as well as the differing addresses for the meta manager redirector relevant for the VO.

Manual configuration steps to join the federations for various VOs using the integrated method are described below.

CMS federation

Install the CMS Trivial File Catalogue name2name library. You'll need version compatible with installed XRootD packages and for EPEL releases this means:

The xrootd-cmstfc package may require installation of xerces-c to satisfy the rpm dependencies, e.g. "yum install xerces-c" if necessary.

Install the storage.xml file for your site in /etc/xrootd/storage.xml (available from $VO_CMS_SW_DIR/SITECONF/local/PhEDEx/storage.xml). Choose a new "protocol" name to use that is not already in use in your storage.xml. (e.g. it is "direct" in the example below and in xrootd-dpmfedredir_cms.cfg). Add the following lines to your storage.xml in the section, keeping the order of the two lines:

<lfn-to-pfn protocol="direct" destination-match=".*" path-match="/+store/test/xrootd/<CMS Site Name>/store/(.*)" result="/dpm/<dpm domain>/home/cms/store/$1"/>
<lfn-to-pfn protocol="direct" destination-match=".*" path-match="/+store/(.*)" result="/dpm/<dpm domain>/home/cms/store/$1"/>

change and as needed. is usually a name like T2_Region_Site_Name. For CMS TFC details also see https://twiki.cern.ch/twiki/bin/view/Main/XrootdTfcChanges

Allow incoming connections to the head node on port 11001 (you can change port number to suite site, but avoid 1094 or 1095). Open also a port 11011 internal to your cluster. ( this is needed for a second redirector which is going to fix an issue affecting AAA). In case you would like to provide WAN access via standard port to CMS files, also the 11011 port needs to be public open.

The following files need to be updated/added on the headnode ( same for SL6/CentOS6 or SL7/CentOS7 installations) please check the templates to update your conf

https://gitlab.cern.ch/lcgdm/xrootd-conf-example/tree/master/cms

/etc/xrootd/xrootd-dpmredir.cfg -> to add the redirection to the internal redirector
/etc/xrootd/xrootd-dpmfedredir_cms.cfg -> implementing subscription to the regiotnal redirector
/etc/xrootd/xrootd-dpmfedredir_cmslocal.cfg -> implementing redirection to the regional redirector

The regional redirector address and port depends on CMS, so please contact CMS VO experts for this.

For for SL6/CentOS6 installations the following file need to be updated as described in the template

/etc/sysconfig/xrootd

For SL7/CentOS7 installations, Xrootd Unit files override configuration for the Xrootd/Cmsd instances to run need to be created as follows:

# systemctl edit xrootd@dpmfedredir_cms
# systemctl edit xrootd@dpmfedredir_cmslocal
# systemctl edit cmsd@dpmfedredir_cms

to include what is the content of the override.conf file in the template

https://gitlab.cern.ch/lcgdm/xrootd-conf-example/blob/master/cms/override.conf

And finally enable and restart services, on SL6/CentOS6

# chkconfig cmsd on
# service cmsd restart
# service xrootd restart

on SL7/CentOS7

# systemctl enable xrootd@dpmfedredir_cms
# systemctl enable xrootd@dpmfedredir_cmslocal
# systemctl enable cmsd@dpmfedredir_cms
# systemctl restart cmsd@*
# systemctl restart xrootd@*

Local logging level

The configuration file templates used in these manual configuration steps may have settings for a high logging level (depending on the version used). You should reduce these either directly at the time of first configuration or shortly afterwards. To go to the usual level of xrootd logging remove or comment out the directives:

ofs.trace all
xrd.trace all
oss.trace all
pss.trace all
cms.trace all

from /etc/xrootd/xrootd-dpmredir.cfg, xrootd-dpmdisk.cfg and any xrootd-dpmfedredir_VO.cfg files you have for federations. Restart xrootd, on head node & disk nodes for the change to take effect. Also restart cmsd if necessary (run on the head node when using integrated federation).

VO central monitoring

xrootd has the capability to periodically send reports of many aspects of the service and file accesses via udp packets. Some VOs would like to collect this information at a central point for analysis.

At present the monitoring data which xrootd sends can not be filtered by VO. You need to be aware that data access via xroot by any user from any VO on your dpm will cause information concerning the access to be sent to the central VO monitoring endpoints you define here. If this is a concern please do not enable central monitoring. You may like to report it to dpm support.

ATLAS monitoring only

add

xrootd.monitor all auth flush 30s window 5s fstat 60 lfn ops xfr 5 dest redir fstat info user uct2-int.mwt2.org:9930 dest redir fstat info user atlas-fax-eu-collector.cern.ch:9330
xrd.report uct2-int.mwt2.org:9931 every 60s all -buff -poll sync

to /etc/xrootd/xrootd-dpmdisk.cfg on all the disk servers (and head node if it is also a disk server). Restart the xrootd service.

CMS monitoring only

add

xrootd.monitor all fstat 60 lfn ops ssq xfr 5 ident 5m dest fstat info user redir CMS-AAA-EU-COLLECTOR.cern.ch:9330
xrd.report xrootd.t2.ucsd.edu:9931 every 60s all sync

to /etc/xrootd/xrootd-dpmdisk.cfg on all the disk servers (and head node if it is also a disk server). Restart the xrootd service.

ATLAS and CMS monitoring at the same time

add

xrootd.monitor all flush 30s ident 5m fstat 60 lfn ops ssq xfr 5 window 5s dest fstat info user redir CMS-AAA-EU-COLLECTOR.cern.ch:9330 dest fstat info user redir atlas-fax-eu-collector.cern.ch:9330
xrd.report xrootd.t2.ucsd.edu:9931,uct2-int.mwt2.org:9931 every 60s all sync

to /etc/xrootd/xrootd-dpmdisk.cfg on all the disk servers (and head node if it is also a disk server). Restart the xrootd service.

Appendix: Configuration parameters recognised by XrdDPMFinder

dpm.putlifetime
dpm.putfiletype
dpm.putstoken
dpm.fixedidrestrict
dpm.namelib
dpm.enablecmsclient
dpm.defaultprefix
dpm.namecheck
dpm.allowvo
dpm.localroot
dpm.replacementprefix
dpm.putsize
dpm.getlifetime
dpm.getfiletype
dpm.getstoken
dpm.xrdserverport
dpm.mkpath
dpm.mmreqhost
dpm.gracetime
dpm.principal
dpm.fqan
dpm.dmconf

-- FabrizioFurano - 2016-12-07

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r15 - 2022-02-04 - PetrVokac
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    DPM All webs login

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