#
# Alfred configuration settings and default user preference values.
#
# $Revision: #1 $
# $Date: 2007/02/28 $
#
# ----------------------------------------
# To get per-host configurations, copy this file to: 
# $RMANTREE/lib/alfred/alfred.ini-`hostname -s`
# (e.g.  alfred.ini-cruncher) and make the appropriate
# customizations; note: the hostname-named file will be
# processed -after- this default one (so it can just be
# overrides, no need to copy unchanged items).
#
# The most recent PER-USER preferences
# are found in: ~user/.pixarPrefs/RAT(version)/alfred.prefs
# which is processed last.
#

# ------------------------------------------------
#
# NOTE: the maitre-d host specification has been moved
# to the bottom of this file.
#

# -----------------------------------------------
# database - Specifies the "BatCave" database into which alfred will log
# various state data and events.  The four-item list consists of:
#  - the database type  (only MySQL is currently supported)
#  - the database server hostname
#  - the name of the database containing the alfred-specific tables
#    (the database/tables must be created first, using the supplied scripts)
#  - the database login username
#  - the database login password
#
# You can substitute your site-specific hostnames and database names
# into the specification below; or, you can configure your site nameserver,
# etc, such that these default names will work unchanged.
#
# Use the empty string {} to disable database logging. Alfred will
# automatically disabled database logging if the database connection
# attempt fails, using the given settings.
#
# Note: local dispatcher or alfserver settings may also be overridden
# on a site-wide basis by the maitre-d's alfsite.ini mechanism.
#
# (see also the 'menuItemWatchServers' setting below; at large sites,
#  there can be significant maitre-d performance gains when the
#  "Watch Servers" UI is disabled, and the BatCave interface may be
#  an alternative way to provide many of the same functions.)
#
# set alfConfig(database) {} ;# to disable database logging
#
set alfConfig(database) {MySQL alfsqlserver alfsqldatabase alfsqluser ""}


# -----------------------------------------------
# assignerDSO - the filename of the DSO which handles the maitre-d
# remote server assignments.  This can be site defined file created
# from the example code in the RAT devkit, or it can be the empty
# string {} which causes the default built-in server assignment
# scheme to be used.  File names which don't begin with '/' are
# considered to be relative to the directory containing the alfred
# executable.
#
set alfConfig(assignerDSO) {}


# -----------------------------------------------
# spoolLocation is where alfred deposits spooled jobs,
# checkpoint files, and command-output log files.
# Note that "/tmp" is typically -not- a good choice for
# this directory since /tmp is often cleared on reboot and
# therefore any restartable checkpoint files would be lost.
#
if {"windows" == [GetPlatform platform]} {
	set appPaths(spoolLocation) "c:/temp/alfspool"
} else {
	if {[file exists /var/tmp]} {
		set appPaths(spoolLocation) "/var/tmp/alfredSpool"
	} elseif {[file exists /usr/tmp]} {
		set appPaths(spoolLocation) "/usr/tmp/alfredSpool"
	} else {
		set appPaths(spoolLocation) "/tmp"
	}
}


# -----------------------------------------------
# RemoteCmd fallback handling
# Some applications, such as Pixar's MTOR generate alfred scripts which
# use "RemoteCmd" exclusively to represent commands that should be
# executed on remote systems.  Usually these remote commands are handled
# by a cooperating alfserver running on the remote host.  The following
# settings control the dispatcher's behavior when the remote alfserver
# isn't responding (or hasn't been installed).  The RemoteCmd operator
# will fallback to the following settings when the 'doRemoteCmdFallback'
# setting is 1.  NOTE: the default fallback command is 'rsh' which requires
# a matching rshd (remote execution daemon) on the remote server.  Typical
# Windows NT systems do not have a unix-style rshd, so the fallback settings
# defined below are not appropriate for default NT-to-NT execution; alfserver
# should be installed instead.  The "Status" string defined below is required
# to retrieve the exit status of the remote command, since rsh doesn't handle
# this, see rsh(1).  The "Command" and "Status" strings are wrapped around
# the specified RemoteCmd and will result in something like the following:
#
# rsh host -n 'render some.rib; if ($status) echo ALF_EXIT_STATUS $status'
#
# Note: you can force the rsh behavior to always happen, without
# the usual initial attempt to use alfserver, by setting the
# doRemoteCmdFallback value to "2".
#
if {"windows" == [GetPlatform platform]} {
	set alfConfig(doRemoteCmdFallback)  0
} else {
	set alfConfig(doRemoteCmdFallback)  1
}
set alfConfig(RemoteCmdFallbackCommand) {rsh %h -n}
set alfConfig(RemoteCmdFallbackStatus)  {; if ($status) echo ALF_EXIT_STATUS $status}


