####################################################################
##
## This is the arc.conf REFERENCE DOCUMENT defining the configuration blocks and
## configuration options for the ARC services.
##
##! WARNING: this file will not work as a configuration template!
##! NEVER USE THIS DOCUMENT AS A CONFIGURATION FILE!
##!
##! WARNING: this file is machine-read to extract defaults and render the web version!
##! PLEASE BE CAREFUL EDITING IT AND FOLLOW THE MARKUP!
##!
##! Reference markup used by web-rendering:
##!   - Text delimited by double-quotes("text") or square breaets([text]) is rendered monospace.
##!   - Lines starded with "##!" are ignored in the web-rendering.
##!   - There should be an empty line before new option definition.
##!   - Lines started with "## " are rendered as an option desciption text.
##!   - Lines started with "#text" are rendered as an example blocks.
##!   - Line ending with colon followed by space (": ") starts monospace block.
##!     Content on the block should be indented by spaces. The block ends when indent ends.
##!   - Line ending with colon (":") start the list. Following lines should be indented and prefixed
##!     either with dash ("-") or numbers. Another option is to use definition lists with
##!     further indented description text (see for example "voms_processing")
##!   - Line started with "NOTE that" rendered as Note block. If you need multiline indent
##!     subsequent lines with 2 spaces.
##!   - Lines started with "CHANGE" or "TODO" are rendered as corresponding Warning blocks.
##!   - Special keywords "## multivalued", "## sequenced' and "## allowedvalues:" are parsed.
##
## The arc.conf configuration file consists of the following blocks: 
##
##  [common]
##  [authgroup:groupname]
##  [mapping]
##  [lrms]
##  [arex]
##  [arex/cache]
##  [arex/cache/cleaner]
##  [arex/data-staging]
##  [arex/ws]
##  [arex/ws/jobs]
##  [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]
##  [infosys/accesscontrol]
##  [queue:name]
##  [datadelivery-service]
##  [custom:blockname]
##
## If "arc.conf.d" directory exists next to "arc.conf" file, all files in this directory
## ending with ".conf" will be read in alphabetical order and their content merged with
## the arc.conf file.
##
## 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 that quotes around the configuration value(s) must NOT be used.
## NOTE that 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:
##   a) All trailing and leading spaces on each confiuration line are stripped and ignored.
##      This aplies both to block headers and block content.
##   b) All spaces around the "=" sign in "option=value" kind of string (after 'a' is applied)
##      are stripped and ignored. For example line "hostname = myhost.info" is treated as
##      identical to "hostname=myhost.info".
##   c) In block headers of [keyword] kind (after 'a' is applied) no additional spaces are allowed
##      around "keyword" and inside "keyword".
##   d) In block headers of [keyword:identifier] kind (after 'a' is applied) no additional spaces
##      are allowed around "keyword" and inside both "keyword" and "identifier".
##      The spaces ARE allowed around  "identifier" part 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. 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.
##
## ARC configuration parser makes sure that blocks are AUTOMATICALLY RE-ORDERED in accordance to the
## defaults-defined order of block keywords. Several blocks with the same keyword but different
## identifiers (named blocks) will be sorted in according to read-out order.
##
## When the same block is defined in the several files in "arc.conf.d" directory, configuration options
## inside this block are appended in the read-out order. Complex logic (like overrides) is not supported.
## It is advised to use "arcctl config dump" to verify the desired running configuration after merge.
##
## 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 = value [optional values] - 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 "#"
## multivalued
## allowedvalues: 12 34 56
## default: 34
#example_config_option=56
###########################################################################


### The [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.
#[common]

## hostname = string - The FQDN of the frontend on which the ARC services are deployed.
## default: $EXEC{hostname -f}
#hostname=myhost.org

## http_proxy = url - 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
#http_proxy=proxy.mydomain.org:3128

### X509 related parameters
## x509_host_key = path - 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
#x509_host_key=/etc/grid-security/hostkey.pem

## x509_host_cert = path - 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
#x509_host_cert=/etc/grid-security/hostcert.pem

## x509_cert_policy = keyword  - layout of CA certificates.
## The following keywords are supported: grid, system, any. 
## This variable defines if the server is going to use Globus (igtf) layout of
## CA certificates, just let OpenSSL handle that (system), or allow both options (any). 
## default: grid
#x509_cert_policy=grid

## x509_cert_dir = path  - 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
#x509_cert_dir=/etc/grid-security/certificates

### VOMS related parameters
## x509_voms_dir = path - the path to the directory containing *.lsc files
## needed for verification of VOMS service signature in the proxy-certificate.
## default: /etc/grid-security/vomsdir
#x509_voms_dir=/etc/grid-security/vomsdir

## voms_processing = keyword - Defines how to behave if errors in VOMS AC processing detected.
## The following keywords are supported:
##   "relaxed"
##       use everything that passed validation.
##   "standard"
##       same as relaxed but fail if parsing errors took place and
##       VOMS extension is marked as critical. This is a default.
##   "strict"
##       fail if any parsing error was discovered
##   "noerrors"
##       fail if any parsing or validation error happened.
## allowedvalues: relaxed standard strict noerrors
## default: standard
#voms_processing=strict
##
##
### end of the [common] block ##############################################


### The [authgroup:groupname] blocks ##########################
## 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.
#[authgroup:prodtesters]

## subject = certificate_subject - Rule to match specific subject of user's
## X.509 certificate. No masks, patterns and regular expressions are allowed.
## sequenced
## default: undefined
#subject=/O=Grid/O=Big VO/CN=Main Boss
#subject=/O=Grid/O=Big VO/CN=Deputy Boss

## file = path - 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.
## sequenced
## default: undefined
#file=/etc/grid-security/local_users
#file=/etc/grid-security/atlas_users

## voms = vo group role capabilities - Match VOMS attribute in user's credential.
## Use "*" to match any value.
## sequenced
## default: undefined
#voms=nordugrid Guests * *
#voms=atlas students prodman *

