Provided by: nordugrid-arc-hed_5.0.5-1ubuntu1_amd64 
NAME
arc.conf - ARC configuration
SYNOPSIS
/etc/arc.conf
${ARC_LOCATION}/etc/arc.conf
DESCRIPTION
ARC has two separate configuration files - one for client tools and another for services. This document
describes the services configuration file. For client configuration please see "ARC Clients User Manual"
at http://www.nordugrid.org/documents/arc-ui.pdf
ARC configuration uses a plain-text "ini-style" format. It is also possible to use an XML format, however
that is outside the scope of this document.
The configuration file consists of several configuration blocks. Each configuration block is identified
by a keyword and contains the configuration options for a specific part of the ARC middleware.
Each configuration block starts with its identifying keyword inside square brackets. Thereafter follows
one or more attribute value pairs written one on each line in the following format (note that the
attribute names are CASE-SENSITIVE):
[keyword1]
attribute1="value1"
attribute2="value2"
[keyword2]
attribute="value"
If the ARC_LOCATION environment variable is set the ARC configuration file located at
${ARC_LOCATION}/etc/arc.conf is read first. If this file is not present or the relevant configuration
information is not found in this file, the file at /etc/arc.conf is read.
The [common] block
The parameters set within this block are available for all the other blocks. These are the configuration
parameters shared by the different components of ARC (e.g. grid-manager, infosys)
hostname
hostname - the FQDN of the frontend node, optional in the common block but MUST be set in the
cluster block
Example:
hostname="myhost.org"
x509_voms_dir
x509_voms_dir path - the path to the directory containing *.lsc files needed for checking validity
of VOMS extensions. If not specified default value /etc/grid-security/vomsdir is used.
Example:
x509_voms_dir="/etc/grid-security/vomsdir"
lrms ARC supports various LRMS flavours, as listed in this section. For detailed description of options
please refer to ARC CE sysadmin guide:
http://www.nordugrid.org/documents/arc-ce-sysadm-guide.pdf
ONLY ONE LRMS IS ALLOWED. MULTIPLE lrms ENTRIES WILL TRIGGER UNEXPECTED BEHAVIOUR.
lrms sets the type of the Local Resource Management System (queue system), and optionally - the
default queue name, separated with a blank space: lrmstype queue_name. For lrmstype, the
following systems are supported and can be chosen (one per server):
fork - simple forking of jobs to the same node as the server
sge - (Sun/Oracle) Grid Engine
condor - Condor
pbs - PBS
lsf - LSF
ll - LoadLeveler
slurm - SLURM
dgbridge - Desktop Grid
PBS has many flavours, ARC currenly supports OpenPBS, PBSPro, ScalablePBS and Torque (the official
name for ScalablePBS). There is no need to specify the flavour or the version number of the PBS,
simply write 'pbs'. Similarly, there is no need to specify (Sun/Oracle) Grid Engine versions and
flavours. "lrmstype" MUST be set here, it is a MANDATORY parameter!
The optional queue parameter specifies the default Grid queue of the LRMS. Jobs will be submitted
to this queue if they do not specify queue name in job description. Queue name must match one of
the [queue/queue_name] block labels, see below.
Example:
lrms="pbs gridlong"
lrms="pbs"
PBS options
pbs_bin_path
the path to the qstat,pbsnodes,qmgr etc PBS binaries, no need to set if PBS is not used
Example:
pbs_bin_path="/usr/bin"
pbs_log_path
the path of the PBS server logfiles which are used by A-REX to determine whether a PBS job is
completed. If not specified, A-REX will use qstat for that.
Example:
pbs_log_path="/var/spool/pbs/server_logs"
Condor options
condor_rank
condor_rank - If you are not happy with the way Condor picks nodes when running jobs, you can
define your own ranking algorithm by optionally setting the condor_rank attribute. condor_rank
should be set to a ClassAd float expression that you could use in the Rank attribute in a Condor
job description. Obviously no need to set if Condor is not used. An example:
Example:
condor_rank="(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000"
condor_bin_path
condor_bin_path - Path to Condor binaries. Must be set if Condor is used.
Example:
condor_bin_path=/opt/condor/bin
condor_config
condor_config - Path to Condor config file. Must be set if Condor is used and the config file is
not in its default location (/etc/condor/condir_config or ~/condor/condor_config). The full path
to the file should be given.
Example:
condor_config=/opt/condor/etc/condor_config
SGE options
sge_bin_path
sge_bin_path - Path to Sun Grid Engine (SGE) binaries, MUST be set if SGE is the LRMS used
Example:
sge_bin_path="/opt/n1ge6/bin/lx24-x86"
sge_root
sge_root - Path to SGE installation directory. MUST be set if SGE is used.
Example:
sge_root="/opt/n1ge6"
sge_cell
sge_cell - The name of the SGE cell to use. This option is only necessary in case SGE is set up
with a cell name different from 'default'
Example:
sge_cell="default"
sge_qmaster_port
sge_qmaster_port, sge_execd_port - these options should be used in case SGE command line clients
require SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables to be set. Usually they are not
necessary.
Example:
sge_qmaster_port="536"
sge_execd_port="537"
SLURM options
slurm_bin_path
slurm_bin_path - Path to SLURM binaries, must be set if installed outside of normal $PATH
Example:
slurm_bin_path="/usr/bin"
slurm_wakeupperiod
How long should infosys wait before querying SLURM for new data (seconds)
Example:
slurm_wakeupperiod="15"
slurm_use_sacct
Should ARC use sacct instead of scontrol to get information on finished jobs. Requires that
accounting is turned on in SLURM. Default is "no".
Example:
slurm_use_sacct="yes"
LSF options
lsf_bin_path
the PATH to LSF bin folder no need to set if LSF is not used
Example:
lsf_bin_path="/usr/local/lsf/bin/"
lsf_profile_path
the PATH to profile.lsf no need to set if LSF is not used
Example:
lsf_profile_path="/usr/share/lsf/conf"
LL options
ll_bin_path
the PATH to the LoadLeveler bin folder no need to set if LoadLeveler is not used
Example:
ll_bin_path="/opt/ibmll/LoadL/full/bin"
ll_consumable_resources
support for a LoadLeveler setup using Consumable Resources no need to set if LoadLeveler is not
used
Example:
ll_consumable_resources="yes"
Desktop Grid options
dgbridge_stage_dir
Desktop Bridge www publish dir
Example:
dgbridge_stage_dir="/var/www/DGBridge"
dgbridge_stage_prepend
Desktop Bridge URL prefix pointing to dgbridge_stage_dir
Example:
dgbridge_stage_prepend="http://edgi-bridge.example.com/DGBridge/"
Boinc options
boinc_db_host boinc_db_port boinc_db_name boinc_db_user boinc_db_pass
Connection details for the Boinc database.
Example:
boinc_db_host="localhost"
boinc_db_port="3306"
boinc_db_name="myproject"
boinc_db_user="boinc"
boinc_db_pass="password"
Other [common] options
globus_tcp_port_range
globus_tcp_port_range, globus_udp_port_range - Firewall configuration In a firewalled environment
the software which uses GSI needs to know what ports are available. The full documentation can be
found at: http://dev.globus.org/wiki/FirewallHowTo These variable are similar to the Globus
environment variables: GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE. These variables are not
limited to [common], but can be set individually for each service in corresponding section: [grid-
manager], [gridftpd] Example:
Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"
x509_user_key
x509_user_cert, x509_user_key - Server credentials location. These variables are similar to the
GSI environment variables: X509_USER_KEY and X509_USER_CERT These variables are not limited to
[common], but can be set individually for each service in corresponding section: [grid-manager],
[gridftpd], [nordugridmap]
Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"
x509_cert_dir
x509_cert_dir - Location of trusted CA certificates This variable is similar to the GSI
environment variable: X509_CERT_DIR This variable is not limited to [common], but can be set
individually for each service in corresponding section: [grid-manager], [gridftpd]
Example:
x509_cert_dir="/etc/grid-security/certificates"
gridmap
gridmap - The gridmap file location This variable is similar to the GSI environment variable:
GRIDMAP This variable is not limited to [common], but can be set individually for each service in
corresponding section: [grid-manager], [gridftpd] The default is /etc/grid-security/grid-mapfile
Example:
gridmap="/etc/grid-security/grid-mapfile"
voms_processing
voms_processing - Defines how to behave if errors in VOMS AC processing detected.
relaxed - use everything that passed validation.
standard - same as relaxed but fail if parsing errors took place and VOMS extension is marked as
critical. This is the default.
strict - fail if any parsing error was discovered.
noerrors - fail if any parsing or validation error happened. This command can also be used in
[grid-manager] and [gridftpd] blocks.
Example:
voms_processing="standard"
voms_trust_chain
voms_trust_chain - Define the DN chain that the host services trust when the VOMS AC from peer
VOMS proxy certificate is parsed and validated. There can be multiple "voms_trust_chain"
existing, each one corresponds to a VOMS server. This variable is similar to the information in
*.lsc file, but with two differences:
1, You don't need to create a *.lsc file per VOMS server, but create a chain per VOMS server;
2, Regular expressions are supported when matching the DNs.
This variable is not limited to [common], but can be used in [grid-manager] and [gridftpd] blocks.
This variable should be used together with voms_processing. This variable will overwrite the
information in *.lsc if *.lsc exists.
Example:
voms_trust_chain = "/O=Grid/O=NorduGrid/CN=host/arthur.hep.lu.se" "/O=Grid/O=NorduGrid/CN=NorduGrid Certification Authority"
voms_trust_chain = "/O=Grid/O=NorduGrid/CN=host/emi-arc.eu" "/O=Grid/O=NorduGrid/CN=NorduGrid Certification Authority"
voms_trust_chain = "^/O=Grid/O=NorduGrid"
[vo] block
[vo] block is used to define VOs and generate mapfiles from user list maintained by VO databases. VO
block is a configuration block for the nordugridmap utility. Please note that [vo] block processing by
nordugridmap utility depend on parameters defined in the [nordugridmap] block.
[vo] block by itself does not affect authorization of client/user. For that label defined by vo=""
attribute may be used in [group] block with with 'file' rule.
id id blockid - specifies the unique configuration block id (this does not affect nordugridmap
utility)
Example:
id="vo_1"
vo vo vo_name - specifies the VO name, this name can be used in other blocks. MUST be given.
Example:
vo="nordugrid"
file file path - output gridmap-file where GENERATED mapping list will be stored. See parameters below
to define how to generate this file. If the same file specified as output for different [vo]
blocks, nordugridmap will automatically merge entries in given blocks order. Default is
'/etc/grid-security/gridmapfile'.
Example:
file="/etc/grid-security/VOs/atlas-users"
source source URL - the URL of the VO database which is assigned to this VO. The nordugridmap will use
this URL to automatically generate and keep up-to-date userlist (mapfile) specified by the 'file'
attribute. URL is a multivalued attribute, several sources can be specified for the [vo] block
and all the users from those sources will be merged into the same file. The source URLs are
processed in the given order. Currently supported URL types are:
http(s):// - URL to plain text file. File should contain a list
of DNs with optional issuer certificate authority DN
(see require_issuerdn): "user DN" ["issuer DN"]
voms(s):// - URL to VOMS-Admin interface
nordugrid - add NorduGrid VO members
ldap:// - expect LDAP-schema formatted VO Group
file:// - local file (stand-alone or dynamically generated by
nordugridmap). File should contain a list of DNs with
optional mapped unixid: "user DN" [mapped user ID]
Result of optional mapped unixid processing depend
on mapuser_processing option settings.
vo:// - reference to another [vo] configuration block
edg-mkgridmap://
- local configuration file used by edg-mkgridmap tool.
nordugridmap will parse configuration from file and
process it as additional [vo] block that will be referred
authomatically in place URL specified. This allow
easy migration from edg-mkgridmap solution without
rewriting your previous configuration (NOTE that rarely
used 'auth' directive and 'AUTO' mapping options are not
supported)
You can use either vo:// or file:// entries to specify dependencies between [vo] blocks, but using
vo:// is a recommended way. For each separate source URL it is possible to override some
parameters value. You can use the following syntax to perform this:
source="URL < parameter1=value1 parameter2=value2"
You can override the following parameters:
mapped_unixid for http(s),voms(s),ldap and file URLs
cache_enable for http(s),voms(s),ldap and file URLs
voms_method for voms(s) URLs
mapuser_processing for file URLs with mapped_unixid='<unixid>' overrides
(control mapped_unixid overriding behaviour for URL)
Example:
source="vomss://voms.ndgf.org:8443/voms/nordugrid.org"
source="vomss://lcg-voms.cern.ch:8443/voms/atlas?/atlas/Role=VO-Admin < mapped_unixid=atlasadmin"
source="vomss://kuiken.nikhef.nl:8443/voms/gin.ggf.org < voms_method=get"
source="http://www.nordugrid.org/developers.dn"
source="ldap://grid-vo.nikhef.nl/ou=lcg1,o=atlas,dc=eu-datagrid,dc=org"
source="file:///etc/grid-security/priviliged_users.dn"
source="vo://nordugrid_community"
source="nordugrid"
mapped_unixid
mapped_unixid unixid - the local UNIXID which is used in the generated grid-mapfile by the
nordugridmap utility.
If any of the sources have already provided mapping information (file:// or vo://) behaviour
depends on 'mapuser_processing' [nordugridmap] block configuration:
mapuser_processing = 'overwrite': ignore already provided mapping and
apply mapped_unixid for all sources
mapuser_processing = 'keep': apply mapped_unixid only for sources that
does not already has mapping information
[vo] block can only have one UNIXID. If 'mapped_unixid' is not specified behaviour depends on
'allow_empty_unixid' [nordugridmap] block configuration value:
allow_empty_unixid = 'yes': empty value will be used for mapped_unixid
which means that nordugridmap will generate only
the list of DNs without mapping (consider using
mapuser_processing='overwrite' along with this
option or sources that does not provide previously
defined mapping information)
allow_empty_unixid = 'no': skip users without mapping information (if
no mapping information provided by sources)
Example:
mapped_unixid="gridtest"
voms_fqan_map
voms_fqan_map fqan unixid - the local UNIXID which is used to map voms(s) sources with specific
FQAN given. Several voms_fqan_map can be specified for a [vo] block. For each voms(s) sources in
[vo] block and every voms_fqan_map record separate source record will be authomatically generated
with mapped_unixid overrided to specified one. Sources are generated in a given voms_fqan_map
order. Original voms(s) source URL are processed LAST. This allows to simplify configuration,
especially in redundancy cases when several VOMS servers are used for the same VO.
Example:
voms_fqan_map="/atlas/Role=VO-Admin atlasadmin"
voms_fqan_map="/atlas/Role=production atlasprod"
require_issuerdn
require_issuerdn yes/no - another nordugridmap option. YES would map only those DNs obtained from
the URLs which have the corresponding public CA packages installed. Default is 'no'. Note, that
some sources does not provide issuer information (like voms(s):// or file://). If this sources are
used within [vo] block and require_issuerdn is set to 'yes' behaviour depends on issuer_processing
[nordugridmap] block configuration:
issuer_processing = 'relaxed': check only those records that have issuer
information provided, allow other sources
issuer_processing = 'strict': if issuer information was not found record
is filtered and will not be passed into mapfile
Example:
require_issuerdn="no"
filter filter ACL string - An ACL filter for the nordugridmap utility. Multiple allow/deny statements
are possible. The fetched DNs are filtered against the specified rules before they are added to
the generated mapfile. * can be used as a wildcard. You may run the nordugridmap with the --test
command line option to see how the filters you specified work. If at least one allow filter is
specified implicit deny is used at the end of ACL. If only deny filters are present - implicit
allow used at the end.
Example:
filter="deny *infn*"
filter="allow *NorduGrid*"
[group] Authorisation block
These configuration blocks define rules used to define to which authorization group a user belongs. The
group should not be mistaken for a virtual organisation (VO). A group may match a single vo if only a
single check (rule) on vo membership is performed. It is however more common to allow multiple VOs in a
single group. ARC also allows many other ways to assign users to groups. Technically, permissions are
only granted to groups, not directly to VOs.
The block specifies single authorization group. There may be multiple [group] blocks in configuration
defining multiple authorization groups.
The block can be specified in two ways - either using [group/group1] like subblock declaration per group
or just [group]. The two formats are equivalent. Every block (till the beginning of next block or the end
of the file) defines one authorization group.
IMPORTANT: Rules in a group are processed in their order of appearance. The first matching rule decides
the membership of a the user to a group and the processing STOPS. There are positively and negatively
matching rules. If a rule is matched positively then the user tested is accepted into the respective
group and further processing is stopped. Upon a negative match the user would be rejected for that group
- processing stops too. The sign of rule is determined by prepending the rule with be omitted. A rule may
also be prepended with '!' to invert result of rule, which will let the rule match the complement of
users. That complement operator ('!') may be combined with the operator for positive or negative
matching.
A group MUST be defined before it may be used. In this respect the arc.conf is ORDER SENSITIVE.
The authorization groups can be used in [gridftpd] and in its sub-blocks. The syntax of their
specification varies with the service they are used for. For using authorization groups and VO blocks in
HED framework please read "Security Framework of ARC" at http://www.nordugrid.org/documents/arc-security-
documentation.pdf
name name group_name - Specify name of group. If there is no such command in block, name of subblock is
used instead (that is what subblocks are used for). For example [group/users].
Example:
name="users"
subject
subject certificate_subject - Rule to match specific subject of user's X.509 certificate. No
masks, patterns and regular expressions are allowed. For more information about X.509 refer to
http://www.wikipedia.org/wiki/X509
Example:
subject="/O=Grid/O=Big VO/CN=Main Boss"
file file path - Start reading rules from another file. That file has a bit different format. It can't
contain blocks and commands are separated from arguments by space. Also word "subject" in subject
command may be skipped. That makes it convenient to directly add gridmap-like lists to
authorization group.
Example:
file="/etc/grid-security/local_users"
voms voms vo group role capabilities - Match VOMS attribute in user's credential. Use '*' to match any
value. More information about VOMS can be found at http://grid-auth.infn.it
Example:
voms="nordugrid Guests * *"
group group group_name [group_name ...] - Match user already belonging to one of specified groups.
Groups refered here must be defined earlier in configuration file. Multiple group names may be
specified for this rule. That allows creating hierarchical structure of authorization groups like
Example:
group="local_admins"
plugin plugin timeout path [argument ...] - Run external executable or function from shared library. Rule
is matched if plugin returns 0. In arguments following substitutions are supported:
%D - subject of certificate
%P - path to proxy
For more about plugins read documentation.
Example:
plugin="10 /opt/external/bin/permis %P"
lcas lcas library directory database - Call LCAS functions to check rule. Here library is path to
shared library of LCAS, either absolute or relative to directory; directory is path to LCAS
installation directory, equivalent of LCAS_DIR variable; database is path to LCAS database,
equivalent to LCAS_DB_FILE variable. Each arguments except library is optional and may be either
skipped or replaced with ’*’.
Example:
lcas=""
remote remote URL ... - Check user's credentials against remote service. Only DN groups stored at LDAP
directories are supported. Multiple URLs are allowed in this rule.
Example:
remote="ldap://grid-vo.nordugrid.org/ou=People,dc=nordugrid,dc=org"
vo vo vo_name ... - Match user belonging to VO specified by "vo=vo_name" as configured in one of
PREVIOUSLY defined [vo] blocks. Multiple VO names are allowed for this rule.
Example:
vo="nordugrid"
all all - Matches any user identity. This command requires no arguments but
still can be written as all="" or all= for consistency.
Example:
all=""
The [grid-manager] block
The [grid-manager] block configures the part of A-REX service hosted in arched taking care of the grid
tasks on the frontend (stagein/stageout, LRMS job submission, caching, etc..). Name of this block is
historical and comes from times then this functionality was handled by separate process called grid-
manager. This section also configures WS interfaces of A-REX service also hosted by same container.
controldir
controldir path - The directory of the A-REX's internal job log files, not needed on the nodes.
<must be set>
Example:
controldir="/var/spool/nordugrid/jobstatus"
sessiondir
sessiondir path [drain] - the directory which holds the sessiondirs of the grid jobs. Multiple
session directories may be specified by specifying multiple sessiondir commands. In this case jobs
are spread evenly over the session directories. If sessiondir="*" is set, the session directory
will be spread over the ${HOME}/.jobs directories of every locally mapped unix user. It is
preferred to use common session directories. The path may be followed by "drain", in which case no
new jobs will be assigned to that sessiondir, but current jobs will still be processed and
accessible. <sessiondir must be set>
Example:
sessiondir="/scratch/grid"
sessiondir="/mnt/grid drain"
runtimedir
runtimedir path - The directory which holds the runtimeenvironment scripts, should be available on
the nodes as well! The runtimeenvironments are automatically detected and advertised in the
information system.
Example:
runtimedir="/SOFTWARE/runtime"
scratchdir
scratchdir path - path on computing node to move session directory to before execution. If defined
should contain the path to the directory on the computing node which can be used to store a jobs'
files during execution. Sets the environment variable RUNTIME_LOCAL_SCRATCH_DIR. Default is not
to move session directory before execution.
Example:
scratchdir="/local/scratch/"
shared_scratch
shared_scratch path - path on frontend where scratchdir can be found. If defined should contain
the path corresponding to that set in scratchdir as seen on the frontend machine. Sets the
environment variable RUNTIME_FRONTEND_SEES_NODE.
Example:
shared_scratch="/mnt/scratch"
nodename
nodename path - command to obtain hostname of computing node.
Example:
nodename="/bin/hostname"
cachedir
cachedir cache_path [link_path] - specifies a directory to store cached data. Multiple cache
directories may be specified by specifying multiple cachedir commands. Cached data will be
distributed evenly over the caches. Specifying no cachedir command or commands with an empty path
disables caching. Optional link_path specifies the path at which the cache_path is accessible on
computing nodes, if it is different from the path on the A-REX host. Example:
cache="/shared/cache /frontend/jobcache" If "link-path" is set to '.' files are not soft-linked,
but copied to session directory. If a cache directory needs to be drained, then cachedir should
specify "drain" as the link path, in which case no new files will be added to the cache.
Example:
cachedir="/scratch/cache"
cachedir="/fs1/cache drain"
remotecachedir
remotecachedir cache_path [link_path] - specifies caches which are under the control of other A-
REXs, but which this A-REX can have read-only access to. Multiple remote cache directories may be
specified by specifying multiple remotecachedir commands. If a file is not available in paths
specified by cachedir, A-REX looks in remote caches. link_path has the same meaning as in
cachedir, but the special path ``replicate'' means files will be replicated from remote caches to
local caches when they are requested.
Example:
remotecachedir="/mnt/fs1/cache replicate"
cachesize
cachesize max min - specifies high and low watermarks for space used by cache, as a percentage of
the space on the file system on which the cache directory is located. When the max is exceeded,
files will be deleted to bring the used space down to the min level. It is a good idea to have the
cache on its own separate file system. To turn off this feature "cachesize" without parameters can
be specified.
Example:
cachesize="80 70"
cachelifetime
If cache cleaning is enabled, files accessed less recently than the given time period will be
deleted. Example values of this option are 1800, 90s, 24h, 30d. When no suffix is given the unit
is seconds.
Example:
cachelifetime="30d"
cacheshared
cacheshared yes|no - specifies whether the caches share a filesystem with other data. If set to
yes then cache-clean calculates the size of the cache instead of using filesystem used space.
Example:
cacheshared="yes"
cachespacetool
cachespacetool path [options] - specifies an alternative tool to "df" that cache-clean should use
to obtain space information on the cache file system. The output of this command must be
"total_bytes used_bytes". The cache directory is passed as the last argument to this command.
Example:
cachespacetool="/etc/getspace.sh"
cachelogfile
cachelogfile path - specifies the filename where output of the cache-clean tool should be logged.
Defaults to /var/log/arc/cache-clean.log.
Example:
cachelogfile="/tmp/cache-clean.log"
cacheloglevel
cacheloglevel level - specifies the level of logging by the cache-clean tool, between 0 (FATAL)
and 5 (DEBUG). Defaults to 3 (INFO).
Example:
cacheloglevel="4"
cachecleantimeout
cachecleantimeout time - the timeout in seconds for running the cache-clean tool. If using a large
cache or slow file system this value can be increased to allow the cleaning to complete. Defaults
to 3600 (1 hour).
Example:
cachecleantimeout="10000"
cacheaccess
cacheaccess rule - rules for allowing access to files in the cache remotely through the A-REX web
interface. A rule has three parts:
1. Regular expression defining a URL pattern
2. Credential attribute to match against a client's credential
3. Credential value to match against a client's credential A client is allowed to access the
cached file if a URL pattern matches the cached file URL and the client's credential has the
attribute and value required for that pattern. Possible values for credential attribute are dn,
voms:vo, voms:role and voms:group. Remote cache access requires that the A-REX web interface is
enabled via arex_mount_point.
Examples:
cacheaccess="gsiftp://host.org/private/data/.* voms:vo myvo:production"
cacheaccess="gsiftp://host.org/private/data/bob/.* dn /O=Grid/CN=Bob"
enable_cache_service
enable_cache_service yes|no - Turn on or off the cache service interface. If turned on the cache
service must be installed and the A-REX WS interface must be enabled via arex_mount_point. The
interface is accessible at the same host and port as given inn arex_mount_point with path
/cacheservice. Default is off.
Example:
enable_cache_service="yes"
user user user[:group] - Switch to a non root user/group after startup. Use with caution.
Example:
user="grid"
debug debug debuglevel - Set debug level of the arched daemon hosting A-REX service, between 0 (FATAL)
and 5 (DEBUG). Defaults to 3 (INFO).
Example:
debug="2"
logfile
logfile path - Specify log file location. If using an external log rotation tool be careful to
make sure it matches the path specified here. Default log file is "/var/log/arc/grid-manager.log"
Example:
logfile="/var/log/arc/grid-manager.log"
wslogfile
wslogfile path - Specify log file location for WS-interface operations. This file is only created
if the WS-interface is enabled through the arex_mount_point option. The logsize, logreopen and
debug options also apply to this file. If using an external log rotation tool be careful to make
sure it matches the path specified here. It is possible to specify the same file as logfile to
combine the logs. Default is /var/log/arc/ws-interface.log.
Example:
wslogfile="/var/log/arc/ws-interface.log"
logsize
logsize size [number] - 'Size' specifies in bytes how big log file is allowed to grow
(approximately). If log file exceeds specified size it is renamed into logfile.0. And logfile.0 is
renamed into logfile.1, etc. up to 'number' logfiles. Don't set logsize if you don't want to
enable the ARC logrotation because another logrotation tool is used.
Example:
logsize="100000 2"
logreopen
logreopen yes|no - Specifies if log file must be closed after each record is added. By default
arched keeps log file open. This option can be used to make behaviour of arched compatible with
external log rotation utilities.
Example:
logreopen="no"
pidfile
pidfile path - Specify location of file containing PID of daemon process. This is useful for
automatic start/stop scripts.
Example:
pidfile="/var/run/arched-arex.pid"
gnu_time
the gnu time command, default /usr/bin/time
Example:
gnu_time="/usr/bin/time"
shared_filesystem
if computing node can access session directory at frontend, defaults to 'yes'
Example:
shared_filesystem="yes"
mail specifies the email address from where the notification mails are sent, <must be specified>
Example:
mail="grid.support@somewhere.org"
joblog joblog path - specifies where to store specialized log about started and finished jobs. If path is
empty or no such command - log is not written. This log is not used by any other part of ARC, so
keep it disabled unless needed.
Example:
joblog="/var/log/arc/gm-jobs.log"
jobreport
jobreport [URL ...] [timeout] - tells to report all started and finished jobs to logger service at
'URL'. Multiple URLs and multiple jobreport commands are allowed. In that case the job info will
be sent to all of them. Timeout specifies how long (in days) to try to pass information before
give up. Suggested value is 30 days.
Example:
jobreport="https://grid.uio.no:8001/logger"
jobreport_publisher
jobreport publisher - name of the accounting records publisher.
Example:
jobreport_publisher="jura"
jobreport_credentials
jobreport credentials path [key_file [cert_file [ca_dir]]] - specifies the credentials for
accessing the accounting service.
Example:
jobreport_credentials="/etc/grid-security/hostkey.pem /etc/grid-security/hostcert.pem /etc/grid-
security/certificates"
jobreport_options
jobreport options [name:value, ...]- specifies additional parameters for the jobreporter.
Example:
jobreport_options="urbatch:50,archiving:/tmp/archive,topic:/topic/global.accounting.cpu.central"
jobreport_logfile
jobreport logfile - name of the file to store stderr of the publisher executable.
Example:
jobreport_logfile="/var/log/arc/jura.log"
max_job_control_requests
max_job_control_requests number - max number of simultaneously processed job management requests
over WS interface - like job submission, cancel, status check etc. Default value is 100.
Example:
max_job_control_requests="100"
max_infosys_requests
max_infosys_requests number - max number of simultaneously processed resource info requests over
WS interface. Default value is 1.
Example:
max_infosys_requests="1"
max_data_transfer_requests
max_data_transfer_requests number - max number of simultaneously processed data transfer requests
over WS interface - like data staging. Default value is 100.
Example:
max_data_transfer_requests="100"
maxjobs
maxjobs number1 number2 number3 number4 - specifies maximum allowed number of jobs.
number1 - jobs which are not in FINISHED state (jobs tracked in RAM)
number2 - jobs being run (SUBMITTING, INLRMS states)
number3 - jobs being processed per DN
number4 - jobs in whole system
Missing number or -1 means no limit.
Example:
maxjobs="10000 10 2000"
wakeupperiod
wakeupperiod time - specifies how often A-REX cheks for new jobs arrived, job state change
requests, etc. That is resposivity of A-REX. 'time' is time period in seconds. Default is 3
minutes. Usually this command is not needed because important state changes are also trigering
out-of-schedule checks.
NOTE: This parameter does not affect responsivity of backend scripts - especially scan-*-job. That
means that upper estimation of time for detecting job finished executing is sum of responsivity of
backend script + wakeupperiod.
Example:
wakeupperiod="180"
defaultttl
defaultttl [ttl [ttr]] - ttl is the time in seconds for how long a session directory will survive
after job execution has finished. If not specified the default is 1 week. ttr is how long
information about a job will be kept after the session directory is deleted. If not specified, the
ttr default is one month.
Example:
defaultttl="259200"
authplugin
authplugin state options plugin_path - Every time job goes to 'state' run 'plugin_path'
executable. Options consist of key=value pairs separated by ','.
Possible keys are
timeout - wait for result no longer that 'value' seconds (timeout= can be omitted).
onsuccess,onfailure,ontimeout - what to do if plugin exited with exit code 0, not 0, timeout
achieved.
Possible actions are:
pass - continue executing job,
fail - cancel job,
log - write to log fail about problem and continue executing job.
Example:
authplugin="ACCEPTED timeout=10 /usr/libexec/arc/bank %C/job.%I.local %S"
authplugin
ARC is distributed with the plugin "inputcheck". Its purpose is to check if input files requested
in job's RSL are accessible from this machine. It is better to run it before job enters cluster.
It accepts 2 arguments: names of files containing RSL and credentials' proxy. This plugin is only
guaranteed to work for job submitted through the legacy GridFTP interface, as this is the only
interface for which credentials in the form of proxy certificate files are guaranteed to exist.
Example:
authplugin="ACCEPTED 60 /usr/libexec/arc/inputcheck %C/job.%I.description %C/job.%I.proxy"
authplugin
ARC is distributed with the plugin "arc-vomsac-check". Its purpose is to enforce per-queue access
policies based on VOMS attributes present in user's proxy-certificate. Plugin should be run before
job enters the cluster. It requires 2 argments: path to job information .local file and path to
credentials file. Enforced per-queue access policies are configured with 'ac_policy' option in
the [queue/name] configuration block.
Example:
authplugin="ACCEPTED 60 /usr/libexec/arc/arc-vomsac-check -L %C/job.%I.local -P %C/job.%I.proxy"
localcred
localcred timeout plugin_path - Every time an external executable is run this plugin will be
called. Its purpose is to set non-unix permissions/credentials on running tasks. Note: the process
itself can still be run under the root account. If plugin_path looks like somename@somepath, then
function 'somename' from the shared library located at 'somepath' will be called (timeout is not
effective in that case). A-REX must be run as root to use this option. Comment it out unless you
really know what you are doing.
Example:
localcred="0 acquire@/opt/nordugrid/lib/afs.so %C/job.%I.proxy"
norootpower
norootpower yes|no - if set to yes, all job management proccesses will switch to mapped user's
identity while accessing session directory. This is useful if session directory is on NFS root
squashing turned on. Default is no.
Example:
norootpower="yes"
allowsubmit
allowsubmit [group ...] - list of authorization groups of users allowed to submit new jobs while
"allownew=no" is active in jobplugin configuration. Multiple commands are allowed.
Example:
allowsubmit="mygroup"
allowsubmit="yourgroup"
helper helper user executable arguments - associates an external program with A-REX. This program will be
kept running under the account of the user specified by username. Currently only ’.’ is supported
as username, corresponding to the user running A-REX. Every time this executable finishes it will
be started again. This helper plugin mechanism can be used as an alternative to /etc/init.d or
cron to (re)start external processes.
Example:
helper=". /usr/local/bin/myutility"
tmpdir tmpdir - used by the A-REX, default is /tmp
Example:
tmpdir="/tmp"
maxrerun
maxrerun - specifies how many times job can be rerun if it failed in LRMS. Default value is 5.
This is only an upper limit, the actual rerun value is set by the user in his xrsl.
Example:
maxrerun="5"
globus_tcp_port_range
globus_tcp_port_range, globus_udp_port_range - Firewall configuration.
Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"
x509_user_key
x509_user_cert, x509_user_key - Location of credentials for service. These may be used by any
module or external utility which need to contact another service not on behalf of user who
submited job.
Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"
x509_cert_dir
x509_cert_dir - Location of trusted CA certificates
Example:
x509_cert_dir="/etc/grid-security/certificates"
http_proxy
http_proxy - http proxy server location
Example:
http_proxy="proxy.mydomain.org:3128"
fixdirectories
fixdirectories yes|missing|no - specifies during startup A-REX should create all directories
needed for it operation and set suitable default permissions. If "no" is specified then A-REX does
nothing to prepare its operational environment. In case of "missing" A-REX only creates and sets
permissions for directories which are not present yet. For "yes" all directories are created and
permisisons for all used directories are set to default safe values. Default behaviour is as if
"yes" is specified.
Example:
fixdirectories="yes"
arex_mount_point
arex_mount_point - enables web services interfaces, including job execution and information
system. The argument is an https URL defining the endpoint port and path:
https://<hostname>:<port>/<path>
In order to submit job a client must specify the exact published path. Make sure the chosen port
is not blocked by firewall or other security rules.
Example:
arex_mount_point="https://piff.hep.lu.se:443/arex"
enable_arc_interface
enable_arc_interface yes|no - turns on or off the ARC own WS interface based on OGSA BES and WSRF.
If enabled the interface can be accessed at the URL specified by arex_mount_point (this option
must also be specified). Default is yes.
Example:
enable_arc_interface="yes"
enable_emies_interface
enable_emies_interface - enable the EMI Execution Service interface. If enabled the interface can
be accessed at the URL specified in arex_mount_point (this option must also be specified)
Example:
enable_emies_interface="yes"
arguspep_endpoint
arguspep_endpoint - specifies URL of Argus PEPD service (by default, the argus pepd service runs
on port 8154 with path /authz) to use for authorization and user mapping. It is worth to mention
that "requireClientCertAuthentication" (default is false) item of pepd.ini (configuration of Argus
PEPD service) is set to be 'true', then https should be used, otherwise http is proper. If
specified Argus is contacted for every operation requested through WS interface (see
arex_mount_point).
Example:
arguspep_endpoint="https://somehost.somedomain:8154/authz"
arguspep_profile
arguspep_profile - defines which communication profile to use while communicationg with Argus PEPD
service. Possible values are:
direct - pass all authorization attributes (only for debugging)
subject - pass only subject name of client
cream - makes A-REX pretend it is gLite CREAM service. This is
recommended profile for interoperability with gLite.
emi - new profile devloped in EMI project. This is default option.
Example:
arguspep_profile="cream"
arguspep_usermap
arguspep_usermap - specifies either response from Argus servie may define mapping of client to
local account. Possible values are 'yes' and 'no'. Default is 'no'. Argus is contacted after all
other user mapping is performed. Hence it can overwrite all other decisions.
Example:
arguspep_usermap="no"
arguspdp_endpoint
arguspdp_endpoint - specifies URL of Argus PDP service (by default, the argus pepd service runs on
port 8152 with path /authz) to use for authorization and user mapping. It is worth to mention
that "requireClientCertAuthentication" (default is false) item of pdp.ini (configuration of Argus
PDP service) is set to be 'true', then https should be used, otherwise http is proper. If
specified Argus is contacted for every operation requested through WS interface (see
arex_mount_point).
Example:
arguspdp_endpoint="https://somehost.somedomain:8152/authz"
arguspdp_profile
arguspdp_profile - defines which communication profile to use while communicationg with Argus PDP
service. Possible values are:
subject - pass only subject name of client
cream - makes A-REX pretend it is gLite CREAM service. This is
recommended profile for interoperability with gLite.
emi - new profile devloped in EMI project. This is default option.
Example:
arguspdp_profile="cream"
arguspdp_acceptnotapplicable
arguspdp_accpetnotapplicable - specify if the "NotApplicable" decision returned by Argus PDP
service is treated as reason to deny request. Default is no, which treats "NotApplicable" as reson
to deny request.
Example:
arguspdp_acceptnotapplicable="no"
watchdog
watchdog - specifies if additinal watchdog processes is spawned to restart main process if it is
stuck or dies. Possible values are 'yes' and 'no'. Default is 'no'.
Example:
watchdog="no"
[data-staging] block
[data-staging] block configures DTR data staging parameters.
debug debug - Log level for transfer logging in job.id.errors files, between 0 (FATAL) and 5 (DEBUG).
Default is to use value set by debug option in [grid-manager] section.
Example:
debug="4"
maxdelivery
maxdelivery - Maximum number of concurrent file transfers, i.e. active transfers using network
bandwidth. This is the total number for the whole system including any remote staging hosts.
Default is 10.
Example:
maxdelivery="40"
maxprocessor
maxprocessor - Maximum number of concurrent files in each pre- and post- processing state, eg
cache check or replica resolution. Default is 10.
Example:
maxprocessor="20"
maxemergency
maxemergency - Maximum "emergency" slots which can be assigned to transfer shares when all slots
up to the limits configured by the above two options are used by other shares. This ensures shares
cannot be blocked by others. Default is 1.
Example:
maxemergency="5"
maxprepared
maxprepared - Maximum number of files in a prepared state, i.e. pinned on a remote storage such as
SRM for transfer. A good value is a small multiple of maxdelivery. Default is 200.
Example:
maxprepared="250"
sharetype
sharetype - Scheme to assign transfer shares. Possible values are dn, voms:vo, voms:role and
voms:group.
Example:
sharetype="voms:role"
definedshare
definedshare - Defines a share with a fixed priority, different from the default (50). Priority is
an integer between 1 (lowest) and 100 (highest).
Example:
definedshare="myvo:production 80"
definedshare="myvo:student 20"
dtrlog dtrlog - A file in which data staging state information (for monitoring and recovery purposes) is
periodically dumped. Default is controldir/dtrstate.log
Example:
dtrlog="/tmp/dtrstate.log"
deliveryservice
The following 4 options are used to configure multi-host data staging. deliveryservice - URL to a
data delivery service which can perform remote data staging
Example:
deliveryservice="https://myhost.org:60003/datadeliveryservice"
localdelivery
localdelivery - If any deliveryservice is defined, this option determines whether local data
transfer is also performed. Default is no.
Example:
localdelivery="yes"
remotesizelimit
remotesizelimit - Lower limit on file size (in bytes) of files that remote hosts should transfer.
Can be used to increase performance by transferring small files using local processes.
Example:
remotesizelimit="100000"
usehostcert
usehostcert - Whether the A-REX host certificate should be used for communication with remote
hosts instead of the users' proxies. Default is no.
Example:
usehostcert="yes"
acix_endpoint
acix_endpoint URL - the ARC Cache Index specified here will be queried for every input file
specified in a job description and any replicas found in sites with accessible caches will be
added to the replica list of the input file. The replicas will be tried in the order specified by
preferredpattern.
Example:
acix_endpoint="https://cacheindex.ndgf.org:6443/data/index"
securetransfer
securetransfer yes|no - if data connection allows to choose use secure|non-secure data transfer.
Currently only works for gridftp. default is no
Example:
securetransfer="no"
passivetransfer
passivetransfer yes|no - If yes, gridftp transfers are passive. Setting this option to yes can
solve transfer problems caused by firewalls. default is no
Example:
passivetransfer="no"
localtransfer
localtransfer yes|no - If yes, then the data download from to Grid to the session directory
(stagein) will be part of the batch job (prior to the execution of the binary). Default is no.
Example:
localtransfer="no"
B httpgetpartial
httpgetpartial yes|no - If yes, HTTP GET transfers may transfer data in chunks/parts. If no - data
is always transfered in one piece. Default is yes.
Example:
httpgetpartial="yes"
speedcontrol
speedcontrol min_speed min_time min_average_speed max_inactivity - specifies how slow data
transfer must be to trigger error. Tranfer is canceled if speed is below min_speed bytes per
second for at least min_time seconds, or if average rate is below min_average_speed bytes per
second, or no data was transfered for longer than max_inactivity seconds. Value of zero turns
feature off. Default is "0 300 0 300"
Example:
speedcontrol="0 300 0 300"
preferredpattern
preferredpattern pattern - specifies a preferred pattern on which to sort multiple replicas of an
input file. It consists of one or more patterns separated by a pipe character (|) listed in order
of preference. Replicas will be ordered by the earliest match. If the dollar character ($) is used
at the end of a pattern, the pattern will be matched to the end of the hostname of the replica.
Example:
preferredpattern="srm://myhost.ac.uk|.uk$|ndgf.org$"
copyurl
copyurl url_head local_path - specifies that URLs, starting from 'url_head' should be accessed in
a different way (most probaly unix open). The file from obtained path will be copied to the
session directory. NOTE: 'local_path' can also be of URL type. you can have several copyurl
lines
Example:
copyurl="gsiftp://example.org:2811/data/ gsiftp://example.org/data/"
copyurl="gsiftp://example2.org:2811/data/ gsiftp://example2.org/data/"
linkurl
linkurl url_head local_path [node_path] - identical to 'copyurl', only file won't be copied, but
soft-link will be created. The 'local_path' specifies the way to access the file from the
gatekeeper, and is used to check permissions. The 'node_path' specifies how the file can be
accessed from computing nodes, and will be used for soft-link creation. If 'node_path' is missing
- 'local_path' will be used. you can have multiple linkurl settings
Example:
linkurl="gsiftp://somewhere.org/data /data"
linkurl="gsiftp://example.org:2811/data/ /scratch/data/"
maxtransfertries
maxtransfertries - the maximum number of times download and upload will be attempted per job
(retries are only performed if an error is judged to be temporary)
Example:
maxtransfertries="10"
[gridftpd] block
The [gridftpd] block configures the gridftpd server
user user user[:group] - Switch to a non root user/group after startup
WARNING: Make sure that the certificate files are owned by the user/group specified by this
option. Default value is root.
Example:
user="grid"
debug debug debuglevel - Set debug level of the gridftpd daemon, between 0 (FATAL) and 5 (DEBUG).
Default is 3 (INFO).
Example:
debug="2"
daemon daemon yes|no - Whether GFS is run in daemon mode. Default is yes.
Example:
daemon="yes"
logfile
logfile path - Set logfile location
Example:
logfile="/var/log/arc/gridftpd.log"
logsize
logsize size [number] - 'Size' specifies in bytes how big log file is allowed to grow
(approximately). If log file exceeds specified size it is renamed into logfile.0. And logfile.0 is
renamed into logfile.1, etc. up to 'number' logfiles. Don't set logsize if you don't want to
enable the ARC logrotation because another logrotation tool is used.
Example:
logsize="100000 2"
pidfile
pidfile path - Specify location of file containig PID of daemon process. This is useful for
automatic star/stop scripts.
Example:
pidfile="/var/run/gridftpd.pid"
port port bindport - Port to listen on (default 2811)
Example:
port="2811"
pluginpath
pluginpath - directory where the plugin libraries are installed, default is
$ARC_LOCATION/lib(64)/arc
Example:
pluginpath="/usr/lib/arc/"
encryption
encryption yes|no - should data encryption be allowed, default is no, encryption is very heavy
Example:
encryption="no"
include
include - Include contents of another configuration file.
Example:
include="path"
allowunknown
allowunknown yes|no - if no, check user subject against grid-mapfile and reject if missing. By
default unknown (not in the grid-mapfile) grid users are rejected
Example:
allowunknown="no"
maxconnections
maxconnections - maximum number of connections accepted by a gridftpd server. Default is 100.
Example:
maxconnections="200"
defaultbuffer
defaultbuffer size - defines size of every buffer for data reading/writing. Default is 65536.
The actual value may decrease if the cumulative size of all buffers exceeds value specified by
maxbuffer.
Example:
defaultbuffer="65536"
maxbuffer
maxbuffer size - defines maximal amount of memory in bytes to be allocated for all data
reading/writing buffers. Default is 640kB. The number of buffers is (max {3, min {41, 2P + 1}}),
where P is the parallelism level requested by the client. Hence, even without parallel streams
enabled number of buffers will be 3.
Example:
maxbuffer="655360"
globus_tcp_port_range
globus_tcp_port_range, globus_udp_port_range - Firewall configuration
Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"
firewall
firewall - hostname or IP addres to use in response to PASV command instead of IP address of a
network interface of computer.
Example:
firewall="hostname"
x509_user_key
x509_user_cert, x509_user_key - Server credentials location
Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"
x509_cert_dir
x509_cert_dir - Location of trusted CA certificates
Example:
x509_cert_dir="/etc/grid-security/certificates"
gridmap
gridmap - The gridmap file location The default is /etc/grid-security/grid-mapfile
Example:
gridmap="/etc/grid-security/grid-mapfile"
unixmap
unixmap [unixname][:unixgroup] rule - more sophisticated way to map Grid identity of client to
local account. If client matches 'rule' it's assigned specified unix identity or one generated by
rule. Mapping commands are processed sequentially and processing stops at first successful one
(like in [group] section). For possible rules read "ARC Computing Element. System Administrator
guide" manual. All rules defined in [group] section canbe used. There are also additional rules
which produce not only yes/no result but also give back user and group names to which mapping
should happen. The way it works is quite complex so it is better to read full documentation.
For safety reasons if sophisticated mapping is used it is better to finish mapping sequence with
default mapping to nonexistent or safe account.
Example:
unixmap="nobody:nogroup all"
unixgroup
unixgroup group rule - do mapping only for users belonging to specified authorization 'group'. It
is similar to an additional filter for unixmap command which filters out all users not belonging
to specified authorization group. Only rules which generate unix user and group names may be used
in this command. Please read "ARC Computing Element System Administrator Guide" for more
information.
Example:
unixgroup="users simplepool /etc/grid-security/pool/users"
unixvo unixvo vo rule - do mapping only for users belonging to specified VO. Only rules which generate
unix identity name may be used in this command. Please read "ARC Computing Element. System
Administrator Guide" for more information. This command is similar to 'unixgroup' described above
and exists for convenience for setups which base mapping on VOs users belong to.
Example:
unixvo="ATLAS unixuser atlas:atlas"
[gridftpd/filedir] block
[gridftpd/filedir] "fileplugin" storage block subblock for "exporting" a directory using the gridftpd's
fileplugin plugin. gridftp plugins are shared libraries. "filedir" is a unique label. The access
control is set by using the "dir" configuration option
plugin plugin name - specifies name of shared library to be loaded relative to "pluginpath". The next
line is MUST for a gridftp file server with "fileplugin", don't change anything
Example:
plugin="fileplugin.so"
groupcfg
groupcfg group_name [group_name ...] - specifies authorization groups for which this plugin is
activated. In case groupcfg is not used the plugin is loaded for every mapped grid user. Multiple
names were may be specified delimited by blank space. Group names are as specified in [group]
sections.
Example:
groupcfg="users"
path the name of the virtual directory served by the gridftp server, REQUIRED the exported storage area
is accessible as gsiftp://my_server/topdir. "topdir" is just an example, call the virtual path
anything you like, even "/" is a valid choice.
Example:
path="/topdir"
mount the physical directory corresponding to the virtual one: gsiftp://my_server/topdir will give
access to the /scratch/grid directory on my_server, REQUIRED
Example:
mount="/scratch/grid"
dir dir - this is the access control parameter, you can have several "dir" lines controlling different
directories within then same block
dir path options - specifies access rules for accessing files in 'path' (relative to virtual and
real path) and all the files and directories below.
'options' are:
nouser - do not use local file system rights, only use those
specifies in this line
owner - check only file owner access rights
group - check only group access rights
other - check only "others" access rights
if none of the above specified usual unix access rights are applied.
read - allow reading files
delete - allow deleting files
append - allow appending files (does not allow creation)
overwrite - allow overwriting already existing files (does not
allow creation, file attributes are not changed)
dirlist - allow obtaining list of the files
cd - allow to make this directory current
create owner:group permissions_or:permissions_and - allow creating
new files. File will be owned by 'owner' and owning group
will be 'group'. If '*' is used, the user/group to which
connected user is mapped will be used. The permissions
will be set to permissions_or & permissions_and. (second
number is reserved for the future usage).
mkdir owner:group permissions_or:permissions_and - allow creating new directories.
Example:
Set permissions on mounted directory:
dir="/ nouser read cd dirlist delete create *:* 664:664 mkdir *:* 775:775"
Example:
Adjust permissions on some subdirectories:
dir="/section1 nouser read mkdir *:* 700:700 cd dirlist"
dir="/section2 nouser read mkdir *:* 700:700 cd dirlist"
[gridftpd/jobs] subblock
[gridftpd/jobs] subblock which creates the jobsubmission interface, using the jobplugin of the gridftpd
service. gridftp plugins are shared libraries. 'jobs' is a unique label.
path the path to the virtual gridftpd directory which is used during the job submission. MUST be set.
Example:
path="/jobs"
plugin plugin name - specifies name of shared library to be loaded relative to "pluginpath". The next
line is MUST for a job submission service via gridftpd "jobplugin", don't change anything!
Example:
plugin="jobplugin.so"
groupcfg
groupcfg group_name [group_name ...] - specifies authorization groups for which this plugin is
activated. In case groupcfg is not used the plugin is loaded for every mapped grid user.
Example:
groupcfg="users"
allownew
The 'allownew' configuration parameter sets if the grid resource accepts submission of new jobs.
This parameter can be used to close down a grid. The default is yes
Example:
allownew="yes"
remotegmdirs
remotegmdirs controldir sessiondir - Specifies control and session directories to which jobs can
be submitted but which are under the control of another A-REX. The corresponding controldir and
sessiondir parameters must be defined in another A-REX's configuration. Multiple remotegmdirs can
be specified.
Example:
remotegmdirs="/mnt/host1/control /mnt/host1/session"
maxjobdesc
maxjobdesc size - specifies maximal allowed size of job description in bytes. Default value is
5MB. If value is missing or 0 size is not limited.
Example:
maxjobdesc="5242880"
configfile
configfile service_configuration_path - If [gridftpd] and [grid-manager] configuration parts are
located in separate files this configuration option allows to link them. The
service_configuration_path points to configuration file containing [grid-manager] section. Use
this option only if You really know what You are doing.
Example:
configfile="/etc/arc.conf"
[infosys] block
[infosys] block configures the hosting environment of the Information services (Local Info Tree, Index
Service, Registrations, see the Information System manual) provided by the OpenLDAP slapd server.
infosys_compat
infosys_compat - Setting this variable will cause ARC to use the old infoproviders. Basically,
the new version uses A-REX to create LDIF while the old version uses a BDII provider-script to do
it. The new version is required for GLUE2 output.
Example:
infosys_compat="disable"
infoproviders_timeout
infoproviders_timeout - this only applies to new infoproviders. it changes A-REX behaviour with
respect to a single infoprovider run. Increase this value if you have many jobs in the controldir
and infoproviders need more time to process. The value is in seconds. Default is 600 seconds.
Example:
infoproviders_timeout = "600"
debug debug - sets the debug level/verbosity of the startup script {0 or 1}. Default is 0.
Example:
debug="1"
hostname
hostname - the hostname of the machine running the slapd service will be the bind for slapd. If
not present, will be taken from the [common] block or guessed
Example:
hostname="my.testbox"
port port - the port where the slapd service runs. Default infosys port is 2135.
Example:
port="2135"
slapd_loglevel
slapd_loglevel - sets the native slapd loglevel (see man slapd). Slapd logs via syslog. The
default is set to no-logging (0) and it is RECOMMENDED not to be changed in a production
environment. Non-zero slap_loglevel value causes serious performance decrease.
Example:
slapd_loglevel="0"
slapd_hostnamebind
slapd_hostnamebind - may be used to set the hostname part of the network interface to which the
slapd process will bind. Most of the cases no need to set since the hostname configuration
parameter is already sufficient. The default is empty. The example below will bind the slapd
process to all the network interfaces available on the server.
Example:
slapd_hostnamebind="*"
threads
threads - the native slapd threads parameter, default is 32. If you run an Index service too you
should modify this value.
Example:
threads="128"
timelimit
timelimit - the native slapd timelimit parameter. Maximum number of seconds the slapd server will
spend answering a search request. Default is 3600. You probably want a much lower value.
Example:
timelimit="1800"
idletimeout
idletimeout - the native slapd idletimeout parameter. Maximum number of seconds the slapd server
will wait before forcibly closing idle client connections. Its value must be larger than the value
of "timelimit" option. If not set, it defaults to timelimit + 1.
Example:
idletimeout="1800"
ldap_schema_dir
ldap_schema_dir - allows to explicitly specify a path to the schema files. Note that this doesn't
override standard location, but adds the specified path to the standard locations /etc/ldap and
/etc/openldap. If you plan to relocate Glue1 and GLUE2 schemas, all these should be in the same
directory that you specify here. this option does NOT apply to nordugrid.schema file. Such file
has a release dependent location. Default is to use only standard locations described above.
Example:
ldap_schema_dir="/nfs/ldap/schema/"
oldconfsuffix
oldconfsuffix .suffix - sets the suffix of the backup files of the low-level slapd configuration
files in case they are regenerated. Default is ".oldconfig".
Example:
oldconfsuffix=".oldconfig"
overwrite_config
overwrite_config yes|no - determines if the infosys startup scripts should generate new low-level
slapd configuration files. By default the low-level configuration files are regenerated with
every server startup making use of the values specified in the arc.conf.
Example:
overwrite_config="yes"
registrationlog
registrationlog path - specifies the logfile for the registration processes initiated by your
machine. Default is "/var/log/arc/inforegistration.log"
Example:
registrationlog="/var/log/arc/inforegistration.log"
providerlog
providerlog path - Specifies log file location for the information provider scripts. The feature
is only available with >= 0.5.26 tag. Default is "/var/log/arc/infoprovider.log"
Example:
providerlog="/var/log/arc/infoprovider.log"
provider_loglevel
provider_loglevel - loglevel for the infoprovider scripts (0-5). The default is 1 (critical
errors are logged)
Example:
provider_loglevel="2"
user user unix_user - the unix user running the infosys processes such as the slapd, the registrations
and infoprovider scripts. By default the ldap-user is used, you can run it as root if you wish.
In case of non-root value you must make sure that the A-REX directories and their content are
readable by the 'user' and the 'user' has access to the full LRMS information including jobs
submitted by other users. The A-REX directories (controldir, sessiondir runtimedir, cachedir) are
specified in the [grid-manager] block
Example:
user="root"
giis_location
giis_location - If giis_location is not set, ARC_LOCATION will be used instead.
Example:
giis_location="/usr/"
infosys_nordugrid
These three variables decide which schema should be used for publishing data. They can all be
enabled at the same time. Default is to enable nordugrid mds and disable glue. infosys_nordugrid
- Enables NorduGrid schema
Example:
infosys_nordugrid="enable"
infosys_glue12
infosys_glue12 - Enables glue1.2/1.3 schema If infosys_glue12 is enabled, then resource_location,
resource_latitude and resource_longitude need to be set in the [infosys/glue12] block. These
variables do not have default values. The rest of the variables defaults are showcased below.
Example:
infosys_glue12="disable"
infosys_glue2_ldap
infosys_glue2 - Enables GLUE2 schema
Example:
infosys_glue2_ldap="disable"
infosys_glue2_ldap_showactivities
infosys_glue2_ldap_showactivities - Enables GLUE2 ComputingActivities to appear in the LDAP
rendering they're currently disabled by default.
Example:
infosys_glue2_ldap_showactivities="disable"
infosys_glue2_service_qualitylevel
infosys_glue2_service_qualitylevel - Allows a sysadmin to define a different GLUE2 QualityLevel
for A-REX. This can be used for operations. default: production Allowed value is one of:
"production", "pre-production", "testing", "development" Refer to GLUE2 documentation for the
meaning of these strings.
Example:
infosys_glue2_service_qualitylevel="production"
slapd slapd - Configure where the slapd command is located, default is: /usr/sbin/slapd
Example:
slapd="/usr/sbin/slapd"
slapadd
slapadd - Configure where the slapadd command is located, default is: /usr/sbin/slapadd
Example:
slapadd="/usr/sbin/slapadd"
BDII specific
Starting from 11.05, Nordugrid ARC only supports BDII5. These variables are usually automatically set by
ARC, and are here mostly for debug purposes and to tweak exotic BDII5 installations. In general, a
sysadmin should not set these.
bdii_debug_level
bdii_debug_level - set the following to DEBUG to check bdii errors in bdii-update.log useful not
to enable slapd logs reducing performance issues.
Example:
bdii_debug_level="ERROR"
provider_timeout
provider_timeout - This variable allows a system administrator to modify the behaviour of bdii-
update. This is the time BDII waits for the scripts generated by A-REX infoproviders to produce
their output. Default is 300 seconds.
Example:
provider_timeout=300
infosys_debug
infosys_debug - This variable disables/enables an ldap-database containing information about the
ldap database itself on "o=infosys" it is very useful for debugging. Default is enabled.
Example:
infosys_debug="disable"
BDII5 uses the following variables. These might change depending on BDII version. ARC sets them by
inspecting distributed bdii configuration files. DO NOT CHANGE UNLESS YOU KNOW WHAT YOU'RE DOING
bdii_location
bdii_location - The installation directory for the BDII. Default is /usr
Example:
bdii_location="/usr"
bdii_var_dir
bdii_var_dir - Contains BDII pid files and slapd pid files
Example:
bdii_var_dir="/var/run/arc/bdii"
bdii_log_dir
bdii_log_dir - Contains infosys logs
Example:
bdii_log_dir="/var/log/arc/bdii"
bdii_tmp_dir
bdii_tmp_dir - Contains provider scripts
Example:
bdii_tmp_dir="/var/tmp/arc/bdii"
bdii_lib_dir
bdii_lib_dir - Contains slapd databases
Example:
bdii_lib_dir="/var/lib/arc/bdii"
bdii_update_pid_file
bdii_update_pid_file, slapd_pid_file - Allows to change bdii-update and slapd pidfiles filename
and location
Example:
bdii_update_pid_file="/var/run/arc/bdii-update.pid"
slapd_pid_file="$bdii_var_dir/db/slapd.pid"
bdii_database
bdii_database - Configure what ldap database backend should be used, default is: bdb
Example:
bdii_database="bdb"
The following options are for tweaking only. Usually one should not configure them. They change the BDII
configuration file generated by ARC. Please consult BDII manual for details.
bdii_conf
bdii_conf - Location of the bdii configuration file. ARC modifies the original and sets it as
default /var/run/arc/infosys/bdii.conf
Example:
bdii_conf="/var/run/arc/infosys/bdii.conf"
Command line options used to run bdii-update. ARC finds it looking into bdii configuration. default:
${bdii_location}/sbin/bdii-update
bdii_update_cmd
bdii_archive_size
bdii_db_config
bdii_breathe_time
bdii_delete_delay
bdii_read_timeout
bdii_run_dir
bindmethod
cachettl
db_archive
db_checkpoint
EGIIS-related commands
giis_fifo
giis_fifo - path to fifo used by EGIIS. default is /var/run/arc/giis-fifo This file is
automatically created by ARC, the option is only for tweaking.
Example:
giis_fifo=/var/run/arc/giis-fifo
LDAP parameters of the cluster.pl (old) infoprovider, use the defaults, do NOT change them unless you
know what you are doing
cachetime
cachetime affects old infoproviders, and forces the validity time of the record.
Example:
cachetime="30"
sizelimit
sizelimit affects registration to egiis
Example:
sizelimit="10"
slapd_cron_checkpoint
slapd_cron_checkpoint - LDAP checkpoint enable/disable This option was introduced to solve bug
#2032, to reduce the number of log files produced by BDII. It is usually not needed, but if BDII
produces large logs and huge number of files, should help solving the issues related to that.
Example:
slapd_cron_checkpoint="enable"
[infosys/glue12] block
This block holds information that is needed by the glue 1.2 generation. This is only necessary if
infosys_glue12 is enabled.
resource_location
These variables need to be set if infosys_glue12 is enabled. IMPORTANT: no slashes or backslashes
here! Example: "Kastrup, Denmark"
Example:
resource_location=""
resource_latitude
Example: "55.75000"
Example:
resource_latitude=""
resource_longitude
Example: "12.41670"
Example:
resource_longitude=""
cpu_scaling_reference_si00
Example 2400
Example:
cpu_scaling_reference_si00=""
processor_other_description
Example Cores=3,Benchmark=9.8-HEP-SPEC06
Example:
processor_other_description=""
glue_site_web
Example http://www.ndgf.org
Example:
glue_site_web=""
glue_site_unique_id
Example NDGF-T1
Example:
glue_site_unique_id=""
provide_glue_site_info
This variable decides if the GlueSite should be published. In case you want to set up a more
complicated setup with several publishers of data to a GlueSite, then you may wish to tweak this
parameter.
Example:
provide_glue_site_info="true"
[infosys/site/sitename] block
[infosys/site/sitename] Site BDII configuration block, this block is used to configure ARC to generate a
site-bdii that can be registered in GOCDB etc to make it a part of a gLite network. The sitename part is
to be declarative of the site-bdii being generated.
unique_id
The unique id used to identify this site, eg "NDGF-T1"
Example:
unique_id=""
url The URL is of the format: ldap://host.domain:2170/mds-vo-name=something,o=grid and should point to
the resource-bdii
Example:
url=""
[infosys/admindomain] block
[infosys/admindomain] GLUE2 AdminDomain configuration block, to configure administrative items of the
cluster. This values do not affect neither glue12 or nordugrid renderings. If the whole block is not
specified, will default to an AdminDomain called UNDEFINEDVALUE.
name name - the Name attribute for the domain. This will show in top-BDII to group the resources
belonging to this cluster. to group a bunch of clusters under the same AdminDomain, just use the
same name. If not specified, will default to UNDEFINEDVALUE.
Example:
name="ARC-TESTDOMAIN"
description
description - description of this domain. Not mandatory.
Example:
description="ARC test Domain"
www www - URL pointing at a site holding information about the AdminDomain. Not mandatory.
Example:
www="http://www.nordugrid.org/"
distributed
distributed - set this to yes if the domain is distributed that means, if the resources belonging
to the domain are considered geographically distributed.
Example:
distributed=yes
owner owner - contact email of a responsible subject for the domain
Example:
owner=admin@nordugrid.org
otherinfo
otherinfo - fills the OtherInfo GLUE2 field. no need to set, used only for future development.
Example:
otherinfo=Test Other info
[infosys/index/indexname] block
[infosys/index/indexname] Index Service block configures and enables an Information Index Service. A
separate Index block is required for every Index Service you may run on the given machine. The
'indexname' constitutes to the
name name - The unique (within the hosting machine) name of the Index Service. Its value becomes part
of the LDAP suffix of the Index Service: (mds-vo-name=value of the name attribute, o=grid)
Example:
name="indexname"
allowreg
allowregistration - Implements registration filtering within an Index Sevice Sets the Local
Information Trees or lower level Index Services allowed to register to the Index Service. List
each allowed registrants with the allowreg attribute.
WARNING: specifying allowreg implies setting up a strict filtering, only the matching registrants
will be able to register to the Index. The wildcard * can be used in allowreg. Several allowreg
lines can be used. Some examples:
-All the Swedish machines can register regardless they are resources or Indices
allowreg="*.se:2135"
-Cluster resources from Denmark can register allowreg="*.dk:2135/nordugrid-cluster-name=*, Mds-
Vo-name=local, o=grid"
-Storage resources from HIP, Finland can register allowreg="*hip.fi:2135/nordugrid-se-name=*,
Mds-Vo-name=local, o=grid"
-The index1.sweden.se can register as a Sweden Index (and only as a Sweden Index)
allowreg="index1.sweden.se:2135/Mds-vo-Name=Sweden,o=Grid"
-Any Index Service can register allowreg="*:2135/Mds-vo-Name=*,o=Grid"
Example:
allowreg="trusted.host.org.se:2135/Mds-vo-Name=Trusted-Index,o=Grid"
[infosys/index/indexname/registration/registrationname] block
[infosys/index/indexname/registration/registrationname] Index service registration block This block
enables a registration process initiated by the to a target Index Service. NorduGrid maintains a webpage
with information on major Index Services: http://www.nordugrid.org/NorduGridMDS/index_service.html
targethostname
targethostname - the hostname of the machine running the registration target Index Service
Example:
targethostname="index.myinstitute.org"
targetport
targetport - the port on which the target Index Service is running. The default is the 2135
Infosys port.
Example:
targetport="2135"
targetsuffix
targetsuffix - the LDAP suffix of the target Index Service
Example:
targetsuffix="mds-vo-name=BigIndex,o=grid"
regperiod
regperiod - The registration period in seconds, the registration messages are continously sent
according to the regperiod. Default is 120 sec.
Example:
regperiod="300"
registranthostname
registranthostname - the hostname of the machine sending the registrations. This attribute
inherits its value from the [common] and [infosys] blocks, most cases no need to set.
Example:
registranthostname="myhost.org"
registrantport
registrantport - the port of the slapd service hosting the registrant Index Service. The attribute
inherits its value from the [infosys] block (and therefore defaults to 2135)
Example:
registrantport="2135"
registrantsuffix
registrantsuffix - the LDAP suffix of the registrant Index Service. It is automatically
determined from the registration block name, therefore most of the cases no need to specify. In
this case the default registrantsuffix will be:
"Mds-Vo-name=indexname"
please mind uppercase/lowercase characters in the above string when defining allowreg in an index!
Don't set it unless you want to overwrite the default.
Example:
registrantsuffix="mds-vo-name=indexname,o=grid"
[cluster] block
This block configures how your cluster is seen on the grid monitor (infosys point of view). Please
consult the Infosys manual for detailed information on cluster attributes. If you want your cluster
(configured below) to appear in the infosys (on the monitor) you also need to create a cluster
registration block (see the next block).
hostname
hostname - the FQDN of the frontend node, if the hostname is not set already in the common block
then it MUST be set here
Example:
hostname="myhost.org"
interactive_contactstring
interactive_contactstring - the contact string for interactive logins, set this if the cluster
supports some sort of grid-enabled interactive login (gsi-ssh), multivalued
Example:
interactive_contactstring="gsissh://frontend.cluster:2200"
cluster_alias
alias - an arbitrary alias name of the cluster, optional
Example:
cluster_alias="Big Blue Cluster in Nowhere"
comment
comment - a free text field for additional comments on the cluster in a single line, no newline
character is allowed!
Example:
comment="This cluster is specially designed for XYZ applications: www.xyz.org"
cluster_location
cluster_location - The geographical location of the cluster, preferably specified as a postal code
with a two letter country prefix
Example:
cluster_location="DK-2100"
cluster_owner
cluster_owner - it can be used to indicate the owner of a resource, multiple entries can be used
Example:
cluster_owner="World Grid Project"
cluster_owner="University of NeverLand"
authorizedvo
authorizedvo - this attribute is used to advertise which VOs are authorized on the cluster.
Multiple entries are allowed. This entries will be shown in GLUE2 AccessPolicy and MappingPolicy
objects.
Example:
authorizedvo="developer.nordugrid.org"
authorizedvo="community.nordugrid.org"
clustersupport
clustersupport - this is the support email address of the resource, multiple entries can be used
Example:
clustersupport="grid.support@mysite.org"
clustersupport="grid.support@myproject.org"
lrmsconfig
lrmsconfig - an optional free text field to describe the configuration of your Local Resource
Management System (batch system).
Example:
lrmsconfig="single job per processor"
homogeneity
homogeneity - determines whether the cluster consists of identical NODES with respect to cputype,
memory, installed software (opsys). The frontend is NOT needed to be homogeneous with the nodes.
In case of inhomogeneous nodes, try to arrange the nodes into homogeneous groups assigned to a
queue and use queue-level attributes. Possible values: True,False, the default is True. False
will trigger multiple GLUE2 ExecutionEnvironments to be published if applicable.
Example:
homogeneity="True"
architecture
architecture - sets the hardware architecture of the NODES. The "architecture" is defined as the
output of the "uname -m" (e.g. i686). Use this cluster attribute if only the NODES are homogeneous
with respect to the architecture. Otherwise the queue-level attribute may be used for
inhomogeneous nodes. If the frontend's architecture agrees to the nodes, the "adotf"
(Automatically Determine On The Frontend) can be used to request automatic determination.
Example:
architecture="adotf"
opsys opsys - this multivalued attribute is meant to describe the operating system of the computing
NODES. Set it to the opsys distribution of the NODES and not the frontend! opsys can also be used
to describe the kernel or libc version in case those differ from the originally shipped ones. The
distribution name should be given as distroname-version.number, where spaces are not allowed.
Kernel version should come in the form kernelname-version.number. If the NODES are inhomogeneous
with respect to this attribute do NOT set it on cluster level, arrange your nodes into homogeneous
groups assigned to a queue and use queue-level attributes.
Example:
opsys="Linux-2.6.18"
opsys="glibc-2.5.58"
opsys="CentOS-5.6"
nodecpu
nodecpu - this is the cputype of the homogeneous nodes. The string is constructed from the
/proc/cpuinfo as the value of "model name" and "@" and value of "cpu MHz". Do NOT set this
attribute on cluster level if the NODES are inhomogeneous with respect to cputype, instead arrange
the nodes into homogeneous groups assigned to a queue and use queue-level attributes. Setting the
nodecpu="adotf" will result in Automatic Determination On The Frontend, which should only be used
if the frontend has the same cputype as the homogeneous nodes.
Example:
nodecpu="AMD Duron(tm) Processor @ 700 MHz"
nodememory
nodememory - this is the amount of memory (specified in MB) on the node which can be guaranteed to
be available for the application. Please note in most cases it is less than the physical memory
installed in the nodes. Do NOT set this attribute on cluster level if the NODES are inhomogeneous
with respect to their memories, instead arrange the nodes into homogeneous groups assigned to a
queue and use queue-level attributes.
Example:
nodememory="512"
defaultmemory
defaultmemory - If a user submits a job without specifying how much memory should be used, this
value will be taken first. The order is: xrsl -> defaultmemory -> nodememory -> 1GB. This is the
amount of memory (specified in MB) that a job will request(per rank).
Example:
defaultmemory="512"
benchmark
benchmark name value - this optional multivalued attribute can be used to specify benchmark
results on the cluster level. Use this cluster attribute if only the NODES are homogeneous with
respect to the benchmark performance. Otherwise the similar queue-level attribute should be used.
Please try to use one of standard benchmark names given below if possible.
Example:
benchmark="SPECINT2000 222"
benchmark="SPECFP2000 333"
middleware
middleware - the multivalued attribute shows the installed grid software on the cluster, nordugrid
and globus-ng is automatically set, no need to specify middleware=nordugrid or middleware=globus
Example:
middleware="my grid software"
nodeaccess
nodeaccess - determines how the nodes can connect to the internet. Not setting anything means the
nodes are sitting on a private isolated network. "outbound" access means the nodes can connect to
the outside world while "inbound" access means the nodes can be connected from outside. inbound &
outbound access together means the nodes are sitting on a fully open network.
Example:
nodeaccess="inbound"
nodeaccess="outbound"
dedicated_node_string
dedicated_node_string - the string which is used in the PBS node configuration to distinguish the
grid nodes from the rest. Suppose only a subset of nodes are available for grid jobs, and these
nodes have a common "node property" string, this case the dedicated_node_string should be set to
this value and only the nodes with the corresponding "pbs node property" are counted as grid
enabled nodes. Setting the dedicated_node_string to the value of the "pbs node property" of the
grid-enabled nodes will influence how the totalcpus, user freecpus is calculated. You don't need
to set this attribute if your cluster is fully available for the grid and your cluster's PBS
configuration does not use the "node property" method to assign certain nodes to grid queues. You
shouldn't use this configuration option unless you make sure your PBS configuration makes use of
the above described setup.
Example:
dedicated_node_string="gridnode"
localse
localse - this multivalued parameter tells the BROKER that certain URLs (and locations below that)
should be considered "locally" available to the cluster.
Example:
localse="gsiftp://my.storage/data1/"
localse="gsiftp://my.storage/data2/"
gm_mount_point
gm_mount_point - this is the same as the "path" from the [gridftpd/jobs] block. The default is
"/jobs". Will be cleaned up later, do NOT touch it.
Example:
gm_mount_point="/jobs"
gm_port
gm_port - this is the same as the "port" from the [gridftpd] block. The default is "2811". Will be
cleaned up later.
Example:
gm_port="2811"
cpudistribution
cpudistribution - this is the CPU distribution over nodes given in the form: ncpu:m where
n is the number of CPUs per machine
m is the number of such computers
Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with 3 single CPU machines, 4 dual CPU
machines, one machine with 4 CPUs. This command is needed to tweak and overwrite the values
returned by the underlying LRMS. In general there is no need to configure it.
Example:
cpudistribution=1cpu:3,2cpu:4,4cpu:1
[infosys/cluster/registration/registrationname] block
Computing resource (cluster) registration block configures and enables the registration process of a
computing resource to an Index Service. A cluster can register to several Index Services this case each
registration process should have its own block. NorduGrid maintains a webpage with information on major
Index Services: http://www.nordugrid.org/NorduGridMDS/index_service.html
targethostname
targethostname - see description earlier
Example:
targethostname="index.myinstitute.org"
targetport
targetport - see description earlier
Example:
targetport="2135"
targetsuffix
targetsuffix - see description earlier
Example:
targetsuffix="mds-vo-name=BigIndex,o=grid"
regperiod
regperiod - see description earlier
Example:
regperiod="300"
registranthostname
registranthostname - see description earlier
Example:
registranthostname="myhost.org"
registrantport
registrantport - see description earlier
Example:
registrantport="2135"
registrantsuffix
registrantsuffix - the LDAP suffix of the registrant cluster resource It is automatically
determined from the [infosys] block and the registration blockname. In this case the default
registrantsuffix will be:
"nordugrid-cluster-name=hostname,Mds-Vo-name=local,o=Grid"
please mind uppercase/lowercase characters above if defining allowreg in an index! Don't set it
unless you want to overwrite the default.
Example:
registrantsuffix="nordugrid-cluster-name=myhost.org,Mds-Vo-name=local,o=grid"
[queue/queue_name] block
Each grid-enabled queue should have a separate queue block. The queuename should be used as a label in
the block name. A queue can represent a PBS/LSF/SGE/SLURM/LL queue, a SGE pool, a Condor pool or a
single machine in case 'fork' type of LRMS is specified in the [common] block.
Queues don't need to be registered (there is no queue registration block), once you configured your
cluster to register to an Index Service the queue entries (configured with this block) automatically will
be there. Please consult the ARC Information System manual for detailed information on queue attributes:
http://www.nordugrid.org/documents/arc_infosys.pdf
use the queue_name for labeling the block. The special name 'fork' should be used for labeling the queue
block in case you specified 'fork' type of LRMS in the [common] block.
name name sets the name of the grid-enabled queue. It MUST match the queue_name label of the
corresponding queue block, see above. Use "fork" if you specified 'fork' type of LRMS in the
[common] block. Queue name MUST be specified, even if the queue block is already correctly
labeled.
Example:
name="gridlong"
homogeneity
homogeneity - determines whether the queue consists of identical NODES with respect to cputype,
memory, installed software (opsys). In case of inhomogeneous nodes, try to arrange the nodes into
homogeneous groups and assigned them to a queue. Possible values: True,False, the default is
True.
Example:
homogeneity="True"
scheduling_policy
scheduling_policy - this optional parameter tells the schedulling policy of the queue, PBS by
default offers the FIFO scheduller, many sites run the MAUI. At the moment FIFO & MAUI is
supported. If you have a MAUI scheduller you should specify the "MAUI" value since it modifies the
way the queue resources are calculated. BY default the "FIFO" sceduller is assumed.
Example:
scheduling_policy="FIFO"
comment
comment - a free text field for additional comments on the queue in a single line, no newline
character is allowed!
Example:
comment="This queue is nothing more than a condor pool"
maui_bin_path
maui_bin_path - set this parameter for the path of the maui commands like showbf in case you
specified the "MAUI" scheduling_policy above. This parameter can be set in the [common] block as
well.
Example:
maui_bin_path="/usr/local/bin"
queue_node_string
queue_node_string - In PBS you can assign nodes to a queue (or a queue to nodes) by using the
"node property" PBS node configuration method and asssigning the marked nodes to the queue
(setting the resources_default.neednodes = queue_node_string for that queue). This parameter
should contain the "node property" string of the queue-assigned nodes. Setting the
queue_node_string changes how the queue-totalcpus, user freecpus are determined for this queue.
Essentially, queue_node_string value is used to construct nodes= string in PBS script, such as
nodes=count:queue_node_string where count is taken from the job description (1 if not specified).
You shouldn't use this option unless you are sure that your PBS configuration makes use of the
above configuration. Read NorduGrid PBS instructions for more information:
http://www.nordugrid.org/documents/pbs-config.html
Example:
queue_node_string="gridlong_nodes"
queue_node_string="ppn=4:ib"
sge_jobopts
sge_jobopts - additional SGE options to be used when submitting jobs to SGE from this queue. If
in doubt, leave it commented out
Example:
sge_jobopts="-P atlas -r yes"
condor_requirements
condor_requirements - only needed if using Condor. It needs to be defined for each queue. Use this
option to determine which nodes belong to the current queue. The value of 'condor_requirements'
must be a valid constraints string which is recognized by a condor_status -constraint '....'
command. It can reference pre-defined ClassAd attributes (like Memory, Opsys, Arch, HasJava, etc)
but also custom ClassAd attributes. To define a custom attribute on a condor node, just add two
lines like the ones below in the `hostname`.local config file on the node:
NORDUGRID_RESOURCE=TRUE
STARTD_EXPRS = NORDUGRID_RESOURCE, $(STARTD_EXPRS)
A job submitted to this queue is allowed to run on any node which satisfies the
'condor_requirements' constraint. If 'condor_requirements' is not set, jobs will be allowed to
run on any of the nodes in the pool. When configuring multiple queues, you can differentiate them
based on memory size or disk space, for example:
Example:
condor_requirements="(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)"
lsf_architecture
CPU architecture to request when submitting jobs to LSF. Use only if you know what you are doing.
Example:
lsf_architecture="PowerPC"
totalcpus
totalcpus - manually sets the number of cpus assigned to the queue. No need to specify the
parameter in case the queue_node_string method was used to assign nodes to the queue (this case it
is dynamically calculated and the static value is overwritten) or when the queue have access to
the entire cluster (this case the cluster level totalcpus is the relevant parameter). Use this
static parameter only if some special method is applied to assign a subset of totalcpus to the
queue.
Example:
totalcpus="32"
nodecpu
queue-level configuration parameters: nodecpu, nodememory, architecture, opsys and benchmark
should be set if they are homogeneous over the nodes assigned to the queue AND they are different
from the cluster-level value. Their meanings are described in the cluster block. Usage: this
queue collects nodes with "nodememory=512" while another queue has nodes with "nodememory=256" ->
don't set the cluster attributes but use the queue-level attributes. When the frontend's
architecture or cputype agrees with the queue nodes, the "adotf" (Automatically Determine On The
Frontend) can be used to request automatic determination of architecture or nodecpu.
Example:
nodecpu="adotf"
nodememory="512"
architecture="adotf"
opsys="Fedora 16"
opsys="Linux-3.0"
benchmark="SPECINT2000 222"
benchmark="SPECFP2000 333"
ac_policy
queue access policy rules based on VOMS attributes in user's proxy certificate (requires the arc-
vomsac-check plugin to be enabled). Matching rules have the following format:
ac_policy="[+/-]VOMS: <FQAN>"
Please read arc-vomsac-check manual page for more information.
Example:
ac_policy="-VOMS: /badvo"
ac_policy="VOMS: /.*/Role=production"
authorizedvo
authorizedvo - this attribute is used to advertise which VOs are authorized on the specific queue.
Multiple entries are allowed. This entries will be shown in the MappingPolicy objects. If
something is already defined in the [cluster] block, the shown VOs will be the union set of those
defined in [cluster] with those specific to this [queue] block.
Example:
authorizedvo="LocalUsers"
authorizedvo="atlas"
authorizedvo="community.nordugrid.org"
cachetime
this affects old infoproviders, and forces the validity time of the record.
Example:
cachetime="30"
sizelimit
sizelimit affects registration to EGIIS
Example:
sizelimit="5000"
[registration/emir] block
Services registration into EMIR block configures and enables the registration process of a services
enabled in this configuration file into EMI indexing service (EMIR).
emirurls
List of URL separated by comma of EMIR services which are to accept registration. This is
mandatory.
Example:
emirurls="https://somehost:60002/emir"
validity
Time in seconds for which registration records should stay valid.
Example:
validity=600
period Time in seconds how othen registration record should be sent to the registration service.
Example:
period=60
disablereg_xbes
disablereg_xbes may be used to selectively disable registration of A-REX service. Possible values
are yes and no. Default is no,
Example:
disablereg_xbes="no"
[nordugridmap] block
[nordugridmap] block configuration is used to fine-tune behaviour of the nordugridmap - an ARC tool used
to generate grid-mapfiles. Please refer to [vo] block description to find information how to specify VO
sources for mapfile generation. This section setup general VO-independent parameters.
x509_user_key
x509_user_cert, x509_user_key - public certificate and privat key to be used when fetching sources
over TLS (https:// and vomss:// sources retrieval rely on this parameter) If not specified, values
defined in [common] section will be used. If there is also no [common] section,
X509_USER_{CERT,KEY} variables are used. Default is '/etc/grid-security/host{cert,key}.pem'
Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"
x509_cert_dir
x509_cert_dir - the directory containing CA certificates. This information is needed by the
'require_issuerdn' [vo] block option. Default is '/etc/grid-security/certificates/'.
Example:
x509_cert_dir="/etc/grid-security/certificates/"
generate_vomapfile
generate_vomapfile - control is nordugridmap will generate vo-mapfile used by arc-ur-logger.
Default is 'yes'.
Example:
generate_vomapfile="yes"
vomapfile
vomapfile - path to vo-mapfile location. Default is /etc/grid-security/grid-vo-mapfile
Example:
vomapfile="/etc/grid-security/grid-vo-mapfile"
log_to_file
log_to_file - control whether logging output of nordugridmap will be saved to file. Default is
'no' (STDERR is used).
Example:
log_to_file="yes"
logfile
logfile - specify the nordugridmap log file location when in use. Default is
'/var/log/arc/nordugridmap.log'.
Example:
logfile="/var/log/arc/nordugridmap.log"
cache_enable
cache_enable - control whether caching of external sources will be used. Default is 'yes'.
Example:
cache_enable="yes"
cachedir
cachedir - specify the path where cached sources will be stored. Default is
'/var/spool/nordugrid/gridmapcache/'
Example:
cachedir="/var/spool/nordugrid/gridmapcache/"
cachetime
cachetime - controls how many time (in seconds) cached information remains valid. Default is
259200 (3 days).
Example:
cachetime="259200"
issuer_processing
issuer_processing - control the behaviour of [vo] block require_issuerdn parameter. Valid values
are 'relaxed' and 'strict'. Please see 'require_issuerdn' description in [vo] block for details.
Default is 'relaxed'.
Example:
issuer_processing="relaxed"
mapuser_processing
mapuser_processing - control the behaviour of [vo] block mapped_unixid parameter usage. Valid
values are 'overwrite' and 'keep'. Please see 'mapped_unixid' description in [vo] block for
details. Default is 'keep'.
Example:
mapuser_processing="keep"
allow_empty_unixid
allow_empty_unixid - control whether empty (or unspecified) Please see 'mapped_unixid' description
of [vo] block for details. Default is 'no'
Example:
allow_empty_unixid="no"
voms_method
voms_method - control how to get information from voms(s) sources. Valid values are:
soap - call SOAP method directly using SOAP::Lite
get - use old implementation that manually parses XML response Default is 'soap'.
Example:
voms_method="soap"
debug debug level - controls the verbosity of nordugridmap output. Valid values are:
0 - FATAL - only critical fatal error shown
1 - ERROR - errors, including non-critical are shown
2 - WARNING (default) - configuration errors that can be ignored
3 - INFO - processing information
4 - VERBOSE - a bit more processing information
5 - DEBUG - lot of processing information
When test run is requested (--test command line option of the nordugridmap) debug level is
automatically set to 5 (DEBUG). Default is 2 (WARNING)
Example:
debug="4"
fetch_timeout
fetch_timeout - control how many time (in seconds) nordugridmap will wait for external sources
retrieval. Default is 15.
Example:
fetch_timeout="15"
The [acix/cacheserver] block
The cache server component of ACIX runs alongside A-REX. It periodically scans the cache directories and
composes a Bloom filter of cache content which can be pulled by an ACIX index server.
logfile
Log file location for the cache server. Default is /var/log/arc/acix-cache.log
Example:
logfile="/tmp/acix-cache.log"
The [acix/indexserver] block
The index server component of ACIX collects cache content filters from a set of cache servers configured
in this block. The index server can be queried for the location of cached files.
cacheserver
ACIX cache servers from which to pull information
Example:
cacheserver="https://some.host:5443/data/cache"
cacheserver="https://another.host:5443/data/cache"
NorduGrid ARC 5.0.5 2016-03-26 arc.conf(5)