Skip to content

Install XRootD Standalone

EL7 version compatibility

There is an incompatibility with EL7 < 7.5 due to an issue with the globus-gsi-proxy-core package

XRootD is a hierarchical storage system that can be used in a variety of ways to access data, typically distributed among actual storage resources. In this document we focus on using XRootD as a simple layer exporting an underlying storage system (e.g., HDFS) to the outside world.

Before Starting

Before starting the installation process, consider the following points:

  • User IDs: If it does not exist already, the installation will create the Linux user ID xrootd
  • Service certificate: The XRootD service uses a host certificate and key pair at /etc/grid-security/xrd/xrdcert.pem and /etc/grid-security/xrd/xrdkey.pem
  • Networking: The XRootD service uses port 1094 by default

As with all OSG software installations, there are some one-time (per host) steps to prepare in advance:

Installing XRootD

To install the XRootD Standalone server, run the following Yum command:

[email protected] # yum install osg-xrootd-standalone

Configuring XRootD

To configure XRootD as a standalone server, you will modify /etc/xrootd/xrootd-standalone.cfg and the config files under /etc/xrootd/config.d/ as follows:

  1. Configure a rootdir in /etc/xrootd/config.d/10-common-site-local.cfg, to point to the top of the directory hierarchy which you wish to serve via XRootD. For example, to serve /data:

    set rootdir = /data

  2. To limit the sub-directories to serve under your configured rootdir, comment out the all.export / directive in /etc/xrootd/config.d/90-osg-standalone-paths.cfg, and add an all.export directive for each directory under rootdir that you wish to serve via XRootD. For example, to serve the contents of /data/store and /data/public (with rootdir configured to /data):

    all.export /store/
all.export /public/

    Note

    The directories specified this way are writable by default. Access controls should be managed via authorization configuration.

  3. In /etc/xrootd/config.d/10-common-site-local.cfg, add a line to set the resourcename variable to the resource name of your XRootD service. For example, the XRootD service registered at the FermiGrid site should set the following configuration:

    set resourcename = Fermilab Public DCache

    Note

    CMS sites should follow CMS policy for resourcename

  4. On EL 6, set the default options to use the standalone configuration in the /etc/sysconfig/xrootd file.

    XROOTD_DEFAULT_OPTIONS="-l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-standalone.cfg -k fifo"

Configuring authorization

To configure XRootD authorization please follow the documentation here.

Optional configuration

The following configuration steps are optional and will likely not be required for setting up a small site. If you do not need any of the following special configurations, skip to the section on using XRootD.

Enabling Hadoop support (EL 7 Only)

For documentation on how to export your Hadoop storage using XRootD please see this documentation

Enabling CMS TFC support (CMS sites only)

For CMS users, there is a package available to integrate rule-based name lookup using a storage.xml file. See this documentation.

Using XRootD

In addition to the XRootD service itself, there are a number of supporting services in your installation. The specific services are:

Software Service Name Notes
Fetch CRL fetch-crl-boot and fetch-crl-cron See CA documentation for more info
XRootD EL 7:[email protected], EL 6:xrootd

Start the services in the order listed and stop them in reverse order. As a reminder, here are common service commands (all run as root):

To … On EL 7, run the command… On EL 6, run the command…
Start a service systemctl start SERVICE-NAME service SERVICE-NAME start
Stop a service systemctl stop SERVICE-NAME service SERVICE-NAME stop
Enable a service to start during boot systemctl enable SERVICE-NAME chkconfig SERVICE-NAME on
Disable a service from starting during boot systemctl disable SERVICE-NAME chkconfig SERVICE-NAME off

Validating XRootD

To validate an XRootD installation, perform the following verification steps:

  1. Verify file transfer over the XRootD protocol using XRootD client tools:

    1. Install the client tools:

      [email protected] # yum install xrootd-client

    2. Copy a file to a directory for which you have write access:

      [email protected] # xrdcp /bin/sh root://localhost:1094//tmp/first_test
[xrootd] Total 0.76 MB  [====================] 100.00 % [inf MB/s]

    3. Verify that the file has been copied over:

      [email protected] # ls -l /tmp/first_test
-rw-r--r-- 1 xrootd xrootd 801512 Apr 11 10:48 /tmp/first_test

  2. Verify file transfer over HTTP using GFAL2 client tools:

    1. Install the GFAL2 client tools:

      [email protected] # yum install gfal2-util gfal2-plugin-http

    2. Copy a file to a directory for which you have write access:

      [email protected] # gfal-copy /bin/sh http://localhost:1094//tmp/first_test

    3. Verify that the file has been copied over:

      [email protected] # ls -l /tmp/first_test
-rw-r--r-- 1 xrootd xrootd 801512 Apr 11 10:48 /tmp/first_test

Getting Help

To get assistance. please use the Help Procedure page.

Reference

Service Configuration

On EL 6, which config to use is set in the file /etc/sysconfig/xrootd.

To use the standalone config, you would use:

XROOTD_DEFAULT_OPTIONS="-l /var/log/xrootd/xrootd.log -c /etc/xrootd/xrootd-standalone.cfg -k fifo"

On EL 7, which config to use is determined by the service name given to systemctl. To use the standalone config, you would use:

[email protected] # systemctl start [email protected]

File locations

Service/Process Configuration File Description
xrootd /etc/xrootd/xrootd-standalone.cfg Main XRootD configuration
/etc/xrootd/config.d/ Drop-in configuration dir
/etc/xrootd/auth_file Authorized users file
Service/Process Log File Description
xrootd /var/log/xrootd/server/xrootd.log XRootD server daemon log
cmsd /var/log/xrootd/server/cmsd.log Cluster management log
This material is based upon work supported by the National Science Foundation under Grant Nos. 1148698 and 1836650 . Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.