## authgroup = group_name [group_name ...] - 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".
## sequenced
## default: undefined
#authgroup=local_admins
#authgroup=local_admins remote_users

## plugin = timeout path [arg1 [arg2 [arg3...]]] - 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 audiences extracted from JWT token (here second # is audience's index starting from 0)
##  - "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.
## sequenced
## default: undefined
#plugin=10 /usr/libexec/arc/arc-lcas %D %P liblcas.so /usr/lib64 /etc/lcas/lcas.db
## CHANGE: NEW environment variables in 7.0.0.

## authtokens = subject issuer audience scope group - Match OIDC token claims.
## Use "*" to match any value.
## sequenced
## default: undefined
#authtokens=e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 https://wlcg.cloud.cnaf.infn.it/ * * *

## authtokensgen = logical expression - 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
##  - "" - strings can be enclosed in quotes to allow special symbols in strings, to in include " in such string use \"
## All empty spaces are optional. This functionality is experimental.
## sequenced
## default: undefined
#authtokensgen = (sub=e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0) & (iss="https://wlcg.cloud.cnaf.infn.it/") & !(email~".*\.evil\.com")
## CHANGE: NEW in 7.0.0

## all = yes|no - Matches any or none user identity. For "yes" argument this rule
## always returns positive match. For "no" it is always no match.
## sequenced
## default: undefined
#all=yes
##
##
### end of the [authgroup:name] blocks ###############################


### The [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 "authgroup" members are mapped
##   - policy 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 "authgroup"
##     specified in the rule (can be redefined with "policy_on_nogroup" option)
##   - processing STOPS if identity of user match "authgroup" specified in the mapping rule.
##     Depend on whether this mapping rule returns valid UNIX identity the processing can be
##     redefined with "policy_on_map" and "policy_on_nomap" options.
##
## Policy can be redefined at the any point of configuration sequence and affects
## all mapping rules defined after the polcy rule.
##
## NOTE that if mapping process STOPS and there is still no local UNIX identity
##   identified, the user running A-REX will be used.
## NOTE that when grid-identity is mapped to "root" account - request processing fails implicitely.
##
##
#[mapping]

## map_to_user = authgroup_name unixname[:unixgroup] - 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).
## sequenced
## default: undefined
#map_to_user=authgroupA nobody:nobody

## map_to_pool = authgroup_name directory - 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:
##   "timeout"
##      Define the timeout in days (default is "10") after which the UNIX
##      account can be reassigned to another user if not used. The "0" value
##      means no lease expiration.
## sequenced
## default: undefined
#map_to_pool=atlas /etc/grid-security/pool/atlas

## map_with_file = authgroup_name file - 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.
## sequenced
## default: undefined
#map_with_file=authgroupB /etc/grid-security/grid-mapfile

## map_with_plugin = authgroup_name timeout plugin [arg1 [arg2 [...]]] - 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.
##
## The environment variables passed to the 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 audiences extracted from JWT token (here second # is audience's index starting from 0)
##  - "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 LCMAPS plugin that can be enabled with the corresponfing
## configuration. For more information about configuring LCMAPS refer to
## 'Using LCAS/LCMAPS' document.
## sequenced
## default: undefined
#map_with_plugin=authgroupC 30 /usr/libexec/arc/arc-lcmaps %D %P liblcmaps.so /usr/lib64 /etc/lcmaps/lcmaps.db arc

## policy_on_nomap = continue/stop - 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.
## sequenced
## default: undefined
## allowedvalues: continue stop
#policy_on_nomap=continue

## policy_on_map = continue/stop - 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).
## sequenced
## default: undefined
## allowedvalues: continue stop
#policy_on_map=stop

## policy_on_nogroup = continue/stop - 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.
## sequenced
## default: undefined
## allowedvalues: continue stop
#policy_on_nogroup=stop
##
##
### end of the [mapping] block ##############################################


### The [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 primarily supports SLURM, Condor and its own fork LRMS flavours, as listed below. 
## Please note that the various PBS flavours have best effort community support only.
#[lrms]

## *lrms = lrmstype [defaultqueue] - 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.
##
## For lrmstype, the following values can be chosen:
##   - fork    - simple forking of jobs to the same node as the server
##   - condor  - Condor
##   - pbs     - PBS (covers Torque and other old PBS flavours e.g. OpenPBS, older PBSPro, etc)
##   - pbspro  - Altair PBS Professional
##   - slurm   - SLURM
##
## 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.
##
## allowedvalues: fork sge condor pbs pbspro lsf ll slurm boinc
## default: undefined
## mandatory
#lrms=pbspro gridlong
#lrms=slurm

## lrmsconfig = text - 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
#lrmsconfig=single job per processor

## benchmark = string - 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
#benchmark=HEPSPEC 12.26
## CHANGE: MODIFIED in 7.0.0

## defaultmemory = number - 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
#defaultmemory=512

## nodename = path - 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 that this way of getting WN hostname will be used only in case of
##   particular LRMS backend had no native LRMS-defined way.
## default: undefined
#nodename=/bin/hostname -s

## gnu_time = path - 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
#gnu_time=/usr/bin/time

## movetool = comand - 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
#movetool=rsync -av

### PBS options: set these only in case of lrms=pbs
## pbs_bin_path = path - The path to the qstat,pbsnodes,qmgr etc PBS binaries,
## no need to set if PBS is not used
## default: /usr/bin
#pbs_bin_path=/usr/bin

## pbs_log_path = path - The path of the PBS server logfiles which are used by A-REX to determine
## whether a PBS job is completed. If not specified, A-REX will use qstat for that.
## default: /var/spool/pbs/server_logs
#pbs_log_path=/var/spool/pbs/server_logs

## pbs_dedicated_node_string = string - 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
#pbs_dedicated_node_string=gridnode

