Provided by: nordugrid-arc-hed_1.1.1-1_i386 bug

NAME

       arc.conf, .arc/client.conf - ARC configuration

DESCRIPTION

       Configuration files for NorduGrid ARC.

SYNOPSIS

       /etc/arc.conf

       ${ARC_LOCATION}/etc/arc.conf

       ${HOME}/.arc/client.conf

DESCRIPTION

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

       The  ARC  configuration  file  can  be  written in one of two different
       formats: plain text or xml. In the plain text format 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"

       In the xml format the arc configuration file consist of a single  "arc"
       xml  element. Inside this element each configuration block appears as a
       separate xml element named after the block's identifying keyword.  This
       block in turn contains attribute value pairs in the following format:

       <arc>
        <keyword1>
         <attribute1>value1</attribute1>
         <attribute2>value2</attribute2>
        </keyword1>
        <keyword2>
         <attribute>value</attribute>
        </keyword2>
       </arc>

       However,  if  a  configuration  block has an id attribute, it should be
       given as an xml attribute to the keyword instead:

       <keyword id="value">

       Some options can also have suboptions. In the plain text  format  these
       are  given  as a comma separated list without spaces of attribute value
       pairs before the option value:

       attribute="subattr1=subval1,subattr2=subval2 value"

       In the xml format the suboptions are given as  attributes  to  the  xml
       tag:

       <attribute subattr1="subval1" subattr2="subval2">value</attribute>

       The  following  keywords  are  used in the block names: common, client,
       group,  vo,  grid-manager,  gridftpd,  httpsd,  infosys,  registration,
       cluster, queue, se, rc.

       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.

       For  ARC  client  applications  each  user  can  specify   a   personal
       configuration  file  at  ${HOME}/.arc/client.conf.  Only the common and
       client blocks are used in this file. If this file  is  not  present  or
       does  not  contain  the  relevant  configuration information the global
       configuration files are read instead.

COMMON OPTIONS

       Options listed in the common configuration block affect  all  parts  of
       the  ARC  middleware,  unless overridden in a configuration block for a
       particular service or a command line option.

CLIENT OPTIONS

       giis   Configures which GIISes to use to discover computing and storage
              resources. The default is to use the four top level GIISes:

              ldap://index1.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
              ldap://index2.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
              ldap://index3.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
              ldap://index4.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid

              This option can be repeated several times.

              Example (plain text):

              giis="ldap://atlasgiis.nbi.dk:2135/O=Grid/Mds-Vo-name=Atlas"

              Example (xml):

              <giis>ldap://odin.switch.ch:2135/O=Grid/Mds-Vo-
              name=Switzerland</giis>

       debug

              Default debug level to use for the arc clients.  Corresponds  to
              the -d command line switch of the clients. Default value is 0.

              Example (plain text): debug="2"

              Example (xml): <debug>2</debug>

       timeout
              Timeout  to  use  for  interaction  with  LDAP  servers, gridftp
              servers, etc. If a server, during e.g. job submission, does  not
              answer  in  the  specified  number of seconds, the connection is
              timed out and closed. Default value is 20 seconds.

              Example (plain text): timeout="20"

              Example (xml): <timeout>10</timeout>

       downloaddir
              Default download directory to download files to when  retrieving
              output  files from jobs using arccli get. Default is the current
              working directory.

              Example (plain text): downloaddir="/home/johndoe/arc-downloads"

              Example (xml): <downloaddir>/tmp/johndoe</downloaddir>

       alias  Alias substitutions to perform in connection with the -c command
              line switch of the arc clients. Alias definitions are recursive.
              Any alias defined in a block that is read before a  given  block
              can be used in alias definitions in that block. An alias defined
              in a block can also be used in alias definitions  later  in  the
              same block. This option can be repeated several times.

              Example (plain text):

              alias="host1=somehost.nbi.dk"
              alias="host2=otherhost.uu.se"
              alias="myhosts=host1 host2"

              Example (xml):

              <alias>host1=somehost.nbi.dk</alias>
              <alias>host2=otherhost.uu.se</alias>
              <alias>myhosts=host1 host2</alias>

              With  the  example  above  "arcsub  -c  myhosts" will resolve to
              "arcsub -c somehost.nbi.dk -c otherhost.uu.se"

       broker Configures which  broker  to  use  during  job  submission.  The
              default  one  is  the FastestCpus broker that chooses, among the
              possible targets, the target  with  the  fastest  CPUs.  Another
              possibility  is  the  RandomSort  broker that chooses the target
              randomly  among  the  targets  surviving  the  job   description
              matchmaking.

              Example (plain text): broker="RandomSort"

              Example (xml): <broker>RandomSort</broker>

