localconfig.yml.defaults

---
#### OVERVIEW ####
# You can customize your deployment by making a copy of this file called
# localconfig.yml and customizing the settings in it.
#
# In many cases, you will only want to change the site and instance
# names in the vars section. 
#
# This provisioning system is basically a front-end to Ansible. 
# If you want to learn more about how things work, start with our
# setup doc if you haven't already read it:
#   https://github.com/tunapanda/provision/wiki/Setup
#
# And then read the Ansible docs if you want more:
#   http://docs.ansible.com
  

#### DEBUG ####
# Amount of debug output to print.
# Set to 0 (normal) - 3 (lots)
#
debug: 0


#### PLATFORM ####
# Platform describes the hardware to which you will be deploying.
#
# You can manually set it to anything represented by one of the 
# `playbooks/group_vars/platform_NAME` files, like `cubietruck` or `vm`,
# but the provisioning script will set this automatically if you are
# it is run on a cubietruck or by Vagrant, so you can usually leave it
# set to "auto".
#
platform: auto


#### PROFILE ####
# A profile defines collections of server roles that are frequently 
# installed together. 
#
# You can set this to any name represented by one of the
# `playbooks/NAME.yml` files (only use the `NAME` part in the setting). 
# If the profile has special default settings, they will be stored in 
# `playbooks/group_vars/NAME`, with global defaults in 
# playbooks/group_vars/all`. These can be overridden in the `vars` 
# section below.
#
# Common values include:
#   "classroom_server" = a web server with a portal page that provides
#   access to lots of educational content. If you want this to include
#   larger resources like offline versions of wikipedia and khan
#   academy lite, set wikipedia__enabled and/or kalite__enabled
#   in the vars section below.
#
#   "swag_dev" = A dev environment for the Swag learning management
#   tool, including the Learning Locker LRS. Also see provision__data_dir
#   in the vars section.
#
#   "dynamic" = automatically (re-)generate `playbooks/dynamic.yml`,
#   which applies any server role enabled in the vars section below.
#
profile: classroom_server


#### ANSIBLE VARS ####
# You can fine-tune settings here. 
# Most sever roles have settings defined in:
#
#     playbooks/roles/*/defaults/main.yml
#
# These can be overidden by the global defaults defined in:
#
#     playbooks/group_vars/all
#
# ...which in turn can be overriden by profile or platform 
# settings in the other file in group_vars/.
# 
# The commented values below represent global defaults for
# some (but far from all) of these settings.
#
# If you uncomment and customize a setting here, it will override
# everything else.
#
vars:
  ## SITE AND INSTANCE NAMES ##
  # The following two settings are the only ones you should always
  # customize before deployment. They define a unique DNS domain, usable
  # only by clients that use this server for DHCP, that is used to offer
  # services from this device. They should be customized for your
  # Deployment.
  #
  # After provisioning, this device will be accessible to anything that
  # uses it as a dhcp server at the following name (read on for details):
  #
  #   $provision__instance.$provision__domain
  #
  # And services will be available at names like
  #
  #  edx.$provision__instance.$provision__domain

  # Uncomment and set the instance name to a short, one-word description of 
  # your organization or location. For example, Tunapanda Institute might use "ti". 
  # Shorter is better in case someone has to type the url manually!
  #
  # If you have multiple instances within the same site or organization,
  # consider using instance names like "room1.mysite", "room2.mysite", etc.
  #
  # If unset, the default value will be derived from the platform
  # and/or profile settings above. When provisioning completes, it will print
  # a message with the hostname.
  #
  #provision__instance: "mysite"

  # The domain should be the domain of your organization, or
  # you can use the "t" (as in "test") subdomain of x2go.co.
  #
  #provision__domain: "t.x2go.co"

  ## NETWORKING ##
  # By default the provisioning system assumes that `eth0` is your 
  # internal interface (the one connected to the local network) 
  # and does not otherwise touch your network config. You can change
  # what the internal interface is, and/or configure an external interface
  # (the one connected to the Internet, if you are provisioning a
  # gateway machine), and/or change the IP address assigned to either.
  # See the templates in the `networking` role for details.
  #
  # For example, to make eth1 the internal interface, assigned a static IP, 
  # and eth0 the external interface using DHCP, you would do the following...
  #
  #provision__internal_interface: 
  #  stat: "{{ ansible_eth1 }}"
  #  address: "10.0.0.1"  # drop this if you don't want to change the address
  #provision__external_interface:
  #  stat: "{{ ansible_eth0 }}"
  #  address: "dhcp"
  #
  ## The settings above just identify internal/external interfaces for
  ## services that need to know about them. This tells provisioning to
  ## actually take over their configuration.
  #network__interface_configs:
  #  - provision__internal_interface
  #  - provision__external_interface
  #

  ## MODULES DIRECTORY (probably only relevant for VMs) ##
  # By default, VM deployments store most of the important content
  # in the `modules`  subdirectory of wherever you cloned this repo.
  # In other words, content is stored on the host system and shared
  # back to the VM. This makes it easier to work on code or other
  # changes without having to open a shell on the VM. However,
  # all files are shared with write privileges to get around limitations
  # in how the shared filesystem handles permissions, which may cause
  # some software to misbehave. Uncomment the line below to store
  # content in the default location (/usr/local/tunapand/data), 
  # which is on the VM's local filesystem.
  #
  #provision__data_dir: "{{provision__base_dir}}/modules"