### Condor options: set these only in case of lrms=condor
## condor_bin_path = path - Path to Condor binaries. Must be set if Condor
## is used.
## default: /usr/bin
#condor_bin_path=/opt/condor/bin

## condor_config = path - 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
#condor_config=/opt/condor/etc/condor_config

## condor_rank = ClassAd_float_expression - 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
#condor_rank=(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000

## condor_requirements = string - 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
#condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)

### SLURM options: set these only in case of lrms=slurm
## slurm_bin_path = path - Path to SLURM binaries, must be set if installed
## outside of normal PATH
## default: /usr/bin
#slurm_bin_path=/usr/bin

## slurm_wakeupperiod = numsec - How long should infosys wait before querying SLURM
## for new data (seconds)
## default: 30
#slurm_wakeupperiod=15

## slurm_use_sacct = yes/no - Indicates whether ARC should use sacct instead of scontrol
## to obtain information about finished jobs
## allowedvalues: yes no
## default: yes
#slurm_use_sacct=yes

## slurm_requirements = string - Use this option to specify extra SLURM-specific parameters.
## default: undefined
#slurm_requirements=mincpus=8

## slurm_query_retries = number - 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
#slurm_query_retries=3
##
##
### end of [lrms] block #####################################################


### The [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...
#[arex]

## user = user[:group] - 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
#user=grid:grid

## norootpower = yes|no - 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.
## allowedvalues: yes no
## default: no
#norootpower=yes

## delegationdb = db_name - specify which DB to use to store delegations.
## Currently supported db_names are bdb and sqlite
## default: sqlite
#delegationdb=sqlite

## watchdog = yes/no - Specifies if additional watchdog processes is spawned to restart
## main process if it is stuck or dies.
## allowedvalues: yes no
## default: no
#watchdog=no

## loglevel = level - Set loglevel of the arched daemon hosting A-REX service
## between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
## allowedvalues: 0 1 2 3 4 5 FATAL ERROR WARNING INFO VERBOSE DEBUG
## default: 3
#loglevel=3

## logfile = path - 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
#logfile=/var/log/arc/arex.log

## joblog = path - 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
#joblog=

## fixdirectories = yes/missing/no - Specifies during startup A-REX should
## create all directories needed for it operation and set suitable default
## permissions. If "no" is specified then A-REX does nothing to prepare its
## operational environment. In case of "missing" A-REX only creates and
## sets permissions for directories which are not present yet.  For "yes"
## all directories are created and permissions for all used directories are
## set to default safe values.
## allowedvalues: yes missing no
## default: yes
#fixdirectories=yes

## controldir = path - 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 and for
## storing many small files. The directory is not needed on the nodes.
## default: /var/spool/arc/jobstatus
#controldir=/var/spool/arc/jobstatus

## sessiondir = path [drain] - 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.
## multivalued
## default: /var/spool/arc/sessiondir
#sessiondir=/scratch/arcsessions drain
#sessiondir=*

## defaultttl = [ttl [ttr]] - 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
#defaultttl=2592000

## shared_filesystem = yes/no - Specifies if computing nodes can access folders mounted
## with protocols like NFS with the same pathnames as the frontend.
## NOTE that the default 'yes' assumes that the paths to the session directories
##   are the same on both frontend and nodes.
##   If these paths are not the same, then one should set the "scratchdir" option.
## The option changes the "RUNTIME_NODE_SEES_FRONTEND" variable in the submission scripts.
## allowedvalues: yes no
## default: yes
#shared_filesystem=yes

## scratchdir = path - 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
#scratchdir=/local/scratch/

## shared_scratch = path - The path on frontend where scratchdir can be found. If
## defined should contain the path corresponding to that set in scratchdir as
## seen on the frontend machine. Sets the environment variable
## RUNTIME_FRONTEND_SEES_NODE.
## default: undefined
#shared_scratch=/mnt/scratch

## tmpdir = path - A temporary directory used by A-REX.
## default: /tmp
#tmpdir=/tmp

## runtimedir = path - 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.
## multivalued
## default: undefined
#runtimedir=/var/spool/arc/extraruntimes
#runtimedir=/cvmfs/vo/arcruntime

## maxjobs = number1 number2 number3 number4 number5 - 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
#maxjobs=10000 10 2000 -1 -1

## maxrerun = number - 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
#maxrerun=5

## statecallout = state options plugin_path [plugin_arguments] - 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, INLRMS, FINISHING, FINISHED and DELETED.
## Options consist of "key=value" pairs separated by comma. Possible keys are:
##   "timeout"
##      defines the timeout in seconds to wait for plugin execution ("timeout=" can be omitted).
##   "onsuccess", "onfailure", "ontimeout"
##      defines 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 (see "lrms" configuration option in [lrms] block)
##   - "%L" - LRMS name (see "lrms" configuration option in [lrms] block)
##   - "%W" - ARC installation path (corresponds to the "ARC_LOCATION" environmental 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
## multivalued
## default: undefined
#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 = time - 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 that 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
#wakeupperiod=180

## infoproviders_timelimit = seconds - 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
#infoproviders_timelimit=10800

## pidfile = path - Specify location of file containing PID of daemon process.
## default: /run/arched-arex.pid
#pidfile=/run/arched-arex.pid

## mail = email_address - Specifies the email address from where the notification mails are sent
## default: $VAR{user}@$VAR{[common]hostname}
#mail=grid.support@somewhere.org

## helper = user executable arguments - 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
#helper=. /usr/local/bin/myutility

## helperlog = path - Configuration option to specify the location of log for helpers.
## default: /var/log/arc/job.helper.errors
#helperlog=/var/log/arc/job.helper.errors

## forcedefaultvoms = VOMS_FQAN - 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
#forcedefaultvoms=/vo/group/subgroup

