Aggiornamenti

Sirio può aggiornarsi da solo da Impostazioni → Aggiornamenti. Le release arrivano da un server degli aggiornamenti privato che gestisci tu: file statici in HTTPS, dietro basic auth HTTP, con una credenziale per ogni installazione. Il repository è privato, quindi i link alle release di GitHub richiedono un’autenticazione, e un token GitHub su ogni server permetterebbe a ciascuno di leggere tutto il sorgente. Una chiave di installazione può solo scaricare le release, e si può revocare per una macchina senza toccare le altre.

Una release diventa installabile per la sua firma, non per il server da cui arriva. Il checksums.txt di ogni release è firmato con una chiave ed25519 che non lascia mai la macchina di chi pubblica, e la parte pubblica è compilata dentro Sirio. Chi prende il controllo del server degli aggiornamenti, o si impossessa di una chiave di installazione, può trattenere gli aggiornamenti ma non può far installare un binario.

Collegare un’installazione

Apri Impostazioni → Aggiornamenti e inserisci l’indirizzo del server degli aggiornamenti (es. https://aggiornamenti.esempio.it) e la chiave di installazione, <nome>:<segreto>, fornita da chi gestisce il server. La chiave viene salvata cifrata e non viene più mostrata; la scheda ne mostra solo il nome. Revocarla sul server taglia fuori solo quell’installazione.

Come si svolge un aggiornamento

1. Sirio legge l’index.json del server ogni 6 ore (o quando premi Controlla ora) ed elenca le release più recenti di quella in esecuzione.
2. Quando ne installi una (o lo fa la politica automatica), Sirio la scarica in /var/lib/sirio/update/staging, verifica firma e checksum, e deposita una richiesta con la versione. Da solo non può fare altro: gira come utente non privilegiato con ProtectSystem=strict, dove /usr/local/bin è in sola lettura.
3. La unit sirio-update.path avvia sirio-update come root. L’helper copia la release fuori dalla directory di Sirio e la verifica di nuovo, con le chiavi di release del binario già installato (di root, quindi è di lui che fidarsi). Rifiuta anche una release che non sia più recente, così una release vecchia ma firmata davvero non può servire a tornare indietro.
4. Ferma Sirio, fa una copia del binario (/usr/local/lib/sirio/sirio-sysadmin.prev) e del database (/usr/local/lib/sirio/rollback/), poi esegue l’install.sh della release stessa con il binario scaricato. È lo stesso script di un’installazione a mano, quindi si aggiornano anche unit e helper, e le impostazioni nel drop-in restano.
5. Aspetta che la nuova versione diventi “active” e resti tale per 15 secondi senza che systemd la riavvii, sulla versione attesa. Se non succede, o se install.sh fallisce, rimette il binario e il database precedenti e riavvia Sirio: l’aggiornamento risulta ripristinato, con il motivo.

Il pannello resta irraggiungibile per circa mezzo minuto. La pagina Impostazioni continua a interrogarlo durante il riavvio e si ricarica da sola sulla nuova versione.

Un aggiornamento riavvia Sirio, il che interrompe le esecuzioni delle pipeline e i backup, quindi li aspetta. Un aggiornamento manuale viene rifiutato finché ce n’è qualcuno in coda o in corso, uno automatico viene rimandato finché non ce ne sono più.

Solo gli amministratori vedono la scheda Aggiornamenti e i suoi endpoint. Aggiornare sostituisce il binario di cui si fidano gli helper di root, quindi non è un permesso assegnabile.

Aggiornamenti automatici

Impostazioni → Aggiornamenti → Aggiornamenti automatici stabilisce quanto grande può essere il passo che Sirio fa da solo:

Impostazione	Installa da solo
Disattivati (predefinito)	niente: controlla e mostra cosa c’è
Patch	v1.4.2 → v1.4.3
Minor	anche v1.4.2 → v1.5.0
Major	ogni release, v2.0.0 compresa

I livelli si leggono alla lettera dai tag: v0.14.0 → v0.15.0 è un passo minor, anche se semver permette a una minor 0.x di rompere qualcosa. La release più recente che la politica permette viene installata appena non c’è niente in corso. Una release fallita o ripristinata non viene ritentata in automatico: installala a mano, o aspetta la successiva. Le build di sviluppo (non esattamente un commit con tag) non si aggiornano mai da sole.

Il protocollo

Cosa chiede Sirio al server degli aggiornamenti, per chi volesse servirlo in un altro modo:

• GET <server>/index.json → {"releases": [{"version": "v0.15.0", "date": "2026-10-20T10:00:00Z", "notes": "…"}]}. Le voci che non sono vX.Y.Z vengono ignorate.
• GET <server>/releases/<versione>/<file> per checksums.txt, checksums.txt.sig (firma ed25519 in base64 dei byte esatti di checksums.txt), install.sh e sirio-sysadmin-<versione>-linux-<arch>.
• Ogni richiesta porta la basic auth (nome e segreto dell’installazione) e un User-Agent: sirio-sysadmin/<versione> (linux/<arch>). 401 o 403 significa chiave rifiutata. I redirect vengono seguiti, senza credenziali se puntano a un altro host.
• L’indirizzo deve essere https. http in chiaro è accettato solo verso loopback, per i test.

Dove stanno le cose

• /var/lib/sirio/update/: staging/ (la release scaricata, rimossa dopo un aggiornamento riuscito), request, result, update.log (il download) e install.log (l’installazione). L’helper li legge e li scrive come utente di Sirio, mai come root (vedi sicurezza.md).
• /usr/local/lib/sirio/sirio-sysadmin.prev e /usr/local/lib/sirio/rollback/: il binario e il database precedenti, conservati fino all’aggiornamento successivo.
• journalctl -u sirio-update: l’output dell’helper.
• SIRIO_UPDATES_ENABLED=false toglie la sezione; SIRIO_UPDATE_HELPER indica un helper installato altrove.

Un ripristino rimette binario e database, non unit e helper: restano quelli della nuova release. install.sh li mantiene compatibili con la release precedente, e un install.sh più vecchio non si può rieseguire senza la sua release.

La chiave di installazione è decifrabile da qualunque cosa giri come utente di Sirio, step shell delle pipeline compresi. È accettabile perché apre solo i download delle release, ed è il motivo per cui ogni macchina ha la sua.