Lewati ke isi

Odoo Server Provisioning on Ubuntu or Debian

Baseline runbook for installing one Scola school instance on a Linux server.

Last verified: 2026-04-02

1. Scope

This runbook is for:

  • Ubuntu or Debian servers
  • one school per Odoo instance
  • Odoo 17 runtime from scola-be
  • Scola modules from scola-odoo-module
  • PostgreSQL on the same host

This is intentionally separate from the WSL local-dev flow in Odoo Local Setup on WSL.

Target layout on the server:

/opt/scola/
├── code/
│   ├── scola-be
│   └── scola-odoo-module
├── instances/
│   └── <school-code>/
│       ├── data/
│       └── logs/
└── venv/

/etc/scola/
└── <school-code>.conf

The scripts added in this repo assume that layout by default, but every important path can be overridden with environment variables.

3. Why This Uses Different Scripts Than WSL

The WSL scripts are for developer convenience. They rely on:

  • wsl.exe -u root
  • local dev defaults
  • disposable databases and runtime directories

Server installation should use native Linux behavior instead:

  • run directly as root or with sudo
  • create a dedicated service user
  • write config into /etc/scola
  • manage Odoo through systemd
  • keep runtime data under /opt/scola/instances/<school-code>

So the answer is: reuse the logic, but not the exact WSL wrapper.

4. Prerequisites

Before provisioning a school instance:

  1. Prepare a fresh Ubuntu or Debian host.
  2. Check out the code:
  3. /opt/scola/code/scola-be
  4. /opt/scola/code/scola-odoo-module
  5. Copy the provisioning scripts from this repo, or run them from the checked-out repo directly.

Example checkout:

sudo mkdir -p /opt/scola/code
sudo chown -R "$USER":"$USER" /opt/scola
cd /opt/scola/code
git clone <scola-be-repo-url> scola-be
git clone <scola-odoo-module-repo-url> scola-odoo-module

5. Bootstrap the Host

Run once per server:

cd /path/to/scola-fe-v2
sudo bash scripts/server/bootstrap_odoo_host.sh

This script will:

  1. install Ubuntu or Debian packages
  2. create the odoo service user
  3. prepare /opt/scola
  4. ensure PostgreSQL is online
  5. create a shared Python virtualenv
  6. install Odoo Python dependencies if scola-be is already checked out

6. Provision One School Instance

Example for a single school:

cd /path/to/scola-fe-v2
sudo \
  INSTANCE_NAME=smpn1pmk \
  INSTANCE_HOSTNAME=smpn1pmk.example.sch.id \
  INSTANCE_DB_NAME=smpn1pmk \
  INSTANCE_DB_USER=smpn1pmk \
  INSTANCE_DB_PASSWORD='<strong-db-password>' \
  INSTANCE_ADMIN_PASSWORD='<strong-master-password>' \
  INSTANCE_HTTP_PORT=8069 \
  INSTANCE_LONGPOLLING_PORT=8072 \
  INSTANCE_MODULES='scola_bundle_core,scola_bundle_assessment' \
  bash scripts/server/provision_odoo_school.sh

This script will:

  1. ensure directories and runtime ownership
  2. install Python dependencies
  3. create the PostgreSQL role and database
  4. write /etc/scola/<school-code>.conf
  5. write and register systemd unit scola-<school-code>.service
  6. install the requested modules or bundles
  7. restart the service and probe /web/login

7. Upgrade an Existing School

Use the same provisioning script, but switch the Odoo mode from install to upgrade:

cd /path/to/scola-fe-v2
sudo \
  INSTANCE_NAME=smpn1pmk \
  INSTANCE_DB_NAME=smpn1pmk \
  INSTANCE_DB_USER=smpn1pmk \
  INSTANCE_DB_PASSWORD='<strong-db-password>' \
  INSTANCE_ADMIN_PASSWORD='<strong-master-password>' \
  INSTANCE_MODULES='scola_bundle_core,scola_bundle_assessment' \
  INSTANCE_ODOO_MODE=u \
  bash scripts/server/provision_odoo_school.sh

That gives you one repeatable entrypoint for both initial provisioning and controlled upgrades.

8. Frontend Dev Against Local Odoo

For frontend development, do not point Vite directly at production or be-dev unless you really intend to.

Use .env.development.local.example as the template:

cp .env.development.local.example .env.development.local

That keeps Vite proxy enabled and points it to http://127.0.0.1:8069.

Then start:

bash scripts/local/run_odoo_local.sh
npm run dev

If the console prints PROXY_TARGET: http://127.0.0.1:8069, the frontend is using the local Odoo instance.

9. What Still Needs Manual Ops Work

These scripts intentionally stop short of full production hardening. You still need:

  • Nginx reverse proxy
  • TLS certificates
  • firewall rules
  • backup and restore policy
  • log rotation and retention
  • monitoring and alerting

The generic production guidance remains in Deployment Backend.

My recommendation is:

  • use scripts/local/* for local development in WSL
  • use scripts/server/* for a single-school Ubuntu or Debian host
  • if later you manage many schools or many servers, move from shell scripts to Ansible or another proper provisioning layer

For one school or a small number of customer instances, the Linux-native scripts here are a reasonable starting point.