Virtual machine development environment

From FusionForge Wiki
Revision as of 17:33, 28 February 2014 by Beuc-inria (talk | contribs) (Stalled SSH access)

Jump to: navigation, search

We provide a development virtual machine (aka FusionForge Sandbox) with an already configured automated tests environment. FusionForge is not pre-installed, it is automatically built using included scripts.

To use the VM, please install Vagrant. By default Vagrant uses VirtualBox so install it too.

(Note: if you wish, you can extract the disk image from the .box and use it with KVM, see below.)

Install in Vagrant

vagrant init fusionforge-dev http://fusionforge.fusionforge.org/sandbox/fusionforge-dev.box
# optionaly modify 'Vagrantfile', e.g. enable 'vb.gui' to open the graphics display.
vagrant up
vagrant ssh -- -l root


This VM/appliance is designed to help you get started on development. It's basically a clean Debian system, with a checkout of the FusionForge code and a few helper scripts. Those scripts are in the /root/fusionforge/tools/VM-scripts directory:

  • update.sh will update the sources from Debian FusionForge's Bzr repository, and also the currently installed packages.
  • build.sh builds FusionForge packages from the sources, and stores them in the package repository at /root/debian-repository/.
  • install.sh installs those FusionForge packages. This should end up with an up-to-date FusionForge running on http://forge.local/ , with the administrator's login being “admin” and its password being “myadmin”.
  • install-gui.sh optionally sets up an X11 graphical environment.
  • run-testsuite.sh installs Selenium and runs the testsuite

We recommend you run these scripts in order. There's an icon on the VM's Desktop to run build.sh+install.sh, and another one for run-testsuite.sh.

The actual source code is stored under /root/fusionforge, so that's where you should do the changes you want to test.

Stalled SSH access

If user SSH access to the VM is stalling, check that nscd is installed:

aptitude install nscd

See the thread about this issue.

Running the test suite

First, we need a few manual steps to avoid Firefox self-signed certificate error dialogs when running selenium tests.

  • Start connection with valid DISPLAY (using the VM display, or ssh -X)
  • Close your existing Firefox windows (if any) and run:
firefox -ProfileManager
  • Configure a new Firefox profile in a directory of your choice, e.g. /root/fusionforge/tests/ff-profile-selenium/
  • Still in Firefox, visit https://forge.local/ and add an exception for the self-signed certificate
  • Close Firefox
  • To run the tests with the corresponding Firefox profile, pass a -firefoxProfileTemplate option to selenium in /root/fusionforge/tests/scripts/phpunit.sh:
PATH=/usr/lib/iceweasel:$PATH LANG=C java -jar /usr/share/selenium/selenium-server.jar -firefoxProfileTemplate /root/fusionforge/tests/ff-profile-selenium/ -singleWindow >/dev/null &

Now you can run /root/fusionforge/tools/VM-scripts/run-testsuite.sh in a terminal (may take a few minutes to start).

Running remotely

If you don't want to install a full GUI on the VM, you can also run the interesting things remotely through SSH using

vagrant ssh -- -l root -X

Note that Selenium needs an X11 display (since it drives a graphical web browser).

You may prefer running the X display inside the VM to start the selenium server, so that windows opened by the tests don't bother you.


To reset the FusionForge admin password

Use: /usr/share/gforge/bin/forge_set_password admin

Accessing the web interface from host

In the Vagrantfile, add:

config.vm.network :forwarded_port, guest: 80,  host: 8080
config.vm.network :forwarded_port, guest: 443, host: 8443

In /etc/fusionforge/config.ini.d/zzzz-local.ini, add:


And in your host's /etc/hosts, add: forge.local

Then hit http://forge.local:8080/ !

Using psql as root

su - postgres -c "psql -c 'CREATE ROLE root; ALTER ROLE root LOGIN SUPERUSER'"

Slow DNS

If your DNS requests have some 5s delay, try replacing with your local DNS in /etc/resolv.conf.

I'd like to know why VirtualBox' DNS is so slow :/ This makes the cowbuilder debootstrap particularly long.

Using QEMU/KVM instead of VirtualBox

Converting from Virtualbox image format to QEMU qcow2

Converting from Virtualbox image format to QEMU qcow2: convert to raw format first

tar xf fusionforge-dev.box fusionforge-dev-disk1.vmdk
VBoxManage clonehd -format RAW fusionforge-dev-disk1.vmdk ffsandbox.raw  # ~10GB

Then optionaly convert to QCOW2 format:

qemu-img convert -f raw -O qcow2 ffsandbox.raw ffsandbox.qcow2

Running inside libvirt

  • Create a VM by importing the created qcow2 disk image, with virt-manager.
  • You may need to set manually the driver type to 'qcow2' in "disk" device section in the VM xml file (in /etc/libvirt/qemu/). In this case you need to redefine the VM xml file by: `sudo virsh -c qemu:///system define /etc/libvirt/qemu/ffsandbox.xml` then start the VM.
  • You need to reconfigure network interfaces in /etc/network/interfaces afterwards for replicating eth0 config stanza for eth1 for instance. You can find which device to enable by running ifconfig -a.
  • You may need to check the web_host setting in /etc/fusionforge/config.ini.d/debian-install.ini to adjust the forge's URLs for redirections.

Modify the VM

The VM is automatically generated from scratch using the Packer tool. See the Packer configuration in tools/VM-bootstrap/.