Vai al contenuto

Impostazioni cookie

Scelga per ogni tipo quali cookie consente. Può modificare la sua scelta in qualsiasi momento tramite Impostazioni cookie in fondo a ogni pagina. Informativa sulla privacy

Necessari

Sempre attivi

Servono per accedere, conservare il carrello e ricordare le sue scelte. Sono sempre attivi.

Quali cookie?
  • weboke_sessie, weboke_klant, weboke_remember: la sua sessione e la permanenza dell'accesso
  • weboke_basket: il suo carrello
  • wkBtwIncl: visualizzazione dei prezzi con o senza IVA
  • wok_cookies: la sua scelta sui cookie, 12 mesi

Misurano quale annuncio porta a una visita o a un ordine, così non paghiamo annunci che non funzionano.

Quali cookie?
  • Google Ads tramite Google Tag Manager (_gcl_au, _gcl_aw), fino a 90 giorni
  • OpenAI Ads, annunci in ChatGPT
  • wok_aff: tramite quale partner è arrivato da noi (programma di affiliazione), 60 giorni

4,6

Paese e lingua

Ogni paese ha il suo sito, con i prezzi e l'IVA di quel paese.

Vedi

Ciclo di vita e upgrade di release

Modulo 4: Software e aggiornamenti · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione saprà verificare il ciclo di vita della Sua distribuzione, saprà che cosa significa "end of life" per il Suo server e saprà pianificare ed eseguire in sicurezza un upgrade di release.

Concetti chiave: release, LTS, supporto standard, Debian LTS, Ubuntu ESM e Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, upgrade minimo e completo, repository di terze parti, snapshot, curl | bash

Ogni release ha una data di scadenza

Gli aggiornamenti automatici (lezione 4.2) funzionano solo finché la Sua distribuzione produce ancora aggiornamenti per la Sua versione. Ogni release di Debian e Ubuntu riceve aggiornamenti di sicurezza per un periodo fisso. Poi si ferma: il Suo server non riceve più correzioni, nemmeno per vulnerabilità gravi. Questo si chiama end of life (EOL).

Per vedere quale versione ha, usi:

anna@web1:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
...

Su Ubuntu compare per esempio VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian supporta pienamente una release per circa tre anni. Dopodiché subentra il team Debian LTS per altri due anni, con aggiornamenti di sicurezza per i pacchetti più usati. Per le release attuali (situazione a novembre 2026, da verificare su debian.org/releases):

ReleasePubblicataFine supporto ordinarioFine LTS
Debian 13 "trixie"9 agosto 2025agosto 202830 giugno 2030
Debian 12 "bookworm"10 giugno 202311 luglio 202630 giugno 2028

Debian 12 riceve quindi ancora aggiornamenti tramite LTS, ma è nella fase finale. Un nuovo server lo installi su Debian 13.

Ubuntu

Ubuntu pubblica ogni due anni, ad aprile, una release LTS (Long Term Support), con cinque anni di manutenzione di sicurezza standard. Con un abbonamento Ubuntu Pro (gratuito per uso personale su alcune macchine) si aggiunge ESM (Expanded Security Maintenance), fino a dieci anni in totale.

ReleaseSupporto standard fino aCon ESM fino a
Ubuntu 26.04 LTSmaggio 2031maggio 2036
Ubuntu 24.04 LTSmaggio 2029maggio 2034

Tra una release LTS e l'altra escono versioni intermedie (come la 25.10) con solo nove mesi di supporto. Non sono pensate per un server che deve funzionare per anni. Per un server scelga sempre una LTS.

Che cosa significa EOL per Lei

Un server su una release che non riceve più aggiornamenti continua a funzionare normalmente. Ed è proprio questo l'aspetto insidioso: non si accorge di nulla, finché qualcuno sfrutta una vulnerabilità corretta ovunque tranne che da Lei. Inoltre:

  • il nuovo software (una nuova versione di PHP, una nuova release di Docker) non viene più compilato per la Sua release;
  • anche i repository di terze parti smettono, spesso prima;
  • più aspetta, più grande è il salto. Debian non supporta il salto di una release: da 11 a 13 si deve passare per la 12.

Segni quindi la data EOL del Suo server in agenda, con un promemoria sei mesi prima.

