SYNOPSIS

/etc/arc.conf

${ARC_LOCATION}/etc/arc.conf

DESCRIPTION

ARC has two separate configuration files - one for client tools and another for services. This document describes the services configuration file. For client configuration please see "ARC Clients User Manual" at http://www.nordugrid.org/documents/arc-ui.pdf

ARC configuration uses a plain-text "ini-style" format. It is also possible to use an XML format, however that is outside the scope of this document.

The configuration file consists of several configuration blocks. Each configuration block is identified by a keyword and contains the configuration options for a specific part of the ARC middleware.

Each configuration block starts with its identifying keyword inside square brackets. Thereafter follows one or more attribute value pairs written one on each line in the following format (note that the attribute names are CASE-SENSITIVE):

[keyword1]
attribute1=value1
attribute2=value2
[keyword2]
attribute=value

If the ARC_LOCATION environment variable is set the ARC configuration file located at ${ARC_LOCATION}/etc/arc.conf is read first. If this file is not present or the relevant configuration information is not found in this file, the file at /etc/arc.conf is read.

The [common] block

The parameters set within this block are available for all the other blocks. These are the configuration parameters shared by the different components of ARC (e.g. grid-manager, infosys)

hostname

hostname - the FQDN of the frontend node, optional in the common block but MUST be set in the cluster block

Example:
hostname="myhost.org"

x509_voms_dir

x509_voms_dir path - the path to the directory containing *.lsc files needed for checking validity of VOMS extensions. If not specified default value /etc/grid-security/vomsdir is used.

Example:
x509_voms_dir="/etc/grid-security/vomsdir"

lrms

ARC supports various LRMS flavours, as listed in this section. For detailed description of options please refer to ARC CE sysadmin guide:

http://www.nordugrid.org/documents/arc-ce-sysadm-guide.pdf

ONLY ONE LRMS IS ALLOWED. MULTIPLE lrms ENTRIES WILL TRIGGER UNEXPECTED BEHAVIOUR.

lrms sets the type of the Local Resource Management System (queue system), and optionally - the default queue name, separated with a blank space: lrmstype queue_name. For lrmstype, the following systems are supported and can be chosen (one per server):
   fork   - simple forking of jobs to the same node as the server
   sge    - (Sun/Oracle) Grid Engine
   condor - Condor
   pbs    - PBS
   lsf    - LSF
   ll     - LoadLeveler
   slurm  - SLURM
   dgbridge - Desktop Grid
    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. "lrmstype" MUST be set here, it is a MANDATORY parameter!

The optional queue parameter specifies the default Grid queue of the LRMS. Jobs will be submitted to this queue if they do not specify queue name in job description. Queue name must match one of the [queue/queue_name] block labels, see below.

Example:
lrms="pbs gridlong"
lrms="pbs"

PBS options

pbs_bin_path

the path to the qstat,pbsnodes,qmgr etc PBS binaries, no need to set if PBS is not used

Example:
pbs_bin_path="/usr/bin"

pbs_log_path

the path of the PBS server logfiles which are used by A-REX to determine whether a PBS job is completed. If not specified, A-REX will use qstat for that.

Example:
pbs_log_path="/var/spool/pbs/server_logs"

Condor options

condor_rank

condor_rank - 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. Obviously no need to set if Condor is not used. An example:

Example:
condor_rank="(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000"

condor_bin_path

condor_bin_path - Path to Condor binaries. Must be set if Condor is used.

Example:
condor_bin_path=/opt/condor/bin

condor_config

condor_config - Path to Condor config file. Must be set if Condor is used and the config file is not in its default location (/etc/condor/condir_config or ~/condor/condor_config). The full path to the file should be given.

Example:
condor_config=/opt/condor/etc/condor_config

SGE options

sge_bin_path

sge_bin_path - Path to Sun Grid Engine (SGE) binaries, MUST be set if SGE is the LRMS used

Example:
sge_bin_path="/opt/n1ge6/bin/lx24-x86"

sge_root

sge_root - Path to SGE installation directory. MUST be set if SGE is used.

Example:
sge_root="/opt/n1ge6"

sge_cell

sge_cell - 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'

Example:
sge_cell="default"

sge_qmaster_port

sge_qmaster_port, sge_execd_port - these 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.

Example:
sge_qmaster_port="536"
sge_execd_port="537"

SLURM options

slurm_bin_path

slurm_bin_path - Path to SLURM binaries, must be set if installed outside of normal $PATH

Example:
slurm_bin_path="/usr/bin"

slurm_wakeupperiod

How long should infosys wait before querying SLURM for new data (seconds)

Example:
slurm_wakeupperiod="15"

slurm_use_sacct

Should ARC use sacct instead of scontrol to get information on finished jobs. Requires that accounting is turned on in SLURM. Default is "no".

Example:
slurm_use_sacct="yes"

LSF options

lsf_bin_path

the PATH to LSF bin folder no need to set if LSF is not used

Example:
lsf_bin_path="/usr/local/lsf/bin/"

lsf_profile_path

the PATH to profile.lsf no need to set if LSF is not used

Example:
lsf_profile_path="/usr/share/lsf/conf"

LL options

ll_bin_path

the PATH to the LoadLeveler bin folder no need to set if LoadLeveler is not used

Example:
ll_bin_path="/opt/ibmll/LoadL/full/bin"

ll_consumable_resources

support for a LoadLeveler setup using Consumable Resources no need to set if LoadLeveler is not used

Example:
ll_consumable_resources="yes"

Desktop Grid options

dgbridge_stage_dir

Desktop Bridge www publish dir

Example:
dgbridge_stage_dir="/var/www/DGBridge"

dgbridge_stage_prepend

Desktop Bridge URL prefix pointing to dgbridge_stage_dir

Example:
dgbridge_stage_prepend="http://edgi-bridge.example.com/DGBridge/"

Boinc options

boinc_db_host boinc_db_port boinc_db_name boinc_db_user boinc_db_pass

Connection details for the Boinc database.

Example:
boinc_db_host="localhost"
boinc_db_port="3306"
boinc_db_name="myproject"
boinc_db_user="boinc"
boinc_db_pass="password"

Other [common] options

globus_tcp_port_range

globus_tcp_port_range, globus_udp_port_range - Firewall configuration In a firewalled environment the software which uses GSI needs to know what ports are available. The full documentation can be found at: http://dev.globus.org/wiki/FirewallHowTo These variable are similar to the Globus environment variables: GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE. These variables are not limited to [common], but can be set individually for each service in corresponding section: [grid-manager], [gridftpd] Example:

Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"

x509_user_key

x509_user_cert, x509_user_key - Server credentials location. These variables are similar to the GSI environment variables: X509_USER_KEY and X509_USER_CERT These variables are not limited to [common], but can be set individually for each service in corresponding section: [grid-manager], [gridftpd], [nordugridmap]

Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"

x509_cert_dir

x509_cert_dir - Location of trusted CA certificates This variable is similar to the GSI environment variable: X509_CERT_DIR This variable is not limited to [common], but can be set individually for each service in corresponding section: [grid-manager], [gridftpd]

Example:
x509_cert_dir="/etc/grid-security/certificates"

gridmap

gridmap - The gridmap file location This variable is similar to the GSI environment variable: GRIDMAP This variable is not limited to [common], but can be set individually for each service in corresponding section: [grid-manager], [gridftpd] The default is /etc/grid-security/grid-mapfile

Example:
gridmap="/etc/grid-security/grid-mapfile"

voms_processing

voms_processing - Defines how to behave if errors in VOMS AC processing detected.
  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 the default.
  strict - fail if any parsing error was discovered.
  noerrors - fail if any parsing or validation error happened. This command can also be used in [grid-manager] and [gridftpd] blocks.

Example:
voms_processing="standard"

voms_trust_chain

voms_trust_chain - Define the DN chain that the host services trust when the VOMS AC from peer VOMS proxy certificate is parsed and validated. There can be multiple "voms_trust_chain" existing, each one corresponds to a VOMS server. This variable is similar to the information in *.lsc file, but with two differences:
 1, You don't need to create a *.lsc file per VOMS server, but create a chain per VOMS server;
 2, Regular expressions are supported when matching the DNs.

This variable is not limited to [common], but can be used in [grid-manager] and [gridftpd] blocks. This variable should be used together with voms_processing. This variable will overwrite the information in *.lsc if *.lsc exists.

Example:


voms_trust_chain = "/O=Grid/O=NorduGrid/CN=host/arthur.hep.lu.se" "/O=Grid/O=NorduGrid/CN=NorduGrid Certification Authority"


voms_trust_chain = "/O=Grid/O=NorduGrid/CN=host/emi-arc.eu" "/O=Grid/O=NorduGrid/CN=NorduGrid Certification Authority"


voms_trust_chain = "^/O=Grid/O=NorduGrid"

enable_perflog_reporting

enable_perflog_reporting yes/no - Switch on or off performance reporting. Default is no.

Example:
enable_perflog_reporting="yes"

perflogdir

perflogdir logdir - Directory where performance logs should be stored. Default is /var/log/arc/perflogs

Example:
perflogdir="/var/log/arc/perflogs"

[vo] block

[vo] block is used to define VOs and generate mapfiles from user list maintained by VO databases. VO block is a configuration block for the nordugridmap utility. Please note that [vo] block processing by nordugridmap utility depend on parameters defined in the [nordugridmap] block.

[vo] block by itself does not affect authorization of client/user. For that label defined by vo="" attribute may be used in [group] block with with 'file' rule.

id

id blockid - specifies the unique configuration block id (this does not affect nordugridmap utility)

Example:
id="vo_1"

vo

