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).