v3.3.0 — Living with more than one Odoo

Nothing you have installed changes. This release is about the two moments the
multi-instance work of 3.1.0 and 3.2.0 had left uncomfortable — the helper, and
the moment you create a second instance — plus the one Odoo × distribution
combination that did not work.

Leaving dev no longer leaves an instance down

dev stops the service and opens a shell as the instance's user. It used to
leave it stopped, saying so in a line that only whoever was still watching the
screen ever read. Now it puts the service back the way it found it:

Restart 'odoo18'? [Y/n]

You are asked first, and the answer you get by pressing Enter is always as it
was — an instance that was serving comes back up, one you had deliberately
switched off stays off. Close the window, or kill the session, and the same rule
is applied without asking: that is the case the behaviour exists for, and a
question needs somebody there to answer it.

Three verbs can name another instance

status, logs and dev take an instance, so you can go from list to what
you meant without first remembering somebody else's helper name:

odoo list                 # what is here, what is up, what drives each
odoo status cliente-x
odoo logs cliente-x 500
odoo dev cliente-x        # a shell as its user, to reach its files

Names work the way list prints them — cliente-x, odoo-cliente-x,
odoo-cliente-x.service — plus default for the unnamed installation. An
unknown name is refused with the listing; a name matching two installations is
refused rather than guessed.

start, stop and restart do not take one, and that is a choice rather
than an omission: looking at somebody else's instance is not the hazard,
starting it is. To act on a named instance you use its own helper, which list
tells you. For the same reason dev cliente-x opens a shell without stopping
that service — and says so, since its port stays busy.

The form asks which instance this is

Until now an instance could only be created with --instance or
ODOO_INSTANCE, so whoever sat at the terminal learned a second Odoo was
possible from a refusal, after the fact. Run sudo invok with no arguments and
the first question is now:

? Instance name (empty = the historical instance)
a second Odoo beside an existing one needs a name; leave empty for the first

Leaving it empty is a real answer and changes nothing. It is the first
question because everything below it is named after it: the user, the database
and the install directory are then suggested as odoo-cliente-x instead of
odoo.

Odoo 16 installs on Fedora

It did not, and the reason was upstream: Odoo 16's newest gevent pin is
written for Python >= 3.12 with nothing above it, so past 3.12 pip kept
choosing a release whose newest prebuilt wheel is cp312 and had to compile.

The ceiling the installer applies is now per Odoo version — 3.12 for 16,
3.13 for the rest — so on Fedora it installs python3.12 for the occasion,
builds the virtualenv on it, and the rollback takes it back with everything
else. Ubuntu and Debian are unaffected: their system Python was already below
both ceilings.

This removes a declared limitation: the README, the package's own page and
two wiki pages said the combination did not work. A CI job now installs and
rolls it back on fedora:41, and a test refuses to let a version with a ceiling
of its own exist without such a job.

Upgrading

Download the new version and replace the binary; there is no repository to
update. Installed instances are untouched — their manifests, services and
helpers keep working, and the helper in your home is rewritten with the new
verbs the next time you install anything on that machine.

v3.2.0 — Odoo 16 installs, and every version we promise is now actually run

Nothing new to type, and nothing to migrate: existing installations are
untouched and the manifest format is unchanged. This release is about a
promise the front page has made since the beginning — Odoo 16, 17, 18 and
19 — that nothing had ever checked.

Odoo 16 installs again

It did not, and the cause was ours rather than Odoo's. The installer put
setuptools into the virtualenv without an upper bound — meaning whatever
exists today — and setuptools 82 removed pkg_resources, which Odoo 16
imports on its very first line. On Ubuntu 22.04 the virtualenv already ships
a setuptools that has it, so the installer was replacing a working one with a
broken one.

What that step owes the virtualenv is that setuptools exists, never that
it is the newest. It is now bounded.

All four versions are now exercised, not just accepted

Every CI configuration installed 18.0, so 16, 17 and 19 were accepted by the
command line and run by nobody — until a customer's machine reported the
first one. Each of the four now has a job that installs it, checks Odoo
answers over HTTP, and rolls it back, on both Ubuntu 22.04 and 24.04. A test
refuses to let the command line accept a version no job covers, so this
cannot quietly come back.

The other three, it turned out, already worked. They were not broken; they
were unverified — a different problem with the same cure.

One combination is declared instead of promised

Odoo 16 does not install on Fedora ≥ 41. Its newest gevent pin is
written for Python ≥ 3.12 and selects a release with no prebuilt wheel for
Python 3.13, which is the interpreter every current Fedora ends up on. That
is upstream's shape, not something the installer can flag away — but trying
it is no longer a wall of compiler output: the failure names the interpreter
and prints the pins that Odoo version declares.

Odoo 16 on Ubuntu or Debian is unaffected, and 17, 18 and 19 install on
Fedora normally.

Multi-instance: a failed installation no longer takes its neighbours down

If an installation fails halfway, the automatic cleanup now knows the
shared-artifact rule that invok rollback has known since 3.1.0. It matters
in one narrow case and only there: an instance that created /opt/odoo, the
system packages and the PostgreSQL cluster, was interrupted, had a second
instance installed beside it, and then failed on being resumed. It would have
removed them from under a running instance.

Related: when a rollback keeps the traversal bit on /opt/odoo because
another named instance still needs to walk through it, it now says so and
names who. Before, a changed permission was left with nothing to attribute it
to.

Also

• the explanation for a failed gevent build used to appear only on a Python
  newer than the ones tested — and the case it was written for happens on
  exactly the newest tested one, so it was silent precisely where it was
  needed;

Also

