Installation

Auf unserem Server tuedfed-tat40web.srv.mwn.de wurde Odoo nach der offiziellen Anleitung von Odoo unter Ubuntu installiert.

Odoo verwendet als Datenbank Postgres. Das muss also zuerst installiert werden: 

sudo apt install postgresql -y

Odoo richtet bei der Installation über die Paketquellen (siehe unten) automatisch einen Benutzer odoo in Linux und Postgres ein. Für Zugriff auf Postgres siehe auch die Seite zu Postgres Zugriff.

Eine weitere Abhängigkeit, die man von Hand vorher installieren muss ist wkhtmltopdf. Nachdem die Installation über die Standard Ubuntu Paketquellen nicht funktioniert hat, wurde es manuell installiert. 

wget https://github.com/wkhtmltopdf/packaging/releases/download/0.12.6-1/wkhtmltox_0.12.6-1.focal_amd64.deb
apt install ./wkhtmltox_0.12.6-1.focal_amd64.deb
# Test:
#wkhtmltopdf

Odoo selbst ist nicht Teil von den Ubuntu Paketquellen. Daher muss man es zuerst als Repo Quelle hinzufügen und kann es dann aber gewohnt mit apt installieren. 

# Odoo hat ein eigenes Paket Repo. Dazu muss man den deren Key als vertrauenswürdig hinzufügen
wget -q -O - https://nightly.odoo.com/odoo.key | sudo gpg --dearmor -o /usr/share/keyrings/odoo-archive-keyring.gpg
# Dann das Repo hinzufügen
echo 'deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/16.0/nightly/deb/ ./' | sudo tee /etc/apt/sources.list.d/odoo.list
# Und abschließend Paketlisten aktualisieren und Odoo installieren
sudo apt-get update && sudo apt-get install odoo

Konfiguration

Details zur Standard-Konfiguration von Odoo finden sich in der Dokumentation von Odoo. Unsere Installation unterscheidet sich dahingehend von Standard-Installationen, dass wir verschiedene Datenbanken über verschiedene Subdomains erreichbar machen, damit verschiedene Nutzer(-gruppen) unabhängig voneinander arbeiten können. Folgende Änderungen gegenüber den Standards sind dafür nötig:

  • dbfilter ist eine Funktion, wie eine Odoo Instanz mit getrennten Datenbanken von mehrere "Kunden" unabhängig verwendet werden kann. Der aktuelle Filter ^%d.*$ bewirkt, dass über eine gegebene Subdomain nur Datenbanken erreichbar sind, deren Name mit dem Namen der Subdomain beginnt (oder einfach übereinstimmt). Beispielsweise sind die Datenbanken startzustand-ohne-webshop und startzustand-mit-webshop über startzustand.usw erreichbar und dobhan über dobhan.usw.
  • db_maxconn ist ein Parameter, mit dem die Anzahl der Verbindungen von Odoo zu Postgres begrenzt werden kann. Bei einem Multi-Datenbank-Setup muss man diesen Parameter so einstellen, dass die Parameter db_maxconn, workers und max_cron_threads aus odoo.conf und der Parameter max_connections aus postgresql.conf folgende Ungleichung erfüllen: (1 + workers + max_cron_threads) * db_maxconn < max_connections (Quelle).
  • PostgreSQL kann man weitestgehend so lassen wie es ist, nachdem Odoo und Postgres auf dem gleichen Server laufen. Wenn sie auf getrennten Maschinen laufen müsste man eine Verbindung über einen SSH-Tunnel herstellen oder externe IPs erlauben. Um obige Ungleichung zur Vermeidung zu vieler Clients zu erfüllen, muss der Wert von max_connections in /etc/postgresql/12/main/postgresql.conf entsprechend gewählt werden. In unserem Fall ist max_connections = 300 statt der ursprünglichen 100 gesetzt, sodass noch etwas Puffer oberhalb der (1+6+1)*32=256 Clients vorhanden ist, die Odoo maximal in Anspruch nimmt.

Im Fall unserer Installation findet sich die Hauptkonfiguration von Odoo in /etc/odoo/odoo.conf statt /etc/odoo.conf, wie es in der Dokumentation steht. Die aktuelle Config ist relativ kurz (falls sich nicht geändert hat): 

; See https://www.odoo.com/documentation/16.0/administration/install/deploy.html

