Setup

Deployment

Overview

There are four ways in which the provisioning system might be used:

• Deploying to a vagrant-based VM
  • Best for development and testing, unless you need a non-x86 architecture
• Deploying to a cubietruck
  • x2go default for deployments to locations with no existing hardware, or power/space limitations
• Deploying to a commodity PC
  • Tunapanda default for deployments to locations that already have hardware
• Refreshing/reloading the config after deployment
  • Applies to all of the above methods
  • bootstrap.sh is run from /etc/rc.local at every boot (but skips most tasks if not net connection is detected)

Deploying to a vagrant VM:

1. Install vagrant and virtualbox
2. git clone --recursive https://github.com/tunapanda/provision

• Note: The --recursive is essential!

1. cd provision
2. vagrant up
3. To access the system, either:

• vagrant ssh (CLI only, no password required)
• A new VirtualBox window should appear during deployment. You can log in there with username teacher and password Tunapanda2. If you installed the GUI (see 'customization' below), you will have full desktop access here.

An important note about vagrant deployments: Normally, the deployment process clones the provision git repo into /usr/local/tunapanda/provision. In this case, you've already cloned the repo on your host system, so we can just use that. The Vagrantfile that controls the VM's behavior mounts the directory where you cloned the repo on your host as /usr/local/tunapanda/provision on the VM. This is why VM-based deployments can be very convenient for development. Just modify stuff in the repo and run vagrant provision to apply your changes.

Deploying to a cubietruck

edX requires several modifications to work on ARM. Thanks mainly to the hard work of Arturo Samanez, we have a prebuilt image of Lubuntu 13 with edX pre-installed. You will need to begin by using it to create an SD card from which to boot the cubie.

Note: these instructions require a Linux machine with a micro SD reader.

1. Determine the device name of your SD card (e.g. /dev/sdb). Try fdisk -l as root.
2. git clone -b edx_Lubuntu-13 https://github.com/iLearner/x2go.git x2go-arm
3. cd x2go-arm
4. python execute sd /dev/DEVICE_FROM_STEP_1

• This will destroy any data on the SD card

1. Boot the cubie from the SD

• sshd is not installed by default in this image (yes, we should fix that), so you will need to connect it to a keyboard and monitor the first time you use it.
• It should boot directly to a root prompt

1. apt-get install -y openssh-server
2. If your cubietruck has a SATA drive in it, do the following:
3. Identify the device name of the disk. * fdisk -l can help with this * On a cubietruck, the hard disk should be /dev/sda, and it should have a partition called /dev/sda1.
4. BE SURE YOU GOT THE RIGHT DEVICE NAME! The next step will destroy everything on it.
5. Format the disk and apply a label to identify it: * mkfs.ext4 -L TUNAPANDA_DATA /dev/sdX1 (replace X with the correct device name. the 1 means the first partition)
6. Follow the Commodity PC instructions below to install and run the provisioning system. It will automatically use a cubietruck-specific profile if it detects an ARM architecture
7. If your cubietruck does not have a SATA drive, you will not have enough space for much content. When you have installed a drive, you can follow these instructions to set it up.

Deploying to a commodity PC

Log in as root (or log in as another user and run sudo -i). Just using sudo isn't enough, because the ssh keys Ansible needs are stored in root's homedir. This should be fixed, but it's what we have for now.

sudo -i
cd /tmp
https://github.com/tunapanda/provision/blob/master/scripts/bootstrap.sh
bash bootstrap.sh  # add -x if troubleshooting

Customizing

First, a very brief overview of Ansible, the system we use to configure systems during deployment. You will need to understand at least three concepts: roles, playbooks, and profiles (roles and playbooks are ansible terms, profiles are specific to this provisioning system).

• A role describes how to deploy a specific service or machine type. Most of the roles we use can be found in playbooks/roles/. Well-written roles use variables instead of hard-coded values so their behavior can be customized without re-writing the role. Variables can be overridden in...
• A playbook describes a set of roles to load and (optionally) custom values for variables that control what they do.

Normally, the best profile is automatically chosen based on hardware architecture, etc, but if you want to (and you know what you're doing!), you can fine-tune things with a special profile called custom, and the localconfig.yml file. Note that this file does not exist by default, but you can create one using localconfig.yml.sample as a template, or using the following command, which will create a config file with all available settings set to their default values:

(echo "---" ; echo "groups: [ custom ]"; echo "vars:" ; for r in $(ls playbooks/roles/) ; do echo "" ; echo "  ## $r role" ; cat playbooks/roles/$r/defaults/main.yml | grep -v '^---' | grep -v '^[[:space:]]*$' | sed 's,^,  ,'; done) > localconfig.yml

Almost every role has a variable called role_name__enabled (note the double-underscore), which is usually set to false. For many customizations you will only need to change these settings, and can ignore the others.

When you've made your changes, simply run vagrant provision if you are using vagrant, or run /usr/local/tunapanda/provision/scripts/bootstrap.sh on other systems.

Creating an ISO

Note: this feature hasn't been tested much recently. If you encounter problems, please file an issue with information on how you used it and what went wrong

You can generate a bootable DVD of the provisioned system, which can then be used to demo or install a duplicate of the system elsewhere, by adding build_iso__enabled: true to your localconfig.yml.