When we finished our Chef integration, we wanted to give our users a template that was ready to use with Abiquo. Creating the template was a bit more painful than I expected at the start.


One thing we omitted in the first version was the time sync. If the difference between the clock of the machine trying to access the Chef server and the Chef server itself is more than 15 minutes, the server denies access with a 401 error.

This means our template needs to be synchronized, so we made the following changes:

  • Update all hypervisor clocks. A virtual machine gets the time from the hypervisors when it boots. If all your infrastructure is already in sync with ntp, for example, this will be easier.
  • Force synchronization when the VM boots up. We added a few lines to the init script to stop the ntp server, run the ntp client and start the ntp server again. Remember that ntp only makes small corrections to the time. If your VM is getting a date and time that is too far from the right one, ntp will not be able to sync the time in the first run and it will cause Chef to fail on the first attempt. Sync your hypervisors!


Our initial idea was to release 3 templates with the Chef agent: CentOS 5.7, CentOS 6.2 and Ubuntu 11.04. For testing, we used the Opscode Community Repository . We started testing with the WordPress recipe because it has useful dependencies like MySQL and Apache. But the tests failed. When we looked into it, we found the recipe was trying to install packages that do not exist in certain distributions (CentOS 5.7 and CentOS 6.2).

We fixed a few things but we were unable to believe that anyone would be using these recipes as they were. We asked on chat and found out that most of the recipes are broken for all other operating systems except Ubuntu. So we moved to Ubuntu and everything started working better.

The only fix we made was adding an ‘apt-get update’ because sometimes we got an error that some packages could not be found because the DB was outdated.


After we got WordPress working we wanted to get the Jira recipe working. Jira is a program by Atlassian that is used to manage tickets. It’s a really powerful bug tracker that we use in the development of Abiquo.

The first approach was something similar to the flow presented in this video but instead of getting a screen from Jira, we got an error screen from Apache. It appeared that Tomcat was not starting up.

We started debugging and we found that the recipe requires manual steps to configure the database. After deploying your recipe, you need to log in to the VM and run some commands and after that you can run Jira. Honestly, I was a bit surprised by that. It is true that the recipe automates most of the installation, but why force the user to run commands to create the DB and configure a user to connect to the database?

The answer was in the readme. This recipe was written some time ago, when the MySQL recipe was not yet written. There is a note in the readme explaining that the manual steps are there until someone writes the MySQL recipe. But no one had updated the Jira recipe.

In the end, we updated the recipe to use the MySQL server recipe and to use the new version of Jira (5.0.2).

We will provide a git repository with these fixes. And we have made a pull request to the Opscode repository in order to contribute this recipe upgrade.