arc.conf (5) - Linux Manuals
arc.conf: ARC configuration
NAME
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 expert-debug-on/no - Switch on or off performance reporting. Default is no. Only switch on if you specifically need it, and are aware of the possible local root exploit due to permissive directory.
Example:
enable_perflog_reporting="expert-debug-on"- 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_unixidfor http(s),voms(s),ldap and file URLs
cache_enablefor http(s),voms(s),ldap and file URLs
voms_methodfor voms(s) URLs
mapuser_processingfor file URLs with mapped_unixid='<unixid>' 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