Starting xrootd

The simplest possible setup is one server and one or more clients:

As with the original rootd server, this is relatively easy to setup. Assuming you have installed xrootd, you can start it as:

kan001> xrootd

Unlike the rootd server, this doesn't immediately go into background, but in fact produces some amount of logging information. You should see something like:

040816 05:00:42 001 (c) 2004 Stanford University/SLAC xrd version 20040810-2328
040816 05:00:42 001 xrd@kan001.slac.stanford.edu initialization started.
040816 05:00:42 001 Optimizing for 4096 connections; maximum is 16384
040816 05:00:42 001 (c) 2003 Stanford University/SLAC XRootd (eXtended Root Daemon).
040816 05:00:42 001 XRootd seclib not specified; strong authentication disabled
040816 05:00:42 001 XRootd fslib not specified; using native file system
040816 05:00:42 001 (c) 2003 Stanford University/SLAC sfs (Standard File System)v 9.0n
040816 05:00:42 001 Prep log directory not specified; prepare tracking disabled.
040816 05:00:42 001 Warning, only '/tmp' will be exported.
040816 05:00:42 001 XRootd protocol version 2.2.0 build 20040810-2328 successfully loaded.
040816 05:00:42 001 xrd@kan001.slac.stanford.edu:1094 initialization completed.

(Obviously you can send this to a log file. More on that later.) Using some xrootd client application, you should be able to access a file on the server using the same syntax as with TNetFile/rootd, for example:

root://kan001//tmp/mydatafile.root

From a client-side application such as a ROOT interactive session, you should be able to open the file and perform operations on it:

root [1] myfile = TFile::Open("root://kan001//tmp/mydatafile.root");    
root [2] myfile->ls(); 
XTNetFile**             root://kan001//tmp/mydatafile.root
 XTNetFile*             root://kan001//tmp/mydatafile.root
  KEY: TF1      fooHist;1       gaus
  KEY: TF1      barHist;1       gaus
root [3] myfile->Close();
root [4] .q

The log printout from xrootd will show something like:

040816 05:24:33 019 XrootdXeq: User logged in as elmer.3630:17@noric15
040816 05:24:44 019 XrdLink: elmer.3630:17@noric15 disconnected after 0:00:11

Accessing areas other than /tmp

One important difference from rootd is that xrootd by default only allows one to access files in /tmp. This is for security reasons so that a running xrootd doesn't give remote clients access to read (or write to!) everything visible as xrootd.

A client accessing an area which is not explicitly exported by xrootd, e.g.:

root://kan001//data/mydatafile.root

will get an error such as:

Error in : Server [kan001.slac.stanford.edu:1094] did not return OK message for last request.
Error in : Server declared error 3010: 'Opening path '/data/mydatafile.root' is disallowed.'
Error in : Error opening the file ///data/mydatafile.root on host kan001.slac.stanford.edu:1094

You must specify explicitly any directories you wish to export via xrootd. This can be done on the command line when starting xrootd, for example:

kan001> xrootd /data

will export the /data directory.

xrootd log files

xrootd has a command line option to specify the output log file name:

kan001> xrootd -l xrdlog &

The primary advantage of using this option as opposed to simply redirecting the output to a file is that there is also a feature which does automatic log file rotation. At midnight each night xrootd will move the current xrdlog logfile to "xrdlog.yyyymmdd" and then continue writing to xrdlog.

Alternate port numbers

As with rootd, xrootd will started automatically on the IANA assigned port number 1094. If you need to start it on another port, that can be done as:

kan001> xrootd -p 2525

and the client-side applications would then need to access the file as:

root://kan001:2525//tmp/mydatafile.root

In general it is probably simplest to run xrootd on the standard port 1094.

Configuration files

xrootd can be configured via a config file as well as via command line options. There are in fact many more options available via the config file and hence this is the recommended way of starting xrootd:

kan001> xrootd -l xrdlog -c xrootd.cf &

where the config file "xrootd.cf" can have configuration directives like:

# Start the server on port 2525
xrd.port 2525
# Export files in /data only
xrootd.export /data

in order to achieve (for example) what was done with command line options in the sections above. Note that lines beginning with "#" are taken to be comments and ignored. For the moment we just note that all config lines are of the form:

<configclass>.<option> [optval1] [optval2] [...]

It is also important to note that spelling errors in either <configclass> or <option> will result in the entire line being (silently) ignored.

Read-only data access

An important thing to note about xrootd access to files is that by default it allows any accessed file to be opened in update mode (and/or new files to be created). For many situations this is undesirable: the goal is simply to make data files available for others to read. The easiest thing to do in that case is simply to disallow all write access. To do this you need to add two lines to your config file:

xrootd.fslib /opt/xrootd/lib/libXrdOfs.so
oss.readonly

in your log file. The first of these will cause the shared library for the optional ofs/oss file layer to be loaded (the exact path the "lib" area will depend on how you installed xrootd). This shared library provides a number of filesystem extensions. The second line disallows all write/update access using one of these options.

More fine-grained configurations are possible, but globally disallowing writes like this should cover a common use case.

Single server summary

This example has described various options for using xrootd with a single server.

To summarize: suppose you want to provide read-only access for users to a bunch of data files on some server in /data (and run xrootd on the standard port). You want automatic rotation/renaming of the log file each night at midnight. The config file would be:

#
# xrootd.cf
#
xrootd.fslib /opt/xrootd/lib/libXrdOfs.so
oss.readonly
xrootd.export /data

and you would start the server as:

prompt> xrootd -l xrdlog -c xrootd.cf &