ARC Configuration Reference Document
General configuration structure
This is the arc.conf REFERENCE DOCUMENT defining the configuration blocks and
configuration options for the ARC services.
The arc.conf configuration file consists of the following blocks:
[common]
[authtokens]
[authgroup:groupname]
[mapping]
[lrms]
[arex]
[arex/cache]
[arex/cache/cleaner]
[arex/data-staging]
[arex/ws]
[arex/ws/jobs]
[arex/ws/publicinfo]
[arex/ws/cache]
[arex/ws/candypond]
[arex/jura]
[arex/jura/sgas:targetname]
[arex/jura/apel:targetname]
[arex/ganglia]
[infosys]
[infosys/ldap]
[infosys/nordugrid]
[infosys/glue2]
[infosys/glue2/ldap]
[infosys/cluster]
[queue:name]
[datadelivery-service]
[custom:blockname]
[block]
A block configures an ARC service, a service interface, a utility or a subsystem.
Enabling (turning on) a functionality, a service or an interface requires the presence of the
appropriate configuration block. To disable a service or an interface, simply delete or
comment out the related arc.conf block (you may need to rerun the corresponding startup script).
The [common] block is mandatory even if not a single option is specified within. The presence of
the block turns on the default values for the configuration options within the block.
As an example, in order to set up a minimalistic ARC CE offering no external interfaces
you need to configure at least the [common], [mapping], [arex], [lrms],
[infosys] and [queue:name] blocks.
As another example, an ARC-based data offloader would require the [common] and the
[datadelivery-service] blocks.
A block is identified by its block header. A block header may consist of
keywords and optionally block identifiers. Keywords may be separated by /
and used to label subblocks (e.g. [arex/jura]), while block identifiers
are separated by : from keywords. For example, in the [queue:short]
block header queue is a keyword while short is an identifier, e.g. the name of the queue.
Block headers must be UNIQUE.
A block starts with a unique [keyword:identifier] blockheader and ends where the next block
starts, that is at the next [blockheader] directive.
A block may have sub-blocks e.g. the various interfaces of the AREX service are configured via
sub-blocks (e.g. [arex/ws]). When a sub-block is enabled then the corresponding parent block must
also appear in the arc.conf file.
Configuration blocks contain (config option, config value) pairs following the syntax in single line:
config_option=value element [optional value element]
Note
quotes around the configuration value(s) must NOT be used.
Note
the arc.conf is CASE-SENSITIVE!
Space handling syntax in arc.conf
for configuration lines:
(stripped space)option(stripped space)=(stripped space)value(saved space)(value)(stripped space)
and for block headers:
[keyword:(stripped space)space is NOT allowed within identifier(stripped space)]
Detailed textual definition:
All trailing and leading spaces on each confiuration line are stripped and ignored. This aplies both to block headers and block content.
All spaces around the
=sign inoption=valuekind of string (after ‘a’ is applied) are stripped and ignored. For example linehostname = myhost.infois treated as identical tohostname=myhost.info.In block headers of
[keyword]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand insidekeyword.In block headers of
[keyword:identifier]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand inside bothkeywordandidentifier. The spaces ARE allowed aroundidentifierpart and stripped and ignored.
Mandatory configuration options are indicated by an asterix prefix to the
option name e.g: *mandatory_configoption. Mandatory options with undefined values
will result in service stop during the startup process.
Each of the configuration options have well-defined default that is specified in this reference
file. The default can take either a pre-set value, a special substitution or the keyword
undefined. Configuration options within an enabled block take their default values in case
they are missing (or commented out). Configuration parameters with undefined defaults takes
no values. Furthermore, configuration options within disabled blocks takes no values either.
Configuration blocks are ORDER-DEPENDENT. To be safe, please use the order as indicated in the list of blocks in this reference. This is especially important for configuration blocks related to authorization and mapping. The order dependency is also honoured within options inside a certain block.
This means for instance that configuration blocks related to authorization MUST appear before used in
the blocks such as [mapping], [arex/ws/jobs] or [gridftp/jobs]. Order dependency within a block is
for instance important when it comes to authorization decisions, as the first matching rule is used.
For more details see the specific block reference.
Below we give a detailed description of all the configuration options of the
different configuration blocks. Every configuration option is described
in a dedicated paragraph with the following reference syntax notation.
This file is parsed at buildtime to assist in configuration default parsing and validation script
and so it is important that it follows the agreed syntax: For each block or
option please add explanatory text with two ## followed by a space at the
beginning of the line and then an example with a single # and no spaces at
the beginning of the line.
example_config_option
Synopsis: example_config_option = value [optional values]
Description: Here comes the explanation
of the config option. Mandatory configuration options are indicated by an asterix prefix to the
option name e.g: *mandatory_configoption vs. optional_configoption.
The explanation can be followed by the special keywords in a separate line:
multivalued- used to indicate that config option can be specified multiple times. This forms a set of values for the same configuration option irrespective of lines order.
sequenced- used to indicate that config option is a part of the sequence and its effect on configuration depends on the lines order. Sequenced option can be specified several times in the configuration sequence independently.
Missing such keywords means the config option can only occur once in the arc.conf.
By default the arc.conf config options are optional and single-valued.
For some config options only a fix set of values are allowed. These are
listed in a separate line after the allowedvalues keyword.
The default of every config option is explicitly given in the default: line.
Default can be a pre-set value, a substitution or the undefined keyword.
The last line of the paragraph is always a valid example preceded by a single #
This option in multivalued.
Allowed values: 12, 34, 56
Default: 34
Example:
example_config_option=56
Configuration blocks and options
[common] block
Common configuration affecting all ARC components, usually related to networking or security
or service behaviour. This block is mandatory.
The common block options may be overridden by the specific sections of the components later.
The [common] always appears at the beginning of the config file. The config options set within
this block are available for all the other blocks thus shared by the different components of ARC.
hostname
[common]
Synopsis: hostname = string
Description: The FQDN of the frontend on which the ARC services are deployed.
Default: $EXEC{hostname -f}
Example:
hostname=myhost.org
http_proxy
[common]
Synopsis: http_proxy = url
Description: The http proxy server. This setting affects all client HTTP(s) requests that initiated by ARC core services, including data staging, SAML communications, and pushing SGAS accounting records. This variable is similar to setting the ARC_HTTP_PROXY environmental variable.
Default: undefined
Example:
http_proxy=proxy.mydomain.org:3128
x509_host_key
[common]
Synopsis: x509_host_key = path
Description: Server credential location.
Sets the full path to the host private key.
These variables are similar to the GSI enviroment variable X509_USER_KEY
If indicated, the variable can be set individually for each service/component in the
corresponding block.
Default: /etc/grid-security/hostkey.pem
Example:
x509_host_key=/etc/grid-security/hostkey.pem
x509_host_cert
[common]
Synopsis: x509_host_cert = path
Description: Server credential location. Sets the full
path to the host public certificate.
These variables are similar to the GSI environment variable X509_USER_CERT
If indicated, the variable can be set individually for each service/component in the
corresponding block.
Default: /etc/grid-security/hostcert.pem
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
x509_cert_policy
[common]
Synopsis: x509_cert_policy = keyword
Description: layout of CA certificates. The following keywords are supported: globus, system. This varaible defines either server is going to use Globus layout of CA certifiactes or just let OpenSSL handle that.
Default: globus
Example:
x509_cert_policy=globus
x509_cert_dir
[common]
Synopsis: x509_cert_dir = path
Description: Location of trusted CA certificates.
This variable is similar to the GSI enviroment variable X509_CERT_DIR
If indicated, the variable can be set individually for each service/component in the
corresponding block. If x509_cert_policy is set to ‘system’ this variable is ignored.
Default: /etc/grid-security/certificates
Example:
x509_cert_dir=/etc/grid-security/certificates
x509_voms_dir
[common]
Synopsis: x509_voms_dir = path
Description: the path to the directory containing *.lsc files needed for verification of VOMS service signature in the proxy-certificate.
Default: /etc/grid-security/vomsdir
Example:
x509_voms_dir=/etc/grid-security/vomsdir
voms_processing
[common]
Synopsis: voms_processing = keyword
Description: Defines how to behave if errors in VOMS AC processing detected. The following keywords are supported:
relaxeduse everything that passed validation.
standardsame as relaxed but fail if parsing errors took place and VOMS extension is marked as critical. This is a default.
strictfail if any parsing error was discovered
noerrorsfail if any parsing or validation error happened.
Allowed values: relaxed, standard, strict, noerrors
Default: standard
Example:
voms_processing=strict
[authtokens] block
This block activates processing of OIDC tokens as defined in WLCG profile.
Warning
TODO: remove when it is actually always enabled in the code
[authgroup:groupname] block
These configuration blocks contain authorization rules.
An [authrgroup:groupname] block always defines a group of users where members of the group are
those who satisfy the authorization rules.
The rules within the block determine which user belong to the authgroup.
Then, access control and identity mapping of ARC services are implemented
via associating a authgroup with an interface, queue or a mapping rule
using one of the allowaccess, denyaccess or [mapping] block parameters.
The authgroup should not be mistaken for a virtual organisation (VO).
An authgroup may match a single VO if only a single check (rule) on VO membership is perfomed.
IMPORTANT: Rules in an authgroup are processed in their order of appearance.
The first matching rule decides the membership of the user to the authgroup
being evaluated and the processing STOPS within that authgroup. This does not mean that
the same user is not processed for the next authgroup: all [authgroup:groupname] blocks are
evaluated, even if a user already has a match with one of the earlier groups.
All the objects used in the rules MUST be defined before it may be used. For example, to create group of authgroups you must first defined the child groups.
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
+ (for positive) or - (for negative) signs. + is default and can
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.
subject
[authgroup:groupname]
Synopsis: subject = certificate_subject
Description: Rule to match specific subject of user’s X.509 certificate. No masks, patterns and regular expressions are allowed.
This is sequenced option.
Default: undefined
Example:
subject=/O=Grid/O=Big VO/CN=Main Boss
subject=/O=Grid/O=Big VO/CN=Deputy Boss
file
[authgroup:groupname]
Synopsis: file = path
Description: Processes a list of DNs stored in an external file one per line
in grid-mapfile format (see map_with_file from [mapping] block, unixname is ignored)
and adds those to the authgroup.
This is sequenced option.
Default: undefined
Example:
file=/etc/grid-security/local_users
file=/etc/grid-security/atlas_users
voms
[authgroup:groupname]
Synopsis: voms = vo group role capabilities
Description: Match VOMS attribute in user’s credential.
Use * to match any value.
This is sequenced option.
Default: undefined
Example:
voms=nordugrid Guests * *
voms=atlas students prodman *
authgroup
[authgroup:groupname]
Synopsis: authgroup = group_name [group_name ...]
Description: Match user already belonging to one
of specified authgroups. The authgroup referred here must be defined earlier in
arc.conf configuration file. Multiple authgroup names may be specified for this rule.
That allows creating hierarchical structure of authorization groups like
all-atlas are those which are atlas-users and atlas-admins.
This is sequenced option.
Default: undefined
Example:
authgroup=local_admins
authgroup=local_admins remote_users
plugin
[authgroup:groupname]
Synopsis: plugin = timeout path [arg1 [arg2 [arg3...]]]
Description: Run external executable or function from shared library. Rule is matched if plugin returns 0. Any other return code or timeout are treated as rule not matched. In arguments following substitutions are supported:
%D- subject of certicate
%P- path to proxy
The environment variables passed to plugin contain basic information about user authentication. Following variables are set if corresponding information is available:
X509_SUBJECT_NAME- common name of user’s certificate.
BEARER_TOKEN_#_SUBJECT- user’s subject (identifier) extracted from JWT token (here # is tokens index, typically 0)
BEARER_TOKEN_#_ISSUER- issuer of the token extracted from JWT token
BEARER_TOKEN_#_AUDIENCE- designated audience extracted from JWT token
BEARER_TOKEN_#_SCOPE_#- assigned scope extracted from JWT token (here second # is scope’s index starting from 0)
BEARER_TOKEN_#_GROUP_#- assigned WLCG group extracted from JWT token
BEARER_TOKEN_#_CLAIM_<name>_#- raw claim values of the token of claim<name>
ARC ships with LCAS plugin that can be enabled with following plugin configuration. For more information about configuring LCAS refer to ‘Using LCAS/LCMAPS’ document.
This is sequenced option.
Default: undefined
Example:
plugin=10 /usr/libexec/arc/arc-lcas %D %P liblcas.so /usr/lib64 /etc/lcas/lcas.db
Warning
CHANGE: NEW environment variables in 7.0.0.
authtokens
[authgroup:groupname]
Synopsis: authtokens = subject issuer audience scope group
Description:
Match OIDC token claims.
Use * to match any value.
This is sequenced option.
Default: undefined
Example:
authtokens=e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 https://wlcg.cloud.cnaf.infn.it/ * * *
authtokensgen
[authgroup:groupname]
Synopsis: authtokensgen = logical expression
Description: Match OIDC token claims. Expression to match. Following operators are available:
=- match token claim value (left part represents claim name) to specified string (right part), produces boolean result
~- match token claim value (left part represents claim name) to regex expression (right part), produces boolean result
!- boolean negation
&- boolean AND
|- boolean OR
^- boolean XOR
()- brackets are used to control priority of evaluation, without brackets all operators have same priority‘’ or `` - strings can be enclosd in quotes to allow special symbols in strings
All empty spaces are optional. This functionality is experimental.
Default: undefined
Warning
CHANGE: NEW in 7.0.0.
all
[authgroup:groupname]
Synopsis: all = yes|no
Description:
Matches any or none user identity. For yes argument this rule
always returns positive match. For no it is always no match.
This is sequenced option.
Default: undefined
Example:
all=yes
[mapping] block
This block defines the grid-identity to local UNIX identity mapping rules used by various ARC components.
Rules in the [mapping] block are processed IN A SEQUENCE in line order of the
configuration file (from top to bottom).
There are two kind of rules:
mapping rules that defines how the particular
authgroupmembers are mappedpolicy rules that modifies the mapping rules sequence processing
Default policy for mapping rules processing is:
processing CONTINUES to the next rule if identity of user DO NOT match
authgroupspecified in the rule (can be redefined withpolicy_on_nogroupoption)processing STOPS if identity of user match
authgroupspecified in the mapping rule. Depend on whether this mapping rule returns valid UNIX identity the processing can be redefined withpolicy_on_mapandpolicy_on_nomapoptions.
Policy can be redefined at the any point of configuration sequence and affects all mapping rules defined after the polcy rule.
Note
if mapping process STOPS and there is still no local UNIX identity identified, the user running A-REX will be used.
Note
when grid-identity is mapped to root account - request processing fails implicitely.
map_to_user
[mapping]
Synopsis: map_to_user = authgroup_name unixname[:unixgroup]
Description:
the users that belongs to
specified authgroup are mapped to unixname local UNIX account that may be
optionally followed by a unixgroup UNIX group.
In case of non-existing unixname account the mapping rule treated as a rule that
did not returned mapped identity (nomap).
This is sequenced option.
Default: undefined
Example:
map_to_user=authgroupA nobody:nobody
map_to_pool
[mapping]
Synopsis: map_to_pool = authgroup_name directory
Description: the user that belong to specified
authgroup is assigned one of the local UNIX accounts in the pool. Account names that
are part of this pool are stored line-by-line in the pool file inside the directory.
The directory also contains information about used accont names stored in another files.
If there are no more available accounts in the defined pool for mapping then
accounts not used for a configurable time period may be reassigned.
The pool behaviour, including account reuse, is configureable with the opional
directory/config file that has INI syntax (line-by-line key=value).
Possible keys of the config file are:
timeoutDefine the timeout in days (default is
10) after which the UNIX account can be reassigned to another user if not used. The0value means no lease expiration.
This is sequenced option.
Default: undefined
Example:
map_to_pool=atlas /etc/grid-security/pool/atlas
map_with_file
[mapping]
Synopsis: map_with_file = authgroup_name file
Description:
for users that belongs to specified
authgroup the DN of certificate is matched against a list of DNs stored in
the specified file, one per line followed by a local UNIX account name.
The DN must be quoted if it contains blank spaces.
This rule can be used to implement legacy grid-mapfile aproach.
This is sequenced option.
Default: undefined
Example:
map_with_file=authgroupB /etc/grid-security/grid-mapfile
map_with_plugin
[mapping]
Synopsis: map_with_plugin = authgroup_name timeout plugin [arg1 [arg2 [...]]]
Description: run
external plugin executable with specified arguments to find the UNIX account
name to which users that belogns to specified authgroup will be mapped to.
A rule matches if the exit code is 0 and there is a UNIX account name
printed on stdout (optionally followed by a UNIX group name separated by colon).
The exit code 1 designates failed mapping. Any other code or timeout means fatal
failure and will abort any further mapping processing. That will also cause
rejection of corresponding connection.
Plugin execution time is limited to timeout seconds.
The environment variables passed to plugin contain basic information about user
authentication. For description of those variables see ‘plugin’ command from
[authgroup] section.
In the arguments the following substitutions are applied before the plugin is started:
%D- subject of user’s certificate,
%P- path to credentials’ proxy file.
ARC ships with LCMAPS plugin that can be enabled with the corresponfing configuration. For more information about configuring LCMAPS refer to ‘Using LCAS/LCMAPS’ document.
This is sequenced option.
Default: undefined
Example:
map_with_plugin=authgroupC 30 /usr/libexec/arc/arc-lcmaps %D %P liblcmaps.so /usr/lib64 /etc/lcmaps/lcmaps.db arc
policy_on_nomap
[mapping]
Synopsis: policy_on_nomap = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user match authgroup specified in the mapping rule and mapping
rule DO NOT return valid UNIX identity. Default policy is stop processing the furhter
rules.
For example this policy will be triggered if pool is depleted, certificate subject is
missing in the map file used for defined authgroup or plugin execution failed.
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_nomap=continue
policy_on_map
[mapping]
Synopsis: policy_on_map = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user match authgroup specified in the mapping rule and mapping
rule return valid UNIX identity. Default policy is stop processing the furhter
rules.
This policy will be triggered if rule successfully returns the result (allocated in pool,
matched in map file, plugin call was successful).
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_map=stop
policy_on_nogroup
[mapping]
Synopsis: policy_on_nogroup = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user DO NOT match authgroup specified in the mapping rule.
Default policy is continue processing the furhter rules.
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_nogroup=stop
[lrms] block
This block specifies the characteristics of the Local Resource Manager System (batch system) underneath the ARC CE. This block contains all the lrms-specific parameters and information. Configuration values in this block are available for A-REX, the backends, accounting and infosys ARC subsystems.
ARC support the most common LRMS flavours.
lrms
[lrms]
Synopsis: *lrms = lrmstype [defaultqueue]
Description: Sets the type of the LRMS (queue system) and optionally the default queue name. ONLY ONE LRMS IS ALLOWED. MULTIPLE LRMS ENTRIES WILL TRIGGER UNEXPECTED BEHAVIOUR.
Warning
TODO: mark deprecated backends
For lrmstype, the following values can be chosen:
fork - simple forking of jobs to the same node as the server
sge - (Sun/Oracle) Grid Engine
condor - Condor
pbs - PBS (covers Torque and other old PBS flavours e.g. OpenPBS, older PBSPro, etc)
pbspro - Altair PBS Professional
lsf - LSF
ll - LoadLeveler
slurm - SLURM
boinc - Boinc
The optional defaultqueue parameter specifies the name of an existing LRMS queue
in the cluster that will be used by AREX as the default queue to submit grid jobs in case
the client does not specify a queue name during the job submission procees.
This queue name must match one of the [queue:queue_name] blocks.
Allowed values: fork, sge, condor, pbs, pbspro, lsf, ll, slurm, boinc
Default: undefined
mandatory
Example:
lrms=pbspro gridlong
lrms=slurm
lrmsconfig
[lrms]
Synopsis: lrmsconfig = text
Description: An optional free text field to describe the configuration of your Local Resource Management System (batch system). The value is published in the infosys, and is not used otherwise.
Default: undefined
Example:
lrmsconfig=single job per processor
benchmark
[lrms]
Synopsis: benchmark = string
Description: Defines the default benchmark specification to store in the accounting AAR records if per-job data is missing. It is advised to set it to cluster-wide defaults in case of reporting to APEL to aviod records diversity for failed jobs or buggy backends.
Default: HEPSPEC 1.0
Example:
benchmark=HEPSPEC 12.26
Warning
CHANGE: MODIFIED in 7.0.0
defaultmemory
[lrms]
Synopsis: defaultmemory = number
Description: The LRMS memory request of job to be set by the LRMS backend scripts, if a user submits a job without specifying how much memory should be used. The order of precedence is: job description -> defaultmemory. This is the amount of memory (specified in MB) that a job will request.
Default: undefined
Example:
defaultmemory=512
nodename
[lrms]
Synopsis: nodename = path
Description: Redefine the command to obtain hostname of LRMS worker node.
By default the value is defined on buildtime and depend on the OS.
In most cases /bin/hostname -f will be used.
Note
this way of getting WN hostname will be used only in case of particular LRMS backend had no native LRMS-defined way.
Default: undefined
Example:
nodename=/bin/hostname -s
gnu_time
[lrms]
Synopsis: gnu_time = path
Description: Path to the GNU time command on the LRMS worker nodes. If time command exists on the node, jobscript will write additional diagnostic information.
Default: /usr/bin/time
Example:
gnu_time=/usr/bin/time
movetool
[lrms]
Synopsis: movetool = comand
Description: Redefine the command used to move files during jobscript execution on LRMS worker node (the command should be available on WNs). This in particular applies to files movement from sessiondir to scratchdir in the shared sessiondir case.
Default: mv
Example:
movetool=rsync -av
pbs_bin_path
[lrms]
Synopsis: pbs_bin_path = path
Description: The path to the qstat,pbsnodes,qmgr etc PBS binaries, no need to set if PBS is not used
Default: /usr/bin
Example:
pbs_bin_path=/usr/bin
pbs_log_path
[lrms]
Synopsis: pbs_log_path = path
Description: 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.
Default: /var/spool/pbs/server_logs
Example:
pbs_log_path=/var/spool/pbs/server_logs
pbs_dedicated_node_string
[lrms]
Synopsis: pbs_dedicated_node_string = string
Description: The string which
is used in the PBS node config 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 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 config does not use
the node property method to assign certain nodes to grid queues. You
shouldn’t use this config option unless you make sure your PBS config makes
use of the above described setup.
Default: undefined
Example:
pbs_dedicated_node_string=gridnode
condor_bin_path
[lrms]
Synopsis: condor_bin_path = path
Description: Path to Condor binaries. Must be set if Condor is used.
Default: /usr/bin
Example:
condor_bin_path=/opt/condor/bin
condor_config
[lrms]
Synopsis: condor_config = path
Description: Full path to Condor config file. Must be set if Condor is used and the config file is not in its default location (/etc/condor/condor_config or ~/condor/condor_config). The full path to the file should be given.
Default: /etc/condor/condor_config
Example:
condor_config=/opt/condor/etc/condor_config
condor_rank
[lrms]
Synopsis: condor_rank = ClassAd_float_expression
Description: 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.
Default: undefined
Example:
condor_rank=(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000
condor_requirements
[lrms]
Synopsis: condor_requirements = string
Description: Specify additional constraints for Condor resources.
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 resource 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.
Default: undefined
Example:
condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)
sge_bin_path
[lrms]
Synopsis: sge_bin_path = path
Description: Path to Sun Grid Engine (SGE) binaries, Default is search for qsub command in the shell PATH
Default: undefined
Example:
sge_bin_path=/opt/n1ge6/bin/lx24-x86
sge_root
[lrms]
Synopsis: sge_root = path
Description: Path to SGE installation directory. MUST be set if SGE is used.
Default: /gridware/sge
Example:
sge_root=/opt/n1ge6
sge_cell
[lrms]
Synopsis: sge_cell = name
Description: 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’
Default: default
Example:
sge_cell=default
sge_qmaster_port
[lrms]
Synopsis: sge_qmaster_port = port
Description: The SGE port 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.
Default: undefined
Example:
sge_qmaster_port=536
sge_execd_port
[lrms]
Synopsis: sge_execd_port = port
Description: The SGE port options should be used in case SGE command line clients requre SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables to be set. Usually they are not necessary.
Default: undefined
Example:
sge_execd_port=537
sge_jobopts
[lrms]
Synopsis: sge_jobopts = string
Description: Additional SGE options to be used when submitting jobs to SGE
Default: undefined
Example:
sge_jobopts=-P atlas -r yes
slurm_bin_path
[lrms]
Synopsis: slurm_bin_path = path
Description: Path to SLURM binaries, must be set if installed outside of normal PATH
Default: /usr/bin
Example:
slurm_bin_path=/usr/bin
slurm_wakeupperiod
[lrms]
Synopsis: slurm_wakeupperiod = numsec
Description: How long should infosys wait before querying SLURM for new data (seconds)
Default: 30
Example:
slurm_wakeupperiod=15
slurm_use_sacct
[lrms]
Synopsis: slurm_use_sacct = yes/no
Description: Indicates whether ARC should use sacct instead of scontrol to obtain information about finished jobs
Allowed values: yes, no
Default: yes
Example:
slurm_use_sacct=yes
slurm_requirements
[lrms]
Synopsis: slurm_requirements = string
Description: Use this option to specify extra SLURM-specific parameters.
Default: undefined
Example:
slurm_requirements=memory on node >> 200
slurm_query_retries
[lrms]
Synopsis: slurm_query_retries = number
Description: Number of sacct/scontrol retries performed in scan-SLURM-job If slurm is overloaded the sacct/scontrol command call may fail. If retries > 1 sacct/scontrol is retried after some seconds for that(those) particular job(s). If all retry attempts fail, the next scan-SLURM-job institiation will pick up the job(s) from last time.
Default: 1
Example:
slurm_query_retries=3
lsf_bin_path
[lrms]
Synopsis: lsf_bin_path = path
Description: The PATH to LSF bin folder
Default: /usr/bin
Example:
lsf_bin_path=/usr/local/lsf/bin/
lsf_profile_path
[lrms]
Synopsis: lsf_profile_path = path
Description: Path to the profile.lsf file. Infoprovider scripts will source profile.lsf to setup LSF utilites environment.
Default: /usr/share/lsf/conf/profile.lsf
Example:
lsf_profile_path=/usr/local/share/lsf/conf/profile.lsf
lsf_architecture
[lrms]
Synopsis: lsf_architecture = string
Description: CPU architecture to request when submitting jobs to LSF. Use only if you know what you are doing.
Default: undefined
Example:
lsf_architecture=PowerPC
ll_bin_path
[lrms]
Synopsis: ll_bin_path = path
Description: The PATH to the LoadLeveler bin folder
Default: /usr/bin
Example:
ll_bin_path=/opt/ibmll/LoadL/full/bin
ll_consumable_resources
[lrms]
Synopsis: ll_consumable_resources = yes/no
Description: Indicates whether the LoadLeveler setup is using Consumable Resources.
Allowed values: yes, no
Default: no
Example:
ll_consumable_resources=yes
boinc_db_host
[lrms]
Synopsis: boinc_db_host = hostname
Description: Connection strings for the boinc database: host
Default: localhost
Example:
boinc_db_host=localhost
boinc_db_port
[lrms]
Synopsis: boinc_db_port = port
Description: Connection strings for the boinc database: port
Default: 3306
Example:
boinc_db_port=3306
boinc_db_name
[lrms]
Synopsis: boinc_db_name = db_name
Description: Connection strings for the boinc database: db_name
Default: undefined
Example:
boinc_db_name=myproject
boinc_db_user
[lrms]
Synopsis: boinc_db_user = user
Description: Connection strings for the boinc database: db_user
Default: undefined
Example:
boinc_db_user=boinc
boinc_db_pass
[lrms]
Synopsis: boinc_db_pass = pwd
Description: Connection strings for the boinc database: pwd
Default: undefined
Example:
boinc_db_pass=password
boinc_app_id - ID of the app handled by this CE. Setting this option makes database queries much faster in large projects with many apps.
Default: undefined
Example:
boinc_app_id=1
boinc_project_dir - Base directory of the BOINC project
Default: undefined
Example:
boinc_project_dir=/home/boinc
[arex] block
The [arex] block, together with its various subblocks,
configures the A-REX service hosted in arched. A-REX takes care of
various middleware tasks on the frontend such as job creation and management,
stagein/stageout, LRMS job submission, data caching, etc…
user
[arex]
Synopsis: user = user[:group]
Description: Switch to a non root user/group after startup. Use with caution because of limited functionality when arex is not run under root.
Default: root
Example:
user=grid:grid
norootpower
[arex]
Synopsis: norootpower = yes|no
Description: If set to yes, all job management processes will switch to mapped user’s identity while accessing session directory. This is useful if session directory is on NFS with root squashing turned on.
Allowed values: yes, no
Default: no
Example:
norootpower=yes
delegationdb
[arex]
Synopsis: delegationdb = db_name
Description: specify which DB to use to store delegations. Currently supported db_names are bdb and sqlite
Default: sqlite
Example:
delegationdb=sqlite
watchdog
[arex]
Synopsis: watchdog = yes/no
Description: Specifies if additional watchdog processes is spawned to restart main process if it is stuck or dies.
Allowed values: yes, no
Default: no
Example:
watchdog=no
loglevel
[arex]
Synopsis: loglevel = level
Description: Set loglevel of the arched daemon hosting A-REX service between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
logfile
[arex]
Synopsis: logfile = path
Description: Specify A-REX log file location. If using an external log rotation tool be careful to make sure it matches the path specified here.
Default: /var/log/arc/arex.log
Example:
logfile=/var/log/arc/arex.log
joblog
[arex]
Synopsis: joblog = path
Description: Specifies where to store specialized log about started and finished jobs. If path is empty log is NOT written. Controlled by logrotate if deafult name is kept. This log is not used by any other part of ARC so can be safely disabled if you are not interested in storing jobs log.
Default: /var/log/arc/arex-jobs.log
Example:
joblog=
fixdirectories
[arex]
Synopsis: fixdirectories = yes/missing/no
Description: 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 permissions for all used directories are
set to default safe values.
Allowed values: yes, missing, no
Default: yes
Example:
fixdirectories=yes
controldir
[arex]
Synopsis: controldir = path
Description: The directory of the A-REX’s internal job metadata files. For a heavy loaded computing elements you can consider to locate controldir on a dedicated partition optimized for small random reads and writes. The directory is not needed on the nodes.
Default: /var/spool/arc/jobstatus
Example:
controldir=/var/spool/arc/jobstatus
sessiondir
[arex]
Synopsis: sessiondir = path [drain]
Description: the directory which holds the sessiondirs of the grid jobs.
Multiple session directories may be specified.
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.
This option in multivalued.
Default: /var/spool/arc/sessiondir
Example:
sessiondir=/scratch/arcsessions drain
sessiondir=*
defaultttl
[arex]
Synopsis: defaultttl = [ttl [ttr]]
Description: The ttl parameter sets the time in seconds for how long a job session directory will survive after job execution has finished. If not specified the default is 1 week. The ttr parameter sets how long information about a job will be kept after the session directory is deleted. If not specified, the ttr default is one month.
Default: 604800 2592000
Example:
defaultttl=2592000
scratchdir
[arex]
Synopsis: scratchdir = path
Description: The 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. If the variable is not set, then the session dir is not moved before execution. Don’t set this parameter unless you want to move the sessiondir to scratchdir on the node.
Default: undefined
Example:
scratchdir=/local/scratch/
tmpdir
[arex]
Synopsis: tmpdir = path
Description: A temporary directory used by A-REX.
Default: /tmp
Example:
tmpdir=/tmp
runtimedir
[arex]
Synopsis: runtimedir = path
Description: The directory which holds the additional runtimeenvironment scripts, added by system administrator. Several directories can be specified. To enable RTEs to be advertised in the information system and used during submission the arcctl tool should be used.
This option in multivalued.
Default: undefined
Example:
runtimedir=/var/spool/arc/extraruntimes
runtimedir=/cvmfs/vo/arcruntime
maxjobs
[arex]
Synopsis: maxjobs = number1 number2 number3 number4 number5
Description: 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
number5 - LRMS scripts limit (jobs in SUBMITTING and CANCELING)
A parameter set to -1 means no limit.
Default: -1 -1 -1 -1 -1
Example:
maxjobs=10000 10 2000 -1 -1
maxrerun
[arex]
Synopsis: maxrerun = number
Description: Specifies how many times job can be rerun if it failed in LRMS. This is only an upper limit, the actual rerun value is set by the user in his xrsl.
Default: 5
Example:
maxrerun=5
statecallout
[arex]
Synopsis: statecallout = state options plugin_path [plugin_arguments]
Description: Enables a callout feature
of A-REX: every time job goes to state A-REX will run plugin_path executable.
The following states are allowed:
ACCEPTED, PREPARING, SUBMIT, FINISHING, FINISHED and DELETED.
Options consist of key=value pairs separated by comma. Possible keys are:
timeoutdefines the timeout in seconds to wait for plugin execution (
timeout=can be omitted).onsuccess,onfailure,ontimeoutdefines the action that A-REX should take on successful execution (exit code 0), failed execution (exit code is not 0) or execution timeout respectively.
Possible actions are:
pass- continue executing job,
fail- cancel job,
log- write to log about the failure and continue executing job.
It is possible to use following sugstitutions to construct plugin command line:
%R- session root (value of sessiondir in[arex]block)
%C- controldir path
%U- username of mapped UNIX account
%u- numeric UID of mapped UNIX account
%g- numeric GID of mapped UNIX account
%H- home directory of mapped UNIX account as specified in/etc/passwd
%Q- default queue (seelrmsconfiguration option in[lrms]block)
%L- LRMS name (seelrmsconfiguration option in[lrms]block)
%W- ARC installation path (corresponds to theARC_LOCATIONenvironmental variable)
%F- path to configuration file for this instance
%I- job ID (substituted in runtime)
%S- job state (substituted in runtime)
Plugins included into ARC distribution:
arc-blahp-logger- write accounting log for every finished job in BLAH format
This option in multivalued.
Default: undefined
Example:
statecallout=FINISHED timeout=10,onfailure=pass /usr/libexec/arc/arc-blahp-logger -I %I -U %u -L %C/job.%I.local -P %C/job.%I.proxy
wakeupperiod
[arex]
Synopsis: wakeupperiod = time
Description:
Specifies how often A-REX checks for new jobs
arrived, job state change requests, etc. That is responsiveness of
A-REX. time is time period in seconds. Default is 3 minutes.
Usually no need to change this parameter because important state changes
are also triggering out-of-schedule checks.
Note
this parameter does not affect responsiveness of backend scripts -
especially scan-<LRMS>-job. That means that upper estimation of time for
detecting job finished executing is sum of responsiveness of backend script + wakeupperiod.
Default: 180
Example:
wakeupperiod=180
infoproviders_timelimit
[arex]
Synopsis: infoproviders_timelimit = seconds
Description: Sets the execution time limit of the infoprovider scripts started by the A-REX. Infoprovider scripts running longer than the specified timelimit are gracefully handled by the A-REX (the behaviour depends on the state of the system) Increase this value if you have many jobs in the controldir and infoproviders need more time to process.
Default: 10800
Example:
infoproviders_timelimit=10800
pidfile
[arex]
Synopsis: pidfile = path
Description: Specify location of file containing PID of daemon process.
Default: /run/arched-arex.pid
Example:
pidfile=/run/arched-arex.pid
mail
[arex]
Synopsis: mail = email_address
Description: Specifies the email address from where the notification mails are sent
Default: $VAR{user}@$VAR{[common]hostname}
Example:
mail=grid.support@somewhere.org
helper
[arex]
Synopsis: helper = user executable arguments
Description: By enabling this parameter A-REX will
run an external helper program under the user useraccount. The program will be
kept running, every time the executable finishes it will be started again.
As a limitation, currently only ‘.’ is supported as username, which corresponds
to the user running A-REX.
Default: undefined
Example:
helper=. /usr/local/bin/myutility
helperlog
[arex]
Synopsis: helperlog = path
Description: Configuration option to specify the location of log for helpers.
Default: /var/log/arc/job.helper.errors
Example:
helperlog=/var/log/arc/job.helper.errors
forcedefaultvoms
[arex]
Synopsis: forcedefaultvoms = VOMS_FQAN
Description: specify VOMS FQAN which user will be
assigned if his/her credentials contain no VOMS attributes.
To assign different values to different queues put this command
into [queue] block.
Default: undefined
Example:
forcedefaultvoms=/vo/group/subgroup
tokenscopes
[arex]
Synopsis: tokenscopes = action=scope[,action=scope[...]]
Description: assigns JWT token scopes required to perform specific actions. Multiple tokenscopes entries are allowed. Following actions are supported:
info- information about server
jobinfo- information about jobs
jobcreate- create new job or restart existing
jobcancel- cancel active jobs
jobdelete- remove jobs from server
datainfo- information about files in session directory
datawrite- create new or modify files in session directory
dataread- read files in session directory
The action=scope pairs can be replaced with identifier which works as shortcut for
multiple actions and scopes. Only currently supported shortcut identifier is wlcg (see below)
Default: undefined
Following example assigns scopes according to WLCG profile and alternatively
can be defined by tokenscopes=wlcg.
Example:
tokenscopes=jobinfo=compute.read,jobcreate=compute.create,jobcancel=compute.cancel,jobdelete=compute.cancel
tokenscopes=datainfo=compute.read,datawrite=compute.modify,dataread=compute.read
Warning
CHANGE: NEW in 7.0.0.
[arex/cache] block
This subblock enables and configures the cache functionality of A-REX.
A-REX can cache input files downloaded as part of the stage-in process of grid jobs
so that subsequent jobs requiring the same file don’t have to download it again.
The cached file will be symlinked (or copied) into the session directory of the job.
To disable to cache functionality simply comment out the [arex/cache] config block.
It is a good idea to have the cache on its own separate file system that is shared with the nodes.
For more information about the cache functionality of A-REX consult the Data Cache
technical description in the online documentation.
cachedir
[arex/cache]
Synopsis: *cachedir = cache_path [link_path]
Description: Specifies a directory to store cached
data. Multiple cache directories may be specified. Cached data will be distributed
evenly over the caches.
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.
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 link_path should specify drain,
in which case no new files will be added to the cache and files in the cache
will no longer be used.
Setting link_path to readonly ensures that no new files are written to
this cache, but existing files can still be used.
Draining and read-only caches are not cleaned by the A-REX cache cleaner.
A restart of A-REX is required when changing cache options.
This option in multivalued.
Default: undefined
Example:
cachedir=/scratch/cache
cachedir=/shared/cache /frontend/jobcache
cachedir=/fs1/cache drain
[arex/cache/cleaner] block
This subblock enables the cleaning functionality of the cache. If this block is not enabled then the cache will not be cleaned by A-REX. Either cachesize or cachelifetime should also be set to enable cleaning.
logfile
[arex/cache/cleaner]
Synopsis: logfile = path
Description: sets the filename where output of the cache-clean tool should be logged. Defaults to /var/log/arc/cache-clean.log.
Default: /var/log/arc/cache-cleaner.log
Example:
logfile=/tmp/cache-clean.log
loglevel
[arex/cache/cleaner]
Synopsis: loglevel = level
Description: specifies the level of logging by the cache-clean tool, between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=4
cachesize
[arex/cache/cleaner]
Synopsis: cachesize = max min
Description: 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.
Default: 100 100
Example:
cachesize=50 20
calculatesize
[arex/cache/cleaner]
Synopsis: calculatesize = filesystem/cachedir
Description: specifies the way the space occupied by the cache will be calculated. If set to cachedir then cache-clean calculates the size of the cache instead of using filesystem used space.
Allowed values: filesystem, cachedir
Default: filesystem
Example:
calculatesize=cachedir
cachelifetime
[arex/cache/cleaner]
Synopsis: cachelifetime = time
Description: Turns on time-based file cleaning. 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.
Default: undefined
Example:
cachelifetime=30d
cachespacetool
[arex/cache/cleaner]
Synopsis: cachespacetool = path [options]
Description: 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.
Default: undefined
Example:
cachespacetool=/etc/getspace.sh
cachecleantimeout
[arex/cache/cleaner]
Synopsis: cachecleantimeout = time
Description: 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).
Default: 3600
Example:
cachecleantimeout=10000
[arex/data-staging] block
This subblock enables and configures the data staging capabilities of A-REX. A subsystem called DTR (Data Transfer Reloaded) is responsible for collecting input data for a job before submission to the LRMS, and for staging out data after the job has finished. Automagic data staging of A-REX is a very powerful feature, disabling this functionality (by commenting out the subblock) is not recommended.
loglevel
[arex/data-staging]
Synopsis: loglevel = number
Description: Sets the log level for transfer logging in job.id.errors files,
between 0 (FATAL) and 5 (DEBUG). Default is to use value set by loglevel option in
[arex] section.
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: $VAR{[arex]loglevel}
Example:
loglevel=4
logfile
[arex/data-staging]
Synopsis: logfile = path
Description: A central file in which all data staging messages from every job will be collected and logged in addition to their job.id.errors files. If this option is not present or the path is empty the log file is not created. This file is not automatically controlled by logrotate unless you name it as /var/log/arc/datastaging.log.
Default: undefined
Example:
logfile=/var/log/arc/datastaging.log
statefile
[arex/data-staging]
Synopsis: statefile = path
Description: A file in which data staging state information (for monitoring and recovery purposes) is periodically dumped.
Default: $VAR{[arex]controldir}/dtr.state
Example:
statefile=/tmp/dtr.state
usehostcert
[arex/data-staging]
Synopsis: usehostcert = yes/no
Description: Whether the A-REX host certificate should be used for communication with remote hosts instead of the users’ proxies.
Allowed values: yes, no
Default: no
Example:
usehostcert=yes
maxtransfertries
[arex/data-staging]
Synopsis: maxtransfertries = number
Description: 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)
Default: 10
Example:
maxtransfertries=20
passivetransfer
[arex/data-staging]
Synopsis: passivetransfer = yes/no
Description: If yes, gridftp transfers are passive. Setting this option to yes can solve transfer problems caused by firewalls.
Allowed values: yes, no
Default: yes
Example:
passivetransfer=yes
globus_tcp_port_range
[arex/data-staging]
Synopsis: globus_tcp_port_range = port_range
Description: In a firewalled environment
the software which uses GSI needs to know what ports are available.
This parameter is only needed if passivetransfer=no was set.
These variable are similar to the Globus enviroment variables
GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_tcp_port_range=9000,12000
globus_udp_port_range
[arex/data-staging]
Synopsis: globus_udp_port_range = port_range
Description: In a firewalled environment
the software which uses GSI needs to know what ports are available.
This parameter is only needed if passivetransfer=no was set.
These variable are similar to the Globus enviroment variables
GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_udp_port_range=9000,12000
httpgetpartial
[arex/data-staging]
Synopsis: httpgetpartial = yes/no
Description: If yes, HTTP GET transfers may transfer data in chunks/parts. If no - data is always transfered in one piece.
Allowed values: yes, no
Default: no
Example:
httpgetpartial=no
speedcontrol
[arex/data-staging]
Synopsis: speedcontrol = min_speed min_time min_average_speed max_inactivity
Description: specifies how slow data transfer must be to trigger error. Transfer is cancelled 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 transferred for longer than max_inactivity seconds. Value of zero turns feature off.
Default: 0 300 0 300
Example:
speedcontrol=0 300 100 300
speedcontrol=
maxdelivery
[arex/data-staging]
Synopsis: maxdelivery = number
Description: 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: 10
Example:
maxdelivery=40
maxprocessor
[arex/data-staging]
Synopsis: maxprocessor = number
Description: Maximum number of concurrent files in each of the DTR internal pre- and post-processing states, eg cache check or replica resolution.
Default: 10
Example:
maxprocessor=20
maxemergency
[arex/data-staging]
Synopsis: maxemergency = number
Description: 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: 1
Example:
maxemergency=5
maxprepared
[arex/data-staging]
Synopsis: maxprepared = number
Description: 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: 200
Example:
maxprepared=250
copyurl
[arex/data-staging]
Synopsis: copyurl = url_head local_path
Description: Configures a mapping of URLs to locally-
accessible paths. If a URL starts with url_head, the local_path will be
substituted for the actual transfer. Applies to both input and output files.
Note
local_path can also be of URL type.
This option in multivalued.
Default: undefined
Example:
copyurl=gsiftp://example.org:2811/data/ /data/
copyurl=gsiftp://example2.org:2811/data/ /data/
Warning
CHANGE: MODIFIED in 7.0.0 - applies also to output files
linkurl
[arex/data-staging]
Synopsis: linkurl = url_head local_path [node_path]
Description:
Identical to copyurl, configures DTR
so that for certain URLs files won’t be downloaded or copied (in case of copyurl),
but soft-link will be created. The local_path
specifies the way to access the file from the frontend, 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. This option applies
only to input files.
This option in multivalued.
Default: undefined
Example:
linkurl=gsiftp://somewhere.org/data /data
linkurl=gsiftp://example.org:2811/data/ /scratch/data/
preferredpattern
[arex/data-staging]
Synopsis: preferredpattern = pattern
Description: 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. If an exclamation mark (!) is used at the beginning of a pattern, any replicas matching the pattern will be excluded from the sorted replicas.
Default: undefined
Example:
preferredpattern=srm://myhost.ac.uk|.uk$|ndgf.org$|badhost.org$
The following options are used to configure multi-host data staging deployment scenario. In that setup a couple of additional data staging boxes are enabled to off-load data transfers.
deliveryservice
[arex/data-staging]
Synopsis: deliveryservice = URL
Description: The URL to a remote data delivery service which can perform remote data staging.
Default: undefined
Example:
deliveryservice=https://myhost.org:443/datadeliveryservice
localdelivery
[arex/data-staging]
Synopsis: localdelivery = yes/no
Description: If any deliveryservice is defined, this option determines whether local data transfer is also performed.
Allowed values: yes, no
Default: no
Example:
localdelivery=yes
remotesizelimit
[arex/data-staging]
Synopsis: remotesizelimit = size
Description: 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.
Default: undefined
Example:
remotesizelimit=100000
[arex/ws] block
A-REX exposes a set of Web Service interfaces that can be used to create and manage jobs, obtain information about the CE and the jobs, handle delegations, access cache information, so on. Comment out this block if you don’t want to provide WS-interfaces for various A-REX functionalities.
wsurl
[arex/ws]
Synopsis: wsurl = url
Description: Specifies the base URL under which
the web service intrefaces will be available. The URL argument must be a
full URL consisting of protocol+host+port+path: e.g. https://<hostname>:<port>/<path>
Make sure the chosen port is not blocked by firewall or other security rules.
Default: https://$VAR{[common]hostname}:443/arex
Example:
wsurl=https://piff.hep.lu.se:443/arex
logfile
[arex/ws]
Synopsis: logfile = path
Description: Specify log file location for WS-interface operations.
Default: /var/log/arc/ws-interface.log
Example:
logfile=/var/log/arc/ws-interface.log
pidfile
[arex/ws]
Synopsis: pidfile = path
Description: Specify location of file containing PID of daemon process.
Default: /run/arched-arex-ws.pid
Example:
pidfile=/run/arched-arex-ws.pid
max_job_control_requests
[arex/ws]
Synopsis: max_job_control_requests = number
Description: The max number of simultaneously processed job management requests over WS interface - like job submission, cancel, status check etc.
Default: 100
Example:
max_job_control_requests=100
max_infosys_requests
[arex/ws]
Synopsis: max_infosys_requests = number
Description: The max number of simultaneously processed info requests over WS interface.
Default: 1
Example:
max_infosys_requests=1
max_data_transfer_requests
[arex/ws]
Synopsis: max_data_transfer_requests = number
Description: The max number of simultaneously processed data transfer requests over WS interface - like data staging.
Default: 100
Example:
max_data_transfer_requests=100
tlsciphers
[arex/ws]
Synopsis: tlsciphers = ciphers_list
Description: Override OpenSSL ciphers list enabled on server
Default: HIGH:!eNULL:!aNULL
Example:
tlsciphers=HIGH:!eNULL:!aNULL
tlsserverorder
[arex/ws]
Synopsis: tlsserverorder = yes
Description: Force priority order of ciphers for TLS connection to be decided on server sid
Default: no
Example:
tlsserverorder=yes
Warning
CHANGE: NEW in 7.0.0.
tlsprotocols
[arex/ws]
Synopsis: tlsprotocols = SSL/TLS protocols
Description: Specify which protocols to enable This is space separated list of values - SSLv2 SSLv3 TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Default: TLSv1.2 TLSv1.3
Example:
tlsprotocols=TLSv1.2 TLSv1.3
tlscurve
[arex/ws]
Synopsis: tlscurve = curve
Description: Specify SSL/TLS ECDH curve name (SN)
Default: secp521r1
Example:
tlscurve=secp521r1
[arex/ws/jobs] block
This block enables the job management, info query, delegation protocols through REST interface. Read http://www.nordugrid.org/arc/arc7/tech/rest/rest.html for the REST interface specification.
allownew
[arex/ws/jobs]
Synopsis: allownew = yes/no
Description: The ‘allownew’ config parameter sets if the Computing Element accepts submission of new jobs via the WS-interface. This parameter can be used to close down the CE.
Allowed values: yes, no
Default: yes
Example:
allownew=yes
allownew_override
[arex/ws/jobs]
Synopsis: allownew_override = [authgroup ...]
Description: Defines which authorization
groups are allowed to submit new jobs via the WS-interfaces
when the CE is closed with allownew=no
Note
it requires the allownew=no to be set.
This option in multivalued.
Default: undefined
Example:
allownew_override=biousers atlasusers
allownew_override=yourauthgroup
allowaccess
[arex/ws/jobs]
Synopsis: allowaccess = authgroup
Description:
Defines that the specified authgroup members
are authorized to access the ARC-CE via this interface. A related config option the
denyaccess (see below) can be used to reject access.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then no additional restrictions are applied
for authorizing user access and the interface is open to everybody authenticated.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
[arex/ws/jobs]
Synopsis: denyaccess = authgroup
Description: Defines that the specified authgroup members are REJECTED, not authorized to access the ARC-CE via this interface.
Note
a related config option the allowaccess (see above) can be used to grant access.
Multiple denyaccess and allowaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then no additional restrictions are applied
for authorizing user access and the interface is open to everybody authenticated.
Default: undefined
This option in multivalued.
Example:
denyaccess=blacklisted-users
maxjobdesc
[arex/ws/jobs]
Synopsis: maxjobdesc = size
Description: specifies maximal allowed size of job description in bytes. Default value is 5MB. Use 0 to set unlimited size.
Default: 5242880
Example:
maxjobdesc=0
[arex/ws/publicinfo] block
AREX allows access to public informaton for non-authorized users. Presence of this block enables such feature.
Warning
TODO: remove when implicitly enabled in code
allowaccess
[arex/ws/publicinfo]
Synopsis: allowaccess = authgroup
Description:
Defines that the specified authgroup members are authorized to access
public information. For more information see similar configuration option in [arex/ws/jobs] block.
Default: undefined
This option in multivalued.
Example:
allowaccess=monitors
denyaccess
[arex/ws/publicinfo]
Synopsis: denyaccess = authgroup
Description: Defines that the specified authgroup members are REJECTED, not authorized
to access public information. For more information see similar configuration option in [arex/ws/jobs] block.
Default: undefined
This option in multivalued.
Example:
denyaccess=badactors
[arex/ws/cache] block
The content of the A-REX cache can be accessed via a WS-interface. Configuring this block will allow reading cache files through a special URL. For example, if the remote file gsiftp://remotehost/file1 is stored in the cache and the WS interfaces (configured above) are available via wsurl of https://hostname:443/arex/, then the cached copy of the file can be access via the following special URL: https://hostname:443/arex/cache/gsiftp://remotehost/file1 Comment out this block if you don’t want to expose the cache content via WS-interface.
cacheaccess
[arex/ws/cache]
Synopsis: cacheaccess = rule
Description: This parameter defines the access control rules for the cache wsinterface, the rules for allowing access to files in the cache remotely through the A-REX web interface. If not set, then noone can access anything. The default is not set that means complete denial. A rule has three parts:
Regular expression defining a URL pattern
Credential attribute to match against a client’s credential
Regular expression defining a 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 matches the value required for that pattern. Possible values for credential attribute are dn, voms:vo, voms:role and voms:group.
This option in multivalued.
Default: undefined
Example:
cacheaccess=gsiftp://host.org/private/data/.* voms:vo myvo:production
cacheaccess=gsiftp://host.org/private/data/bob/.* dn /O=Grid/O=NorduGrid/.*
[arex/ws/candypond] block
The CandyPond (Cache and deliver your pilot on-demand data) A-REX Web
Service exposes various useful data-staging related operations
for the pilot job model where input data for jobs is not known until the job
is running on the worker node. This service is intended to be used by A-REX managed jobs.
This service requires the [arex/data-staging] functionality.
To use service from the job context enable EVN/CANDYPOND RTE.
The CandyPond service is available via the wsurl/candypond URL (e.g. https://hostname:443/arex/candypond)
[arex/jura] block
A-REX is responsible for collecting accounting measurements from various ARC subsystems, including batch system backends and DTR data staging.
A-REX writes all accounting data into the local accounting
database that can be queried with arcctl accounting.
JURA is the accounting record generating and reporting ARC CE module. A-REX periodically executes JURA to create usage records based on the accounting target configuration and accounting database data.
Enable and configure this block if you want to send accounting records to accounting services.
Note
a dedicated accounting target subblock is needed for every accounting
destination. The target subblocks are either of a type apel or sgas:
[arex/jura/apel:targetname] or [arex/jura/sgas:targetname].
logfile
[arex/jura]
Synopsis: logfile = path
Description: The name of the jura logfile.
Default: /var/log/arc/jura.log
Example:
logfile=/var/log/arc/jura.log
loglevel
[arex/jura]
Synopsis: loglevel = number
Description: Log level for the JURA accounting module.
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
vomsless_vo
[arex/jura]
Synopsis: vomsless_vo = voname[#voissuer]
Description: This parameter allows the sysadmin to manually assign
VOs during pubishing to jobs that were submitted with VOMS-less grid proxies.
voname is the VO name to be used in the generated records (the same as expected in voms-proxy)
optional voissuer (relevant to SGAS only) value is the VOMS server identity (certificate DN).
Default: undefined
Example:
vomsless_vo=atlas
vomsless_vo=atlas#/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch
vo_group
[arex/jura]
Synopsis: vo_group = group
Description: Adds an additional VO group attribute(s) to the usage records.
This option in multivalued.
Default: undefined
Example:
vo_group=/atlas/production
urdelivery_frequency
[arex/jura]
Synopsis: urdelivery_frequency = seconds
Description: Specifies the frequency of JURA process regular execution by the A-REX. The actual treshold of records reporting frequency can be defined on per-target basis.
Default: 3600
Example:
urdelivery_frequency=3600
x509_host_key
[arex/jura]
Synopsis: x509_host_key = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
x509_host_cert
[arex/jura]
Synopsis: x509_host_cert = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
x509_cert_dir
[arex/jura]
Synopsis: x509_cert_dir = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
[arex/jura/sgas:targetname] block
An SGAS sub-block of [arex/jura] enables and configures an SGAS accounting
server as a target destination to which JURA will send properly formatted usage records.
You need to define a separate block with a unique targetname for every SGAS target server.
Note that the block name will be used by JURA to track that latest records sent to
this targed. Be aware that if you rename the block, target will be handled as a new one.
However targeturl change will not trigger a new target handling.
targeturl
[arex/jura/sgas:targetname]
Synopsis: *targeturl = url
Description: The service endpoint URL of SGAS server.
Default: undefined
Example:
targeturl=https://grid.uio.no:8001/logger
localid_prefix
[arex/jura/sgas:targetname]
Synopsis: localid_prefix = prefix_string
Description: Sets a prefix value for the LocalJobID ur parameter for the SGAS usage records.
Default: undefined
Example:
localid_prefix=some_text_for_SGAS
vofilter
[arex/jura/sgas:targetname]
Synopsis: vofilter = vo
Description: Configures a job record filtering mechanism based on the VO attribute of the jobs. Only the matching job records, which was one of VO that you set here, will be sent to the target accounting service.
This option in multivalued.
Default: undefined
Example:
vofilter=atlas
vofilter=fgi.csc.fi
urbatchsize
[arex/jura/sgas:targetname]
Synopsis: urbatchsize = number
Description: JURA sends usage records not one-by-one, but in batches. This options sets the size of a batch. Zero value means unlimited batch size.
Default: 50
Example:
urbatchsize=80
urdelivery_frequency
[arex/jura/sgas:targetname]
Synopsis: urdelivery_frequency = seconds
Description: Add optional minimal treshold of the interval between subsequent records publishing to this target.
Note
the actual delivery interval is the value divisible by urdelivery_frequency
defined in [arex/jura] block that define the entire JURA process invocation frequency.
Default: undefined
Example:
urdelivery_frequency=3600
[arex/jura/apel:targetname] block
An APEL sub-block of [arex/jura] enables and configures an APEL accounting
server as a target destination to which JURA will send properly formatted usage records.
You need to define a separate block with a unique targetname for every APEL target server.
Note that the block name will be used by JURA to track that latest records sent to
this targed. Be aware that if you rename the block, target will be handled as a new one.
However targeturl change will not trigger a new target handling.
targeturl
[arex/jura/apel:targetname]
Synopsis: *targeturl = url
Description: The service endpoint URL of the APEL accounting server.
Default: undefined
Example:
targeturl=https://msg.argo.grnet.gr
topic
[arex/jura/apel:targetname]
Synopsis: topic = topic_name
Description: Sets the name of the APEL topic to which JURA will publish the accounting records. AMS destination topic for compute element is ‘gLite-APEL’
Default: gLite-APEL
Example:
topic=/queue/global.accounting.test.cpu.central
project
[arex/jura/apel:targetname]
Synopsis: project = project_name
Description: Sets the name of the APEL project to use.
Default: accounting
Example:
project=accounting-nl
Warning
CHANGE: NEW in 6.19.0
gocdb_name
[arex/jura/apel:targetname]
Synopsis: *gocdb_name = name
Description: Can be used to specify the GOCDB name of the resource. This value would be seen as Site attribute in the generated APEL records.
Default: undefined
Example:
gocdb_name=GRID_UIO_NO
apel_messages
[arex/jura/apel:targetname]
Synopsis: apel_messages = type
Description: Define what kind of records JURA
will send to APEL services during regular publishing process.
Possible cases are: per-job EMI CAR records (urs), APEL summary records (summaries).
APEL Sync messages are always generated.
Allowed values: urs, summaries
Default: summaries
Example:
apel_messages=urs
vofilter
[arex/jura/apel:targetname]
Synopsis: vofilter = vo
Description: Configures a job record filtering mechanism based on the VO attribute of the jobs. Only the matching job records, which was one of VO that you set here, will be sent to the target accounting service.
This option in multivalued.
Default: undefined
Example:
vofilter=atlas
vofilter=fgi.csc.fi
urbatchsize
[arex/jura/apel:targetname]
Synopsis: urbatchsize = number
Description: JURA sends usage records not one-by-one, but in batches. This options sets the size of a batch. Zero value means unlimited batch size. 500 is recommended to avoid too large messages using AMS
Default: 500
Example:
urbatchsize=500
urdelivery_frequency
[arex/jura/apel:targetname]
Synopsis: urdelivery_frequency = seconds
Description: Add optional minimal treshold of the interval between subsequent records publishing to this target.
Note
the actual delivery interval is the value divisible by urdelivery_frequency
defined in [arex/jura] block that define the entire JURA process invocation frequency.
APEL recommended value is once per day for summaries. Use smaller values for urs.
Default: 86000
Example:
urdelivery_frequency=14000
[arex/ganglia] block
This block enables the monitoring of ARC-specific metrics. Earlier versions (ARC < 6.0) relied only on the standalone tool gangliarc, ganglia is now instead integrated into ARC, and gangliarc is obsolete.
Note
AREX ganglia (as gangliarc did) depends on an existing ganglia installation, as it sends its metrics to a running gmond process.
gmetric_bin_path
[arex/ganglia]
Synopsis: gmetric_bin_path = path
Description: The path to gmetric executable.
Default: /usr/bin/gmetric
Example:
gmetric_bin_path=/usr/local/bin/gmetric
metrics
[arex/ganglia]
Synopsis: metrics = name_of_the_metrics
Description: the metrics to be monitored. metrics takes a comma-separated list of one or more of the following metrics:
staging – number of tasks in different data staging states - not yet implemented
cache – free cache space
session – free session directory space
heartbeat – last modification time of A-REX heartbeat
failedjobs – the number of failed jobs per last 100 finished
jobstates – number of jobs in different A-REX stages
all – all of the above metrics
Default: all
Allowed values: staging, cache, session, heartbeat, failedjobs, jobstates, all
Example:
metrics=all
frequency
[arex/ganglia]
Synopsis: frequency = seconds
Description: The period between each information gathering cycle, in seconds.
Default: 60
Example:
frequency=300
[infosys] block
This block enables and configures the core part of the information system. Enables the information collection to be used by other ARC components, including interfaces. Parameters in this block applies to all the infosys subsystems.
logfile
[infosys]
Synopsis: logfile = path
Description: Specifies log file location for the information provider scripts.
Default: /var/log/arc/infoprovider.log
Example:
logfile=/var/log/arc/infoprovider.log
loglevel
[infosys]
Synopsis: loglevel = number
Description: The loglevel for the infoprovider scripts (0-5). Each value corresponds to the following verbosity levels: FATAL => 0, ERROR => 1 , WARNING => 2, INFO => 3, VERBOSE => 4, DEBUG => 5
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
validity_ttl
[infosys]
Synopsis: validity_ttl = seconds
Description: The published infosys records advertise their validity e.g. how long the info should be considered up-to-date by the clients. Use this parameter to set the published validity value.
Note
different schemas may render this information differently.
Default: 10800
Example:
validity_ttl=10800
[infosys/ldap] block
This infosys subblock enables and configures the ldap hosting service for the infosys functionality. Using an LDAP server with some schema is one way to publish information about your Computing Element. Comment out this block if you don’t want to run an LDAP-based information system.
hostname
[infosys/ldap]
Synopsis: hostname = FQDN
Description: the hostname of the machine running the slapd service
will be the bind for slapd. If not present, will be taken from the [common]
Default: $VAR{[common]hostname}
Example:
hostname=my.testbox
slapd_hostnamebind
[infosys/ldap]
Synopsis: slapd_hostnamebind = string
Description: 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 parameter is already sufficient. The example below will bind the slapd process to all the network interfaces available on the server.
Default: undefined
Example:
slapd_hostnamebind=*
port
[infosys/ldap]
Synopsis: port = port_number
Description: The port on which the slapd service runs. The default infosys port is assumed to be 2135 by many clients, therefore think twice before you change it because 3rd party clients assume 2135 to be the ldap infosys port.
Default: 2135
Example:
port=2135
user
[infosys/ldap]
Synopsis: user = unix_user
Description: overwrites the unix user running the slapd.
By default the startup scripts search for well-known ldap-users like ldap or openldap
than fall-back to root if not found.
Default: undefined
Example:
user=slapd
slapd
[infosys/ldap]
Synopsis: slapd = path
Description: explicitly define the path to slapd command.
By default the startup scripts search for slapd binary in the system PATH.
Default: undefined
Example:
slapd=/usr/sbin/slapd
slapd_loglevel
[infosys/ldap]
Synopsis: slapd_loglevel = number
Description: 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.
Default: 0
Example:
slapd_loglevel=0
threads
[infosys/ldap]
Synopsis: threads = number
Description: The native slapd threads parameter, default is 32.
Default: 32
Example:
threads=128
timelimit
[infosys/ldap]
Synopsis: timelimit = seconds
Description: 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.
Default: 3600
Example:
timelimit=1800
idletimeout
[infosys/ldap]
Synopsis: idletimeout = seconds
Description: The native slapd idletimeout parameter. Maximum number of
seconds the slapd server will wait before forcibly closing idle client
connections. It’s value must be larger than the value of timelimit option.
If not set, it defaults to timelimit + 1.
Default: $EVAL{$VAR{timelimit} + 1}
Example:
idletimeout=1801
infosys_ldap_run_dir
[infosys/ldap]
Synopsis: infosys_ldap_run_dir = path
Description: The location where NorduGrid/GLUE2 LDAP ldif file will be generated, and where the fifo to sync between infoproviders and BDII will be generated.
Default: /run/arc/infosys
Example:
infosys_ldap_run_dir=/run/arc/infosys
ldap_schema_dir
[infosys/ldap]
Synopsis: ldap_schema_dir = path
Description: Allows to explicitly specify an additional 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. Normally it is sufficient to use only standard schema file locations, therefore not to set this parameter.
Default: undefined
Example:
ldap_schema_dir=/nfs/ldap/schema/
Note
the following options configure the third-party bdii ldap parameters. In 99% of cases no need to change anything and use the defaults. These variables are usually automatically set by ARC, and are here mostly for debug purposes and to tweak exotic BDII installations.
bdii_debug_level
[infosys/ldap]
Synopsis: bdii_debug_level = level
Description: Set this parameter to DEBUG to check bdii errors in bdii-update.log At the same time don’t enable slapd logs this way reducing performance issues.
Default: WARNING
Example:
bdii_debug_level=ERROR
bdii_provider_timeout
[infosys/ldap]
Synopsis: bdii_provider_timeout = seconds
Description: This variable allows a system administrator to modify the behaviour of bdii-update. This is the time BDII waits for the bdii provider scripts generated by A-REX infosys to produce their output.
Default: 10800
Example:
bdii_provider_timeout=10800
Note
BDII5 uses these 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
[infosys/ldap]
Synopsis: bdii_location = path
Description: The installation directory for the BDII.
Default: /usr
Example:
bdii_location=/usr
bdii_run_dir
[infosys/ldap]
Synopsis: bdii_run_dir = path
Description: Contains BDII pid files and slapd pid files
Default: /run/arc/bdii
Example:
bdii_run_dir=/run/arc/bdii
bdii_log_dir
[infosys/ldap]
Synopsis: bdii_log_dir = path
Description: Contains infosys logs
Default: /var/log/arc/bdii
Example:
bdii_log_dir=/var/log/arc/bdii
bdii_tmp_dir
[infosys/ldap]
Synopsis: bdii_tmp_dir = path
Description: Contains provider scripts
Default: /var/tmp/arc/bdii
Example:
bdii_tmp_dir=/var/tmp/arc/bdii
bdii_var_dir
[infosys/ldap]
Synopsis: bdii_var_dir = path
Description: Contains slapd databases
Default: /var/lib/arc/bdii
Example:
bdii_var_dir=/var/lib/arc/bdii
bdii_update_pid_file
[infosys/ldap]
Synopsis: bdii_update_pid_file = path
Description: Allows to change bdii-update pidfiles filename and location
Default: $VAR{bdii_run_dir}/bdii-update.pid
Example:
bdii_update_pid_file=/run/arc/bdii/bdii-update.pid
bdii_database
[infosys/ldap]
Synopsis: bdii_database = backend_type
Description: Configure what ldap database backend should
be used. If left undefined it will default to hdb for openldap versions
up to 2.4 and to mdb for openldap versions 2.5 and later.
Default: undefined
Example:
bdii_database=hdb
bdii_conf
[infosys/ldap]
Synopsis: bdii_conf = path
Description: Location of the bdii config file generated by ARC.
Default: $VAR{[infosys/ldap]infosys_ldap_run_dir}/bdii.conf
Example:
bdii_conf=/run/arc/infosys/bdii.conf
bdii_update_cmd
[infosys/ldap]
Synopsis: bdii_update_cmd = path
Description: path to bdii-update script
Default: $VAR{bdii_location}/sbin/bdii-update
Example:
bdii_update_cmd=/usr/sbin/bdii-update
bdii_db_config
[infosys/ldap]
Synopsis: bdii_db_config = path
Description: path to slapd database configuration file
Default: /etc/bdii/DB_CONFIG
Example:
bdii_db_config=/etc/bdii/DB_CONFIG
bdii_archive_size
[infosys/ldap]
Synopsis: bdii_archive_size = number
Description: Sets BDII_ARCHIVE_SIZE in bdii configuration file
Default: 0
Example:
bdii_archive_size=0
bdii_breathe_time
[infosys/ldap]
Synopsis: bdii_breathe_time = number
Description: Sets BDII_BREATHE_TIME in bdii configuration file
Default: 10
Example:
bdii_breathe_time=10
bdii_delete_delay
[infosys/ldap]
Synopsis: bdii_delete_delay = number
Description: Sets BDII_DELETE_DELAY in bdii configuration file
Default: 0
Example:
bdii_delete_delay=0
bdii_read_timeout
[infosys/ldap]
Synopsis: bdii_read_timeout = number
Description: Sets BDII_READ_TIMEOUT in bdii configuration file
Default: $EVAL{$VAR{bdii_provider_timeout} + $VAR{[arex]infoproviders_timelimit} + $VAR{[arex]wakeupperiod}}
Example:
bdii_read_timeout=300
Infosys Schema sub-blocks: The following infosys sub-blocks enable
information publishing according to various information schema.
In order to publish information in a certain schema, the corresponding
sub-block must be defined in addition to the schema-neutral [infosys/cluster]
and [queue:name] blocks!
Comment out a specific schema block if you don’t want to publish a specific
information schema representation.
Currently available information model (schema) sub-blocks:
[infosys/nordugrid]- The native ARC info representation of a cluster and its queues
[infosys/glue2]- The GLUE2 information model, both LDAP and XML (the latter is for WS-interface)
[infosys/glue2/ldap]- The LDAP rendering of the GLUE2 model
[infosys/nordugrid] block
Enables the publication of the NorduGrid information model in
the LDAP-based infosys. See the NORDUGRID-TECH-4 for schema definition.
The configuration block does not contain any parameter. The information tree
is populated based on the contents of the schema-neutral [infosys/cluster]
and [queue:name] blocks.
[infosys/glue2] block
Enables the publication of the GLUE2 information model both in the LDAP and
XML rendering.
The information tree is populated based on the contents of the schema-neutral
[infosys/cluster] and [queue:name] blocks and the GLUE2 specific schema sub-blocks.
admindomain_name
[infosys/glue2]
Synopsis: admindomain_name = string
Description: The Name attribute for the admindomain. 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.
Default: UNDEFINEDVALUE
Example:
admindomain_name=ARC-TESTDOMAIN
admindomain_description
[infosys/glue2]
Synopsis: admindomain_description = text
Description: The free-form description of this domain.
Default: undefined
Example:
admindomain_description=ARC test Domain
admindomain_www
[infosys/glue2]
Synopsis: admindomain_www = url
Description: The URL pointing at a site holding information about the AdminDomain.
Default: undefined
Example:
admindomain_www=http://www.nordugrid.org/
admindomain_distributed
[infosys/glue2]
Synopsis: admindomain_distributed = yes/no
Description: Set this to yes if the domain is distributed that means, if the resources belonging to the domain are considered geographically distributed.
Allowed values: yes, no
Default: no
Example:
admindomain_distributed=yes
admindomain_owner
[infosys/glue2]
Synopsis: admindomain_owner = email
Description: The contact email of a responsible person for the domain
Default: undefined
Example:
admindomain_owner=admin@nordugrid.org
admindomain_otherinfo
[infosys/glue2]
Synopsis: admindomain_otherinfo = text
Description: Free-form text that fills the OtherInfo GLUE2 field. no need to set, used only for future development.
Default: undefined
Example:
admindomain_otherinfo=Test Other info
computingservice_qualitylevel
[infosys/glue2]
Synopsis: computingservice_qualitylevel = qlevel
Description: Allows a sysadmin to define different GLUE2 QualityLevel values for A-REX. Refer to GLUE2 documentation for the qualitylevel definitions.
Allowed values: production, pre-production, testing, development
Default: production
Example:
computingservice_qualitylevel=production
[infosys/glue2/ldap] block
Enables the publication of the LDAP-rendering of the GLUE2 infomodel.
showactivities
[infosys/glue2/ldap]
Synopsis: showactivities = yes/no
Description: Enables GLUE2 ComputingActivities in the LDAP rendering
Allowed values: yes, no
Default: no
Example:
showactivities=no
[infosys/cluster] block
Information schema-neutral blocks [infosys/cluster] and [queue:NAME] contain attributes
that describe the computing cluster together with its queues. The parameters are
available for every information model/schema representation.
This block describes the cluster characteristics of a Computing Element. The information specified here is mostly used by the Infosys ARC component.
alias
[infosys/cluster]
Synopsis: alias = text
Description: An arbitrary alias name of the cluster, optional.
Default: undefined
Example:
alias=Big Blue Cluster in Nowhere
hostname
[infosys/cluster]
Synopsis: hostname = fqdn
Description: Set the FQDN of the frontend.
Default: $VAR{[common]hostname}
Example:
hostname=myhost.org
interactive_contactstring
[infosys/cluster]
Synopsis: interactive_contactstring = url
Description: the contact URL for interactive logins, set this if the cluster supports some sort of grid-enabled interactive login (gsi-ssh),
This option in multivalued.
Default: undefined
Example:
interactive_contactstring=gsissh://frontend.cluster:2200
comment
[infosys/cluster]
Synopsis: comment = text
Description: Free text field for additional comments on the cluster in a single line, no newline character is allowed!
Default: undefined
Example:
comment=This cluster is specially designed for XYZ applications: www.xyz.org
cluster_location
[infosys/cluster]
Synopsis: cluster_location = formatted_string
Description: The geographical location of the cluster, preferably specified as a postal code with a two letter country prefix
Default: undefined
Example:
cluster_location=DK-2100
cluster_owner
[infosys/cluster]
Synopsis: cluster_owner = text
Description: It can be used to indicate the owner of a resource, multiple entries can be used
This option in multivalued.
Default: undefined
Example:
cluster_owner=World Grid Project
cluster_owner=University of NeverLand
advertisedvo
[infosys/cluster]
Synopsis: advertisedvo = vo_name
Description: This attribute is used to advertise which VOs are authorized on the cluster. Add only one VO for each advertisedvo entry. Multiple VOs in the same line will cause errors. These entries will be shown in all GLUE2 AccessPolicy and MappingPolicy objects, that is, they will apply for all Endpoints(Interfaces) and all Shares(currently queues). You can override the advertisedvos per queue. The information is also published in the NorduGrid schema.
Note
it is IMPORTANT to understand that this parameter is NOT enforcing any access control, it is just for information publishing!
This option in multivalued.
Default: undefined
Example:
advertisedvo=atlas
advertisedvo=community.nordugrid.org
clustersupport
[infosys/cluster]
Synopsis: clustersupport = email
Description: This is the support email address of the resource.
This option in multivalued.
Default: undefined
Example:
clustersupport=arc.support@mysite.org
clustersupport=arc.support@myproject.org
homogeneity
[infosys/cluster]
Synopsis: homogeneity = True/False
Description: 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. False may trigger multiple GLUE2 ExecutionEnvironments to be published if applicable.
Allowed values: True, False
Default: True
Example:
homogeneity=True
architecture
[infosys/cluster]
Synopsis: architecture = string
Description: 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.
Default: adotf
Example:
architecture=adotf
opsys
[infosys/cluster]
Synopsis: opsys = formatted_string
Description: 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.
If opsys=adotf, will result in Automatic Determination of the Operating System
On The Frontend, which should only be used if the frontend has the same
OS as the nodes.
The adotf discovered values will be used to fill GLUE2 OSName, OSVersion
and OSFamily unless these values are explicitly defined for each queue.
See the [queue:queuename] block for their usage.
Note
any custom value other than adotf does NOT affect values in the GLUE2 schema.
This option in multivalued.
Default: adotf
Example:
opsys=Linux-2.6.18
opsys=glibc-2.5.58
opsys=CentOS-5.6
nodecpu
[infosys/cluster]
Synopsis: nodecpu = formatted_string
Description:
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.
Default: adotf
Example:
nodecpu=AMD Duron(tm) Processor @ 700 MHz
nodememory
[infosys/cluster]
Synopsis: nodememory = number
Description: 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.
Default: undefined
Example:
nodememory=64000
middleware
[infosys/cluster]
Synopsis: middleware = string
Description: The multivalued attribute shows the installed grid software on the cluster. Nordugrid-ARC is automatically set, no need to specify
This option in multivalued.
Default: undefined
Example:
middleware=my software
nodeaccess
[infosys/cluster]
Synopsis: nodeaccess = inbound/outbound
Description: 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.
This option in multivalued.
Default: undefined
Allowed values: inbound, outbound
Example:
nodeaccess=inbound
nodeaccess=outbound
localse
[infosys/cluster]
Synopsis: localse = url
Description: This multivalued parameter tells the BROKER that certain URLs (and
locations below that) should be considered locally available to the cluster.
This option in multivalued.
Default: undefined
Example:
localse=gsiftp://my.storage/data1/
localse=gsiftp://my.storage/data2/
cpudistribution
[infosys/cluster]
Synopsis: cpudistribution = formatted_string
Description: This is the CPU distribution over nodes
given in the form ncpu:m where:
nis the number of CPUs per machinemis the number of such machines
Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with
3 single CPU machines, 4 dual CPU machines and one machine with 4 CPUs.
Default: undefined
Example:
cpudistribution=1cpu:3,2cpu:4,4cpu:1
maxcputime
[infosys/cluster]
Synopsis: maxcputime = number
Description: This is the maximum CPU time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxcputime=300000
mincputime
[infosys/cluster]
Synopsis: mincputime = number
Description: This is the minimum CPU time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
mincputime=1200
maxwalltime
[infosys/cluster]
Synopsis: maxwalltime = number
Description: This is the maximum Wall time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxwalltime=600000
minwalltime
[infosys/cluster]
Synopsis: minwalltime = number
Description: This is the minimum Wall time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxwalltime=1800
[queue:name] block
Each grid-enabled queue on the cluster should be represented and described by a separate queue block. The queue_name should be used as a label in the block name. In case of fork, or other LRMSes with no queue names, just use any unique string. 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. This block describes the queue characteristics.
homogeneity
[queue:name]
Synopsis: homogeneity = True/False
Description: 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.
Allowed values: True, False
Default: $VAR{[infosys/cluster]homogeneity}
Example:
homogeneity=True
comment
[queue:name]
Synopsis: comment = text
Description: A free-form text field for additional comments on the queue in a single line, no newline character is allowed!
Default: undefined
Example:
comment=This queue is nothing more than a condor pool
pbs_queue_node
[queue:name]
Synopsis: pbs_queue_node = string
Description: In PBS you can assign nodes to a queue
(or a queue to nodes) by using the node property mark in PBS config.
Essentially, pbs_queue_node value is used to construct nodes= string in
PBS script, such as nodes=count:pbs_queue_node where count is taken from
the job description (1 if not specified).
This corresponds to setting the following parameter in PBS for this queue:
resources_default.neednodes = cpu_topology[:pbs_queue_node]
Setting the pbs_queue_node changes how the queue-totalcpus, user freecpus are
determined for this queue.
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
Default: undefined
Example:
pbs_queue_node=gridlong_nodes
pbs_queue_node=ppn=4:ib
sge_jobopts
[queue:name]
Synopsis: sge_jobopts = string
Description: Per-queue override of additional SGE options to be used when submitting jobs to SGE to this queue
Default: undefined
Example:
sge_jobopts=-P atlas -r yes
condor_requirements
[queue:name]
Synopsis: condor_requirements = string
Description: It may be defined for each Condor 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.
Default: $VAR{[lrms]condor_requirements}
Example:
condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)
slurm_requirements
[queue:name]
Synopsis: slurm_requirements = string
Description: Use this option to specify extra SLURM-specific parameters.
Default: undefined
Example:
slurm_requirements=memory on node >> 200
totalcpus
[queue:name]
Synopsis: totalcpus = number
Description: 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).
Default: undefined
Example:
totalcpus=32
queue-level configuration parameters: nodecpu, nodememory, architecture, opsys
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 [infosys/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.
For GLUE2, fine tune configuration of ExecutionEnvironments’ OSName, OSVersion, OSFamily
is allowed with dedicated options osname,osversion,osfamily.
nodecpu
[queue:name]
Synopsis: nodecpu = formatted_string
Description: see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]nodecpu}
Example:
nodecpu=AMD Duron(tm) Processor @ 700 MHz
nodememory
[queue:name]
Synopsis: nodememory = number
Description: see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]nodememory}
Example:
nodememory=512
defaultmemory
[queue:name]
Synopsis: defaultmemory = number
Description: The LRMS memory request of job to be set by the LRMS backend
scripts, if a user submits a job without specifying how much memory should be used.
The order of precedence is: job description -> [lrms-defaultmemory] -> [queue-defaultmemory].
This is the amount of memory (specified in MB) that a job will request.
Default: undefined
Example:
defaultmemory=512
architecture
[queue:name]
Synopsis: architecture = string
Description: see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]architecture}
Example:
architecture=adotf
opsys
[queue:name]
Synopsis: opsys = formatted_string
Description: see description at [infosys/cluster] block
If osname, osversion are present, the values in opsys are ignored.
This option in multivalued.
Default: $VAR{[infosys/cluster]opsys}
Example:
opsys=Linux-2.6.18
opsys=glibc-2.5.58
osname
[queue:name]
Synopsis: osname = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osname=Ubuntu
osversion
[queue:name]
Synopsis: osversion = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osversion=12.04
osfamily
[queue:name]
Synopsis: osfamily = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osfamily=linux
benchmark
[queue:name]
Synopsis: benchmark = name value
Description: Defines resource benchmark results for accounting and information publishing. The nodes in the same queue are assumed to be homogeneous with respect to the benchmark performance. In case of multiple benchmarks are specified:
Accounting subsystem will use ONLY THE FIRST defined benchmark.
Infosys will publish all defined benchmark values.
The values represent per-core CPU performance.
Note
APEL accounting services supports HEPscore23, HEPSPEC or Si2k benchmark types only.
This option in multivalued.
Default: HEPSPEC 1.0
Example:
benchmark=HEPscore23 16.5
benchmark=HEPSPEC 12.26
benchmark=Si2k 3065
allowaccess
[queue:name]
Synopsis: allowaccess = authgroup
Description:
Defines that the specified authgroup members
are authorized to submit jobs to this queue of ARC-CE after the user already granted access to the CE via one of the interfaces.
A related config option the denyaccess (see below) can be used to deny submission to the queue.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then the queue is accessible by everyone already authorized.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
[queue:name]
Synopsis: denyaccess = authgroup
Description: Defines that the specified authgroup members
are NOT allowed to submit jobs to this queue of ARC-CE after despite the user is already granted access to the CE via one of the interfaces.
A related config option the allowaccess (see below) can be used to grant job submission to the queue.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then the queue is accessible by everyone already authorized.
Default: undefined
This option in multivalued.
Example:
denyaccess=blacklisted-for-the-queue
advertisedvo
[queue:name]
Synopsis: advertisedvo = vo_name
Description: This attribute is used to advertise
which VOs are authorized on the [queue:name] of the cluster.
Add only one VO for each advertiseddvo entry. Multiple VOs in the same line
will cause errors.
These entries will be shown in the MappingPolicy objects, that is,
they will apply for the Shares that corresponds to the queue.
The information is also published in the NorduGrid schema.
Note
if you have also configured advertisedvo in the [infosys/cluster] block,
the result advertised VOs per queue will override whatever is defined in [infosys/cluster] block!
Note
it is IMPORTANT to understand that this parameter is NOT enforcing any access control, it is just for information publishing!
This option in multivalued.
Default: $VAR{[infosys/cluster]advertisedvo}
Example:
advertisedvo=atlas
advertisedvo=community.nordugrid.org
maxslotsperjob
[queue:name]
Synopsis: maxslotsperjob = number
Description: This GLUE2 specific parameter configures the MaxSlotsPerJob value on a particular queue. This value is usually generated by LRMS infocollectors, but there are cases in which a system administrator might like to tweak it. Default is to publish what is returned by the LRMS, and if nothing is returned, NOT to publish the MaxSlotsPerJob attribute. If a system administrator sets the value here, that value will be published instead, regardless of what the LRMS returns. Each LRMS might have a different meaning for this value.
Default: undefined
Example:
maxslotsperjob=5
forcedefaultvoms
[queue:name]
Synopsis: forcedefaultvoms = VOMS_FQAN
Description: specify VOMS FQAN which user will be assigned if his/her credentials contain no VOMS attributes.
Default: $VAR{[arex]forcedefaultvoms}
Example:
forcedefaultvoms=/vo/group/subgroup
maxcputime
[queue:name]
Synopsis: maxcputime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
maxcputime=300000
mincputime
[queue:name]
Synopsis: mincputime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
mincputime=1200
maxwalltime
[queue:name]
Synopsis: maxwalltime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
maxwalltime=600000
minwalltime
[queue:name]
Synopsis: minwalltime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
minwalltime=1800
[datadelivery-service] block
This block configures and enables the data delivery service. This service is intended to off-load data-staging from A-REX and usually deployed on one or more separate machines.
This service can also act as an independent data transfers service that case it would require an inteligent data manager that could replace A-REX’s intelligence.
transfer_dir
[datadelivery-service]
Synopsis: *transfer_dir = path
Description: The directori(es) on the DDS host in which the service is allowed to read and write. When DDS is used as a remote transfer service assisting A-REX then this is usually one or more cache and/or session directories shared as a common mount with A-REX.
This option in multivalued.
Default: undefined
Example:
transfer_dir=/shared/arc/cache
transfer_dir=/shared/arc/session
hostname
[datadelivery-service]
Synopsis: hostname = FQDN
Description: The hostname of the machine on which DDS service runs.
Default: $EXEC{hostname -f}
Example:
hostname=localhost
port
[datadelivery-service]
Synopsis: port = port
Description: Port on which service listens
Default: 443
Example:
port=8443
pidfile
[datadelivery-service]
Synopsis: pidfile = path
Description: pid file of the daemon
Default: /run/arched-datadelivery-service.pid
Example:
pidfile=/run/arched-datadelivery-service.pid
logfile
[datadelivery-service]
Synopsis: logfile = path
Description: log file of the daemon
Default: /var/log/arc/datadelivery-service.log
Example:
logfile=/tmp/delivery.log
loglevel
[datadelivery-service]
Synopsis: loglevel = level
Description: set loglevel of the data delivery service between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5
Default: 3
Example:
loglevel=4
user
[datadelivery-service]
Synopsis: user = username
Description: Overwrites the user under which the service runs. The default is the user starting the service. DDS is very limited if not run as root.
Default: undefined
Example:
user=ddsuser
secure
[datadelivery-service]
Synopsis: secure = yes/no
Description: Set to no if the service should run without a host certificate. In this case
the corresponding deliveryservice option in the [arex/data-staging] A-REX configuration block
should use http rather than https URLs.
Allowed values: yes, no
Default: yes
Example:
secure=no
allowed_ip
[datadelivery-service]
Synopsis: *allowed_ip = ip
Description: IP address authorized to access service. Normally this is the A-REX host IP. By default the delivery service listens on all available interfaces, so if both IPv4 and IPv6 are enabled on this and the A-REX host, remember to add both A-REX host IPs here.
This option in multivalued.
Default: undefined
Example:
allowed_ip=192.0.2.1
allowed_ip=2001:db8:85a3::8a2e:370:7334
allowed_dn
[datadelivery-service]
Synopsis: allowed_dn = DN
Description: DN authorized to access service. This option restricts access to specified DNs (of the users who submit jobs to A-REX). It is only effective if secure=yes.
This option in multivalued.
Default: undefined
Example:
allowed_dn=/O=Grid/O=Big VO/CN=Main Boss
x509_host_key
[datadelivery-service]
Synopsis: x509_host_key = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
x509_host_cert
[datadelivery-service]
Synopsis: x509_host_cert = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
x509_cert_dir
[datadelivery-service]
Synopsis: x509_cert_dir = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
[custom:name] block
This optional block is for those who wish to include non-ARC configuration
in arc.conf. Custom blocks will be ignored by ARC components including the
configuration validator. Any non-ARC configuration which is not in a
custom block will be flagged as an error by the validator and A-REX will not
start.
Removed blocks and options
This is the arc.conf DELETED file that contains all the configuration blocks
and options that have been DELETED in ARC version 7.0.0 and later
[deleted:blocks] block
Following blocks and corresponding functionality are removed complemete from ARC7 release and should be cleaned up from previous ARC6 configuration:
[authtokens] (always enabled in ARC7)
[lrms/ssh]
[arex/ws/publicinfo] (always enabled in ARC7)
[arex/ws/argus]
[gridftpd]
[gridftpd/jobs]
[gridftpd/filedir]
[infosys/glue1]
[infosys/glue1/site-bdii]
[acix-scanner]
[acix-index]
[userlist:name]
[nordugridmap]
Note
Options marked DELETED without stating a version were deleted in version 7.0.0 compared to the latest ARC6 supported configuration.
[authgroup:groupname] block
userlist
[authgroup:groupname]
Synopsis: userlist = ulist_name [ulist_name ...]
Description:
Match user belonging to ulist_name defined
in an earlier [userlist:ulist_name] block. Multiple userlist names are allowed for
this rule.
This is sequenced option.
Default: undefined
Example:
userlist=biousers
Warning
CHANGE: DELETED
[arex/data-staging] block
use_remote_acix
[arex/data-staging]
Synopsis: use_remote_acix = URL
Description: If configured then the ARC Cache Index, available at the URL, 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 variable.
Default: undefined
Example:
use_remote_acix=https://cacheindex.ndgf.org:6443/data/index
Warning
CHANGE: DELETED