1arc.conf(5) NorduGrid ARC arc.conf(5)
2
6 arc.conf, .arc/client.conf - ARC configuration
7
10 Configuration files for NorduGrid ARC.
11
14 /etc/arc.conf
15 ${ARC_LOCATION}/etc/arc.conf
17 ${HOME}/.arc/client.conf
19
22 The ARC configuration file consists of several configuration blocks.
23 Each configuration block is identified by a keyword and contains the
24 configuration options for a specific part of the ARC middleware.
25 The ARC configuration file can be written in one of two different for‐
27 mats: plain text or xml. In the plain text format each configuration
28 block starts with its identifying keyword inside square brackets.
29 Thereafter follows one or more attribute value pairs written one on
30 each line in the following format (note that the attribute names are
31 CASE-SENSITIVE):
32 [keyword1]
34 attribute1="value1"
35 attribute2="value2"
36 [keyword2]
38 attribute="value"
39 In the xml format the arc configuration file consist of a single "arc"
41 xml element. Inside this element each configuration block appears as a
42 separate xml element named after the block's identifying keyword. This
43 block in turn contains attribute value pairs in the following format:
44 <arc>
46 <keyword1>
47 <attribute1>value1</attribute1>
48 <attribute2>value2</attribute2>
49 </keyword1>
50 <keyword2>
51 <attribute>value</attribute>
52 </keyword2>
53 </arc>
54 However, if a configuration block has an id attribute, it should be
56 given as an xml attribute to the keyword instead:
57 <keyword id="value">
59 Some options can also have suboptions. In the plain text format these
61 are given as a comma separated list without spaces of attribute value
62 pairs before the option value:
63 attribute="subattr1=subval1,subattr2=subval2 value"
65 In the xml format the suboptions are given as attributes to the xml
67 tag:
68 <attribute subattr1="subval1" subattr2="subval2">value</attribute>
70 The following keywords are used in the block names: common, client,
72 group, vo, grid-manager, gridftpd, httpsd, infosys, registration, clus‐
73 ter, queue, se, rc.
74 If the ARC_LOCATION environment variable is set the ARC configuration
76 file located at ${ARC_LOCATION}/etc/arc.conf is read first. If this
77 file is not present or the relevant configuration information is not
78 found in this file, the file at /etc/arc.conf is read.
79 For ARC client applications each user can specify a personal configura‐
81 tion file at ${HOME}/.arc/client.conf. Only the common and client
82 blocks are used in this file. If this file is not present or does not
83 contain the relevant configuration information the global configuration
84 files are read instead.
85
88 Options listed in the common configuration block affect all parts of
89 the ARC middleware, unless overridden in a configuration block for a
90 particular service or a command line option.
91
94 giis Configures which GIISes to use to discover computing and storage
95 resources. The default is to use the four top level GIISes:
96 ldap://index1.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
98 ldap://index2.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
99 ldap://index3.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
100 ldap://index4.nordugrid.org:2135/O=Grid/Mds-Vo-name=NorduGrid
101 This option can be repeated several times.
103 Example (plain text):
105 giis="ldap://atlasgiis.nbi.dk:2135/O=Grid/Mds-Vo-name=Atlas"
107 Example (xml):
109 <giis>ldap://odin.switch.ch:2135/O=Grid/Mds-Vo-name=Switzer‐
111 land</giis>
112 debug
115 Default debug level to use for the arc clients. Corresponds to
117 the -d command line switch of the clients. Default value is 0.
118 Example (plain text): debug="2"
120 Example (xml): <debug>2</debug>
122 timeout
125 Timeout to use for interaction with LDAP servers, gridftp
126 servers, etc. If a server, during e.g. job submission, does not
127 answer in the specified number of seconds, the connection is
128 timed out and closed. Default value is 20 seconds.
129 Example (plain text): timeout="20"
131 Example (xml): <timeout>10</timeout>
133 downloaddir
136 Default download directory to download files to when retrieving
137 output files from jobs using arccli get. Default is the current
138 working directory.
139 Example (plain text): downloaddir="/home/johndoe/arc-downloads"
141 Example (xml): <downloaddir>/tmp/johndoe</downloaddir>
143 alias Alias substitutions to perform in connection with the -c command
146 line switch of the arc clients. Alias definitions are recursive.
147 Any alias defined in a block that is read before a given block
148 can be used in alias definitions in that block. An alias defined
149 in a block can also be used in alias definitions later in the
150 same block. This option can be repeated several times.
151 Example (plain text):
153 alias="host1=somehost.nbi.dk"
155 alias="host2=otherhost.uu.se"
156 alias="myhosts=host1 host2"
157 Example (xml):
159 <alias>host1=somehost.nbi.dk</alias>
161 <alias>host2=otherhost.uu.se</alias>
162 <alias>myhosts=host1 host2</alias>
163 With the example above "arcsub -c myhosts" will resolve to "arc‐
165 sub -c somehost.nbi.dk -c otherhost.uu.se"
166 broker Configures which broker to use during job submission. The
169 default one is the FastestCpus broker that chooses, among the
170 possible targets, the target with the fastest CPUs. Another pos‐
171 sibility is the RandomSort broker that chooses the target ran‐
172 domly among the targets surviving the job description matchmak‐
173 ing.
174 Example (plain text): broker="RandomSort"
176 Example (xml): <broker>RandomSort</broker>
178
181 The group configuration blocks define rules used to determine to which
182 authorisation groups a user belongs. Each authorisation group is
183 defined in its own group configuration block and should be given a
184 unique id. If the plain text format is used, the authorisation group
185 "users" is defined by:
186 [group]
188 id="users"
189 If the xml format is used the same block is defined using the attrib‐
191 uted xml tag:
192 <group id="users">...</group>
194 The attribute value pairs in a group configuration block represent
196 rules for allowing or denying users as members of the group. These
197 rules are processed in order of appearance. The first rule that matches
198 the information presented by a user stops the processing of the remain‐
199 ing rules in the block. The result of a rule can be inverted, so that a
200 matching rule counts as non-matching and vice versa. In the plain text
201 format this is done by prepending the rule with an exclamation mark. In
202 the xml format it is done by adding a match attribute with the value
203 "inverted" to the rule's xml tag.
204 A matching rule can either allow or deny a user. If the plain text for‐
206 mat is used an allow rule is defined by prepending a the rule with plus
207 sign and a deny rule by prepending it with a minus sign. If the xml
208 format is used the type of rule is indicated by adding a rule attribute
209 with a value of "allow" or "deny" to the xml tag. In either format, if
210 the type is not indicated, the rule is interpreted as an allow rule.
211 Currently the authorisation groups can be referred to in gridftpd and
212 httpsd blocks.
213 subject
216 Match a specific certificate subject.
217 Examples (plain text):
219 +subject="/O=Grid/O=Big VO/CN=Main Boss"
221 -subject="/O=Grid/O=Tiny VO/CN=Small Boss"
222 !subject="/O=Grid/O=Bad VO/CN=Evil Boss"
223 Examples (xml):
225 <subject rule="allow">/O=Grid/O=Big VO/CN=Main Boss</subject>
227 <subject rule="reject">/O=Grid/O=Tiny VO/CN=Small Boss</subject>
228 <subject match="inverted">/O=Grid/O=Bad VO/CN=Evil Boss</sub‐
229 ject>
230 These examples will allow the Big Boss, deny the Small Boss and
232 allow everyone except the Evil Boss (except the Small Boss which
233 was denied by the previous rule).
234 all Matches any credential.
237 Example (plain text): all="all"
239 Example (xml): <all>all</all>
241 file This is convenient for directly adding gridmap like lists to
244 authorisation groups.
245 Example: file="/etc/grid-security/local-users"
247 group Match users belonging to a different group. The value for this
250 attribute is the id of the referred group.
251 Example: group="admins"
253 plugin Run an external executable or a function from shared library.
256 The rule matches if the plugin returns 0. The value for this
257 attribute is a space separated list of arguments in the format
258 "[function@]path [arg1 [arg2 [...]]]". If the plugin is given as
259 function@path then the function
260 int function (char* arg1, char* arg2, ...)
262 from the shared library at path is called. Otherwise the exter‐
264 nal executable at the specified path is called with the given
265 arguments.
266 In the arguments the following substitutions are supported:
268 %D the subject of the user's certificate
271 %P the path to the proxy file
274 Optionally a timeout value (specified in seconds) can be given
277 by adding a suboption.
278 Example (plain text):
280 plugin="timeout=10 /opt/external/bin/permis %P"
282 Example (xml):
284 <plugin timeout="10">/opt/external/bin/permis %P</plugin>
286 remote Check the user's credentials against a remote service. Only URLs
289 to groups stored at LDAP directories are supported.
290 Example:
292 remote="ldap://grid-vo.nordugrid.org/ou=people,dc=nor‐
294 dugrid,dc=org"
295 vo Match users belonging to a VO (virtual organisation) as config‐
298 ured in one of vo blocks. The value for this attribute is the id
299 of the referred VO.
300 Example: vo="nordugrid"
302 voms Match a voms (virtual organisation management service) creden‐
305 tial. The value for this attribute should be a space separated
306 list of voms attributes to be matched in the order "vo group
307 role capability". A `*' can be used as a wildcard for any value.
308 Example: voms="nordugrid guests * *"
310
313 A vo block is used to define VOs (virtual organisations) and generate
314 mapfiles from user lists maintained by VO databases. A vo block is a
315 configuration block for the nordugridmap utility. The vo blocks can
316 also be used and referenced in authorisation group blocks and in gacl
317 expressions. Each vo block should be given a unique id. If the plain
318 text format is used, the vo group "atlas" is defined by:
319 [vo]
321 id="atlas"
322 If the xml format is used the same block is defined using the attrib‐
324 uted xml tag:
325 <vo id="atlas">...</vo>
327 file The file which contains the user lists associated with this VO.
330 The file is automatically generated using the nordugridmap util‐
331 ity.
332 Example: file="/etc/grid-security/VOs/atlas-users"
334 source The URL of a VO database assigned to this VO. The nordugridmap
337 utility will use this URL to automatically generate and keep up-
338 to-date the user list (mapfile) specified by the file attribute.
339 This is a multivalued attribute - several sources can be speci‐
340 fied for a vo block and all the users from those sources will be
341 merged into the same file. The source URLs are processed in the
342 given order. Currently supported URL types are: http(s), ldap,
343 voms(s) and file.
344 Examples:
346 source="http://www.nordugrid.org/developers.dn"
348 source="vomss://voms.ndgf.org:8443/voms/nordugrid.org"
349 source="ldap://grid-vo.nikhef.nl/ou=lcg1,o=atlas,dc=eu-data‐
350 grid,dc=org"
351 source="vomss://lcg-voms.cern.ch:8443/voms/atlas?/atlas/Role=VO-
352 Admin"
353 source="file:///etc/grid-security/priviliged-users.txt"
354 mapped_unixid
357 The local unix ID which is used in the generated gridmap file by
358 the nordugridmap utility. Don't specify it (or leave it empty)
359 in case you only need a generated user list without mapping
360 information. A vo block can only have one unix ID, all the users
361 from all the sources are mapped to the same ID.
362 Example: mapped_unixid="gridtest"
364 require_issuerdn
367 If set to "yes" only those DNs obtained from the URLs which have
368 the corresponding public CA packages installed will be mapped.
369 Default is "no".
370 Example: require_issuerdn="no"
372 x509_cert_dir
375 The directory containing the CA certificates. This information
376 is needed by the require_issuerdn option.
377 Example: x509_cert_dir="/etc/grid-security/certificates"
379 filter An ACL filter for the nordugridmap utility. Multiple allow/deny
382 statements are possible. The fetched DNs are filtered against
383 the specified rules before they are added to the generated map‐
384 file. A `*' can be used as a wildcard. You may run the nor‐
385 dugridmap with the --test command line option to see how the
386 filters you specified work.
387 Examples:
389 filter="deny *infn*"
391 filter="allow *NorduGrid*"
392
395 The grid-manager block configures the grid-manager process taking care
396 of the grid tasks on the frontend (stagein/stageout, LRMS job submis‐
397 sion, caching, etc...).
398 controldir
401 The directory of the grid-manager's internal job log files, not
402 needed on the nodes.
403 Example: controldir="/var/spool/nordugrid/jobstatus"
405 sessiondir
408 The directory which holds the session directories of the grid
409 jobs. Multiple session directories may be specified by specify‐
410 ing multiple sessiondir commands. In this case jobs are spread
411 evenly over the session directories. If sessiondir="*" is set,
412 the session directory will be spread over the ${HOME}/.jobs
413 directories of every locally mapped unix user. It is preferred
414 to use common session directories.
415 Example: sessiondir="/scratch/grid"
417 runtimedir
420 The directory which holds the runtime environment scripts,
421 should be available on the nodes as well. The runtime environ‐
422 ments are automatically detected and advertised in the informa‐
423 tion system.
424 Example: runtimedir="/SOFTWARE/runtime"
426 cachedir
429 Specifies the directory where to store cached data. If the cache
430 attribute is not specified or the specified path is empty
431 caching is disabled. An optional second argument specifies the
432 path at which the cached data is accessible at the computing
433 nodes (if different from the path at the frontend node). If the
434 second argument is set to `.' files are not soft-linked, but
435 copied to the session directory. Multiple caches can be speci‐
436 fied by specifying multiple cachedir options
437 Examples:
439 cachedir="/scratch/cache"
441 cachedir="/shared/cache /frontend/cache"
442 remotecachedir
445 Specifies caches which are under the control of other GMs, but
446 which this GM can have read-only access to. Multiple remote
447 cache directories may be specified by specifying multiple
448 remotecachedir commands. If a file is not available in paths
449 specified by cachedir, the GM looks in remote caches. The second
450 argument has the same meaning as in cachedir, but the special
451 path ``replicate'' means files will be replicated from remote
452 caches to local caches when they are requested.
453 Example: remotecachedir="/mnt/fs1/cache replicate"
455 cachesize
458 Value should be given as "max min". Specifies high and low
459 watermark for space used by cache. Values are specified as per‐
460 centages of the cache file system.
461 Example: cachesize="80 70"
463 cachelifetime
466 If cache cleaning is enabled, files accessed less recently than
467 the given time period will be deleted. Example values of this
468 option are 1800, 90s, 24h, 30d. When no suffix is given the unit
469 is seconds.
470 Example: cachelifetime="30d"
472 cachelogfile
475 Specifies the filename where output of the cache-clean tool
476 should be logged. Defaults to /var/log/arc/cache-clean.log.
477 Example: cachelogfile="/tmp/cache-clean.log"
479 cacheloglevel
482 Specifies the level of logging by the cache-clean tool, between
483 0 (FATAL) and 5 (DEBUG). Defaults to 3 (INFO).
484 Example: cacheloglevel="2"
486 cachecleantimeout
489 The timeout in seconds for running the cache-clean tool. If
490 using a large cache or slow file system this value can be
491 increased to allow the cleaning to complete. Defaults to 3600 (1
492 hour).
493 Example: cachecleantimeout="10000"
495 user Switch to a non-root user/group after startup. The format of the
498 argument is user[:group].
499 Examples:
501 user="grid"
503 user="griduser:gridgroup"
504 debug Set the debug level of the grid-manager daemon. Level 0 stands
507 for no debug. Increasing number gives more information, up to a
508 maximum of 5.
509 Example: debug="2"
511 logfile
514 Specify the log file location. This file is opened/created
515 before the daemon switches to specified user. Hence it can be
516 owned by root. Default log file is "/var/log/arc/grid-man‐
517 ager.log".
518 Example: logfile="/var/log/arc/grid-manager.log"
520 logsize
523 Specifies the (approximate) maximum size in bytes of the log
524 file. A second argument indicates how many log files are kept.
525 When the logfile exceeds the specified size it is renamed to
526 logfile.0 and logfile.0 is renamed to logfile.1 and so on. When
527 installing from packages, logrotate is used to manage log files,
528 so only use this option if logrotate is disabled.
529 Example: logsize="100000 2"
531 pidfile
534 Specifies the location of the file containing the process id
535 (PID) of the daemon process. This is useful for automatic
536 start/stop scripts.
537 Example: pidfile="/var/run/grid-manager.pid"
539 gnu_time
542 the GNU time command. Default is /usr/bin/time.
543 Example: gnu_time="/usr/bin/time"
545 shared_filesystem
548 Specifies whether the computing nodes can access the session
549 directory at the frontend node. Defaults to "yes".
550 Example: shared_filesystem="yes"
552 mail Specifies the e-mail address from where the notification mails
555 are sent.
556 Example: mail="grid.support@somewhere.org"
558 joblog Specifies where to store a specialised log about started and
561 finished jobs. If the given path is empty or the joblog
562 attribute is not given the log is disabled.
563 Example: joblog="/var/log/arc/gm-jobs.log"
565 jobreport
568 Tells the grid-manager to report all started and finished jobs
569 to a logger service. Multiple jobreport commands are allowed. In
570 that case the job information will be sent to all specified ser‐
571 vices.
572 Example: jobreport="https://grid.uio.no:8001/logger"
574 maxjobs
577 Specifies the maximum allowed number of jobs being processed at
578 different stages: 1. max processed jobs – maximum number of con‐
579 current jobs processed. This does not limit the amount of jobs
580 which can be submitted to the cluster. 2. max running jobs –
581 maximum number of jobs passed to Local Resource Management Sys‐
582 tem. 3. max jobs per dn – maximum number of concurrent jobs pro‐
583 cessed by A-REX per user DN. If this option is used the total
584 maximum number of jobs processed is still max processed jobs. 4.
585 max jobs total – total maximum number of jobs associated with
586 service. It is advised to use this limit only in exceptional
587 case because it also accounts for finished jobs. Missing number
588 or -1 means no limit.
589 Example: maxjobs="10000 10 1000"
591 maxload
594 Specifies the maximum allowed number of jobs. The value should
595 be three numbers separated by spaces. The first number limits
596 the number of jobs being processed on frontend (PREPARING, FIN‐
597 ISHING states). The second number is the additional reserved
598 number of jobs being processed on frontend. The third number
599 limits the number of files being transferred simultaneously by
600 jobs in PREPARING and FINISHING states. Missing number or -1
601 means no limit.
602 Example: maxload="10 2 5"
604 maxloadshare
607 Specifies a sharing mechanism for data transfer. The values are
608 an integer followed by a space followed by a string. The first
609 number is the maximum number of processes that can run per
610 transfer share and the string is the scheme used to assign jobs
611 to transfer shares. Possible values of this string are "dn",
612 "voms:vo", "voms:role", and "voms:group".
613 Example: maxloadshare="4 voms:role"
615 share_limit
618 Specifies a transfer share that has a number of processes dif‐
619 ferent from the default value in maxloadshare. name is the name
620 of the share and limit is the number of processes for this
621 share. In the configuration should appear after maxloadshare. Can
622 be repeated several times for different shares.
623 Example: share_limit="atlas:production 10"
625 newdatastaging
628 Turns on and off the new data staging framework which replaces
629 the downloader and uploader for managing input and output files.
630 It is off by default
631 Example: newdatastaging="yes"
633 delivery_service
636 Specifies a remote delivery service to be used by the new data
637 staging framework.
638 Example: delivery_service="https://example.com:60002/datadeliv‐
640 eryservice
641 local_delivery
644 In case remote delivery services are configured using the previ‐
646 ous option, this option specifices whether or not delivery
647 should also be done locally on the A-REX host. Default is no.
648 Example: local_delivery="yes"
650 wakeupperiod
653 Specifies how often the grid-manager checks for new jobs
654 arrived, jobs finished in LRMS, etc. The value should be an
655 integer representing a time period in seconds. Default is 3 min‐
656 utes. Usually this command is not needed.
657 Example: wakeupperiod="180"
659 securetransfer
662 Specifies if the server allows users to specify to use secure
663 data transfer. Default is "no".
664 Example: securetransfer="no"
666 passivetransfer
669 Specifies whether gridftp transfers are passive. Setting this
670 option to yes can solve transfer problems caused by firewalls.
671 Default is "no".
672 Example: passivetransfer="no"
674 localtransfer
677 If set to "yes" the data download to the session directory
678 (stage in) will be part of the batch job (prior to the execution
679 of the binary). Default is "no".
680 Example: localtransfer="no"
682 speedcontrol
685 Specifies how slow data transfers must be to trigger an error.
686 The value should be four integers separated by spaces in the
687 format "min_speed min_time min_average_speed max_inactivity".
688 The transfer is cancelled if the speed is below min_speed bytes
689 per second for at least min_time seconds, or if average rate is
690 below min_average_speed bytes per second, or no data was trans‐
691 ferred for longer than max_inactivity seconds. A value of zero
692 turns feature off. Default is "0 300 0 300".
693 Example: speedcontrol="0 300 0 300"
695 defaultttl
698 The value should be given as "ttl [ttr]". ttl is the time in
699 seconds for how long a session directory will survive after job
700 execution has finished. If not specified the default is one
701 week. ttr is how long information about a job will be kept. If
702 not specified the ttr default is one month.
703 Example: defaultttl="259200"
705 authplugin
708 Every time a job goes into a specific state the specified exe‐
709 cutable is run with the given arguments. In the plain text for‐
710 mat the state is specified by adding its name before the path to
711 the executable and any specified suboptions. In the xml format
712 the state is given by a state xml attribute to the xml tag. Pos‐
713 sible suboptions are:
714 timeout
717 wait for result no longer than the specified number of
718 seconds.
719 onsuccess, onfailure, ontimeout
722 what to do if the plugin exits with exit code zero, with
723 non-zero exit code or if the timeout is reached respec‐
724 tively. Possible values are:
725 pass - continue the execution of the job,
727 fail - cancel the job,
729 log - write to the log file about the problem and con‐
731 tinue the execution of the job.
732 Example (plain text):
735 authplugin="ACCEPTED timeout=10 /opt/nordugrid/libexec/bank
737 %C/job.%I.local %S"
738 Example (xml):
740 <authplugin state="ACCEPTED" timeout="10">/opt/nor‐
742 dugrid/libexec/bank %C/job.%I.local %S</authplugin>
743 ARC is distributed with a plugin called "inputcheck". It's pur‐
745 pose is to check if input files requested in job's XRSL are
746 accessible from this machine. It accepts two arguments: the name
747 of the file containing the XRSL and name of the proxy file.
748 Example (plain text):
750 authplugin="ACCEPTED timeout=60 /opt/nor‐
752 dugrid/libexec/inputcheck %C/job.%I.description %C/job.%I.proxy"
753 Example (xml):
755 <authplugin state="ACCEPTED" timeout="60">/opt/nor‐
757 dugrid/libexec/inputcheck %C/job.%I.description
758 %C/job.%I.proxy</authplugin>
759 localcred
762 Run an external executable or a function form a shared library.
763 Every time the job has to do something on behalf of a local user
764 this plugin will be called. It's purpose is to set non-unix per‐
765 missions and credentials on the running task. If the plugin path
766 looks like name@path, then the function "name" from the shared
767 library at path will be called, otherwise the external exe‐
768 cutable at path will be called. Don't use it unless you really
769 know what you are doing. A timeout can be defined as a suboption
770 if required.
771 Example (plain text): localcred="acquire@/opt/nor‐
773 dugrid/lib/afs.so %C/job.%I.proxy"
774 Example (xml): <localcred>acquire@/opt/nordugrid/lib/afs.so
776 %C/job.%I.proxy</localcred>
777 norootpower
780 If set to "yes", all job management processes will switch to the
781 mapped user's identity while accessing the session directory.
782 This is useful if the session directory is on NFS with root
783 squashing turned on. Default is "no".
784 Example: norootpower="yes"
786 allowsubmit
789 An authorisation group allowed to submit new jobs while
790 "allownew=no" is active in the jobplugin configuration. Multiple
791 commands are allowed.
792 Example: allowsubmit="admins"
794 helper Allows to run additional executables on behalf of users. Every
797 time this executable finishes it will be started again. This
798 helper plugin mechanism can be used as the grid-manager's alter‐
799 native for the /etc/init.d or cron to (re)start external pro‐
800 cesses. The value should be given as "user executable argu‐
801 ments". If user is `*' one instance is run for every specified
802 user. If user is `.' one instance is run unrelated to any speci‐
803 fied user.
804 Example: helper=". /usr/local/bin/myutility"
806 preferredpattern
809 pattern - specifies a preferred pattern on which to sort multi‐
810 ple replicas of an input file. It consists of one or more pat‐
811 terns separated by a pipe character (|) listed in order of pref‐
812 erence. Replicas will be ordered by the earliest match. If the
813 dollar character ($) is used at the end of a pattern, the pat‐
814 tern will be matched to the end of the hostname of the replica.
815 Example: preferredpattern="srm://myhost.ac.uk|.uk$|ndgf.org$"
817 copyurl
820 url_head local_path - specifies that URLs, starting from
821 `url_head', should be accessed in a different way (most probably
822 unix open). The `url_head' part of the URL will be replaced with
823 `local_path' and the file from the obtained path will be copied
824 to the session directory. NOTE: `local_path' can also be of URL
825 type. You can have several copyurl lines.
826 Example: copyurl="gsiftp://example.org:2811/data/ gsiftp://exam‐
828 ple.org/data/"
829 linkurl
832 url_head local_path [node_path] - identical to `copyurl', only
833 the file won't be copied, but soft-link will be created. The
834 `local_path' specifies the way to access the file from the gate‐
835 keeper, and is used to check permissions. The `node_path' speci‐
836 fies how the file can be accessed from computing nodes, and will
837 be used for soft-link creation. If `node_path' is missing -
838 `local_path' will be used. You can have multiple linkurl set‐
839 tings.
840 Example: linkurl="gsiftp://example.org:2811/data/
842 /scratch/data/"
843 tmpdir Used by the grid-manager. Default is /tmp.
846 Example: tmpdir="/tmp"
848 maxrerun
851 Specifies how many times a job can be rerun if it fails in the
852 LRMS. Default value is 2. This is only an upper limit, the
853 actual rerun value is set by the user in his xrsl.
854 Example: maxrerun="2"
856 maxtransfertries
859 The maximum number of times download and upload will be
860 attempted per job (retries are only performed if an error is
861 judged to be temporary).
862 Example: maxtransfertries="10"
864 pbs_bin_path
867 The path to qstat, pbsnodes, qmgr and other PBS binaries. No
868 need to set if PBS is not used.
869 Example: pbs_bin_path="/usr/bin"
871 pbs_log_path
874 The path to the PBS server log files which are used by the grid-
875 manager to determine whether a PBS job is completed. If not
876 specified the grid-manager will use qstat for that.
877 Example: pbs_log_path="/var/spool/pbs/server_logs"
879 sge_bin_path
882 Path to Sun Grid Engine (SGE) binaries. MUST be set if SGE is
883 used.
884 Example: sge_bin_path="/opt/n1ge6/bin/lx24-x86"
886 sge_root
889 Path to SGE installation directory. MUST be set if SGE is used.
890 Example: sge_root="/opt/n1ge6"
892 sge_cell
895 The name of the SGE cell to use. This option is only necessary
896 in case SGE is set up with a cell name different from 'default'
897 Example: sge_cell="default"
899 sge_qmaster_port, sge_execd_port
902 These options should be used in case SGE command line clients
903 requre SGE_QMASTER_PORT and SGE_EXECD_PORT environment variables
904 to be set. Usually they are not necessary.
905 Example:
907 sge_qmaster_port="536"
908 sge_execd_port="537"
909 SLURM_bin_path
912 The path to squeue, sinfo and other SLURM binaries. No need to
913 set if SLURM is not used.
914 Example: SLURM_bin_path="/usr/bin"
916 SLURM_log_path The path to the SLURM server log files which are
918 used by the grid-manager to determine whether a SLURM job is
919 completed.
920 Example: SLURM_log_path="/var/spool/slurm"
922 SLURM_wakeupperiod How long should infosys wait between querying
925 SLURM for new data.
926 Example: SLURM_wakeupperiod="15"
928 condor_location
931 Path to directory containing Condor's bin, sbin, etc. No need to
932 set if Condor is not used.
933 Example: condor_location="/opt/condor"
935 condor_config
938 Path to Condor's configuration file. No need to set if Condor is
939 not used.
940 Example: condor_config="/opt/condor/etc/condor_config"
942 condor_rank
945 If you are not happy with the way Condor picks nodes when run‐
946 ning jobs, you can define your own ranking algorithm by option‐
947 ally setting the condor_rank attribute. It should be set to a
948 ClassAd float expression that you could use in the Rank
949 attribute in a Condor job description. Obviously no need to set
950 if Condor is not used.
951 Example:
953 condor_rank="(1-LoadAvg/2)*(1-LoadAvg/2)*Memory/1000*KFlops/1000000"
955 lsf_bin_path
958 The PATH to LSF bin folder. No need to set if LSF is not used.
959 Example: lsf_bin_path="/usr/local/lsf/bin/"
961 lsf_profile_path
964 The PATH to LSF profile: profile.lsf. No need to set if LSF is
965 not used.
966 Example: lsf_profile_path="/usr/share/lsf/conf"
968 ll_bin_path
971 The PATH to the LoadLeveler bin folder. No need to set if
972 LoadLeveler is not used.
973 Example: ll_bin_path="/opt/ibmll/LoadL/full/bin"
975 ll_consumable_resources
978 Use Consumable Resources for a LoadLeveler.
979 Example: ll_consumable_resources="yes"
981 hostname
984 The FQDN of the frontend node.
985 Example: hostname="myhost.org"
987 lrms Sets the type of Local Resource Management System (queueing sys‐
990 tem). Choose one from the following options: fork, sge, condor,
991 pbs, lsf, ll, slurm. PBS has many flavours, we support OpenPBS,
992 PBSPro, ScalablePBS and Torque (the official name for Scal‐
993 ablePBS). No need to specify the flavour or the version number
994 of the PBS, simply write "pbs". The optional "queue" parameter
995 specifies the default grid queue of the LRMS. The grid-manager
996 submits jobs to this queue if there is no queue set in the job's
997 XRSL.
998 Example: lrms="pbs grid"
1000 globus_tcp_port_range, globus_udp_port_range
1003 Firewall configuration. In a firewalled environment the software
1004 which uses GSI needs to know what ports are available. The full
1005 documentation can be found at: http://dev.globus.org/wiki/Fire‐
1006 wallHowTo. These variable are similar to the Globus environment
1007 variables GLOBUS_TCP_PORT_RANGE and GLOBUS_UDP_PORT_RANGE.
1008 Example:
1010 globus_tcp_port_range="9000,12000"
1012 globus_udp_port_range="9000,12000"
1013 x509_user_cert, x509_user_key
1016 Server credentials location. These variables are similar to the
1017 GSI environment variables X509_USER_KEY and X509_USER_CERT.
1018 Example:
1020 x509_user_key="/etc/grid-security/hostkey.pem"
1022 x509_user_cert="/etc/grid-security/hostcert.pem"
1023 x509_cert_dir
1026 Location of trusted CA certificates. This variable is similar to
1027 the GSI environment variable X509_CERT_DIR.
1028 Example: x509_cert_dir="/etc/grid-security/certificates"
1030 gridmap
1033 The gridmap file location. This variable is similar to the GSI
1034 environment variable GRIDMAP. The default is /etc/grid-secu‐
1035 rity/grid-mapfile.
1036 Example: gridmap="/etc/grid-security/grid-mapfile"
1038 voms_processing
1041 Defines how to behave if errors in VOMS AC processing detected.
1042 relaxed - use everything that passed validation.
1043 standard - same as relaxed but fail if parsing errors took place
1044 and VOMS extension is marked as critical. This is a default.
1045 strict - fail if any parsing error was discovered.
1046 noerrors - fail if any parsing or validation error happened.
1047 Example: voms_processing="strict"
1049 http_proxy
1052 Use an http proxy server for downloading files from http
1053 servers. The format of the argument is host[:port].
1054 Example: http_proxy="proxy.mydomain.org:3128"
1056 In the command arguments (paths, executables, ...) the following sub‐
1059 stitutions can be used:
1060 %R session directory
1063 %C control directory
1066 %U username
1069 %u userid - numerical
1072 %g groupid - numerical
1075 %H home directory - home specified in /etc/passwd
1078 %Q default queue
1081 %L default lrms
1084 %W installation path - ${ARC_LOCATION}
1087 %G globus path - ${GLOBUS_LOCATION}
1090 %c list of all control directories
1093 %I job ID (for plugins only, substituted at runtime)
1096 %S job state (for authplugin plugins only, substituted at runtime)
1099 %O reason (for localcred plugins only, substituted at runtime).
1102 Possible reasons are:
1103 new - new job, new credentials
1105 renew - old job, new credentials
1107 write - write/delete file, create/delete directory (through
1109 gridftp)
1110 read - read file, directory, etc. (through gridftp)
1112 extern - call external program (grid-manager)
1114 See some of the examples above for examples of use.
1117
1120 The gridftpd block configures the gridftpd server.
1121 user Switch to a non-root user/group after startup. The format of the
1124 argument is user[:group]. WARNING: Make sure that the certifi‐
1125 cate files are owned by the user[:group] specified by this
1126 option. Default value is root.
1127 Example: user="grid"
1129 debug Set the debug level of the gridftpd daemon. Level 0 stands for
1132 no debug. Increasing number gives more information up to a maxi‐
1133 mum of 5.
1134 Example: debug="2"
1136 logfile
1139 Set log file location.
1140 Example: logfile="/var/log/arc/gridftpd.log"
1142 logsize
1145 Specifies the (approximate) maximum size in bytes of the log
1146 file. A second argument indicates how many log files are kept.
1147 When the logfile exceeds the specified size it is renamed to
1148 logfile.0 and logfile.0 is renamed to logfile.1 and so on. When
1149 installing from packages, logrotate is used to manage log files,
1150 so only use this option if logrotate is disabled.
1151 Example: logsize="100000 2"
1153 pidfile
1156 Specifies the location of the file containing the process id
1157 (PID) of the daemon process. This is useful for automatic
1158 start/stop scripts.
1159 Example: pidfile="/var/run/gridftpd.pid"
1161 port Port to listen on (default 2811).
1164 Example: port="2811"
1166 pluginpath
1169 Directory where the plugin libraries are installed, default is
1170 ${ARC_LOCATION}/lib/arc.
1171 Example: pluginpath="/opt/nordugrid/lib"
1173 encryption
1176 Should data encryption be allowed, default is "no". Encryption
1177 is very heavy.
1178 Example: encryption="no"
1180 allowunknown
1183 If "no", check user subject against grid-mapfile and reject if
1184 missing. By default unknown (not in the grid-mapfile) grid users
1185 are rejected.
1186 Example: allowunknown="no"
1188 maxconnections
1191 Maximum number of connections accepted by a gridftpd server.
1192 Default is 100.
1193 Example: maxconnections="200"
1195 globus_tcp_port_range, globus_udp_port_range
1198 Firewall configuration.
1199 Examples:
1201 globus_tcp_port_range="9000,12000"
1203 globus_udp_port_range="9000,12000"
1204 firewall
1207 IP address or hostname to use in response to PASV command
1208 instead of IP address of a network interface of computer. This
1209 command may be used if server is situated behind NAT.
1210 Examples: firewall=gateway.campus.org
1212 x509_user_cert, x509_user_key
1215 Server credentials location.
1216 Examples:
1218 x509_user_key="/etc/grid-security/hostkey.pem"
1220 x509_user_cert="/etc/grid-security/hostcert.pem"
1221 x509_cert_dir
1224 Location of trusted CA certificates.
1225 Example: x509_cert_dir="/etc/grid-security/certificates"
1227 gridmap
1230 The gridmap file location. The default is /etc/grid-secu‐
1231 rity/grid-mapfile
1232 Example: gridmap="/etc/grid-security/grid-mapfile"
1234 voms_processing
1237 Defines how to behave if errors in VOMS AC processing detected.
1238 relaxed - use everything that passed validation.
1239 standard - same as relaxed but fail if parsing errors took place
1240 and VOMS extension is marked as critical. This is a default.
1241 strict - fail if any parsing error was discovered.
1242 noerrors - fail if any parsing or validation error happened.
1243 Example: voms_processing="strict"
1245
1248 Configuration for a classic gridftp file server using the fileplugin.
1249 Each exported mount point is configured in its own configuration block
1250 and is given its own id. If the plain text format is used, the configu‐
1251 ration block identified as "files" is defined by:
1252 [gridftpd]
1254 id="files"
1255 If the xml format is used the same block is defined using the attrib‐
1257 uted xml tag:
1258 <gridftpd id="files">...</gridftpd>
1260 The access control is defined by specifying the dir configuration
1262 option.
1263 plugin Specifies the name of the shared library to be loaded relative
1266 to the path given in the pluginpath option. For a classic
1267 gridftp file server using the fileplugin it should be fileplu‐
1268 gin.so.
1269 Example: plugin="fileplugin.so"
1271 groupcfg
1274 Specifies the authorisation groups for which this plugin is
1275 activated. In case groupcfg is not specified the plugin is
1276 loaded for every mapped grid user.
1277 Example: groupcfg="atlas_users bio_students"
1279 path The name of the virtual directory served by the gridftp server.
1282 If set to "/topdir" the exported storage area is accessible as
1283 gsiftp://<hostname>/topdir. The virtual path can be anything you
1284 like, even "/" is a valid choice.
1285 Example: path="/topdir"
1287 mount The physical directory on the local file system corresponding to
1290 the virtual one.
1291 Example: mount="/scratch/grid"
1293 dir This is the access control parameter, you can have several dir
1296 lines controlling different directories within then same block.
1297 The value for this option is a path followed by one or more
1299 options. The options are:
1300 nouser do not use local file system rights, only use those spec‐
1302 ifies in this line
1303 owner check only file owner access rights
1305 group check only group access rights
1307 other check only "others" access rights
1309 If none of the above specified usual unix access rights are
1312 applied.
1313 read allow reading files
1316 delete allow deleting files
1318 append allow appending files (does not allow creation)
1320 overwrite
1322 allow overwriting already existing files (does not allow
1323 creation, file attributes are not changed)
1324 dirlist
1326 allow obtaining list of the files
1327 cd allow to make this directory current
1329 create owner:group permissions_or:permissions_and
1331 allow creating new files. File will be owned by `owner'
1332 and owning group will be `group'. If `*' is used, the
1333 user/group to which connected user is mapped will be
1334 used. The permissions will be set to permissions_or &
1335 permissions_and. (The second number is reserved for the
1336 future usage).
1337 mkdir owner:group permissions_or:permissions_and
1339 allow creating new directories.
1340 Examples:
1343 dir="/ nouser read cd dirlist delete create *:* 664:664 mkdir
1345 *:* 775:775"
1346 dir="/scratch nouser read mkdir *:* 700:700 cd dirlist"
1347 dir="/example_data nouser read mkdir *:* 700:700 cd dirlist"
1348
1351 Configuration for a GACL enabled gridftp file server using the gaclplu‐
1352 gin. Each exported mount point is configured in its own configuration
1353 block and is given its own identifier. If the plain text format is
1354 used, the configuration block identified as "gaclfiles" is defined by:
1355 [gridftpd]
1357 id="gaclfiles"
1358 If the xml format is used the same block is defined using the attrib‐
1360 uted xml tag:
1361 <gridftpd id="gaclfiles">...</gridftpd>
1363 The access control is set through GACL files placed in the physical
1365 directories assigned to every file/directory. Newly created directories
1366 and uploaded files automatically obtain their default GACL files: only
1367 the creator of the file/directory has read, write, list and admin capa‐
1368 bilities. This default is not configurable yet. Additionally the
1369 "mount" directory must contain a .gacl file with initial GACL otherwise
1370 the rule will be "deny everything for everyone".
1371 plugin Specifies the name of the shared library to be loaded relative
1374 to the path given in the pluginpath option. For a GACL enabled
1375 gridftp file server using the gaclplugin it should be gaclplu‐
1376 gin.so.
1377 Example: plugin="gaclplugin.so"
1379 groupcfg
1382 Specifies the authorisation groups for which this plugin is
1383 activated. In case groupcfg is not specified the plugin is
1384 loaded for every mapped grid user.
1385 Example: groupcfg="atlas_users bio_students"
1387 path The name of the virtual directory served by the gridftp server.
1390 If set to "/gacltop" the exported storage area is accessible as
1391 gsiftp://<hostname>/gacltop. The virtual path can be anything
1392 you like, even "/" is a valid choice.
1393 Example: path="/gacltop"
1395 mount The physical directory on the local file system corresponding to
1398 the virtual one. The directory must contain a .gacl file with
1399 the default GACL settings.
1400 Example: mount="/scratch/GACL"
1402 gacl Specifies the default GACL rule. MUST be set. The GACL expres‐
1405 sion must be given in one line and in GACL xml format.
1406 Example: gacl="<gacl>very long single line</gacl>"
1408 The default gacl can contain variables which are replaced with
1410 values taken from client's credentials. The following variables
1411 are supported:
1412 $subject
1415 subject of user's certificate (DN),
1416 $voms subject of VOMS server (DN),
1418 $vo name of VO (from VOMS certificate),
1420 $role role (from VOMS certificate),
1422 $capability
1424 capabilities (from VOMS certificate),
1425 $group name of group (from VOMS certificate).
1427
1430 Configuration for a job submission interface using the gridftp servers
1431 jobplugin. The identifier of the configuration block is arbitrary but
1432 must be unique. If the plain text format is used, the configuration
1433 block identified as "jobs" is defined by:
1434 [gridftpd]
1436 id="jobs"
1437 If the xml format is used the same block is defined using the attrib‐
1439 uted xml tag:
1440 <gridftpd id="jobs">...</gridftpd>
1442 plugin Specifies the name of the shared library to be loaded relative
1445 to the path given in the pluginpath option. For a job submission
1446 service it should be jobplugin.so.
1447 Example: plugin="jobplugin.so"
1449 groupcfg
1452 Specifies the authorisation groups for which this plugin is
1453 activated. In case groupcfg is not specified the plugin is
1454 loaded for every mapped grid user.
1455 Example: groupcfg="atlas_users bio_students"
1457 path The name of the virtual directory used during jobs submission.
1460 This will be part of the jobid of the jobs submitted to this
1461 service.
1462 Example: path="/jobs"
1464 allownew
1467 Specifies if the grid resource accepts submission of new jobs.
1468 This parameter can be used to close down a grid. The default is
1469 "yes".
1470 Example: allownew="yes"
1472 remotegmdirs
1475 Specifies control and session directories to which jobs can be
1476 submitted but which are under the control of another GM. The
1477 corresponding controldir and sessiondir parameters must be
1478 defined in another grid-manager's configuration. Multiple
1479 remotegmdirs can be specified.
1480 Example: remotegmdirs="/mnt/host1/control /mnt/host1/session"
1482 maxjobdesc
1485 Specifies maximal allowed size of job description in bytes.
1486 Default value is 5MB. If value is missing or 0 size is not lim‐
1487 ited.
1488 Example: maxjobdesc="5242880"
1490
1494 The infosys block configures the hosting environment of the Information
1495 services (Local Info Tree, Index Service, Registrations).
1496 infosys_compat
1499 Setting this variable will cause ARC to use the old info‐
1500 providers. Basically, the new version uses A-REX to create LDIF
1501 while the old version uses a BDII provider-script to do it. The
1502 new version is required for Glue2 output.
1503 Example: infosys_compat="disable"
1505 overwrite_config
1508 Determines if the grid-infosys startup script should generate
1509 new low-level slapd configuration files. By default the low-
1510 level configuration files are regenerated with every server
1511 startup making use of the values specified in the arc.conf.
1512 Example: overwrite_config="yes"
1514 oldconfsuffix
1517 Sets the suffix of the backup files of the low-level slapd con‐
1518 fig files in case the they are regenerated. Default is ".oldcon‐
1519 fig".
1520 Example: oldconfsuffix=".oldconfig"
1522 hostname
1525 The hostname of the machine running the slapd service.
1526 Example: hostname="my.testbox"
1528 port The port where the slapd service runs. Default infosys port is
1531 2135.
1532 Example: port="2135"
1534 debug Sets the debug level/verbosity of the startup script {0 or 1}.
1537 Default is 0.
1538 Example: debug="1"
1540 slapd_loglevel
1543 Sets the native slapd log level (see man slapd). Slapd logs via
1544 syslog. The default is set to no-logging (0) and it is RECOM‐
1545 MENDED not to be changed in a production environment. Non-zero
1546 slap_loglevel value causes serious performance decrease.
1547 Example: slapd_loglevel="0"
1549 slapd_hostnamebind
1552 May be used to set the hostname part of the network interface to
1553 which the slapd process will bind. Most of the cases no need to
1554 set since the hostname config parameter is already sufficient.
1555 The default is empty. The example below will bind the slapd
1556 process to all the network interfaces available on the server.
1557 Example: slapd_hostnamebind="*"
1559 threads
1563 The native slapd threads parameter, default is 32. If you run an
1564 Index service too you should modify this value.
1565 Example: threads="128"
1567 timelimit
1570 The native slapd timelimit parameter. Maximum number of seconds
1571 the slapd server will spend answering a search request. Default
1572 is 3600. You probably want a much lower value.
1573 Example: timelimit="1800"
1575 idletimeout
1578 The native slapd idletimeout parameter. Maximum number of sec‐
1579 onds the slapd server will wait before forcibly closing idle
1580 client connections. It's value must be larger than the value of
1581 "timelimit" option. If not set, it defaults to timelimit + 1.
1582 Example: idletimeout="1800"
1583 registrationlog
1586 Specifies the log file for the registration processes initiated
1587 by your machine. Default is "/var/log/arc/inforegistration.log".
1588 Example: registrationlog="/var/log/arc/inforegistration.log"
1590 providerlog
1593 Specifies log file location for the information provider
1594 scripts. The feature is only available with >= 0.5.26 tag.
1595 Default is "/var/log/arc/infoprovider.log"
1596 Example: providerlog="/var/log/arc/infoprovider.log"
1598 provider_loglevel
1601 Log level for the information provider scripts (0, 1, 2). The
1602 default is 1 (critical errors are logged).
1603 Example: provider_loglevel="2"
1605 x509_cert_dir
1608 Location of trusted CA certificates.
1609 Example: x509_cert_dir=/etc/grid-security/certificates
1611 x509_user_cert, x509_user_key
1614 Server credentials location.
1615 Examples:
1617 x509_user_cert="/etc/grid-security/ldapcert.pem"
1619 x509_user_key="/etc/grid-security/ldapkey.pem"
1620 gridmap
1623 The gridmap file location.
1624 Example: gridmap=/etc/grid-security/grid-mapfile
1626 limit_core, limit_nofile
1629 Shell limits for the slapd process set via `ulimit -c' and
1630 `ulimit -n'.
1631 Examples:
1633 limit_core="0"
1635 limit_nofile=""
1636 user The unix user running the information system processes such as
1639 the slapd, the registrations and information provider scripts.
1640 By default the user executing the startup script is set. In case
1641 of non-root value you must make sure that the grid-manager
1642 directories and their content are readable by the `user' and the
1643 `user' has access to the full LRMS information including jobs
1644 submitted by other users. The grid-manager directories (con‐
1645 troldir, sessiondir, runtimedir, cachedir) are specified in the
1646 grid-manager block
1647 Example: user="root"
1649 giis_location
1652 If giis_location is not set, NORDUGRID_LOCATION will be used
1653 instead.
1654 Example: giis_location="/opt/nordugrid"
1656 works together with both BDII4 and BDII5. If you use the
1660 nordugrid-packaged BDII installation, these variables have sensible
1661 defaults and can be omitted. The only variables that system administra‐
1662 tors may want to change when using nordugrid-bdii are infosys_nordugrid
1663 and infosys_glue12. These two variables specify what format the output
1664 should be in, default is infosys_nordugrid=enable, infosys_glue12=dis‐
1665 able. If infosys_glue12 is enabled, then you need to set resource_loca‐
1666 tion, resource_latitude, resource_longitude, cpuscalingreferencesi00,
1667 processorotherdescription, gluesiteweb and gluesiteuniqueid under the
1668 [infosys/glue12] block. These variables do not have default values. You
1669 may also want to set provide_glue_site_info to false in case you want
1670 to set up a more complicated setup with several publishers of data to a
1671 GlueSite. The rest of the variables defaults are showcased here.
1672 infosys_debug disables/enables an ldap-database at the ldap tree entry‐
1673 point o=infosys. Note, the gLite supplied BDII installs into /opt/bdii.
1674 If you for some reason do not want to use the bdb ldap backend, you can
1675 set this with bdii_database.
1676 Examples:
1678 General BDII options.
1680 bdii_location="/usr"
1682 infosys_nordugrid="enable"
1683 infosys_glue12="disable"
1684 infosys_debug="disable"
1685 bdii_tmp_dir="/var/tmp/bdii"
1686 bdii_var_dir="/var/run/bdii"
1687 bdii_log_dir="/var/log/arc/bdii"
1688 bdii_conf="/var/run/nordugrid/bdii.conf"
1689 bdii_database="bdb"
1690 bdii_breathe_time="30"
1691 Glue 1.2 specific attributes
1693 resource_location="Kastrup, Denmark"
1695 resource_latitude="55.75000"
1696 resource_longitude="12.41670"
1697 cpuscalingreferencesi00="2400"
1698 processorotherdescription="Cores=3,Benchmark=9.8-HEP-SPEC06"
1699 gluesiteweb="http://www.ndgf.org"
1700 gluesiteuniqueid="NDGF-T1"
1701 provide_glue_site_info="true"
1702 BDII4 specific options.
1704 bdii_cmd="/etc/init.d/bdii4"
1706 bdii_update_cmd="/usr/sbin/bdii4-update"
1707 bdii_search_timeout="30"
1708 bdii_auto_update="no"
1709 bdii_auto_modify="no"
1710 bdii_modify_dn="no"
1711 bdii_is_cache="yes"
1712 bdii_update_url="http://"
1713 bdii_update_ldif="http://"
1714 bdii_update_conf="/var/run/nordugrid/bdii-update.conf"
1715 BDII5 specific options.
1718 bdii_read_timeout="300"
1720 bdii_db_config="/etc/bdii/DB_CONFIG"
1721 fix_glue="no"
1722 bdii_archive_size="0"
1723 bdii_update_pid_file="/var/run/arc/bdii-update.pid"
1724 slapd_pid_file="$bdii_var_dir/db/slapd.pid"
1725 slapd
1729 Configure where the slapd command is located, default is:
1730 /usr/sbin/slapd
1731 Example: slapd="/usr/sbin/slapd"
1733 slapadd
1736 Configure where the slapadd command is located, default is:
1737 /usr/sbin/slapadd
1738 Example: slapadd="/usr/sbin/slapadd"
1740
1743 The Index Service block configures and enables an Information Index
1744 Service. A separate configuration block is required for every Index
1745 Service you may run on a given machine. Each index service should be
1746 given its own id. This id is used as the index name in the "Mds-Vo-
1747 name=indexname, O=Grid" LDAP suffix characterising the Index Service.
1748 If the plain text format is used, the index service identified as
1749 "indexname" is defined by:
1750 [infosys/site]
1752 id="sitename"
1753 Site BDII configuration block, this block is used to configure ARC to
1755 generate a site-bdii that can be registered in GOCDB etc to make it a
1756 part of a gLite network. The sitename part is to be declarative of the
1757 site-bdii being generated.
1758 Examples: The unique id used to identify this site, eg "NDGF-T1"
1760 unique_id=""
1761 The url is on the format: ldap://host.domain:2170/mds-vo-name=some‐
1762 thing,o=grid and should point to the resource-bdii.
1763 url=""
1764 [infosys/index]
1766 id="indexname"
1767 If the xml format is used the same block is defined using the attrib‐
1769 uted xml tag inside the infosys block:
1770 <infosys>
1772 <index id="indexname">...</index>
1773 </infosys>
1774 allowreg
1777 Implements registration filtering within an Index Sevice. Sets
1778 the Local Information Trees or lower level Index Services
1779 allowed to register to the Index Service. List each allowed reg‐
1780 istrant with the allowreg attribute. Specifying allowreg implies
1781 setting up a strict filtering, only the matching registrants
1782 will be able to register to the Index. The wildcard `*' can be
1783 used in allowreg. Several allowreg lines can be used.
1784 Examples:
1786 All the Swedish machines can register regardless they are
1788 resources or indexes:
1789 allowreg="*.se:2135"
1791 Cluster resources from Denmark can register:
1793 allowreg="*.dk:2135/nordugrid-cluster-name=*, Mds-Vo-name=local,
1795 O=Grid"
1796 Storage resources from HIP, Finland can register:
1798 allowreg="*.hip.fi:2135/nordugrid-se-name=*, Mds-Vo-name=local,
1800 O=Grid"
1801 The index1.sweden.se can register as a Sweden Index (and only as
1803 a Sweden Index):
1804 allowreg="index1.sweden.se:2135/Mds-Vo-name=Sweden, O=Grid"
1806 Any Index Service can register:
1808 allowreg="*:2135/Mds-Vo-name=*, O=Grid"
1810
1813 Options for registering a grid information index service (GIIS) to a
1814 higher level in the Information System. Each GIIS can be registered to
1815 more than one information index server. Each registration is configured
1816 in its own configuration block.
1817 If the plain text format is used, the registration of the index service
1819 identified as "indexname" is defined by:
1820 [infosys/index/registration]
1822 id="indexname"
1823 If the xml format is used the same block is defined using a registra‐
1825 tion tag inside the attributed xml tag inside the infosys block:
1826 <infosys>
1828 <index id="indexname">
1829 <registration>...</registration>
1830 </index>
1831 </infosys>
1832 targethostname
1835 The hostname of the machine running the registration target
1836 Index Service
1837 Example: targethostname="index.myinstitute.org"
1839 targetport
1842 The port on which the target Index Service is running. The
1843 default is the 2135 Grid Resource Information Service port.
1844 Example: targetport="2135"
1846 targetsuffix
1849 The LDAP suffix of the target Index Service
1850 Example: targetsuffix="Mds-Vo-name=BigIndex, O=Grid"
1852 regperiod
1855 The registration period in seconds, the registration messages
1856 are continuously sent according to the regperiod. Default is 120
1857 s.
1858 Example: regperiod="300"
1860 registranthostname
1863 The hostname of the machine sending the registrations. This
1864 attribute inherits its value from the common and infosys blocks,
1865 most cases no need to set.
1866 Example: registranthostname="myhost.org"
1868 registrantport
1871 The port of the slapd service hosting the registrant Index Ser‐
1872 vice. The attribute inherits its value from the [infosys] block
1873 (and therefore defaults to 2135)
1874 Example: registrantport="2135"
1876 registrantsuffix
1879 The LDAP suffix of the registrant Index Service. It is automat‐
1880 ically determined from the registration block name, therefore
1881 most of the cases no need to specify.
1882 Example: registrantsuffix="Mds-Vo-name=indexname, O=Grid"
1884
1887 The cluster block configures how your cluster is seen on the grid moni‐
1888 tor (infosys point of view). Please consult the Infosys manual for
1889 detailed information on cluster attributes. If you want your cluster
1890 configured below to appear in the infosys (on the monitor) you also
1891 need to create a cluster registration block see the next block.
1892 hostname
1895 The FQDN of the frontend node.
1896 Example: hostname="myhost.org"
1898 interactive_contactstring
1901 The contact string for interactive logins, set this if the clus‐
1902 ter supports some sort of grid enabled interactive login (gsi-
1903 ssh).
1904 Example: interactive_contactstring="gsissh://frontend.clus‐
1906 ter:2200/"
1907 alias An arbitrary alias name of the cluster, optional.
1910 Example: alias="Big Blue Cluster in Nowhere"
1912 comment
1915 A free text field for additional comments about the cluster.
1916 Example:
1918 comment="This cluster is specially designed for XYZ applica‐
1920 tions: www.xyz.org"
1921 cluster_location
1924 The geographical location of the cluster, preferably specified
1925 as a postal code with a two letter country prefix.
1926 Example: cluster_location="DK-2100"
1928 cluster_owner
1931 It can be used to indicate the owner of a resource, multiple
1932 entries can be used.
1933 Example: cluster_owner="World Grid Project"
1935 authorizedvo
1938 This attribute is used to advertise which VOs are authorized on
1939 the cluster. Multiple entries are allowed.
1940 Example: authorizedvo="developer.nordugrid.org"
1942 clustersupport
1945 This is the support email address of the resource, multiple
1946 entries can be used.
1947 Example: clustersupport="grid.support@myproject.org"
1949 lrmsconfig
1952 An optional free text field to describe the configuration of
1953 your Local Resource Management System (batch system).
1954 Example: lrmsconfig="single job per processor"
1956 homogeneity
1959 Determines whether the cluster consists of identical nodes with
1960 respect to CPU type, memory, installed software (opsys). The
1961 frontend does not have to be homogeneous with the nodes. In case
1962 of inhomogeneous nodes, try to arrange the nodes into homoge‐
1963 neous groups assigned to a queue and use queue level attributes.
1964 Possible values: True, False. The default is True.
1965 Example: homogeneity="True"
1967 architecture
1970 Sets the hardware architecture of the nodes. The "architecture"
1971 is defined as the output of the "uname -m" (e.g. i686). Use this
1972 cluster attribute if only the nodes are homogeneous with respect
1973 to the architecture. Otherwise the queue level attribute may be
1974 used for inhomogeneous nodes. If the frontend's architecture
1975 agrees to the nodes, the "adotf" (Automatically Determine On The
1976 Frontend) can be used to request automatic determination.
1977 Example: architecture="adotf"
1979 opsys This multivalued attribute is meant to describe the operating
1982 system of the computing nodes. The opsys attribute can also be
1983 used to describe the kernel or libc version in case those differ
1984 from the originally shipped ones. The distribution name should
1985 be given as distroname-version.number, where spaces are not
1986 allowed. Kernel version should come in the form kernelname-ver‐
1987 sion.number. If the nodes are inhomogeneous with respect to this
1988 attribute do not set it on cluster level, arrange your nodes
1989 into homogeneous groups assigned to a queue and use queue level
1990 attributes.
1991 Examples:
1993 opsys="Redhat-7.2"
1995 opsys="Linux-2.4.21-mypatch"
1996 opsys="glibc-2.3.1"
1997 nodecpu
2000 This is the CPU type of the homogeneous nodes. The string is
2001 constructed from the /proc/cpuinfo as the value of "model name"
2002 and "@" and value of "cpu MHz". Do not set this attribute on
2003 cluster level if the nodes are inhomogeneous with respect to CPU
2004 type, instead arrange the nodes into homogeneous groups assigned
2005 to a queue and use queue-level attributes. Setting the
2006 nodecpu="adotf" will result in Automatic Determination On The
2007 Frontend, which should only be used if the frontend has the same
2008 CPU type as the homogeneous nodes.
2009 Example: nodecpu="AMD Duron(tm) Processor @ 700 MHz"
2011 nodememory
2014 This is the amount of memory (specified in MB) on the node which
2015 can be guaranteed to be available for the application. Please
2016 note in most cases it is less than the physical memory installed
2017 in the nodes. Do not set this attribute on cluster level if the
2018 nodes are inhomogeneous with respect to their memories, instead
2019 arrange the nodes into homogeneous groups assigned to a queue
2020 and use queue level attributes.
2021 Example: nodememory="512"
2023 defaultmemory
2026 If a user submits a job without specifying how much memory
2027 should be used, this value will be taken first. The order is:
2028 xrsl -> defaultmemory -> nodememory -> 1GB. This is the amount
2029 of memory (specified in MB) that a job will request(per rank).
2030 Example: defaultmemory="512"
2032 benchmark
2035 This optional multivalued attribute can be used to specify
2036 benchmark results on the cluster level. Use this cluster
2037 attribute if only the nodes are homogeneous with respect to the
2038 benchmark performance. Otherwise the similar queue level
2039 attribute should be used. Please try to use one of standard
2040 benchmark names given below if possible.
2041 Examples:
2043 benchmark="SPECINT2000 222" benchmark="SPECFP2000 333"
2045 middleware
2048 The multivalued attribute shows the installed grid software on
2049 the cluster, nordugrid and globus is automatically set, no need
2050 to specify middleware="nordugrid" or middleware="globus".
2051 Example: middleware="my grid software"
2053 nodeaccess
2056 Determines how the nodes can connect to the internet. Not set‐
2057 ting anything means the nodes are sitting on a private isolated
2058 network. "outbound" access means the nodes can connect to the
2059 outside world while "inbound" access means the nodes can be con‐
2060 nected from outside. inbound & outbound access together means
2061 the nodes are sitting on a fully open network.
2062 Examples:
2064 nodeaccess="inbound" nodeaccess="outbound"
2066 dedicated_node_string
2069 The string which is used in the PBS node configuration to dis‐
2070 tinguish the grid nodes from the rest. Suppose only a subset of
2071 nodes are available for grid jobs, and these nodes have a common
2072 "node property" string, in this case the dedicated_node_string
2073 should be set to this value and only the nodes with the corre‐
2074 sponding "pbs node property" are counted as grid enabled nodes.
2075 Setting the dedicated_node_string to the value of the "pbs node
2076 property" of the grid enabled nodes will influence how the
2077 totalcpus and the user freecpus is calculated. You don't need to
2078 set this attribute if your cluster is fully available for the
2079 grid and your cluster's PBS configuration does not use the "node
2080 property" method to assign certain nodes to grid queues. You
2081 shouldn't use this configuration option unless you make sure
2082 your PBS configuration makes use of the above described setup.
2083 Example: dedicated_node_string="gridnode"
2085 localse
2088 This multivalued parameter tells the broker that certain URLs
2089 (and locations below that) should be considered "locally" avail‐
2090 able to the cluster.
2091 Example: localse="gsiftp://my.storage/data2/"
2093 gm_mount_point
2096 This should be the same as the "path" from the gridftpd's job‐
2097 plugin configuration block. The default is "/jobs".
2098 Example: gm_mount_point="/jobs"
2100 gm_port
2103 This should be the same as the "port" from the gridftpd's job‐
2104 plugin block. The default is "2811".
2105 Example: gm_port="2811"
2107 cachetime, timelimit, sizelimit
2110 LDAP parameters of the cluster information provider. Do not
2111 change the defaults unless you know what you are doing.
2112 Examples:
2114 cachetime="30"
2116 timelimit="30"
2117 sizelimit="10"
2118
2121 Options for registering the cluster in the Information System. The
2122 cluster can be registered to more than one information index server.
2123 Each registration is configured in its own configuration block.
2124 If the plain text format is used, the cluster registration block is
2126 defined by:
2127 [cluster/registration]
2129 If the xml format is used the same block is defined using a registra‐
2131 tion tag inside the cluster block:
2132 <cluster>
2134 <registration>...</registration>
2135 </cluster>
2136 targethostname
2139 See description earlier.
2140 Example: targethostname="index.myinstitute.org"
2142 targetport
2145 See description earlier.
2146 Example: targetport="2135"
2148 targetsuffix
2151 See description earlier.
2152 Example: targetsuffix="Mds-Vo-name=BigIndex, O=Grid"
2154 regperiod
2157 See description earlier.
2158 Example: regperiod="300"
2160 registranthostname
2163 See description earlier.
2164 Example: registranthostname="myhost.org"
2166 registrantport
2169 See description earlier.
2170 Example: registrantport="2135"
2172 registrantsuffix
2175 The LDAP suffix of the registrant cluster resource It is auto‐
2176 matically determined from the infosys block. Don't set it unless
2177 you want to overwrite the default.
2178 Example: registrantsuffix="nordugrid-cluster-name=myhost.org,
2180 Mds-Vo-name=local, O=Grid"
2181
2184 Each grid enabled queue should have a separate queue block. The queue
2185 name should be used as the id of the configuration group. A queue can
2186 represent a PBS queue, an SGE pool, a Condor pool or a machine with a
2187 `fork' LRMS. Queues don't need to be registered (there is no queue reg‐
2188 istration block), once you configured your cluster to register to a
2189 Index Service the queue entries (configured with this block) automati‐
2190 cally will be there. Please consult the Infosys manual for detailed
2191 information on queue attributes. The special id `fork' should be used
2192 for identifying the queue block of the fork LRMS.
2193 fork_job_limit
2196 The allowed number of concurrent jobs in a fork system, relevant
2197 only for a fork queue. Default is 1. The special value `cpunum‐
2198 ber' can be used which will set the limit of running jobs to the
2199 number of CPUs available in the machine. This parameter is used
2200 in the calculation of free CPUs in a fork system.
2201 Example: fork_job_limit="cpunumber"
2203 homogeneity
2206 Determines whether the queue consists of identical nodes with
2207 respect to CPU type, memory, installed software (opsys). In case
2208 of inhomogeneous nodes, try to arrange the nodes into homoge‐
2209 neous groups and assigned them to a queue. Possible values:
2210 True, False. The default is True.
2211 Example: homogeneity="True"
2213 scheduling_policy
2216 This optional parameter tells the scheduling policy of the
2217 queue. PBS by default offers the FIFO scheduler, many sites run
2218 the MAUI scheduler. At the moment FIFO & MAUI is supported. If
2219 you have a MAUI scheduler you should specify the "MAUI" value
2220 since it modifies the way the queue resources are calculated. By
2221 default the "FIFO" scheduler is assumed.
2222 Example: scheduling_policy="FIFO"
2224 comment
2227 A free text field for additional comments about the queue.
2228 Example: comment="This queue is nothing more than a condor pool"
2230 maui_bin_path
2233 Set this parameter for the path of the maui commands like showbf
2234 in case you specified the "MAUI" scheduling policy above.
2235 Example: maui_bin_path="/usr/local/bin"
2237 queue_node_string
2240 In PBS you can assign nodes to a queue (or a queue to nodes) by
2241 using the "node property" PBS node configuration method and
2242 assigning the marked nodes to the queue (setting the
2243 resources_default.neednodes = queue_node_string for that queue).
2244 This parameter should contain the "node property" string of the
2245 queue assigned nodes. Setting the queue_node_string changes how
2246 the queue's totalcpus and user freecpus are determined for this
2247 queue. You shouldn't use this option unless you make sure that
2248 your PBS configuration makes use of the above configuration.
2249 Example: queue_node_string="gridlong_nodes"
2251 sge_jobopts
2254 Specify additional SGE options to be used when submitting jobs
2255 to SGE.
2256 Example: sge_jobopts="-P atlas -r yes"
2258 condor_requirements
2261 Only needed if using Condor. If using mutpiple queues, it needs
2262 to be defined for each queue. Use this option to determine which
2263 nodes belong to the current queue. The value of 'con‐
2264 dor_requirements' must be a valid constraints string which is
2265 recognized by a condor_status -constraint '....' command. It can
2266 reference pre-defined ClassAd attributes (like Memory, Opsys,
2267 Arch, HasJava, etc) but also custom ClassAd attributes. To
2268 define a custom attribute on a condor node, just add two lines
2269 like the ones below in the `hostname`.local config file on the
2270 node:
2271 NORDUGRID_RESOURCE=TRUE
2272 STARTD_EXPRS = NORDUGRID_RESOURCE, $(STARTD_EXPRS)
2273 A job submitted to this queue is allowed to run on any node
2275 which satisfies the 'condor_requirements' constraint. If 'con‐
2276 dor_requirements' is not set, jobs will be allowed to run on any
2277 of the nodes in the pool. When configuring multiple queues, you
2278 can differentiate them based on memory size or disk space.
2279 Example:
2281 condor_requirements="(OpSys == "linux" && NORDUGRID_RESOURCE && Memory >= 1000 && Memory < 2000)"
2283 lsf_architecture
2286 CPU architecture to request when submitting jobs to LSF. Use
2287 only if you know what you are doing.
2288 Example: lsf_architecture="PowerPC"
2290 totalcpus
2293 Manually sets the number of CPUs assigned to the queue. No need
2294 to specify the parameter in case the queue_node_string method
2295 was used to assign nodes to the queue (this case it is dynami‐
2296 cally calculated and the static value is overwritten) or when
2297 the queue have access to the entire cluster (this case the clus‐
2298 ter level totalcpus is the relevant parameter). Use this static
2299 parameter only if some special method is applied to assign a
2300 subset of totalcpus to the queue.
2301 Example: totalcpus="32"
2303 nodecpu, nodememory, architecture, opsys, benchmark
2306 Queue level configuration parameters should be set if they are
2307 homogeneous over the nodes assigned to the queue and they are
2308 different from the cluster level value. Their meanings are
2309 described in the cluster block. When the frontend's architecture
2310 or cputype agrees with the queue nodes, the "adotf" (Automati‐
2311 cally Determine On The Frontend) can be used to request auto‐
2312 matic determination of architecture or nodecpu.
2313 Examples:
2315 nodecpu="Pentium III (Coppermine) @ 1001 MHz"
2317 nodememory="512"
2318 architecture="adotf"
2319 opsys="Mandrake 8.0"
2320 opsys="Linux-2.4.19"
2321 benchmark="SPECINT2000 222"
2322 benchmark="SPECFP2000 333"
2323 gridmap
2326 Can be used to specify an alternative file holding the list of
2327 grid SNs for this queue. The information system parses the list
2328 of users from this file and advertises them as authorized users
2329 for this queue. Beware that this list is not actually used by
2330 gridftpd for authorization.
2331 Example: gridmap="/etc/grid-security/queuename-gridmap"
2333 cachetime, timelimit, sizelimit
2336 LDAP parameters of the queue, job and user information provider.
2337 Do not change the defaults unless you know what you are doing.
2338 Examples:
2340 cachetime="30" timelimit="30" sizelimit="5000"
2342
2346 http://www.nordugrid.org/meetings/sophia-conf.jpg
2347NorduGrid ARC 1.1.0 2011-10-24 arc.conf(5)