# ------------------------------------------------
# The localDomain setting is used primarily to ensure that
# http-mode URLs and authentication cookies are generated
# for the correct domain.  If you specify a domain here,
# e.g. "pixar.com", then it will be used in all URLs. If you
# use an empty string, then nameserver results will be used
# directly, which are often already fully qualified at many
# sites.  Use the string "?" to indicate that alfred should
# guess at the domain name using some heuristics.
#
set alfConfig(localDomain) {}


# -----------------------------------------------
# allowHTTP - 1=allow, 0=deny - connections from http clients.
# Specifies whether web browsers are allowed to connect to dispatchers
# and the maitre_d to get job status.
# IMPORTANT: use of this feature should be carefully considered since it
# can expose sensitive job information and images (files) to "the web".
# Access is controlled using basic HTTP passwords for user authentication
# (this is the only scheme supported by all browsers), and therefore there
# is some risk that someone monitoring the transactions could also gain
# access. As usual, there is significantly less risk if everything is
# behind the same firewall.
#
# If this mode is enabled, alfred dispatchers function as web servers,
# generating html job status updates; this operation is completely
# independent of any other http server.  Browsers initially connect to
# the maitre_d which maintains redirection links to the active dispatchers.
# Hence, users need easy access to the current maitre_d's URL; typically a
# site might establish a link on a common homepage pointing to the maitre_d,
# the href should be in this form:  http://maitredHost:maitredPort
# e.g.  <a href="http://blink.batcave.org:9000">Current Alfred Jobs</a>
# See also the discussion of dispatcher passwords (authHTTP) below,
# and if fallback maitre_d's are in use, consider installing the provided
# maitre_d.cgi script under the normal site http server.
#
# The httpImgRoot parameter defines the restricted path for http image
# retrieval. Alfred dispatchers will make finished frames available to
# web browsers under certain circumstances (chaser cmd = "sho filename"),
# but only if the first part of the image file's real path matches this
# string. Use "-" to disallow image retrieval altogether. Note that for
# this scheme to work, renderers etc must be made to cooperate (i.e. their
# output destination must lie within the restricted path).  Using "/" is
# the most general setting, giving access to all files; hence, it is also
# the least secure configuration since it essentially allows arbitrary
# files to be sent to browsers as images.
#
set alfConfig(allowHTTP) 0
set alfConfig(httpImgRoot) "-"