## usetokenforvoms = yes/no - Whether claims from WLCG complaint tokens 
## to be used as VOMS attributes.
## allowedvalues: yes no
## default: no
#usetokenforvoms=yes
## CHANGE: NEW in 7.0.0

## tokenscopes = action=scope[,action=scope[...]] - 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".
#tokenscopes=jobinfo=compute.read,jobcreate=compute.create,jobcancel=compute.cancel,jobdelete=compute.cancel
#tokenscopes=datainfo=compute.read,datawrite=compute.modify,dataread=compute.read
## CHANGE: NEW in 7.0.0

## authtokenmap = claim:attrname[,...] - map your token claim key to a custom attribute name to be used in accounting
## multivalued
## default: name:name,email:email,preferred_username:username,wlcg_groups:group
#authtokenmap=sub:user
## CHANGE: NEW in 7.0.0
##
##
### end of the [arex] block ###################################


### The [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.
#[arex/cache]

## *cachedir = cache_path [link_path] - 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.
## multivalued
## default: undefined
#cachedir=/scratch/cache
#cachedir=/shared/cache /frontend/jobcache
#cachedir=/fs1/cache drain
##
##
### end of the [arex/cache] #############################################


### The [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.
#[arex/cache/cleaner]

## logfile = path - 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
#logfile=/tmp/cache-clean.log

## loglevel = level - specifies the level of logging by the cache-clean
## tool, between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
## allowedvalues: 0 1 2 3 4 5 FATAL ERROR WARNING INFO VERBOSE DEBUG
## default: 3
#loglevel=4

## cachesize = max min - Specifies high and low watermarks for space used
## by cache, as a percentage of the space on the file system on which
## the cache directory is located. When the max is exceeded, files will
## be deleted to bring the used space down to the min level. It is a
## good idea to have the cache on its own separate file system.
## default: 100 100
#cachesize=50 20

## calculatesize = filesystem/cachedir - 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.
## allowedvalues: filesystem cachedir
## default: filesystem
#calculatesize=cachedir

## cachelifetime = time - 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
#cachelifetime=30d

## cachespacetool = path [options] - specifies an alternative tool to "df" that
## cache-clean should use to obtain space information on the cache file system.
## The output of this command must be "total_bytes used_bytes". The cache
## directory is passed as the last argument to this command.
## default: undefined
#cachespacetool=/etc/getspace.sh

## cachecleantimeout = time - the timeout in seconds for running the cache-clean
## tool. If using a large cache or slow file system this value can be
## increased to allow the cleaning to complete. Defaults to 3600 (1 hour).
## default: 3600
#cachecleantimeout=10000
##
##
### end of the [arex/cache/cleaner] #############################################


### The [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.
#[arex/data-staging]

## loglevel = number - 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.
## allowedvalues: 0 1 2 3 4 5 FATAL ERROR WARNING INFO VERBOSE DEBUG
## default: $VAR{[arex]loglevel}
#loglevel=4

## logfile = path  - 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
#logfile=/var/log/arc/datastaging.log

## statefile = path - A file in which data staging state information
## (for monitoring and recovery purposes) is periodically dumped.
## default: $VAR{[arex]controldir}/dtr.state
#statefile=/tmp/dtr.state

## usehostcert = yes/no - Whether the A-REX host certificate should be used for
## communication with remote hosts instead of the users' proxies.
## allowedvalues: yes no
## default: no
#usehostcert=yes

## maxtransfertries = number - 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
#maxtransfertries=20

## passivetransfer = yes/no - If yes, gridftp transfers are passive. Setting
## this option to yes can solve transfer problems caused by firewalls.
## allowedvalues: yes no
## default: yes
#passivetransfer=yes

## globus_tcp_port_range = port_range - 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
#globus_tcp_port_range=9000,12000

## globus_udp_port_range = port_range - 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
#globus_udp_port_range=9000,12000

## httpgetpartial = yes/no - If yes, HTTP GET transfers may transfer data in
## chunks/parts. If no - data is always transfered in one piece.
## allowedvalues: yes no
## default: no
#httpgetpartial=no

## speedcontrol = min_speed min_time min_average_speed max_inactivity - 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
#speedcontrol=0 300 100 300
#speedcontrol=

## maxdelivery = number - 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
#maxdelivery=40

## maxprocessor = number - Maximum number of concurrent files in each of the DTR
## internal pre- and post-processing states, eg cache check or replica resolution.
## default: 10
#maxprocessor=20

## maxemergency = number - 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
#maxemergency=5

## maxprepared = number - 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
#maxprepared=250

## sharepolicy = grouping - Defines the mechanism to be used for the
## grouping of the job transfers. DTR assigns the transfers to shares, so that those shares
## can be assigned to different priorities.
## Possible values for "grouping" are dn, voms:vo, voms:role and voms:group:
##   dn
##     each job is assigned to a share based on the DN of the user sumbitting the job.
##   voms:vo
##     each job is assigned to a share based on the VO specified in the proxy.
##   voms:role
##     each job is assigned to a share based on the role specified in the first attribute
##     found in the proxy.
##   voms:group
##     each job is assigned to a share based on the group specified in the first attribute
##     found in the proxy.
## In case of the voms schemes, if the proxy is not a VOMS proxy, then a default share is used.
## If sharepolicy is not set then the client-defined priority is applied.
## default: undefined
#sharepolicy=voms:role

## sharepriority = share priority - Defines a share with a fixed priority,
## different from the default (50). Priority is an integer between 1 (lowest) and 100 (highest).
## multivalued
## default: undefined
#sharepriority=myvo:students 20
#sharepriority=myvo:production 80

## copyurl = url_head local_path - 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 that "local_path" can also be of URL type.
## multivalued
## default: undefined
#copyurl=gsiftp://example.org:2811/data/ /data/
#copyurl=gsiftp://example2.org:2811/data/ /data/
## CHANGE: MODIFIED in 7.0.0 - applies also to output files