Due strade: aggiornare o ricostruire

Ci sono due percorsi puliti verso una nuova release.

  1. Upgrade in-place: aggiorna il server esistente alla nuova release. È rapido e tutto resta al suo posto, ma anche vecchi residui e personalizzazioni vengono portati con sé.
  2. Ricostruire da zero: crea un nuovo server con la nuova release, vi reinstalla i Suoi servizi (comodo con gli appunti della lezione 10.4 o con Docker Compose, modulo 9), trasferisce i dati dal Suo backup e cambia il DNS (lezione 7.1). Più lavoro, ma il risultato è pulito ed è al tempo stesso un test del Suo backup.

Per un piccolo server con pochi servizi un upgrade in-place va benissimo. Se gira molto software personalizzato, o se il server è già stato aggiornato più volte, valuti invece di ricostruirlo.

Preparare un upgrade in-place

Prima di iniziare, si assicuri di queste cinque cose:

  1. Uno snapshot nel pannello del Suo provider, subito prima di iniziare, e un backup recente fuori dal server (modulo 8). Uno snapshot è la Sua via rapida per tornare indietro se l'upgrade si interrompe a metà.
  2. Un secondo accesso: la console del Suo provider. Lavora via SSH, e se le impostazioni di rete o il server SSH cambiano durante l'upgrade, vorrà poter proseguire dalla console. Le note di rilascio di Debian lo dicono esplicitamente: predisponga in anticipo un altro modo per accedere.
  3. Leggere le note di rilascio, soprattutto il capitolo "Issues to be aware of". Per Debian 13 vi si trova per esempio: /tmp ora risiede di default in memoria, /etc/sysctl.conf non viene più letto (usi /etc/sysctl.d/) e /boot deve essere abbastanza grande.
  4. Controllare i repository di terze parti. I pacchetti che non provengono da Debian o Ubuntu stessi possono entrare in conflitto durante l'upgrade. Verifichi quali repository ha (ls /etc/apt/sources.list.d/) e se il produttore offre già una versione per la nuova release.
  5. Una sessione che sopravviva a una connessione interrotta. Avvii l'upgrade in tmux o screen. Se cade la Sua connessione internet, l'upgrade prosegue e può riprenderlo con tmux attach.

Debian: i passaggi

Dalle note di rilascio di Debian 13, per un upgrade dalla 12 alla 13:

root@web1:~# apt update && apt full-upgrade          # prima aggiornare completamente la release attuale
root@web1:~# sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
root@web1:~# apt update
root@web1:~# apt upgrade --without-new-pkgs          # aggiornamento minimo
root@web1:~# apt full-upgrade                        # aggiornamento completo
root@web1:~# reboot

Se usa ancora /etc/apt/sources.list, modifichi lì il nome in codice. I repository di terze parti li disattivi temporaneamente durante l'upgrade (rinominandoli in .disabled) e poi li riattivi con il nome in codice della nuova release, se il produttore lo prevede.

Durante l'upgrade presti attenzione alle domande sui file di configurazione. Se ha modificato un file di persona, come sshd_config, dpkg Le chiede se vuole mantenere la Sua versione. Mantenga la Sua versione se sa perché l'ha modificata, e poi la confronti con quella nuova (.dpkg-dist).

Dopo il riavvio:

anna@web1:~$ cat /etc/os-release | grep VERSION=
VERSION="13 (trixie)"
anna@web1:~$ systemctl --failed
anna@web1:~$ sudo apt autoremove

systemctl --failed (lezione 6.1) deve risultare vuoto. Verifichi anche che i Suoi siti web e container funzionino e che il Suo monitoraggio (lezione 8.3) sia verde.

Ubuntu: do-release-upgrade

Ubuntu ha un programma apposito:

anna@web1:~$ sudo apt update && sudo apt full-upgrade
anna@web1:~$ sudo do-release-upgrade

Due cose da sapere. Primo: Ubuntu propone l'upgrade da una LTS alla successiva solo dopo la prima point release (per esempio la 26.04.1, qualche mese dopo aprile). È una scelta voluta: nei primi mesi vengono risolti i problemi più grossi. Secondo: se esegue l'upgrade via SSH, do-release-upgrade avvisa che per sicurezza avvia un server SSH aggiuntivo su una porta di riserva. Quella porta deve poter passare attraverso il Suo firewall (lezione 5.2) se ne ha bisogno; di solito non serve, perché ha la console.

