Scalla
Configuration File Syntax
Andrew Hanushevsky
Stanford Linear
8 January 2008
Scalla: Structured Cluster Architecture for Low Latency Access
©2004-2008 by the Board of Trustees of the Leland Stanford,
Jr., University
All Rights Reserved
Produced under contract DE-AC02-76-SFO0515 with the Department
of Energy
This code is available under a BSD-style
license allowing minimally restricted use.
This document describes the syntax used in the configuration file for xrootd and cmsd. Refer to the respective configuration documents on directive details.
All configuration directives start
with a prefix identifying the system component to which the directive applies. The
prefix is separated by the actual directive keyword by a single period. This
allows configuration of all aspects of a system using a single configuration
file. The following table lists valid prefixes. Grayed rows indicate components
that have been replaced but are still accepted for upward compatibility. You
should migrate to the new components as quickly as possible.
|
Prefix |
System Component |
|
acc |
Access control (i.e., authorization) |
|
cms |
Cluster Management Services[1] |
|
odc |
Open distribute clustering[2] |
|
ofs |
Open file system coordinating acc, odc, & oss components |
|
olb |
Open Load Balancing[3] |
|
oss |
Open storage system (i.e., file
system implementation) |
|
sec |
Security authentication |
|
xrd |
Extended Request Daemon |
|
xrootd |
The xrootd protocol
implementation. |
|
all |
Applies the directive to all of
the above components. |
Records that do not start
with a recognized identifier are ignored. This
includes blank record, comment lines (i.e., lines starting with a pound sign,
#), and prefixes not immediately followed by a single period. Because each
component has a unique prefix, a common configuration file can be used for the
whole system. The location
of the configuration file is specified on the command line. Refer to the
reference manuals for each component on how it locates the configuration files.
This guide documents the basic directive syntax and
describes the use of conditional statements and set variables within the
configuration file.
The if-fi directives are used
to allow you to optionally include directives based on host and instance name.
The syntax for this directive pair is:
if [ hostpat [. . .] ] [ conds ]
[ other
directives when if is true
]
[
else
[ other
directives when if is false
]
]
fi
hostpat: host | host+
| pfx* | *sfx | pfx*sfx]
conds: cond1 | cond2
cond1: exec pgm [. . .] [&& cond2]
cond2: named name [. . .]
Function
Specify the conditions under which subsequent directives are to be used.
Parameters
hostpat
The pattern of the host to which subsequent directive applies. All non-applicable hosts ignore all directives until the fi. Host patterns are:
host Any host that matches the specified DNS name.
host+ Any host that has an address that matches any of the addresses assigned to host.
pfx* Any host starting with pfx.
*sfx Any host ending with sfx.
pfx*sfx Any host beginning with pfx and ending with sfx.
name An instance name (i.e., a name that can be
specified using the –n command
line option). All directives until the fi are ignored unless the executable
has been given one of the names in the list of names.
pgm The prefix-name of the executable. The prefix-name is defined to be all of the characters in the base filename (i.e., the directory path removed) up to but not including the first dot in the name, if any. If the name starts with a dot, the prefix-name is the complete base filename.
Defaults
None.
At least one hostpat, exec or the named keyword must be specified.
Notes
1) All specified conditions must be true (i.e., hostpat, exec, and named) for the subsequent directives to be used.
2) Every if must be followed by a fi. Every fi must be preceded by an if.
3) Every else must be preceded by an if.
4) Nested if directives are not allowed.
5) The name anon refers to servers that were not given a name via –n.
6) Some directives allow the “if” to be placed as the rightmost tokens on the associated directive line. For these directives, no “fi” is required as the end of the line determines the if’s scope.
Examples
if
*slac.stanford.edu named anon
xrd.port 9999
fi
if named public
xrd.port
8888
else
xrd.port
9999
fi
if exec olbd && named public
xrd.port
2131
else
xrd.port
1094
fi
set var = {
value | $envvar }
Function
Specify the value a set variable must have.
Parameters
var The name of a variable. Variable names
may only contain letters and digits and should start with a letter. Case is
significant. Variable names may not be longer than 63 characters.
value The
value to be assigned to the variable. It must consist of a single non-blank
text token no longer than 511 characters.
$envvar
Specifies that the value comes from an environmental variable named envvar. The environmental
variable must be set to a single non-blank text token no longer than 511
characters.
Notes
1) Use of an environmental variable that has not been set is considered to be a fatal error.
Example
set myVar = myToken
set
yourVar=$EnvVar
1st_token
subs
subs: [vname][text][subs]
vname: $var
| ${var} | $(var)
Function
Specify a variable to be substituted by its set value.
Parameters
1st_token
The first token in any line of a
configuration file. The first token may never specify a variable and is one of
the following:
·
A
prefixed directive
·
if, else,
or the token fi
·
set
·
#
(indicating a comment)
text Any text.
$var The
name of a set variable. The variable name ends when an non-alphanumeric
character is encountered; including the of the line. The variable’s value
replaces “$var”.
${var}Tthe name of a set variable. The
variable name is the text within the braces. The variable’s value replaces “${var}”.
$(var) The
name of a set variable. The variable name is the text within the parenthesis.
The variable’s value replaces “$(var)”.
Notes
1) Use of a variable that has not been set is considered to be a fatal error.
2) Variables may be used in any text line other than a set statement.
3) Substitution occurs only once. Substituted lines are never rescanned.
Example
set myHost = io.slac.stanford.edu
set myPath = /foo/fum/fi/
all.role
manager if $myHost
ofs.fslib $(myPath)libXrdOfs.so
set { -q | -v | -V }
Function
Specify the level of substitution detail.
Parameters
-q Enables quiet mode. Neither substitutions nor
substituted lines are displayed.
-v Enables
verbose mode. While
substitutions are not displayed; substituted lines are displayed. This is the
default.
-V Enables very verbose mode. Both
substitutions and substituted lines are displayed.
Defaults
set -v
Notes
1) Configuration files are processed by multiple components. Every time a component scans through a configuration file and “-v” is in effect, substituted lines used by that component are displayed.
2) When “-V” is in effect, every time a variable is given a value the assignment is displayed. This means that each component scanning through the configuration file will generate a display of all set statements.
Example
set -V
29 March 2007
·
Manual
introduced.
8 January 2008
· Deprecate the odc and olb components.
[1] Cluster Management Services replace Open Load Balancing (olb) and Open Distributed Cluster (odc) components in previous versions of Scalla. The odc and olb prefixes are still accepted by the cms component. You may either run cmsd or olbd but not a mixture of both.
[2] The odc component has been functionally replaced by the cms component and is considered deprecated.
[3] The olb component has been functionally replaced by the cms component and is considered deprecated.