Il numero e la gamma di sistemi operativi supportati sono un fattore significativo per l'impegno che deve essere investito nel CI, nel packaging e nei numerosi test. È quindi necessario trovare un compromesso che concili le esigenze del maggior numero possibile di utenti con una CI efficiente. In passato, il risultato veniva determinato poco prima del rilascio di una versione di Checkmk. Dall'introduzione di Checkmk 2.2.0 abbiamo invece adottato una politica di supporto del sistema operativo. Questo fornisce agli utenti la sicurezza per la pianificazione dei futuri aggiornamenti di Checkmk e dei sistemi operativi supportati da questi. In particolare, gli utenti di Ubuntu dovrebbero leggere questo articolo.

Fino a Checkmk 2.1.0, la determinazione dei sistemi operativi supportati era una decisione individuale, basata su sondaggi tra gli utenti e sull'analisi dei dati di download. Da un lato, poteva accadere che le versioni di Ubuntu che erano state effettivamente dismesse (o trasferite a ESM) fossero ancora supportate su richiesta dei clienti. Dall'altro lato, sono state abbandonate le distribuzioni enterprise presenti sul mercato da molto tempo, ma che avrebbero ricevuto aggiornamenti durante il ciclo di vita dell'imminente versione di Checkmk.

Tempi definiti invece di decisioni individuali

A partire dal rilascio della versione 2.2.0, le tempistiche esplicite hanno sostituito la prassi precedente di prendere decisioni poco prima del rilascio.

Una nuova versione di Checkmk supporterà solo le distribuzioni il cui termine di supporto annunciato dal distributore è almeno tre mesi dopo la data di rilascio della versione principale di Checkmk.

