anybox-odoo-host

Warning

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 http://apt.anybox.fr

Introduction

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.

Contents:

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

Separate man pages:

Indices and tables:

Installation

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 http://apt.anybox.fr/openerp common main
deb http://apt.anybox.fr/openerp anybox contrib

Packages undergoing evaluation will be uploaded to the testing variants:

deb http://apt.anybox.fr/openerp common main
deb http://apt.anybox.fr/openerp anybox-testing contrib

Packages undergoing evaluation will be uploaded to anybox-testing.

Architecture

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 apt.postgresql.org 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…)

Commands

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.

Note

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

Frequent commands

supervisorctl:
manage OpenERP/Odoo process, see openerp_host_instance_start_stop
anybox-odoo-deploy:
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.

anybox-register-buildout:
create Supervisor and Nginx configuration based on templates for one instance.
anybox-ajout-client:
create the system user and the PotsgreSQL role for one customer

Rare or automatic commands

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

Global install commands

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

Configuration files

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

Logs

Nginx:
/var/log/nginx
Supervisor:
/var/log/supervisor
buildouts:
~INSTANCE/log

Backups

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.

Warning

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 aoh1.anybox.fr && /usr/local/sbin/notify_shinken_backups_ok)

Note

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

Note

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

Project directory structure

Example

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

current_buildout

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.

`hostname`.cfg

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)