vo vo_name - specifies the VO name, this name can be used in other blocks. MUST be given.

Example:
vo="nordugrid"

file

file path - output gridmap-file where GENERATED mapping list will be stored. See parameters below to define how to generate this file. If the same file specified as output for different [vo] blocks, nordugridmap will automatically merge entries in given blocks order. Default is '/etc/grid-security/gridmapfile'.

Example:
file="/etc/grid-security/VOs/atlas-users"

source

source URL - the URL of the VO database which is assigned to this VO. The nordugridmap will use this URL to automatically generate and keep up-to-date userlist (mapfile) specified by the 'file' attribute. URL is a multivalued attribute, several sources can be specified for the [vo] block 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 with optional issuer certificate authority DN
                (see require_issuerdn): "user DN" ["issuer DN"]
   voms(s):// - URL to VOMS-Admin interface
   nordugrid  - add NorduGrid VO members
   ldap://    - expect LDAP-schema formatted VO Group
   file://    - local file (stand-alone or dynamically generated by 
                nordugridmap). File should contain a list of DNs with
                optional mapped unixid: "user DN" [mapped user ID]
                Result of optional mapped unixid processing depend
                on mapuser_processing option settings.
   vo://      - reference to another [vo] configuration block 
   edg-mkgridmap:// 
              - local configuration file used by edg-mkgridmap tool.
                nordugridmap will parse configuration from file and 
                process it as additional [vo] block that will be referred 
                authomatically in place URL specified. This allow 
                easy migration from edg-mkgridmap solution without 
                rewriting your previous configuration (NOTE that rarely 
                used 'auth' directive and 'AUTO' mapping options are not 
                supported)

You can use either vo:// or file:// entries to specify dependencies between [vo] blocks, but using vo:// 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>' overrides
                       (control mapped_unixid overriding behaviour for URL)

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="ldap://grid-vo.nikhef.nl/ou=lcg1,o=atlas,dc=eu-datagrid,dc=org"
source="file:///etc/grid-security/priviliged_users.dn"
source="vo://nordugrid_community"
source="nordugrid"

mapped_unixid

mapped_unixid unixid - the local UNIXID which is used in the generated grid-mapfile by the nordugridmap utility.

If any of the sources have already provided mapping information (file:// or vo://) behaviour depends on 'mapuser_processing' [nordugridmap] block configuration:
   mapuser_processing = 'overwrite': ignore already provided mapping and 
                        apply mapped_unixid for all sources
   mapuser_processing = 'keep': apply mapped_unixid only for sources that
                        does not already has mapping information

[vo] block can only have one UNIXID. If 'mapped_unixid' is not specified behaviour depends on 'allow_empty_unixid' [nordugridmap] block configuration value:
   allow_empty_unixid = 'yes': empty value will be used for mapped_unixid
                        which means that nordugridmap will generate only 
                        the list of DNs without mapping (consider using  
                        mapuser_processing='overwrite' along with this 
                        option or sources that does not provide previously
                        defined mapping information)
   allow_empty_unixid = 'no': skip users without mapping information (if
                        no mapping information provided by sources)

Example:
mapped_unixid="gridtest"

voms_fqan_map

voms_fqan_map fqan unixid - the local UNIXID which is used to map voms(s) sources with specific FQAN given. Several voms_fqan_map can be specified for a [vo] block. For each voms(s) sources in [vo] block and every voms_fqan_map record separate source record will be authomatically generated with mapped_unixid overrided 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.

Example:
voms_fqan_map="/atlas/Role=VO-Admin atlasadmin"
voms_fqan_map="/atlas/Role=production atlasprod"

require_issuerdn

require_issuerdn yes/no - another nordugridmap option. YES would map only those DNs obtained from the URLs which have the corresponding public CA packages installed. Default is 'no'. Note, that some sources does not provide issuer information (like voms(s):// or file://). If this sources are used within [vo] block and require_issuerdn is set to 'yes' behaviour depends on issuer_processing [nordugridmap] block configuration:
   issuer_processing = 'relaxed': check only those records that have issuer 
                       information provided, allow other sources
   issuer_processing = 'strict': if issuer information was not found record 
                       is filtered and will not be passed into mapfile

Example:
require_issuerdn="no"

filter

filter ACL string - 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 mapfile. * 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.

Example:
filter="deny *infn*"
filter="allow *NorduGrid*"

[group] Authorisation block

These configuration blocks define rules used to define to which authorization group a user belongs. The group should not be mistaken for a virtual organisation (VO). A group may match a single vo if only a single check (rule) on vo membership is performed. It is however more common to allow multiple VOs in a single group. ARC also allows many other ways to assign users to groups. Technically, permissions are only granted to groups, not directly to VOs.

The block specifies single authorization group. There may be multiple [group] blocks in configuration defining multiple authorization groups.

The block can be specified in two ways - either using [group/group1] like subblock declaration per group or just [group]. The two formats are equivalent. Every block (till the beginning of next block or the end of the file) defines one authorization group.

IMPORTANT: Rules in a group are processed in their order of appearance. The first matching rule decides the membership of a the user to a group and the processing STOPS. 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 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.

A group MUST be defined before it may be used. In this respect the arc.conf is ORDER SENSITIVE.

The authorization groups can be used in [gridftpd] and in its sub-blocks. The syntax of their specification varies with the service they are used for. For using authorization groups and VO blocks in HED framework please read "Security Framework of ARC" at http://www.nordugrid.org/documents/arc-security-documentation.pdf

name

name group_name - Specify name of group. If there is no such command in block, name of subblock is used instead (that is what subblocks are used for). For example [group/users].

Example:
name="users"

subject

subject certificate_subject - Rule to match specific subject of user's X.509 certificate. No masks, patterns and regular expressions are allowed. For more information about X.509 refer to http://www.wikipedia.org/wiki/X509

Example:
subject="/O=Grid/O=Big VO/CN=Main Boss"

file

file path - Start reading rules from another file. That file has a bit different format. It can't contain blocks and commands are separated from arguments by space. Also word "subject" in subject command may be skipped. That makes it convenient to directly add gridmap-like lists to authorization group.

Example:
file="/etc/grid-security/local_users"

voms

voms vo group role capabilities - Match VOMS attribute in user's credential. Use '*' to match any value. More information about VOMS can be found at http://grid-auth.infn.it

Example:
voms="nordugrid /nordugrid/Guests * *"

group

group group_name [group_name ...] - Match user already belonging to one of specified groups. Groups refered here must be defined earlier in configuration file. Multiple group names may be specified for this rule. That allows creating hierarchical structure of authorization groups like

Example:
group="local_admins"

plugin

plugin timeout path [argument ...] - Run external executable or function from shared library. Rule is matched if plugin returns 0. In arguments following substitutions are supported:
  %D - subject of certificate
  %P - path to proxy

For more about plugins read documentation.

Example:
plugin="10 /opt/external/bin/permis %P"

lcas

lcas library directory database - Call LCAS functions to check rule. Here library is path to shared library of LCAS, either absolute or relative to directory; directory is path to LCAS installation directory, equivalent of LCAS_DIR variable; database is path to LCAS database, equivalent to LCAS_DB_FILE variable. Each arguments except library is optional and may be either skipped or replaced with ’*’.

Example:
lcas=""

remote

remote URL ... - Check user's credentials against remote service. Only DN groups stored at LDAP directories are supported. Multiple URLs are allowed in this rule.

Example:
remote="ldap://grid-vo.nordugrid.org/ou=People,dc=nordugrid,dc=org"

vo

vo vo_name ... - Match user belonging to VO specified by "vo=vo_name" as configured in one of PREVIOUSLY defined [vo] blocks. Multiple VO names are allowed for this rule.

Example:
vo="nordugrid"

all

all - Matches any user identity. This command requires no arguments but
 still can be written as all="" or all= for consistency.

Example:
all=""

The [grid-manager] block

The [grid-manager] block configures the part of A-REX service hosted in arched taking care of the grid tasks on the frontend (stagein/stageout, LRMS job submission, caching, etc..). Name of this block is historical and comes from times then this functionality was handled by separate process called grid-manager. This section also configures WS interfaces of A-REX service also hosted by same container.

controldir

controldir path - The directory of the A-REX's internal job log files, not needed on the nodes. <must be set>

Example:
controldir="/var/spool/nordugrid/jobstatus"

sessiondir

sessiondir path [drain] - the directory which holds the sessiondirs of the grid jobs. Multiple session directories may be specified by specifying multiple sessiondir commands. 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. <sessiondir must be set>

Example:
sessiondir="/scratch/grid"
sessiondir="/mnt/grid drain"

runtimedir

runtimedir path - The directory which holds the runtimeenvironment scripts, should be available on the nodes as well! The runtimeenvironments are automatically detected and advertised in the information system.

Example:
runtimedir="/SOFTWARE/runtime"

scratchdir

scratchdir path - 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. Default is not to move session directory before execution.

Example:
scratchdir="/local/scratch/"

shared_scratch

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

Example:
shared_scratch="/mnt/scratch"

nodename

nodename path - command to obtain hostname of computing node.

Example:
nodename="/bin/hostname"

cachedir

cachedir cache_path [link_path] - specifies a directory to store cached data. Multiple cache directories may be specified by specifying multiple cachedir commands. Cached data will be distributed evenly over the caches. Specifying no cachedir command or commands with an empty path disables caching. 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. Example: cache="/shared/cache /frontend/jobcache" 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 cachedir should specify "drain" as the link path, in which case no new files will be added to the cache.

Example:
cachedir="/scratch/cache"
cachedir="/fs1/cache drain"

remotecachedir

remotecachedir cache_path [link_path] - specifies caches which are under the control of other A-REXs, but which this A-REX can have read-only access to. Multiple remote cache directories may be specified by specifying multiple remotecachedir commands. If a file is not available in paths specified by cachedir, A-REX looks in remote caches. link_path has the same meaning as in cachedir, but the special path ``replicate'' means files will be replicated from remote caches to local caches when they are requested.

Example:
remotecachedir="/mnt/fs1/cache replicate"

cachesize

cachesize max min - specifies high and low watermarks for space used by cache, as a percentage of the space on the file system on which the cache directory is located. When the max is exceeded, files will be deleted to bring the used space down to the min level. It is a good idea to have the cache on its own separate file system. To turn off this feature "cachesize" without parameters can be specified.

Example:
cachesize="80 70"

cachelifetime

If cache cleaning is enabled, 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.

Example:
cachelifetime="30d"

cacheshared

cacheshared yes|no - specifies whether the caches share a filesystem with other data. If set to yes then cache-clean calculates the size of the cache instead of using filesystem used space.

Example:
cacheshared="yes"

cachespacetool

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

Example:
cachespacetool="/etc/getspace.sh"

cachelogfile

cachelogfile path - specifies the filename where output of the cache-clean tool should be logged. Defaults to /var/log/arc/cache-clean.log.

Example:
cachelogfile="/tmp/cache-clean.log"

cacheloglevel

cacheloglevel level - specifies the level of logging by the cache-clean tool, between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).

Example:
cacheloglevel="4"

cachecleantimeout

cachecleantimeout time - the timeout in seconds for running the cache-clean tool. If using a large cache or slow file system this value can be increased to allow the cleaning to complete. Defaults to 3600 (1 hour).

Example:
cachecleantimeout="10000"

cacheaccess

cacheaccess rule - rules for allowing access to files in the cache remotely through the A-REX web interface. A rule has three parts:
 1. Regular expression defining a URL pattern
 2. Credential attribute to match against a client's credential
 3. Regular expression defining a credential value to match against a client's
    credential A client is allowed to access the cached file if a URL pattern matches the cached file URL and the client's credential has the attribute and matches the value required for that pattern. Possible values for credential attribute are dn, voms:vo, voms:role and voms:group. Remote cache access requires that the A-REX web interface is enabled via arex_mount_point.

Examples:
cacheaccess="gsiftp://host.org/private/data/.* voms:vo myvo:production"
cacheaccess="gsiftp://host.org/private/data/ng/.* dn /O=Grid/O=NorduGrid/.*"

enable_cache_service

enable_cache_service yes|no - Turn on or off the cache service interface. If turned on the cache service must be installed and the A-REX WS interface must be enabled via arex_mount_point. The interface is accessible at the same host and port as given inn arex_mount_point with path /cacheservice. Default is off.

Example:
enable_cache_service="yes"

user

user user[:group] - Switch to a non root user/group after startup. Use with caution.

Example:
user="grid"

debug

debug debuglevel - Set debug level of the arched daemon hosting A-REX service, between 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).