GROUP OPTIONS

       The  group configuration blocks define rules used to determine to which
       authorisation groups  a  user  belongs.  Each  authorisation  group  is
       defined  in  its  own  group  configuration block and should be given a
       unique id. If the plain text format is used,  the  authorisation  group
       "users" is defined by:

       [group]
       id="users"

       If  the  xml  format  is  used  the  same  block  is  defined using the
       attributed xml tag:

       <group id="users">...</group>

       The attribute value pairs in  a  group  configuration  block  represent
       rules  for  allowing  or  denying  users as members of the group. These
       rules are processed in order of appearance. The first rule that matches
       the  information  presented  by  a  user  stops  the  processing of the
       remaining rules in the block. The result of a rule can be inverted,  so
       that  a  matching  rule  counts  as non-matching and vice versa. In the
       plain text  format  this  is  done  by  prepending  the  rule  with  an
       exclamation  mark.  In  the  xml  format  it  is done by adding a match
       attribute with the value "inverted" to the rule's xml tag.

       A matching rule can either allow or deny a  user.  If  the  plain  text
       format  is  used an allow rule is defined by prepending a the rule with
       plus sign and a deny rule by prepending it with a minus  sign.  If  the
       xml  format  is  used  the  type  of rule is indicated by adding a rule
       attribute with a value of "allow" or "deny" to the xml tag.  In  either
       format,  if  the  type  is not indicated, the rule is interpreted as an
       allow rule. Currently the authorisation groups can be  referred  to  in
       gridftpd and httpsd blocks.

       subject
              Match a specific certificate subject.

              Examples (plain text):

              +subject="/O=Grid/O=Big VO/CN=Main Boss"
              -subject="/O=Grid/O=Tiny VO/CN=Small Boss"
              !subject="/O=Grid/O=Bad VO/CN=Evil Boss"

              Examples (xml):

              <subject rule="allow">/O=Grid/O=Big VO/CN=Main Boss</subject>
              <subject rule="reject">/O=Grid/O=Tiny VO/CN=Small Boss</subject>
              <subject        match="inverted">/O=Grid/O=Bad        VO/CN=Evil
              Boss</subject>

              These examples will allow the Big Boss, deny the Small Boss  and
              allow everyone except the Evil Boss (except the Small Boss which
              was denied by the previous rule).

       all    Matches any credential.

              Example (plain text): all="all"

              Example (xml): <all>all</all>

       file   This is convenient for directly adding  gridmap  like  lists  to
              authorisation groups.

              Example: file="/etc/grid-security/local-users"

       group  Match  users  belonging to a different group. The value for this
              attribute is the id of the referred group.

              Example: group="admins"

       plugin Run an external executable or a function  from  shared  library.
              The  rule  matches  if  the plugin returns 0. The value for this
              attribute is a space separated list of arguments in  the  format
              "[function@]path [arg1 [arg2 [...]]]". If the plugin is given as
              function@path then the function

              int function (char* arg1, char* arg2, ...)

              from the  shared  library  at  path  is  called.  Otherwise  the
              external  executable  at  the  specified path is called with the
              given arguments.

              In the arguments the following substitutions are supported:

              %D     the subject of the user's certificate

              %P     the path to the proxy file

              Optionally a timeout value (specified in seconds) can  be  given
              by adding a suboption.

              Example (plain text):

              plugin="timeout=10 /opt/external/bin/permis %P"

              Example (xml):

              <plugin timeout="10">/opt/external/bin/permis %P</plugin>

       remote Check the user's credentials against a remote service. Only URLs
              to groups stored at LDAP directories are supported.

              Example:

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

       vo     Match   users  belonging  to  a  VO  (virtual  organisation)  as
              configured in one of vo blocks. The value for this attribute  is
              the id of the referred VO.

              Example: vo="nordugrid"

       voms   Match   a   voms   (virtual   organisation  management  service)
              credential. The value for  this  attribute  should  be  a  space
              separated list of voms attributes to be matched in the order "vo
              group role capability". A `*' can be used as a wildcard for  any
              value.

              Example: voms="nordugrid guests * *"