## linkurl = url_head local_path [node_path] - 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.
## multivalued
## default: undefined
#linkurl=gsiftp://somewhere.org/data /data
#linkurl=gsiftp://example.org:2811/data/ /scratch/data/

## preferredpattern = pattern - specifies a preferred pattern on which
## to sort multiple replicas of an input file. It consists of one or
## more patterns separated by a pipe character (|) listed in order of
## preference. Replicas will be ordered by the earliest match. If the
## dollar character ($) is used at the end of a pattern, the pattern
## will be matched to the end of the hostname of the replica. 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
#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 = URL - The URL to a remote data delivery service which can perform remote
## data staging.
## multivalued
## default: undefined
#deliveryservice=https://myhost.org:443/datadeliveryservice

## localdelivery = yes/no - If any deliveryservice is defined, this option determines
## whether local data transfer is also performed.
## allowedvalues: yes no
## default: no
#localdelivery=yes

## remotesizelimit = size - 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
#remotesizelimit=100000
##
##
### end of the [arex/data-staging] block ############################


### The [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.
#[arex/ws]

## wsurl = url - 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
#wsurl=https://piff.hep.lu.se:443/arex

## logfile = path - Specify log file location for WS-interface operations.
## default: /var/log/arc/ws-interface.log
#logfile=/var/log/arc/ws-interface.log

## pidfile = path - Specify location of file containing PID of daemon process.
## default: /run/arched-arex-ws.pid
#pidfile=/run/arched-arex-ws.pid

## max_job_control_requests = number - The max number of simultaneously processed job management
## requests over WS interface - like job submission, cancel, status check etc.
## default: 100
#max_job_control_requests=100

## max_infosys_requests = number - The max number of simultaneously processed info
## requests over WS interface.
## default: 1
#max_infosys_requests=1

## max_data_transfer_requests = number - The max number of simultaneously processed data transfer
## requests over WS interface - like data staging.
## default: 100
#max_data_transfer_requests=100

## tlsciphers = ciphers_list - Override OpenSSL ciphers list enabled on server
## default: HIGH:!eNULL:!aNULL
#tlsciphers=HIGH:!eNULL:!aNULL

## tlsserverorder = yes - Force priority order of ciphers for TLS connection to be decided on server sid
## default: no
#tlsserverorder=yes
## CHANGE: NEW in 7.0.0

## tlsprotocols = SSL/TLS protocols - 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
#tlsprotocols=TLSv1.2 TLSv1.3

## tlscurve = curve - Specify SSL/TLS ECDH curve name (SN)
## default: secp521r1
#tlscurve=secp521r1
##
##
### end of the [arex/ws] block ##############################


### The [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.
#[arex/ws/jobs]

## allownew = yes/no - 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.
## allowedvalues: yes no
## default: yes
#allownew=yes

## allownew_override = [authgroup ...]  - Defines which authorization
## groups are allowed to submit new jobs via the WS-interfaces
## when the CE is closed with "allownew=no"
## NOTE that it requires the "allownew=no" to be set.
## multivalued
## default: undefined
#allownew_override=biousers atlasusers
#allownew_override=yourauthgroup

## allowaccess = authgroup - 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
## multivalued
#allowaccess=biousers
#allowaccess=atlasusers

## denyaccess = authgroup - Defines that the specified authgroup members
## are REJECTED, not authorized to access the ARC-CE via this interface. 
## NOTE that 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
## multivalued
#denyaccess=blacklisted-users

## maxjobdesc = size - specifies maximal allowed size of job description
## in bytes. Default value is 5MB. Use 0 to set unlimited size.
## default: 5242880
#maxjobdesc=0
##
##
### end of the [arex/ws/jobs] block ##############################


### The [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.
#[arex/ws/cache]

## cacheaccess = rule - 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:
##  1. Regular expression defining a URL pattern
##  2. Credential attribute to match against a client's credential
##  3. 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.
## multivalued
## default: undefined
#cacheaccess=gsiftp://host.org/private/data/.* voms:vo myvo:production
#cacheaccess=gsiftp://host.org/private/data/bob/.* dn /O=Grid/O=NorduGrid/.*
##
##
### end of the [arex/ws/cache] block ####################


### The [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/ws/candypond]
##
##
### end of the [arex/ws/candypond] block ####################


### The [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 that 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]".
##
#[arex/jura]

## logfile = path - The name of the jura logfile.
## default: /var/log/arc/jura.log
#logfile=/var/log/arc/jura.log

## loglevel = number - Log level for the JURA accounting module.
## allowedvalues: 0 1 2 3 4 5 FATAL ERROR WARNING INFO VERBOSE DEBUG
## default: 3
#loglevel=3

## vomsless_vo = [authgroup ]voname[#voissuer] - 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).
## If authgroup is specified then this parameter is applied only if user belongs to specified authgroup.
## default: undefined
#vomsless_vo=atlas
#vomsless_vo=atlas#/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch
#vomsless_vo=atlasgroup atlas

## vo_group = group - Adds an additional VO group attribute(s) to the usage records.
## multivalued
## default: undefined
#vo_group=/atlas/production

## urdelivery_frequency = seconds - 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
#urdelivery_frequency=3600

## x509_host_key = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_host_key}
#x509_host_key=/etc/grid-security/hostkey.pem

## x509_host_cert = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_host_cert}
#x509_host_cert=/etc/grid-security/hostcert.pem

## x509_cert_dir = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_cert_dir}
#x509_cert_dir=/etc/grid-security/certificates
##
##
### end of the [arex/jura] block ########################################

### The [arex/jura/sgas:targetname] blocks ##############################
## 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.
#
#[arex/jura/sgas:neic_sgas]

## *targeturl = url - The service endpoint URL of SGAS server.
## default: undefined
#targeturl=https://grid.uio.no:8001/logger

## localid_prefix = prefix_string - Sets a prefix value for the LocalJobID ur parameter
## for the SGAS usage records.
## default: undefined
#localid_prefix=some_text_for_SGAS