# ----------------------
# wranglerPassFile is the -name- of the file which contains the
# encrypted "wrangler password". This password is used to establish http
# session "cookies" which allow the alfred equivalent of superusers to get
# http access to every user's job queue (via the web browser interface). If
# the filename below is the empty string, or if the named file doesn't exist
# or is zero-length then access is denied. To set up the file initially,
# use touch(1) to create an empty file, then run "alfred -wpasswd" to set
# the initial password (or change it). The file needs to be writable by
# users who are allowed to set/change the password; it needs to be readable
# by the maitre_d process and those users who will be starting dispatchers
# (the cookie is authenticated on every connection to a dispatcher).
# If the filename doesn't begin with "/" then it is assumed to be relative
# to the directory containing the alfred.ini file.  NOTE: forward-slashes
# should be used in all cases, even for absolute paths on Windows NT.
#
# wranglerDisplayMode determines the default display format for
# dispatcher entries; valid modes are "summary" and "unrolled".
# Summary mode is identical to the normal (non-wrangler) listing
# which shows each dispatcher's user name and a tally of waiting,
# active, and done jobs. Unrolled mode lists all the individual
# jobs on each dispatcher and provides pull-down menu commands to
# pause, reorder, or delete each job and change its priority.
#
# wranglerIdleFilter determines the default number of dispatchers
# which are displayed to wranglers. If set to {all} then all running
# dispatchers are displayed. If a time value is given, such as {1 day}
# then only dispatchers which have been active within the given period
# will be displayed, idle dispatchers are listed on a separate page.
# Valid units are: seconds, minutes, hours, days (or a unique
# abbreviation), for example {2.5 hours}.
#
# timerWranglerMode is the timeout interval, in hours, for a single
# wrangler-mode session. When the privileges expire for a particular
# browswer they can be restored by simply resubmitting the wrangler
# password on the 'About Alfred' html form.
#
# the wranglerNewWinLinks setting controls whether new browser
# windows are created by default when a job or dispatcher link is
# followed from the main wrangler web page; use 0 to turn them off.
#
# allowServerShutdownEjects controls whether or not the maitre-d 
# will take special action when an alfserver is shutdown while it
# still has active tasks.  If the value is '1' then the maitre-d
# will attempt to requeue those tasks on other servers, otherwise
# the dispatchers will likely flag the server task shutdowns as
# errors (which might be appropriate in some circumstances).
#
set appPaths(wranglerPassFile) {}
set alfConfig(wranglerDisplayMode) {unrolled}
set alfConfig(wranglerIdleFilter) {all}
set alfConfig(timerWranglerMode) 24
set alfConfig(wranglerNewWinLinks) 1
set alfConfig(allowServerShutdownEjects) 1

#-----------------------
# rshForDispatcherDiscovery controls how dispatcher control-ports
# are determined by alfred UI processes, when connecting to a remote
# dispatcher using 'alfred -h user@host'.  These port numbers can not be
# hard-coded as a "well-known service" because there can be dispatchers
# for multiple users running on the same host; while rare, this situation
# requires more than one unique port to be active at once.  If there is
# a site-wide maitre-d process running, the UI can contact it and ask
# for the given dispatcher's port, since these are registered with the
# maitre-d.  Otherwise, given that one dispatcher-per-host is common, an
# attempt is made to connect to port 9001 which is the dispatcher default.
# Somewhat stronger validation of remote UI connections can be achieved
# by enabling rshForDispatcherDiscovery.  This option causes the UI to
# use rsh to execute a command on the target remote host in order to
# retrieve the dispatcher's port.  The rsh itself acts as a kind of
# authentication check since the UI owner must have login access on
# the remote system.  Also see the userPrefs(accessControl) details.
#
set alfConfig(rshForDispatcherDiscovery) 0

#-----------------------
# Site 'directory service' queries
# to be tried initially to enumerate users, groups, hosts;
# these are typical queries appropriate for many unix systems.
# These commands are executed in a subshell, stdout is assumed
# to have one item per line.
#
set alfConfig(enumerateUsers) "ypcat passwd"
set alfConfig(enumerateGroups) "ypcat group"
set alfConfig(enumerateHosts) "ypcat hosts"


#-----------------------
# prebuilt server host enumeration
# Normally when the "Master Schedule" editor is invoked, alfred
# attempts to automatically acquire a list of candidate server
# hosts using a combination of built-in mechanisms.  These include
# 'ypcat hosts' and simply reading the contents of /etc/hosts.
# On some systems this can be a very time consuming process, and
# it can also generate lists which include a lot of inappropriate
# machine names.  You can create a predefined list of appropriate
# server machines for alfred to use.  Place the hostnames in a file,
# one per line, and specify the filename here (then uncomment the
# line below).  If this item is defined (uncommented) then it
# will override the "enumerateHosts" item above!  If you have
# a prebuilt file, consider just using "cat filename" or similar
# as the enumeration method above.
#
# set appPaths(prebuiltHostnameFile) {file_name}


# ------------------------------------------------
# The various alfreds communicate on TCP/IP sockets, the only port
# number which needs to be "well-known" is the maitre_d service
# request port. When dispatchers are started, and there is a maitredHost
# defined above, they communicate with the maitre_d daemon on this port.
# This is also the port that http clients (i.e. web browsers) connect to
# when they're looking for alfred updates. Also NIMBY alfreds register
# their shielding and get job announcements on this port. The dispatchers
# and UI's also use sockets to communicate, but they use temporary ports
# generated by the kernel at runtime; when a remote UI needs to connect
# it finds the dispatcher's current port number in a runtime lockfile
# called /tmp/.alfdp.user on the dispatching host.
# see also: inetd(1), <netinet/in.h>, /etc/services
#
set alfConfig(maitredPort) 9000


