ARC Configuration Reference Document
General configuration structure
This is the arc.conf REFERENCE DOCUMENT defining the configuration blocks and
configuration options for the ARC services.
The arc.conf configuration file consists of the following blocks:
[common]
[authgroup:groupname]
[mapping]
[authtokens]
[lrms]
[lrms/ssh]
[arex]
[arex/cache]
[arex/cache/cleaner]
[arex/data-staging]
[arex/ws]
[arex/ws/jobs]
[arex/ws/publicinfo]
[arex/ws/cache]
[arex/ws/candypond]
[arex/ws/argus]
[arex/jura]
[arex/jura/sgas:targetname]
[arex/jura/apel:targetname]
[arex/jura/archiving] (removed in 6.8.0)
[arex/ganglia]
[gridftpd]
[gridftpd/jobs]
[gridftpd/filedir]
[infosys]
[infosys/ldap]
[infosys/nordugrid]
[infosys/glue2]
[infosys/glue2/ldap]
[infosys/glue1]
[infosys/glue1/site-bdii]
[infosys/cluster]
[queue:name]
[datadelivery-service]
[acix-scanner]
[acix-index]
[userlist:name]
[nordugridmap]
[custom:blockname]
[block]
A block configures an ARC service, a service interface, a utility or a subsystem.
Enabling (turning on) a functionality, a service or an interface requires the presence of the
appropriate configuration block. To disable a service or an interface, simply delete or
comment out the related arc.conf block (you may need to rerun the corresponding startup script).
The [common] block is mandatory even if not a single option is specified within. The presence of
the block turns on the default values for the configuration options within the block.
As an example, in order to set up a minimalistic ARC CE offering no external interfaces
you need to configure at least the [common], [mapping], [arex], [lrms],
[infosys] and [queue:name] blocks.
As another example, an ARC-based data offloader would require the [common] and the
[datadelivery-service] blocks.
A block is identified by its block header. A block header may consist of
keywords and optionally block identifiers. Keywords may be separated by /
and used to label subblocks (e.g. [arex/jura]), while block identifiers
are separated by : from keywords. For example, in the [queue:short]
block header queue is a keyword while short is an identifier, e.g. the name of the queue.
Block headers must be UNIQUE.
A block starts with a unique [keyword:identifier] blockheader and ends where the next block
starts, that is at the next [blockheader] directive.
A block may have sub-blocks e.g. the various interfaces of the AREX service are configured via
sub-blocks (e.g. [arex/ws]). When a sub-block is enabled then the corresponding parent block must
also appear in the arc.conf file.
Configuration blocks contain (config option, config value) pairs following the syntax in single line:
config_option=value element [optional value element]
Note
quotes around the configuration value(s) must NOT be used any longer.
Note
the arc.conf is CASE-SENSITIVE!
Space handling syntax in arc.conf
for configuration lines:
(stripped space)option(stripped space)=(stripped space)value(saved space)(value)(stripped space)
and for block headers:
[keyword:(stripped space)space is NOT allowed within identifier(stripped space)]
Detailed textual definition:
All trailing and leading spaces on each confiuration line are stripped and ignored. This aplies both to block headers and block content.
All spaces around the
=sign inoption=valuekind of string (after ‘a’ is applied) are stripped and ignored. For example linehostname = myhost.infois treated as identical tohostname=myhost.info.In block headers of
[keyword]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand insidekeyword.In block headers of
[keyword:identifier]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand inside bothkeywordandidentifier. The spaces ARE allowed aroundidentifierpart and stripped and ignored.
Mandatory configuration options are indicated by an asterix prefix to the
option name e.g: *mandatory_configoption. Mandatory options with undefined values
will result in service stop during the startup process.
Each of the configuration options have well-defined default that is specified in this reference
file. The default can take either a pre-set value, a special substitution or the keyword
undefined. Configuration options within an enabled block take their default values in case
they are missing (or commented out). Configuration parameters with undefined defaults takes
no values. Furthermore, configuration options within disabled blocks takes no values either.
Configuration blocks are ORDER-DEPENDENT. To be safe, please use the order as indicated in the list of blocks in this reference. This is especially important for configuration blocks related to authorization and mapping. The order dependency is also honoured within options inside a certain block.
This means for instance that configuration blocks related to authorization MUST appear before used in
the blocks such as [mapping], [arex/ws/jobs] or [gridftp/jobs]. Order dependency within a block is
for instance important when it comes to authorization decisions, as the first matching rule is used.
For more details see the specific block reference.
Below we give a detailed description of all the configuration options of the
different configuration blocks. Every configuration option is described
in a dedicated paragraph with the following reference syntax notation.
This file is parsed at buildtime to assist in configuration default parsing and validation script
and so it is important that it follows the agreed syntax: For each block or
option please add explanatory text with two ## followed by a space at the
beginning of the line and then an example with a single # and no spaces at
the beginning of the line.
example_config_option
Synopsis: example_config_option = value [optional values]
Description: Here comes the explanation
of the config option. Mandatory configuration options are indicated by an asterix prefix to the
option name e.g: *mandatory_configoption vs. optional_configoption.
The explanation can be followed by the special keywords in a separate line:
multivalued- used to indicate that config option can be specified multiple times. This forms a set of values for the same configuration option irrespective of lines order.
sequenced- used to indicate that config option is a part of the sequence and its effect on configuration depends on the lines order. Sequenced option can be specified several times in the configuration sequence independently.
Missing such keywords means the config option can only occur once in the arc.conf.
By default the arc.conf config options are optional and single-valued.
For some config options only a fix set of values are allowed. These are
listed in a separate line after the allowedvalues keyword.
The default of every config option is explicitly given in the default: line.
Default can be a pre-set value, a substitution or the undefined keyword.
The last line of the paragraph is always a valid example preceded by a single #
This option in multivalued.
Allowed values: 12, 34, 56
Default: 34
Example:
example_config_option=56
Configuration blocks and options
[common] block
Common configuration affecting all ARC components, usually related to networking or security
or service behaviour. This block is mandatory.
The common block options may be overridden by the specific sections of the components later.
The [common] always appears at the beginning of the config file. The config options set within
this block are available for all the other blocks thus shared by the different components of ARC.
hostname
Synopsis: hostname = string
Description: The FQDN of the frontend on which the ARC services are deployed.
Default: $EXEC{hostname -f}
Example:
hostname=myhost.org
Warning
CHANGE: MODIFIED semantics in 6.0.0, not mandatory any longer.
http_proxy
Synopsis: http_proxy = url
Description: The http proxy server. This setting affects all client HTTP(s) requests that initiated by ARC core services, including data staging, SAML communications, and pushing SGAS accounting records. This variable is similar to setting the ARC_HTTP_PROXY environmental variable.
Default: undefined
Example:
http_proxy=proxy.mydomain.org:3128
Warning
CHANGE: MOVED in 6.0.0 from the old [grid-manager] block.
x509_host_key
Synopsis: x509_host_key = path
Description:
(previously x509_user_key) Server credential location.
Sets the full path to the host private key.
These variables are similar to the GSI enviroment variable X509_USER_KEY
If indicated, the variable can be set individually for each service/component in the
corresponding block.
Default: /etc/grid-security/hostkey.pem
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
(previously x509_user_cert) Server credential location. Sets the full
path to the host public certificate.
These variables are similar to the GSI environment variable X509_USER_CERT
If indicated, the variable can be set individually for each service/component in the
corresponding block.
Default: /etc/grid-security/hostcert.pem
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Location of trusted CA certificates.
This variable is similar to the GSI enviroment variable X509_CERT_DIR
If indicated, the variable can be set individually for each service/component in the
corresponding block.
Default: /etc/grid-security/certificates
Example:
x509_cert_dir=/etc/grid-security/certificates
x509_voms_dir
Synopsis: x509_voms_dir = path
Description: the path to the directory containing *.lsc files needed for verification of VOMS service signature in the proxy-certificate.
Default: /etc/grid-security/vomsdir
Example:
x509_voms_dir=/etc/grid-security/vomsdir
voms_processing
Synopsis: voms_processing = keyword
Description: Defines how to behave if errors in VOMS AC processing detected. The following keywords are supported:
relaxeduse everything that passed validation.
standardsame as relaxed but fail if parsing errors took place and VOMS extension is marked as critical. This is a default.
strictfail if any parsing error was discovered
noerrorsfail if any parsing or validation error happened.
Allowed values: relaxed, standard, strict, noerrors
Default: standard
Example:
voms_processing=strict
[authgroup:groupname] block
These configuration blocks contain authorization rules.
An [authrgroup:groupname] block always defines a group of users where members of the group are
those who satisfy the authorization rules.
The rules within the block determine which user belong to the authgroup.
Then, access control and identity mapping of ARC services are implemented
via associating a authgroup with an interface, queue or a mapping rule
using one of the allowaccess, denyaccess or [mapping] block parameters.
For more info please read Security Framework of ARC at
http://www.nordugrid.org/documents/arc-security-documentation.pdf
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.
Warning
CHANGE: RENAMED the block in 6.0.0.
subject
Synopsis: subject = certificate_subject
Description: Rule to match specific subject of user’s X.509 certificate. No masks, patterns and regular expressions are allowed.
This is sequenced option.
Default: undefined
Example:
subject=/O=Grid/O=Big VO/CN=Main Boss
subject=/O=Grid/O=Big VO/CN=Deputy Boss
file
Synopsis: file = path
Description: Processes a list of DNs stored in an external file one per line
in grid-mapfile format (see map_with_file from [mapping] block, unixname is ignored)
and adds those to the authgroup.
This is sequenced option.
Default: undefined
Example:
file=/etc/grid-security/local_users
file=/etc/grid-security/atlas_users
Warning
CHANGE: MODIFIED semantics in 6.0.0. The external file should only contain DNs, no complex rules. No need to change the code.
voms
Synopsis: voms = vo group role capabilities
Description:
Match VOMS attribute in user’s credential.
Use * to match any value.
This is sequenced option.
Default: undefined
Example:
voms=nordugrid Guests * *
voms=atlas students prodman *
authgroup
Synopsis: authgroup = group_name [group_name ...]
Description: (previously group) Match user already belonging to one
of specified authgroups. The authgroup referred here must be defined earlier in
arc.conf configuration file. Multiple authgroup names may be specified for this rule.
That allows creating hierarchical structure of authorization groups like
all-atlas are those which are atlas-users and atlas-admins.
This is sequenced option.
Default: undefined
Example:
authgroup=local_admins
authgroup=local_admins remote_users
Warning
CHANGE: RENAMED in 6.0.0.
userlist
Synopsis: userlist = ulist_name [ulist_name ...]
Description:
(previously vo) Match user belonging to ulist_name defined
in an earlier [userlist:ulist_name] block. Multiple userlist names are allowed for this rule.
This is sequenced option.
Default: undefined
Example:
userlist=biousers
Warning
CHANGE: RENAMED in 6.0.0.
plugin
Synopsis: plugin = timeout path [arg1 [arg2 [arg3...]]]
Description: Run external executable or function from shared library. Rule is matched if plugin returns 0. Any other return code or timeout are treated as rule not matched. In arguments following substitutions are supported:
%D- subject of certicate
%P- path to proxy
ARC ships with LCAS plugin that can be enabled with following plugin configuration. For more information about configuring LCAS refer to ‘Using LCAS/LCMAPS’ document.
This is sequenced option.
Default: undefined
Example:
plugin=10 /usr/libexec/arc/arc-lcas %D %P liblcas.so /usr/lib64 /etc/lcas/lcas.db
authtokens
Synopsis: authtokens = subject issuer audience scope group
Description: Match OIDC token claims.
Use * to match any value.
This is sequenced option.
Default: undefined
Example:
authtokens=e83eec5a-e2e3-43c6-bb67-df8f5ec3e8d0 https://wlcg.cloud.cnaf.infn.it/ * * *
Warning
CHANGE: INTRODUCED in 6.6.0.
all
Synopsis: all = yes|no
Description:
Matches any or none user identity. For yes argument this rule
always returns positive match. For no it is always no match.
This is sequenced option.
Default: undefined
Example:
all=yes
Warning
CHANGE: MODIFIED options in 6.0.0.
[mapping] block
This block defines the grid-identity to local UNIX identity mapping rules used by various ARC components.
Rules in the [mapping] block are processed IN A SEQUENCE in line order of the
configuration file (from top to bottom).
There are two kind of rules:
mapping rules that defines how the particular
authgroupmembers are mappedpolicy rules that modifies the mapping rules sequence processing
Default policy for mapping rules processing is:
processing CONTINUES to the next rule if identity of user DO NOT match
authgroupspecified in the rule (can be redefined withpolicy_on_nogroupoption)processing STOPS if identity of user match
authgroupspecified in the mapping rule. Depend on whether this mapping rule returns valid UNIX identity the processing can be redefined withpolicy_on_mapandpolicy_on_nomapoptions.
Policy can be redefined at the any point of configuration sequence and affects all mapping rules defined after the polcy rule.
Note
if mapping process STOPS and there is still no local UNIX identity identified, the user running A-REX will be used.
Note
when grid-identity is mapped to root account - request processing fails implicitely.
Warning
CHANGE: NEW block in 6.0.0.
map_to_user
Synopsis: map_to_user = authgroup_name unixname[:unixgroup]
Description:
the users that belongs to
specified authgroup are mapped to unixname local UNIX account that may be
optionally followed by a unixgroup UNIX group.
In case of non-existing unixname account the mapping rule treated as a rule that
did not returned mapped identity (nomap).
This is sequenced option.
Default: undefined
Example:
map_to_user=authgroupA nobody:nobody
map_to_pool
Synopsis: map_to_pool = authgroup_name directory
Description: the user that belong to specified
authgroup is assigned one of the local UNIX accounts in the pool. Account names that
are part of this pool are stored line-by-line in the pool file inside the directory.
The directory also contains information about used accont names stored in another files.
If there are no more available accounts in the defined pool for mapping then
accounts not used for a configurable time period may be reassigned.
The pool behaviour, including account reuse, is configureable with the opional
directory/config file that has INI syntax (line-by-line key=value).
Possible keys of the config file are:
timeoutDefine the timeout in days (default is
10) after which the UNIX account can be reassigned to another user if not used. The0value means no lease expiration.
This is sequenced option.
Default: undefined
Example:
map_to_pool=atlas /etc/grid-security/pool/atlas
map_with_file
Synopsis: map_with_file = authgroup_name file
Description:
for users that belongs to specified
authgroup the DN of certificate is matched against a list of DNs stored in
the specified file, one per line followed by a local UNIX account name.
The DN must be quoted if it contains blank spaces.
This rule can be used to implement legacy grid-mapfile aproach.
This is sequenced option.
Default: undefined
Example:
map_with_file=authgroupB /etc/grid-security/grid-mapfile
map_with_plugin
Synopsis: map_with_plugin = authgroup_name timeout plugin [arg1 [arg2 [...]]]
Description: run
external plugin executable with specified arguments to find the UNIX account
name to which users that belogns to specified authgroup will be mapped to.
A rule matches if the exit code is 0 and there is a UNIX account name
printed on stdout (optionally followed by a UNIX group name separated by colon).
The exit code 1 designates failed mapping. Any other code or timeout means fatal
failure and will abort any further mapping processing. That will also cause
rejection of corresponding connection.
Plugin execution time is limited to timeout seconds.
In the arguments the following substitutions are applied before the plugin is started:
%D- subject of user’s certificate,
%P- path to credentials’ proxy file.
ARC ships with LCMAPS plugin that can be enabled with the corresponfing configuration. For more information about configuring LCMAPS refer to ‘Using LCAS/LCMAPS’ document.
This is sequenced option.
Default: undefined
Example:
map_with_plugin=authgroupC 30 /usr/libexec/arc/arc-lcmaps %D %P liblcmaps.so /usr/lib64 /etc/lcmaps/lcmaps.db arc
policy_on_nomap
Synopsis: policy_on_nomap = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user match authgroup specified in the mapping rule and mapping
rule DO NOT return valid UNIX identity. Default policy is stop processing the furhter
rules.
For example this policy will be triggered if pool is depleted, certificate subject is
missing in the map file used for defined authgroup or plugin execution failed.
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_nomap=continue
policy_on_map
Synopsis: policy_on_map = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user match authgroup specified in the mapping rule and mapping
rule return valid UNIX identity. Default policy is stop processing the furhter
rules.
This policy will be triggered if rule successfully returns the result (allocated in pool,
matched in map file, plugin call was successful).
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_map=stop
policy_on_nogroup
Synopsis: policy_on_nogroup = continue/stop
Description: redefines mapping rules sequence processing policy
in case identity of user DO NOT match authgroup specified in the mapping rule.
Default policy is continue processing the furhter rules.
This is sequenced option.
Default: undefined
Allowed values: continue, stop
Example:
policy_on_nogroup=stop
[authtokens] block
This block activates processing of OIDC tokens as defined in WLCG profile.
Warning
CHANGE: NEW block in 6.6.0.
[lrms] block
This block specifies the characteristics of the Local Resource Manager System (batch system) underneath the ARC CE. This block contains all the lrms-specific parameters and information. Configuration values in this block are available for A-REX, the backends, accounting and infosys ARC subsystems.
ARC support the most common LRMS flavours.
Warning
CHANGE: NEW block in 6.0.0. Contains parameters previously set in [common], [infosys], [cluster], [queue]
lrms
Synopsis: *lrms = lrmstype [defaultqueue]
Description: Sets the type of the LRMS (queue system) and optionally the default queue name. ONLY ONE LRMS IS ALLOWED. MULTIPLE LRMS ENTRIES WILL TRIGGER UNEXPECTED BEHAVIOUR.
For lrmstype, the following values can be chosen:
fork - simple forking of jobs to the same node as the server
sge - (Sun/Oracle) Grid Engine
condor - Condor
pbs - PBS (covers Torque and other old PBS flavours e.g. OpenPBS, older PBSPro, etc)
pbspro - Altair PBS Professional
lsf - LSF
ll - LoadLeveler
slurm - SLURM
boinc - Boinc
slurmpy - new EXPERIMENTAL SLURM scripts (contains the ssh remote batch management as well)
The optional defaultqueue parameter specifies the name of an existing LRMS queue
in the cluster that will be used by AREX as the default queue to submit grid jobs in case
the client does not specify a queue name during the job submission procees.
This queue name must match one of the [queue:queue_name] blocks.
Allowed values: fork, sge, condor, pbs, pbspro, lsf, ll, slurm, boinc, slurmpy
Default: undefined
mandatory
Example:
lrms=pbspro gridlong
lrms=slurm
Warning
CHANGE: slurmpy NEW in 6.0.0. pbspro NEW in 6.1.0
lrmsconfig
Synopsis: lrmsconfig = text
Description: An optional free text field to describe the configuration of your Local Resource Management System (batch system). The value is published in the infosys, and is not used otherwise.
Default: undefined
Example:
lrmsconfig=single job per processor
Warning
CHANGE: MOVED in 6.0.0 from the [cluster] block.
benchmark
Synopsis: benchmark = string
Description: Defines the default benchmark specification to store in the accounting AAR records (as it is) if per-job data is missing. It is advised to set it to cluster-wide defaults in case of reporting to APEL to aviod records diversity for failed jobs or buggy backends.
Default: HEPSPEC:1.0
Example:
benchmark=HEPSPEC:12.26
Warning
CHANGE: NEW in 6.8.0
defaultmemory
Synopsis: defaultmemory = number
Description: The LRMS memory request of job to be set by the LRMS backend scripts, if a user submits a job without specifying how much memory should be used. The order of precedence is: job description -> defaultmemory. This is the amount of memory (specified in MB) that a job will request.
Default: undefined
Example:
defaultmemory=512
Warning
CHANGE: MOVED in 6.0.0 from the [cluster] block.
nodename
Synopsis: nodename = path
Description:
Redefine the command to obtain hostname of LRMS worker node.
By default the value is defined on buildtime and depend on the OS.
In most cases /bin/hostname -f will be used.
Note
this way of getting WN hostname will be used only in case of particular LRMS backend had no native LRMS-defined way.
Default: undefined
Example:
nodename=/bin/hostname -s
Warning
CHANGE: MOVED in 6.0.0 from the [arex] block.
gnu_time
Synopsis: gnu_time = path
Description: Path to the GNU time command on the LRMS worker nodes. If time command exists on the node, jobscript will write additional diagnostic information.
Default: /usr/bin/time
Example:
gnu_time=/usr/bin/time
Warning
CHANGE: MOVED in 6.0.0 from the [arex] block.
movetool
Synopsis: movetool = comand
Description: Redefine the command used to move files during jobscript execution on LRMS worker node (the command should be available on WNs). This in particular applies to files movement from sessiondir to scratchdir in the shared sessiondir case.
Default: mv
Example:
movetool=rsync -av
Warning
CHANGE: NEW in 6.8
pbs_bin_path
Synopsis: pbs_bin_path = path
Description: The path to the qstat,pbsnodes,qmgr etc PBS binaries, no need to set if PBS is not used
Default: /usr/bin
Example:
pbs_bin_path=/usr/bin
pbs_log_path
Synopsis: pbs_log_path = path
Description: The path of the PBS server logfiles which are used by A-REX to determine whether a PBS job is completed. If not specified, A-REX will use qstat for that.
Default: /var/spool/pbs/server_logs
Example:
pbs_log_path=/var/spool/pbs/server_logs
pbs_dedicated_node_string
Synopsis: pbs_dedicated_node_string = string
Description: (previously dedicated_node_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
Example:
pbs_dedicated_node_string=gridnode
Warning
CHANGE: RENAMED and MOVED in 6.0.0 from [cluster].
condor_bin_path
Synopsis: condor_bin_path = path
Description: Path to Condor binaries. Must be set if Condor is used.
Default: /usr/bin
Example:
condor_bin_path=/opt/condor/bin
condor_config
Synopsis: condor_config = path
Description: Full path to Condor config file. Must be set if Condor is used and the config file is not in its default location (/etc/condor/condor_config or ~/condor/condor_config). The full path to the file should be given.
Default: /etc/condor/condor_config
Example:
condor_config=/opt/condor/etc/condor_config
condor_rank
Synopsis: condor_rank = ClassAd_float_expression
Description: If you are not happy with the way Condor picks nodes when running jobs, you can define your own ranking algorithm by optionally setting the condor_rank attribute. condor_rank should be set to a ClassAd float expression that you could use in the Rank attribute in a Condor job description.
Default: undefined
Example:
condor_rank=(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000
condor_requirements
Synopsis: condor_requirements = string
Description: Specify additional constraints for Condor resources.
The value of condor_requirements must be a valid constraints string
which is recognized by a condor_status -constraint ... command. It can
reference pre-defined ClassAd attributes (like Memory, Opsys, Arch, HasJava,
etc) but also custom ClassAd attributes. To define a custom attribute on a
condor node, just add two lines like the ones below in the $(hostname).local
config file on the node:
NORDUGRID_RESOURCE=TRUE
STARTD_EXPRS = NORDUGRID_RESOURCE, $(STARTD_EXPRS)
A job submitted to this resource is allowed to run on any node which satisfies
the condor_requirements constraint. If condor_requirements is not set,
jobs will be allowed to run on any of the nodes in the pool. When configuring
multiple queues, you can differentiate them based on memory size or disk
space, for example.
Default: undefined
Example:
condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)
sge_bin_path
Synopsis: sge_bin_path = path
Description: Path to Sun Grid Engine (SGE) binaries, Default is search for qsub command in the shell PATH
Default: undefined
Example:
sge_bin_path=/opt/n1ge6/bin/lx24-x86
sge_root
Synopsis: sge_root = path
Description: Path to SGE installation directory. MUST be set if SGE is used.
Default: /gridware/sge
Example:
sge_root=/opt/n1ge6
sge_cell
Synopsis: sge_cell = name
Description: The name of the SGE cell to use. This option is only necessary in case SGE is set up with a cell name different from ‘default’
Default: default
Example:
sge_cell=default
sge_qmaster_port
Synopsis: sge_qmaster_port = port
Description: The SGE port options should be used in case SGE command line clients require SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables to be set. Usually they are not necessary.
Default: undefined
Example:
sge_qmaster_port=536
sge_execd_port
Synopsis: sge_execd_port = port
Description: The SGE port options should be used in case SGE command line clients requre SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables to be set. Usually they are not necessary.
Default: undefined
Example:
sge_execd_port=537
sge_jobopts
Synopsis: sge_jobopts = string
Description: Additional SGE options to be used when submitting jobs to SGE
Default: undefined
Example:
sge_jobopts=-P atlas -r yes
slurm_bin_path
Synopsis: slurm_bin_path = path
Description: Path to SLURM binaries, must be set if installed outside of normal PATH
Default: /usr/bin
Example:
slurm_bin_path=/usr/bin
slurm_wakeupperiod
Synopsis: slurm_wakeupperiod = numsec
Description: How long should infosys wait before querying SLURM for new data (seconds)
Default: 30
Example:
slurm_wakeupperiod=15
slurm_use_sacct
Synopsis: slurm_use_sacct = yes/no
Description: Indicates whether ARC should use sacct instead of scontrol to obtain information about finished jobs Not supported by slurmpy.
Allowed values: yes, no
Default: yes
Example:
slurm_use_sacct=yes
slurm_requirements
Synopsis: slurm_requirements = string
Description: Use this option to specify extra SLURM-specific parameters.
Default: undefined
Example:
slurm_requirements=memory on node >> 200
Warning
CHANGE: NEW in 6.0.0.
slurm_query_retries
Synopsis: slurm_query_retries = number
Description: Number of sacct/scontrol retries performed in scan-SLURM-job If slurm is overloaded the sacct/scontrol command call may fail. If retries > 1 sacct/scontrol is retried after some seconds for that(those) particular job(s). If all retry attempts fail, the next scan-SLURM-job institiation will pick up the job(s) from last time.
Default: 1
Example:
slurm_query_retries=3
lsf_bin_path
Synopsis: lsf_bin_path = path
Description: The PATH to LSF bin folder
Default: /usr/bin
Example:
lsf_bin_path=/usr/local/lsf/bin/
lsf_profile_path
Synopsis: lsf_profile_path = path
Description: Path to the profile.lsf file. Infoprovider scripts will source profile.lsf to setup LSF utilites environment.
Default: /usr/share/lsf/conf/profile.lsf
Example:
lsf_profile_path=/usr/local/share/lsf/conf/profile.lsf
lsf_architecture
Synopsis: lsf_architecture = string
Description: CPU architecture to request when submitting jobs to LSF. Use only if you know what you are doing.
Default: undefined
Example:
lsf_architecture=PowerPC
Warning
CHANGE: MOVED in 6.0.0 from [queue:name] block.
ll_bin_path
Synopsis: ll_bin_path = path
Description: The PATH to the LoadLeveler bin folder
Default: /usr/bin
Example:
ll_bin_path=/opt/ibmll/LoadL/full/bin
ll_consumable_resources
Synopsis: ll_consumable_resources = yes/no
Description: Indicates whether the LoadLeveler setup is using Consumable Resources.
Allowed values: yes, no
Default: no
Example:
ll_consumable_resources=yes
boinc_db_host
Synopsis: boinc_db_host = hostname
Description: Connection strings for the boinc database: host
Default: localhost
Example:
boinc_db_host=localhost
boinc_db_port
Synopsis: boinc_db_port = port
Description: Connection strings for the boinc database: port
Default: 3306
Example:
boinc_db_port=3306
boinc_db_name
Synopsis: boinc_db_name = db_name
Description: Connection strings for the boinc database: db_name
Default: undefined
Example:
boinc_db_name=myproject
boinc_db_user
Synopsis: boinc_db_user = user
Description: Connection strings for the boinc database: db_user
Default: undefined
Example:
boinc_db_user=boinc
boinc_db_pass
Synopsis: boinc_db_pass = pwd
Description: Connection strings for the boinc database: pwd
Default: undefined
Example:
boinc_db_pass=password
boinc_app_id - ID of the app handled by this CE. Setting this option makes database queries much faster in large projects with many apps.
Default: undefined
Example:
boinc_app_id=1
boinc_project_dir - Base directory of the BOINC project
Default: undefined
Example:
boinc_project_dir=/home/boinc
[lrms/ssh] block
This sub-block configures the ssh environment for remote batch management. Currently ONLY the python slurm (slurmpy) EXPERIMENTAL batch module is able to utilize the remote ssh feature. Parameters within this block are relevant if the cluster frontend is remotely located wrt. CE frontend (machine running A-REX). If specified with the parameters below, the session, cache and runtime directories will be mounted from the cluster frontend on the CE frontend using sshfs. Job submission and management will done using ssh (Paramiko).
Warning
CHANGE: NEW sub-block in 6.0.0 to configure ssh support in slurmpy as a part of tech preview.
remote_host
Synopsis: *remote_host = hostname
Description: Define the remote cluster frontend machine which contains session, cache and runtime directories and where jobs should be submitted to.
Default: undefined
mandatory
Example:
remote_host=myremotehost.org
private_key
Synopsis: *private_key = path
Description: Location of the private key which should be used establish connection to the machine specified by the ‘remote_host’ attribute.
Default: undefined
mandatory
Example:
private_key=/etc/grid-security/hostkey-priv.pem
remote_user
Synopsis: *remote_user = user
Description: User on remote cluster which should be used for mounting directories, submitting and managing jobs, and gathering information about cluster.
Default: undefined
mandatory
Example:
remote_user=grid
remote_sessiondir
Synopsis: remote_sessiondir = path
Description: Session directory on cluster frontend to be
mounted (sshfs) on CE machine at directory specified by the ‘sessiondir’
attribute in the [arex] block.
Default: undefined
mandatory
Example:
remote_sessiondir=/scratch/grid
remote_cachedir
Synopsis: remote_cachedir = path
Description: Cache directory on cluster frontend to be
mounted (sshfs) on CE machine at directory specified by the ‘cachedir’
attribute in the [arex] block.
Default: undefined
Example:
remote_cachedir=/scratch/cache
ssh_timeout
Synopsis: ssh_timeout = time
Description: Timeout of establishing ssh connection. Unit in seconds.
Default: 10
Example:
ssh_timeout=10
[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…
Warning
CHANGE: RENAMED block in 6.0.0.
user
Synopsis: user = user[:group]
Description: Switch to a non root user/group after startup. Use with caution because of limited functionality when arex is not run under root.
Default: root
Example:
user=grid:grid
norootpower
Synopsis: norootpower = yes|no
Description: If set to yes, all job management processes will switch to mapped user’s identity while accessing session directory. This is useful if session directory is on NFS with root squashing turned on.
Allowed values: yes, no
Default: no
Example:
norootpower=yes
delegationdb
Synopsis: delegationdb = db_name
Description: specify which DB to use to store delegations. Currently supported db_names are bdb and sqlite
Default: sqlite
Example:
delegationdb=sqlite
Warning
CHANGE: MODIFIED in 6.0.0 with new default.
watchdog
Synopsis: watchdog = yes/no
Description: Specifies if additional watchdog processes is spawned to restart main process if it is stuck or dies.
Allowed values: yes, no
Default: no
Example:
watchdog=no
loglevel
Synopsis: loglevel = level
Description: (previously debug) Set loglevel of the arched daemon hosting A-REX service between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
Warning
CHANGE: RENAMED in 6.0.0.
logfile
Synopsis: logfile = path
Description: Specify A-REX log file location. If using an external log rotation tool be careful to make sure it matches the path specified here.
Default: /var/log/arc/arex.log
Example:
logfile=/var/log/arc/arex.log
Warning
CHANGE: MODIFIED default (renamed file) in 6.0.0.
joblog
Synopsis: joblog = path
Description: Specifies where to store specialized log about started and finished jobs. If path is empty log is NOT written. Controlled by logrotate if deafult name is kept. This log is not used by any other part of ARC so can be safely disabled if you are not interested in storing jobs log.
Default: /var/log/arc/arex-jobs.log
Example:
joblog=
fixdirectories
Synopsis: fixdirectories = yes/missing/no
Description: Specifies during startup A-REX should
create all directories needed for it operation and set suitable default
permissions. If no is specified then A-REX does nothing to prepare its
operational environment. In case of missing A-REX only creates and
sets permissions for directories which are not present yet. For yes
all directories are created and permissions for all used directories are
set to default safe values.
Allowed values: yes, missing, no
Default: yes
Example:
fixdirectories=yes
controldir
Synopsis: controldir = path
Description: The directory of the A-REX’s internal job metadata files. For a heavy loaded computing elements you can consider to locate controldir on a dedicated partition optimized for small random reads and writes. The directory is not needed on the nodes.
Default: /var/spool/arc/jobstatus
Example:
controldir=/var/spool/arc/jobstatus
sessiondir
Synopsis: sessiondir = path [drain]
Description: the directory which holds the sessiondirs of the grid jobs.
Multiple session directories may be specified.
In this case jobs are spread evenly over the session directories.
If sessiondir=* is set, the session directory will be spread over the
${HOME}/.jobs directories of every locally mapped unix user. It is preferred
to use common session directories. The path may be followed by drain, in
which case no new jobs will be assigned to that sessiondir, but current jobs
will still be processed and accessible.
This option in multivalued.
Default: /var/spool/arc/sessiondir
Example:
sessiondir=/scratch/arcsessions drain
sessiondir=*
defaultttl
Synopsis: defaultttl = [ttl [ttr]]
Description: The ttl parameter sets the time in seconds for how long a job session directory will survive after job execution has finished. If not specified the default is 1 week. The ttr parameter sets how long information about a job will be kept after the session directory is deleted. If not specified, the ttr default is one month.
Default: 604800 2592000
Example:
defaultttl=2592000
scratchdir
Synopsis: scratchdir = path
Description: The path on computing node to move session directory to before execution. If defined should contain the path to the directory on the computing node which can be used to store a jobs’ files during execution. Sets the environment variable RUNTIME_LOCAL_SCRATCH_DIR. If the variable is not set, then the session dir is not moved before execution. Don’t set this parameter unless you want to move the sessiondir to scratchdir on the node.
Default: undefined
Example:
scratchdir=/local/scratch/
tmpdir
Synopsis: tmpdir = path
Description: A temporary directory used by A-REX.
Default: /tmp
Example:
tmpdir=/tmp
runtimedir
Synopsis: runtimedir = path
Description: The directory which holds the additional runtimeenvironment scripts, added by system administrator. Several directories can be specified. To enable RTEs to be advertised in the information system and used during submission the arcctl tool should be used.
This option in multivalued.
Default: undefined
Example:
runtimedir=/var/spool/arc/extraruntimes
runtimedir=/cvmfs/vo/arcruntime
maxjobs
Synopsis: maxjobs = number1 number2 number3 number4 number5
Description: specifies maximum allowed number of jobs. number1 - jobs which are not in FINISHED state (jobs tracked in RAM) number2 - jobs being run (SUBMITTING, INLRMS states) number3 - jobs being processed per DN number4 - jobs in whole system number5 - LRMS scripts limit (jobs in SUBMITTING and CANCELING) A parameter set to -1 means no limit.
Default: -1 -1 -1 -1 -1
Example:
maxjobs=10000 10 2000 -1 -1
Warning
CHANGE: MODIFIED in 6.0.0. Explicitly indicate no limit with -1. Missing number should not be allowed.
maxrerun
Synopsis: maxrerun = number
Description: Specifies how many times job can be rerun if it failed in LRMS. This is only an upper limit, the actual rerun value is set by the user in his xrsl.
Default: 5
Example:
maxrerun=5
statecallout
Synopsis: statecallout = state options plugin_path [plugin_arguments]
Description: (previously authplugin)
Enables a callout feature of A-REX: every time job goes to state A-REX
will run plugin_path executable. The following states are allowed:
ACCEPTED, PREPARING, SUBMIT, FINISHING, FINISHED and DELETED.
Options consist of key=value pairs separated by comma. Possible keys are:
timeoutdefines the timeout in seconds to wait for plugin execution (
timeout=can be omitted).onsuccess,onfailure,ontimeoutdefines the action that A-REX should take on successful execution (exit code 0), failed execution (exit code is not 0) or execution timeout respectively.
Possible actions are:
pass- continue executing job,
fail- cancel job,
log- write to log about the failure and continue executing job.
It is possible to use following sugstitutions to construct plugin command line:
%R- session root (value of sessiondir in[arex]block)
%C- controldir path
%U- username of mapped UNIX account
%u- numeric UID of mapped UNIX account
%g- numeric GID of mapped UNIX account
%H- home directory of mapped UNIX account as specified in/etc/passwd
%Q- default queue (seelrmsconfiguration option in[lrms]block)
%L- LRMS name (seelrmsconfiguration option in[lrms]block)
%W- ARC installation path (corresponds to theARC_LOCATIONenvironmental variable)
%F- path to configuration file for this instance
%I- job ID (substituted in runtime)
%S- job state (substituted in runtime)
Plugins included into ARC distribution:
arc-blahp-logger- write accounting log for every finished job in BLAH format
This option in multivalued.
Default: undefined
Example:
statecallout=FINISHED timeout=10,onfailure=pass /usr/libexec/arc/arc-blahp-logger -I %I -U %u -L %C/job.%I.local -P %C/job.%I.proxy
Warning
CHANGE: RENAMED in 6.0.0 from authplugin.
wakeupperiod
Synopsis: wakeupperiod = time
Description:
Specifies how often A-REX checks for new jobs
arrived, job state change requests, etc. That is responsiveness of
A-REX. time is time period in seconds. Default is 3 minutes.
Usually no need to change this parameter because important state changes
are also triggering out-of-schedule checks.
Note
this parameter does not affect responsiveness of backend scripts -
especially scan-<LRMS>-job. That means that upper estimation of time for
detecting job finished executing is sum of responsiveness of backend script + wakeupperiod.
Default: 180
Example:
wakeupperiod=180
infoproviders_timelimit
Synopsis: infoproviders_timelimit = seconds
Description: (previously infoproviders_timeout) Sets the execution time limit of the infoprovider scripts started by the A-REX. Infoprovider scripts running longer than the specified timelimit are gracefully handled by the A-REX (the behaviour depends on the state of the system) Increase this value if you have many jobs in the controldir and infoproviders need more time to process.
Default: 10800
Example:
infoproviders_timelimit=10800
Warning
CHANGED: RENAMED and MOVED in 6.0.0 to [arex] block.
pidfile
Synopsis: pidfile = path
Description: Specify location of file containing PID of daemon process.
Default: /run/arched-arex.pid
Example:
pidfile=/run/arched-arex.pid
mail
Synopsis: mail = email_address
Description: Specifies the email address from where the notification mails are sent
Default: $VAR{user}@$VAR{[common]hostname}
Example:
mail=grid.support@somewhere.org
Warning
CHANGE: MODIFIED in 6.0.0.
gnu_time
Synopsis: gnu_time = path
Description: The gnu time command
Warning
CHANGE: MOVED in 6.0.0 to [lrms].
nodename
Synopsis: nodename = path
Description: The command to obtain hostname of computing node.
Warning
CHANGE: MOVED in 6.0.0 to [lrms].
helper
Synopsis: helper = user executable arguments
Description:
By enabling this parameter A-REX will
run an external helper program under the user useraccount. The program will be
kept running, every time the executable finishes it will be started again.
As a limitation, currently only ‘.’ is supported as username, which corresponds
to the user running A-REX.
Default: undefined
Example:
helper=. /usr/local/bin/myutility
helperlog
Synopsis: helperlog = path
Description: Configuration option to specify the location of log for helpers.
Default: /var/log/arc/job.helper.errors
Example:
helperlog=/var/log/arc/job.helper.errors
Warning
CHANGE: NEW PARAMETER in 6.0.0.
forcedefaultvoms
Synopsis: forcedefaultvoms = VOMS_FQAN
Description:
specify VOMS FQAN which user will be
assigned if his/her credentials contain no VOMS attributes.
To assign different values to different queues put this command
into [queue] block.
Default: undefined
Example:
forcedefaultvoms=/vo/group/subgroup
[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.
Warning
CHANGE: NEW block in 6.0.0.
cachedir
Synopsis: *cachedir = cache_path [link_path]
Description:
Specifies a directory to store cached
data. Multiple cache directories may be specified. Cached data will be distributed
evenly over the caches.
Optional link_path specifies the path at which the cache_path is accessible on
computing nodes, if it is different from the path on the A-REX host.
If link_path is set to . files are not soft-linked, but copied to session
directory.
If a cache directory needs to be drained, then link_path should specify drain,
in which case no new files will be added to the cache and files in the cache
will no longer be used.
Setting link_path to readonly ensures that no new files are written to
this cache, but existing files can still be used.
Draining and read-only caches are not cleaned by the A-REX cache cleaner.
A restart of A-REX is required when changing cache options.
This option in multivalued.
Default: undefined
Example:
cachedir=/scratch/cache
cachedir=/shared/cache /frontend/jobcache
cachedir=/fs1/cache drain
Warning
CHANGE: Added readonly option in 6.7
[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.
Warning
CHANGE: NEW block in 6.0.0.
logfile
Synopsis: logfile = path
Description: (previously cachelogfile) sets the filename where output of the cache-clean tool should be logged. Defaults to /var/log/arc/cache-clean.log.
Default: /var/log/arc/cache-cleaner.log
Example:
logfile=/tmp/cache-clean.log
Warning
CHANGE: RENAMED in 6.0.0.
loglevel
Synopsis: loglevel = level
Description: (previously cacheloglevel) specifies the level of logging by the cache-clean tool, between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=4
Warning
CHANGE: RENAMED in 6.0.0.
cachesize
Synopsis: cachesize = max min
Description: Specifies high and low watermarks for space used by cache, as a percentage of the space on the file system on which the cache directory is located. When the max is exceeded, files will be deleted to bring the used space down to the min level. It is a good idea to have the cache on its own separate file system.
Default: 100 100
Example:
cachesize=50 20
calculatesize
Synopsis: calculatesize = filesystem/cachedir
Description: (previously cacheshared) specifies the way the space occupied by the cache will be calculated. If set to cachedir then cache-clean calculates the size of the cache instead of using filesystem used space.
Allowed values: filesystem, cachedir
Default: filesystem
Example:
calculatesize=cachedir
Warning
CHANGE: RENAMED in 6.0.0 .
cachelifetime
Synopsis: cachelifetime = time
Description: Turns on time-based file cleaning. Files accessed less recently than the given time period will be deleted. Example values of this option are 1800, 90s, 24h, 30d. When no suffix is given the unit is seconds.
Default: undefined
Example:
cachelifetime=30d
cachespacetool
Synopsis: cachespacetool = path [options]
Description: specifies an alternative tool to df that
cache-clean should use to obtain space information on the cache file system.
The output of this command must be total_bytes used_bytes. The cache
directory is passed as the last argument to this command.
Default: undefined
Example:
cachespacetool=/etc/getspace.sh
cachecleantimeout
Synopsis: cachecleantimeout = time
Description: the timeout in seconds for running the cache-clean tool. If using a large cache or slow file system this value can be increased to allow the cleaning to complete. Defaults to 3600 (1 hour).
Default: 3600
Example:
cachecleantimeout=10000
[arex/data-staging] block
This subblock enables and configures the data staging capabilities of A-REX. A subsystem called DTR (Data Transfer Reloaded) is responsible for collecting input data for a job before submission to the LRMS, and for staging out data after the job has finished. Automagic data staging of A-REX is a very powerful feature, disabling this functionality (by commenting out the subblock) is not recommended.
Warning
CHANGE: RENAMED block in 6.0.0.
loglevel
Synopsis: loglevel = number
Description:
(previously debug) Sets the log level for transfer logging in job.id.errors files,
between 0 (FATAL) and 5 (DEBUG). Default is to use value set by loglevel option in
[arex] section.
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: $VAR{[arex]loglevel}
Example:
loglevel=4
Warning
CHANGE: RENAMED in 6.0.0.
logfile
Synopsis: logfile = path
Description: (previously central_logfile) A central file in which all data staging messages from every job will be collected and logged in addition to their job.id.errors files. If this option is not present or the path is empty the log file is not created. This file is not automatically controlled by logrotate unless you name it as /var/log/arc/datastaging.log.
Default: undefined
Example:
logfile=/var/log/arc/datastaging.log
Warning
CHANGE: RENAMED in 6.0.0.
statefile
Synopsis: statefile = path
Description: (previously dtrlog) A file in which data staging state information (for monitoring and recovery purposes) is periodically dumped.
Default: $VAR{[arex]controldir}/dtr.state
Example:
statefile=/tmp/dtr.state
Warning
CHANGE: RENAMED and MODIFIED in 6.0.0, new default value.
usehostcert
Synopsis: usehostcert = yes/no
Description: Whether the A-REX host certificate should be used for communication with remote hosts instead of the users’ proxies.
Allowed values: yes, no
Default: no
Example:
usehostcert=yes
maxtransfertries
Synopsis: maxtransfertries = number
Description: the maximum number of times download and upload will be attempted per job (retries are only performed if an error is judged to be temporary)
Default: 10
Example:
maxtransfertries=20
passivetransfer
Synopsis: passivetransfer = yes/no
Description: If yes, gridftp transfers are passive. Setting this option to yes can solve transfer problems caused by firewalls.
Allowed values: yes, no
Default: yes
Example:
passivetransfer=yes
Warning
CHANGE: NEW DEFAULT in 6.0.0.
globus_tcp_port_range
Synopsis: globus_tcp_port_range = port_range
Description:
In a firewalled environment
the software which uses GSI needs to know what ports are available.
This parameter is only needed if passivetransfer=no was set.
These variable are similar to the Globus enviroment variables
GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_tcp_port_range=9000,12000
Warning
CHANGE: MOVED in 6.0.0.
globus_udp_port_range
Synopsis: globus_udp_port_range = port_range
Description:
In a firewalled environment
the software which uses GSI needs to know what ports are available.
This parameter is only needed if passivetransfer=no was set.
These variable are similar to the Globus enviroment variables
GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_udp_port_range=9000,12000
Warning
CHANGE: MOVED in 6.0.0.
httpgetpartial
Synopsis: httpgetpartial = yes/no
Description: If yes, HTTP GET transfers may transfer data in chunks/parts. If no - data is always transfered in one piece.
Allowed values: yes, no
Default: no
Example:
httpgetpartial=no
Warning
CHANGE: NEW default in 6.0.0.
speedcontrol
Synopsis: speedcontrol = min_speed min_time min_average_speed max_inactivity
Description: specifies how slow data transfer must be to trigger error. Transfer is cancelled if speed is below min_speed bytes per second for at least min_time seconds, or if average rate is below min_average_speed bytes per second, or no data was transferred for longer than max_inactivity seconds. Value of zero turns feature off.
Default: 0 300 0 300
Example:
speedcontrol=0 300 100 300
speedcontrol=
Warning
CHANGE: MODIFIED in 6.0.0: missing parameter speedcontrol= should also turn the feature off, not just zero value.
maxdelivery
Synopsis: maxdelivery = number
Description: Maximum number of concurrent file transfers, i.e. active transfers using network bandwidth. This is the total number for the whole system including any remote staging hosts.
Default: 10
Example:
maxdelivery=40
maxprocessor
Synopsis: maxprocessor = number
Description: Maximum number of concurrent files in each of the DTR internal pre- and post-processing states, eg cache check or replica resolution.
Default: 10
Example:
maxprocessor=20
maxemergency
Synopsis: maxemergency = number
Description: Maximum emergency slots which can be assigned to transfer
shares when all slots up to the limits configured by the above two options
are used by other shares. This ensures shares cannot be blocked by others.
Default: 1
Example:
maxemergency=5
maxprepared
Synopsis: maxprepared = number
Description: Maximum number of files in a prepared state, i.e. pinned on a remote storage such as SRM for transfer. A good value is a small multiple of maxdelivery.
Default: 200
Example:
maxprepared=250
copyurl
Synopsis: copyurl = url_head local_path
Description: Configures that DTR should use copy instead of download in case of certain stagein files. URLs, starting from ‘url_head’ should be accessed in a different way (most probaly unix open). The ‘url_head’ part of the URL will be replaced with ‘local_path’ and file from obtained path will be copied to the session directory. NOTE: ‘local_path’ can also be of URL type.
This option in multivalued.
Default: undefined
Example:
copyurl=gsiftp://example.org:2811/data/ /data/
copyurl=gsiftp://example2.org:2811/data/ /data/
linkurl
Synopsis: linkurl = url_head local_path [node_path]
Description: Identical to ‘copyurl’, configures DTR so that for certain URLs files won’t be downloaded or copied (in case of copyurl), but soft-link will be created. The ‘local_path’ specifies the way to access the file from the frontend, and is used to check permissions. The ‘node_path’ specifies how the file can be accessed from computing nodes, and will be used for soft-link creation. If ‘node_path’ is missing - ‘local_path’ will be used.
This option in multivalued.
Default: undefined
Example:
linkurl=gsiftp://somewhere.org/data /data
linkurl=gsiftp://example.org:2811/data/ /scratch/data/
use_remote_acix
Synopsis: use_remote_acix = URL
Description: (previously acix_endpoint) If configured then the ARC Cache Index, available at the URL, will be queried for every input file specified in a job description and any replicas found in sites with accessible caches will be added to the replica list of the input file. The replicas will be tried in the order specified by preferredpattern variable.
Default: undefined
Example:
use_remote_acix=https://cacheindex.ndgf.org:6443/data/index
Warning
CHANGE: RENAMED in 6.0.0.
preferredpattern
Synopsis: preferredpattern = pattern
Description: specifies a preferred pattern on which to sort multiple replicas of an input file. It consists of one or more patterns separated by a pipe character (|) listed in order of preference. Replicas will be ordered by the earliest match. If the dollar character ($) is used at the end of a pattern, the pattern will be matched to the end of the hostname of the replica. If an exclamation mark (!) is used at the beginning of a pattern, any replicas matching the pattern will be excluded from the sorted replicas.
Default: undefined
Example:
preferredpattern=srm://myhost.ac.uk|.uk$|ndgf.org$|badhost.org$
The following options are used to configure multi-host data staging deployment scenario. In that setup a couple of additional data staging boxes are enabled to off-load data transfers.
deliveryservice
Synopsis: deliveryservice = URL
Description: The URL to a remote data delivery service which can perform remote data staging.
Default: undefined
Example:
deliveryservice=https://myhost.org:443/datadeliveryservice
localdelivery
Synopsis: localdelivery = yes/no
Description: If any deliveryservice is defined, this option determines whether local data transfer is also performed.
Allowed values: yes, no
Default: no
Example:
localdelivery=yes
remotesizelimit
Synopsis: remotesizelimit = size
Description: Lower limit on file size (in bytes) of files that remote hosts should transfer. Can be used to increase performance by transferring small files using local processes.
Default: undefined
Example:
remotesizelimit=100000
[arex/ws] block
A-REX exposes a set of Web Service interfaces that can be used to create and manage jobs, obtain information about the CE and the jobs, handle delegations, access cache information, so on. Comment out this block if you don’t want to provide WS-interfaces for various A-REX functionalities.
Warning
CHANGE: NEW block in 6.0.0. Most of the parameters originates from the old [grid-manager] block
wsurl
Synopsis: wsurl = url
Description: (previously arex_mount_point) Specifies the base URL under which the web service intrefaces will be available. The URL argument must be a full URL consisting of protocol+host+port+path: e.g. https://<hostname>:<port>/<path> Make sure the chosen port is not blocked by firewall or other security rules.
Default: https://$VAR{[common]hostname}:443/arex
Example:
wsurl=https://piff.hep.lu.se:443/arex
Warning
CHANGE: RENAMED and MODIFIED in 6.0.0.
logfile
Synopsis: logfile = path
Description: (previously wslogfile) Specify log file location for WS-interface operations.
Default: /var/log/arc/ws-interface.log
Example:
logfile=/var/log/arc/ws-interface.log
Warning
CHANGE: RENAMED in 6.0.0.
pidfile
Synopsis: pidfile = path
Description: Specify location of file containing PID of daemon process.
Default: /run/arched-arex-ws.pid
Example:
pidfile=/run/arched-arex-ws.pid
Warning
CHANGE: INTRODUCED in 6.13.0.
max_job_control_requests
Synopsis: max_job_control_requests = number
Description: The max number of simultaneously processed job management requests over WS interface - like job submission, cancel, status check etc.
Default: 100
Example:
max_job_control_requests=100
max_infosys_requests
Synopsis: max_infosys_requests = number
Description: The max number of simultaneously processed info requests over WS interface.
Default: 1
Example:
max_infosys_requests=1
max_data_transfer_requests
Synopsis: max_data_transfer_requests = number
Description: The max number of simultaneously processed data transfer requests over WS interface - like data staging.
Default: 100
Example:
max_data_transfer_requests=100
tlsciphers
Synopsis: tlsciphers = ciphers_list
Description: Override OpenSSL ciphers list enabled on server
Default: HIGH:!eNULL:!aNULL
Example:
tlsciphers=HIGH:!eNULL:!aNULL
Warning
CHANGE: INTRODUCED in 6.14.0.
tlsserverorder
Synopsis: tlsserverorder = yes
Description: Force priority order of ciphers for TLS connection to be decided on server sid
Default: no
Example:
tlsserverorder=yes
Warning
CHANGE: INTRODUCED in 7.0.0.
tlsprotocols
Synopsis: tlsprotocols = SSL/TLS protocols
Description: Specify which protocols to enable This is space separated list of values - SSLv2 SSLv3 TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Default: TLSv1.2 TLSv1.3
Example:
tlsprotocols=TLSv1.2 TLSv1.3
Warning
CHANGE: INTRODUCED in 6.14.0.
tlscurve
Synopsis: tlscurve = curve
Description: Specify SSL/TLS ECDH curve name (SN)
Default: secp521r1
Example:
tlscurve=secp521r1
Warning
CHANGE: INTRODUCED in 6.14.0.
[arex/ws/jobs] block
AREX offers a set of web service interfaces implented via either REST or WS-SOAP. This block enables the job management, info query, delegation protocols through both the REST and EMIES interface. Consult the http://svn.nordugrid.org/repos/nordugrid/doc/trunk/tech_doc/emi-es/EMI-ES-Specification_v1.16.pdf for EMIES inteface description and read the http://www.nordugrid.org/documents/arc6/tech/rest/rest.html for the REST interface specification.
Warning
CHANGE: NEW sub-block in 6.0.0.
allownew
Synopsis: allownew = yes/no
Description: The ‘allownew’ config parameter sets if the Computing Element accepts submission of new jobs via the WS-interface. This parameter can be used to close down the CE.
Allowed values: yes, no
Default: yes
Example:
allownew=yes
Warning
CHANGE: NEW in 6.0.0. Implement support in the code for WS-interface.
allownew_override
Synopsis: allownew_override = [authgroup ...]
Description: (previously allowsubmit) 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.
This option in multivalued.
Default: undefined
Example:
allownew_override=biousers atlasusers
allownew_override=yourauthgroup
Warning
CHANGE: RENAMED and MODIFIED behaviour in 6.0.0. Modified behaviour: possible to specify several groups on a single line!
allowaccess
Synopsis: allowaccess = authgroup
Description:
(previously groupcfg) Defines that the specified authgroup members
are authorized to access the ARC-CE via this interface. A related config option the
denyaccess (see below) can be used to reject access.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then no additional restrictions are applied
for authorizing user access and the interface is open to everybody authenticated.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
Synopsis: denyaccess = authgroup
Description: 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
This option in multivalued.
Example:
denyaccess=blacklisted-users
maxjobdesc
Synopsis: maxjobdesc = size
Description: specifies maximal allowed size of job description in bytes. Default value is 5MB. Use 0 to set unlimited size.
Default: 5242880
Example:
maxjobdesc=0
Warning
CHANGE: NEW in 6.0.0.
[arex/ws/publicinfo] block
AREX allows access to public informaton for non-authorized users. Presence of this block enables such feature.
Warning
CHANGE: NEW block in 6.7.0.
allowaccess
Synopsis: allowaccess = authgroup
Description:
Defines that the specified authgroup members are authorized to access
public information. For more information see similar configuration option in [arex/ws/jobs] block.
Default: undefined
This option in multivalued.
Example:
allowaccess=monitors
Warning
CHANGE: NEW in 6.7.0.
denyaccess
Synopsis: denyaccess = authgroup
Description:
Defines that the specified authgroup members are REJECTED, not authorized
to access public information. For more information see similar configuration option in [arex/ws/jobs] block.
Default: undefined
This option in multivalued.
Example:
denyaccess=badactors
Warning
CHANGE: NEW in 6.7.0.
[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.
Warning
CHANGE: NEW block in 6.0.0.
cacheaccess
Synopsis: cacheaccess = rule
Description: This parameter defines the access control rules for the cache wsinterface, the rules for allowing access to files in the cache remotely through the A-REX web interface. If not set, then noone can access anything. The default is not set that means complete denial. A rule has three parts:
Regular expression defining a URL pattern
Credential attribute to match against a client’s credential
Regular expression defining a credential value to match against a client’s credential
A client is allowed to access the cached file if a URL pattern matches the cached file URL and the client’s credential has the attribute and matches the value required for that pattern. Possible values for credential attribute are dn, voms:vo, voms:role and voms:group.
This option in multivalued.
Default: undefined
Example:
cacheaccess=gsiftp://host.org/private/data/.* voms:vo myvo:production
cacheaccess=gsiftp://host.org/private/data/bob/.* dn /O=Grid/O=NorduGrid/.*
[arex/ws/candypond] block
The CandyPond (Cache and deliver your pilot on-demand data) A-REX Web
Service (previously called Cache 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.
The CandyPond service is available via the wsurl/candypond URL (e.g. https://hostname:443/arex/candypond)
Warning
CHANGE: NEW block in 6.0.0, and RENAMED service.
[arex/ws/argus] block
The Web Service components of A-REX may directly use the Argus service (https://twiki.cern.ch/twiki/bin/view/EGEE/AuthorizationFramework) for requesting authorization decisions and performing client mapping to a local user account. This block turns on and configures the A-REX WS - Argus integration. When this block is enabled, A-REX will communicate to Argus PEP or PDP service for every WS interface operation! Comment out this block if you don’t intend to use any external Argus service with A-REX WS interfaces. Using Argus with gridftp interface is possible only via LCMAPS callout.
Warning
CHANGE: NEW block in 6.0.0.
arguspep_endpoint
Synopsis: *arguspep_endpoint = url
Description:
Specifies URL of Argus PEPD service to use for
authorization and user mapping.
It is worth to mention that requireClientCertAuthentication (default is false)
item of pepd.ini (configuration of Argus PEPD service) is set to be ‘true’, then
https should be used, otherwise http is proper.
Note
Argus will be contacted for every WS interface operation requested!
Default: undefined
Example:
arguspep_endpoint=https://somehost.somedomain:8154/authz
arguspep_profile
Synopsis: arguspep_profile = profile_name
Description: Defines which communication profile to use while communicating with Argus PEPD service. Possible values for profile_name are:
direct - pass all authorization attributes (only for debugging) subject - pass only subject name of client emi - ARC native profile developed in EMI project. This is default option.
Allowed values: direct, subject, emi
Default: emi
Example:
arguspep_profile=emi
Warning
CHANGE: MODIFIED parameter values in 6.0.0: removed CREAM.
arguspep_usermap
Synopsis: arguspep_usermap = yes/no
Description: Specifies whether response from Argus service may define mapping of client to local account. Default is ‘no’. Note that Argus is contacted after all the other user mapping is performed. Hence it can overwrite all other decisions.
Allowed values: yes, no
Default: no
Example:
arguspep_usermap=no
arguspdp_endpoint
Synopsis: arguspdp_endpoint = url
Description: Specifies URL of Argus PDP service to use for
authorization and user mapping.
It is worth to mention that requireClientCertAuthentication (default is false)
item of pdp.ini (configuration of Argus PDP service) is set to be ‘true’, then
https should be used, otherwise http is proper.
Note
Argus will be contacted for every WS interface operation requested!
Default: undefined
Example:
arguspdp_endpoint=https://somehost.somedomain:8152/authz
arguspdp_profile
Synopsis: arguspdp_profile = profile_name
Description: Defines which communication profile to use while communicating with Argus PDP service. Possible values for profile_name are:
subject - pass only subject name of client emi - ARC native profile developed in EMI project. This is default option.
Allowed values: subject, emi
Default: emi
Example:
arguspdp_profile=emi
Warning
CHANGE: MODIFIED parameter values in 6.0.0: remove CREAM.
arguspdp_accpetnotapplicable
Synopsis: arguspdp_accpetnotapplicable = yes/no
Description:
Specify if the NotApplicable decision returned by Argus
PDP service is treated as reason to deny request. Default is ‘no’, which treats
NotApplicable as reason to deny request.
Allowed values: yes, no
Default: no
Example:
arguspdp_acceptnotapplicable=no
[arex/jura] block
A-REX is responsible for collecting accounting measurements from various ARC subsystems, including batch system backends and DTR data staging.
Staring from 6.4 release A-REX writes all accounting data into the local accounting
database that can be queries 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 using accounting data.
Note
in the ARC releases before 6.4 the accounting measurements were collected in the job log files that are only used for publishing records. This functionality was supported for backward compatibility in 6.4-6.7 releases and was removed in ARC 6.8.0
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].
logfile
Synopsis: logfile = path
Description: (previously jobreport_logfile) The name of the jura logfile.
Default: /var/log/arc/jura.log
Example:
logfile=/var/log/arc/jura.log
loglevel
Synopsis: loglevel = number
Description: Log level for the JURA accounting module.
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
vomsless_vo
Synopsis: vomsless_vo = voname[#voissuer]
Description: This parameter allows the sysadmin to manually assign
VOs during pubishing to jobs that were submitted with VOMS-less grid proxies.
voname is the VO name to be used in the generated records (the same as expected in voms-proxy)
optional voissuer (relevant to SGAS only) value is the VOMS server identity (certificate DN).
Default: undefined
Example:
vomsless_vo=atlas
vomsless_vo=atlas#/DC=ch/DC=cern/OU=computers/CN=lcg-voms.cern.ch
vo_group
Synopsis: vo_group = group
Description: Adds an additional VO group attribute(s) to the usage records.
This option in multivalued.
Default: undefined
Example:
vo_group=/atlas/production
urdelivery_frequency
Synopsis: urdelivery_frequency = seconds
Description: (previously jobreport_period) Specifies the frequency of JURA process regular execution by the A-REX. The actual treshold of records reporting frequency can be defined on per-target basis.
Default: 3600
Example:
urdelivery_frequency=3600
Warning
CHANGE: RENAMED in 6.0.0.
x509_host_key
Synopsis: x509_host_key = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: NEW in 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: NEW in 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
Warning
CHANGE: NEW in 6.0.0.
[arex/jura/sgas:targetname] block
An SGAS sub-block of [arex/jura] enables and configures an SGAS accounting
server as a target destination to which JURA will send properly formatted usage records.
You need to define a separate block with a unique targetname for every SGAS target server.
Note that the block name will be used by JURA to track that latest records sent to
this targed. Be aware that ff you rename the block, target will be handled as a new one.
However targeturl change will not trigger a new target handling.
targeturl
Synopsis: *targeturl = url
Description: The service endpoint URL of SGAS server.
Default: undefined
Example:
targeturl=https://grid.uio.no:8001/logger
Warning
CHANGE: NEW in 6.0.0.
localid_prefix
Synopsis: localid_prefix = prefix_string
Description: Sets a prefix value for the LocalJobID ur parameter for the SGAS usage records.
Default: undefined
Example:
localid_prefix=some_text_for_SGAS
Warning
CHANGE: NEW in 6.0.0.
vofilter
Synopsis: vofilter = vo
Description: Configures a job record filtering mechanism based on the VO attribute of the jobs. Only the matching job records, which was one of VO that you set here, will be sent to the target accounting service.
This option in multivalued.
Default: undefined
Example:
vofilter=atlas
vofilter=fgi.csc.fi
Warning
CHANGE: NEW in 6.0.0.
urbatchsize
Synopsis: urbatchsize = number
Description: JURA sends usage records not one-by-one, but in batches. This options sets the size of a batch. Zero value means unlimited batch size.
Default: 50
Example:
urbatchsize=80
urdelivery_frequency
Synopsis: urdelivery_frequency = seconds
Description: (introduced in 6.4.0) Add optional minimal treshold of the interval between subsequent records publishing to this target.
Note
the actual delivery interval is the value divisible by urdelivery_frequency
defined in [arex/jura] block that define the entire JURA process invocation frequency.
Default: undefined
Example:
urdelivery_frequency=3600
Warning
CHANGE: NEW in 6.4.0.
[arex/jura/apel:targetname] block
An APEL sub-block of [arex/jura] enables and configures an APEL accounting
server as a target destination to which JURA will send properly formatted usage records.
You need to define a separate block with a unique targetname for every APEL target server.
Note that the block name will be used by JURA to track that latest records sent to
this targed. Be aware that ff you rename the block, target will be handled as a new one.
However targeturl change will not trigger a new target handling.
targeturl
Synopsis: *targeturl = url
Description: The service endpoint URL of the APEL accounting server.
Default: undefined
Example:
targeturl=https://msg.argo.grnet.gr
topic
Synopsis: topic = topic_name
Description: Sets the name of the APEL topic to which JURA will publish the accounting records. AMS destination topic for compute element is ‘gLite-APEL’
Default: gLite-APEL
Example:
topic=/queue/global.accounting.test.cpu.central
project
Synopsis: project = project_name
Description: Sets the name of the APEL project to use.
Default: accounting
Example:
project=accounting-nl
Warning
CHANGE: NEW in 6.19.0
gocdb_name
Synopsis: *gocdb_name = name
Description: Can be used to specify the GOCDB name of the resource. This value would be seen as Site attribute in the generated APEL records.
Default: undefined
Example:
gocdb_name=GRID_UIO_NO
apel_messages
Synopsis: apel_messages = type
Description: (introduced in 6.4.0) 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.
Note
on the heavy loaded sites with 10k+ jobs weekly summaries generation has
a performance penalty in ARC < 6.8. It is advised to use urs in this case.
Allowed values: urs, summaries, summaries-v04
Default: summaries
Example:
apel_messages=urs
Warning
CHANGE: NEW in 6.4.0.
vofilter
Synopsis: vofilter = vo
Description: Configures a job record filtering mechanism based on the VO attribute of the jobs. Only the matching job records, which was one of VO that you set here, will be sent to the target accounting service.
This option in multivalued.
Default: undefined
Example:
vofilter=atlas
vofilter=fgi.csc.fi
urbatchsize
Synopsis: urbatchsize = number
Description: JURA sends usage records not one-by-one, but in batches. This options sets the size of a batch. Zero value means unlimited batch size. 500 is recommended to avoid too large messages using AMS
Default: 500
Example:
urbatchsize=500
urdelivery_frequency
Synopsis: urdelivery_frequency = seconds
Description: (introduced in 6.4.0) Add optional minimal treshold of the interval between subsequent records publishing to this target.
Note
the actual delivery interval is the value divisible by urdelivery_frequency
defined in [arex/jura] block that define the entire JURA process invocation frequency.
APEL recommended value is once per day for summaries. Use smaller values for urs.
Default: 86000
Example:
urdelivery_frequency=14000
Warning
CHANGE: NEW in 6.4.0.
[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.
Warning
CHANGE: RENAMED block in 6.0.0.
gmetric_bin_path
Synopsis: gmetric_bin_path = path
Description: (previously gmetric_exec) The path to gmetric executable.
Default: /usr/bin/gmetric
Example:
gmetric_bin_path=/usr/local/bin/gmetric
Warning
CHANGE: MOVED and RENAMED in 6.0.0 from deleted [gangliarc] block.
metrics
Synopsis: metrics = name_of_the_metrics
Description: the metrics to be monitored. metrics takes a comma-separated list of one or more of the following metrics: - staging – number of tasks in different data staging states - not yet implemented - cache – free cache space - session – free session directory space - heartbeat – last modification time of A-REX heartbeat - processingjobs – the number of jobs currently being processed by ARC (jobs
between PREPARING and FINISHING states) - not yet implemented
failedjobs – the number of failed jobs per last 100 finished
jobstates – number of jobs in different A-REX stages
all – all of the above metrics
Default: all
Allowed values: staging, cache, session, heartbeat, processingjobs, failedjobs, jobstates, all
Example:
metrics=all
frequency
Synopsis: frequency = seconds
Description: The period between each information gathering cycle, in seconds.
Default: 60
Example:
frequency=300
Warning
CHANGE: MODIFIED in 6.0.0. Default increased from 20s to one minute.
[gridftpd] block
This block enables and configures the gridftp server. The usage of the gridftp is twofold in connection with ARC: 1) The server together with its custom jobplugin can be used as a job submission and management interface for an ARC CE. 2) The server with the filedirplugin can be used as a very simplistic storage element. This block configures the common server capabilities. To make the gridftp service functional, you need to enable at least one of the plugin subblocks as well.
user
Synopsis: user = user[:group]
Description: Switch to a non root user/group after startup WARNING: Make sure that the certificate files are owned by the user/group specified by this option.
Default: root:root
Example:
user=grid
loglevel
Synopsis: loglevel = level
Description: (previously debug) Set log level of the gridftpd daemon, between 0 (FATAL) and 5 (DEBUG). Default is 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=2
Warning
CHANGE: RENAMED in 6.0.0.
logfile
Synopsis: logfile = path
Description: Set logfile location of the gridftp server.
Default: /var/log/arc/gridftpd.log
Example:
logfile=/var/log/arc/gridftpd.log
pidfile
Synopsis: pidfile = path
Description: Specify location of file containing PID of daemon process.
Default: /run/gridftpd.pid
Example:
pidfile=/run/gridftpd.pid
port
Synopsis: port = bindport
Description: Port to listen on. For gridftp-based job submission strongly adviced to use the default 2811 port because 3rd party clients assume ARC CE using that port.
Default: 2811
Example:
port=2811
allowencryption
Synopsis: allowencryption = yes/no
Description: (previously encryption) should data encryption be allowed on client request. Encryption is very heavy, therefore the default is no.
Allowed values: yes, no
Default: no
Example:
allowencryption=no
Warning
CHANGE: RENAMED in 6.0.0.
allowactivedata
Synopsis: allowactivedata = yes/no
Description: if no, only passive data transfer is allowed. By default both passive and active data transfers are allowed.
Default: yes
Example:
allowactivedata=yes
maxconnections
Synopsis: maxconnections = number
Description: The maximum number of connections accepted by a gridftpd server.
Default: 100
Example:
maxconnections=200
defaultbuffer
Synopsis: defaultbuffer = size
Description: Defines size of every buffer for data reading/writing. The actual value may decrease if the cumulative size of all buffers exceeds value specified by maxbuffer.
Default: 65536
Example:
defaultbuffer=65536
maxbuffer
Synopsis: maxbuffer = size
Description: Defines maximal amount of memory in bytes to be allocated for all data reading/writing buffers. Default is 640kB. The number of buffers is (max {3, min {41, 2P + 1}}), where P is the parallelism level requested by the client. Hence, even without parallel streams enabled number of buffers will be 3.
Default: 655360
Example:
maxbuffer=655360
globus_tcp_port_range
Synopsis: globus_tcp_port_range = port_range
Description: In a firewalled environment the software which uses GSI needs to know what ports are available. If not set a random port is selected. These variable are similar to the Globus enviroment variables: GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_tcp_port_range=9000,12000
globus_udp_port_range
Synopsis: globus_udp_port_range = port_range
Description: In a firewalled environment the software which uses GSI needs to know what ports are available. If not set a random port is selected. These variable are similar to the Globus enviroment variables: GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
Default: 9000,9300
Example:
globus_udp_port_range=9000,12000
firewall
Synopsis: firewall = hostname
Description: The hostname or IP address to use in response to PASV command instead of the IP address of a network interface of computer.
Default: undefined
Example:
firewall=my.host.org
x509_host_key
Synopsis: x509_host_key = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
[gridftpd/jobs] block
The jobplugin of the gridftp server implements a custom job management and submission interface of ARC CE. This subblock enables and configures that interface. Consult the Technical Reference within the ARC sysadmin guide for the interface specification. Comment out this subblock if you don’t want a gridftp-based jobinterface.
allownew
Synopsis: allownew = yes/no
Description: This parameter sets if the ARC CE accepts submission of new jobs via the gridftp interface. This parameter can be used to close down the ARC CE.
Allowed values: yes, no
Default: yes
Example:
allownew=yes
allownew_override
Synopsis: allownew_override = [authgroup ...]
Description: (previously allowsubmit) Defines which authorization groups are allowed to submit new jobs via the gridftp interface when the CE is closed with allownew=no. Note that it requires the allownew=no to be set.
This option in multivalued.
Default: undefined
Example:
allownew_override=biousers atlasusers
allownew_override=yourauthgroup
Warning
CHANGE: RENAMED and MODIFIED in 6.0.0. Possible to specify several groups on a single line.
allowaccess
Synopsis: allowaccess = authgroup
Description:
(previously groupcfg) Defines that the specified authgroup members
are authorized to access the ARC-CE via this interface. A related config option the
denyaccess (see below) can be used to reject access.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then no additional restrictions are applied
for authorizing user access and the interface is open to everybody authenticated.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
Synopsis: denyaccess = authgroup
Description: 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
This option in multivalued.
Example:
denyaccess=blacklisted-users
maxjobdesc
Synopsis: maxjobdesc = size
Description: specifies maximal allowed size of job description in bytes. Default value is 5MB. Use 0 to set unlimited size.
Default: 5242880
Example:
maxjobdesc=0
[gridftpd/filedir] block
The filedirplugin module of the gridftp server can be used to set up a
simplistic grid storage element (SE). This subblock enables and configures
such an SE by exporting a directory using the gridftpd’s filedirplugin.
Comment out this block if you don’t need a SE.
path
Synopsis: *path = virtdir
Description: The name of the virtual directory served by the gridftp server.
The exported storage area is accessible as gsiftp://my_server/virtdir.
Even / is a valid choice.
Default: undefined
Example:
path=/topdir
mount
Synopsis: *mount = path
Description: The physical directory corresponding to the virtual one: gsiftp://my_server/virtdir will give access to this location.
Default: undefined
Example:
mount=/scratch/grid
allowaccess
Synopsis: allowaccess = authgroup
Description: (previously groupcfg) Defines that the specified authgroup members
are authorized to access the gridftp file service. A related config option the
denyaccess (see below) can be used to reject access.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then no additional restrictions are applied
for authorizing user access and the interface is open to everybody authenticated.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
Synopsis: denyaccess = authgroup
Description: Defines that the specified authgroup members
are REJECTED, not authorized to access the gridftp file service. 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
This option in multivalued.
Example:
denyaccess=blacklisted-users
dir
Synopsis: dir = path options
Description: Specifies access rules for accessing files in path
(relative to virtual and real path) and all the files and directories below.
Available permisisons check options are:
- nouser
do not use local file system rights, only use those specifies in this line
- owner
check only file owner access rights
- group
check only group access rights
- other
check only
othersaccess rights
If none of the above specified usual unix access rights are applied.
Avaiable permissions enforecement options are:
- read
allow reading files
- delete
allow deleting files
- append
allow appending files (does not allow creation)
- overwrite
allow overwriting already existing files (does not allow creation, file attributes are not changed)
- dirlist
allow obtaining list of the files
- cd
allow to make this directory current
- create owner:group permissions_or:permissions_and
allow creating new files. File will be owned by
ownerand owning group will begroup. If*is used, the user/group to which connected user is mapped will be used. The permissions will be set topermissions_or & permissions_and. (second number is reserved for the future usage).- mkdir owner:group permissions_or:permissions_and
allow creating new directories.
Example shows setting permissions on mounted / directory and adjusting permissions
on /section1 and /section2 subdirectories.
This option in multivalued.
Default: undefined
Example:
dir=/ nouser read cd dirlist delete create *:* 664:664 mkdir *:* 775:775
dir=/section1 nouser read mkdir *:* 700:700 cd dirlist
dir=/section2 nouser read mkdir *:* 700:700 cd dirlist
[infosys] block
This block enables and configures the core part of the information system. Enables the information collection to be used by other ARC components, including interfaces. Parameters in this block applies to all the infosys subsystems.
logfile
Synopsis: logfile = path
Description: (previously providerlog) Specifies log file location for the information provider scripts.
Default: /var/log/arc/infoprovider.log
Example:
logfile=/var/log/arc/infoprovider.log
Warning
CHANGE: RENAMED in 6.0.0.
loglevel
Synopsis: loglevel = number
Description: (previously provider_loglevel) The loglevel for the infoprovider scripts (0-5). Each value corresponds to the following verbosity levels: FATAL => 0, ERROR => 1 , WARNING => 2, INFO => 3, VERBOSE => 4, DEBUG => 5
Allowed values: 0, 1, 2, 3, 4, 5, FATAL, ERROR, WARNING, INFO, VERBOSE, DEBUG
Default: 3
Example:
loglevel=3
Warning
CHANGE: RENAMED in 6.0.0.
validity_ttl
Synopsis: validity_ttl = seconds
Description: The published infosys records advertise their validity e.g. how long the info should be considered up-to-date by the clients. Use this parameter to set the published validity value.
Note
different schemas may render this information differently.
Default: 10800
Example:
validity_ttl=10800
[infosys/ldap] block
This infosys subblock enables and configures the ldap hosting service for the infosys functionality. Using an LDAP server with some schema is one way to publish information about your Computing Element. Comment out this block if you don’t want to run an LDAP-based information system.
Warning
CHANGE: NEW block in 6.0.0.
hostname
Synopsis: hostname = FQDN
Description:
the hostname of the machine running the slapd service
will be the bind for slapd. If not present, will be taken from the [common]
Default: $VAR{[common]hostname}
Example:
hostname=my.testbox
slapd_hostnamebind
Synopsis: slapd_hostnamebind = string
Description: May be used to set the hostname part of the network interface to which the slapd process will bind. Most of the cases no need to set since the hostname parameter is already sufficient. The example below will bind the slapd process to all the network interfaces available on the server.
Default: undefined
Example:
slapd_hostnamebind=*
port
Synopsis: port = port_number
Description: The port on which the slapd service runs. The default infosys port is assumed to be 2135 by many clients, therefore think twice before you change it because 3rd party clients assume 2135 to be the ldap infosys port.
Default: 2135
Example:
port=2135
user
Synopsis: user = unix_user
Description: overwrites the unix user running the slapd.
By default the startup scripts search for well-known ldap-users like ldap or openldap
than fall-back to root if not found.
Default: undefined
Example:
user=slapd
Warning
CHANGE: MOVED in 6.0.0 from [infosys].
slapd
Synopsis: slapd = path
Description:
explicitly define the path to slapd command.
By default the startup scripts search for slapd binary in the system PATH.
Default: undefined
Example:
slapd=/usr/sbin/slapd
slapd_loglevel
Synopsis: slapd_loglevel = number
Description: Sets the native slapd loglevel (see man slapd). Slapd logs via syslog. The default is set to no-logging (0) and it is RECOMMENDED not to be changed in a production environment. Non-zero slap_loglevel value causes serious performance decrease.
Default: 0
Example:
slapd_loglevel=0
threads
Synopsis: threads = number
Description: The native slapd threads parameter, default is 32.
Default: 32
Example:
threads=128
timelimit
Synopsis: timelimit = seconds
Description: The native slapd timelimit parameter. Maximum number of seconds the slapd server will spend answering a search request. Default is 3600. You probably want a much lower value.
Default: 3600
Example:
timelimit=1800
idletimeout
Synopsis: idletimeout = seconds
Description: The native slapd idletimeout parameter. Maximum number of
seconds the slapd server will wait before forcibly closing idle client
connections. It’s value must be larger than the value of timelimit option.
If not set, it defaults to timelimit + 1.
Default: $EVAL{$VAR{timelimit} + 1}
Example:
idletimeout=1801
infosys_ldap_run_dir
Synopsis: infosys_ldap_run_dir = path
Description: The location where NorduGrid/GLUE2 LDAP ldif file will be generated, and where the fifo to sync between infoproviders and BDII will be generated.
Default: /run/arc/infosys
Example:
infosys_ldap_run_dir=/run/arc/infosys
ldap_schema_dir
Synopsis: ldap_schema_dir = path
Description: Allows to explicitly specify an additional path to the schema files. Note that this doesn’t override standard location, but adds the specified path to the standard locations /etc/ldap and /etc/openldap. Normally it is sufficient to use only standard schema file locations, therefore not to set this parameter.
Default: undefined
Example:
ldap_schema_dir=/nfs/ldap/schema/
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
Synopsis: bdii_debug_level = level
Description: Set this parameter to DEBUG to check bdii errors in bdii-update.log At the same time don’t enable slapd logs this way reducing performance issues.
Default: WARNING
Example:
bdii_debug_level=ERROR
bdii_provider_timeout
Synopsis: bdii_provider_timeout = seconds
Description: (previously provider_timeout in bdii block) This variable allows a system administrator to modify the behaviour of bdii-update. This is the time BDII waits for the bdii provider scripts generated by A-REX infosys to produce their output.
Default: 10800
Example:
bdii_provider_timeout=10800
Warning
CHANGE: RENAMED parameter in 6.0.0.
BDII5 uses these variables. These might change depending on BDII version. ARC sets them by inspecting distributed bdii configuration files. DO NOT
Warning
CHANGE UNLESS YOU KNOW WHAT YOU’RE DOING
bdii_location
Synopsis: bdii_location = path
Description: The installation directory for the BDII.
Default: /usr
Example:
bdii_location=/usr
bdii_run_dir
Synopsis: bdii_run_dir = path
Description: Contains BDII pid files and slapd pid files
Default: /run/arc/bdii
Example:
bdii_run_dir=/run/arc/bdii
bdii_log_dir
Synopsis: bdii_log_dir = path
Description: Contains infosys logs
Default: /var/log/arc/bdii
Example:
bdii_log_dir=/var/log/arc/bdii
bdii_tmp_dir
Synopsis: bdii_tmp_dir = path
Description: Contains provider scripts
Default: /var/tmp/arc/bdii
Example:
bdii_tmp_dir=/var/tmp/arc/bdii
bdii_var_dir
Synopsis: bdii_var_dir = path
Description: Contains slapd databases
Default: /var/lib/arc/bdii
Example:
bdii_var_dir=/var/lib/arc/bdii
bdii_update_pid_file
Synopsis: bdii_update_pid_file = path
Description: Allows to change bdii-update pidfiles filename and location
Default: $VAR{bdii_run_dir}/bdii-update.pid
Example:
bdii_update_pid_file=/run/arc/bdii/bdii-update.pid
bdii_database
Synopsis: bdii_database = backend_type
Description: Configure what ldap database backend should
be used. If left undefined it will default to hdb for openldap versions
up to 2.4 and to mdb for openldap versions 2.5 and later.
Default: undefined
Example:
bdii_database=hdb
bdii_conf
Synopsis: bdii_conf = path
Description: Location of the bdii config file generated by ARC.
Default: $VAR{[infosys/ldap]infosys_ldap_run_dir}/bdii.conf
Example:
bdii_conf=/run/arc/infosys/bdii.conf
bdii_update_cmd
Synopsis: bdii_update_cmd = path
Description: path to bdii-update script
Default: $VAR{bdii_location}/sbin/bdii-update
Example:
bdii_update_cmd=/usr/sbin/bdii-update
bdii_db_config
Synopsis: bdii_db_config = path
Description: path to slapd database configuration file
Default: /etc/bdii/DB_CONFIG
Example:
bdii_db_config=/etc/bdii/DB_CONFIG
bdii_archive_size
Synopsis: bdii_archive_size = number
Description: Sets BDII_ARCHIVE_SIZE in bdii configuration file
Default: 0
Example:
bdii_archive_size=0
bdii_breathe_time
Synopsis: bdii_breathe_time = number
Description: Sets BDII_BREATHE_TIME in bdii configuration file
Default: 10
Example:
bdii_breathe_time=10
bdii_delete_delay
Synopsis: bdii_delete_delay = number
Description: Sets BDII_DELETE_DELAY in bdii configuration file
Default: 0
Example:
bdii_delete_delay=0
bdii_read_timeout
Synopsis: bdii_read_timeout = number
Description: Sets BDII_READ_TIMEOUT in bdii configuration file
Default: $EVAL{$VAR{bdii_provider_timeout} + $VAR{[arex]infoproviders_timelimit} + $VAR{[arex]wakeupperiod}}
Example:
bdii_read_timeout=300
Infosys Schema sub-blocks: The following infosys sub-blocks enable
information publishing according to various information schema.
In order to publish information in a certain schema, the corresponding
sub-block must be defined in addition to the schema-neutral [infosys/cluster]
and [queue:name] blocks!
Comment out a specific schema block if you don’t want to publish a specific
information schema representation.
Currently available information model (schema) sub-blocks:
[infosys/nordugrid]- The native ARC info representation of a cluster and its queues[infosys/glue2]- The GLUE2 information model, both LDAP and XML (the latter is for WS-interface)[infosys/glue2/ldap]- The LDAP rendering of the GLUE2 model[infosys/glue1]- The legacy GLUE1 model (only LDAP)[infosys/glue1/site-bdii]- The site BDII element of the GLUE1 legacy model
[infosys/nordugrid] block
Enables the publication of the NorduGrid information model in
the LDAP-based infosys. See the NORDUGRID-TECH-4 for schema definition.
The configuration block does not contain any parameter. The information tree
is populated based on the contents of the schema-neutral [infosys/cluster]
and [queue:name] blocks.
Warning
CHANGE: NEW block in 6.0.0.
[infosys/glue2] block
Enables the publication of the GLUE2 information model both in the LDAP and
XML rendering.
The information tree is populated based on the contents of the schema-neutral
[infosys/cluster] and [queue:name] blocks and the GLUE2 specific schema sub-blocks.
Warning
CHANGE: NEW block in 6.0.0.
AdminDomain entity parameters: 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
Example:
admindomain_name=ARC-TESTDOMAIN
admindomain_description
Synopsis: admindomain_description = text
Description: The free-form description of this domain.
Default: undefined
Example:
admindomain_description=ARC test Domain
admindomain_www
Synopsis: admindomain_www = url
Description: The URL pointing at a site holding information about the AdminDomain.
Default: undefined
Example:
admindomain_www=http://www.nordugrid.org/
admindomain_distributed
Synopsis: admindomain_distributed = yes/no
Description: Set this to yes if the domain is distributed that means, if the resources belonging to the domain are considered geographically distributed.
Allowed values: yes, no
Default: no
Example:
admindomain_distributed=yes
admindomain_owner
Synopsis: admindomain_owner = email
Description: The contact email of a responsible person for the domain
Default: undefined
Example:
admindomain_owner=admin@nordugrid.org
admindomain_otherinfo
Synopsis: admindomain_otherinfo = text
Description: Free-form text that fills the OtherInfo GLUE2 field. no need to set, used only for future development.
Default: undefined
Example:
admindomain_otherinfo=Test Other info
ComputingService entity parameters: computingservice_qualitylevel = qlevel - (previously infosys_glue2_service_qualitylevel) Allows a sysadmin to define different GLUE2 QualityLevel values for A-REX. Refer to GLUE2 documentation for the qualitylevel definitions.
Allowed values: production, pre-production, testing, development
Default: production
Example:
computingservice_qualitylevel=production
Warning
CHANGE: RENAMED in 6.0.0.s
[infosys/glue2/ldap] block
Enables the publication of the LDAP-rendering of the GLUE2 infomodel.
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.
Warning
CHANGE: NEW block in 6.0.0.
showactivities
Synopsis: showactivities = yes/no
Description: (previously infosys_glue2_ldap_showactivities) Enables GLUE2 ComputingActivities to appear in the LDAP rendering
Allowed values: yes, no
Default: no
Example:
showactivities=no
Warning
CHANGE: RENAMED in 6.0.0.
[infosys/glue1] block
This block enables the publication of GLUE1 LDAP representation of a CE.
The information tree is populated based on the contents of the schema-neutral
[infosys/cluster] and [queue:name] blocks and the GLUE1 specific schema sub-blocks.
This block holds information that is needed by the glue1, in addition to the
schema-neutral blocks.
Warning
CHANGE: RENAMED block in 6.0.0.
resource_location
Synopsis: resource_location = string
Description: GLUE1 location attribute. IMPORTANT: no slashes or backslashes here!
Default: undefined
Example:
resource_location=Kastrup, Denmark
resource_latitude
Synopsis: resource_latitude = latitude
Description: GLUE1 latitude.
Default: undefined
Example:
resource_latitude=55.75000
resource_longitude
Synopsis: resource_longitude = longitude
Description: GLUE1 longitude.
Default: undefined
Example:
resource_longitude=12.41670
cpu_scaling_reference_si00
Synopsis: cpu_scaling_reference_si00 = number
Description: GLUE1 CPU_scaling
Default: undefined
Example:
cpu_scaling_reference_si00=2400
processor_other_description
Synopsis: processor_other_description = string
Description: GLUE1 proc description
The text entered under this option is copied as in in the glue1
rendering of GlueHostProcessorOtherDescription.
Cores is used to calculate the number of physical processors for
GlueSubClusterPhysicalCPUs
The Benchmark value entered here is ignored by the rest
of ARC configuration. It will NOT be used for accounting.
Note that in ARC > 6.3 the proper way of configuring benchmark for both
infosys and accounting is by adding it to the [queue:name] blocks.
This generic string is kept here for backward compatibility,
and most likely will not work as expected (or as used by CREAM).
Default: undefined
Example:
processor_other_description=Cores=3,Benchmark=9.8-HEP-SPEC06
glue_site_web
Synopsis: glue_site_web = url
Description: GLUE1 site web url
Default: undefined
Example:
glue_site_web=http://www.ndgf.org
glue_site_unique_id
Synopsis: glue_site_unique_id = siteid
Description: GLUE1 site id
Default: undefined
Example:
glue_site_unique_id=NDGF-T1
[infosys/glue1/site-bdii] block
Enable this block ONLY if you want to publish a semi-fake GLUE1 site-bdii as part of the LDAP server. This block is used to configure ARC to generate a semi-fake site-bdii that can be registered in GOCDB. The default will generate an object that you can reference in GOCDB GIIS field as such:
ldap://archost.domain:2135/mds-vo-name=<unique-site-id>,o=grid Example: ldap://archost.domain:2135/mds-vo-name=NDGF-T1,o=grid
Since the original site-bdii listens on port 2170, you may want to port forward 2170 to 2135 in your firewall, but it is not a requirement. This fake site bdii is only good if you have a single ARC as a service in your organization. It cannot aggregate any information like the real site-bdii does. It just presents a partial rendering of a site-bdii that is good enough for top-bdii to pick up the information. GOCDB checks against this fake-site-bdii should be disabled as it is not fully compliant with the site-bdii specification. They will fail if enabled.
Warning
CHANGE: RENAMED block in 6.0.0.
unique_id
Synopsis: *unique_id = id
Description:
The unique id used to identify this site, eg NDGF-T1
Default: undefined
Example:
unique_id=NDGF-T1
url
Synopsis: *url = url
Description: This url is the insertion point in the arc Glue1 ldif tree
for the semi-fake site-bdii ldap object.
The content of the ldap object is mainly generated from the data in the
[infosys/glue1] block.
The url format is ldap://host.domain:ldapport/basedn
Example: ldap://host.domain:2135/o=grid
The generated site-bdii information will be attached under the basedn,
in the example for o=grid: mds-vo-name=unique-id,o=grid
In most cases you want to leave the default untouched, unless you know what you’re doing.
Default: ldap://localhost:2135/o=grid
Example:
url=ldap://host.domain:2135/o=grid
[infosys/cluster] block
Information schema-neutral blocks [infosys/cluster] and [queue:NAME] contain attributes
that describe the computing cluster together with its queues. The parameters are
available for every information model/schema representation.
This block describes the cluster characteristics of a Computing Element. The information specified here is mostly used by the Infosys ARC component.
alias
Synopsis: alias = text
Description: An arbitrary alias name of the cluster, optional.
Default: undefined
Example:
alias=Big Blue Cluster in Nowhere
hostname
Synopsis: hostname = fqdn
Description: Set the FQDN of the frontend.
Default: $VAR{[common]hostname}
Example:
hostname=myhost.org
interactive_contactstring
Synopsis: interactive_contactstring = url
Description: the contact URL for interactive logins, set this if the cluster supports some sort of grid-enabled interactive login (gsi-ssh),
This option in multivalued.
Default: undefined
Example:
interactive_contactstring=gsissh://frontend.cluster:2200
comment
Synopsis: comment = text
Description: Free text field for additional comments on the cluster in a single line, no newline character is allowed!
Default: undefined
Example:
comment=This cluster is specially designed for XYZ applications: www.xyz.org
cluster_location
Synopsis: cluster_location = formatted_string
Description: The geographical location of the cluster, preferably specified as a postal code with a two letter country prefix
Default: undefined
Example:
cluster_location=DK-2100
cluster_owner
Synopsis: cluster_owner = text
Description: It can be used to indicate the owner of a resource, multiple entries can be used
This option in multivalued.
Default: undefined
Example:
cluster_owner=World Grid Project
cluster_owner=University of NeverLand
advertisedvo
Synopsis: advertisedvo = vo_name
Description: (previously authorizedvo) This attribute is used to advertise which VOs are authorized on the cluster. Add only one VO for each advertisedvo entry. Multiple VOs in the same line will cause errors. These entries will be shown in all GLUE2 AccessPolicy and MappingPolicy objects, that is, they will apply for all Endpoints(Interfaces) and all Shares(currently queues). You can override the advertisedvos per queue. The information is also published in the NorduGrid schema.
Note
it is IMPORTANT to understand that this parameter is NOT enforcing any access control, it is just for information publishing!
This option in multivalued.
Default: undefined
Example:
advertisedvo=atlas
advertisedvo=community.nordugrid.org
Warning
CHANGE: RENAMED in 6.0.0.
clustersupport
Synopsis: clustersupport = email
Description: This is the support email address of the resource.
This option in multivalued.
Default: undefined
Example:
clustersupport=arc.support@mysite.org
clustersupport=arc.support@myproject.org
homogeneity
Synopsis: homogeneity = True/False
Description: Determines whether the cluster consists of identical NODES with respect to cputype, memory, installed software (opsys). The frontend is NOT needed to be homogeneous with the nodes. In case of inhomogeneous nodes, try to arrange the nodes into homogeneous groups assigned to a queue and use queue-level attributes. False may trigger multiple GLUE2 ExecutionEnvironments to be published if applicable.
Allowed values: True, False
Default: True
Example:
homogeneity=True
architecture
Synopsis: architecture = string
Description: Sets the hardware architecture of the NODES. The architecture
is defined as the output of the uname -m (e.g. i686). Use this cluster
attribute if only the NODES are homogeneous with respect to the architecture.
Otherwise the queue-level attribute may be used for inhomogeneous nodes. If
the frontend’s architecture agrees to the nodes, the adotf (Automatically
Determine On The Frontend) can be used to request automatic determination.
Default: adotf
Example:
architecture=adotf
opsys
Synopsis: opsys = formatted_string
Description: This multivalued attribute is meant to describe the operating system
of the computing NODES. Set it to the opsys distribution of the NODES and not
the frontend! opsys can also be used to describe the kernel or libc version
in case those differ from the originally shipped ones. The distribution name
should be given as distroname-version.number, where spaces are not allowed.
Kernel version should come in the form kernelname-version.number.
If the NODES are inhomogeneous with respect to this attribute do NOT set it on
cluster level, arrange your nodes into homogeneous groups assigned to a queue
and use queue-level attributes.
If opsys=adotf, will result in Automatic Determination of the Operating System
On The Frontend, which should only be used if the frontend has the same
OS as the nodes.
The adotf discovered values will be used to fill GLUE2 OSName, OSVersion
and OSFamily unless these values are explicitly defined for each queue.
See the [queue:queuename] block for their usage.
Note: Any custom value other than ‘adotf’ does NOT affect values in the GLUE2 schema.
This option in multivalued.
Default: adotf
Example:
opsys=Linux-2.6.18
opsys=glibc-2.5.58
opsys=CentOS-5.6
nodecpu
Synopsis: nodecpu = formatted_string
Description: This is the cputype of the homogeneous nodes. The string is
constructed from the /proc/cpuinfo as the value of model name and @ and
value of cpu MHz. Do NOT set this attribute on cluster level if the NODES
are inhomogeneous with respect to cputype, instead arrange the nodes into
homogeneous groups assigned to a queue and use queue-level attributes. Setting
the nodecpu=adotf will result in Automatic Determination On The Frontend,
which should only be used if the frontend has the same cputype as the
homogeneous nodes.
Default: adotf
Example:
nodecpu=AMD Duron(tm) Processor @ 700 MHz
nodememory
Synopsis: nodememory = number
Description: This is the amount of memory (specified in MB) on the node which can be guaranteed to be available for the application. Please note in most cases it is less than the physical memory installed in the nodes. Do NOT set this attribute on cluster level if the NODES are inhomogeneous with respect to their memories, instead arrange the nodes into homogeneous groups assigned to a queue and use queue-level attributes.
Default: undefined
Example:
nodememory=64000
middleware
Synopsis: middleware = string
Description: The multivalued attribute shows the installed grid software on the cluster. Nordugrid-ARC is automatically set, no need to specify
This option in multivalued.
Default: undefined
Example:
middleware=my software
nodeaccess
Synopsis: nodeaccess = inbound/outbound
Description: Determines how the nodes can connect to the internet.
Not setting anything means the nodes are sitting on a private isolated network.
outbound access means the nodes can connect to the outside world while
inbound access means the nodes can be connected from outside.
inbound & outbound access together means the nodes are sitting on a fully open network.
This option in multivalued.
Default: undefined
Allowed values: inbound, outbound
Example:
nodeaccess=inbound
nodeaccess=outbound
localse
Synopsis: localse = url
Description: This multivalued parameter tells the BROKER that certain URLs (and
locations below that) should be considered locally available to the cluster.
This option in multivalued.
Default: undefined
Example:
localse=gsiftp://my.storage/data1/
localse=gsiftp://my.storage/data2/
cpudistribution
Synopsis: cpudistribution = formatted_string
Description: This is the CPU distribution over nodes
given in the form ncpu:m where:
nis the number of CPUs per machinemis the number of such machines
Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with
3 single CPU machines, 4 dual CPU machines and one machine with 4 CPUs.
Default: undefined
Example:
cpudistribution=1cpu:3,2cpu:4,4cpu:1
maxcputime
Synopsis: maxcputime = number
Description: This is the maximum CPU time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxcputime=300000
mincputime
Synopsis: mincputime = number
Description: This is the minimum CPU time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
mincputime=1200
maxwalltime
Synopsis: maxwalltime = number
Description: This is the maximum Wall time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxwalltime=600000
minwalltime
Synopsis: minwalltime = number
Description: This is the minimum Wall time specified in seconds that the LRMS can allocate for the job. The default if not defined is that infoproviders get this value automatically from the LRMS. The purpose of this option is to tweak and override discovered value, or publish this value in case the LRMS module do not support automatic detection.
Default: undefined
Example:
maxwalltime=1800
[queue:name] block
Each grid-enabled queue on the cluster should be represented and described by a separate queue block. The queue_name should be used as a label in the block name. In case of fork, or other LRMSes with no queue names, just use any unique string. A queue can represent a PBS/LSF/SGE/SLURM/LL queue, a SGE pool, a Condor pool or a single machine in case ‘fork’ type of LRMS. This block describes the queue characteristics.
homogeneity
Synopsis: homogeneity = True/False
Description: determines whether the queue consists of identical NODES with respect to cputype, memory, installed software (opsys). In case of inhomogeneous nodes, try to arrange the nodes into homogeneous groups and assigned them to a queue. Possible values: True,False, the default is True.
Allowed values: True, False
Default: $VAR{[infosys/cluster]homogeneity}
Example:
homogeneity=True
comment
Synopsis: comment = text
Description: A free-form text field for additional comments on the queue in a single line, no newline character is allowed!
Default: undefined
Example:
comment=This queue is nothing more than a condor pool
pbs_queue_node
Synopsis: pbs_queue_node = string
Description: (previously 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
Example:
pbs_queue_node=gridlong_nodes
pbs_queue_node=ppn=4:ib
Warning
CHANGE: RENAMED in 6.0.0.
sge_jobopts
Synopsis: sge_jobopts = string
Description: Per-queue override of additional SGE options to be used when submitting jobs to SGE to this queue
Default: undefined
Example:
sge_jobopts=-P atlas -r yes
condor_requirements
Synopsis: condor_requirements = string
Description: It may be defined for each Condor queue.
Use this option to determine which nodes belong to the current queue.
The value of condor_requirements must be a valid constraints string
which is recognized by a condor_status -constraint ... command. It can
reference pre-defined ClassAd attributes (like Memory, Opsys, Arch, HasJava,
etc) but also custom ClassAd attributes. To define a custom attribute on a
condor node, just add two lines like the ones below in the $(hostname).local
config file on the node:
NORDUGRID_RESOURCE=TRUE
STARTD_EXPRS = NORDUGRID_RESOURCE, $(STARTD_EXPRS)
A job submitted to this queue is allowed to run on any node which satisfies
the condor_requirements constraint. If condor_requirements is not set,
jobs will be allowed to run on any of the nodes in the pool. When configuring
multiple queues, you can differentiate them based on memory size or disk
space, for example.
Default: $VAR{[lrms]condor_requirements}
Example:
condor_requirements=(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)
slurm_requirements
Synopsis: slurm_requirements = string
Description: Use this option to specify extra SLURM-specific parameters.
Default: undefined
Example:
slurm_requirements=memory on node >> 200
Warning
CHANGE: NEW in 6.0.0.
totalcpus
Synopsis: totalcpus = number
Description: Manually sets the number of cpus assigned to the queue. No need to specify the parameter in case the queue_node_string method was used to assign nodes to the queue (this case it is dynamically calculated and the static value is overwritten) or when the queue have access to the entire cluster (this case the cluster level totalcpus is the relevant parameter).
Default: undefined
Example:
totalcpus=32
queue-level configuration parameters: nodecpu, nodememory, architecture, opsys
should be set if they are homogeneous over the nodes assigned
to the queue AND they are different from the cluster-level value.
Their meanings are described in the [infosys/cluster] block.
Usage: this queue collects nodes with nodememory=512 while another queue has nodes
with nodememory=256 -> don’t set the cluster attributes but use the queue-level
attributes. When the frontend’s architecture or cputype agrees with the queue
nodes, the adotf (Automatically Determine On The Frontend) can be used to
request automatic determination of architecture or nodecpu.
For GLUE2, fine tune configuration of ExecutionEnvironments’ OSName, OSVersion, OSFamily
is allowed with dedicated options osname,osversion,osfamily.
nodecpu
Synopsis: nodecpu = formatted_string
Description: see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]nodecpu}
Example:
nodecpu=AMD Duron(tm) Processor @ 700 MHz
nodememory
Synopsis: nodememory = number
Description: see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]nodememory}
Example:
nodememory=512
defaultmemory
Synopsis: defaultmemory = number
Description: The LRMS memory request of job to be set by the LRMS backend
scripts, if a user submits a job without specifying how much memory should be used.
The order of precedence is: job description -> [lrms-defaultmemory] -> [queue-defaultmemory].
This is the amount of memory (specified in MB) that a job will request.
Default: undefined
Example:
defaultmemory=512
Warning
CHANGE: NEW in 6.0.0.
architecture
Synopsis: architecture = string
Description:
see description at [infosys/cluster] block
Default: $VAR{[infosys/cluster]architecture}
Example:
architecture=adotf
opsys
Synopsis: opsys = formatted_string
Description: see description at [infosys/cluster] block
If osname, osversion are present, the values in opsys are ignored.
This option in multivalued.
Default: $VAR{[infosys/cluster]opsys}
Example:
opsys=Linux-2.6.18
opsys=glibc-2.5.58
osname
Synopsis: osname = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osname=Ubuntu
osversion
Synopsis: osversion = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osversion=12.04
osfamily
Synopsis: osfamily = string
Description: Only for GLUE2 overrides values defined in opsys for a single ExecutionEnvironment. Configuration of multiple ExecutionEnvironment for the same queue is not supported. Create a different queue for that.
Default: undefined
Example:
osfamily=linux
benchmark
Synopsis: benchmark = name value
Description: Defines resource benchmark results for accounting and information publishing. The nodes in the same queue are assumed to be homogeneous with respect to the benchmark performance.
Note
in ARC < 6.4 this parameter is only used for information publishing.
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 are accept HEPscore23, HEPSPEC or Si2k benchmark types only.
This option in multivalued.
Default: HEPSPEC 1.0
Example:
benchmark=HEPscore23 16.5
benchmark=HEPSPEC 12.26
benchmark=Si2k 3065
Warning
CHANGE: MODIFIED IN 6.4.0.
allowaccess
Synopsis: allowaccess = authgroup
Description:
(previously groupcfg) Defines that the specified authgroup members
are authorized to submit jobs to this queue of ARC-CE after the user already granted access to the CE via one of the interfaces.
A related config option the denyaccess (see below) can be used to deny submission to the queue.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then the queue is accessible by everyone already authorized.
Default: undefined
This option in multivalued.
Example:
allowaccess=biousers
allowaccess=atlasusers
denyaccess
Synopsis: denyaccess = authgroup
Description: Defines that the specified authgroup members
are NOT allowed to submit jobs to this queue of ARC-CE after despite the user is already granted access to the CE via one of the interfaces.
A related config option the allowaccess (see below) can be used to grant job submission to the queue.
Multiple allowaccess and denyaccess authorization statements are allowed within a configuration block.
These statements are processed sequentially in the order they are specified in the
config block. The processing stops on first allowaccess or denyaccess statement matching the authgroup membership.
If there are no authorization statements specified, then the queue is accessible by everyone already authorized.
Default: undefined
This option in multivalued.
Example:
denyaccess=blacklisted-for-the-queue
advertisedvo
Synopsis: advertisedvo = vo_name
Description: (previously authorizedvo) This attribute is used to advertise
which VOs are authorized on the [queue:name] of the cluster.
Add only one VO for each advertiseddvo entry. Multiple VOs in the same line
will cause errors.
These entries will be shown in the MappingPolicy objects, that is,
they will apply for the Shares that corresponds to the queue.
The information is also published in the NorduGrid schema.
Note
if you have also configured advertisedvo in the [infosys/cluster] block,
the result advertised VOs per queue will override whatever is defined in [infosys/cluster] block!
Note
it is IMPORTANT to understand that this parameter is NOT enforcing any access control, it is just for information publishing!
This option in multivalued.
Default: $VAR{[infosys/cluster]advertisedvo}
Example:
advertisedvo=atlas
advertisedvo=community.nordugrid.org
Warning
CHANGE: RENAMED in 6.0.0.
maxslotsperjob
Synopsis: maxslotsperjob = number
Description: This GLUE2 specific parameter configures the MaxSlotsPerJob value on a particular queue. This value is usually generated by LRMS infocollectors, but there are cases in which a system administrator might like to tweak it. Default is to publish what is returned by the LRMS, and if nothing is returned, NOT to publish the MaxSlotsPerJob attribute. If a system administrator sets the value here, that value will be published instead, regardless of what the LRMS returns. Each LRMS might have a different meaning for this value.
Default: undefined
Example:
maxslotsperjob=5
forcedefaultvoms
Synopsis: forcedefaultvoms = VOMS_FQAN
Description: specify VOMS FQAN which user will be assigned if his/her credentials contain no VOMS attributes.
Default: $VAR{[arex]forcedefaultvoms}
Example:
forcedefaultvoms=/vo/group/subgroup
Warning
CHANGE: documented in [queue] as described in [arex].
maxcputime = number - This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
maxcputime=300000
mincputime
Synopsis: mincputime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
mincputime=1200
maxwalltime
Synopsis: maxwalltime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
maxwalltime=600000
minwalltime
Synopsis: minwalltime = number
Description: This value overrides the one defined in
the [infosys/cluster] block. See description in that block.
Default: undefined
Example:
minwalltime=1800
[datadelivery-service] block
This block configures and enables the data delivery service. This service is intended to off-load data-staging from A-REX and usually deployed on one or more separate machines.
This service can also act as an independent data transfers service that case it would require an inteligent data manager that could replace A-REX’s intelligence.
Warning
CHANGE: NEW block in 6.0.0.
transfer_dir
Synopsis: *transfer_dir = path
Description: (previously allowed_dir) The directori(es) on the DDS host in which the service is allowed to read and write. When DDS is used as a remote transfer service assisting A-REX then this is usually one or more cache and/or session directories shared as a common mount with A-REX.
This option in multivalued.
Default: undefined
Example:
transfer_dir=/shared/arc/cache
transfer_dir=/shared/arc/session
Warning
CHANGE: NEW in 6.0.0.
hostname
Synopsis: hostname = FQDN
Description: The hostname of the machine on which DDS service runs.
Default: $EXEC{hostname -f}
Example:
hostname=localhost
Warning
CHANGE: NEW in 6.0.0.
port
Synopsis: port = port
Description: Port on which service listens
Default: 443
Example:
port=8443
Warning
CHANGE: NEW in 6.0.0.
pidfile
Synopsis: pidfile = path
Description: pid file of the daemon
Default: /run/arched-datadelivery-service.pid
Example:
pidfile=/run/arched-datadelivery-service.pid
Warning
CHANGE: NEW in 6.0.0.
logfile
Synopsis: logfile = path
Description: log file of the daemon
Default: /var/log/arc/datadelivery-service.log
Example:
logfile=/tmp/delivery.log
Warning
CHANGE: NEW in 6.0.0.
loglevel
Synopsis: loglevel = level
Description: set loglevel of the data delivery service between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
Allowed values: 0, 1, 2, 3, 4, 5
Default: 3
Example:
loglevel=4
Warning
CHANGE: NEW in 6.0.0.
user
Synopsis: user = username
Description: Overwrites the user under which the service runs. The default is the user starting the service. DDS is very limited if not run as root.
Default: undefined
Example:
user=ddsuser
Warning
CHANGE: NEW in 6.0.0.
secure
Synopsis: secure = yes/no
Description:
Set to no if the service should run without a host certificate. In this case
the corresponding deliveryservice option in the [arex/data-staging] A-REX configuration block
should use http rather than https URLs.
Allowed values: yes, no
Default: yes
Example:
secure=no
Warning
CHANGE: NEW in 6.0.0.
allowed_ip
Synopsis: *allowed_ip = ip
Description: IP address authorized to access service. Normally this is the A-REX host IP. By default the delivery service listens on all available interfaces, so if both IPv4 and IPv6 are enabled on this and the A-REX host, remember to add both A-REX host IPs here.
This option in multivalued.
Default: undefined
Example:
allowed_ip=192.0.2.1
allowed_ip=2001:db8:85a3::8a2e:370:7334
Warning
CHANGE: NEW in 6.0.0.
allowed_dn
Synopsis: allowed_dn = DN
Description: DN authorized to access service. This option restricts access to specified DNs (of the users who submit jobs to A-REX). It is only effective if secure=yes.
This option in multivalued.
Default: undefined
Example:
allowed_dn=/O=Grid/O=Big VO/CN=Main Boss
Warning
CHANGE: NEW in 6.0.0.
x509_host_key
Synopsis: x509_host_key = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: NEW in this block in 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: NEW in this block in 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
Warning
CHANGE: NEW in this block in 6.0.0.
[acix-scanner] block
The ARC Cache Index (ACIX) is a distributed system that maintains a catalog of locations of cached files stored in various A-REX caches. ACIX consists of two components, the Cache Scanner (on the CEs), and the Index Server.
This config block enables and configures the cache scanner component of ACIX. The scanning component of ACIX is a separate service that runs alongside A-REX/DDS and all it needs from A-REX/DDS service is the location of the cache.
The acix-scanner periodically scans the cache directories and composes a Bloom filter of A-REX cache content which can be pulled via its public interface. In the current deployment the ACIX index services are the main consumers of the collected information.
Warning
CHANGE: RENAMED block, RENAMED component in 6.0.0 (cache scanner, instead of cacheserver)
cachedir
Synopsis: cachedir = cache_path
Description:
Specifies the cache directory to be scanned in case not set in
[arex/cache] block (e.g. the scanner is running on a different machine then A-REX)
This option in multivalued.
Default: $VAR{[arex/cache]cachedir}
Example:
cachedir=/scratch/cache
cachedir=/fs1/cache drain
logfile
Synopsis: logfile = path
- Description:
Log file location for the acix-scanner.
Default: /var/log/arc/arc-acix-scanner.log
Example:
logfile=/tmp/arc-acix-scanner.log
Warning
CHANGE: MODIFIED default for the logfile.
hostname
Synopsis: hostname = string
Description: Hostname on which the acix-scanner listens
Default: $EXEC{hostname -f}
Example:
hostname=myhost.org
port
Synopsis: port = port
Description: Port on which the acix-scanner service listens
Default: 5443
Example:
port=6000
cachedump
Synopsis: cachedump = yes/no
Description: Whether to make a dump of the list of files on the cache at $TMP/ARC-ACIX/timestamp each time the acix-scanner runs.
Default: no
Allowed values: yes, no
Example:
cachedump=yes
x509_host_key
Synopsis: x509_host_key = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: NEW in this block from 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: NEW in this block from 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
Warning
CHANGE: NEW in this block from 6.0.0.
[acix-index] block
The ARC Cache Index (ACIX) is a distributed system that maintains a catalog of locations of cached files stored in various A-REX caches. ACIX consists of two components, the Cache Scanner (on the CEs), and the Index Server. This config block enables and configures the index server component of ACIX.
The index server component of ACIX collects cache content filters generated by a set of acix-scanners and maintains an aggregated view of distributed cache contents.
The acix-index server is deployed separately and can be queried for the location of cached files.
The service endpoint is https://hostname:6443/data/index and a query is
performed via giving the URLs to check as comma-separated values to the url option, e.g.:
index_service_endpoint?url=http://www.nordugrid.org:80/data/echo.sh,http://my.host/data1
cachescanner
Synopsis: *cachescanner = url
Description: (previously cacheserver) ACIX cache scanners from which to pull information
This option in multivalued.
Default: undefined
Example:
cachescanner=https://some.host:5443/data/cache
cachescanner=https://another.host:5443/data/cache
Warning
CHANGE: RENAMED in 6.0.0.
x509_host_key
Synopsis: x509_host_key = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: NEW in this block from 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: NEW in this block from 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
Warning
CHANGE: NEW in this block from 6.0.0.
[userlist:name] block
The [userlist:name] blocks are used to define userlists and configure how those are
generated by the nordugridmap utility, including the optional user mapping information.
The userlist is identified with the generated file that is stored in the outfile.
Please note that behaviour of the nordugridmap external utility can be further modified by
the optional [nordugridmap] block (see next block).
Note that the [userlist:name] block by itself does not affect authorization. In order to define
auth rules userlists can be referenced within the [authgroup] blocks by the userlist=name
parameter.
Also, the generated outfile can be used via the ‘file’ auth rule of the [authgroup] block.
The order of this block in arc.conf may influence authorization decision. This block must
appear before the [arex] block.
Warning
CHANGE: RENAMED block in 6.0.0: blockname now better reflects the purpose of the config block. This block is not defining any VO!
outfile
Synopsis: outfile = path
Description:
(previously file) The full path of the GENERATED file that contains the
userlist (with optional mapping info).
If the same file specified as output for different [userlist:name] blocks
then nordugridmap will automatically merge entries following the order of the blocks.
Default: /etc/grid-security/grid-mapfile
Example:
outfile=/etc/grid-security/lists/atlas-users
Warning
CHANGE: RENAMED in 6.0.0.
source
Synopsis: *source = url
Description: the URL of the VO database which is used to generate the userlist. The nordugridmap will use this URL to automatically generate and keep up-to-date userlist (mapfile) specified by the ‘outfile’ attribute.
url is a multivalued attribute, several sources can be specified and all the users from those sources will be merged into the same file. The source URLs are processed in the given order.
Currently supported URL types are:
http(s)://URL to plain text file. File should contain a list of DNs.
voms(s)://URL to VOMS-Admin interface
file://local file (stand-alone or dynamicaly generated by
nordugridmap). File should contain a list of DNs with optional mapped unixid:user DN[mapped user ID]Result of optional mapped unixid processing depend onmapuser_processingoption settings.userlist://reference to another
[userlist/name]configuration blocknordugridadd NorduGrid VO members
You can use either userlist:// or file:// entries to specify dependencies
between [userlist/name] blocks, but using userlist:// is a recommended way.
For each separate source URL it is possible to override some parameters value. You can use the following syntax to perform this:
"source=URL < parameter1=value1 parameter2=value2"
You can override the following parameters:
mapped_unixidfor http(s),voms(s),ldap and file URLs
cache_enablefor http(s),voms(s),ldap and file URLs
voms_methodfor voms(s) URLs
mapuser_processingfor file URLs with
mapped_unixid='<unixid>'overrided (controlmapped_unixidoverriding behaviour for URL)
This option in multivalued.
Default: undefined
Example:
source=vomss://voms.ndgf.org:8443/voms/nordugrid.org
source=vomss://lcg-voms.cern.ch:8443/voms/atlas?/atlas/Role=VO-Admin < mapped_unixid=atlasadmin
source=vomss://kuiken.nikhef.nl:8443/voms/gin.ggf.org < voms_method=get
source=http://www.nordugrid.org/developers.dn
source=file:///etc/grid-security/priviliged_users.dn
source=userlist://biousers
source=nordugrid
Warning
CHANGE: MODIFIED options in 6.0.0: edg-mkgridmap source option is removed (obsolete technology); vo source option is renamed as userlist.
mapped_unixid
Synopsis: mapped_unixid = unixid
Description: The local UNIXID which is optionally used in the generated outfile by the nordugridmap utility.
If any of the sources have already provided mapping information (file://
or userlist://) behavior depends on ‘mapuser_processing’ from the [nordugridmap] block:
mapuser_processing = overwriteignore already provided mapping and apply
mapped_unixidfor all sourcesmapuser_processing = keepapply mapped_unixid only for sources that does not already has mapping information
If the mapped_unixid config parameter is not specified or has empty value,
then behavior depends on the value of allow_empty_unixid from the
[nordugridmap] block:
allow_empty_unixid = yesempty value will be used for
mapped_unixidwhich means that nordugridmap will generate only the list of DNs without mapping (consider usingmapuser_processing = overwritealong with this option or sources that does not provide previously defined mapping information)allow_empty_unixid = nothen nordugridmap will skip users without mapping information (if no mapping information provided by sources)
Default: nobody
Example:
mapped_unixid=
mapped_unixid=gridtest
Warning
CHANGE: MODIFIED in 6.0.0. The empty value should work the same way as missing parameter. set the default to nobody
voms_fqan_map
Synopsis: voms_fqan_map = fqan unixid
Description: The local UNIXID which is used to map voms(s) sources with specific FQAN given.
Several voms_fqan_map can be specified for a [userlist/name] block.
For each voms(s) sources in [userlist/name] block and every voms_fqan_map record
separate source record will be automatically generated with mapped_unixid
overwritten to specified one.
Sources are generated in a given voms_fqan_map order. Original voms(s) source URL are processed LAST.
This allows to simplify configuration, especially in redundancy cases when several VOMS servers are used for the same VO.
This option in multivalued.
Default: undefined
Example:
voms_fqan_map=/atlas/Role=VO-Admin atlasadmin
voms_fqan_map=/atlas/Role=production atlasprod
filter
Synopsis: filter = ACL string
Description: An ACL filter for the nordugridmap utility. Multiple allow/deny statements are possible. The fetched DNs are filtered against the specified rules before they are added to the generated outfile.
* can be used as a wildcard. You may run the nordugridmap with the --test
command line option to see how the filters you specified work.
If at least one allow filter is specified implicit deny is used at the end of ACL. If only deny filters are present - implicit allow used at the end.
This option in multivalued.
Default: undefined
Example:
filter=deny *infn*
filter=allow *NorduGrid*
[nordugridmap] block
This optional block is used to fine-tune the behavior of the
nordugridmap utility - an ARC tool used to generate grid-mapfiles.
Normal setups don’t need to configure this block.
Please refer to [userlist/name] block above to find information how
to specify sources for userlist generation. This section setup
general source-independent parameters.
x509_host_key
Synopsis: x509_host_key = path
Description: Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_key}
Example:
x509_host_key=/etc/grid-security/hostkey.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_host_cert
Synopsis: x509_host_cert = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_host_cert}
Example:
x509_host_cert=/etc/grid-security/hostcert.pem
Warning
CHANGE: RENAMED in 6.0.0.
x509_cert_dir
Synopsis: x509_cert_dir = path
Description:
Optional parameter to overwrite [common] block values.
Default: $VAR{[common]x509_cert_dir}
Example:
x509_cert_dir=/etc/grid-security/certificates
gridmap_owner
Synopsis: gridmap_owner = username
Description: The owner of the generated mapfiles.
Default: root
Example:
gridmap_owner=root
gridmap_group
Synopsis: gridmap_group = groupname
Description: The group of generated gridmapfiles.
Default: root
Example:
gridmap_group=root
gridmap_permissions
Synopsis: gridmap_permissions = filemode
Description: The permissions of generated gridmapfiles.
Default: 0600
Example:
gridmap_permissions=0600
log_to_file
Synopsis: log_to_file = yes/no
Description: control whether logging output of nordugridmap will be saved to file. If the value is ‘no’ nordugridmap will write all information to STDERR.
Allowed values: yes, no
Default: yes
Example:
log_to_file=no
logfile
Synopsis: logfile = path
Description: specify the nordugridmap log file location when log_to_file is set yes.
Default: /var/log/arc/nordugridmap.log
Example:
logfile=/var/log/arc/nordugridmap.log
cache_enable
Synopsis: cache_enable = yes/no
Description: Controls whether caching of external sources will be used.
Allowed values: yes, no
Default: yes
Example:
cache_enable=yes
cachedir
Synopsis: cachedir = path
Description: Specifies the path where cached sources will be stored.
Default: /var/spool/arc/gridmapcache/
Example:
cachedir=/var/spool/arc/gridmapcache/
cachetime
Synopsis: cachetime = seconds
Description: Controls how long (in seconds) the cached information remains valid. Default is 259200 (3 days).
Default: 259200
Example:
cachetime=259200
mapuser_processing
Synopsis: mapuser_processing = owerwrite/keep
Description: Controls the behavior of [userlist:name] block’s mapped_unixid
parameter usage.
Please see ‘mapped_unixid’ description in [userlist:name] block for details.
Allowed values: keep, overwrite
Default: keep
Example:
mapuser_processing=keep
allow_empty_unixid
Synopsis: allow_empty_unixid = yes/no
Description: Controls whether empty (or unspecified)
‘mapped_unixid’ [userlist:name] block option is allowed to be used.
Please see ‘mapped_unixid’ description for details.
Allowed values: yes, no
Default: yes
Example:
allow_empty_unixid=no
Warning
CHANGE: MODIFIED in 6.0.0.
voms_method
Synopsis: voms_method = soap/get
Description: Controls how to get information from VOMS(S) sources. Valid values are:
soap - call SOAP method directly using SOAP::Lite get - use old implementation that manually parses XML response
Allowed values: soap, get
Default: soap
Example:
voms_method=soap
loglevel
Synopsis: loglevel = level
Description: (previously debug) Controls the verbosity of nordugridmap output. Valid values are:
0 - FATAL - only critical fatal error shown 1 - ERROR - errors, including non-critical are shown 2 - WARNING (default) - configuration errors that can be ignored 3 - INFO - processing information 4 - VERBOSE - a bit more processing information 5 - DEBUG - lot of processing information
When test run is requested (–test command line option of the nordugridmap) loglevel is automatically set to 5 (DEBUG).
Allowed values: 0, 1, 2, 3, 4, 5
Default: 2
Example:
loglevel=4
Warning
CHANGE: RENAMED in 6.0.0.
fetch_timeout
Synopsis: fetch_timeout = seconds
Description: Controls how many time (in seconds) nordugridmap will wait for external sources retrieval.
Default: 15
Example:
fetch_timeout=15
[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.
Configuration options removed in ARC 6.8.0
[arex/jura] block
urdelivery_keepfailed
Synopsis: urdelivery_keepfailed = days
Description: (deprecated in 6.4.0) Specifies for how many days JURA will try to send a record to the destination accounting service before it gives up. Records not successfully sent by after the number of days expired will be deleted from the controldir/logs directory. The deleted records are nevertheless archived if archiving was turned on. Scatring from 6.4 all records are stored in the accounting database without expiration time independently of publishing process.
Default: 30
Example:
urdelivery_keepfailed=30
Warning
CHANGE: DEPRECATED in 6.4.0
[arex/jura/sgas:targetname] block
legacy_fallback
Synopsis: legacy_fallback = yes/no
Description:
(introduced in 6.4.0) If set to yes then accounting records
publishing to this target will be handled with the previous version of code (6.0-6.3)
that relies on A-REX job log files. Use this option only if you experience problems
with the new Jura.
Default: no
Example:
legacy_fallback=no
Warning
CHANGE: NEW in 6.4.0.
[arex/jura/apel:targetname] block
use_ssl
Synopsis: use_ssl = yes/no
Description:
(deprecated in 6.4.0) Turns on/off ssl for the SSM
communication with APEL server. Use only with ARC version < 6.4.0.
In ARC 6.4+ targeturl protocol defines the usage of SSL.
Allowed values: yes, no
Default: no
Example:
use_ssl=yes
Warning
CHANGE: DEPRECATED in 6.4.0.
benchmark_type
Synopsis: benchmark_type = type
Description:
(deprecated in 6.4.0) Type of benchmark (Si2k, HEPSPEC)
to be reported in every UR.
Starting from 6.4 no need to specify the benchmark values here as those will be
taken from the [queue] block benchmark option.
Default: undefined
Example:
benchmark_type=HEPSPEC
Warning
CHANGE: DEPRECATED in 6.4.0.
benchmark_value
Synopsis: benchmark_value = number
Description:
(deprecated in 6.4.0) The value of the of benchmark
to be reported in every UR.
Starting from 6.4 no need to specify the benchmark values here as those will be
taken from the [queue] block benchmark option.
Default: undefined
Example:
benchmark_value=2.4
Warning
CHANGE: DEPRECATED in 6.4.0.
benchmark_description
Synopsis: benchmark_description = string
Description: (deprecated in 6.4.0) Additional description for the benchmark to be reported in every UR.
Default: undefined
Example:
benchmark_description=some description for benchmark
Warning
CHANGE: DEPRECATED in 6.4.0.
legacy_fallback
Synopsis: legacy_fallback = yes/no
Description:
(introduced in 6.4.0) If set to yes then accounting records
publishing to this target will be handled with the previous version of code (6.0-6.3)
that relies on A-REX job log files. Use this option only if you experience problems
with the new Jura.
Default: no
Example:
legacy_fallback=no
Warning
CHANGE: NEW in 6.4.0.
[arex/jura/archiving] block
This block enables the archiving functionality of pre 6.4 jura implementaton
Note
starting from ARC 6.4.0, with the next generation accounting subsystem
introduction, this block only takes action if the legacy_fallback option
is set to yes for a target. In 6.4 all accounting data is stored in the database
eliminating the need of any additional records archiving.
When enabled the usage records generated by JURA are stored
in a the specified archivedir directory on the disk.
Stored records are than processed by accounting archive manager that process the records, store data into SQLite accounting archive database, create new archive structure and maintains the accounting database aging.
By default the archiving is turned off.
Warning
CHANGE: DEPRECATED in 6.4.0.
archivedir
Synopsis: archivedir = path
Description:
Sets the directory path for the jura archived usage records.
Usage records generated by jura reporter are stored in this directory with
the following file naming convention used::
usagerecord<Type>.<jobid>.<random>.
Here Type is one of the supported record formats such as OGFUR or CAR.
Default: /var/spool/arc/jura/archive
Example:
archivedir=/var/spool/arc/jura/archive
logfile
Synopsis: logfile = path
Description: The name of the accounting database manager logfile.
Default: /var/log/arc/jura-archive-manager.log
Example:
logfile=/var/log/arc/jura-archive-manager.log
archivettl
Synopsis: archivettl = days
Description: The records time to live (ttl) parameter sets the number of days to keep the usage record files in the accounting database If not specified the files are kept forever.
Default: undefined
Example:
archivettl=365