Example:
debug="2"

logfile

logfile path - Specify log file location. If using an external log rotation tool be careful to make sure it matches the path specified here. Default log file is "/var/log/arc/grid-manager.log"

Example:
logfile="/var/log/arc/grid-manager.log"

wslogfile

wslogfile path - Specify log file location for WS-interface operations. This file is only created if the WS-interface is enabled through the arex_mount_point option. The logsize, logreopen and debug options also apply to this file. If using an external log rotation tool be careful to make sure it matches the path specified here. It is possible to specify the same file as logfile to combine the logs. Default is /var/log/arc/ws-interface.log.

Example:
wslogfile="/var/log/arc/ws-interface.log"

logsize

logsize size [number] - 'Size' specifies in bytes how big log file is allowed to grow (approximately). If log file exceeds specified size it is renamed into logfile.0. And logfile.0 is renamed into logfile.1, etc. up to 'number' logfiles. Don't set logsize if you don't want to enable the ARC logrotation because another logrotation tool is used.

Example:
logsize="100000 2"

logreopen

logreopen yes|no - Specifies if log file must be closed after each record is added. By default arched keeps log file open. This option can be used to make behaviour of arched compatible with external log rotation utilities.

Example:
logreopen="no"

pidfile

pidfile path - Specify location of file containing PID of daemon process. This is useful for automatic start/stop scripts.

Example:
pidfile="/var/run/arched-arex.pid"

gnu_time

the gnu time command, default /usr/bin/time

Example:
gnu_time="/usr/bin/time"

shared_filesystem

if computing node can access session directory at frontend, defaults to 'yes'

Example:
shared_filesystem="yes"

mail

specifies the email address from where the notification mails are sent, <must be specified>

Example:
mail="[email protected]"

joblog

joblog path - specifies where to store specialized log about started and finished jobs. If path is empty or no such command - log is not written. This log is not used by any other part of ARC, so keep it disabled unless needed.

Example:
joblog="/var/log/arc/gm-jobs.log"

jobreport

jobreport [URL ...] [timeout] - tells to report all started and finished jobs to logger service at 'URL'. Multiple URLs and multiple jobreport commands are allowed. In that case the job info will be sent to all of them. Timeout specifies how long (in days) to try to pass information before give up. Suggested value is 30 days.

Example:
jobreport="https://grid.uio.no:8001/logger"

jobreport_publisher

jobreport publisher - name of the accounting records publisher.

Example:
jobreport_publisher="jura"

jobreport_credentials

jobreport credentials path [key_file [cert_file [ca_dir]]] - specifies the credentials for accessing the accounting service.

Example:
jobreport_credentials="/etc/grid-security/hostkey.pem /etc/grid-security/hostcert.pem /etc/grid-security/certificates"

jobreport_options

jobreport options [name:value, ...]- specifies additional parameters for the jobreporter.

Example:
jobreport_options="urbatch:50,archiving:/tmp/archive,topic:/topic/global.accounting.cpu.central"

jobreport_logfile

jobreport logfile - name of the file to store stderr of the publisher executable.

Example:
jobreport_logfile="/var/log/arc/jura.log"

max_job_control_requests

max_job_control_requests number - max number of simultaneously processed job management requests over WS interface - like job submission, cancel, status check etc. Default value is 100.

Example:
max_job_control_requests="100"

max_infosys_requests

max_infosys_requests number - max number of simultaneously processed resource info requests over WS interface. Default value is 1.

Example:
max_infosys_requests="1"

max_data_transfer_requests

max_data_transfer_requests number - max number of simultaneously processed data transfer requests over WS interface - like data staging. Default value is 100.

Example:
max_data_transfer_requests="100"

maxjobs

maxjobs number1 number2 number3 number4 - 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
  Missing number or -1 means no limit.

Example:
maxjobs="10000 10 2000"

wakeupperiod

wakeupperiod time - specifies how often A-REX cheks for new jobs arrived, job state change requests, etc. That is resposivity of A-REX. 'time' is time period in seconds. Default is 3 minutes. Usually this command is not needed because important state changes are also trigering out-of-schedule checks.

NOTE: This parameter does not affect responsivity of backend scripts - especially scan-*-job. That means that upper estimation of time for detecting job finished executing is sum of responsivity of backend script + wakeupperiod.

Example:
wakeupperiod="180"

defaultttl

defaultttl [ttl [ttr]] - ttl is the time in seconds for how long a session directory will survive after job execution has finished. If not specified the default is 1 week. ttr is how long information about a job will be kept after the session directory is deleted. If not specified, the ttr default is one month.

Example:
defaultttl="259200"

authplugin

authplugin state options plugin_path - Every time job goes to 'state' 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.

Example:
authplugin="ACCEPTED timeout=10 /usr/libexec/arc/bank %C/job.%I.local %S"

authplugin

ARC is distributed with the plugin "inputcheck". Its purpose is to check if input files requested in job's RSL are accessible from this machine. It is better to run it before job enters cluster. It accepts 2 arguments: names of files containing RSL and credentials' proxy. This plugin is only guaranteed to work for job submitted through the legacy GridFTP interface, as this is the only interface for which credentials in the form of proxy certificate files are guaranteed to exist.

Example:
authplugin="ACCEPTED 60 /usr/libexec/arc/inputcheck %C/job.%I.description %C/job.%I.proxy"

authplugin

ARC is distributed with the plugin "arc-vomsac-check". Its purpose is to enforce per-queue access policies based on VOMS attributes present in user's proxy-certificate. Plugin should be run before job enters the cluster. It requires 2 argments: path to job information .local file and path to credentials file. Enforced per-queue access policies are configured with 'ac_policy' option in the [queue/name] configuration block.

Example:
authplugin="ACCEPTED 60 /usr/libexec/arc/arc-vomsac-check -L %C/job.%I.local -P %C/job.%I.proxy"

localcred

localcred timeout plugin_path - Every time an external executable is run this plugin will be called. Its purpose is to set non-unix permissions/credentials on running tasks. Note: the process itself can still be run under the root account. If plugin_path looks like somename@somepath, then function 'somename' from the shared library located at 'somepath' will be called (timeout is not effective in that case). A-REX must be run as root to use this option. Comment it out unless you really know what you are doing.

Example:
localcred="0 acquire@/opt/nordugrid/lib/afs.so %C/job.%I.proxy"

norootpower

norootpower yes|no - if set to yes, all job management proccesses will switch to mapped user's identity while accessing session directory. This is useful if session directory is on NFS root squashing turned on. Default is no.

Example:
norootpower="yes"

allowsubmit

allowsubmit [group ...] - list of authorization groups of users allowed to submit new jobs while "allownew=no" is active in jobplugin configuration. Multiple commands are allowed.