#-----------------------
# Metrics reporting and automatic maitre-d discovery,
# multicast vs unicast metrics, and multicast "TTL" (hop count). 
#
# Alfserver and the alfred maitre-d "find" each other on the network
# using multicast packets addressed to a particular multicast address.
# Routers on the network ensure that these packets are delivered to
# all "subscribed" systems.  By default alfred and alfserver use
# 239.255.224.99, port 9002/udp, for multicasts.  Sites can change
# this multicast address by adding the hostname "alf-status" to the
# site nameserver (e.g. DNS, NIS, /etc/hosts, etc), and picking an
# appropriate multicast address for it from the multicast range
# (224.0.0.0 - 239.255.255.255).  Note that there are IANA numbering
# conventions which apply to multicast addresses.
#
# Alternatively, conventional "unicast" communications can be used.
# Rather than creating a hostname entry for "alf-status" with an
# address from the multicast range, you can instead simply add
# "alf-status" as an alias for the maitre-d host's regular IP
# address.  The alfserver metrics will be sent as standard UDP
# packets directly to the named maitre-d.  Note that this approach
# should not be used with fallback maitre-ds, since alfservers
# would only be able to locate the one named host, and metrics
# would only be delivered to that one host.
#
# By default, given a multicast address, alfservers will use multicast
# to discover the current maitre-d, but then use unicast to actually
# deliver the metrics updates to one maitre-d at any given time.
# Alternatively, "SetPref metricsDelivery {multicast}" can be used to
# force metrics to be sent back to the multicast address so that any
# other interested listeners can receive them simultaneously; note that
# this was the default behavior prior to the 6.5 release.
# 
# Some notes on multicast routing:
# Routers typically do *not* forwarded multicast packets between subnets,
# by default.  Hubs and switches are usually oblivious to the packet type,
# although a few sites report that excessive multicast traffic can degrade
# the performance of some smarter switches due to the one-to-many nature
# of multicasting.  As for routing among subnets:
#
#    (from http://www.isl.org/EIES/mbone/mbone27.htm)
#    Time-To-Live (TTL) for Multicast Packets
#    The IP multicast routing protocol uses the Time To Live (TTL) field
#    of IP datagrams to decide how "far" from a sending host a given
#    multicast packet should be forwarded. The default TTL for multicast
#    datagrams is 1, which will result in multicast packets going only to
#    other hosts on the local network. A setsockopt(2) call may be used to
#    change the TTL.  As the value for TTL increases, routers will expand
#    the number of hops they will forward a multicast packet.
#
# The default alfred TTL setting is 1, you should increase it
# by small increments if alfservers on one subnet can't see a
# maitre-d on another subnet.  NOTE: typically this change needs
# be made in both alfred.ini AND alfserver.ini, you can use
#   SetPref MulticastTTL 2      in both files.
#
SetPref metricsAddr {alf-status} ;# defaults to 239.255.224.99, see above
SetPref metricsPort {9002}
SetPref metricsDelivery {unicast}
SetPref MulticastTTL 1

#-----------------------
# dispatcher event timeout (seconds)
# the dispatcher checks for task status and launch opportunities
# as old tasks complete, but it will only wait at most this long
# before it checks proactively anyway
#
set alfConfig(timerDispatchCheck) 15

#-----------------------
# Maitre-d sync delay
# number of seconds that a restarted maitre-d should wait before
# allocating new slots; this should be long enough to allow all
# running dispatchers to register their current slot usage with
# the new maitre-d.
#
set alfConfig(timerMaitredInitialWait) 20

#-----------------------
# Dispatcher done job maintainence timeout
# number of MINUTES that a dispatcher waits to shutdown after all
# jobs on the local queue are Done, and all UIs have disconnected.
# Helps reduce the number of unused dispatchers on the network,
# and also frees up licenses.  Use zero to indicate "never timeout".
#
set alfConfig(timerDoneJobDispatchExit) 0

