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:

  1. All trailing and leading spaces on each confiuration line are stripped and ignored. This aplies both to block headers and block content.

  2. All spaces around the = sign in option=value kind of string (after ‘a’ is applied) are stripped and ignored. For example line hostname = myhost.info is treated as identical to hostname=myhost.info.

  3. In block headers of [keyword] kind (after ‘a’ is applied) no additional spaces are allowed around keyword and inside keyword.

  4. In block headers of [keyword:identifier] kind (after ‘a’ is applied) no additional spaces are allowed around keyword and inside both keyword and identifier. The spaces ARE allowed around identifier part and stripped and ignored.

Mandatory configuration options are indicated by an asterix prefix to the option name e.g: *mandatory_configoption. Mandatory options with undefined values will result in service stop during the startup process.

Each of the configuration options have well-defined default that is specified in this reference file. The default can take either a pre-set value, a special substitution or the keyword undefined. Configuration options within an enabled block take their default values in case they are missing (or commented out). Configuration parameters with undefined defaults takes no values. Furthermore, configuration options within disabled blocks takes no values either.

Configuration blocks are ORDER-DEPENDENT. 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:

relaxed

use everything that passed validation.

standard

same as relaxed but fail if parsing errors took place and VOMS extension is marked as critical. This is a default.

strict

fail if any parsing error was discovered

noerrors

fail if any parsing or validation error happened.

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 authgroup members are mapped

  • policy rules that modifies the mapping rules sequence processing

Default policy for mapping rules processing is:

  • processing CONTINUES to the next rule if identity of user DO NOT match authgroup specified in the rule (can be redefined with policy_on_nogroup option)

  • processing STOPS if identity of user match authgroup specified in the mapping rule. Depend on whether this mapping rule returns valid UNIX identity the processing can be redefined with policy_on_map and policy_on_nomap options.

Policy can be redefined at the any point of configuration sequence and affects all mapping rules defined after the polcy rule.

Note

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:

timeout

Define the timeout in days (default is 10) after which the UNIX account can be reassigned to another user if not used. The 0 value means no lease expiration.

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

shared_filesystem

Synopsis: shared_filesystem = yes/no

Description: Specifies if computing nodes can access folders mounted with protocols like NFS with the same pathnames as the frontend. Note that the default ‘yes’ assumes that the paths to the session directories are the same on both frontend and nodes. If these paths are not the same, then one should set the scratchdir option. The option changes the RUNTIME_NODE_SEES_FRONTEND variable in the submission scripts.

Allowed values: yes, no

Default: yes

Example:

shared_filesystem=yes

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/

shared_scratch

Synopsis: shared_scratch = path

Description: The path on frontend where scratchdir can be found. If defined should contain the path corresponding to that set in scratchdir as seen on the frontend machine. Sets the environment variable RUNTIME_FRONTEND_SEES_NODE.

Default: undefined

Example:

shared_scratch=/mnt/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:

timeout

defines the timeout in seconds to wait for plugin execution (timeout= can be omitted).

onsuccess, onfailure, ontimeout

defines the action that A-REX should take on successful execution (exit code 0), failed execution (exit code is not 0) or execution timeout respectively.

Possible actions are:

  • pass - continue executing job,

  • fail - cancel job,

  • log - write to log about the failure and continue executing job.

It is possible to use following sugstitutions to construct plugin command line:

  • %R - session root (value of sessiondir in [arex] block)

  • %C - controldir path

  • %U - username of mapped UNIX account

  • %u - numeric UID of mapped UNIX account

  • %g - numeric GID of mapped UNIX account

  • %H - home directory of mapped UNIX account as specified in /etc/passwd

  • %Q - default queue (see lrms configuration option in [lrms] block)

  • %L - LRMS name (see lrms configuration option in [lrms] block)

  • %W - ARC installation path (corresponds to the ARC_LOCATION environmental variable)

  • %F - path to configuration file for this instance

  • %I - job ID (substituted in runtime)

  • %S - job state (substituted in runtime)

Plugins included into ARC distribution:

  • arc-blahp-logger - write accounting log for every finished job in BLAH format

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

sharepolicy

Synopsis: sharepolicy = grouping

Description: (previously sharetype) Defines the mechanism to be used for the grouping of the job transfers. DTR assigns the transfers to shares, so that those shares can be assigned to different priorities. Possible values for grouping are dn, voms:vo, voms:role and voms:group:

dn

each job is assigned to a share based on the DN of the user sumbitting the job.

voms:vo

each job is assigned to a share based on the VO specified in the proxy.

voms:role

each job is assigned to a share based on the role specified in the first attribute found in the proxy.

voms:group

each job is assigned to a share based on the group specified in the first attribute found in the proxy.

In case of the voms schemes, if the proxy is not a VOMS proxy, then a default share is used. If sharepolicy is not set then the client-defined priority is applied.

Default: undefined

Example:

sharepolicy=voms:role

Warning

CHANGE: RENAMED in 6.0.0.

sharepriority

Synopsis: sharepriority = share priority

Description: (previously definedshare) Defines a share with a fixed priority, different from the default (50). Priority is an integer between 1 (lowest) and 100 (highest).

This option in multivalued.

Default: undefined

Example:

sharepriority=myvo:students 20
sharepriority=myvo:production 80

Warning

CHANGE: RENAMED in 6.0.0.

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:

  1. Regular expression defining a URL pattern

  2. Credential attribute to match against a client’s credential

  3. Regular expression defining a credential value to match against a client’s credential

A client is allowed to access the cached file if a URL pattern matches the cached file URL and the client’s credential has the attribute and matches the value required for that pattern. Possible values for credential attribute are dn, voms:vo, voms:role and voms:group.

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 others access 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 owner and owning group will be group. If * is used, the user/group to which connected user is mapped will be used. The permissions will be set to permissions_or & permissions_and. (second number is reserved for the future usage).

mkdir owner:group permissions_or:permissions_and

allow creating new directories.

Example 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:

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

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:

n is the number of CPUs per machine m is the number of such machines

Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with 3 single CPU machines, 4 dual CPU machines and one machine with 4 CPUs.

Default: undefined

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 on mapuser_processing option settings.

userlist://

reference to another [userlist/name] configuration block

nordugrid

add 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_unixid

for http(s),voms(s),ldap and file URLs

cache_enable

for http(s),voms(s),ldap and file URLs

voms_method

for voms(s) URLs

mapuser_processing

for file URLs with mapped_unixid='<unixid>' overrided (control mapped_unixid overriding 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 = overwrite

ignore already provided mapping and apply mapped_unixid for all sources

mapuser_processing = keep

apply mapped_unixid only for sources that does not already has mapping information

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 = yes

empty value will be used for mapped_unixid which means that nordugridmap will generate only the list of DNs without mapping (consider using mapuser_processing = overwrite along with this option or sources that does not provide previously defined mapping information)

allow_empty_unixid = no

then 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