This 1.x version is meant for Debian ≤ 7. For Debian 8 (Jessie), look for the 2.x versions, available in the anybox-jessie or anybox-jessie-testing distributions of


anybox-odoo-host is a package for the Debian GNU/Linux distribution that provides a standardized structure and utilities to host one or several Odoo (formerly OpenERP) instances.

It relies heavily on Anybox’s OpenERP/Odoo buildout recipe : each instance’s software is expected to be packaged before hand with the recipe’s freeze/extract commands, and provided as single archive file (various formats and download options are supported).

Process management is currently done with Supervisor, and the default web front end is Nginx. anybox-odoo-host creates all the needed configuration files for them, through a handful of configurable templates.


On this home page (also readable as man anybox-odoo-host from installed systems)

Separate man pages:

Indices and tables:


Supported OpenERP/Odoo versions: 6.0 through 8.0 Supported Debian versions: 6 (Squeeze) and 7 (Wheezy)

The simplest is to hook to Anybox Debian sources and use the following combination:

deb common main
deb anybox contrib

Packages undergoing evaluation will be uploaded to the testing variants:

deb common main
deb anybox-testing contrib

Packages undergoing evaluation will be uploaded to anybox-testing.


Here is a simplified diagram

  • the web front-end used is the Debian standard Nginx
  • PotsgreSQL server is local, connections are expected to be in peer. Every versions available via can be used.
  • (optional) servers can be in high-availability, with PotsgreSQL replication (WAL streaming).
  • Odoo processes are managed by Supervisor
  • each customer has his own system user and a PotsgreSQL role which has databases creation rights
  • One customer has one or many projects, each one with a buildout and one or many databases.
  • Each buildout produces start process commands (gunicorn, cron, longpolling…)


Scripts beginning with anybox- are written in Python and accept a --help argument

anybox-register-buildout --help

Most of conventions and coincidences (for example, Supervisor process group name is customer name) are default values for the many options

In this documentation/man page , we try and avoid referencing the precise name and behaviour of available options, referring to the various help outputs of the commands, in order to fight against discrepancies. Nevertheless, we do provide higher level information on the behaviour of commands, with some overlap with those help outputs. In case of doubt or conflict (please report them), the command help output is usually the one to be right.


Warning, some scripts are located in /usr/sbin, especially if only root can launch them.

Frequent commands

manage OpenERP/Odoo process, see openerp_host_instance_start_stop
The main deployment workhorse. Downloads, extracts, installs buildout archives and create/upgrade databases.
service nginx:
monitor Nginx. Use reload to apply configuration change(s) without taking risks.
service postgresql:
monitor PotsgreSQL. Use reload to apply configuration change(s) without taking risks : most of postgresql.conf and pg_hba.conf settings can be changed with a simple reload. Settings that require a restart are explicitely labelled as such in the comments.

Instance initialisation commands

Without being rare these commands are meant to be executed only one time for each project.

create Supervisor and Nginx configuration based on templates for one instance.
create the system user and the PotsgreSQL role for one customer

Rare or automatic commands

to create an additional database for an already deployed project
do a database backup and may optionnaly keep a fixed number of active snapshots. See Local backups production
to send backups from master to slave
very dangerous delete all databases andinitiate PotsgreSQL as slave for replication

Global install commands

set up the structure of the Supervisor configuration. Executed by the install or the update of anybox-odoo-host.

Configuration files

/etc/nginx/sites-available/* activated by symbolic links in /etc/nginx/sites-enabled
buildouts, new structure:
~INSTANCE/`hostname`.cfg (file which contains server specifities according to buildout)
buildouts, legacy anybox-openerp-host structure:
HTTPS certificates:




They are located in /var/backups/postgresql. This directory has special ACL so that customer’s system user can produces dumps, to be separated and to be accessible by the backup user.


Never user chmod on dumps except if we know how to monitor and check ACL (cf man getfacl, man setfactl, man acl).

In high-availability pairs servers setups, anybox-rsync-pg-backups is used to send backups from master to slave

Local backups production

The anybox-openerp-rotating-backup script does:

  • produce database backup in /var/backup/postgresql (thanks to permissions and ACLs set up by anybox-openerp-host)
  • limit local backups number
  • optionaly, inform Shinken backups are done
  • optionaly, restore freshly backuped database including date in the name, this is the rotative part
  • nothing if the server is a slave for the PotsgreSQL replication !

anybox-openerp-rotating-backup is started by customer’s system user cron, as initialised by anybox-odoo-deploy

gracinet@aoh2:~$ sudo crontab -u anybox -l | tail -1 23 21 * * * /usr/bin/anybox-openerp-rotating-backup –remount-as-database anybox –shinken-enable –shinken-host anybox_oerp

Backups shipping

The anybox-rsync-pg-backups script uses a dedicated SSH key and it started by a cron from /etc/cron.d, which next informs Shinken that all was done correctly.

Here is a typical example:

gracinet@aoh2:~$ sudo cat /etc/cron.d/anybox-rsync-pg-backups
08 14 * * * backup (/usr/bin/anybox-rsync-pg-backups && /usr/local/sbin/notify_shinken_backups_ok)


TODO notify_shinken_backups_ok should be embedded in anybox-rsync-pg-backups.


The Debian package also prepare the cron in /etc/cron.d/, to uncomment and to configure with the right hostname.

Project directory structure


Here’s a real-life instance listing:

customer_example@server2:~/project-example$ ls -l
total 401308
lrwxrwxrwx  1 customer_example openerp       19 Sep 30 10:16 current_buildout -> project-example-openerp-1.1b5-2
drwxr-xr-x  2 customer_example openerp     4096 Sep 30 10:16 log
drwxr-xr-x  2 customer_example openerp     4096 Sep 30 10:16 dumps
-rw-r--r--  1 customer_example openerp      631 Jul 26 11:56 server2.cfg
drwx------ 24 customer_example openerp     4096 Sep 27 08:40 project-example-openerp-1.1b4-2
drwx------ 24 customer_example openerp     4096 Sep 30 10:17 project-example-openerp-1.1b5-2
drwxr-xr-x  2 customer_example openerp     4096 Sep  3 10:54 tarballs


The subdirectory current_buildout is a symbolic link to the last delivery (results of archive extraction)

It allows to reconcile two requirements:

  • path stability, particularly in the Supervisor configuration
  • the capability to switch quickly from one version to another (useful to rollback a failed deployment)

current_buildout is the default value picked by anybox-odoo-deploy.


In the previous example, it’s server2.cfg. This file contains the local configuration thanks to the extends of the delivered file (generally release.cfg, but you can change it)