#-----------------------
# maximum allowed shielding period (seconds) for alfred -nimby
# If a host is enabled in the alfred.schedule it was "meant" to be used as
# a server, users sitting at the console can run the not-in-my-back-yard
# UI (aka nimby) which temporarily blocks dispatching to their host until
# they've been idle for "a while" - which is defined to be the shorter of
# the period specified here and the current screensaver timeout (as reported
# by xset).  The idea is that a host will always be dispatchable unless a
# logged-in user is running alfred -nimby, and even then it will be made
# available while the screensaver is running; this number just overrides
# someone who is idle but has set an absurdly long screensaver timeout,
# or turned it off. The host will remain shielded if they're moving the
# mouse, this is just the maximum time it remains shielded when idle.
# 
set alfConfig(timerNimbyMaxShield) 3600

#-----------------------
# acceptable communication lag (seconds)
# synchronous (socket) communication between
# the various alfred components should block
# for this long before deciding there's a problem.
#
set alfConfig(timerNetworkLag) 60

#-----------------------
# automatic temporary avoidance of hosts which are having "trouble"
# these settings specify the number of seconds that the host slots
# should be avoided during slot assignment before retrying them again.
#
#   timerAvoidNoRoute - host was unreachable (shutdown or off the network),
#                       or its name wasn't found in the nameserver database
#   timerAvoidNoListener - host was found, and up, but alfserver doesn't
#                       appear to be listening on the expected port(s).
#   timerAvoidTooBusy - host is up and alfserver is responding, but
#                       the system is too busy to accept additional work.
#   timerAvoidRecentErrors - a command recently dispatched to the host
#                       encountered some kind of run-time error.  Since
#                       errors are usually due to data problems and are not
#                       host-specific, you may NOT want to momentarily make
#                       a host unavailable to everyone just because one task
#                       had an error, in which case set this value to "0".
#                       However, a short delay can be very useful because it
#                       allows auto-retries to move to a different available
#                       host, which might just allow the task to run.  Also
#                       see the 'autoAvoidServerErrors' user preference which
#                       allows users to automatically disable these hosts in
#                       the job's huntgroup when too many errors occur.
#
set alfConfig(timerAvoidNoRoute) 60
set alfConfig(timerAvoidNoListener) 30
set alfConfig(timerAvoidTooBusy) 10
set alfConfig(timerAvoidRecentErrors) 10

#-----------------------
# time-to-live (sec) for entries in the maitre_d queue
# dispatchers who need hosts when none are available are put on a
# queue maintained by the maitre_d, if the dispatcher fails to ask
# for the host again within this interval, its position times out
# and it goes to the end of the queue on its next request.
#
set alfConfig(timerMaitredQueue) 120

#-----------------------
# alwaysDoJobCleanup: determines whether job-level cleanup commands
# are run for jobs that have never been active.  If set to '1' then
# all job-level cleanup command will be run when a job is deleted,
# whether or not the job has been active.  This can be important
# for jobs that need to cleanup auxilliary files that were created
# when the job was spooled, such as RIB files, frozen copies of
# models, etc etc.  If set to '0', then the cleanups only run when
# a job has been active, which is sensible only if the temporary files
# used by ALL jobs are created by the jobs themselves.
#
set alfConfig(alwaysDoJobCleanup) 1

#-----------------------
# timerJobSweepGracePeriod - task delete escalation grace period (seconds),
#     when a job is deleted, running tasks must be stopped;  a series of
#     increasingly severe mechanisms are used to kill running processes.
#     First the process stdin is disconnected, then SIGTERM is sent to
#     the process, then SIGKILL is delivered.  This timer controls how
#     long alfred should wait between shutdown attempts for the process
#     to exit before escalating the severity.  The first number is
#     the interval between stdin-disconnect and SIGTERM, the second is
#     the interval between SIGTERM and SIGKILL.
# timerCleanLimit - exit grace period for clean-up commands (seconds),
#     when a job is deleted (or a task is restarted) the clean-up
#     commands of nodes on active paths are run. If a clean-up 
#     command takes longer than this interval it is actively killed
#     and the clean-up continues.
#
set alfConfig(timerJobSweepGracePeriod) {2 5}
set alfConfig(timerCleanLimit) 15