## vofilter = vo - 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.
## multivalued
## default: undefined
#vofilter=atlas
#vofilter=fgi.csc.fi

## urbatchsize = number - 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
#urbatchsize=80

## urdelivery_frequency = seconds - Add optional minimal treshold
## of the interval between subsequent records publishing to this target.
## NOTE that 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
#urdelivery_frequency=3600
##
##
### end of the [arex/jura/sgas:targetname] blocks ########################

### The [arex/jura/apel:targetname] blocks ###############################
## 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.
#[arex/jura/apel:egi_prod_apel]

## *targeturl = url - The service endpoint URL of the APEL accounting server.
## default: undefined
#targeturl=https://msg.argo.grnet.gr

## topic = topic_name - 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
#topic=/queue/global.accounting.test.cpu.central

## project = project_name - Sets the name of the APEL project to use.
## default: accounting
#project=accounting-nl

## *gocdb_name = name - 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
#gocdb_name=GRID_UIO_NO

## apel_messages = type - 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")
## or APEL summary records v0.4 ("summaries-v04")
## APEL Sync messages are always generated.
## allowedvalues: urs summaries summaries-v04
## default: summaries
#apel_messages=urs

## vofilter = vo - 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.
## multivalued
## default: undefined
#vofilter=atlas
#vofilter=fgi.csc.fi

## urbatchsize = number - 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
#urbatchsize=500

## urdelivery_frequency = seconds - Add optional minimal
## treshold of the interval between subsequent records publishing to this target.
## NOTE that 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
#urdelivery_frequency=14000
##
##
### end of the [arex/jura/apel:targetname] blocks ############################

### The [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 that AREX ganglia (as gangliarc did) depends on an existing ganglia installation,
##   as it sends its metrics to a running gmond process.
#[arex/ganglia]

## gmetric_bin_path = path - The path to gmetric executable.
## default: /usr/bin/gmetric
#gmetric_bin_path=/usr/local/bin/gmetric

## metrics = name_of_the_metrics - 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
## allowedvalues: staging cache session heartbeat failedjobs jobstates all
#metrics=all

## frequency = seconds - The period between each information gathering cycle, in seconds.
## default: 60
#frequency=300
##
##
### end of the [arex/ganglia] block ##############


### The [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.
#[infosys]

## logfile = path - Specifies log file location for the information
## provider scripts.
## default: /var/log/arc/infoprovider.log
#logfile=/var/log/arc/infoprovider.log

## loglevel = number - 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
## allowedvalues: 0 1 2 3 4 5 FATAL ERROR WARNING INFO VERBOSE DEBUG
## default: 3
#loglevel=3

## validity_ttl = seconds - 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 that different schemas may render this information differently.
## default: 10800
#validity_ttl=10800
##
##
### end of [infosys] block #################################################


### The [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.
#[infosys/ldap]

## hostname = FQDN - 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}
#hostname=my.testbox

## slapd_hostnamebind = string - 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
#slapd_hostnamebind=*

## port = port_number - 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
#port=2135

## user = unix_user - 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
#user=slapd

## slapd = path - explicitly define the path to slapd command.
## By default the startup scripts search for "slapd" binary in the system PATH.
## default: undefined
#slapd=/usr/sbin/slapd

## slapd_loglevel = number - 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
#slapd_loglevel=0

## threads = number - The native slapd threads parameter, default is 32.
## default: 32
#threads=128

## timelimit = seconds - 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
#timelimit=1800

## idletimeout = seconds - 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}
#idletimeout=1801

## infosys_ldap_run_dir = path - 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
#infosys_ldap_run_dir=/run/arc/infosys

## ldap_schema_dir = path - 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
#ldap_schema_dir=/nfs/ldap/schema/

## NOTE that 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 = level - 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
#bdii_debug_level=ERROR

## bdii_provider_timeout = seconds - 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
#bdii_provider_timeout=10800

## NOTE that 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 = path - The installation directory for the BDII.
## default: /usr
#bdii_location=/usr

## bdii_run_dir = path - Contains BDII pid files and slapd pid files
## default: /run/arc/bdii
#bdii_run_dir=/run/arc/bdii

## bdii_log_dir = path - Contains infosys logs
## default: /var/log/arc/bdii
#bdii_log_dir=/var/log/arc/bdii

## bdii_tmp_dir = path - Contains provider scripts
## default: /var/tmp/arc/bdii
#bdii_tmp_dir=/var/tmp/arc/bdii

## bdii_var_dir = path - Contains slapd databases
## default: /var/lib/arc/bdii
#bdii_var_dir=/var/lib/arc/bdii

## bdii_update_pid_file = path  - Allows to change bdii-update
## pidfiles filename and location
## default: $VAR{bdii_run_dir}/bdii-update.pid
#bdii_update_pid_file=/run/arc/bdii/bdii-update.pid

## bdii_database = backend_type - 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
#bdii_database=hdb

## bdii_conf = path - Location of the bdii config file generated by ARC.
## default: $VAR{[infosys/ldap]infosys_ldap_run_dir}/bdii.conf
#bdii_conf=/run/arc/infosys/bdii.conf

## bdii_update_cmd = path - path to bdii-update script
## default: $VAR{bdii_location}/sbin/bdii-update
#bdii_update_cmd=/usr/sbin/bdii-update

## bdii_db_config = path - path to slapd database configuration file
## default: /etc/bdii/DB_CONFIG
#bdii_db_config=/etc/bdii/DB_CONFIG

## bdii_archive_size = number - Sets BDII_ARCHIVE_SIZE in bdii configuration file
## default: 0
#bdii_archive_size=0

## bdii_breathe_time = number - Sets BDII_BREATHE_TIME in bdii configuration file
## default: 10
#bdii_breathe_time=10