Example:
allowsubmit="mygroup"
allowsubmit="yourgroup"

helper

helper user executable arguments - associates an external program with A-REX. This program will be kept running under the account of the user specified by username. Currently only ’.’ is supported as username, corresponding to the user running A-REX. Every time this executable finishes it will be started again. This helper plugin mechanism can be used as an alternative to /etc/init.d or cron to (re)start external processes.

Example:
helper=". /usr/local/bin/myutility"

tmpdir

tmpdir - used by the A-REX, default is /tmp

Example:
tmpdir="/tmp"

maxrerun

maxrerun - specifies how many times job can be rerun if it failed in LRMS. Default value is 5. This is only an upper limit, the actual rerun value is set by the user in his xrsl.

Example:
maxrerun="5"

globus_tcp_port_range

globus_tcp_port_range, globus_udp_port_range - Firewall configuration.

Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"

x509_user_key

x509_user_cert, x509_user_key - Location of credentials for service. These may be used by any module or external utility which need to contact another service not on behalf of user who submited job.

Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"

x509_cert_dir

x509_cert_dir - Location of trusted CA certificates

Example:
x509_cert_dir="/etc/grid-security/certificates"

http_proxy

http_proxy - http proxy server location

Example:
http_proxy="proxy.mydomain.org:3128"

fixdirectories

fixdirectories yes|missing|no - specifies during startup A-REX should create all directories needed for it operation and set suitable default permissions. If "no" is specified then A-REX does nothing to prepare its operational environment. In case of "missing" A-REX only creates and sets permissions for directories which are not present yet. For "yes" all directories are created and permisisons for all used directories are set to default safe values. Default behaviour is as if "yes" is specified.

Example:
fixdirectories="yes"

arex_mount_point

arex_mount_point - enables web services interfaces, including job execution and information system. The argument is an https URL defining the endpoint port and path:

     https://<hostname>:<port>/<path>

In order to submit job a client must specify the exact published path. Make sure the chosen port is not blocked by firewall or other security rules.

Example:
arex_mount_point="https://piff.hep.lu.se:443/arex"

enable_arc_interface

enable_arc_interface yes|no - turns on or off the ARC own WS interface based on OGSA BES and WSRF. If enabled the interface can be accessed at the URL specified by arex_mount_point (this option must also be specified). Default is yes.

Example:
enable_arc_interface="yes"

enable_emies_interface

enable_emies_interface - enable the EMI Execution Service interface. If enabled the interface can be accessed at the URL specified in arex_mount_point (this option must also be specified)

Example:
enable_emies_interface="yes"

arguspep_endpoint

arguspep_endpoint - specifies URL of Argus PEPD service (by default, the argus pepd service runs on port 8154 with path /authz) 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. If specified Argus is contacted for every operation requested through WS interface (see arex_mount_point).

Example:
arguspep_endpoint="https://somehost.somedomain:8154/authz"

arguspep_profile

arguspep_profile - defines which communication profile to use while communicationg with Argus PEPD service. Possible values are:
 direct - pass all authorization attributes (only for debugging)
 subject - pass only subject name of client
 cream - makes A-REX pretend it is gLite CREAM service. This is  
   recommended profile for interoperability with gLite.
 emi - new profile devloped in EMI project. This is default option.

Example:
arguspep_profile="cream"

arguspep_usermap

arguspep_usermap - specifies either response from Argus servie may define mapping of client to local account. Possible values are 'yes' and 'no'. Default is 'no'. Argus is contacted after all other user mapping is performed. Hence it can overwrite all other decisions.

Example:
arguspep_usermap="no"

arguspdp_endpoint

arguspdp_endpoint - specifies URL of Argus PDP service (by default, the argus pepd service runs on port 8152 with path /authz) 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. If specified Argus is contacted for every operation requested through WS interface (see arex_mount_point).

Example:
arguspdp_endpoint="https://somehost.somedomain:8152/authz"

arguspdp_profile

arguspdp_profile - defines which communication profile to use while communicationg with Argus PDP service. Possible values are:
 subject - pass only subject name of client
 cream - makes A-REX pretend it is gLite CREAM service. This is  
   recommended profile for interoperability with gLite.
 emi - new profile devloped in EMI project. This is default option.

Example:
arguspdp_profile="cream"

arguspdp_acceptnotapplicable

arguspdp_accpetnotapplicable - specify if the "NotApplicable" decision returned by Argus PDP service is treated as reason to deny request. Default is no, which treats "NotApplicable" as reson to deny request.
  Example:
arguspdp_acceptnotapplicable="no"

watchdog

watchdog - specifies if additinal watchdog processes is spawned to restart main process if it is stuck or dies. Possible values are 'yes' and 'no'. Default is 'no'.

Example:
watchdog="no"

groupcfg

groupcfg group_name [group_name ...] - specifies authorization groups for grid-manager to accept. The main location of this parameter is inside [gridftpd/jobs] block. The 'groupcfg' located here is only effective if computing service is configured without GridFTP interface and hence [gridftpd/jobs] block is missing.

Example:
groupcfg="users"

unixmap unixgroup unixvo

unixmap [unixname][:unixgroup] rule - more sophisticated mapping to local account
unixgroup group rule - more sophisticated mapping to local account for specific authorization groups.
unixvo vo rule - more sophisticated mapping to local account for users belonging to specified VO.
The main location for these parameters is [gridftpd] section. If located here they are only active if computing service is configured without GridFTP interface and hence [gridftpd/jobs] block is missing. For more detailed information see section [gridftpd] and read "ARC Computing Element. System Administrator guide" manual.

Example:
unixmap="nobody:nogroup all"
unixgroup="users simplepool /etc/grid-security/pool/users"
unixvo="ATLAS unixuser atlas:atlas"

allowunknown

allowunknown yes|no - check user subject against grid-mapfile. The main location for this parameter is [gridftpd] section. If located here it is only active if computing service is configured without GridFTP interface and hence [gridftpd/jobs] block is missing. For more detailed information see section [gridftpd].

Example:
allowunknown="no"

[data-staging] block

[data-staging] block configures DTR data staging parameters.

debug

debug - Log level for transfer logging in job.id.errors files, between 0 (FATAL) and 5 (DEBUG). Default is to use value set by debug option in [grid-manager] section.

Example:
debug="4"

maxdelivery

maxdelivery - 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 is 10.

Example:
maxdelivery="40"

maxprocessor

maxprocessor - Maximum number of concurrent files in each pre- and post- processing state, eg cache check or replica resolution. Default is 10.

Example:
maxprocessor="20"

maxemergency

maxemergency - 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 is 1.

Example:
maxemergency="5"

maxprepared

maxprepared - 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 is 200.

Example:
maxprepared="250"

sharetype

sharetype - Scheme to assign transfer shares. Possible values are dn, voms:vo, voms:role and voms:group.

Example:
sharetype="voms:role"

definedshare

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

Example:
definedshare="myvo:production 80"
definedshare="myvo:student 20"

dtrlog

dtrlog - A file in which data staging state information (for monitoring and recovery purposes) is periodically dumped. Default is controldir/dtrstate.log

Example:
dtrlog="/tmp/dtrstate.log"

deliveryservice

The following 4 options are used to configure multi-host data staging. deliveryservice - URL to a data delivery service which can perform remote data staging

Example:
deliveryservice="https://myhost.org:60003/datadeliveryservice"

localdelivery

localdelivery - If any deliveryservice is defined, this option determines whether local data transfer is also performed. Default is no.

Example:
localdelivery="yes"

remotesizelimit

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

Example:
remotesizelimit="100000"

usehostcert

usehostcert - Whether the A-REX host certificate should be used for communication with remote hosts instead of the users' proxies. Default is no.

Example:
usehostcert="yes"

acix_endpoint

acix_endpoint URL - the ARC Cache Index specified here 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.

Example:
acix_endpoint="https://cacheindex.ndgf.org:6443/data/index"

securetransfer

securetransfer yes|no - if data connection allows to choose use secure|non-secure data transfer. Currently only works for gridftp. default is no

Example:
securetransfer="no"

passivetransfer

passivetransfer yes|no - If yes, gridftp transfers are passive. Setting this option to yes can solve transfer problems caused by firewalls. default is no

Example:
passivetransfer="no"

localtransfer

localtransfer yes|no - If yes, then the data download from to Grid to the session directory (stagein) will be part of the batch job (prior to the execution of the binary). Default is no.

Example:
localtransfer="no"

B httpgetpartial

httpgetpartial yes|no - If yes, HTTP GET transfers may transfer data in chunks/parts. If no - data is always transfered in one piece. Default is yes.

Example:
httpgetpartial="yes"

speedcontrol

speedcontrol min_speed min_time min_average_speed max_inactivity - specifies how slow data transfer must be to trigger error. Tranfer is canceled 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 transfered for longer than max_inactivity seconds. Value of zero turns feature off. Default is "0 300 0 300"

Example:
speedcontrol="0 300 0 300"

preferredpattern

preferredpattern pattern - specifies a preferred pattern on which to sort multiple replicas of an input file. It consists of one or more patterns separated by a pipe character (|) listed in order of preference. Replicas will be ordered by the earliest match. If the dollar character ($) is used at the end of a pattern, the pattern will be matched to the end of the hostname of the replica.

Example:
preferredpattern="srm://myhost.ac.uk|.uk$|ndgf.org$"

copyurl

copyurl url_head local_path - specifies that URLs, starting from 'url_head' should be accessed in a different way (most probaly unix open). The file from obtained path will be copied to the session directory. NOTE: 'local_path' can also be of URL type. you can have several copyurl lines