VO OPTIONS

       A  vo  block is used to define VOs (virtual organisations) and generate
       mapfiles from user lists maintained by VO databases. A vo  block  is  a
       configuration  block  for  the  nordugridmap utility. The vo blocks can
       also be used and referenced in authorisation group blocks and  in  gacl
       expressions.  Each  vo  block should be given a unique id. If the plain
       text format is used, the vo group "atlas" is defined by:

       [vo]
       id="atlas"

       If the xml  format  is  used  the  same  block  is  defined  using  the
       attributed xml tag:

       <vo id="atlas">...</vo>

       file   The  file which contains the user lists associated with this VO.
              The file  is  automatically  generated  using  the  nordugridmap
              utility.

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

       source The  URL  of a VO database assigned to this VO. The nordugridmap
              utility will use this URL to automatically generate and keep up-
              to-date the user list (mapfile) specified by the file attribute.
              This is  a  multivalued  attribute  -  several  sources  can  be
              specified  for  a  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),
              ldap, voms(s) and file.

              Examples:

              source="http://www.nordugrid.org/developers.dn"
              source="vomss://voms.ndgf.org:8443/voms/nordugrid.org"
              source="ldap://grid-vo.nikhef.nl/ou=lcg1,o=atlas,dc=eu-
              datagrid,dc=org"
              source="vomss://lcg-voms.cern.ch:8443/voms/atlas?/atlas/Role=VO-
              Admin"
              source="file:///etc/grid-security/priviliged-users.txt"

       mapped_unixid
              The local unix ID which is used in the generated gridmap file by
              the  nordugridmap  utility. Don't specify it (or leave it empty)
              in case you only need a  generated  user  list  without  mapping
              information. A vo block can only have one unix ID, all the users
              from all the sources are mapped to the same ID.

              Example: mapped_unixid="gridtest"

       require_issuerdn
              If set to "yes" only those DNs obtained from the URLs which have
              the  corresponding  public CA packages installed will be mapped.
              Default is "no".

              Example: require_issuerdn="no"

       x509_cert_dir
              The directory containing the CA certificates.  This  information
              is needed by the require_issuerdn option.

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

       filter 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. A `*' 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.

              Examples:

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

GRID-MANAGER OPTIONS

       The grid-manager block configures the grid-manager process taking  care
       of   the  grid  tasks  on  the  frontend  (stagein/stageout,  LRMS  job
       submission, caching, etc...).

       controldir
              The directory of the grid-manager's internal job log files,  not
              needed on the nodes.

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

       sessiondir
              The  directory  which  holds the session directories 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.

              Example: sessiondir="/scratch/grid"

       runtimedir
              The  directory  which  holds  the  runtime  environment scripts,
              should  be  available  on  the  nodes  as  well.   The   runtime
              environments  are  automatically  detected and advertised in the
              information system.

              Example: runtimedir="/SOFTWARE/runtime"

       cachedir
              Specifies the directory where to store cached data. If the cache
              attribute  is  not  specified  or  the  specified  path is empty
              caching is disabled. An optional second argument  specifies  the
              path  at  which  the  cached data is accessible at the computing
              nodes (if different from the path at the frontend node). If  the
              second  argument  is  set to `.'  files are not soft-linked, but
              copied  to  the  session  directory.  Multiple  caches  can   be
              specified by specifying multiple cachedir options

              Examples:

              cachedir="/scratch/cache"
              cachedir="/shared/cache /frontend/cache"

       remotecachedir
              Specifies  caches  which are under the control of other GMs, but
              which this GM 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, the GM looks in remote caches. The second
              argument 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
              Value should be given as  "max  min".  Specifies  high  and  low
              watermark  for  space  used  by  cache.  Values are specified as
              percentages of the cache file system.

              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"

       cachelogfile
              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
              Specifies the level of logging by the cache-clean tool,  between
              0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).

              Example: cacheloglevel="2"

       cachecleantimeout
              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"

       user   Switch to a non-root user/group after startup. The format of the
              argument is user[:group].

              Examples:

              user="grid"
              user="griduser:gridgroup"

       debug  Set  the  debug level of the grid-manager daemon. Level 0 stands
              for no debug. Increasing number gives more information, up to  a
              maximum of 5.

              Example: debug="2"

       logfile
              Specify  the  log  file  location.  This  file is opened/created
              before the daemon switches to specified user. Hence  it  can  be
              owned   by   root.   Default  log  file  is  "/var/log/arc/grid-
              manager.log".

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

       logsize
              Specifies the (approximate) maximum size in  bytes  of  the  log
              file.  A  second argument indicates how many log files are kept.
              When the logfile exceeds the specified size  it  is  renamed  to
              logfile.0  and logfile.0 is renamed to logfile.1 and so on. When
              installing from packages, logrotate is used to manage log files,
              so only use this option if logrotate is disabled.

              Example: logsize="100000 2"

       pidfile
              Specifies  the  location  of  the file containing the process id
              (PID) of the  daemon  process.  This  is  useful  for  automatic
              start/stop scripts.

              Example: pidfile="/var/run/grid-manager.pid"

       gnu_time
              the GNU time command. Default is /usr/bin/time.

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

       shared_filesystem
              Specifies  whether  the  computing  nodes can access the session
              directory at the frontend node. Defaults to "yes".

              Example: shared_filesystem="yes"

       mail   Specifies the e-mail address from where the  notification  mails
              are sent.

              Example: mail="grid.support@somewhere.org"

       joblog Specifies  where  to  store  a specialised log about started and
              finished jobs.  If  the  given  path  is  empty  or  the  joblog
              attribute is not given the log is disabled.

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

       jobreport
              Tells  the  grid-manager to report all started and finished jobs
              to a logger service. Multiple jobreport commands are allowed. In
              that  case  the  job  information  will be sent to all specified
              services.

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

       maxjobs
              Specifies the maximum allowed number of jobs being processed  at
              different  stages:  1.  max  processed  jobs - maximum number of
              concurrent jobs processed. This does not  limit  the  amount  of
              jobs  which can be submitted to the cluster. 2. max running jobs
              - maximum number of jobs passed  to  Local  Resource  Management
              System.  3.  max jobs per dn - maximum number of concurrent jobs
              processed by A-REX per user DN. If this option is used the total
              maximum number of jobs processed is still max processed jobs. 4.
              max jobs total - total maximum number of  jobs  associated  with
              service.  It  is  advised  to use this limit only in exceptional
              case because it also accounts for nished jobs. Missing number or
              -1 means no limit.

              Example: maxjobs="10000 10 1000"

       maxload
              Specifies  the  maximum allowed number of jobs. The value should
              be three numbers separated by spaces. The  first  number  limits
              the  number  of  jobs  being  processed  on frontend (PREPARING,
              FINISHING states). The second number is the additional  reserved
              number  of  jobs  being  processed on frontend. The third number
              limits the number of files being transferred  simultaneously  by
              jobs  in  PREPARING  and  FINISHING states. Missing number or -1
              means no limit.

              Example: maxload="10 2 5"

       maxloadshare
              Specifies a sharing mechanism for data transfer. The values  are
              an  integer  followed by a space followed by a string. The first
              number is the maximum number  of  processes  that  can  run  per
              transfer  share and the string is the scheme used to assign jobs
              to transfer shares. Possible values of  this  string  are  "dn",
              "voms:vo", "voms:role", and "voms:group".

              Example: maxloadshare="4 voms:role"

       share_limit
              Specifies  a  transfer  share  that  has  a  number of processes
              different from the default value in maxloadshare.  name  is  the
              name  of the share and limit is the number of processes for this
              share. In the conguration should appear after maxloadshare.  Can
              be repeated several times for different shares.

              Example: share_limit="atlas:production 10"

       newdatastaging
              Turns  on  and off the new data staging framework which replaces
              the downloader and uploader for managing input and output files.
              It is off by default

              Example: newdatastaging="yes"

       delivery_service
              Specifies  a  remote delivery service to be used by the new data
              staging framework.

              Example:
              delivery_service="https://example.com:60002/datadeliveryservice

       local_delivery

              In  case  remote  delivery  services  are  configured  using the
              previous option, this option specifices whether or not  delivery
              should also be done locally on the A-REX host. Default is no.

              Example: local_delivery="yes"

       wakeupperiod
              Specifies  how  often  the  grid-manager  checks  for  new  jobs
              arrived, jobs finished in LRMS, etc.  The  value  should  be  an
              integer  representing  a  time  period  in seconds. Default is 3
              minutes. Usually this command is not needed.

              Example: wakeupperiod="180"

       securetransfer
              Specifies if the server allows users to specify  to  use  secure
              data transfer. Default is "no".

              Example: securetransfer="no"

       passivetransfer
              Specifies  whether  gridftp  transfers are passive. Setting this
              option to yes can solve transfer problems caused  by  firewalls.
              Default is "no".

              Example: passivetransfer="no"

       localtransfer
              If  set  to  "yes"  the  data  download to the session directory
              (stage in) will be part of the batch job (prior to the execution
              of the binary).  Default is "no".

              Example: localtransfer="no"

       speedcontrol
              Specifies  how  slow data transfers must be to trigger an error.
              The value should be four integers separated  by  spaces  in  the
              format  "min_speed  min_time  min_average_speed max_inactivity".
              The transfer is cancelled if the speed is below min_speed  bytes
              per  second for at least min_time seconds, or if average rate is
              below  min_average_speed  bytes  per  second,  or  no  data  was
              transferred  for  longer than max_inactivity seconds. A value of
              zero turns feature off. Default is "0 300 0 300".

              Example: speedcontrol="0 300 0 300"

       defaultttl
              The value should be given as "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  one
              week.  ttr  is how long information about a job will be kept. If
              not specified the ttr default is one month.

              Example: defaultttl="259200"

       authplugin
              Every time a job  goes  into  a  specific  state  the  specified
              executable  is  run  with the given arguments. In the plain text
              format the state is specified by adding its name before the path
              to  the  executable  and  any  specified  suboptions. In the xml
              format the state is given by a state xml attribute  to  the  xml
              tag. Possible suboptions are:

              timeout
                     wait  for  result  no longer than the specified number of
                     seconds.

              onsuccess, onfailure, ontimeout
                     what to do if the plugin exits with exit code zero,  with
                     non-zero   exit   code  or  if  the  timeout  is  reached
                     respectively. Possible values are:

                     pass - continue the execution of the job,

                     fail - cancel the job,

                     log - write  to  the  log  file  about  the  problem  and
                     continue the execution of the job.

              Example (plain text):

              authplugin="ACCEPTED    timeout=10   /opt/nordugrid/libexec/bank
              %C/job.%I.local %S"

              Example (xml):

              <authplugin                                     state="ACCEPTED"
              timeout="10">/opt/nordugrid/libexec/bank         %C/job.%I.local
              %S</authplugin>

              ARC is distributed  with  a  plugin  called  "inputcheck".  It's
              purpose  is  to check if input files requested in job's XRSL are
              accessible from this machine. It accepts two arguments: the name
              of the file containing the XRSL and name of the proxy file.

              Example (plain text):

              authplugin="ACCEPTED                                  timeout=60
              /opt/nordugrid/libexec/inputcheck          %C/job.%I.description
              %C/job.%I.proxy"

              Example (xml):

              <authplugin                                     state="ACCEPTED"
              timeout="60">/opt/nordugrid/libexec/inputcheck
              %C/job.%I.description %C/job.%I.proxy</authplugin>

       localcred
              Run  an external executable or a function form a shared library.
              Every time the job has to do something on behalf of a local user
              this  plugin  will  be  called.  It's purpose is to set non-unix
              permissions and credentials on the running task. If  the  plugin
              path  looks  like  name@path,  then the function "name" from the
              shared library at path will be called,  otherwise  the  external
              executable  at  path  will  be  called.  Don't use it unless you
              really know what you are doing. A timeout can be  defined  as  a
              suboption if required.

              Example                       (plain                      text):
              localcred="acquire@/opt/nordugrid/lib/afs.so %C/job.%I.proxy"

              Example   (xml):    <localcred>acquire@/opt/nordugrid/lib/afs.so
              %C/job.%I.proxy</localcred>

       norootpower
              If set to "yes", all job management processes will switch to the
              mapped user's identity while accessing  the  session  directory.
              This  is  useful  if  the  session directory is on NFS with root
              squashing turned on. Default is "no".

              Example: norootpower="yes"

       allowsubmit
              An  authorisation  group  allowed  to  submit  new  jobs   while
              "allownew=no" is active in the jobplugin configuration. Multiple
              commands are allowed.

              Example: allowsubmit="admins"

       helper Allows to run additional executables on behalf of  users.  Every
              time  this  executable  finishes  it will be started again. This
              helper plugin  mechanism  can  be  used  as  the  grid-manager's
              alternative  for  the  /etc/init.d or cron to (re)start external
              processes.  The  value  should  be  given  as  "user  executable
              arguments".  If  user  is  `*'  one  instance  is  run for every
              specified user. If user is `.' one instance is run unrelated  to
              any specified user.

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

       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
              url_head   local_path  -  specifies  that  URLs,  starting  from
              `url_head', should be accessed in a different way (most probably
              unix open). The `url_head' part of the URL will be replaced with
              `local_path' and the file from the 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/"

       linkurl
              url_head  local_path  [node_path] - identical to `copyurl', only
              the 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://example.org:2811/data/
              /scratch/data/"

       tmpdir Used by the grid-manager. Default is /tmp.

              Example: tmpdir="/tmp"

       maxrerun
              Specifies  how  many times a job can be rerun if it fails in the
              LRMS. Default value is 2. This  is  only  an  upper  limit,  the
              actual rerun value is set by the user in his xrsl.

              Example: maxrerun="2"

       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"

       pbs_bin_path
              The  path  to  qstat,  pbsnodes, qmgr and other PBS binaries. No
              need to set if PBS is not used.

              Example: pbs_bin_path="/usr/bin"

       pbs_log_path
              The path to the PBS server log files which are used by the grid-
              manager  to  determine  whether  a  PBS job is completed. If not
              specified the grid-manager will use qstat for that.

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

       sge_bin_path
              Path to Sun Grid Engine (SGE) binaries. MUST be set  if  SGE  is
              used.

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

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

              Example: sge_root="/opt/n1ge6"

       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_execd_port
              These options should be used in case SGE  command  line  clients
              requre SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables
              to be set. Usually they are not necessary.

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

       SLURM_bin_path
              The path to squeue, sinfo and other SLURM binaries. No  need  to
              set if SLURM is not used.

              Example: SLURM_bin_path="/usr/bin"

              SLURM_log_path  The path to the SLURM server log files which are
              used by the grid-manager to determine whether  a  SLURM  job  is
              completed.

              Example: SLURM_log_path="/var/spool/slurm"

              SLURM_wakeupperiod How long should infosys wait between querying
              SLURM for new data.

              Example: SLURM_wakeupperiod="15"

       condor_location
              Path to directory containing Condor's bin, sbin, etc. No need to
              set if Condor is not used.

              Example: condor_location="/opt/condor"

       condor_config
              Path to Condor's configuration file. No need to set if Condor is
              not used.

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

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

              Example:

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

       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 LSF profile: profile.lsf. No need to set if LSF is
              not used.

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

       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
              Use Consumable Resources for a LoadLeveler.

              Example: ll_consumable_resources="yes"

       hostname
              The FQDN of the frontend node.

              Example: hostname="myhost.org"

       lrms   Sets  the  type  of  Local  Resource Management System (queueing
              system). Choose one  from  the  following  options:  fork,  sge,
              condor,  pbs,  lsf, ll, slurm. PBS has many flavours, we support
              OpenPBS, PBSPro, ScalablePBS and Torque (the official  name  for
              ScalablePBS).  No  need  to  specify  the flavour or the version
              number of the PBS, simply  write  "pbs".  The  optional  "queue"
              parameter  specifies  the  default  grid  queue of the LRMS. The
              grid-manager submits jobs to this queue if there is no queue set
              in the job's XRSL.

              Example: lrms="pbs grid"

       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.

              Example:

              globus_tcp_port_range="9000,12000"
              globus_udp_port_range="9000,12000"

       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.

              Example:

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

       x509_cert_dir
              Location of trusted CA certificates. This variable is similar to
              the GSI environment variable X509_CERT_DIR.

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

       gridmap
              The gridmap file location. This variable is similar to  the  GSI
              environment   variable   GRIDMAP.   The  default  is  /etc/grid-
              security/grid-mapfile.

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

       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 a default.
              strict - fail if any parsing error was discovered.
              noerrors - fail if any parsing or validation error happened.

              Example: voms_processing="strict"

       http_proxy
              Use  an  http  proxy  server  for  downloading  files  from http
              servers. The format of the argument is host[:port].

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

       In the  command  arguments  (paths,  executables,  ...)  the  following
       substitutions can be used:

       %R     session directory

       %C     control directory

       %U     username

       %u     userid - numerical

       %g     groupid - numerical

       %H     home directory - home specified in /etc/passwd

       %Q     default queue

       %L     default lrms

       %W     installation path - ${ARC_LOCATION}

       %G     globus path - ${GLOBUS_LOCATION}

       %c     list of all control directories

       %I     job ID (for plugins only, substituted at runtime)

       %S     job state (for authplugin plugins only, substituted at runtime)

       %O     reason  (for  localcred  plugins  only, substituted at runtime).
              Possible reasons are:

              new - new job, new credentials

              renew - old job, new credentials

              write -  write/delete  file,  create/delete  directory  (through
              gridftp)

              read - read file, directory, etc. (through gridftp)

              extern - call external program (grid-manager)

       See some of the examples above for examples of use.

GRIDFTPD OPTIONS

       The gridftpd block configures the gridftpd server.

       user   Switch to a non-root user/group after startup. The format of the
              argument  is  user[:group].  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  Set the debug level of the gridftpd daemon. Level 0  stands  for
              no  debug.  Increasing  number  gives  more  information up to a
              maximum of 5.

              Example: debug="2"

       logfile
              Set log file location.

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

       logsize
              Specifies the (approximate) maximum size in  bytes  of  the  log
              file.  A  second argument indicates how many log files are kept.
              When the logfile exceeds the specified size  it  is  renamed  to
              logfile.0  and logfile.0 is renamed to logfile.1 and so on. When
              installing from packages, logrotate is used to manage log files,
              so only use this option if logrotate is disabled.

              Example: logsize="100000 2"

       pidfile
              Specifies  the  location  of  the file containing the process id
              (PID) of the  daemon  process.  This  is  useful  for  automatic
              start/stop scripts.

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

       port   Port to listen on (default 2811).

              Example: port="2811"

       pluginpath
              Directory  where  the plugin libraries are installed, default is
              ${ARC_LOCATION}/lib/arc.

              Example: pluginpath="/opt/nordugrid/lib"

       encryption
              Should data encryption be allowed, default is  "no".  Encryption
              is very heavy.

              Example: encryption="no"

       allowunknown
              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
              Maximum  number  of  connections  accepted by a gridftpd server.
              Default is 100.

              Example: maxconnections="200"

       globus_tcp_port_range, globus_udp_port_range
              Firewall configuration.

              Examples:

              globus_tcp_port_range="9000,12000"
              globus_udp_port_range="9000,12000"

       firewall
              IP address or hostname  to  use  in  response  to  PASV  command
              instead  of  IP address of a network interface of computer. This
              command may be used if server is situated behind NAT.

              Examples: firewall=gateway.campus.org

       x509_user_cert, x509_user_key
              Server credentials location.

              Examples:

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

       x509_cert_dir
              Location of trusted CA certificates.

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

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

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

       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 a default.
              strict - fail if any parsing error was discovered.
              noerrors - fail if any parsing or validation error happened.

              Example: voms_processing="strict"

GRIDFTPD FILEPLUGIN OPTIONS

       Configuration for a classic gridftp file server using  the  fileplugin.
       Each  exported mount point is configured in its own configuration block
       and is given its own  id.  If  the  plain  text  format  is  used,  the
       configuration block identified as "files" is defined by:

       [gridftpd]
       id="files"

       If  the  xml  format  is  used  the  same  block  is  defined using the
       attributed xml tag:

       <gridftpd id="files">...</gridftpd>

       The access control is  defined  by  specifying  the  dir  configuration
       option.

       plugin Specifies  the  name of the shared library to be loaded relative
              to the path given  in  the  pluginpath  option.  For  a  classic
              gridftp   file   server   using  the  fileplugin  it  should  be
              fileplugin.so.

              Example: plugin="fileplugin.so"

       groupcfg
              Specifies the authorisation groups  for  which  this  plugin  is
              activated.   In  case  groupcfg  is  not specified the plugin is
              loaded for every mapped grid user.

              Example: groupcfg="atlas_users bio_students"

       path   The name of the virtual directory served by the gridftp  server.
              If  set  to "/topdir" the exported storage area is accessible as
              gsiftp://<hostname>/topdir. The virtual path can be anything you
              like, even "/" is a valid choice.

              Example: path="/topdir"

       mount  The physical directory on the local file system corresponding to
              the virtual one.

              Example: mount="/scratch/grid"

       dir    This is the access control parameter, you can have  several  dir
              lines controlling different directories within then same block.

              The  value  for  this  option  is a path followed by one or more
              options. The 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.  (The  second number is reserved for the
                     future usage).

              mkdir owner:group permissions_or:permissions_and
                     allow creating new directories.

              Examples:

              dir="/ nouser read cd dirlist delete create  *:*  664:664  mkdir
              *:* 775:775"
              dir="/scratch  nouser read mkdir *:* 700:700 cd dirlist"
              dir="/example_data nouser read mkdir *:* 700:700 cd dirlist"

GRIDFTPD GACLPLUGIN OPTIONS

       Configuration  for  a  GACL  enabled  gridftp  file  server  using  the
       gaclplugin.  Each  exported  mount  point  is  configured  in  its  own
       configuration  block and is given its own identifier. If the plain text
       format is used, the configuration block identified  as  "gaclfiles"  is
       defined by:

       [gridftpd]
       id="gaclfiles"

       If  the  xml  format  is  used  the  same  block  is  defined using the
       attributed xml tag:

       <gridftpd id="gaclfiles">...</gridftpd>

       The access control is set through GACL files  placed  in  the  physical
       directories assigned to every file/directory. Newly created directories
       and uploaded files automatically obtain their default GACL files:  only
       the  creator  of  the  file/directory  has  read, write, list and admin
       capabilities. This default is not configurable  yet.  Additionally  the
       "mount" directory must contain a .gacl file with initial GACL otherwise
       the rule will be "deny everything for everyone".

       plugin Specifies the name of the shared library to be  loaded  relative
              to  the  path given in the pluginpath option. For a GACL enabled
              gridftp  file  server  using  the  gaclplugin   it   should   be
              gaclplugin.so.

              Example: plugin="gaclplugin.so"

       groupcfg
              Specifies  the  authorisation  groups  for  which this plugin is
              activated.  In case groupcfg is  not  specified  the  plugin  is
              loaded for every mapped grid user.

              Example: groupcfg="atlas_users bio_students"

       path   The  name of the virtual directory served by the gridftp server.
              If set to "/gacltop" the exported storage area is accessible  as
              gsiftp://<hostname>/gacltop.  The  virtual  path can be anything
              you like, even "/" is a valid choice.

              Example: path="/gacltop"

       mount  The physical directory on the local file system corresponding to
              the  virtual  one.  The directory must contain a .gacl file with
              the default GACL settings.

              Example: mount="/scratch/GACL"

       gacl   Specifies  the  default  GACL  rule.  MUST  be  set.  The   GACL
              expression must be given in one line and in GACL xml format.

              Example: gacl="<gacl>very long single line</gacl>"

              The  default  gacl can contain variables which are replaced with
              values taken from client's credentials. The following  variables
              are supported:

              $subject
                     subject of user's certificate (DN),

              $voms  subject of VOMS server (DN),

              $vo    name of VO (from VOMS certificate),

              $role  role (from VOMS certificate),

              $capability
                     capabilities (from VOMS certificate),

              $group name of group (from VOMS certificate).

GRIDFTPD JOBPLUGIN OPTIONS

       Configuration  for a job submission interface using the gridftp servers
       jobplugin. The identifier of the configuration block is  arbitrary  but
       must  be  unique.  If  the plain text format is used, the configuration
       block identified as "jobs" is defined by:

       [gridftpd]
       id="jobs"

       If the xml  format  is  used  the  same  block  is  defined  using  the
       attributed xml tag:

       <gridftpd id="jobs">...</gridftpd>

       plugin Specifies  the  name of the shared library to be loaded relative
              to the path given in the pluginpath option. For a job submission
              service it should be jobplugin.so.

              Example: plugin="jobplugin.so"

       groupcfg
              Specifies  the  authorisation  groups  for  which this plugin is
              activated.  In case groupcfg is  not  specified  the  plugin  is
              loaded for every mapped grid user.

              Example: groupcfg="atlas_users bio_students"

       path   The  name  of the virtual directory used during jobs submission.
              This will be part of the jobid of the  jobs  submitted  to  this
              service.

              Example: path="/jobs"

       allownew
              Specifies  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
              Specifies  control  and session directories to which jobs can be
              submitted but which are under the control  of  another  GM.  The
              corresponding  controldir  and  sessiondir  parameters  must  be
              defined  in  another  grid-manager's  configuration.    Multiple
              remotegmdirs can be specified.

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

       maxjobdesc
              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"

INFORMATION SYSTEM OPTIONS

       The infosys block configures the hosting environment of the Information
       services (Local Info Tree, Index Service, Registrations).

       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"

       overwrite_config
              Determines  if  the  grid-infosys startup script 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"

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

              Example: oldconfsuffix=".oldconfig"

       hostname
              The hostname of the machine running the slapd service.

              Example: hostname="my.testbox"

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

              Example: port="2135"

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

              Example: debug="1"

       slapd_loglevel
              Sets the native slapd log level (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
              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 config 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
              The native slapd threads parameter, default is 32. If you run an
              Index service too you should modify this value.

              Example: threads="128"

       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
              The  native  slapd  idletimeout  parameter.  Maximum  number  of
              seconds  the slapd server will wait before forcibly closing idle
              client connections. It's value must be larger than the value  of
              "timelimit"  option.  If  not set, it defaults to timelimit + 1.
              Example: idletimeout="1800"

       registrationlog
              Specifies the log file for the registration processes  initiated
              by your machine. Default is "/var/log/arc/inforegistration.log".

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

       providerlog
              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
              Log  level  for  the information provider scripts (0, 1, 2). The
              default is 1 (critical errors are logged).

              Example: provider_loglevel="2"

       x509_cert_dir
              Location of trusted CA certificates.

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

       x509_user_cert, x509_user_key
              Server credentials location.

              Examples:

              x509_user_cert="/etc/grid-security/ldapcert.pem"
              x509_user_key="/etc/grid-security/ldapkey.pem"

       gridmap
              The gridmap file location.

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

       limit_core, limit_nofile
              Shell limits for the slapd  process  set  via  `ulimit  -c'  and
              `ulimit -n'.

              Examples:

              limit_core="0"
              limit_nofile=""

       user   The  unix  user running the information system processes such as
              the slapd, the registrations and information  provider  scripts.
              By default the user executing the startup script is set. In case
              of non-root value you  must  make  sure  that  the  grid-manager
              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  grid-manager  directories
              (controldir, sessiondir, runtimedir, cachedir) are specified  in
              the grid-manager block

              Example: user="root"

       giis_location
              If  giis_location  is  not  set, NORDUGRID_LOCATION will be used
              instead.

              Example: giis_location="/opt/nordugrid"

       works together with both BDII4 and BDII5.  If you use the
       nordugrid-packaged BDII installation,  these  variables  have  sensible
       defaults   and   can   be  omitted.  The  only  variables  that  system
       administrators  may  want  to  change  when  using  nordugrid-bdii  are
       infosys_nordugrid and infosys_glue12.  These two variables specify what
       format the output should be in,  default  is  infosys_nordugrid=enable,
       infosys_glue12=disable.  If infosys_glue12 is enabled, then you need to
       set    resource_location,    resource_latitude,     resource_longitude,
       cpuscalingreferencesi00,   processorotherdescription,  gluesiteweb  and
       gluesiteuniqueid under the [infosys/glue12] block. These  variables  do
       not    have    default    values.    You   may   also   want   to   set
       provide_glue_site_info to false in case you  want  to  set  up  a  more
       complicated  setup  with several publishers of data to a GlueSite.  The
       rest of  the  variables  defaults  are  showcased  here.  infosys_debug
       disables/enables   an   ldap-database   at  the  ldap  tree  entrypoint
       o=infosys. Note, the gLite supplied BDII installs  into  /opt/bdii.  If
       you  for  some  reason do not want to use the bdb ldap backend, you can
       set this with bdii_database.

       Examples:

       General BDII options.

       bdii_location="/usr"
       infosys_nordugrid="enable"
       infosys_glue12="disable"
       infosys_debug="disable"
       bdii_tmp_dir="/var/tmp/bdii"
       bdii_var_dir="/var/run/bdii"
       bdii_log_dir="/var/log/arc/bdii"
       bdii_conf="/var/run/nordugrid/bdii.conf"
       bdii_database="bdb"
       bdii_breathe_time="30"

       Glue 1.2 specific attributes

       resource_location="Kastrup, Denmark"
       resource_latitude="55.75000"
       resource_longitude="12.41670"
       cpuscalingreferencesi00="2400"
       processorotherdescription="Cores=3,Benchmark=9.8-HEP-SPEC06"
       gluesiteweb="http://www.ndgf.org"
       gluesiteuniqueid="NDGF-T1"
       provide_glue_site_info="true"

       BDII4 specific options.

       bdii_cmd="/etc/init.d/bdii4"
       bdii_update_cmd="/usr/sbin/bdii4-update"
       bdii_search_timeout="30"
       bdii_auto_update="no"
       bdii_auto_modify="no"
       bdii_modify_dn="no"
       bdii_is_cache="yes"
       bdii_update_url="http://"
       bdii_update_ldif="http://"
       bdii_update_conf="/var/run/nordugrid/bdii-update.conf"

       BDII5 specific options.

       bdii_read_timeout="300"
       bdii_db_config="/etc/bdii/DB_CONFIG"
       fix_glue="no"
       bdii_archive_size="0"
       bdii_update_pid_file="/var/run/arc/bdii-update.pid"
       slapd_pid_file="$bdii_var_dir/db/slapd.pid"

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

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

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

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

GRID INFORMATION INDEX SERVICE (GIIS) OPTIONS

       The Index Service block configures and  enables  an  Information  Index
       Service.  A  separate  configuration  block is required for every Index
       Service you may run on a given machine. Each index  service  should  be
       given  its  own  id.  This id is used as the index name in the "Mds-Vo-
       name=indexname, O=Grid" LDAP suffix characterising the  Index  Service.
       If  the  plain  text  format  is  used, the index service identified as
       "indexname" is defined by:

       [infosys/site]
       id="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.

       Examples: The unique id used to identify this site, eg "NDGF-T1"
       unique_id=""
       The    url    is   on   the   format:   ldap://host.domain:2170/mds-vo-
       name=something,o=grid and should point to the resource-bdii.
       url=""

       [infosys/index]
       id="indexname"

       If the xml  format  is  used  the  same  block  is  defined  using  the
       attributed xml tag inside the infosys block:

       <infosys>
        <index id="indexname">...</index>
       </infosys>

       allowreg
              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
              registrant with  the  allowreg  attribute.  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.

              Examples:

              All  the  Swedish  machines  can  register  regardless  they are
              resources or indexes:

              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"

GRID INFORMATION INDEX SERVICE REGISTRATION OPTIONS

       Options  for  registering  a grid information index service (GIIS) to a
       higher level in the Information System. Each GIIS can be registered  to
       more than one information index server. Each registration is configured
       in its own configuration block.

       If the plain text format is used, the registration of the index service
       identified as "indexname" is defined by:

       [infosys/index/registration]
       id="indexname"

       If  the  xml  format  is  used  the  same  block  is  defined  using  a
       registration tag inside the  attributed  xml  tag  inside  the  infosys
       block:

       <infosys>
        <index id="indexname">
         <registration>...</registration>
        </index>
       </infosys>

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

              Example: targethostname="index.myinstitute.org"

       targetport
              The port on which the  target  Index  Service  is  running.  The
              default is the 2135 Grid Resource Information Service port.

              Example: targetport="2135"

       targetsuffix
              The LDAP suffix of the target Index Service

              Example: targetsuffix="Mds-Vo-name=BigIndex, O=Grid"

       regperiod
              The  registration  period  in seconds, the registration messages
              are continuously sent according to the regperiod. Default is 120
              s.

              Example: regperiod="300"

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

              Example: registrantsuffix="Mds-Vo-name=indexname, O=Grid"

CLUSTER OPTIONS

       The  cluster  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
              The FQDN of the frontend node.

              Example: hostname="myhost.org"

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

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

       alias  An arbitrary alias name of the cluster, optional.

              Example: alias="Big Blue Cluster in Nowhere"

       comment
              A free text field for additional comments about the cluster.

              Example:

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

       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
              It can be used to indicate the owner  of  a  resource,  multiple
              entries can be used.

              Example: cluster_owner="World Grid Project"

       authorizedvo
              This  attribute is used to advertise which VOs are authorized on
              the cluster. Multiple entries are allowed.

              Example: authorizedvo="developer.nordugrid.org"

       clustersupport
              This is the support email  address  of  the  resource,  multiple
              entries can be used.

              Example: clustersupport="grid.support@myproject.org"

       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
              Determines whether the cluster consists of identical nodes  with
              respect  to  CPU  type,  memory, installed software (opsys). The
              frontend does not have 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.

              Example: homogeneity="True"

       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  This  multivalued  attribute  is meant to describe the operating
              system of the computing nodes. The opsys attribute 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.

              Examples:

              opsys="Redhat-7.2"
              opsys="Linux-2.4.21-mypatch"
              opsys="glibc-2.3.1"

       nodecpu
              This is the CPU type 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 CPU
              type, 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
              CPU type as the homogeneous nodes.

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

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

              Examples:

              benchmark="SPECINT2000 222" benchmark="SPECFP2000 333"

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

              Example: middleware="my grid software"

       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.

              Examples:

              nodeaccess="inbound" nodeaccess="outbound"

       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,   in    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 and the 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
              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/data2/"

       gm_mount_point
              This  should  be  the  same  as  the  "path" from the gridftpd's
              jobplugin configuration block. The default is "/jobs".

              Example: gm_mount_point="/jobs"

       gm_port
              This should be the  same  as  the  "port"  from  the  gridftpd's
              jobplugin block. The default is "2811".

              Example: gm_port="2811"

       cachetime, timelimit, sizelimit
              LDAP  parameters  of  the  cluster  information provider. Do not
              change the defaults unless you know what you are doing.

              Examples:

              cachetime="30"
              timelimit="30"
              sizelimit="10"

CLUSTER REGISTRATION OPTIONS

       Options for registering the cluster  in  the  Information  System.  The
       cluster  can  be  registered to more than one information index server.
       Each registration is configured in its own configuration block.

       If the plain text format is used, the  cluster  registration  block  is
       defined by:

       [cluster/registration]

       If  the  xml  format  is  used  the  same  block  is  defined  using  a
       registration tag inside the cluster block:

       <cluster>
        <registration>...</registration>
       </cluster>

       targethostname
              See description earlier.

              Example: targethostname="index.myinstitute.org"

       targetport
              See description earlier.

              Example: targetport="2135"

       targetsuffix
              See description earlier.

              Example: targetsuffix="Mds-Vo-name=BigIndex, O=Grid"

       regperiod
              See description earlier.

              Example: regperiod="300"

       registranthostname
              See description earlier.

              Example: registranthostname="myhost.org"

       registrantport
              See description earlier.

              Example: registrantport="2135"

       registrantsuffix
              The LDAP  suffix  of  the  registrant  cluster  resource  It  is
              automatically  determined  from  the infosys block. 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 OPTIONS

       Each  grid  enabled queue should have a separate queue block. The queue
       name should be used as the id of the configuration group. A  queue  can
       represent  a  PBS queue, an SGE pool, a Condor pool or a machine with a
       `fork' LRMS. Queues don't need to be  registered  (there  is  no  queue
       registration  block), once you configured your cluster to register to a
       Index  Service  the  queue  entries  (configured   with   this   block)
       automatically  will  be  there.  Please  consult the Infosys manual for
       detailed information on queue attributes. The special id `fork'  should
       be used for identifying the queue block of the fork LRMS.

       fork_job_limit
              The allowed number of concurrent jobs in a fork system, relevant
              only  for  a  fork  queue.  Default  is  1.  The  special  value
              `cpunumber' can be used which will set the limit of running jobs
              to the number of CPUs available in the machine.  This  parameter
              is used in the calculation of free CPUs in a fork system.

              Example: fork_job_limit="cpunumber"

       homogeneity
              Determines  whether  the  queue consists of identical nodes with
              respect to CPU type, 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
              This  optional  parameter  tells  the  scheduling  policy of the
              queue. PBS by default offers the FIFO scheduler, many sites  run
              the  MAUI  scheduler. At the moment FIFO & MAUI is supported. If
              you have a MAUI scheduler you should specify  the  "MAUI"  value
              since it modifies the way the queue resources are calculated. By
              default the "FIFO" scheduler is assumed.

              Example: scheduling_policy="FIFO"

       comment
              A free text field for additional comments about the queue.

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

       maui_bin_path
              Set this parameter for the path of the maui commands like showbf
              in case you specified the "MAUI" scheduling policy above.

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

       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
              assigning   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's totalcpus and user freecpus are determined for this
              queue. You shouldn't use this option unless you make  sure  that
              your PBS configuration makes use of the above configuration.

              Example: queue_node_string="gridlong_nodes"

       sge_jobopts
              Specify  additional  SGE options to be used when submitting jobs
              to SGE.

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

       condor_requirements
              Only needed if using Condor. If using mutpiple queues, 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.

              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
              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, nodememory, architecture, opsys, benchmark
              Queue  level  configuration parameters 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. 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.

              Examples:

              nodecpu="Pentium III (Coppermine) @ 1001 MHz"
              nodememory="512"
              architecture="adotf"
              opsys="Mandrake 8.0"
              opsys="Linux-2.4.19"
              benchmark="SPECINT2000 222"
              benchmark="SPECFP2000 333"

       gridmap
              Can  be  used to specify an alternative file holding the list of
              grid SNs for this queue. The information system parses the  list
              of  users from this file and advertises them as authorized users
              for this queue.  Beware that this list is not actually  used  by
              gridftpd for authorization.

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

       cachetime, timelimit, sizelimit
              LDAP parameters of the queue, job and user information provider.
              Do not change the defaults unless you know what you are doing.

              Examples:

              cachetime="30" timelimit="30" sizelimit="5000"

SEE ALSO

       http://www.nordugrid.org/meetings/sophia-conf.jpg