• the explanation for a failed gevent build used to appear only on a Python
  newer than the ones tested — and the case it was written for happens on
  exactly the newest tested one, so it was silent precisely where it was
  needed;
• the refusal that protects a PostgreSQL cluster whose PGDATA was moved by a
  drop-in is now exercised by a real job, not only by unit tests;
• a CI defect worth naming because it hid others: the Fedora jobs had never
  uploaded an installer log, and three separate "be quiet on failure" settings
  made sure nobody noticed.

Install or update

Download again from the assets below and verify the checksum — the commands,
with the exact file names, are in the README. There is no
apt/dnf repository to add. cargo install invok also gives 3.2.0.

v3.1.0 — More than one Odoo per machine

Until now the installer assumed it was alone on the machine: every artifact it created was named after the Odoo version, so two installations of the same version collided on the user, the role, the database, the unit and the config file. From 3.1.0 an installation can be named, and the name qualifies everything it owns.

sudo invok --instance cliente-x --port 8169   # a second instance, beside the first
sudo invok list                               # what this machine carries
sudo invok rollback --instance cliente-x      # undo just that one
sudo invok rollback --all                     # undo them all, shared artifacts last

What is new

• --instance <name> (or ODOO_INSTANCE in a .env) names an installation. The name qualifies the system user, the PostgreSQL role, the database, the service unit, the install directory, the config file, the filestore and the helper command — so two instances share nothing but the machine. The name is validated against the intersection of the five grammars it ends up in.
• invok list — the instances installed here, their state, database and directory.
• invok rollback --instance <name> and --all. Removing one instance leaves in place whatever the others are standing on — /opt/odoo, the system packages, the PostgreSQL cluster, wkhtmltopdf, nginx — and says so; no package is purged. That instance's manifest is kept as the record of who owns those, so the last removal can still take them away. --all does the two passes in the right order.
• Two ports per instance. Odoo's longpolling port used to be hardwired to 8072, so two instances wrote the same number and fought over one socket the moment either ran with more than one worker. It is now derived from --port (+3), overridable with --gevent-port / ODOO_GEVENT_PORT, and checked against the ports the other manifests claim — even when nothing is listening on them, which with the default configuration is exactly the case.
• nginx: each vhost gets its own upstreams and its own longpolling port. Two instances behind one proxy used to make nginx -t fail with a duplicate upstream.
• The instance helper (odoo, odoo-cliente-x) gains list and logs, and status now shows every Odoo service on the machine, marking the one that helper drives. Every verb that starts or stops still acts on its own instance alone.

Fixes

Three of these predate this release and were found by running it, not by reading:

• the network timeout killed the shell, not the worker. These commands run through sudo, so killing the child left git alive holding the pipes: the timeout error, already decided, was never reported and an installation could sit for minutes without a line of log — indistinguishable from having no timeout at all.
• the tarball fallback could never succeed. It was downloaded into /tmp and handed to the Odoo user, and creating somebody else's file in a sticky world-writable directory is refused by the kernel, root included. Nobody had noticed: a fallback only runs when the clone has already failed.
• a step that failed halfway was not undone. It had usually created something already, and that stayed on disk — which kept /opt/odoo alive through the rollback and made every later run find it "pre-existing".
• a dropped package download is now asked again (three attempts). A mirror closing one connection out of twenty-five used to cost a whole installation. A package that does not exist is not retried: it would answer the same way every time.
• the home's original mode is restored alongside its owner; the rollback report no longer calls the shared root a leftover when it was kept on purpose; and the refusal on an existing installation now names --instance among the ways forward.

Upgrading from 3.0.0

• Nothing changes for a single installation. Whoever does not ask for an instance keeps every path, unit, user and manifest exactly as before — byte for byte. Manifests written by earlier versions stay readable, and instances installed by them stay removable.
• A manifest written before 3.1.0 is read as claiming the 8072 longpolling port, which is what those installations really bind.
• The instance helper is rewritten at every installation, so an existing instance gains list and logs the next time it is installed.

Getting it

Static binary, no runtime to install first — .tar.gz (any distro), .deb, .rpm, each with its .sha256, or cargo install invok. Commands in the README; the packages are invok_3.1.0-1_amd64.deb and invok-3.1.0-1.x86_64.rpm.

Verified on Ubuntu 22.04/24.04, Debian 11/12 and Fedora 41/44, with a CI job that installs two instances side by side and removes them one at a time.

3.0.0 — Invok

Installer per Odoo 16/17/18/19 su Ubuntu, Debian e Fedora, con rollback transazionale:
o l'installazione riesce completamente, o il sistema torna esattamente com'era prima.

Questa release non aggiunge funzionalità all'installazione: cambia il nome del progetto e
il modo in cui si ottiene il comando. Il motore, i 25 step e le protezioni sono gli stessi
della 2.4.0.

Il nome

odoo-installer diventa invok, con l'alias breve vok — un collegamento
/usr/bin/vok → /usr/bin/invok creato dalle confezioni, non un secondo programma.

La regola che ha deciso ogni occorrenza: «Odoo» esce dagli identificatori, resta negli usi
descrittivi. Fuori dal nome del binario, dei pacchetti e dei percorsi che l'installer usa per
sé. Dentro, invariati, tutti gli artefatti che sono di Odoo: /opt/odoo, l'utente e il
database odoo, odoo.conf, odoo18.service, il comando helper odoo. Nessun flag, nessuna
chiave .env e nessun percorso di Odoo cambia: una config della 2.4.0 funziona senza modifiche.

	2.4.0	3.0.0