Example:
copyurl="gsiftp://example.org:2811/data/ gsiftp://example.org/data/"
copyurl="gsiftp://example2.org:2811/data/ gsiftp://example2.org/data/"

linkurl

linkurl url_head local_path [node_path] - identical to 'copyurl', only file won't be copied, but soft-link will be created. The 'local_path' specifies the way to access the file from the gatekeeper, 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. you can have multiple linkurl settings

Example:
linkurl="gsiftp://somewhere.org/data /data"
linkurl="gsiftp://example.org:2811/data/ /scratch/data/"

maxtransfertries

maxtransfertries - 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)

Example:
maxtransfertries="10"

[gridftpd] block

The [gridftpd] block configures the gridftpd server

user

user user[:group] - 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 value is root.

Example:
user="grid"

debug

debug debuglevel - Set debug level of the gridftpd daemon, between 0 (FATAL) and 5 (DEBUG). Default is 3 (INFO).

Example:
debug="2"

daemon

daemon yes|no - Whether GFS is run in daemon mode. Default is yes.

Example:
daemon="yes"

logfile

logfile path - Set logfile location

Example:
logfile="/var/log/arc/gridftpd.log"

logsize

logsize size [number] - 'Size' specifies in bytes how big log file is allowed to grow (approximately). If log file exceeds specified size it is renamed into logfile.0. And logfile.0 is renamed into logfile.1, etc. up to 'number' logfiles. Don't set logsize if you don't want to enable the ARC logrotation because another logrotation tool is used.

Example:
logsize="100000 2"

pidfile

pidfile path - Specify location of file containig PID of daemon process. This is useful for automatic star/stop scripts.

Example:
pidfile="/var/run/gridftpd.pid"

port

port bindport - Port to listen on (default 2811)

Example:
port="2811"

pluginpath

pluginpath - directory where the plugin libraries are installed, default is $ARC_LOCATION/lib(64)/arc

Example:
pluginpath="/usr/lib/arc/"

encryption

encryption yes|no - should data encryption be allowed, default is no, encryption is very heavy

Example:
encryption="no"

include

include - Include contents of another configuration file.

Example:
include="path"

allowunknown

allowunknown yes|no - if no, check user subject against grid-mapfile and reject if missing. By default unknown (not in the grid-mapfile) grid users are rejected

Example:
allowunknown="no"

maxconnections

maxconnections - maximum number of connections accepted by a gridftpd server. Default is 100.

Example:
maxconnections="200"

defaultbuffer

defaultbuffer size - defines size of every buffer for data reading/writing. Default is 65536. The actual value may decrease if the cumulative size of all buffers exceeds value specified by maxbuffer.

Example:
defaultbuffer="65536"

maxbuffer

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

Example:
maxbuffer="655360"

globus_tcp_port_range

globus_tcp_port_range, globus_udp_port_range - Firewall configuration

Example:
globus_tcp_port_range="9000,12000"
globus_udp_port_range="9000,12000"

firewall

firewall - hostname or IP addres to use in response to PASV command instead of IP address of a network interface of computer.

Example:
firewall="hostname"

x509_user_key

x509_user_cert, x509_user_key - Server credentials location

Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"

x509_cert_dir

x509_cert_dir - Location of trusted CA certificates

Example:
x509_cert_dir="/etc/grid-security/certificates"

gridmap

gridmap - The gridmap file location The default is /etc/grid-security/grid-mapfile

Example:
gridmap="/etc/grid-security/grid-mapfile"

unixmap

unixmap [unixname][:unixgroup] rule - more sophisticated way to map Grid identity of client to local account. If client matches 'rule' it's assigned specified unix identity or one generated by rule. Mapping commands are processed sequentially and processing stops at first successful one (like in [group] section). For possible rules read "ARC Computing Element. System Administrator guide" manual. All rules defined in [group] section canbe used. There are also additional rules which produce not only yes/no result but also give back user and group names to which mapping should happen. The way it works is quite complex so it is better to read full documentation.

For safety reasons if sophisticated mapping is used it is better to finish mapping sequence with default mapping to nonexistent or safe account.

Example:
unixmap="nobody:nogroup all"

unixgroup

unixgroup group rule - do mapping only for users belonging to specified authorization 'group'. It is similar to an additional filter for unixmap command which filters out all users not belonging to specified authorization group. Only rules which generate unix user and group names may be used in this command. Please read "ARC Computing Element System Administrator Guide" for more information.

Example:
unixgroup="users simplepool /etc/grid-security/pool/users"

unixvo

unixvo vo rule - do mapping only for users belonging to specified VO. Only rules which generate unix identity name may be used in this command. Please read "ARC Computing Element. System Administrator Guide" for more information. This command is similar to 'unixgroup' described above and exists for convenience for setups which base mapping on VOs users belong to.

Example:
unixvo="ATLAS unixuser atlas:atlas"

[gridftpd/filedir] block

[gridftpd/filedir] "fileplugin" storage block subblock for "exporting" a directory using the gridftpd's fileplugin plugin. gridftp plugins are shared libraries. "filedir" is a unique label. The access control is set by using the "dir" configuration option

plugin

plugin name - specifies name of shared library to be loaded relative to "pluginpath". The next line is MUST for a gridftp file server with "fileplugin", don't change anything

Example:
plugin="fileplugin.so"

groupcfg

groupcfg group_name [group_name ...] - specifies authorization groups for which this plugin is activated. In case groupcfg is not used the plugin is loaded for every mapped grid user. Multiple names were may be specified delimited by blank space. Group names are as specified in [group] sections.

Example:
groupcfg="users"

path

the name of the virtual directory served by the gridftp server, REQUIRED the exported storage area is accessible as gsiftp://my_server/topdir. "topdir" is just an example, call the virtual path anything you like, even "/" is a valid choice.

Example:
path="/topdir"

mount

the physical directory corresponding to the virtual one: gsiftp://my_server/topdir will give access to the /scratch/grid directory on my_server, REQUIRED

Example:
mount="/scratch/grid"

dir

dir - this is the access control parameter, you can have several "dir" lines controlling different directories within then same block

 dir path options  - specifies access rules for accessing files in 'path' (relative to virtual and real path) and all the files and directories below.
 'options' are:
      nouser  - do not use local file system rights, only use those
                specifies in this line
      owner   - check only file owner access rights
      group   - check only group access rights
      other   - check only "others" access rights
  if none of the above specified usual unix access rights are applied.
      read    - allow reading files
      delete  - allow deleting files
      append  - allow appending files (does not allow creation)
      overwrite - allow overwriting already existing files (does not 
                allow creation, file attributes are not changed)
      dirlist - allow obtaining list of the files
      cd      - allow to make this directory current
      create owner:group permissions_or:permissions_and  - allow creating
                new files. File will be owned by 'owner' and owning group
                will be 'group'. If '*' is used, the user/group to which
                connected user is mapped will be used. The permissions 
                will be set to permissions_or & permissions_and. (second
                number is reserved for the future usage). 
                
      mkdir owner:group permissions_or:permissions_and  - allow creating new directories.

Example:
Set permissions on mounted directory:
dir="/ nouser read cd dirlist delete create *:* 664:664 mkdir *:* 775:775"

Example:
Adjust permissions on some subdirectories:
dir="/section1 nouser read mkdir *:* 700:700 cd dirlist"
dir="/section2 nouser read mkdir *:* 700:700 cd dirlist"

[gridftpd/jobs] subblock

[gridftpd/jobs] subblock which creates the jobsubmission interface, using the jobplugin of the gridftpd service. gridftp plugins are shared libraries. 'jobs' is a unique label.

path

the path to the virtual gridftpd directory which is used during the job submission. MUST be set.

Example:
path="/jobs"

plugin

plugin name - specifies name of shared library to be loaded relative to "pluginpath". The next line is MUST for a job submission service via gridftpd "jobplugin", don't change anything!

Example:
plugin="jobplugin.so"

groupcfg

groupcfg group_name [group_name ...] - specifies authorization groups for which this plugin is activated. In case groupcfg is not used the plugin is loaded for every mapped grid user.

Example:
groupcfg="users"

allownew

The 'allownew' configuration parameter sets if the grid resource accepts submission of new jobs. This parameter can be used to close down a grid. The default is yes

Example:
allownew="yes"

remotegmdirs

remotegmdirs controldir sessiondir - Specifies control and session directories to which jobs can be submitted but which are under the control of another A-REX. The corresponding controldir and sessiondir parameters must be defined in another A-REX's configuration. Multiple remotegmdirs can be specified.

Example:
remotegmdirs="/mnt/host1/control /mnt/host1/session"

maxjobdesc

maxjobdesc size - specifies maximal allowed size of job description in bytes. Default value is 5MB. If value is missing or 0 size is not limited.

Example:
maxjobdesc="5242880"

configfile

configfile service_configuration_path - If [gridftpd] and [grid-manager] configuration parts are located in separate files this configuration option allows to link them. The service_configuration_path points to configuration file containing [grid-manager] section. Use this option only if You really know what You are doing.

Example:
configfile="/etc/arc.conf"

[infosys] block

[infosys] block configures the hosting environment of the Information services (Local Info Tree, Index Service, Registrations, see the Information System manual) provided by the OpenLDAP slapd server.

infosys_compat

infosys_compat - Setting this variable will cause ARC to use the old infoproviders. Basically, the new version uses A-REX to create LDIF while the old version uses a BDII provider-script to do it. The new version is required for GLUE2 output.

Example:
infosys_compat="disable"

infoproviders_timeout