#-----------------------
# set the name of the executable to use when alfred
# is handed "*.rib" to render. The string below can
# contain the following "variables":
#  %f - will be replaced with a RIB file name
#  %h - will be replaced with a hostname list, e.g. "tinker tailor soldier"
#  %H - will be hostnames in "netrender" format:    "-h tinker -h tailor"
#
# (note: the length of the hostname list is determined by the -n option
#  to alfred; it defaults to one remote host.)
#
set alfConfig(autoRenderCmd) "Cmd {netrender -f -Progress %H %f} -service {pixarNRM|nrmserver} -tags {prman}"

# ------------------------
# where should alfred look for the programs it launches
# (such as netrender, etc). If forcePath is 1, it first looks in the
# same directory as the running alfred executable, then it uses the
# rest of the current path; if 'forcePath' is 0, then it just uses
# the path as is, (which would allow users to have override versions
# of the apps launched by alfred)
#
set alfConfig(forcePath) 0

#
# misc. settings, these aren't likely to be changed:
#  - rmJobsInSpoolDir:  1 or 0, should deleted jobs be deleted?
#  - cmdlogFsize:       font size used in the job-queue command log,
#                       choices are: small, list, delicate, default, bold
#  - slotLoggerMode:    either "application" or "title" for mtd logs
#
set alfConfig(rmJobsInSpoolDir) 1
set alfConfig(cmdlogFsize) small
set alfConfig(slotLoggerMode) "application"


# ------------------------------------------------------------------------
# Limits and Pings
# ------------------------------------------------------------------------
# note - as of V3.0 these have been moved to the alfred.schedule file.
# 'Limits' control the  number of simultaneous launches, by command type;
# 'Pings' are service-specific queries used to determine if a server is
# really ready for new work. See the documentation for details.
# ------------------------------------------------------------------------

# policyLocalLimits is used to determine how "local limit" counts are
# interpreted.  The possible settings are "location" or "owner".
# The default setting (location) means that "local" limit counts restrict
# the number of processes which the dispatcher will launch on its own
# (local) host simultaneously.  This is typically used for things like
# limiting the number of MTOR rib-generators that are running at one time
# on the user's local system.  However, an alternate interpretation is also
# available.  The setting "owner" means that the limit counts should be used
# to restrict the number of commands originating from any one dispatcher,
# whether running locally or on REMOTE servers.  The "owner" setting can
# be used to enforce the policy that a single user (dispatcher) should
# only consume a fixed number of licenses of a certain type, irregardless
# of whether their processes are running locally or remotely.
#
set alfConfig(policyLocalLimits) "location"

# -------------
# The preemption trigger determines whether the (default)
# maitre-d assigner DSO will attempt to do preemption, and if so
# it determines which running tasks are preemptable by others.
# A zero or negative values to indicate that preemption
# should NOT be attempted.  When a positive value is given,
# jobs whose priority is greater than other jobs by the given
# amount will potentially preempt the lower priority jobs.
# When tasks from a lower priority job are preempted, they
# are interupted and then restarted when slots become available.
# Since priority values are arbitrary site-defined floats,
# the trigger value should sensible for typical site job priorities.
# For example, if jobs are typically spooled with a priority of
# 1.0, and "rush" jobs are spooled with 50, then a trigger of
# 100 might be used so that "super rush" jobs of priority 101
# would preempt regular jobs but not rush jobs.   Note: this
# value is used by the default assigner as described, sites may
# have their own custom assigner DSO which ignores this setting
# or treats it differently.
#
set alfConfig(preemptionTrigger) 100



# ------------------------------------------------------------------------
# Preferences
# ------------------------------------------------------------------------
# the remaining settings affect dispatching behavior or the
# display format of the UI, they are the things most likely
# to be changed by individual users (and they are the only
# settings saved in each user's ~/.pixarPrefs/alfred.prefs file)
#
# The most important settings here can be customized by users
# using the Session->Preferences dialog from the UI.
#
# Use the keyword 'LOCK' instead of 'set' to disallow
# per-user changes of these settings; for example:
#   LOCK userPrefs(waitforMaitred) 1
#