## bdii_delete_delay = number - Sets BDII_DELETE_DELAY in bdii configuration file
## default: 0
#bdii_delete_delay=0

## bdii_read_timeout = number - Sets BDII_READ_TIMEOUT in bdii configuration file
## default: $EVAL{$VAR{bdii_provider_timeout} + $VAR{[arex]infoproviders_timelimit} + $VAR{[arex]wakeupperiod}}
#bdii_read_timeout=300
##
##
### end of the [infosys/ldap] sub-block ########################################

## 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

### The [infosys/nordugrid] schema sub-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/nordugrid]
##
##
### end of the [infosys/nordugrid] schema block ########################


### The [infosys/glue2] schema sub-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.
#[infosys/glue2]

## admindomain_name = string - 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
#admindomain_name=ARC-TESTDOMAIN

## admindomain_description = text - The free-form description of this domain.
## default: undefined
#admindomain_description=ARC test Domain

## admindomain_www = url - The URL pointing at a site holding information about the AdminDomain.
## default: undefined
#admindomain_www=http://www.nordugrid.org/

## admindomain_distributed = yes/no - Set this to yes if the domain is distributed
## that means, if the resources belonging to the domain
## are considered geographically distributed.
## allowedvalues: yes no
## default: no
#admindomain_distributed=yes

## admindomain_owner = email - The contact email of a responsible person for the domain
## default: undefined
#admindomain_owner=admin@nordugrid.org

## admindomain_otherinfo = text - Free-form text that fills the OtherInfo GLUE2 field.
## no need to set, used only for future development.
## default: undefined
#admindomain_otherinfo=Test Other info

## computingservice_qualitylevel = qlevel - Allows a sysadmin to define different 
## GLUE2 QualityLevel values for A-REX.
## Refer to GLUE2 documentation for the qualitylevel definitions.
## allowedvalues: production pre-production testing development
## default: production
#computingservice_qualitylevel=production
##
##
### end of the [infosys/glue2] schema block ########################

### The [infosys/glue2/ldap] schema sub-block ###########################
## Enables the publication of the LDAP-rendering of the GLUE2 infomodel.
#[infosys/glue2/ldap]

## showactivities = yes/no - Enables GLUE2 ComputingActivities in the LDAP rendering
## allowedvalues: yes no
## default: no
#showactivities=no
##
##
### end of the [infosys/glue2/ldap] schema sub-block ###########################

### The [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.
#[infosys/cluster]

## alias = text - An arbitrary alias name of the cluster, optional.
## default: undefined
#alias=Big Blue Cluster in Nowhere

## hostname = fqdn - Set the FQDN of the frontend.
## default: $VAR{[common]hostname}
#hostname=myhost.org

## interactive_contactstring = url - the contact URL for interactive logins, set this
## if the cluster supports some sort of grid-enabled interactive login (gsi-ssh),
## multivalued
## default: undefined
#interactive_contactstring=gsissh://frontend.cluster:2200
## CHANGE: REMOVED obsoleted in ARC 7.0.0

## comment = text - Free text field for additional comments on the cluster in a single
## line, no newline character is allowed!
## default: undefined
#comment=This cluster is specially designed for XYZ applications: www.xyz.org

## cluster_location = formatted_string - The geographical location of the cluster, preferably
## specified as a postal code with a two letter country prefix
## default: undefined
#cluster_location=DK-2100

## cluster_owner = text - It can be used to indicate the owner of a resource, multiple
## entries can be used
## multivalued
## default: undefined
#cluster_owner=World Grid Project
#cluster_owner=University of NeverLand

## advertisedvo = vo_name - 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 that it is IMPORTANT to understand that this parameter is NOT enforcing any
##   access control, it is just for information publishing!
## multivalued
## default: undefined
#advertisedvo=atlas
#advertisedvo=community.nordugrid.org

## clustersupport = email - This is the support email address of the resource.
## multivalued
## default: undefined
#clustersupport=arc.support@mysite.org
#clustersupport=arc.support@myproject.org

## homogeneity = True/False - 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.
## allowedvalues: True False
## default: True
#homogeneity=True

## architecture = string - 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
#architecture=adotf

## opsys = formatted_string - 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 that any custom value other than "adotf" does NOT affect values in the GLUE2 schema.
## multivalued
## default: adotf
#opsys=Linux-2.6.18
#opsys=glibc-2.5.58
#opsys=CentOS-5.6

## nodecpu = formatted_string - 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
#nodecpu=AMD Duron(tm) Processor @ 700 MHz

## nodememory = number - 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
#nodememory=64000

## middleware = string - The multivalued attribute shows the installed grid software on
## the cluster. Nordugrid-ARC is automatically set, no need to specify
## multivalued
## default: undefined
#middleware=my software

## nodeaccess = inbound/outbound - 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.
## multivalued
## default: undefined
## allowedvalues: inbound outbound
#nodeaccess=inbound
#nodeaccess=outbound

## localse = url - This multivalued parameter tells the BROKER that certain URLs (and
## locations below that) should be considered "locally" available to the cluster.
## multivalued
## default: undefined
#localse=gsiftp://my.storage/data1/
#localse=gsiftp://my.storage/data2/

## cpudistribution = formatted_string - This is the CPU distribution over nodes
## given in the form "ncpu:m" where:
##   "n" is the number of CPUs per machine
##   "m" is the number of such 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
#cpudistribution=1cpu:3,2cpu:4,4cpu:1

## maxcputime = number - 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
#maxcputime=300000

## mincputime = number - 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
#mincputime=1200

## maxwalltime = number - 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
#maxwalltime=600000

## minwalltime = number - 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
#maxwalltime=1800
##
##
### end of the [infosys/cluster] block #####################


### The [infosys/accesscontrol] block ################################
## AREX allows to control access to public informaton for non-authorized users.
## If this block contains no entries public information is available to anyone.
#[infosys/accesscontrol]
## CHANGE: NEW in 7.0.0

