Until we have a Puppet module to manage this in automated fashion, here's how to setup an environment to run our automated test suite.

Once you have a working environment, see usage.

Install dependencies

The following packages are necessary on Debian Wheezy, with wheezy-backports sources added:

apt-get install git xvfb virt-viewer libsikuli-script-java \
    libxslt1-dev tcpdump unclutter radvd x11-apps syslinux \
    libcap2-bin devscripts libvirt-ruby ruby-rspec gawk ntp \
    ruby-json x11vnc xtightvncviewer ffmpeg libvpx1 dnsmasq-base && \
apt-get -t wheezy-backports install qemu-kvm qemu-system-x86 libvirt0 \
    libvirt-dev libvirt-bin seabios ruby-rjb ruby-packetfu cucumber && \
service libvirt-bin restart

Other requirements

The system running the test suite needs an accurate clock since we sync the clock from the host to the Tails guest after a background snapshot restore to appease Tor. This is why we installed ntp above.

Special use cases

Access the system under test with VNC

If you're running the test suite in a nested environnement, install xtightvncviewer on the bare metal level-0 host. Then you can use vncviewer's -via option so that it automatically setup a ssh tunnel to your first level test suite domain for you and display the Tails VM. E.g. where $DISPLAY is the display given to you by run_test_suite (often 0):

vncviewer -viewonly -via user@level0 localhost:$DISPLAY

Running the test suite as a non-root user

This is entirely possible, but there's some additional configuration required. Run the following as root:

addgroup tcpdump
dpkg-statoverride --update --add root tcpdump 754 /usr/sbin/tcpdump
setcap CAP_NET_RAW+eip /usr/sbin/tcpdump
adduser $USER tcpdump
adduser $USER libvirt
adduser $USER libvirt-qemu

It's important to run setcap after dpkg-statoverride since the latter deletes all capabilities. Unfortunately the setcap command has to be rerun for that reason everytime the tcpdump package is updated until Debian bug #662845 is fixed.

Running these commands will add some interesting capabilities to $USER, so you may want to do this for a dedicated user separate from your normal user. In that case (and if you run the tests as root) the --view option won't work unless you grant $USER access to your display via xhost +SI:localhost:$USER. Alternatively you can use the --vnc-server-only option and manually connect to the VNC server with your normal user. Just make sure the VNC viewer is in view-only mode (e.g. xtightvncviewer --view-only ...) in order to not interfere with the testing session.