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]
[lrms]
[lrms/ssh]
[arex]
[arex/cache]
[arex/cache/cleaner]
[arex/data-staging]
[arex/ws]
[arex/ws/jobs]
[arex/ws/cache]
[arex/ws/candypond]
[arex/ws/argus]
[arex/jura]
[arex/jura/archiving]
[arex/jura/sgas:targetname]
[arex/jura/apel:targetname]
[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 related to authorization are ORDER-DEPENDENT! The authorization blocks [authgroup:name] MUST be defined before used in the blocks such as [mapping], [arex/ws/jobs] or [gridftp/jobs]. The same rule applies to defining legacy [userlist:name] blocks. Furthermore, the order of the authorization blocks itself may have influence over authorization decisions!

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, 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 here 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

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

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.

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

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

plugin

Synopsis: plugin = timeout path [arg1 [arg2 [arg3...]]]

Description: Run external executable or function from shared library. Rule is matched if plugin returns 0. 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

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

[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: This is a new block

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=any 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=any /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). 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=altas 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

[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: This is a new block. 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: new lrmstype values added (slurmpy).

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 here from the [cluster] block

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 here 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 here 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 here from the [arex] block

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. moved here 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 parameter proposed in Umea retreat

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

[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

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

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

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)

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. 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. 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 succesfull 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 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: rename, infoproviders_timelimit, move to [arex] block

pidfile

Synopsis: pidfile = path

Description: Specify location of file containing PID of daemon process.

Default: /var/run/arched-arex.pid

Example:

pidfile=/var/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. implement a default! in the format of root@localhost.

gnu_time

Synopsis: gnu_time = path

Description: The gnu time command

Warning

CHANGE: moved to [lrms]

nodename

Synopsis: nodename = path

Description: The command to obtain hostname of computing node.

Warning

CHANGE: moved 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

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 stagein proces 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 sysadmin guide.

Warning

CHANGE: new block

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. Restart of arex also needed.

This option in multivalued.

Default: undefined

Example:

cachedir=/scratch/cache
cachedir=/shared/cache /frontend/jobcache
cachedir=/fs1/cache drain

[arex/cache/cleaner] block

This subblock enables the cleaning functionality of the cache. If this block is not enabled then the cache will not be cleaned by A-REX. Either cachesize or cachelifetime should also be set to enable cleaning.

Warning

CHANGE: new block

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 as logfile

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 as loglevel

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 parameter

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

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 as loglevel.

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

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, modified: 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: yes

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 here

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 here

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

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

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

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

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. 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. modified: set default as https://hostname:443/arex

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.

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

[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://www.nordugrid.org/documents/EMI-ES-Specification_v1.16.odt for EMIES inteface description and read the TO-BE-PROVIDED ARC-REST interface specification.

Warning

CHANGE: new subblock

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 parameter in this block. 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: rename. modify 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 parameter in this block. Implement support in the code for WS-interface.

[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

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, 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 for the Argus functionality. Change code so that Argus is turned on/off based on this block

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: remove cream (or at least hide from the arc.conf.reference)

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: remove cream (or at least hide from the arc.conf.reference)

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

JURA is the accounting record generating and reporting module of A-REX. A-REX periodically executes JURA to processes the job log files, and based on the accounting target destinations specified in them, JURA creates usage records in the appropriate format and sends the generated records to one or more accounting service destinations. Optionally, the generated accounting records can be archived on the CE. 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]

Warning

CHANGE: new dedicated block for JURA

Warning

CHANGE: A-REX should NOT provide the possibility of client-side target selection (in xrsl) any longer!

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

Warning

CHANGE: renamed.

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

Warning

CHANGE: new parameter! implement it in the code

vomsless_vo

Synopsis: vomsless_vo = voname[#voissuer]

Description: This parameter allows the sysadmin to manually assign VOs 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

Warning

CHANGE: new parameter.

vo_group

Synopsis: vo_group = group

Description: Adds an additional VO group attribute to the usage records.

Default: undefined

Example:

vo_group=/atlas/production

Warning

CHANGE: new parameter

urdelivery_keepfailed

Synopsis: urdelivery_keepfailed = days

Description: 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. This parameter can be overwritten with a target specific value.

Default: 30

Example:

urdelivery_keepfailed=30

Warning

CHANGE: new parameter.

urdelivery_frequency

Synopsis: urdelivery_frequency = seconds

Description: (previously jobreport_period) Specifies the frequency of message publishing: how often the JURA process is started by A-REX.

Default: 3600

Example:

urdelivery_frequency=3600

Warning

CHANGE: renamed

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 parameter in this block

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 parameter in this block

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 parameter in this block

[arex/jura/archiving] block

This block enables the archiving functionality to manage local accounting database.

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 database, create new archive structure and maintains the accounting database aging.

By default the archiving is turned off.

Warning

CHANGE: NEW block

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

Warning

CHANGE: NEW

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

Warning

CHANGE: NEW

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

Warning

CHANGE: new parameter. new feature to implement!

[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. The [arex/jura] config values are applicable for every target sub-block but also can be overwritten. You need to define a separate block with a unique targetname for every SGAS target server.

Warning

CHANGE: new dedicated sub-blocks for SGAS JURA targets

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 parameter

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 parameter

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 parameter

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. This option can also be set in the sgas/apel target blocks to overwrite common value.

Default: 50

Example:

urbatchsize=80

Warning

CHANGE: new parameter.

[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. The [arex/jura] config values are applicable for every target sub-block but also can be overwritten. You need to define a separate block with a unique targetname for every APEL target server.

Warning

CHANGE: new dedicated sub-blocks for APEL JURA targets

targeturl

Synopsis: *targeturl = url

Description: The service endpoint URL of the APEL accounting server.

Default: undefined

Example:

targeturl=https://mq.cro-ngi.hr:6162

Warning

CHANGE: new parameter

topic

Synopsis: topic = topic_name

Description: Sets the name of the APEL topic to which JURA will publish the accounting records.

Default: /queue/global.accounting.cpu.central

Example:

topic=/queue/global.accounting.test.cpu.central

Warning

CHANGE: new parameter.

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 record.

Default: undefined

Example:

gocdb_name=GRID_UIO_NO

Warning

CHANGE: new parameter.

benchmark_type

Synopsis: benchmark_type = type

Description: Type of benchmark (Si2k, Sf2k, HEPSPEC) to be reported in every UR.

Default: undefined

Example:

benchmark_type=HEPSPEC

Warning

CHANGE: new parameter

benchmark_value

Synopsis: benchmark_value = number

Description: The value of the of benchmark to be reported in every UR.

Default: undefined

Example:

benchmark_value=2.4

Warning

CHANGE: new parameter

benchmark_description

Synopsis: benchmark_description = string

Description: Additional description for the benchmark to be reported in every UR.

Default: undefined

Example:

benchmark_description=some description for benchmark

Warning

CHANGE: new parameter

use_ssl

Synopsis: use_ssl = yes/no

Description: Turns on/off ssl for the SSM communication with APEL server.

Allowed values: yes, no

Default: no

Example:

use_ssl=yes

Warning

CHANGE: new parameter

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 parameter

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. This option can also be set in the sgas/apel target blocks to overwrite common value.

Default: 1000

Example:

urbatchsize=1000

Warning

CHANGE: new parameter. new default.

[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

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 from deleted [gangliarc] block and renamed. Path used in arc-ganglia implementation JobsMetrics.cpp

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

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: /var/run/gridftpd.pid

Example:

pidfile=/var/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 as allowencryption

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

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

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: rename. modify 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

[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

loglevel

Synopsis: loglevel = number

Description: (previously provider_loglevel) The loglevel for the infoprovider scripts (0-5). The infosys default is 1 (critical errors are logged) 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: 1

Example:

loglevel=3

Warning

CHANGE: renamed

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

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 here 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: /var/run/arc/infosys

Example:

infosys_ldap_run_dir=/var/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

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: /var/run/arc/bdii

Example:

bdii_run_dir=/var/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=/var/run/arc/bdii/bdii-update.pid

bdii_database

Synopsis: bdii_database = backend_type

Description: Configure what ldap database backend should be used.

Default: hdb

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=/var/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 schema block. should be used to turn on/off nordugrid-ldap publication.

[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 schema block. should be used to turn on/off GLUE2 publication (both ldap & xml)

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

end of the [infosys/glue2] schema block ########################

[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 schema block. should be used to turn on/off GLUE2 LDAP tree publication.

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.

[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. should be used to turn on/off GLUE1 publication.

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

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.

Warning

CHANGE: renamed. turn on/off the fake site-bdii based on this block.

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: The url of the resource BDII underlying the fake site bdii. It is on the format: ldap://host.domain:2170/mds-vo-name=something,o=grid.

Default: undefined

Example:

url=ldap://host.domain:2170/mds-vo-name=something,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 also add additional advertisedvos to queues. 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 it as advertisedvo

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

benchmark

Synopsis: benchmark = name value

Description: This optional multivalued attribute can be used to specify benchmark results on the cluster level. Use this cluster attribute if only the NODES are homogeneous with respect to the benchmark performance. Otherwise the similar queue-level attribute should be used. Please try to use standard benchmark names, if possible.

This option in multivalued.

Default: undefined

Example:

benchmark=SPECINT2000 222
benchmark=SPECFP2000 333

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

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

[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

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 parameter proposed in Umea retreat

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 and benchmark should be set if they are homogeneous over the nodes assigned to the queue AND they are different from the cluster-level value. Their meanings are described in the [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 parameter in this block

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: see description at [infosys/cluster] block

This option in multivalued.

Default: $VAR{[infosys/cluster]benchmark}

Example:

benchmark=SPECINT2000 222
benchmark=SPECFP2000 333

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 is the union set of what is contained in the [infosys/cluster] and in this [queue:name] 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: undefined

Example:

advertisedvo=atlas
advertisedvo=community.nordugrid.org

Warning

CHANGE: renamed it as advertisedvo

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

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

[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

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, also renamed from allowed_dir to work_dir

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

port

Synopsis: port = port

Description: Port on which service listens

Default: 443

Example:

port=8443

Warning

CHANGE: NEW

pidfile

Synopsis: pidfile = path

Description: pid file of the daemon

Default: /var/run/arched-datadelivery-service.pid

Example:

pidfile=/var/run/arched-datadelivery-service.pid

Warning

CHANGE: NEW

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

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

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

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

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

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

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

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

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

[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 (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

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

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

[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

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

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

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

[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: new blockname that 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 from file

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

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

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. set default to yes.

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 as loglevel

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.