ARC Configuration Reference Document¶
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:allowedusers]
[mapping]
[lrms]
[lrms/ssh]
[arex]
[arex/cache]
[arex/cache/cleaner]
[arex/data-staging]
[arex/ws]
[arex/ws/emies]
[arex/ws/cache]
[arex/ws/candypond]
[arex/ws/argus]
[arex/rest]
[arex/jura]
[arex/jura/archiving]
[arex/jura/sgas:neic_sgas]
[arex/jura/apel:egi_prod_apel]
[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:gridlong]
[datadelivery-service]
[acix-scanner]
[acix-index]
[userlist:biousers]
[nordugridmap]
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 allowed within identifier(stripped space)]
Detailed textual definition:
- All trailing and leading spaces on each confiuration line are stripped and ignored. This aplies both to block headers and block content.
- All spaces around the
=sign inoption=valuekind of string (after ‘a’ is applied) are stripped and ignored. For example linehostname = myhost.infois treated as identical tohostname=myhost.info.- In block headers of
[keyword]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand insidekeyword.- In block headers of
[keyword:identifier]kind (after ‘a’ is applied) no additional spaces are allowed aroundkeywordand insidekeyword. The spaces ARE allowed around and insideidentifierpart. Those aroundidentifierare stripped and ignored. Those insideidentifierare treated as its integral part and are preserved.
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] 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!
Configuration blocks¶
[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:name] block¶
These configuration blocks contain authorization rules.
An [authrgroup:name] 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, the access control of ARC services are
implemented via specifying the [authgroup:name] to which certain permissions are granted.
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.
It is however more common to allow multiple VOs in a single authgroup.
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:name] blocks are
evaluated, even if a user already has a match with one of the earlier 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
TODO: consider implementing Roger’s suggestion and introduce a rule variable
All the objects used in the rules (e.g. other authgoups or userlists) MUST be defined before it may be used.
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 option in multivalued.
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 and adds those to the authgroup.
This option in multivalued.
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 option in multivalued.
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 configuration file. Multiple authgroup names may be specified for this rule. That allows creating hierarchical structure of authorization groups like ‘clients’ are those which are ‘users’ and ‘admins’.
This option in multivalued.
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 option in multivalued.
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 option in multivalued.
Default: undefined
Example:
plugin=10 /usr/libexec/arc/arc-lcas %D %P liblcas.so /usr/lib64 /etc/lcas/lcas.db
all - Matches any user identity. This variable requires no arguments or values.
Default: undefined
Example:
all=
[mapping] block¶
This block defines the grid-identity to local UNIX identity mapping rules used by various ARC components. Mapping rules are processed sequentially and processing stops at first successful one.
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.
This option in multivalued.
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 file directory/pool.
Used accont names are stored in other files placed in the same directory.
If a UNIX account name was not used for 10 days, it may be reassigned to another user.
This option in multivalued.
Default: undefined
map_with_file¶
Synopsis: map_with_file = authgroup_name file
Description: for users that belongs to specified
authgroup the subject of certificate is matched against a list of subjects
stored in the specified file, one per line followed by a local UNIX account
name. This rule can be used to implement legacy grid-mapfile aproach.
This option in multivalued.
Default: undefined
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. For safety reasons it is also advised to finish mapping sequence with default mapping rule to nonexistent or safe account if dynamic mapping sources are used.
This option in multivalued.
Default: undefined
Example:
map_with_plugin=altas 30 /usr/libexec/arc/arc-lcmaps %D %P liblcmaps.so /usr/lib64 /etc/lcmaps/lcmaps.db arc
[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. For detailed description of recommended LRMS setups for ARC please refer to ARC CE sysadmin guide: http://www.nordugrid.org/documents/arc-ce-sysadm-guide.pdf
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 all the PBS flavours e.g. OpenPBS, PBSPro, ScalablePBS, Torque)
- lsf - LSF
- ll - LoadLeveler
- slurm - SLURM
- boinc - Boinc
- slurmpy - new generation SLURM scripts (provide access to slurm via ssh too)
PBS has many flavours, ARC currenly supports OpenPBS, PBSPro, ScalablePBS and Torque (the official name for ScalablePBS). There is no need to specify the flavour or the version number of the PBS, simply write ‘pbs’. Similarly, there is no need to specify (Sun/Oracle) Grid Engine versions and flavours.
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 job descriptions submitted to the ARC CE do not specify a requested queue.
This queue name must match one of the [queue:queue_name] blocks.
Allowed values: fork, sge, condor, pbs, lsf, ll, slurm, boinc, slurmpy
Default: fork
Example:
lrms=pbs 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.
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: It needs to 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: 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
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
[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_runtimedir¶
Synopsis: remote_runtimedir = path
Description: Runtime environment directory on cluster frontend to
be mounted (sshfs) on CE machine at directory specified by the ‘runtimedir’
attribute in the [arex] block.
Warning
TODO: check if it is still relevant or work with the ARC6 RTE framework
Default: undefined
Example:
remote_runtimedir=/SOFTWARE/runtime
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.
Warning
TODO: why is it mandatory and why the remote_sessiondir is not mandatory?
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
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
scratchdir¶
Synopsis: scratchdir = path
Description: The path on computing node to move session directory to before execution. If defined should contain the path to the directory on the computing node which can be used to store a jobs’ files during execution. Sets the environment variable RUNTIME_LOCAL_SCRATCH_DIR. If the variable is not set, then the session dir is not moved before execution. Don’t set this parameter unless you want to move the sessiondir to scratchdir on the node.
Default: undefined
Example:
scratchdir=/local/scratch/
tmpdir¶
Synopsis: tmpdir = path
Description: A temporary directory used by A-REX.
Default: /tmp
Example:
tmpdir=/tmp
runtimedir¶
Synopsis: runtimedir = path
Description: The directory which holds the additional runtimeenvironment scripts, added by system administrator. Several directories can be specified. To enable RTEs to be advertised in the information system and used during submission the arcctl tool should be used.
This option in multivalued.
Default: undefined
Example:
runtimedir=/var/spool/arc/extraruntimes
runtimedir=/cvmfs/vo/arcruntime
maxjobs¶
Synopsis: maxjobs = number1 number2 number3 number4 number5
Description: specifies maximum allowed number of jobs. number1 - jobs which are not in FINISHED state (jobs tracked in RAM) number2 - jobs being run (SUBMITTING, INLRMS states) number3 - jobs being processed per DN number4 - jobs in whole system number5 - LRMS scripts limit (jobs in SUBMITTING and CANCELING) A parameter set to -1 means no limit.
Default: -1 -1 -1 -1 -1
Example:
maxjobs=10000 10 2000 -1 -1
Warning
CHANGE: Modified. 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
Description: (previously authplugin) This parameter
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 ,. Possible keys are:
- timeout
- wait for result no longer that ‘value’ seconds, (timeout= can be omitted).
- onsuccess, onfailure, ontimeout
- what to do if plugin exited with exit code 0, not 0, timeout achieved.
Possible actions are:
- pass
- continue executing job,
- fail
- cancel job,
- log
- write to log fail about problem and continue executing job.
This option in multivalued.
Default: undefined
arc-blahp-logger: a statecallout plugin shipped with ARC: it’s purpose is to write accounting log for every finished job in BLAH format.
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/arc/arex.pid
Example:
pidfile=/var/run/run/arex.pid
Warning
TODO: modified pid file location and name
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.
Warning
TODO: check if not in controldir
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.
Warning
TODO: was missed in queue, check it actually works with queues
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
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
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
Warning
TODO: test if a space such as 9000, 9300 brakes gridftp in ARC?
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 pre- and post- processing state, eg cache check or replica resolution.
Warning
TODO: clarify what are those post and pre states, explain it to sysadmins
Default: 10
Example:
maxprocessor=20
maxemergency¶
Synopsis: maxemergency = number
Description:
Maximum emergency slots which can be assigned to transfer
shares when all slots up to the limits configured by the above two options
are used by other shares. This ensures shares cannot be blocked by others.
Default: 1
Example:
maxemergency=5
maxprepared¶
Synopsis: maxprepared = number
Description: Maximum number of files in a prepared state, i.e. pinned on a remote storage such as SRM for transfer. A good value is a small multiple of maxdelivery.
Default: 200
Example:
maxprepared=250
copyurl¶
Synopsis: copyurl = url_head local_path
Description: Configures that DTR should use copy instead of download in case of certain stagein files. URLs, starting from ‘url_head’ should be accessed in a different way (most probaly unix open). The ‘url_head’ part of the URL will be replaced with ‘local_path’ and file from obtained path will be copied to the session directory. NOTE: ‘local_path’ can also be of URL type.
This option in multivalued.
Default: undefined
Example:
copyurl=gsiftp://example.org:2811/data/ /data/
copyurl=gsiftp://example2.org:2811/data/ /data/
linkurl¶
Synopsis: linkurl = url_head local_path [node_path]
Description: Identical to ‘copyurl’, configures DTR so that for certain URLs files won’t be downloaded or copied (in case of copyurl), but soft-link will be created. The ‘local_path’ specifies the way to access the file from the frontend, and is used to check permissions. The ‘node_path’ specifies how the file can be accessed from computing nodes, and will be used for soft-link creation. If ‘node_path’ is missing - ‘local_path’ will be used.
This option in multivalued.
Default: undefined
Example:
linkurl=gsiftp://somewhere.org/data /data
linkurl=gsiftp://example.org:2811/data/ /scratch/data/
use_remote_acix¶
Synopsis: use_remote_acix = URL
Description: (previously acix_endpoint) If configured then the ARC Cache Index, available at the URL, will be queried for every input file specified in a job description and any replicas found in sites with accessible caches will be added to the replica list of the input file. The replicas will be tried in the order specified by preferredpattern variable.
Default: undefined
Example:
use_remote_acix=https://cacheindex.ndgf.org:6443/data/index
Warning
CHANGE: 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 = URL - 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/emies] block¶
EMIES is The Web Service interface offered by A-REX to create and manage computational jobs,
obtain resource and activity information, also handle delegation. EMIES is a complete set of
Computing Element interface, it encapsulates all the functionality a CE should expose via its interface.
See interface description at
http://www.nordugrid.org/documents/EMI-ES-Specification_v1.16.odt
If you don’t want to offer EMIES interface, remove or comment out this block in our arc.conf.
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 [authgroup ...]
Description: (previously groupcfg) Specifies authorization groups that are allowed to access the WS EMIES - based jobsubmission interface. If this parameter is not set, then no additional restrictions are applied for authorizing user access. The matching group is also used for evaluating VOMS attributes representing the user.
Default: undefined
Warning
TODO: check who is authorized in case of no gridmapfile and empty allowaccess
Example:
allowaccess=biousers atlasusers
Warning
CHANGE: new parameter in the EMIES block
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:
- Regular expression defining a URL pattern
- Credential attribute to match against a client’s credential
- Regular expression defining a credential value to match against a client’s credential
A client is allowed to access the cached file if a URL pattern matches the cached file URL and the client’s credential has the attribute and matches the value required for that pattern. Possible values for credential attribute are dn, voms:vo, voms:role and voms:group.
This option in multivalued.
Default: undefined
Example:
cacheaccess=gsiftp://host.org/private/data/.* voms:vo myvo:production
cacheaccess=gsiftp://host.org/private/data/bob/.* dn /O=Grid/O=NorduGrid/.*
[arex/ws/candypond] block¶
The CandyPond (Cache and deliver your pilot on-demand data) A-REX Web
Service (previously called Cache Service) exposes various useful data-staging related operations
for the pilot job model where input data for jobs is not known until the job
is running on the worker node. This service is intended to be used by A-REX managed jobs.
This service requires the [arex/data-staging] functionality.
The CandyPond service is available via the wsurl/candypond URL (e.g. https://hostname:443/arex/candypond)
Warning
TODO: revise packaging now that it is NOT a separate, independent service.
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
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 of JURA.
If archiving is enabled then the generated usage records are stored
in a the specified archivedir directory on the disk 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.
By default the archiving is turned off.
Warning
CHANGE: NEW block
archivettl¶
Synopsis: archivettl = days
Description: The archive time to live (ttl) parameter sets the number of days to keep the archive records in the archivedir. If not specified the records are kept forever.
Default: undefined
Example:
archivettl=365
Warning
CHANGE: new parameter. new feature to implement!
archivedir¶
Synopsis: archivedir = path
Description:
Sets the directory path for the archived usage records.
If archiving is turned on, then the generated usage records 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
Warning
TODO: create the directory
Example:
archivedir=/var/spool/arc/jura/archive
Warning
CHANGE: NEW
[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 through and existing ganglia installation. Earlier versions (ARC < 6.0) relied only on the standalone tool gangliarc. Ganglia is now integrated into ARC to extract jobmetrics. Ganglia for system metrics is run as separate gangliarc instance.
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
logfile¶
Synopsis: logfile = path
Description: log file of the daemon.
Default: /var/log/arc/gangliarc.log
Example:
logfile=/tmp/gangliarc.log
Warning
TODO: is this needed for the internal ganglia?
pidfile¶
Synopsis: pidfile = pid
Description: pid file of the daemon.
Default: /var/run/gangliarc.pid
Example:
pidfile=/tmp/gangliarc.pid
Warning
TODO: it is not a separate service, therefore pid is not there.
python_bin_path¶
Synopsis: python_bin_path = path
Description: The path to python executable.
Default: /usr/bin/python
Example:
python_bin_path=/usr/local/bin/python
Warning
TODO (Maiken) clarify if this is still needed.
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 - 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)
- failedjobs – the number of failed jobs per last 100 finished
- jobstates – number of jobs in different A-REX internal stages
- all – all of the above metrics
Default: all
Allowed values: staging, cache, session, heartbeat, processingjobs, failedjobs, jobstates, all
Example:
metrics=all
Warning
TODO which metrics is used by the internal ganglia?
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 fileplugin 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
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 [authgroup ...]
Description: (previously groupcfg) Specifies authorization groups that are allowed to access the gridftp-based jobsubmission interface. If this parameter is not set, then no additional restrictions are applied for authorizing user access. The matching group is also used for evaluating VOMS attributes representing the user.
Warning
TODO: check what happens if no gridmapfile used with empty value
Default: undefined
Example:
allowaccess=biousers atlasusers
Warning
CHANGE: renamed
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 fileplugin 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 fileplugin.
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 [authgroup ...]
Description: (previously groupcfg) Specifies authorization groups that are allowed to access the gridftp-based jobsubmission interface. If this parameter is not set, then no additional restrictions are applied for authorizing user access.
Default: undefined
Example:
allowaccess=biousers atlasusers
Warning
CHANGE: renamed
dir¶
Synopsis: dir = path options
Description:
Specifies access rules for accessing files in path
(relative to virtual and real path) and all the files and directories below.
Available permisisons check options are:
- nouser
- do not use local file system rights, only use those specifies in this line
- owner
- check only file owner access rights
- group
- check only group access rights
- other
- check only
othersaccess rights
If none of the above specified usual unix access rights are applied.
Avaiable permissions enforecement options are:
- read
- allow reading files
- delete
- allow deleting files
- append
- allow appending files (does not allow creation)
- overwrite
- allow overwriting already existing files (does not allow creation, file attributes are not changed)
- dirlist
- allow obtaining list of the files
- cd
- allow to make this directory current
- create owner:group permissions_or:permissions_and
- allow creating new files. File will be owned by
ownerand owning group will begroup. If*is used, the user/group to which connected user is mapped will be used. The permissions will be set topermissions_or & permissions_and. (second number is reserved for the future usage).- mkdir owner:group permissions_or:permissions_and
- allow creating new directories.
Example shows setting permissions on mounted / directory and adjusting permissions
on /section1 and /section2 subdirectories.
This option in multivalued.
Default: undefined
Warning
TODO: check behaviour when this option is missing and user is mapped to root. (what is the default user mapping for file-plugin?)
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
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
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.
[infosys/cluster] block¶
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:
cluster_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. opsys will be used to fill GLUE2 OSName, OSVersion and OSFamily unless these values are explicitly defined. See below for their usage.
This option in multivalued.
Default: undefined
Warning
TODO: check if adotf is supported for this parameter. If so, use that as default.
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:
nis the number of CPUs per machinemis the number of such machines
Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with
3 single CPU machines, 4 dual CPU machines and one machine with 4 CPUs.
Default: undefined
Example:
cpudistribution=1cpu:3,2cpu:4,4cpu:1
[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 needs to 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)
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 OSName, OSVersion, OSFamily
is allowed in a dedicated subblock.
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
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
This option in multivalued.
Default: undefined
Example:
osname=Ubuntu
osversion¶
Synopsis: osversion = string
Description: Only for GLUE2
Default: undefined
Example:
osversion=12.04
osfamily¶
Synopsis: osfamily = string
Description: Only for GLUE2
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 [authgroup ...]
Description: Specifies authorization groups
that are allowed to submit jobs to this queue. It does not override simular
parameter specified in [gridftpd/jobs] and [arex/ws/emies] blocks.
If this parameter is not set, then no additional restrictions are applied for
authorizing user abbility to submit jobs to this queue.
The matching group from this parameter does not affect which VOMS
attributes are selected as representing the user.
Default: undefined
Example:
allowaccess=biousers atlasusers
Warning
CHANGE: NEW parameter in the [queue:name] block
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]
Warning
TODO: add Florido’s new variables both to the queue and cluster block (maxcputime and maxwalltime)
[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. See details at https://wiki.nordugrid.org/wiki/Data_Staging/Multi-host
This service can also act as an independent data transfers service that case it would require a inteligent data manager that could replace A-REX’s intelligence. (see draft vision document)
Warning
TODO: point to the documentation that describes protocol, operations.
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
Warning
TODO renamed
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
Warning
TODO: got remaned from interface, fix DDS startup script and profile.
port¶
Synopsis: port = port
Description: Port on which service listens
Default: 443
Example:
port=8443
Warning
CHANGE: NEW
ipversion¶
Synopsis: ipversion = number
Description: IP version to use
Default: 4
Example:
ipversion=6
Warning
TODO: Ask Aleksandr if can we have both 4 and 6 together (multivalued)?
Warning
CHANGE: NEW
pidfile¶
Synopsis: pidfile = path
Description: pid file of the daemon
Default: /var/run/arc/datadelivery-service.pid
Warning
TODO: changed the pid file name and location!
Example:
pidfile=/tmp/delivery.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.
This option in multivalued.
Default: undefined
Example:
allowed_ip=192.0.2.1
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
Warning
TODO: changed logfile name
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
Warning
TODO: should be mandatory
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: $VAR{[common/mapping]gridmap}
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 onmapuser_processingoption settings.userlist://- reference to another
[userlist/name]configuration blocknordugrid- 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 (controlmapped_unixidoverriding behaviour for URL)
This option in multivalued.
Default: undefined
Example:
source=vomss://voms.ndgf.org:8443/voms/nordugrid.org
source=vomss://lcg-voms.cern.ch:8443/voms/atlas?/atlas/Role=VO-Admin < mapped_unixid=atlasadmin
source=vomss://kuiken.nikhef.nl:8443/voms/gin.ggf.org < voms_method=get
source=http://www.nordugrid.org/developers.dn
source=file:///etc/grid-security/priviliged_users.dn
source=userlist://biousers
source=nordugrid
Warning
CHANGE: MODIFIED options: 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_unixidfor all sourcesmapuser_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_unixidwhich means that nordugridmap will generate only the list of DNs without mapping (consider usingmapuser_processing = overwritealong with this option or sources that does not provide previously defined mapping information)allow_empty_unixid = no- then nordugridmap will skip users without mapping information
Default: nobody
Example:
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/
Warning
TODO changed file location
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
issuer_processing - control the behavior of [userlist/name] block’s require_issuerdn
Warning
CHANGE28: DELETED
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
Warning
TODO set default to 2
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