La grande trappola: software esterno alla distribuzione

Gli upgrade falliscono quasi sempre per colpa di software che non proviene dalla distribuzione. Tre abitudini fanno la differenza:

  • Niente curl https://... | bash. Uno script preso da internet ed eseguito direttamente come root può modificare qualsiasi cosa sul Suo server: aggiungere repository, considerare affidabili chiavi per tutti i repository, sovrascrivere file. Non sa che cosa è successo, e al prossimo upgrade qualcosa si rompe. Scarichi uno script del genere, lo legga ed esegua piuttosto i passaggi di persona.
  • Un repository aggiuntivo solo dal produttore stesso, con una chiave propria (Signed-By, lezione 4.1), e annoti nella documentazione del server perché è presente.
  • Nessun file .deb isolato scaricato da siti web se lo stesso software è disponibile dalla distribuzione o dal repository del produttore. Quei file non ricevono mai aggiornamenti.

Su AlmaLinux e Rocky Linux

Una versione "major" (9, 10) riceve lì circa dieci anni di aggiornamenti, e le versioni intermedie (9.6, 9.7) si aggiornano normalmente con dnf upgrade. Un salto in-place a una nuova versione major è possibile con lo strumento ELevate (AlmaLinux), ma molti amministratori, per il passaggio a una nuova versione major, preferiscono comunque ricostruire da zero.

In pratica

Nella schermata VPS di WebOké crea uno snapshot prima di un upgrade (al massimo due alla volta, sullo stesso storage del Suo VPS) e dispone della console come secondo accesso. Presso altri provider i nomi sono simili: snapshot, console VNC o web, rescue. Uno snapshot non sostituisce un backup fuori dal server; lo elimini quando tutto funziona, perché cresce con ogni modifica.

Riepilogo

  • Ogni release riceve aggiornamenti di sicurezza per un periodo fisso; poi diventa end of life e il Suo server non riceve più correzioni.
  • Debian: circa tre anni più due anni di LTS; Ubuntu LTS: cinque anni più ESM fino a dieci. Per un server scelga sempre una LTS e segni la data di fine supporto in agenda.
  • Prepari un upgrade con uno snapshot, un backup, la console, le note di rilascio e una sessione tmux.
  • Debian: repository al nuovo nome in codice, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, dopo la prima point release.
  • Il software esterno alla distribuzione è la principale fonte di problemi negli upgrade: niente curl | bash, solo repository del produttore con una chiave propria.

Quiz

1. Il Suo server gira ancora su una release Debian di cui è terminato anche il periodo LTS. Tutto funziona. Qual è il problema?



2. Perché è preferibile eseguire un upgrade di release via SSH in tmux o screen?



3. Vuole passare da Debian 11 a Debian 13. Qual è il percorso corretto?



4. A maggio il Suo server Ubuntu 24.04 non propone l'upgrade alla 26.04, anche se è già uscita. Perché?



5. Una guida su internet dice: "Installi tutto con curl https://get.example.net/install.sh | sudo bash." Qual è la scelta migliore?



Esercizio

Esercizio O4.3: Il Suo piano di upgrade. Verifichi su quale release gira il Suo server e fino a quando riceve aggiornamenti di sicurezza. Poi prepari un piano di upgrade: quali repository di terze parti ha, come crea uno snapshot e un backup, come accede tramite la console, quali passaggi esegue, come verifica il risultato, e se sceglie un upgrade in-place o la ricostruzione da zero (con motivazione)?

Esercizio O4.3: Il Suo piano di upgrade

Questo esercizio lo svolge da sé; nessuno lo verifica. Spunti ciò che ha fatto e segni l'esercizio come completato.




Le Sue spunte e note restano solo in questo browser; non le inviamo da nessuna parte. Se ha effettuato l'accesso, conserviamo in I miei corsi solo il fatto che ha svolto l'esercizio.

Per approfondire

Un momento…

Configuri i suoi domini

Per ogni dominio imposti i nameserver, il collegamento al suo hosting e chi ne diventa l'intestatario.

Caricamento dei suoi domini…