Comando	odoo-installer	invok (+ alias vok)
Manifesto	/var/lib/odoo-installer/state.json	/var/lib/invok/state.json
Log	/var/log/odoo-installer.log	/var/log/invok.log
Lock	/run/odoo-installer.lock	/run/invok.lock

⚠️ Se aggiorni da una 2.x — leggi questo

Le istanze che hai già installato restano disinstallabili. invok continua a leggere il
manifesto nel percorso storico (/var/lib/odoo-installer/state.json, e prima ancora
/opt/odoo/.installer-state.json): sudo invok rollback su una macchina installata con la
2.4.0 funziona. Quel percorso non verrà mai smesso di leggere — toglierlo non lascerebbe
«un'istanza da rimuovere a mano», lascerebbe un'istanza che nessuno sa più disinstallare senza
indovinare i nomi degli artefatti.

Il pacchetto ha un nome nuovo, quindi apt/dnf non lo aggiornano. invok e
odoo-installer sono due pacchetti distinti: installando il primo ti ritrovi anche il secondo,
con due comandi in /usr/bin. Dopo aver installato:

sudo apt remove odoo-installer      # oppure: sudo dnf remove odoo-installer

È sicuro: quel pacchetto depositava solo il binario CLI: rimuoverlo non tocca né Odoo, né il
servizio, né il manifesto.

Il vecchio log resta dov'è. /var/log/odoo-installer.log non viene né spostato né
cancellato — è il post-mortem delle installazioni precedenti. Tienilo o rimuovilo a mano.

Come si installa

Quattro strade, lo stesso eseguibile (musl statico, nessuna dipendenza) tranne l'ultima che
lo compila. Ogni download ha il suo .sha256: verificalo prima di installare.

# Ubuntu / Debian
curl -fsSL -O https://github.com/Omisen/invok/releases/download/v3.0.0/invok_3.0.0-1_amd64.deb
curl -fsSL -O https://github.com/Omisen/invok/releases/download/v3.0.0/invok_3.0.0-1_amd64.deb.sha256
sha256sum -c invok_3.0.0-1_amd64.deb.sha256
sudo apt install ./invok_3.0.0-1_amd64.deb

# Fedora
sudo dnf install ./invok-3.0.0-1.x86_64.rpm

# Qualsiasi distro, senza installare nulla — musl statico
tar xzf invok-x86_64-unknown-linux-musl.tar.gz && sudo ./invok

# Se hai già Rust
cargo install invok

su cui poggia il supporto multi-distribuzione, e la guida rapida chiedeva ancora la toolchain
Rust come prerequisito;

• documentazione: wiki ·
  modello di rollback ·
  storia delle versioni.

---

Progetto indipendente: non affiliato a Odoo S.A. né sostenuto da essa. «Odoo» è un marchio
di Odoo S.A. Questo pacchetto non contiene né redistribuisce codice Odoo.

---

v2.4.0 — Il comando giusto, e un installer che sa dire chi è

Release piccola e di manutenzione, ma necessaria: chi installava la 2.3.0 seguendo la guida non
arrivava alla prima riga. Il comando di download nominava un file che quella release non contiene.

🐛 Il comando di installazione del .deb era rotto

Il pacchetto pubblicato si chiama odoo-installer_2.3.0-1_amd64.deb — con la revisione -1 che
cargo deb aggiunge al nome — mentre README e note di rilascio ne nominavano uno senza. Risultato:
404, prima ancora di scaricare l'installer. Il .rpm era corretto.

Corretto qui, e chiuso su tre livelli perché non si ripeta:

• la revisione è ora dichiarata in Cargo.toml, invece di essere ereditata dal default di uno
  strumento esterno: il nome dell'artefatto è un dato del progetto, non una convenzione altrui che può
  cambiare da sotto;
• il test che lega README e versione compone i nomi dal manifesto invece di scriverli a mano. La
  versione precedente ripeteva la stessa congettura del README, ed era verde mentre il download dava 404;
• il workflow di rilascio verifica che il nome del pacchetto davvero prodotto compaia nel README,
  prima di pubblicarlo. È l'unico punto della catena che legge il file invece di una copia della
  supposizione — e una release pubblicata con la guida sbagliata si corregge solo con un'altra release.

🆕 L'installer sa dire quale versione è

Era pronto ma non era mai stato pubblicato: il tag della 2.3.0 precede di un commit il lavoro che lo
introduce. Da questa release:

• odoo-installer -V (o --installer-version) stampa la versione. --version resta la versione di
  Odoo e non cambia: nessuno script o .env in campo si rompe;
• la versione è la prima riga di ogni log, che questo progetto tiene in vita oltre il rollback proprio
  perché è il post-mortem. Un log arrivato da una macchina cliente ora dice chi l'ha scritto;
• è registrata nel manifesto di disinstallazione: se annulli un'installazione con un binario diverso
  da quello che l'ha creata, il rollback te lo dice prima di iniziare, invece di limitarsi a segnalare
  «step sconosciuto».

Da pacchetto funzionano anche dpkg -l odoo-installer e rpm -q odoo-installer.

🔁 Se aggiorni dalla 2.3.0

Nessuna installazione esistente va rifatta. Sul sistema installato non cambia niente: nessun flag
nuovo, nessuna migrazione, nessuna differenza di comportamento. Cambia solo il tool: scarichi il file col
nome giusto e puoi chiedergli che versione è.

🧪 Come lo sappiamo

Stessa CI di integrazione della 2.3.0 — installazione reale e disinstallazione verificata su Ubuntu 22.04
e 24.04, Debian 11 e 12, Fedora 41 e 44, con gli scenari Nginx, utente preesistente e SIGINT a metà
installazione. Sui mock: 428 test. Le tre guardie nuove sono validate per mutazione: rimettendo il
README sbagliato, il test fallisce nominando il file mancante.

