Provided by: nordugrid-arc-hed_5.0.5-1ubuntu1_amd64 bug

NAME

       arc.conf - ARC configuration

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"

[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 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.  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 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/bob/.* dn /O=Grid/CN=Bob"

       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="grid.support@somewhere.org"

       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"

[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:
              owner=admin@nordugrid.org

       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="grid.support@mysite.org"
              clustersupport="grid.support@myproject.org"

       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"

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"