Sooner or later, your server will need upgrades and patches. A version controlled repository can be of great help when the time comes.

We use git to get our code from a repository, just like we did to install the development environment. For example:

$ git clone https://github.com/odoo/odoo.git -b 8.0 --depth=1

This command gets from GitHub the branch 8.0 source code into an odoo/ subdirectory. At the time of writing, 8.0 is the default branch, so the -b 8.0 option is optional. The --depth=1 option was used to get a shallow copy of the repository, without all version history. This reduces the disk space used and makes the clone operation much faster.

It might be worthwhile to have a slightly more sophisticated setup, with a staging environment alongside the production environment.

With this, we could fetch the latest source code version and test it in the staging environment, without disturbing the production environment. When we're happy with the new version, we would deploy it from staging to production.

Let's consider the repository at ~/odoo-dev/odoo to be our staging environment. It was cloned from GitHub, so that a git pull inside it will fetch and merge the latest changes. But it is also a repository itself, and we can clone it for our production environment, as shown in the following example:

$ mkdir ~/odoo-prd && cd ~/odoo-prd
$ git clone ~/odoo-dev/odoo ~/odoo-prd/odoo/

This will create the production repository at ~/odoo-prd/odoo cloned from the staging ~/odoo-dev/odoo. It will be set to track that repository, so that a git pull inside production will fetch and merge the last versions from staging. Git is smart enough to know that this is a local clone and uses hard links to the parent repository to save disk space, so the --depth option is unnecessary.

Whenever a problem found in production needs troubleshooting, we can checkout in the staging environment the version of the production code, and then debug to diagnose and solve the issue, without touching the production code. Later, the solution patch can be committed to the staging Git history, and then deployed to the production repository using a git pull command on it.

Adding the --save option when starting an Odoo server saves the configuration used to the ~/.openerp_serverrc file. We can use the file as a starting point for our server configuration, which will be stored on /etc/odoo, as shown in the following code:

$ sudo mkdir /etc/odoo
$ sudo chown $(whoami) /etc/odoo
$ cp ~/.openerp_serverrc /etc/odoo/openerp-server.conf

This will have the configuration parameters to be used by our server instance.

The following are the parameters essential for the server to work correctly:

The following settings are also important for a production instance:

When using a reverse proxy, the following settings should be considered:

A production instance is expected to handle significant workload. By default, the server runs one process and is capable of handling only one request at a time. However, a multiprocess mode is available so that concurrent requests can be handled. The option workers=N sets the number of worker processes to use. As a guideline, you can try setting it to 1+2*P, where P is the number of processors. The best setting to use needs to be tuned for each case, since it depends on the server load and what other services are running on the server (such as PostgreSQL).

We can check the effect of the settings made by running the server with the -c or --config option as follows:

$ ./odoo.py -c /etc/odoo/openerp-server.conf

Next, we will want to set up Odoo as a system service and have it started automatically when the system boots.

The Odoo source code includes an init script, used for the Debian packaged distribution. We can use it as our service init script with minor modifications as follows:

$ sudo cp ~/odoo-prd/odoo/debian/init /etc/init.d/odoo
$ sudo chmod +x /etc/init.d/odoo

At this point, you might want to check the content of the init script. The key parameters are assigned to variables at the top of the file. A sample is as follows:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
DAEMON=/usr/bin/openerp-server
NAME=odoo
DESC=odoo
CONFIG=/etc/odoo/openerp-server.conf
LOGFILE=/var/log/odoo/odoo-server.log
PIDFILE=/var/run/${NAME}.pid
USER=odoo

The USER variable is the system user under which the server will run, and you probably want to change it. The other variables should be adequate and we will prepare the rest of the setup having their default values in mind. DAEMON is the path to the server executable, CONFIG is the configuration file to use, and LOGFILE is the log file location.

The DAEMON executable can be a symbolic link to our actual Odoo location, as shown in the following:

$ sudo ln -s ~/odoo-prd/odoo/odoo.py /usr/bin/openerp-server
$ sudo chown $(whoami) /usr/bin/openerp-server

Next we must create the LOGFILE directory as follows:

$ sudo mkdir /var/log/odoo
$ sudo chown $(whoami) /etc/odoo

Now we should be able to start and stop our Odoo service as follows:

$ sudo /etc/init.d/odoo start
Starting odoo: ok

We should now be able to get a response from the server and see no errors in the log file, as shown in the following:

$ curl http://localhost:8069
<html><head><script>window.location = '/web' + location.hash;</script></head></html>
$ less /var/log/odoo/odoo-server.log  # show the log file

Stopping the service is done in a similar way, as shown in the following:

$ sudo /etc/init.d/odoo stop
Stopping odoo: ok

We now only need to make this service start automatically on system boot:

$ sudo update-rc.d odoo defaults

After this, when we reboot our server, the Odoo service should be started automatically and with no errors. It's a good time to check that all is working as expected.