⚠️ Limiti dichiarati

• Ubuntu 26.04 non è supportata, e conviene saperlo perché wsl --install senza argomenti ora scarica
  quella: il suo python3 è il 3.14, che i pin di gevent/greenlet di Odoo non coprono. L'installer
  avvisa al preflight e prosegue, ma l'installazione si ferma al passo dei requisiti Python (annullandosi
  in modo pulito). Usa 22.04 o 24.04.
• Su WSL2 l'installer funziona solo con systemd attivo ([boot] systemd=true in /etc/wsl.conf,
  già il default sulle immagini Ubuntu recenti): senza, l'installazione si ferma a PostgreSQL e si annulla.
• Restano i limiti dichiarati nella 2.3.0 su Fedora: default site di Nginx non toccato, precondizione sul
  PGDATA spostato coperta dai soli test su mock.

📦 Installazione

Qualsiasi distro (binario statico):

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256
sha256sum -c odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256   # deve dire: OK
tar xzf odoo-installer-x86_64-unknown-linux-musl.tar.gz
./odoo-installer -V
sudo ./odoo-installer

Ubuntu / Debian (occhio al -1 nel nome):

📦 Installazione

Qualsiasi distro (binario statico):

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256
sha256sum -c odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256   # deve dire: OK
tar xzf odoo-installer-x86_64-unknown-linux-musl.tar.gz
./odoo-installer -V
sudo ./odoo-installer

Ubuntu / Debian (occhio al -1 nel nome):

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer_2.4.0-1_amd64.deb
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer_2.4.0-1_amd64.deb.sha256
sha256sum -c odoo-installer_2.4.0-1_amd64.deb.sha256
sudo apt install ./odoo-installer_2.4.0-1_amd64.deb
odoo-installer -V

Fedora:

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-2.4.0-1.x86_64.rpm
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.4.0/odoo-installer-2.4.0-1.x86_64.rpm.sha256
sha256sum -c odoo-installer-2.4.0-1.x86_64.rpm.sha256
sudo dnf install ./odoo-installer-2.4.0-1.x86_64.rpm
odoo-installer -V