infoproviders_timeout - this only applies to new infoproviders. it changes A-REX behaviour with respect to a single infoprovider run. Increase this value if you have many jobs in the controldir and infoproviders need more time to process. The value is in seconds. Default is 600 seconds.

Example:
infoproviders_timeout = "600"

debug

debug - sets the debug level/verbosity of the startup script {0 or 1}. Default is 0.

Example:
debug="1"

hostname

hostname - the hostname of the machine running the slapd service will be the bind for slapd. If not present, will be taken from the [common] block or guessed

Example:
hostname="my.testbox"

port

port - the port where the slapd service runs. Default infosys port is 2135.

Example:
port="2135"

slapd_loglevel

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

Example:
slapd_loglevel="0"

slapd_hostnamebind

slapd_hostnamebind - 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 configuration parameter is already sufficient. The default is empty. The example below will bind the slapd process to all the network interfaces available on the server.

Example:
slapd_hostnamebind="*"

threads

threads - the native slapd threads parameter, default is 32. If you run an Index service too you should modify this value.

Example:
threads="128"

timelimit

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

Example:
timelimit="1800"

idletimeout

idletimeout - the native slapd idletimeout parameter. Maximum number of seconds the slapd server will wait before forcibly closing idle client connections. Its value must be larger than the value of "timelimit" option. If not set, it defaults to timelimit + 1.

Example:
idletimeout="1800"

ldap_schema_dir

ldap_schema_dir - allows to explicitly specify a 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. If you plan to relocate Glue1 and GLUE2 schemas, all these should be in the same directory that you specify here. this option does NOT apply to nordugrid.schema file. Such file has a release dependent location. Default is to use only standard locations described above.

Example:
ldap_schema_dir="/nfs/ldap/schema/"

oldconfsuffix

oldconfsuffix .suffix - sets the suffix of the backup files of the low-level slapd configuration files in case they are regenerated. Default is ".oldconfig".

Example:
oldconfsuffix=".oldconfig"

overwrite_config

overwrite_config yes|no - determines if the infosys startup scripts should generate new low-level slapd configuration files. By default the low-level configuration files are regenerated with every server startup making use of the values specified in the arc.conf.

Example:
overwrite_config="yes"

registrationlog

registrationlog path - specifies the logfile for the registration processes initiated by your machine. Default is "/var/log/arc/inforegistration.log"

Example:
registrationlog="/var/log/arc/inforegistration.log"

providerlog

providerlog path - Specifies log file location for the information provider scripts. The feature is only available with >= 0.5.26 tag. Default is "/var/log/arc/infoprovider.log"

Example:
providerlog="/var/log/arc/infoprovider.log"

provider_loglevel

provider_loglevel - loglevel for the infoprovider scripts (0-5). The default is 1 (critical errors are logged)

Example:
provider_loglevel="2"

user

user unix_user - the unix user running the infosys processes such as the slapd, the registrations and infoprovider scripts. By default the ldap-user is used, you can run it as root if you wish. In case of non-root value you must make sure that the A-REX directories and their content are readable by the 'user' and the 'user' has access to the full LRMS information including jobs submitted by other users. The A-REX directories (controldir, sessiondir runtimedir, cachedir) are specified in the [grid-manager] block

Example:
user="root"

giis_location

giis_location - If giis_location is not set, ARC_LOCATION will be used instead.

Example:
giis_location="/usr/"

infosys_nordugrid

These three variables decide which schema should be used for publishing data. They can all be enabled at the same time. Default is to enable nordugrid mds and disable glue. infosys_nordugrid - Enables NorduGrid schema

Example:
infosys_nordugrid="enable"

infosys_glue12

infosys_glue12 - Enables glue1.2/1.3 schema If infosys_glue12 is enabled, then resource_location, resource_latitude and resource_longitude need to be set in the [infosys/glue12] block. These variables do not have default values. The rest of the variables defaults are showcased below.

Example:
infosys_glue12="disable"

infosys_glue2_ldap

infosys_glue2 - Enables GLUE2 schema

Example:
infosys_glue2_ldap="disable"

infosys_glue2_ldap_showactivities

infosys_glue2_ldap_showactivities - Enables GLUE2 ComputingActivities to appear in the LDAP rendering they're currently disabled by default.

Example:
infosys_glue2_ldap_showactivities="disable"

infosys_glue2_service_qualitylevel

infosys_glue2_service_qualitylevel - Allows a sysadmin to define a different GLUE2 QualityLevel for A-REX. This can be used for operations. default: production Allowed value is one of: "production", "pre-production", "testing", "development" Refer to GLUE2 documentation for the meaning of these strings.

Example:
infosys_glue2_service_qualitylevel="production"

slapd

slapd - Configure where the slapd command is located, default is: /usr/sbin/slapd

Example:
slapd="/usr/sbin/slapd"

slapadd

slapadd - Configure where the slapadd command is located, default is: /usr/sbin/slapadd

Example:
slapadd="/usr/sbin/slapadd"

BDII specific

Starting from 11.05, Nordugrid ARC only supports BDII5. These variables are usually automatically set by ARC, and are here mostly for debug purposes and to tweak exotic BDII5 installations. In general, a sysadmin should not set these.

bdii_debug_level

bdii_debug_level - set the following to DEBUG to check bdii errors in bdii-update.log useful not to enable slapd logs reducing performance issues.

Example:
bdii_debug_level="ERROR"

provider_timeout

provider_timeout - This variable allows a system administrator to modify the behaviour of bdii-update. This is the time BDII waits for the scripts generated by A-REX infoproviders to produce their output. Default is 300 seconds.

Example:
provider_timeout=300

infosys_debug

infosys_debug - This variable disables/enables an ldap-database containing information about the ldap database itself on "o=infosys" it is very useful for debugging. Default is enabled.

Example:
infosys_debug="disable"

BDII5 uses the following variables. These might change depending on BDII version. ARC sets them by inspecting distributed bdii configuration files. DO NOT CHANGE UNLESS YOU KNOW WHAT YOU'RE DOING

bdii_location

bdii_location - The installation directory for the BDII. Default is /usr

Example:
bdii_location="/usr"

bdii_var_dir

bdii_var_dir - Contains BDII pid files and slapd pid files

Example:
bdii_var_dir="/var/run/arc/bdii"

bdii_log_dir

bdii_log_dir - Contains infosys logs

Example:
bdii_log_dir="/var/log/arc/bdii"

bdii_tmp_dir

bdii_tmp_dir - Contains provider scripts

Example:
bdii_tmp_dir="/var/tmp/arc/bdii"

bdii_lib_dir

bdii_lib_dir - Contains slapd databases

Example:
bdii_lib_dir="/var/lib/arc/bdii"

bdii_update_pid_file

bdii_update_pid_file, slapd_pid_file - Allows to change bdii-update and slapd pidfiles filename and location

Example:
bdii_update_pid_file="/var/run/arc/bdii-update.pid"
slapd_pid_file="$bdii_var_dir/db/slapd.pid"

bdii_database

bdii_database - Configure what ldap database backend should be used, default is: bdb

Example:
bdii_database="bdb"

The following options are for tweaking only. Usually one should not configure them. They change the BDII configuration file generated by ARC. Please consult BDII manual for details.

bdii_conf

bdii_conf - Location of the bdii configuration file. ARC modifies the original and sets it as default /var/run/arc/infosys/bdii.conf

Example:
bdii_conf="/var/run/arc/infosys/bdii.conf"

Command line options used to run bdii-update. ARC finds it looking into bdii configuration. default: ${bdii_location}/sbin/bdii-update

bdii_update_cmd
bdii_archive_size
bdii_db_config
bdii_breathe_time
bdii_delete_delay
bdii_read_timeout
bdii_run_dir
bindmethod
cachettl
db_archive
db_checkpoint

EGIIS-related commands

giis_fifo

giis_fifo - path to fifo used by EGIIS. default is /var/run/arc/giis-fifo This file is automatically created by ARC, the option is only for tweaking.

Example:
giis_fifo=/var/run/arc/giis-fifo

LDAP parameters of the cluster.pl (old) infoprovider, use the defaults, do NOT change them unless you know what you are doing

cachetime

cachetime affects old infoproviders, and forces the validity time of the record.

Example:
cachetime="30"

sizelimit

sizelimit affects registration to egiis

Example:
sizelimit="10"

slapd_cron_checkpoint

slapd_cron_checkpoint - LDAP checkpoint enable/disable This option was introduced to solve bug #2032, to reduce the number of log files produced by BDII. It is usually not needed, but if BDII produces large logs and huge number of files, should help solving the issues related to that.

Example:
slapd_cron_checkpoint="enable"

[infosys/glue12] block

This block holds information that is needed by the glue 1.2 generation. This is only necessary if infosys_glue12 is enabled.

resource_location

These variables need to be set if infosys_glue12 is enabled. IMPORTANT: no slashes or backslashes here! Example: "Kastrup, Denmark"

Example:
resource_location=""

resource_latitude

Example: "55.75000"

Example:
resource_latitude=""

resource_longitude

Example: "12.41670"

Example:
resource_longitude=""

cpu_scaling_reference_si00

Example 2400

Example:
cpu_scaling_reference_si00=""

processor_other_description

Example Cores=3,Benchmark=9.8-HEP-SPEC06

Example:
processor_other_description=""

glue_site_web

Example http://www.ndgf.org

Example:
glue_site_web=""

glue_site_unique_id

Example NDGF-T1

Example:
glue_site_unique_id=""

provide_glue_site_info

This variable decides if the GlueSite should be published. In case you want to set up a more complicated setup with several publishers of data to a GlueSite, then you may wish to tweak this parameter.

Example:
provide_glue_site_info="true"

[infosys/site/sitename] block

