# This is a configuration file for the Taskr RESTful scheduler daemon.
# AN IMPORTANT NOTE ABOUT YAML CONFIGURATION FILES:
# !!! Be sure to use spaces instead of tabs for indentation, as YAML is very
# !!! sensitive to white-space inconsistencies!
##### HTTP SERVER ##############################################################
# Under what HTTP environment are you running the Fluxr server? The following
# methods are currently supported:
#
# webrick -- simple stand-alone HTTP server; this is the default method
# mongrel -- fast stand-alone HTTP server; much faster than webrick, but
# you'll have to first install the mongrel gem
#
### webrick example
server: webrick
port: 7007
### webrick SSL example
#server: webrick
#port: 443
#ssl_cert: /path/to/your/ssl.pem
# if the private key is separate from cert:
#ssl_key: /path/to/your/private_key.pem
### mongrel example
#server: mongrel
#port: 7007
# It is possible to run mongrel over SSL, but you will need to use a reverse
# proxy (try Pound or Apache).
##### DATABASE #################################################################
# Taskr needs a database to persist its state between restarts.
#
# By default, we use MySQL, since it is widely used and does not require any
# additional ruby libraries besides ActiveRecord.
#
# With MySQL, your config would be something like the following:
# (be sure to create the taskr database in MySQL beforehand,
# i.e. `mysqladmin -u root create taskr`)
database:
adapter: mysql
database: taskr
username: root
password:
host: localhost
# Instead of MySQL you can use SQLite3, PostgreSQL, MSSQL, or anything else
# supported by ActiveRecord.
#
# If you do not have a database server available, you can try using the SQLite3
# back-end. SQLite3 does not require it's own server. Instead all data is stored
# in local files. For SQLite3, your configuration would look something like the
# following (don't forget to install the 'sqlite3-ruby' gem first!):
#
#database:
# adapter: sqlite3
# dbfile: /var/lib/taskr.db
##### AUTHENTICATION ###########################################################
# Taskr supports two methods for authentication: Basic HTTP and CAS.
### Basic HTTP Example
# Uset the following if you want Taskr to demand a username and password from
# the user using basic HTTP authentication clients. Note that this isn't very
# secure unless you run Taskr over HTTPS (see the webrick SSL example above).
#authentication:
# method: basic
# username: taskr
# password: task!
### CAS Example
# Use the following if you want Taskr to demand a username and password using
# Single Sign-On CAS (Central Authentication System). For more information on
# CAS see http://code.google.com/p/rubycas-server/.
# The cas_base_url setting should be the URL of your CAS server.
#authenticatoin:
# method: cas
# cas_base_url: https://login.example.foo/cas
##### LOGGING ##################################################################
### System Log
# This is the general server log where Taskr writes information about web requests.
# You'll want to look here if you encounter general problems with Taskr's
# operation. Do not confuse this log with the task log, which records information
# about the various schedules jobs. The task log is kept in your database and
# is completely separate (see below).
#
# By default, we will try to create a log file named 'taskr.log' in the current
# directory (the directory where you're running taskr from). A better place to put
# the log is in /var/log, but you will have to run taskr as root or otherwise give
# it permissions.
#
# Set the level to DEBUG if you want more detailed logging. Other options are
# INFO, WARN, and ERROR (DEBUG is most verbose, ERROR is least).
log:
file: taskr.log
level: DEBUG
# file: /var/log/taskr.log
# level: INFO
### Task Log
# This is where Taskr records detailed information about your scheduled jobs (tasks).
# Every time a task is triggered, information about the execution is recorded
# in this log (i.e. whether the task executed successfuly, its output, etc.)
# The Task Log is stored in the Taskr database under the log_entries table.
#
# Here you can configure the logging level. The "INFO" level is generally a good
# choice for production systems, although you may want to keep this at "DEBUG"
# if you want to keep a close eye on your tasks -- this is a good idea
# especially when setting up a new Taskr system.
#
# Note that in order to prevent log data from accumulating indefinitely, you
# should set up a "RotateTaskLog" action in your Taskr server. This will
# delete old logs as per the parameters you provide (do this via the
# normal Taskr web interface as you would to set up any other task -- just
# select "RotateTaskLog" for the action).
task_log:
# ERROR, WARN, INFO, or DEBUG
level: DEBUG
### SNMP Traps
# Taskr can be configured to send out SNMP traps whenever task events occur.
# That is, in addition to logging task events to the Task Log (see above),
# Taskr can send out SNMP traps notifying an SNMP listener of the event.
# This functionality relies on the Net-SNMP package's `snmptrap` command-line
# utility, so make sure you have the PERL Net-SNMP installed on your system
# before enabling the following configuration options.
#snmp:
# send_traps: true
# to_host: snmp.example.net
# community: public
# enterprise_oid: 1.3.6.1.4.1.55555.7007
##### MISC #####################################################################
### Custom Task Definitions
# You can define your own task action behaviour by specifying an external ruby
# filename. On startup, Taskr will load any action definitions from this file,
# making them available when scheduling new tasks (you should see your custom
# task classes listed in the Actions pulldown on the new task page).
#
# Custom task definitions must:
# - be defined under the Taskr::Actions module
# - extend the Taskr::Actions::Base class
# - implement a 'execute' method (this is what will be executed when your
# action is triggered)
# - define a 'parameters' class attribute which should be an Array listing
# the names of the parameters that your action takes
# - define a 'description' class attribute which should provide a brief
# description for what your action does (this will show up in the web UI)
#
# Here is an example of a trivial custom action:
#
# module Taskr
# module Actions
# class MyCustomAction < Taskr::Actions::Base
# self.parameters = ['alpha', 'beta']
# self.description = "Multiplies the given parameters and prints the result to stdout."
#
# def execute
# puts parameters['alpha'].to_i * parameters['beta'].to_i
# end
# end
# end
# end
#external_actions: /path/to/file.rb
