Files
ThothII/docs/reports/2026-09-26-server-release-plan.md
T
User 2f53512e4d
Publish documentation / publish (push) Successful in 32s
docs: record server release and hand off remaining acceptance checks
2026-09-27 00:41:37 +02:00

10 KiB
Raw Blame History

Piano eseguibile — rilascio coordinato ThothII / Omics

Data: 26 settembre 2026. Ripresa del passaggio di consegne. Piano approvato dall’utente; esecuzione avviata il 26 settembre 2026 alle 19:28 Europe/Rome. Stato operativo e risultati successivi nel report di esecuzione. Il testo seguente registra la preparazione precedente alla conferma. Nessun fermo, modifica di configurazione operativa, migrazione, ricreazione, login di prova o cambio credenziali eseguito durante questa ripresa.

Risultato proposto

  • ThothII: distribuire core/frontend già costruiti dalla main 497ab84031e285464fdbb73e6e0ce9252687e3ab, conservando percorso del descrittore, project identity, dati e configurazione server.
  • Omics: fast-forward da 1cf7ea90a669a26bf3bc51749eab4d07981da472 al commit locale 928f7e9fff2aba895416776fecf5668ee957d237, che aggiunge il filtro proxy degli asset. Conservare la stessa immagine e lo stesso container web: shell embedded e fix Superset sono già operativi. Riavviare web dopo il backup e ricreare soltanto nginx Omics, fissandone l'immagine all'ID esistente.
  • Mantenere il fix proxy anche nel rollback: la configurazione precedente consente il bypass documentato nell'handoff e non deve essere ripristinata.

L'entrypoint web rieseguirà makemigrations, migrate, controllo superuser, compilemessages e collectstatic. Verificati makemigrations --check --dry-run e migrate --check: nessuna modifica o migrazione pendente. L'utente che lo script creerebbe automaticamente esiste già. Questi controlli saranno ripetuti prima del fermo. Nessuna nuova migrazione di catalogo, Memory o sessioni emerge anche dal confronto ThothII 49333a2d..497ab840; nessun job di migrazione è previsto.

Rivalidazione alla ripresa

Controllo Esito
Immagini/container operativi Stessi ID e date di avvio registrati nell'handoff
Baseline descriptor/env/override/Pi/modelli/segreti Tutti gli hash invariati
Checkout ThothII candidato e Omics candidato SHA attesi, puliti
Checkout ThothII operativo Sempre dirty; preservato, 30 modifiche e due file non tracciati
Checkout Omics operativo Tracciati invariati; nuovi file locali sotto docs/prd/.claude/, preservati
Checkout di lavoro ThothII Nuova directory locale .claude/, estranea al rilascio e preservata
Pi RPC Zero processi, rilevamento effettivo in /proc
Maintenance Inattiva; il contatore admissions del CLI è locale a quel processo e non certifica il drenaggio del server
Doctor Positivo con UID 10001 e gruppi operator/Docker
Omics Gunicorn/Django rispondono; catalogo Superset valido; nessuna migrazione pendente
HTTPS locale Certificato verificato con CA interna e risoluzione del nome a 127.0.0.1; config 200, API anonima 403
Alias Docker Univoci; nginx risolve core/frontend/web; Omics legge il manifest
Compose candidato Environment, reti, porte, mount persistenti/segreti invariati; cambiano immagini, contesti build e due script con contenuto identico
Descrittore candidato Cambiano solo projectDirectory e il percorso dell'overlay git-ssh
Spazio 27,8 GiB liberi; stima non compressa 12,6 GiB; riserva richiesta 20,9 GiB

Il bypass asset operativo non è stato ritestato in questa ripresa: resta quello accertato nell'handoff; il fix resta non distribuito. Le prove HTTPS locali non sostituiscono l'accesso da una postazione esterna o un login reale.

Script revisionato e verifiche

Percorso definitivo di preparazione: /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py. SHA256: eb2c677c8adbee0c9febf919001f654c8535e71f064d9fb7c7883afd02383a41. La precedente release.DRAFT.py resta conservata e non va eseguita.

Correzioni principali:

  • Parsing NUL degli argomenti Pi, rilevamento --mode rpc e --mode=rpc, esclusione del processo di controllo; test reale in container isolato.
  • Gate espliciti anche con Python ottimizzato; lock tra esecuzioni; controllo dei digest dei tag, dei container e degli artefatti preparati.
  • Baseline estesa a CLI, configurazione Omics, CA/proxy host e file locali.
  • Checksum dedicati della configurazione di rollback, creati prima delle mutazioni; journal delle fasi, file parziali conservati e nessun marker VERIFIED su errore.
  • Preservazione proprietari/permessi, .git, file ignorati/non tracciati, ACL/xattr negli archivi. Solo cache dipendenze ricostruibili escluse.
  • Readiness HTTP di Omics, alias dopo ricreazione, controlli HTTPS con CA, tutti gli asset del manifest e riepilogo log per categorie senza contenuti sensibili.
  • Recupero reopen per rendere nuovamente raggiungibile una sessione Pi comparsa durante il drenaggio: riapre solo nginx con il fix, senza fermare web/core/Pi.

Validazione: sintassi Python, 14 test isolati, fase check read-only positiva. I test coprono anche conferma mancante, backup parziale/corrotto, checksum con path traversal, ownership, readiness HTTP e recupero senza stop di Pi. Le fasi mutanti non sono state eseguite né rappresentano un restore provato.

