Salta al contenuto

Documentazione

Aggiornamenti dell’agente

L’agente si aggiorna secondo un orario che si imposta, oppure nel momento in cui si preme il pulsante. Questa pagina spiega che cosa rende affidabile una versione, quando la piattaforma ne consegna una da sola e come installarne una a mano.

Che cosa rende affidabile una versione

Due fatti indipendenti devono coincidere prima che un nuovo binario giri sul suo host: il suo hash deve corrispondere al valore pubblicato dalla piattaforma e deve portare una firma valida sui suoi byte grezzi, prodotta con la chiave di rilascio della piattaforma.

  • Il checksum dimostra che il download è integro. Non dice nulla su chi lo ha prodotto.
  • La firma dimostra chi lo ha prodotto. Viene controllata dall’agente prima che qualcosa venga preparato, e di nuovo da uno script che solo root può modificare prima che il binario venga installato.
  • La chiave pubblica usata da quel secondo controllo è di proprietà di root. L’utente di sistema con cui gira l’agente non può sostituirla, quindi compromettere l’agente non basta comunque per far eseguire un binario come root.
  • Una versione senza firma viene rifiutata. Lo stesso vale per una versione la cui firma non corrisponde, anche quando il checksum corrisponde.

Aggiornare dal pannello

Quando un agente non è aggiornato, il pannello lo segnala in cima alla sua pagina e nell’elenco degli agenti. Premendo il pulsante, la piattaforma consegna all’agente un link di download di breve durata attraverso la connessione già aperta.

  • Un solo agente: il banner sulla sua pagina oppure il riquadro di aggiornamento nella scheda delle impostazioni.
  • Più agenti insieme: li selezioni nell’elenco degli agenti e aggiorni la selezione. Il numero sul pulsante comprende soltanto gli agenti che possono essere davvero aggiornati in questo momento.
  • La dashboard ha un pulsante diretto per ogni agente non aggiornato, così non deve andarlo a cercare.
  • L’avanzamento sopravvive a un ricaricamento della pagina: viene letto dal comando in esecuzione, non da qualcosa che il browser ricorda.
Un agente offline non può essere aggiornato. Il pulsante resta visibile con il motivo accanto, perché è comunque utile sapere che un aggiornamento è in attesa.

L’orario notturno

Ogni agente ha un orario, e di serie è attivo alle 03:00, ora dell’Europa centrale. Se a uno degli orari impostati esiste una versione più recente, la piattaforma la consegna a quell’agente come fa il pulsante. Il resto non cambia: lo stesso binario firmato, gli stessi controlli sull’host, lo stesso ritorno indietro.

  • Più orari per agente, al massimo sei, su una griglia di cinque minuti. Sei bastano per ogni quattro ore e sono abbastanza pochi da leggersi a colpo d’occhio.
  • Gli orari si leggono sullo stesso orologio a muro del resto del pannello. Un orario che non esiste nella notte in cui l’ora va avanti gira un’ora più tardi anziché essere saltato, e un orario che esiste due volte gira una volta sola.
  • C’è una finestra di recupero di quindici minuti e non di più. Un aggiornamento pensato per le 03:00 non lo si vuole alle 09:00: la notte era stata scelta apposta.
  • Un agente che al suo orario era fuori linea salta la notte senza consumare il suo turno, e prende il successivo. Un agente raggiungibile ma già aggiornato il turno lo consuma eccome, così la sua storia mostra che qualcuno ha guardato.
  • Al massimo cinque agenti di uno stesso account partono al minuto. Una flotta di quaranta scarica circa 22 MB ciascuno, da una sola rete, e distribuirlo su otto minuti sta dentro la finestra di recupero.
  • Arriva una notifica quando un aggiornamento pianificato riesce e quando uno fallisce, raggruppata per account. Un agente che fallisce si segnala al massimo una volta al giorno, così un host bloccato non riempie le notifiche con la stessa frase.
Il pulsante non sparisce. Un aggiornamento pianificato e un pulsante premuto sono la stessa operazione, e la pagina dell’agente tiene una storia degli ultimi dieci, orario e pulsante in un unico elenco.

Che cosa succede sull’host

L’agente scarica accanto a sé il nuovo binario, ne verifica checksum e firma e solo allora termina. Systemd riavvia il servizio, un passaggio di proprietà di root controlla ancora una volta il binario preparato, lo installa in modo atomico e verifica che parta davvero prima di mantenerlo. Se una di queste fasi non riesce, il vecchio binario resta al suo posto e il servizio riparte con quello.

Farlo a mano

Non è obbligatorio usare il pannello. Tutto ciò che fa il pulsante si riduce anche a una manciata di comandi, e il pannello li stampa già compilati con il checksum e la firma attuali. I due passaggi da conservare quando se ne scrive uno script sono quelli di verifica:

I comandi e l’output del terminale sono in inglese ovunque, nel pannello e in queste pagine. Un solo testo, una sola verità: quello che legge qui è letteralmente ciò che il suo host le restituirà.

Verificare il checksum di ciò che è stato scaricato.

shell
echo "<sha256-from-the-panel>  provibr-agent-linux-x86_64" | sha256sum -c -

Verificare la firma con la chiave pubblica presente sull’host. È il passaggio che un semplice download non dà, ed è quello che conta.

shell
openssl pkeyutl -verify -pubin -inkey /usr/local/lib/provibr-agent/license-signing.pub -rawin \
  -in ./provibr-agent-linux-x86_64 -sigfile ./provibr-agent-linux-x86_64.sig
Le installazioni precedenti all’introduzione della firma richiedono di eseguire l’installer ancora una volta, per collocare la chiave pubblica e l’unità di servizio aggiornata. Fino ad allora il pannello rifiuta l’aggiornamento con un motivo chiaro, invece di fallire a metà strada.