[infosys/site/sitename] Site BDII configuration block, this block is used to configure ARC to generate a site-bdii that can be registered in GOCDB etc to make it a part of a gLite network. The sitename part is to be declarative of the site-bdii being generated.

unique_id

The unique id used to identify this site, eg "NDGF-T1"

Example:
unique_id=""

url

The URL is of the format: ldap://host.domain:2170/mds-vo-name=something,o=grid and should point to the resource-bdii

Example:
url=""

[infosys/admindomain] block

[infosys/admindomain] GLUE2 AdminDomain configuration block, to configure administrative items of the cluster. This values do not affect neither glue12 or nordugrid renderings. If the whole block is not specified, will default to an AdminDomain called UNDEFINEDVALUE.

name

name - the Name attribute for the domain. 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.

Example:
name="ARC-TESTDOMAIN"

description

description - description of this domain. Not mandatory.

Example:
description="ARC test Domain"

www

www - URL pointing at a site holding information about the AdminDomain. Not mandatory.

Example:
www="http://www.nordugrid.org/"

distributed

distributed - set this to yes if the domain is distributed that means, if the resources belonging to the domain are considered geographically distributed.

Example:
distributed=yes

owner

owner - contact email of a responsible subject for the domain

Example:
[email protected]

otherinfo

otherinfo - fills the OtherInfo GLUE2 field. no need to set, used only for future development.

Example:
otherinfo=Test Other info

[infosys/index/indexname] block

[infosys/index/indexname] Index Service block configures and enables an Information Index Service. A separate Index block is required for every Index Service you may run on the given machine. The 'indexname' constitutes to the

name

name - The unique (within the hosting machine) name of the Index Service. Its value becomes part of the LDAP suffix of the Index Service: (mds-vo-name=value of the name attribute, o=grid)

Example:
name="indexname"

allowreg

allowregistration - Implements registration filtering within an Index Sevice Sets the Local Information Trees or lower level Index Services allowed to register to the Index Service. List each allowed registrants with the allowreg attribute.

WARNING: specifying allowreg implies setting up a strict filtering, only the matching registrants will be able to register to the Index. The wildcard * can be used in allowreg. Several allowreg lines can be used. Some examples:
 -All the Swedish machines can register regardless they are resources or Indices allowreg="*.se:2135"
 -Cluster resources from Denmark can register allowreg="*.dk:2135/nordugrid-cluster-name=*, Mds-Vo-name=local, o=grid"
 -Storage resources from HIP, Finland can register allowreg="*hip.fi:2135/nordugrid-se-name=*, Mds-Vo-name=local, o=grid"
 -The index1.sweden.se can register as a Sweden Index  (and only as a Sweden Index) allowreg="index1.sweden.se:2135/Mds-vo-Name=Sweden,o=Grid"
 -Any Index Service can register allowreg="*:2135/Mds-vo-Name=*,o=Grid"

Example:
allowreg="trusted.host.org.se:2135/Mds-vo-Name=Trusted-Index,o=Grid"

[infosys/index/indexname/registration/registrationname] block

[infosys/index/indexname/registration/registrationname] Index service registration block This block enables a registration process initiated by the to a target Index Service. NorduGrid maintains a webpage with information on major Index Services: http://www.nordugrid.org/NorduGridMDS/index_service.html

targethostname

targethostname - the hostname of the machine running the registration target Index Service

Example:
targethostname="index.myinstitute.org"

targetport

targetport - the port on which the target Index Service is running. The default is the 2135 Infosys port.

Example:
targetport="2135"

targetsuffix

targetsuffix - the LDAP suffix of the target Index Service

Example:
targetsuffix="mds-vo-name=BigIndex,o=grid"

regperiod

regperiod - The registration period in seconds, the registration messages are continously sent according to the regperiod. Default is 120 sec.

Example:
regperiod="300"

registranthostname

registranthostname - the hostname of the machine sending the registrations. This attribute inherits its value from the [common] and [infosys] blocks, most cases no need to set.

Example:
registranthostname="myhost.org"

registrantport

registrantport - the port of the slapd service hosting the registrant Index Service. The attribute inherits its value from the [infosys] block (and therefore defaults to 2135)

Example:
registrantport="2135"

registrantsuffix

registrantsuffix - the LDAP suffix of the registrant Index Service. It is automatically determined from the registration block name, therefore most of the cases no need to specify. In this case the default registrantsuffix will be:
                 "Mds-Vo-name=indexname"

please mind uppercase/lowercase characters in the above string when defining allowreg in an index! Don't set it unless you want to overwrite the default.

Example:
registrantsuffix="mds-vo-name=indexname,o=grid"

[cluster] block

This block configures how your cluster is seen on the grid monitor (infosys point of view). Please consult the Infosys manual for detailed information on cluster attributes. If you want your cluster (configured below) to appear in the infosys (on the monitor) you also need to create a cluster registration block (see the next block).

hostname

hostname - the FQDN of the frontend node, if the hostname is not set already in the common block then it MUST be set here

Example:
hostname="myhost.org"

interactive_contactstring

interactive_contactstring - the contact string for interactive logins, set this if the cluster supports some sort of grid-enabled interactive login (gsi-ssh), multivalued

Example:
interactive_contactstring="gsissh://frontend.cluster:2200"

cluster_alias

alias - an arbitrary alias name of the cluster, optional

Example:
cluster_alias="Big Blue Cluster in Nowhere"

comment

comment - a free text field for additional comments on the cluster in a single line, no newline character is allowed!

Example:
comment="This cluster is specially designed for XYZ applications: www.xyz.org"

cluster_location

cluster_location - The geographical location of the cluster, preferably specified as a postal code with a two letter country prefix

Example:
cluster_location="DK-2100"

cluster_owner

cluster_owner - it can be used to indicate the owner of a resource, multiple entries can be used

Example:
cluster_owner="World Grid Project"
cluster_owner="University of NeverLand"

authorizedvo

authorizedvo - this attribute is used to advertise which VOs are authorized on the cluster. Multiple entries are allowed. This entries will be shown in GLUE2 AccessPolicy and MappingPolicy objects.

Example:
authorizedvo="developer.nordugrid.org"
authorizedvo="community.nordugrid.org"

clustersupport

clustersupport - this is the support email address of the resource, multiple entries can be used

Example:
clustersupport="[email protected]"
clustersupport="[email protected]"

lrmsconfig

lrmsconfig - an optional free text field to describe the configuration of your Local Resource Management System (batch system).

Example:
lrmsconfig="single job per processor"

homogeneity

homogeneity - 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. Possible values: True,False, the default is True. False will trigger multiple GLUE2 ExecutionEnvironments to be published if applicable.

Example:
homogeneity="True"

architecture

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

Example:
architecture="adotf"

opsys

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

Example:
opsys="Linux-2.6.18"
opsys="glibc-2.5.58"
opsys="CentOS-5.6"

nodecpu

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

Example:
nodecpu="AMD Duron(tm) Processor @ 700 MHz"

nodememory

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

Example:
nodememory="512"

defaultmemory

defaultmemory - If a user submits a job without specifying how much memory should be used, this value will be taken first. The order is: xrsl -> defaultmemory -> nodememory -> 1GB. This is the amount of memory (specified in MB) that a job will request(per rank).

Example:
defaultmemory="512"

benchmark

benchmark name value - 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 one of standard benchmark names given below if possible.

Example:
benchmark="SPECINT2000 222"
benchmark="SPECFP2000 333"

middleware

middleware - the multivalued attribute shows the installed grid software on the cluster, nordugrid and globus-ng is automatically set, no need to specify middleware=nordugrid or middleware=globus

Example:
middleware="my grid software"

nodeaccess

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

Example:
nodeaccess="inbound"
nodeaccess="outbound"

dedicated_node_string

dedicated_node_string - the string which is used in the PBS node configuration 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 dedicated_node_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 configuration does not use the "node property" method to assign certain nodes to grid queues. You shouldn't use this configuration option unless you make sure your PBS configuration makes use of the above described setup.

Example:
dedicated_node_string="gridnode"

localse

localse - this multivalued parameter tells the BROKER that certain URLs (and locations below that) should be considered "locally" available to the cluster.

Example:
localse="gsiftp://my.storage/data1/"
localse="gsiftp://my.storage/data2/"

gm_mount_point

gm_mount_point - this is the same as the "path" from the [gridftpd/jobs] block. The default is "/jobs". Will be cleaned up later, do NOT touch it.

Example:
gm_mount_point="/jobs"

gm_port

gm_port - this is the same as the "port" from the [gridftpd] block. The default is "2811". Will be cleaned up later.

Example:
gm_port="2811"

cpudistribution

cpudistribution - this is the CPU distribution over nodes given in the form: ncpu:m where
  n is the number of CPUs per machine
  m is the number of such computers

Example: 1cpu:3,2cpu:4,4cpu:1 represents a cluster with 3 single CPU machines, 4 dual CPU machines, one machine with 4 CPUs. This command is needed to tweak and overwrite the values returned by the underlying LRMS. In general there is no need to configure it.

Example:
cpudistribution=1cpu:3,2cpu:4,4cpu:1

[infosys/cluster/registration/registrationname] block

Computing resource (cluster) registration block configures and enables the registration process of a computing resource to an Index Service. A cluster can register to several Index Services this case each registration process should have its own block. NorduGrid maintains a webpage with information on major Index Services: http://www.nordugrid.org/NorduGridMDS/index_service.html

targethostname

targethostname - see description earlier

Example:
targethostname="index.myinstitute.org"

targetport

targetport - see description earlier

Example:
targetport="2135"

targetsuffix