Una cosa da fare a parte, e vale la pena non rimandarla: le note della v2.3.0 contengono lo stesso URL rotto. Chi arriva dalla pagina Releases e apre la
release precedente — o chi ha già il link in un'email — continua a prendere 404 anche dopo che avremo pubblicato la 2.4.0. Sono due righe da correggere a
mano nel corpo della v2.3.0 (odoo-installer_2.3.0_amd64.deb → odoo-installer_2.3.0-1_amd64.deb, in tre punti: i due curl e l'apt install). Il nuovo
controllo in release.yml protegge le release future, non quella già pubblicata.

v2.3.0 — Fedora supportata davvero

Da questa release l'installer non parla più una lingua sola: Ubuntu, Debian e Fedora sono
supportate allo stesso modo, dallo stesso binario, con la stessa promessa — o l'installazione riesce
completamente, o il sistema torna esattamente com'era prima.

🆕 Novità

• Fedora ≥ 40 supportata, ciclo di vita completo: dnf, nomi dei pacchetti rpm, inizializzazione
  del cluster PostgreSQL (che su Fedora il pacchetto non fa), .rpm di wkhtmltopdf con pin verificato,
  firewalld, SELinux, layout Nginx in conf.d. Il rollback rimuove tutto ciò che ha aggiunto, come
  sulle altre famiglie.
• L'interprete Python si sceglie, non si subisce. Odoo pinna gevent e greenlet per versione di
  Python: su Fedora ≥ 43, dove il python3 di sistema è 3.14, quei pin non lo coprono e pip non
  riuscirebbe a costruire. L'installer crea il virtualenv su python3.13, lo installa per l'occasione
  e lo rimuove con il rollback. Su Ubuntu e Debian non cambia nulla.
• Quando un build non può riuscire, l'installer lo dice. Se l'interprete è più recente dei pin di
  Odoo, arriva un avviso al preflight prima della conferma e, se pip fallisce davvero, un errore che
  nomina la causa invece di lasciare parlare trecento righe di gcc.
• Pacchetto .rpm dell'installer, accanto al .deb: sudo dnf install ./odoo-installer-…rpm e il
  comando è nel PATH, rimovibile con dnf remove. È lo stesso binario statico degli altri formati.
• Protezione in più su PostgreSQL: se il PGDATA dichiarato dal servizio non è quello che l'installer
  sa gestire, l'installazione si ferma prima di toccare qualsiasi cosa invece di inizializzare un
  cluster in un posto e rimuoverne un altro al rollback.

🔁 Se aggiorni dalla 2.2.0

Nessun flag cambia, nessuna installazione esistente va rifatta, nessuna migrazione. Su Ubuntu e Debian
il comportamento è identico alla 2.2.0: la differenza si vede solo installando su Fedora, dove prima
l'installer si fermava e ora arriva in fondo.

🧪 Come lo sappiamo

La CI di integrazione installa davvero e poi disinstalla, verificando che non resti niente:
Ubuntu 22.04 e 24.04 su runner nativi, Debian 11 e 12 in container, Fedora 41 e 44 in container
privilegiato con systemd come PID 1, più gli scenari con Nginx (ufw e firewalld attivi, entrambe le
nature del default site), con utente odoo preesistente e con un SIGINT reale a metà installazione.
Sui mock: 422 test.

⚠️ Limiti dichiarati

• Odoo 18 non gira su Python 3.14: non è una scelta nostra, sono i pin di Odoo. Per questo su
  Fedora ≥ 43 il virtualenv nasce su 3.13. Se la tua distribuzione non impacchetta un interprete
  coperto, l'installazione prosegue lo stesso ma l'avviso ti dice cosa aspettarti.
• Su Fedora il server di default di Nginx non viene toccato: lì è un blocco dentro nginx.conf, non
  un file, e riscrivere la configurazione principale di un servizio non è qualcosa che facciamo. Una
  richiesta a un hostname diverso da --server-name continua a ricevere la pagina di benvenuto.
• La precondizione sul PGDATA spostato con un drop-in è coperta dai soli test su mock: esercitarla in CI
  richiederebbe una macchina configurata contro la convenzione.

📦 Installazione

Qualsiasi distro (binario statico):

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256
sha256sum -c odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256   # deve dire: OK
tar xzf odoo-installer-x86_64-unknown-linux-musl.tar.gz
sudo ./odoo-installer

Ubuntu / Debian:

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer_2.3.0_amd64.deb
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer_2.3.0_amd64.deb.sha256
sha256sum -c odoo-installer_2.3.0_amd64.deb.sha256
sudo apt install ./odoo-installer_2.3.0_amd64.deb

Fedora:
## ⚠️  Limiti dichiarati

- **Odoo 18 non gira su Python 3.14**: non è una scelta nostra, sono i pin di Odoo. Per questo su
  Fedora ≥ 43 il virtualenv nasce su 3.13. Se la tua distribuzione non impacchetta un interprete
  coperto, l'installazione prosegue lo stesso ma l'avviso ti dice cosa aspettarti.
- **Su Fedora il server di default di Nginx non viene toccato**: lì è un blocco dentro `nginx.conf`, non
  un file, e riscrivere la configurazione principale di un servizio non è qualcosa che facciamo. Una
  richiesta a un hostname diverso da `--server-name` continua a ricevere la pagina di benvenuto.
- La precondizione sul PGDATA spostato con un drop-in è coperta dai soli test su mock: esercitarla in CI
  richiederebbe una macchina configurata contro la convenzione.

## 📦 Installazione

**Qualsiasi distro** (binario statico):

```bash
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256
sha256sum -c odoo-installer-x86_64-unknown-linux-musl.tar.gz.sha256   # deve dire: OK
tar xzf odoo-installer-x86_64-unknown-linux-musl.tar.gz
sudo ./odoo-installer

Ubuntu / Debian:

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer_2.3.0_amd64.deb
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer_2.3.0_amd64.deb.sha256
sha256sum -c odoo-installer_2.3.0_amd64.deb.sha256
sudo apt install ./odoo-installer_2.3.0_amd64.deb

Fedora:

curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-2.3.0-1.x86_64.rpm
curl -fsSL -O https://github.com/Omisen/auto-installer-odoo/releases/download/v2.3.0/odoo-installer-2.3.0-1.x86_64.rpm.sha256
sha256sum -c odoo-installer-2.3.0-1.x86_64.rpm.sha256
sudo dnf install ./odoo-installer-2.3.0-1.x86_64.rpm

Ogni asset ha il suo .sha256: verificalo prima di installare.

v2.2.0 — Ctrl-C che annulla, ripresa delle installazioni interrotte, e un rollback che mantiene la promessa

Il tema di questa release è una promessa sola: o l'installazione riesce, o il sistema torna
esattamente com'era. Erano diversi i punti in cui non veniva mantenuta — e nessuno di essi si
manifestava come un errore. Tutti chiusi, e verificati su macchina reale.

In breve

• Ctrl-C non uccide più l'installer: l'installazione si annulla da sé e il sistema torna pulito,
  senza dover lanciare nulla.
• Un'installazione interrotta si riprende da dove si era fermata, senza perdere traccia di cosa
  era già stato creato.
• /opt/odoo sparisce davvero dopo un rollback. Prima restava, sempre.

Se aggiorni dalla 2.1.0, leggi questo

Due cambiamenti possono rompere uno script esistente:

1. Il log si è spostato: ora è /var/log/odoo-installer.log (era /opt/odoo/.installer.log).
   In compenso esiste anche alla prima installazione, che è quando serve davvero.
2. Rilanciare l'installer su un'istanza già installata ora fallisce, con un messaggio che indica
   rollback o --force. Prima "riusciva" — ed era il difetto: sovrascriveva il manifesto di
   disinstallazione e rendeva l'istanza non più rimovibile.

Cambiati anche i percorsi di lock (/run/odoo-installer.lock) e manifesto
(/var/lib/odoo-installer/state.json). Le istanze installate con la 2.1.0 restano
disinstallabili: il percorso storico continua a essere letto.

--enable-ssl si chiama ora --open-https-port, perché è ciò che fa — apre la 443 sul firewall,
non configura TLS. Il vecchio nome e la chiave .env NGINX_ENABLE_SSL continuano a funzionare.

Novità

• Gestione di Ctrl-C e SIGTERM. L'interruzione ha effetto fra uno step e il successivo: quello in
  corso viene portato a termine, perché fermare a metà un apt lascerebbe qualcosa di peggio. Un
  secondo Ctrl-C esce subito (codice 130) e lì il rollback resta a carico tuo.
• Ripresa delle installazioni interrotte. Gli step già eseguiti non vengono rifatti, e resta
  registrato che quegli artefatti sono nostri — è ciò che permette di rimuoverli anche mesi dopo.
  Serve rilanciare con gli stessi parametri: con un database diverso l'installer si ferma e dice
  quale campo non coincide.
• --force: reinstalla sopra un'istanza esistente. Il manifesto precedente viene archiviato,
  mai cancellato.
• Avviso sulle release non testate. Su Ubuntu > 24.04 o Debian > 12 l'installazione prosegue, ma
  ti dice che quella release non è fra quelle su cui giriamo la CI.

Correzioni

Rollback e disinstallazione

• /opt/odoo viene finalmente rimossa: lock, log e manifesto non vivono più dentro il perimetro che
  il rollback deve ripulire.
• Il manifesto non viene mai sovrascritto in silenzio.
• Dopo un fallimento, rilanciare funziona: il manifesto dice cosa c'è ancora sul sistema, non cosa
  è stato fatto. Prima gli step già annullati venivano saltati al rilancio, e l'installazione
  proseguiva dando per esistenti l'utente, la directory e il database appena rimossi.
• Il file di stato deve appartenere a root e descrivere il perimetro atteso, o il rollback si rifiuta
  di agire.
• La barra di progresso avanza anche sugli step che non si possono annullare.

Sicurezza

• Nessun file temporaneo con nome prevedibile scritto da root: i requirements di pip nascono dentro
  il virtualenv, il tarball e il .deb con nome casuale e creazione fail-closed.
• L'unit systemd ha un hardening reale (ProtectSystem, ProtectHome, PrivateDevices,
  RestrictAddressFamilies…) al posto di una direttiva deprecata dal 2016 e ignorata.

Nginx

• Il default site viene ripristinato com'era, non com'è di solito: un symlink torna al suo target
  originale, e un file regolare non viene più cancellato ma messo da parte e rimesso a posto.
• La porta 80 viene aperta anche su una macchina che ha già una regola 8080/tcp.
• Si può installare su una macchina dove Nginx sta già servendo: la 80 occupata da Nginx non è più
  trattata come un conflitto.
• I log del vhost portano la versione nel nome: due istanze non si scrivono più addosso.

Installazioni su macchine non vergini

• Se l'utente odoo esiste già, la home appena creata gli viene consegnata subito — prima
  l'installazione moriva tre step dopo con un mkdir: Permission denied che non diceva nulla.
• Il control-script odoo viene aggiornato: reinstallando una versione diversa non pilota più il
  servizio vecchio.
• Su una distribuzione più recente di quelle note, il pacchetto wkhtmltopdf di ripiego segue la
  famiglia dell'OS: una Debian ignota non riceve più un pacchetto Ubuntu.

Interfaccia

• La risposta ai prompt non finisce più su una riga diversa dalla domanda.
• --dry-run non può più restare appeso a una richiesta di password sudo, e dice quando il piano
  sarà incompleto perché eseguito senza privilegi.

Verifica

312 test automatici, e una CI di integrazione che installa e disinstalla davvero su sei scenari:
Ubuntu 22.04 e 24.04, Debian 11 e 12 in container, con Nginx (nelle due configurazioni possibili del
default site), su una macchina con l'utente odoo già presente, e con un SIGINT reale mandato a
metà installazione.

Rispetto alla versione originale ho applicato le due correzioni che ti avevo segnalato: il conteggio dei test (308 → 312) e la riga su A-R8-1 sotto
«Rollback e disinstallazione». Il resto è identico.

v2.1.0 — Rollback da disco, hardening e Ubuntu 24.04

Quarta release, e la prima evoluzione sostanziale dopo il port Rust della 2.0.0.

La 2.0.0 sapeva installare e sapeva annullare durante un fallimento. La 2.1.0 chiude la
remediation post-audit (R1–R6) e aggiunge il pezzo che mancava alla promessa del progetto:
il rollback disponibile anche dopo, a installazione conclusa — per un Ctrl-C, un
kill -9, o la disinstallazione a posteriori di un'istanza funzionante. Insieme arrivano
le correzioni trovate alle prime installazioni reali su Ubuntu 22.04 e 24.04, che sono
anche il motivo per cui esiste una CI che esegue davvero l'installer.

Novità principali

odoo-installer rollback (alias uninstall)
Il rollback non vive più solo in-process sul fallimento di uno step: legge lo stato
persistito in /opt/odoo/.installer-state.json, ricostruisce gli step, li reidrata ed
esegue gli undo in ordine inverso, best-effort.
Opzioni: --state, --dry-run, --yes, --aggressive-rollback.
A fine rollback un report elenca gli eventuali residui.
L'invocazione senza sottocomando resta l'installazione: nessuna riga di comando esistente
cambia significato.

Lo stato è il manifesto di disinstallazione
A installazione riuscita lo stato non viene più cancellato: viene marcato come concluso e
conservato. È l'unica traccia di quali artefatti abbiamo creato e quali abbiamo trovato
già presenti. Porta anche la configurazione dell'installazione (utente, DB, directory,
versione — mai le password), così un rollback lanciato senza argomenti non indovina i
nomi e non droppa il database sbagliato. Nella 2.0.0 lo stato veniva azzerato a fine
successo, e il caso d'uso principale del comando sarebbe stato morto in partenza.

Protezione del filestore (nuovo step setup-data-dir)
/opt/odoo/.local/share/Odoo è la metà su disco dei dati applicativi: dentro ci sono gli
allegati. Ora lo crea uno step con PreState proprio, invece di apparire al primo avvio di
Odoo senza che nessuno lo registri. Il suo undo richiede due condizioni: directory
creata da noi e database creato da noi. Se il DB era preesistente — quello che
l'anti-drop protegge — il filestore non si tocca, anche se la directory l'abbiamo creata
noi. Proprietà della directory e proprietà dei dati sono due domande diverse.

Nessun residuo in /opt/odoo (nuovo step setup-cache-dir)
La cache di pip nasce dentro il venv (--cache-dir) invece che nella home di odoo, e
/opt/odoo/.cache ha ora un proprietario dichiarato: creata da noi → il rollback la
rimuove; preesistente → resta. Niente più pulizia a euristica nella home del cliente.

Portabilità e installazioni reali

• Nomi dei pacchetti apt portabili tra Ubuntu e Debian. Le dipendenze non sono più
  liste di nomi ma gruppi di alternative, risolti prima di mutare: vince un'alternativa
  già installata (il delta resta onesto), altrimenti la prima installabile. Risoluzione a
  tre livelli — già installato → candidato reale → installabile comunque — che gestisce i
  nomi puramente virtuali di Ubuntu 24.04 (es. libfreetype6-dev). Un pacchetto davvero
  inesistente è un errore prima di toccare il sistema, con il gruppo nel messaggio.
• apt-get update all'inizio dell'installazione, così le liste vecchie di un'immagine
  non fanno dichiarare inesistenti pacchetti validi. Tollerante ai repo irraggiungibili.
• Ubuntu 24.04 / Python 3.12 sbloccato. Le righe gevent/greenlet passano a pip
  verbatim con i loro marker d'ambiente: la versione la scegli pip, non l'installer
  (prima si prendeva la prima riga utile del requirements, che su 24.04 era il pin per
  Jammy — e non compila contro 3.12). Aggiunto setuptools al bootstrap del venv, che da
  3.12 venv non semina più.
• Precondizione venv che può davvero fallire: si verifica import ensurepip invece di
  python3 -m venv --help, che rispondeva 0 anche senza il pacchetto python3-venv.

Robustezza e sicurezza

• Timeout sulle operazioni di rete (clone, tarball di fallback, download .deb):
  default 300s, override con ODOO_NETWORK_TIMEOUT_SECS (0 disattiva). Il processo
  scaduto viene ucciso e raccolto, con errore tipizzato che dice cosa è scaduto e come
  alzare il limite. Prima un mirror che non chiudeva la connessione appendeva l'installer
  a tempo indefinito. apt e le operazioni locali lunghe restano senza timeout: troncare
  dpkg è peggio dell'attesa.
• Verifica d'integrità di wkhtmltopdf con pin SHA-256 (jammy/bullseye/bookworm),
  fail-closed: un .deb senza pin o con hash diverso non viene installato. Installazione
  via apt-get install così le dipendenze vengono risolte davvero.
• Rollback resistente a dpkg rotto. Il rollback gira sempre dopo un fallimento che può
  aver rotto dpkg, e apt non opera su un dpkg rotto: ogni purge passa da un helper con
  recovery. Prima poteva lasciare indietro decine di pacchetti.
• Ordine del reload di Nginx corretto: il riallineamento avviene dopo che le config
  sono state ripristinate, non prima — altrimenti l'Nginx del cliente continuava a servire
  una nostra config con i file già rimossi.
• File privati e argomenti: creazione dei temporanei con O_EXCL|O_NOFOLLOW a 0600 e
  nomi imprevedibili; validazione degli identificatori più -- prima di ogni nome
  posizionale (doppia difesa contro l'argument injection); lockfile a 0600.

Test e CI

Suite ampliata in modo consistente (reidratazione step-per-step, comando di rollback,
end-to-end del rollback con Nginx nella catena, sicurezza locale, timeout di rete, gruppi
di alternative apt), validata per mutazione. La lista delle dipendenze obbligatorie è
congelata da un test: un refactor che perde un pacchetto lo dice subito, senza aspettare
il campo.
Nuovo workflow integration.yml che esegue davvero l'installer (Ubuntu 22.04/24.04 con
systemd: installazione → servizio attivo → Odoo che risponde in HTTP → rollback → sistema
pulito; container Debian 11/12 come sonda di portabilità). Le asserzioni di pulizia leggono
il delta apt dal file di stato, quindi verificano entrambi i lati della promessa chirurgica:
il delta purgato e i preesistenti intatti. La CI veloce su mock resta invariata.

Artefatti

• odoo-installer-x86_64-unknown-linux-gnu.tar.gz — standard (glibc)
• odoo-installer-x86_64-unknown-linux-musl.tar.gz — statico, gira su qualsiasi distro
  (consigliato)
• odoo-installer_2.1.0_amd64.deb — solo il tool in /usr/bin; Odoo lo installa il
  binario a runtime
• File .sha256 accanto a ogni archivio

Aggiornamento dalla 2.0.0

• Nessun cambio incompatibile sulla riga di comando: rollback è un sottocomando nuovo,
  l'uso senza sottocomando è invariato.
• Il file di stato non viene più cancellato a installazione riuscita: è quello che
  rende possibile odoo-installer rollback. Resta a root, 0600.
• Uno stato scritto dalla 2.0.0 è ancora leggibile, ma non contiene la configurazione: in
  quel caso il rollback si ferma con un messaggio esplicito invece di indovinare i nomi di
  utente e database. Per disinstallare un'istanza creata con la 2.0.0, passa gli argomenti
  a mano.

Limiti noti

• Nessun handler SIGINT reale: un Ctrl-C non avvia il rollback da sé. Al suo posto un
  avviso stampato prima delle mutazioni che indirizza a odoo-installer rollback.
• Il job di CI su container non copre l'avvio del servizio: in un container systemd non è
  PID 1, quindi l'installazione si ferma per costruzione a setup-postgres.
• I sorgenti Odoo non sono pinnati a un commit specifico (clone via HTTPS da GitHub).

v2.0.0 — Installer Rust con rollback chirurgico

Odoo Auto-Installer v2.0.0

Riscrittura completa dell'installer da Bash a Rust. Stesso scopo — installare Odoo
(16/17/18/19) su Ubuntu/Debian — ma con una garanzia nuova: o l'installazione riesce
del tutto, o il sistema torna esattamente com'era prima. Niente stati intermedi, niente
residui.

⚠️ Release major, breaking. L'installer Bash (installer.sh + lib/*.sh) è stato
rimosso. Chi usava la vecchia versione passa al nuovo binario: l'invocazione cambia
(vedi sotto).

Novità principali

• Rollback transazionale (chirurgico). Ogni passo registra lo stato prima di agire e
  sa disfarlo. Se qualcosa fallisce, i passi vengono annullati in ordine inverso,
  best-effort, riportando il sistema allo stato iniziale.
• Protezione delle risorse preesistenti. Ciò che c'era già — un database, l'utente di
  sistema, un servizio — non viene mai toccato in rollback. Un DB preesistente non è
  droppato in nessun caso (protezione anti-drop verificata da test dedicati).
• Modalità interattiva e non-interattiva. Prompt guidati al primo uso, oppure
  configurazione via file .env / flag CLI per uso in CI e deploy ripetibili. Priorità di
  risoluzione: CLI → .env → prompt.
• Nginx opzionale + SSL. Reverse proxy configurabile con --with-nginx /
  --server-name / --enable-ssl.
• Sicurezza. Password e segreti con tipo dedicato, redatti nei log e mai stampati.
  Checksum SHA-256 pinnati (TOFU) per il download di wkhtmltopdf. State file a permessi
  0600. Lockfile per evitare esecuzioni concorrenti.
• Logging strutturato su TTY e su file (senza codici ANSI nel file).
• Affidabilità dimostrata. Il confine SystemOps rende i comandi privilegiati
  mockabili; una suite di test (incluso un modello di sistema stateful end-to-end) prova
  che dopo un rollback lo stato finale coincide con quello iniziale.

Installazione

Tre modi (dettagli nel README):

• Binario precompilato (consigliato, niente Rust): scarica il .tar.gz qui sotto —
  ...-musl è statico e gira su qualsiasi distro, ...-gnu per sistemi con glibc
  recente. Verifica con il file .sha256 allegato.
• Pacchetto .deb (esperienza apt nativa): scarica odoo-installer_2.0.0_amd64.deb,
  poi sudo apt install ./odoo-installer_2.0.0_amd64.deb. Il comando odoo-installer
  finisce nel PATH ed è rimovibile con apt remove odoo-installer.
• Build da sorgente: git clone + cargo build --release.

Esecuzione: via sudo da un utente normale.

sudo odoo-installer                                  # guidato
sudo odoo-installer --config production.env --with-nginx   # non-interattivo
sudo odoo-installer --dry-run                         # mostra il piano senza agire

Asset di questa release

- odoo-installer-x86_64-unknown-linux-musl.tar.gz (+ .sha256) — statico, portabile
- odoo-installer-x86_64-unknown-linux-gnu.tar.gz (+ .sha256) — glibc
- odoo-installer_2.0.0_amd64.deb (+ .sha256) — pacchetto Debian/Ubuntu

Solo Linux x86_64: l'installer usa useradd/apt/systemctl/sudo, quindi non esistono
target Windows/macOS sensati.

Note d'uso

- Prima di un uso reale, popola i pin dei checksum wkhtmltopdf (istruzioni nel README).
- Il .deb installa solo il tool: Odoo, PostgreSQL, systemd e Nginx vengono configurati
a runtime quando lanci odoo-installer, non dall'installazione del pacchetto.

v1.2.0

Changelog

v1.2.0 - 14-04-2026

Release focalizzata su una installazione piu guidata, controlli post-installazione piu affidabili e comportamento coerente sulle versioni Odoo supportate.

CLI e configurazione

• introdotta una raccolta input guidata durante il setup: nella versione precedente il flusso era basato quasi esclusivamente su valori di default o su file .env;
• i parametri principali possono ora essere inseriti direttamente durante l'esecuzione, oltre che tramite argomenti CLI o configurazioni .env;
• resa piu chiara la priorita' delle sorgenti di configurazione: argomenti CLI, input interattivo e default finali.

Diagnostica e verifiche

• la suite tests/check_install.sh usa ora di default la diagnostica dell'installazione reale trovata sul sistema, senza basarsi su ipotesi rigide legate a una singola versione;
• aggiunti override espliciti per validare una specifica istanza (--version, --config, --db-user, --port, --odoo-user) quando serve un controllo mirato;
• migliorato il report finale con contesto rilevato automaticamente, riepilogo OK / KO / SKIP / WARN ed esito piu leggibile per l'utente finale;
• corretti i falsi negativi su path, file odoo.conf, nome del servizio, branch Git e controlli Python nelle installazioni multi-versione o basate su checkout Git;
• ridotti i controlli duplicati poco utili, in particolare nei casi in cui un errore systemd rendeva ridondanti ulteriori failure HTTP.

Security

• admin_passwd=admin resta consentito solo con conferma esplicita durante il setup;
• la verifica finale considera admin_passwd=admin non release-ready e restituisce FAIL, anche se l'installazione risulta tecnicamente funzionante.

Docs

• aggiornati README.md, [docs/check_install](https://github.com/Omisen/auto-installer-odoo/wiki/8.-Check-Install-%7C-Suite-di-test-post%E2%80%90installazione) e la documentazione correlata per riflettere il comportamento finale dell'installer, della CLI e della diagnostica.