## allowaccess = authgroup - Defines that only the specified authgroup members are authorized to access
## public information. For more information see similar configuration option in [arex/ws/jobs] block.
## default: undefined
## multivalued
#allowaccess=monitors

## denyaccess = authgroup - 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
## multivalued
#denyaccess=badactors
##
##
### end of the [infosys/accesscontrol] block ####################


### The [queue:name] blocks #######################################
## 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.
#[queue:gridlong]

## homogeneity = True/False - 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.
## allowedvalues: True False
## default: $VAR{[infosys/cluster]homogeneity}
#homogeneity=True

## comment = text - A free-form text field for additional comments on the queue in a single
## line, no newline character is allowed!
## default: undefined
#comment=This queue is nothing more than a condor pool

## pbs_queue_node = string - 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
#pbs_queue_node=gridlong_nodes
#pbs_queue_node=ppn=4:ib

## sge_jobopts = string - Per-queue override of additional SGE options to be used when
## submitting jobs to SGE to this queue
## default: undefined
#sge_jobopts=-P atlas -r yes

## condor_requirements = string - 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}
#condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)

## slurm_requirements = string - Use this option to specify extra SLURM-specific parameters.
## default: undefined
#slurm_requirements=memory on node >> 200

## totalcpus = number - 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
#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 = formatted_string - see description at [infosys/cluster] block
## default: $VAR{[infosys/cluster]nodecpu}
#nodecpu=AMD Duron(tm) Processor @ 700 MHz

## nodememory = number - see description at [infosys/cluster] block
## default: $VAR{[infosys/cluster]nodememory}
#nodememory=512

## defaultmemory = number - 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
#defaultmemory=512

## architecture = string - see description at [infosys/cluster] block
## default: $VAR{[infosys/cluster]architecture}
#architecture=adotf

## opsys = formatted_string - see description at [infosys/cluster] block
## If osname, osversion are present, the values in opsys are ignored.
## multivalued
## default: $VAR{[infosys/cluster]opsys}
#opsys=Linux-2.6.18
#opsys=glibc-2.5.58

## osname = string - 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
#osname=Ubuntu

## osversion = string - 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
#osversion=12.04

## osfamily = string - 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
#osfamily=linux

## benchmark = name value - 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 that APEL accounting services supports "HEPscore23", "HEPSPEC" or "Si2k" benchmark types only.
## multivalued
## default: HEPSPEC 1.0
#benchmark=HEPscore23 16.5
#benchmark=HEPSPEC 12.26
#benchmark=Si2k 3065

## allowaccess = authgroup - 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
## multivalued
#allowaccess=biousers
#allowaccess=atlasusers

## denyaccess = authgroup - 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
## multivalued
#denyaccess=blacklisted-for-the-queue

## advertisedvo = vo_name - 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 that 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 that it is IMPORTANT to understand that this parameter is NOT enforcing any
##   access control, it is just for information publishing!
## multivalued
## default: $VAR{[infosys/cluster]advertisedvo}
#advertisedvo=atlas
#advertisedvo=community.nordugrid.org

## maxslotsperjob = number - 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
#maxslotsperjob=5

## forcedefaultvoms = VOMS_FQAN - specify VOMS FQAN which user will be
## assigned if his/her credentials contain no VOMS attributes.
## default: $VAR{[arex]forcedefaultvoms}
#forcedefaultvoms=/vo/group/subgroup

## maxcputime = number - This value overrides the one defined in
## the [infosys/cluster] block. See description in that block.
## default: undefined
#maxcputime=300000

## mincputime = number - This value overrides the one defined in
## the [infosys/cluster] block. See description in that block.
## default: undefined
#mincputime=1200

## maxwalltime = number - This value overrides the one defined in
## the [infosys/cluster] block. See description in that block.
## default: undefined
#maxwalltime=600000

## minwalltime = number - This value overrides the one defined in
## the [infosys/cluster] block. See description in that block.
## default: undefined
#minwalltime=1800
##
##
### end of the [queue:name] blocks ########################


### The [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.
##
#[datadelivery-service]

## *transfer_dir = path - 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.
## multivalued
## default: undefined
#transfer_dir=/shared/arc/cache
#transfer_dir=/shared/arc/session

## hostname = FQDN - The hostname of the machine on which DDS service runs.
## default: $EXEC{hostname -f}
#hostname=localhost

## port = port - Port on which service listens
## default: 443
#port=8443

## pidfile = path - pid file of the daemon
## default: /run/arched-datadelivery-service.pid
#pidfile=/run/arched-datadelivery-service.pid

## logfile = path - log file of the daemon
## default: /var/log/arc/datadelivery-service.log
#logfile=/tmp/delivery.log

## loglevel = level - set loglevel of the data delivery service between 0
## (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
## allowedvalues: 0 1 2 3 4 5
## default: 3
#loglevel=4

## user = username - 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
#user=ddsuser

## secure = yes/no - 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.
## allowedvalues: yes no
## default: yes
#secure=no

## *allowed_ip = ip - 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.
## multivalued
## default: undefined
#allowed_ip=192.0.2.1
#allowed_ip=2001:db8:85a3::8a2e:370:7334

## allowed_dn = DN - 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.
## multivalued
## default: undefined
#allowed_dn=/O=Grid/O=Big VO/CN=Main Boss

### X509 related parameters
## x509_host_key = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_host_key}
#x509_host_key=/etc/grid-security/hostkey.pem

## x509_host_cert = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_host_cert}
#x509_host_cert=/etc/grid-security/hostcert.pem

## x509_cert_dir = path - Optional parameter to overwrite [common] block values.
## default: $VAR{[common]x509_cert_dir}
#x509_cert_dir=/etc/grid-security/certificates
##
##
### end of the [datadelivery-service] block ##############


### The [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.
#[custom:mytool]
##
##
### end of the [custom] block #################################################