targetsuffix - see description earlier

Example:
targetsuffix="mds-vo-name=BigIndex,o=grid"

regperiod

regperiod - see description earlier

Example:
regperiod="300"

registranthostname

registranthostname - see description earlier

Example:
registranthostname="myhost.org"

registrantport

registrantport - see description earlier

Example:
registrantport="2135"

registrantsuffix

registrantsuffix - the LDAP suffix of the registrant cluster resource It is automatically determined from the [infosys] block and the registration blockname. In this case the default registrantsuffix will be:
   "nordugrid-cluster-name=hostname,Mds-Vo-name=local,o=Grid"

please mind uppercase/lowercase characters above if defining allowreg in an index! Don't set it unless you want to overwrite the default.

Example:
registrantsuffix="nordugrid-cluster-name=myhost.org,Mds-Vo-name=local,o=grid"

[queue/queue_name] block

Each grid-enabled queue should have a separate queue block. The queuename should be used as a label in the block name. 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 is specified in the [common] block.

Queues don't need to be registered (there is no queue registration block), once you configured your cluster to register to an Index Service the queue entries (configured with this block) automatically will be there. Please consult the ARC Information System manual for detailed information on queue attributes:
  http://www.nordugrid.org/documents/arc_infosys.pdf
   use the queue_name for labeling the block. The special name 'fork' should be used for labeling the queue block in case you specified 'fork' type of LRMS in the [common] block.

name

name sets the name of the grid-enabled queue. It MUST match the queue_name label of the corresponding queue block, see above. Use "fork" if you specified 'fork' type of LRMS in the [common] block. Queue name MUST be specified, even if the queue block is already correctly labeled.

Example:
name="gridlong"

homogeneity

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

Example:
homogeneity="True"

scheduling_policy

scheduling_policy - this optional parameter tells the schedulling policy of the queue, PBS by default offers the FIFO scheduller, many sites run the MAUI. At the moment FIFO & MAUI is supported. If you have a MAUI scheduller you should specify the "MAUI" value since it modifies the way the queue resources are calculated. BY default the "FIFO" sceduller is assumed.

Example:
scheduling_policy="FIFO"

comment

comment - a free text field for additional comments on the queue in a single line, no newline character is allowed!

Example:
comment="This queue is nothing more than a condor pool"

maui_bin_path

maui_bin_path - set this parameter for the path of the maui commands like showbf in case you specified the "MAUI" scheduling_policy above. This parameter can be set in the [common] block as well.

Example:
maui_bin_path="/usr/local/bin"

queue_node_string

queue_node_string - In PBS you can assign nodes to a queue (or a queue to nodes) by using the "node property" PBS node configuration method and asssigning the marked nodes to the queue (setting the resources_default.neednodes = queue_node_string for that queue). This parameter should contain the "node property" string of the queue-assigned nodes. Setting the queue_node_string changes how the queue-totalcpus, user freecpus are determined for this queue. Essentially, queue_node_string value is used to construct nodes= string in PBS script, such as nodes=count:queue_node_string where count is taken from the job description (1 if not specified). 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

Example:
queue_node_string="gridlong_nodes"
queue_node_string="ppn=4:ib"

sge_jobopts

sge_jobopts - additional SGE options to be used when submitting jobs to SGE from this queue. If in doubt, leave it commented out

Example:
sge_jobopts="-P atlas -r yes"

condor_requirements

condor_requirements - only needed if using Condor. It needs to be defined for each 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:

Example:
condor_requirements="(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)"

lsf_architecture

CPU architecture to request when submitting jobs to LSF. Use only if you know what you are doing.

Example:
lsf_architecture="PowerPC"

totalcpus

totalcpus - 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). Use this static parameter only if some special method is applied to assign a subset of totalcpus to the queue.

Example:
totalcpus="32"

nodecpu

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

Example:
nodecpu="adotf"
nodememory="512"
architecture="adotf"
opsys="Fedora 16"
opsys="Linux-3.0"
benchmark="SPECINT2000 222"
benchmark="SPECFP2000 333"

ac_policy

queue access policy rules based on VOMS attributes in user's proxy certificate (requires the arc-vomsac-check plugin to be enabled). Matching rules have the following format:
  ac_policy="[+/-]VOMS: <FQAN>"

Please read arc-vomsac-check manual page for more information.

Example:
ac_policy="-VOMS: /badvo"
ac_policy="VOMS: /.*/Role=production"

authorizedvo

authorizedvo - this attribute is used to advertise which VOs are authorized on the specific queue. Multiple entries are allowed. This entries will be shown in the MappingPolicy objects. If something is already defined in the [cluster] block, the shown VOs will be the union set of those defined in [cluster] with those specific to this [queue] block.

Example:
authorizedvo="LocalUsers"
authorizedvo="atlas"
authorizedvo="community.nordugrid.org"

cachetime

this affects old infoproviders, and forces the validity time of the record.

Example:
cachetime="30"

sizelimit

sizelimit affects registration to EGIIS

Example:
sizelimit="5000"

[registration/emir] block

Services registration into EMIR block configures and enables the registration process of a services enabled in this configuration file into EMI indexing service (EMIR).

emirurls

List of URL separated by comma of EMIR services which are to accept registration. This is mandatory.

Example:
emirurls="https://somehost:60002/emir"

validity

Time in seconds for which registration records should stay valid.

Example:
validity=600

period

Time in seconds how othen registration record should be sent to the registration service.

Example:
period=60

disablereg_xbes

disablereg_xbes may be used to selectively disable registration of A-REX service. Possible values are yes and no. Default is no,

Example:
disablereg_xbes="no"

[nordugridmap] block

[nordugridmap] block configuration is used to fine-tune behaviour of the nordugridmap - an ARC tool used to generate grid-mapfiles. Please refer to [vo] block description to find information how to specify VO sources for mapfile generation. This section setup general VO-independent parameters.

x509_user_key

x509_user_cert, x509_user_key - public certificate and privat key to be used when fetching sources over TLS (https:// and vomss:// sources retrieval rely on this parameter) If not specified, values defined in [common] section will be used. If there is also no [common] section, X509_USER_{CERT,KEY} variables are used. Default is '/etc/grid-security/host{cert,key}.pem'

Example:
x509_user_key="/etc/grid-security/hostkey.pem"
x509_user_cert="/etc/grid-security/hostcert.pem"

x509_cert_dir

x509_cert_dir - the directory containing CA certificates. This information is needed by the 'require_issuerdn' [vo] block option. Default is '/etc/grid-security/certificates/'.

Example:
x509_cert_dir="/etc/grid-security/certificates/"

generate_vomapfile

generate_vomapfile - control is nordugridmap will generate vo-mapfile used by arc-ur-logger. Default is 'yes'.

Example:
generate_vomapfile="yes"

vomapfile

vomapfile - path to vo-mapfile location. Default is /etc/grid-security/grid-vo-mapfile

Example:
vomapfile="/etc/grid-security/grid-vo-mapfile"

log_to_file

log_to_file - control whether logging output of nordugridmap will be saved to file. Default is 'no' (STDERR is used).

Example:
log_to_file="yes"

logfile

logfile - specify the nordugridmap log file location when in use. Default is '/var/log/arc/nordugridmap.log'.

Example:
logfile="/var/log/arc/nordugridmap.log"

cache_enable

cache_enable - control whether caching of external sources will be used. Default is 'yes'.

Example:
cache_enable="yes"

cachedir

cachedir - specify the path where cached sources will be stored. Default is '/var/spool/nordugrid/gridmapcache/'

Example:
cachedir="/var/spool/nordugrid/gridmapcache/"

cachetime

cachetime - controls how many time (in seconds) cached information remains valid. Default is 259200 (3 days).

Example:
cachetime="259200"

issuer_processing

issuer_processing - control the behaviour of [vo] block require_issuerdn parameter. Valid values are 'relaxed' and 'strict'. Please see 'require_issuerdn' description in [vo] block for details. Default is 'relaxed'.

Example:
issuer_processing="relaxed"

mapuser_processing

mapuser_processing - control the behaviour of [vo] block mapped_unixid parameter usage. Valid values are 'overwrite' and 'keep'. Please see 'mapped_unixid' description in [vo] block for details. Default is 'keep'.

Example:
mapuser_processing="keep"

allow_empty_unixid

allow_empty_unixid - control whether empty (or unspecified) Please see 'mapped_unixid' description of [vo] block for details. Default is 'no'

Example:
allow_empty_unixid="no"

voms_method

voms_method - control 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 Default is 'soap'.

Example:
voms_method="soap"

debug

debug level - 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) debug level is automatically set to 5 (DEBUG). Default is 2 (WARNING)

Example:
debug="4"

fetch_timeout

fetch_timeout - control how many time (in seconds) nordugridmap will wait for external sources retrieval. Default is 15.

Example:
fetch_timeout="15"

The [acix/cacheserver] block

The cache server component of ACIX runs alongside A-REX. It periodically scans the cache directories and composes a Bloom filter of cache content which can be pulled by an ACIX index server.

logfile

Log file location for the cache server. Default is /var/log/arc/acix-cache.log

Example:
logfile="/tmp/acix-cache.log"

cachedump

Whether to make a dump of the cache contents in a file at $TMP/ARC-ACIX/timestamp each time the cache server runs. Default is no.

Example:
cachedump="yes"

The [acix/indexserver] block

The index server component of ACIX collects cache content filters from a set of cache servers configured in this block. The index server can be queried for the location of cached files.

cacheserver

ACIX cache servers from which to pull information

Example:
cacheserver="https://some.host:5443/data/cache"
cacheserver="https://another.host:5443/data/cache"