Vagrant provisioning for BigSense/LtSense environments
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


vSense is a set of Vagrant environments and Ansible playbooks for building full BigSense and LtSense environments. vSense can also be used to replicate the build and repository servers use by the project for local development forks.


vSense depends on Vagrant 1.6+, Ansible 1.8+ and VirtualBox, as well as some additional vagrant plugins. Check your Linux distribution's package repository for installing Vagrant, Ansible and VirtualBox. Then run the following:

git clone
vagrant plugin install vagrant-hostmanager


Ubuntu 14.04 LTS doesn't have current versions of most of the dependencies we need.

# Install Vagrant 1.7

sudo dpkg -i vagrant_1.7.2_x86_64.deb

# Install packages

sudo apt-get install ansible virtualbox

# Install packages needed for security (optional)

sudo apt-get install whois pwgen

On Gentoo, you will need additional overlays:

# Install Vagrant 1.6+

sudo layman -a andy
sudo echo ">=app-emulation/vagrant-bin-1.6.1 ~amd64" >> /etc/portage/package.accept_keywords

# Install packages

emerge -av vagrant-bin ansible virtualbox

# Install packages needed for security (optional)

emerge -av whois pwgen

Creating a Runtime Environment

A BigSense environment consists of at least three virtual machines: a BigSense server, a database server and a LtSense client. In the Vagrant virtual environment, the LtSense client transmits data from fake virtual sensors (randomly generated data). vSense can be used to automate the process of building such an environment.

The vsense create command can be used to build an environment. In the following example, we'll create an environment called staging which uses a PostgreSQL database for storage, Ubuntu as the operating system and nightly builds of bigsense and ltsense:

cd vSense
./vsense create -d postgres -o ubuntu -s nightly staging

This will create the appropriate Vagrant files in virtual-env/staging. You can edit virtual-env/staging/environment.yml to fine tune your settings. If you have multiple environments, you must edit this file to ensure each environment gets unique IP addresses.

Next you can start the environment:

./vsense start staging

The Vagrant VMs start and the Ansible provisioning scripts will run. You may be prompted for your password as the vagrant-hostmanager plugin will need root privileges to update your /etc/hosts file. When finished, you'll have three VMs. The ltsense-staging VM will start transmitting randomly generated temperatures to the bigsense-staging VM. Assuming you're using the default environment.yml, you should be able to view the take sensor data by going to the following web address:


Congratulations. You now have a BigSense virtual environment. You can also setup a virtual environment with different operating systems and databases. vSense currently supports Ubuntu 14.04, Debian 7 and CentOS 7 (OS flags only affect the BigSense and LtSense VMs. The database VM will always be Ubuntu.)

# create a mysql environment that uses CentOS and nightly builds:

./vsense create -d mysql -o centos -s nightly centos-nightly-mysql

# create a postgres environment that uses debian and stable builds:

./vsense create -d postgres -o debian -s stable debian-stable-postgres

In a real deployment, LtSense would most likely be running on an embedded Linux system with actual sensors attached to it. Packages for BigSense and LtSense are available for many distributions. For full installation and configuration instructions, visit

Using a Microsoft SQL Server (Experimental)

BigSense does support a Microsoft SQL Server backend. Although Microsoft does provide Vagrant boxes for Windows Server 2012, they're only for the Hyper-V provider. For vSense using VirtualBox, you will have to manually create a Windows Server 2012 R2 box and name it Windows2012R2. Currently this functionality is missing from vSense and the -d mssql doesn't currently work. I hope to add this functionality in the future.

TODO: figure out how to auto-mount the SQL Server ISO and install via powershell and document it

Creating a Build Environment (advanced)

A build environment can be useful for developers who wish to fork the project and have their own build servers and local package repositories. Most end-users won't need to do this, but this may be useful for developers.

To start, lets' create a build environment using the following:

./vsense create -e build builder

The default configuration files generated point to the source code located on Github. You can adjust the environment.yml, prior to Vagrant provisioning, to change these locations to local repositories or github forks.

You can also fine tune various other settings in the environment.yml, including those for PGP key generation (used to sign packages). Prior to starting your build environment, you must generate PGP keys:

./vsense genkeys builder

Next, you can start the build environment:

./vsense start builder

You should now have two virtual machines: build and repo. By default, build runs a Jenkins instance that will poll the git repository every 15 minutes to determine if it needs to build new packages. You can start these jobs manually by going to http://build.internal:8080 and executing the BigSense and LtSense jobs.

TODO: insert screen shot

Finally, you can create a local runtime environment that pulls packages from the local build environment:

./vsense create -e run -d postgres -b builder staging

Keep in mind that Jenkins builds packages and publishes them to the appropriate repository tree based on their version numbers. If the current commit has a tag associated it which is a version number, the package will get published in stable. If the tag is a version number followed by characters (e.g. 0.5beta), it will be published in testing. If the current commit is past the latest tag, the package version will end in the short commit hash (e.g. 0.5beta-4-as4g3a) and will be published in nightly.

If the runtime environment is configured for a branch that doesn't have any packages published yet, it will fail to provision.

Infrastructure (advanced)

The Infrastructure environment is a special case for building an haproxy and wiki. It's used for the internal systems that host You probably don't need to build this unless you plan on hosting an entire BigSense organization of your own, or need your various environments accessible from the outside world.


By default, vagrant VMs are insecure. Their vagrant/root passwords are set to vagrant and they use a common, non-passphrase protected SSH key. The secure action can ensure vsense will automatically generate passwords, store those passwords in ~/.password-store and encrypt them with a pgp key (so they can be retrieved using the pass command).

Note that this will only protect new VMs or VMs that are re-provisioned via Ansible.

The secure action requires the following dependencies:

  • pwgen
  • whois (for mkpasswd)
  • pass (optional)

To automatically generate passwords and encrypt them, you must specify a PGP key ID that exists in your keystore.

./vsense secure -p 6D0D93B1

To use a custom SSH key for the vagrant user:

./vsense secure -s [path to ssh key]

Using libvirt+kvm/qemu (advanced)

Our production servers use libvirt+kvm/qemu instead of virtualbox. At a basic level, you need to change your vagrant provider and the boxes.

For the provider, set VAGRANT_DEFAULT_PROVIDER=libvirt in your current shell (or in your .bashrc file to presist across logins).

Then adjust the boxes in virtual-env/vsense.yml (you may need to create an environment first to create this file). You will need boxes that are designed for libvirt. Currently, only Ubuntu has been tested:

  ubuntu: baremettle/ubuntu-14.04

You'll also need to install the appropiate packages:

apt-get install qemu-kvm libvirt-bin libvirt-dev python-libvirt

And install the corret plugin in Vagrant:

vagrant plugin install vagrant-libvirt

Creating a Cross-Matrix Environment (advanced)

vSense comes with fixtures designed for integration tests. The most common of these tests would be to build environments for each supported database and ensure they all return the same results.

TODO - Implement fixtures and cross-environment tests / add documentation