#-----------------------
# Controlling access to "heavy-weight" items on the Scheduling menu.
# At some sites it is appropriate to disable access to the functions
# provided by the "Watch Servers" and "Master Schedule" menu items
# in the Alfred user interface.  The "Watch Servers" interface can
# put a large load on the maitre-d when a site has a lot of servers
# to monitor, and it is largely replaced by the "BatCave" interface.
# Enable with "1", disable with "0".
#
set alfConfig(menuItemWatchServers) 1
set alfConfig(menuItemMasterSchedule) 1

#-----------------------
# verbose - should various status messages be printed to the console?
#
set userPrefs(verbose) 0

#-----------------------
# restrict available remote servers:
# the maitre_d will use the scheduled Crew definitions to find
# all of the servers that a user can access 'now';  users can
# choose to further limit their target pool by explicitly choosing
# services to avoid (by deselecting them in the huntgroup UI).
# The preferences value is inherited by newly spooled jobs, however
# a per-job huntgroup is also maintained, and is user editable, so
# that different jobs may have different run-time huntgroups.
# (note: this kept as an 'avoid' list rather than the more obvious
# direct list of available servers so that dispatchers will automatically
# have access to new servers as they are added; and typically this will
# be the shorter of the two lists.)
#
set userPrefs(avoidServers) {}


# ----------------------
# some behavior tuning params
#
# autoDiscardKeep: integer count of successfully -completed- jobs to keep on
#                  the displayed job queue.  The dispatcher automatically
#                  discards old done jobs, but will retain the specified number
#                  of recently done jobs so users can browse status and logs.
#                  Use "-1" to prevent any auto-discards.  Use "0" (zero) to
#                  indicate that "no done jobs should be kept", meaning that
#                  jobs will be deleted as soon as they are done.
# autoDiscardOnClose:  should remaining -done- jobs be automatically
#                  discarded when the Alfred UI is closed?
#
# dispatchScheme:  dispatching mode affecting primarily -multiple- local jobs
#                  values are: sequentask, sequential, spillover, parallel.
#                  See the dispatching.html document.
# pauseOnError:    if an error occurs during processing,
#                  should the entire job pause, or continue with
#                  all tasks unaffected by the error?
# priorityBias:    the bias added to the crew defined server priorities
# maxTaskOutput:   maximum number of task output records to be saved, per task,
#                  use zero to mean unlimited.
# maxTaskRetries:  how many times should tasks with errors be automatically
#                  restarted before the error is considered 'real'
# jobWhenError:    a shell command executed whenever an error occurs
# jobWhenDone:     a shell command executed when a job successfully completes
#
# autoAvoidServerErrors:  how many errors on a particular server should be
#                  allowed before that server is automatically removed from
#                  a job's huntgroup.  Use zero to disable auto-avoidance.
#                  See also the maitre-d 'timerAvoidRecentErrors' setting above.
#
# timerErrWaitExpire:  time, in hours, before jobs stalled in "Error-Wait"
#                  state are automatically deleted.  Set to 0 to disable any
#                  automatic deletion.  Error-wait state occurs when a job is
#                  unable to proceed because all remaining tasks are blocked
#                  waiting for dependent tasks which have errors.
# expandWalkAhead: certain types of commands generate additional task nodes,
#                  (Iterate and Cmd -expand). Since these commands often result
#                  in additional side-effects such as RIB generation, this
#                  parameter is used to gate the generation of new tasks based
#                  on the number of already existing ready-to-execute tasks.
# waitforMaitred:  if a maitre_d host is defined but not responding
#                  should this dispatcher wait for it to respond or
#                  just run in 'chaos' mode without global state info?
# useEtaHistory:   select whether time estimates depend on the
#                  per-task timing history of previous jobs
#
set userPrefs(autoDiscardOnClose) 1
set userPrefs(autoDiscardKeep) 5
set userPrefs(dispatchScheme) {spillover}
set userPrefs(priorityBias) 0
set userPrefs(pauseOnError) 0
set userPrefs(jobWhenError) ""
set userPrefs(jobWhenDone) ""
set userPrefs(maxTaskOutput) 0
set userPrefs(maxTaskRetries) 0
set userPrefs(autoAvoidServerErrors) 0
set userPrefs(timerErrWaitExpire) 0
set userPrefs(expandWalkAhead) 5
set userPrefs(waitforMaitred) 1
set userPrefs(useEtaHistory) 1
set userPrefs(etaHistory) {}


