Gestione e manutenzione

Questo documento riguarda chi gestisce un'installazione di Orafila: controlli, aggiornamenti, backup e ripristino, incidenti, e le attività di supporto agli utenti. I comandi deploy/... si scrivono sul server, dalla cartella nova-psa.

Chi fa cosa

Controlli

Docker riavvia da solo un servizio che si ferma; i controlli di salute di app (ogni 30 secondi) e processo della posta (segnale ogni 15 secondi) lo segnalano come "unhealthy" se non risponde.

Aggiornamenti

Orafila:

deploy/nova.sh update

Il comando controlla la memoria, fa un backup di sicurezza, scarica la nuova versione con git, ricostruisce l'immagine e riavvia; le migrazioni del database si applicano da sole all'avvio. Si rifiuta di partire se qualcuno ha modificato a mano i file del repository sul server (li elenca). L'interruzione del servizio è di pochi istanti al riavvio dei contenitori.

Sistema operativo e Docker: gli aggiornamenti di sicurezza si installano da soli ogni giorno. Se al login compare *** System restart required ***, riavviate (sudo reboot): dopo un paio di minuti tutto riparte da solo; controllate con deploy/nova.sh status.

Una volta al mese, le immagini di base (database, Caddy, Node.js), che contengono correzioni di sicurezza:

cd deploy && docker compose pull db caddy && docker compose build --pull && cd ..
deploy/nova.sh up

Spazio su disco: up (e quindi update) cancella ogni volta la versione precedente dell'immagine, e la cache di costruzione quando restano meno di 4 GB liberi. Per liberare spazio prima: docker builder prune -af.

Mai usare docker compose down -v, docker volume rm o docker system prune --volumes: cancellano il database.

Backup

• Automatico ogni notte alle 02:30 (ora italiana, più al massimo 15 minuti casuali), dopo deploy/nova.sh install-timer; se il server era spento, parte alla riaccensione.
• A mano in qualunque momento: deploy/nova.sh backup. Elenco: deploy/nova.sh backups.
• Ogni backup è il database completo (tutte le aziende), cifrato con age, verificato e poi copiato nel bucket se configurato. Restano gli ultimi 7 sul server e 30 giorni nel bucket (valori modificabili).
• I nomi sono data e ora UTC: nova-20261020T013000Z.dump.age.
• I backup contengono i dati; gli utenti del database no: dopo un ripristino su un server nuovo le password del database possono essere nuove.

Custodia delle chiavi (nel gestore di password, fuori dal server):

1. la chiave privata dei backup (deploy/secrets/backup.agekey);
2. APP_ENCRYPTION_KEY;
3. consigliato: tutto deploy/.env, aggiornato a ogni modifica.

Ripristino

Sullo stesso server (per esempio per tornare a uno stato precedente):

deploy/nova.sh restore nova-AAAAMMGGTHHMMSSZ.dump.age --yes [--key ~/chiave-salvata.txt]

Il ripristino fa prima un backup di sicurezza dello stato attuale, ferma app e processo della posta, carica il backup in un database temporaneo che sostituisce quello attuale solo se il caricamento riesce (con un database esterno, in una sola transazione), applica le migrazioni più recenti del backup, riavvia e aspetta che i servizi siano in salute. Se la chiave non apre il backup si ferma prima di cambiare qualunque cosa. Tutte le aziende dell'installazione tornano allo stato del backup.

Su un server nuovo (server perso o guasto):

1. nuovo server, record DNS aggiornato al nuovo IP, pacchetto scaricato, sudo deploy/setup-host.sh;
2. chiave privata dei backup rimessa in deploy/secrets/backup.agekey e deploy/.env ricreato dal gestore di password (almeno APP_ENCRYPTION_KEY e i dati del bucket);
3. deploy/nova.sh init --domain ... --email ... per completare i valori mancanti, poi deploy/nova.sh up;
4. deploy/nova.sh backups e deploy/nova.sh restore <ultimo file del bucket> --yes: il file viene scaricato dal bucket, controllato e ripristinato;
5. deploy/nova.sh install-timer.

Gli utenti entrano con la loro password e il loro codice di verifica, come prima. Se nessuno riesce a completare la verifica in due passaggi, APP_ENCRYPTION_KEY non è quella del server di origine. I passi dettagliati sono nelle guide Oracle e DigitalOcean.

Provate il ripristino all'avvio del servizio, con la copia della chiave custodita nel gestore di password: un backup mai ripristinato non dà garanzie.

Se si sospetta un'intrusione nel server

Considerate compromesso tutto ciò che era sul server: deploy/.env (password del database, chiavi del bucket e dell'AI, APP_ENCRYPTION_KEY) e la chiave dei backup.

1. Fermate il server dalla console del fornitore, senza cancellarlo.
2. Revocate la deploy key del repository, la chiave di accesso al bucket e le chiavi dei fornitori AI; createne di nuove.
3. Ricostruite su un server nuovo con password del database, segreto del gateway e chiave dei backup nuovi (tenendo APP_ENCRYPTION_KEY, che serve a leggere i dati) e ripristinate l'ultimo backup precedente all'intrusione, aperto con la vecchia chiave dei backup.
4. Nell'applicazione: cambiate le password delle caselle di posta (prima presso il fornitore di posta, poi in Code e posta) e fate azzerare la verifica in due passaggi a tutti gli utenti (Impostazioni › Utenti), eventualmente anche l'accesso.
5. Valutate con il consulente privacy la notifica della violazione (art. 33-34 GDPR).

Attività dell'operatore della piattaforma

Queste operazioni compaiono nel registro attività dell'azienda con l'autore «Sistema».

Supporto agli utenti (amministratori dell'azienda)

Problemi frequenti