Prendiamo in considerazione i seguenti periodi di supporto:

  • Le distribuzioni Enterprise (RHEL e i suoi derivati, così come SLES) sono tipicamente supportate dal distributore per un massimo di 10 anni.
    • RHEL: Supporto di manutenzione
    • SLES: LTSS
  • Per le distribuzioni comunitarie (Ubuntu e Debian), si applica il tipico periodo di 5 anni di supporto comunitario gratuito. Gli aggiornamenti a pagamento dopo questo periodo (ad esempio, l'ESM di Ubuntu) non sono esplicitamente coperti.
    • Ubuntu: LTS
    • Debian: LTS

Le versioni delle distribuzioni con meno di due anni di supporto totale da parte del distributore non saranno più supportate da Checkmk.

Inoltre, non vogliamo che il numero di versioni per distributore sfugga di mano: Se ci sono più di quattro versioni di una distribuzione da supportare contemporaneamente, non supporteremo quelle che esauriscono il supporto per prime fin dall'inizio o solo per un periodo limitato (che verrà annunciato al momento del rilascio di Checkmk). Nel caso di SLES, ad esempio, ciò significa che a partire dall'attuale versione 2.2 non avremmo supportato la versione 15 SP1:

illustrazione che mostra il ciclo di supporto di Checkmk 2.2.

Spiegazione del grafico: La barra rossa "12 SP4" indica la versione di SUSE non più supportata da Checkmk 2.2, il cui termine di supporto cade nel periodo di tre mesi successivo al rilascio. Delle barre verdi della 12 SP5 e della 15 SP1 fino alla SP4, la 15 SP1 è quella con la durata residua più breve e pertanto non dovrebbe più essere stata presa in considerazione nel rilascio della 2.2.

L'interruzione delle versioni della distribuzione con supporto molto breve riguarda principalmente le versioni STS ("Short Term Support") semestrali di Ubuntu, che ricevono aggiornamenti solo per nove mesi. Le versioni LTS, che vengono sempre rilasciate ad aprile di un anno pari, continueranno a essere pienamente supportate.

Niente più STS?

Nessuna regola senza eccezioni - o, per essere più precisi, un periodo di transizione ben ponderato. Quando abbiamo presentato questa politica alla conferenza Checkmk del giugno 2023, Checkmk 2.1.0 e 2.2.0 erano già stati rilasciati per Ubuntu 22.10 STS. Considerando che il downgrade di un Ubuntu STS alla LTS precedentemente rilasciata non è ufficialmente supportato, ci siamo subito resi conto che l'applicazione di questa politica avrebbe comportato inutili difficoltà per gli utenti che stavano già utilizzando le versioni 2.1.0 e 2.2.0 Beta su Ubuntu 22.10, perché l'unica soluzione pratica sarebbe stata quella di eseguire il backup, reinstallare e ripristinare.

Invece di effettuare il downgrade alla 22.04, stiamo quindi puntando a un aggiornamento morbido: 22.10 STS > 23.04 STS > 23.10 STS > 24.04 LTS. A partire dalla 24.04 LTS, gli utenti Ubuntu interessati rientreranno nel ciclo di rilascio e supporto delle versioni LTS, in modo da eliminare completamente il supporto per STS.

E il supporto hardware?

Un argomento popolare a favore di Ubuntu STS è il suo supporto hardware. Dopo tutto, Ubuntu 23.10 viene fornito con il kernel 6.5, mentre Ubuntu 22.04 con il kernel 5.15. Quest'ultimo è stato rilasciato nell'ottobre 2021 e quindi il supporto per l'hardware rilasciato negli ultimi due anni è piuttosto scarso.

Canonical è consapevole di questo problema e quindi dal 2016 ha effettuato il porting dei kernel delle versioni STS verso le ultime LTS poche settimane dopo il rilascio di STS. Sono quindi disponibili in quel momento come il pacchetto aggiuntivo

linux-generic-hwe-22.04 

A partire dalla dot release .2, quattro mesi dopo il primo STS successivo a una LTS, Canonical fornirà anche immagini di installazione con il kernel STS. In particolare: Ubuntu 22.04.2 a febbraio 2023 includerà il kernel di Ubuntu 22.10, Ubuntu 22.04.3 ad agosto 2023 includerà il kernel 6.2 di Ubuntu 23.04 e 22.04.4 includerà il kernel 6.5 di 23.10 a febbraio 2024.

Illustrazione del cerchio di supporto del kernel ubuntu

Quattro mesi dopo il rilascio di Ubuntu 24.04 LTS, Ubuntu 22.04.5 riceverà il suo kernel e non verranno rilasciati altri kernel STS. L'intero processo ricomincerà quindi da capo per Ubuntu 24.04.

Se dipendi dal supporto per l'hardware più recente, devi quindi sempre assicurarti di utilizzare le immagini di installazione più recenti. Se si lavora con debootstrap o con strumenti di creazione di immagini, assicurarsi di integrare il kernel HWE.

Opzioni flessibili per gli sviluppatori

È perfettamente comprensibile che agli sviluppatori piaccia utilizzare distribuzioni all'avanguardia, per poter disporre tempestivamente delle tecnologie più recenti ed essere in grado di individuare per tempo quali cambiamenti potrebbero causare problemi nelle versioni future della distribuzione.

Tuttavia, questo non significa che Checkmk debba essere offerto anche per ogni versione di STS. La virtualizzazione è il modo più flessibile per eseguire un sistema operativo LTS come guest su un Linux STS. Se si preferisce un'opzione più comoda, è possibile utilizzare le nostre immagini Docker già pronte.

Comoda pianificazione degli aggiornamenti

Anche se pianificare il futuro è ora più facile, in precedenza per aggiornare le vecchie installazioni di Checkmk era necessario ricercare quale versione di Checkmk fosse stata creata per quale versione di un sistema operativo. Per semplificare questo processo, abbiamo creato delle matrici di aggiornamento. Da queste è possibile vedere quando un aggiornamento di Checkmk deve essere combinato con un aggiornamento del sistema operativo e come gli aggiornamenti che riguardano diversi sistemi operativi o versioni di Checkmk possono essere eseguiti con il minor numero di passaggi. Ecco, ad esempio, una schermata della matrice di aggiornamento per la versione da 2.1.0 a 2.2.0 in Ubuntu:

schermata della matrice di aggiornamento di Checkmk dalla 2.1.0 alla 2.2.0 in Ubuntu

Occasionalmente riceviamo richieste di compilazione di versioni di Checkmk molto vecchie su versioni di sistemi operativi piuttosto recenti, o viceversa di un Checkmk relativamente nuovo in combinazione con una versione della distribuzione da tempo dismessa. Per rispondere a queste richieste, abbiamo incluso questi diagrammi in tutti i rami del nostro manuale. In particolare, questo significa che troverai tutte le informazioni necessarie per aggiornare anche un'installazione di Checkmk "dimenticata da qualche parte" nella versione 1.5.0 su Ubuntu 14.04 a una versione 2.2.0 attuale su Ubuntu 22.04.