#-----------------------
# user-access control list, in addition to ~/.rhosts,
# determines which users may attach a controlling UI to
# a running dispatcher; the owner has view + control access.
# e.g.
#  {
#    batman@batcave.org
#    robin@tahoe.fun
#  }
#
set userPrefs(accessControl) {}

# set the default www authorization string (for access to dispatchers);
# if empty: disallows connections from browsers until each user has
# explicitly set their access password (in the preferences editor);
# Any other string is treated as www-basic-authentication (another
# scheme might be used later).  Since users change their access
# individually, this string should be left empty at the site config level.
# The special value {*} causes password checking to be skipped,
# and should be used -very- cautiously.
#
set userPrefs(authHTTP) {}

#
# some ui tuning parameters
#
set userPrefs(rememberWinGeom) 1
set userPrefs(lastWinGeom) "550x300+75+75"
set userPrefs(dagGeoms) {}
set userPrefs(showCmdLog) 1
set userPrefs(allJobsOpen) 0

# note that color names are defined by the X-server, see showrgb(1);
# colors can also be specified explictly in hex as "#RRGGBB"
#

if {"windows" == [GetPlatform platform]} {
	set userPrefs(activeTaskColor) mediumseagreen
	set userPrefs(infoColor) blue2
	set userPrefs(warnColor) midnightblue
	set userPrefs(fadeColor) gray80
	set userPrefs(selectedColor) gray65
	set userPrefs(percentDoneColor) gray80
	set userPrefs(enableColor) SystemWindow
	set userPrefs(errorColor) orange2
	set userPrefs(textbgColor) #FFFFE0

	set userPrefs(boldFont)     "{MS Sans Serif} 10 bold"
	set userPrefs(defaultFont)  "{MS Sans Serif} 8"
	set userPrefs(delicateFont) "{MS Sans Serif} 6"
	set userPrefs(listFont)     "Courier 9"
	set userPrefs(smallFont)    "Courier 8"
} else {
	set userPrefs(activeTaskColor) mediumseagreen
	set userPrefs(infoColor) blue2
	set userPrefs(warnColor) midnightblue
	set userPrefs(fadeColor) gray80
	set userPrefs(selectedColor) gray65
	set userPrefs(percentDoneColor) gray80
	set userPrefs(enableColor) goldenrod2
	set userPrefs(errorColor) orange2
	set userPrefs(textbgColor) cornsilk2

	set userPrefs(boldFont)     {-*-Helvetica-bold-r-normal-*-14-*-*}
	set userPrefs(defaultFont)  {-*-Helvetica-medium-r-normal-*-14-*-*}
	set userPrefs(delicateFont) {-*-Helvetica-medium-r-normal-*-12-*-*}
	set userPrefs(listFont)     {-*-Courier-medium-r-*-*-14-*-*}
	set userPrefs(smallFont)    {-*-Courier-medium-r-*-*-10-*-*}
}


# ----------------------
# maitredHost - Hostname of the maitre_d server, the centralized alfred
# resource coordinator. If defined as the empty string {}, each dispatcher
# will manage its own service allocation, which produces mild anarchy for
# networks with multiple dispatchers racing for the same servers, but
# is probably preferable when only one dispatcher is in use at a time.
# Note: if a host is named here (non-empty) then someone must start
# "alfred -maitre_d"  on that host before dispatchers are started.
# If several hosts are listed here, as in {host1 host2 host3}, then
# the hosts will be tried in sequence; also, if the primary maitre-d
# host becomes unavailable, dispatchers connect to the next available
# fallback system (if the primary returns to service, all connections
# will move back to it).  Note: a maitre-d process must be already
# running on the fallbacks, they are (typically) not started on demand.
#
set alfConfig(maitredHost) {}

# ----------------------
# documentation links to display in the Help menu. see also RAT.ini
#
set appPrefs(HelpURLs(alfred)) {
    "Alfred Documentation" %RATDOCROOT/programmingRAT/alfred/
}