[options]
; This is the password that allows database operations:
admin_passwd = ...
db_host = False
db_port = False
db_user = odoo
db_password = False
dbfilter = ^%d.*$
addons_path = /usr/lib/python3/dist-packages/odoo/addons,/opt/odoo-addons,/var/sftp/andre_schulz_addons,/home/joachim/indust>
default_productivity_apps = True

; Proxy mode for Nginx
proxy_mode = True
xmlrpc_interface = 127.0.0.1
netrpc_interface = 127.0.0.1

; Performance settings
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 450
limit_time_real = 900
max_cron_threads = 1
workers = 6
db_maxconn = 32

Ein zufälliges 16 stelliges Passwort lässt sich mit Linux Befehl < /dev/urandom tr -dc A-Za-z0-9 | head -c${1:-16};echo; generieren.

Nginx

Für HTTPS läuft Odoo hinter einem Nginx Proxy, der in /etc/nginx/sites-enabled/odoo.conf konfiguriert ist. Das Template dazu steht auch in der oben verlinkten Dokumentation. Die Subdomains kommen jeweils in die server-Blöcke, d. h. 

server {
  listen 80;
  listen [::]:80;
  server_name dobhan.erp.digit40.edu.sot.tum.de;
  server_name repoli.erp.digit40.edu.sot.tum.de;
  ...
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name dobhan.erp.digit40.edu.sot.tum.de;
  server_name repoli.erp.digit40.edu.sot.tum.de;
  ...

Subdomain hinzufügen

Um eine neue Subdomain von Hand hinzuzufügen: 

sudo nano /etc/nginx/sites-enabled/odoo.conf  # An beiden Stellen wo "server_name" vorkommt eine neue Zeile hinzufügen
sudo certbot --expand -d neueSubdomain.erp.digit40.edu.sot.tum.de -d dobhan.erp.digit40.edu.sot.tum.de ... # Hier alle Domains auflisten (bei der Frage zum redirect die "1: no redirect" auswählen)
sudo systemctl restart nginx

Dann kann man unter der neuen Subdomain in Odoo eine neue Datenbank einrichten. Wir starten derzeit üblicherweise mit einer Kopie derjenigen Datenbank, an der der Lehrstuhl WiPäd rumspielt. Das geht bequem über den Endpunkt /web/database/manager, also erst auf https://quelle.erp.digit40.edu.sot.tum.de/web/database/manager ein Backup erstellen (Master-Passwort siehe oben odoo.conf) und dieses zip-Archiv dann via "restore" in https://ziel.erp.digit40.edu.sot.tum.de/web/database/manager hochladen (dabei "this database is a copy" wählen).

Eine Skripting-Lösung ist in Arbeit (#39), wird aber gerade durch den Domain-Umzug von erp-test.oct.re zu erp.digit40.edu.sot.tum.de gebremst. Der nervigste Schritt in Handarbeit, nämlich der Certbot-Aufruf mit -d subdomain.erp.digit40.edu.sot.tum.de für jede Subdomain, lässt sich mit 

DOMAINS=$(grep -E 'server_name' /etc/nginx/sites-enabled/odoo.conf | sort | uniq -d | sed 's/server_name //' | sed 's/;//')
CERTBOTPARAM=$(echo $DOMAINS | sed 's/ / -d /g')
sudo certbot --expand --no-redirect -d $CERTBOTPARAM
erledigen.

Update

Updates (zumindest innerhalb einer Version, z.B. Version 16) gehen einfach mit apt update && apt upgrade. Upgrades (z.B. 16->17, sobald verfügbar) sind noch nicht getestet. Falls es nach dem Update zu Fehlermeldungen kommt, die sowas wie web.assets_backend.min.js enthalten, hilft es vermutlich Asset Bundles neu zu generieren. Dazu öffnet man die Instanz mit ?debug=assets, und klickt dann oben rechts auf das "Bug" Symbol und dort auf "Regenerate Assets Bundles":

image

SFTP-Zugriff für André Schulz

Solange keine Containerisierung umgesetzt ist, brauchen fortgeschrittene Benutzer wie André Schulz (Masterand WiPäd), die eigene Addons schreiben, eine Möglichkeit, ihren Code auf den Server zu bringen. Provisorisch ist das entsprechend https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-20-04 mit einem Benutzer andresftp gelöst, der nur per SFTP und nur auf den Ordner /var/sftp/andre_schulz_addons zugreifen kann. Letzterer ist in /etc/odoo/odoo.conf als Addons-Pfad hinzugefügt, sodass André (und jeder andere der neugierig ist) die dortigen Addons installieren kann.