Evidenze in /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/: reviewed-tests.log, reviewed-check.log, script e test; manifest protetti artifacts.json, baseline-extra.json, source-state.json. Restano valide le prove precedenti: 6/6 proxy con ciascun frontend nuovo/vecchio, 28/28 Omics, 782 frontend, 152 backend e 31 browser; nessuna modifica a quelle implementazioni durante questa ripresa.

Comandi risolti per la finestra

Riservare indicativamente 30–45 minuti, da confermare dall'operatore: la durata reale dipende soprattutto dal dump del database condiviso. L'interruzione interessa Omics e ThothII; non vengono fermati Authentik, il database condiviso o il DWH. La prima parte del backup (codice/config/immagini) avviene con le app ancora attive.

Eseguire ciascun comando solo dopo exit 0 del precedente, nella finestra approvata:

sudo -n python3 /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py check
sudo -n python3 /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py backup --window-confirmed
sudo -n python3 /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py deploy --window-confirmed

--window-confirmed registra l'intenzione del comando, non sostituisce il consenso. Lo script contiene tutti i percorsi/ID e l'ordine Compose risolti; non usa pull, build implicite, setup completo, reset o cancellazione volumi.

Sequenza concreta:

  1. Rivalidare baseline, assenza Pi e spazio. Salvare e verificare configurazioni, CLI, sorgenti e immagini correnti.
  2. Attivare maintenance, chiudere nginx Omics, attendere e controllare due volte Pi. In caso di sessioni attive fermare la procedura senza ucciderle.
  3. Fermare Omics web/core/frontend, creare i dump, fermare i soli supporti ThothII, archiviare bind e volumi. Verificare checksum, lettura tar e indici dump.
  4. Solo con backup VERIFIED: fast-forward Omics; aggiornare descriptor/env/overlay; installare CLI verificato e generare proiezioni con UID 10001. Controllare che modelli, Pi, shell e credenziali restino identici.
  5. Riavviare supporti; ricreare core/frontend con stesso progetto thothii-7f901b48fe35; avviare lo stesso web Omics; ricreare nginx col fix e immagine fissata. --no-build --pull never --no-deps limita il lifecycle.
  6. Verificare health/HTTP, DNS, nginx -t, attendere 31 secondi, eseguire prove automatiche HTTP/HTTPS e log. Disattivare maintenance solo dopo esito positivo.

Backup e gestione delle interruzioni

Destinazione nuova, protetta root 0700: /srv/thothii-v2/backups/20260926-coordinated-release. Non esiste ancora: verrà creata nella finestra. Se esiste già, lo script si ferma senza riutilizzare o cancellare il contenuto.

Contiene CLI/descriptor/env/override/generated, sorgenti e Git, configurazioni Omics e proxy, immagini per ID, bind data/registry/Evidence/Pi/segreti, volumi catalogo/Qdrant/Ollama/static/media, dump catalogo e dump PostgreSQL condiviso. Il dump condiviso è una snapshot transazionale coerente mentre gli altri servizi che usano quel DB continuano a operare; non è un backup raw a database fermo. Il volume raw del catalogo ThothII viene copiato solo dopo averlo fermato.

Su errore: niente retry cieco né prosecuzione verso deploy. Leggere journal e stato container. Prima di una mutazione ai servizi, questi restano operativi; dopo la quiescenza possono rimanere fermi. Il manifest rollback-config.json permette il rollback applicativo anche quando il backup dati è incompleto. Nessun restore automatico dei dati; nessuna prova di restore dichiarata.

Se Pi compare dopo chiusura ingressi e prima del fermo applicativo:

sudo -n python3 /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py reopen --window-confirmed

Questo applica il solo proxy sicuro, mantiene le applicazioni e Pi accesi e lascia maintenance attiva: l'utente può salvare/fermare la sessione. La procedura si arresta poi per rivalutare backup parziale e baseline; non tenta automaticamente un nuovo backup o deploy.

Rollback applicativo

Se la nuova applicazione o i controlli falliscono, e non ci sono Pi da salvare:

sudo -n python3 /srv/thothii-v2/operator/releases/20260926-coordinated/reviewed/release.py rollback --window-confirmed

Ripristina configurazioni/CLI/generated e immagini core/frontend precedenti, riavvia lo stesso web Omics, mantiene il commit e il proxy corretto, quindi ripete il collaudo automatico. Ripristina UID/GID/mode originali. Non sovrascrive dati, non ripristina l'intero DB condiviso e non torna al nginx vulnerabile. Non fa reset Git. Rifiuta di interrompere Pi attivi. Dopo un backup parziale conserva gli artefatti per analisi: non li presenta come backup completo.

Collaudo dell'operatore dopo il rilascio

Avvisare l'utente quando i controlli automatici saranno verdi, poi verificare con account autorizzati e dati fittizi:

  1. Login unico Omics → Datamart Builder, /me con identità/ruoli corretti, nessun secondo login; utente normale e admin coerenti.
  2. IT/EN, tema, fullscreen/Esc e persistenza dopo reload.
  3. Sessione di prova, eventi SSE, stop/save/ripresa e lingua immutabile.
  4. Logout e seconda scheda; diniego cross-origin autenticato su risorse di prova.
  5. Database/Memory/Evidence leggibili, layout previsto, HTTPS da client esterno.

Queste prove restano aperte e sono necessarie prima di dichiarare concluso il rilascio, secondo la matrice di accettazione.