Le alternative a CentOS procedono: Rocky Linux lancia la prima release candidate, AlmaLinux dispone del supporto a pagamento

Le alternative a CentOS procedono: Rocky Linux lancia la prima release candidate, AlmaLinux dispone del supporto a pagamento

Dopo l'annuncio della dismissione di CentOS da parte di Red Hat, due principali eredi sono comparsi: Rocky Linux, che è ora alla prima release candidate, e AlmaLinux, che ha recentemente lanciato il supporto a pagamento

di pubblicata il , alle 18:51 nel canale Device
Linux
 
11 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Tasslehoff19 Maggio 2021, 01:04 #11
Originariamente inviato da: WarSide
Non ho scritto il contrario. Nel momento in cui il supporto scade e non ci sono aggiornamenti di sicurezza, la macchina va rifatta. Spesso non viene fatto perché i sistemisti sono pagati a cottimo ed il cummenda di turno non vuole sganciare soldi "perché tanto funziona, perché toccarlo?"
Certamente c'è anche questo scenario, come ce ne sono tanti altri, es non c'è budget, chi paga il rifacimento della macchina?
Oppure il setup è il frutto di anni di lavoro, patch su patch custom rilasciate dal supporto di [metti multinazionale big IT a caso] a seguito di ticker sanguinosi e niente di tutto questo è documentato.
Oppure non ci sono più gli installer o non vi si ha accesso perchè nessuno ha rinnovato la tal subscription, etc etc.

Insomma gli scenari sono tanti, quella che descrivi se vogliamo è la migliore delle ipotesi, no moneta no cammello, e di certo se sei pagato per fare manutenzione ordinaria o presidio non regali un setup da zero, quello giustamente te lo fai pagare e bene.

Non aggiorni l'OS di un server ogni 6 mesi rifacendo la macchina proprio perché non vuoi dover ritestare gli applicativi su uno stack software (OS+libs) differente. Usando Centos stream, uno yum update in pratica ti installa le nightly builds di RH, sei veramente così entusiasta di fare la cavia in ambienti di produzione?

Poi quando tutto sarà containerizzato e l'host sarà solo un "lancia container", allora questo discorso sarà superato. Purtroppo non è ancora così.
Capiamoci, non ho detto che ne sono entusiasta, però non ci vedo nemmeno questa tragedia epocale.
Anche a me è capitato di avere qualche problema per un update (l'ultima volta credo sia successo un paio di anni fa per un update di php, rollback immediato, dopo poche ore c'era già una fix, fantascienza anche per il prodotto commerciale più avanzato e strapagato) però oggettivamente dalla mia esperienza sono casi veramente rari.

Sullo scenario che descrivi riguardo ai container io onestamente non sono così ottimista, non lo vedo così rosa e fiori, anzitutto perchè aggiornare un container non è a costo zero (in termini di effort) o quantomeno è largamente superiore rispetto all'uso di un package manager schedulato.
In secondo luogo dalla mia esperienza anche la riproducibilità di un servizio che gira dentro un container non è sempre garantita, a me ne sono capitati parecchi di scenari in cui due ambienti, con gli stessi container, stessa versione di docker (o altro servizio simile), stessi parametri (o file yaml nel caso di docker-compose), si comportano in modo diverso e tocca tutte le volte ritoccare qualcosa.
Sul rollback nella gran parte dei casi cambia poco o nulla rispetto ad uno scenario tradizionale, per il semplice fatto che tolte le applicazioni totalmente stateless (che nel mondo reale sono più una teoria che realtà, perchè 9 volte su 10 qualche repository ce l'hai sempre, che sia un db o un volume persistente) in molti casi aggiornare un sw (aggiornando il container sulla base di una immagine con una nuove versione del prodotto) significa toccare qualcosa anche sul repository dove stanno i dati, sia che si tratti di qualche ddl per aggiornare la struttura del db o qualche modifica alla struttura dei file.

Repo sconosciuti e controversi === peracottaro. Se hai bisogno di lib molto diverse per i tuoi servizi o ospiti servizi eterogenei sullo stesso server, vai di virtualizzazione/containerizzazione oppure di compilazione statica delle lib.
Ok però oggettivamente trovami qualcuno che avendo a disposizione un repository yum o apt si mette a ricompilare da sorgenti.
La ricompilazione la facevo ai tempi di RedHat 7 (la prima, non RHEL), a meno di avere esigenze talmente specifiche da non essere soddisfatte dai binari disponibili sui repo trovo veramente difficile che qualcuno si metta a ricompilare.
E questo per mille motivi, anzitutto per una questione di costi, ripetere il tutto ad ogni aggiornamento poi diventa ingestibile, e francamente rispetto a un sw che si aggiorna manualmente ogni morte di papa preferisco un repo conosciuto, anche se non certificato o che abbia un controllo di qualità di livello RedHat.

Per fare un esempio che credo molti abbiano sperimentato, in ambito RHEL e derivate praticamente EPEL è un repository necessario, è impensabile lavorare senza e francamente da quando è disponibile non ho trovato una singola macchina RHEL o CentOS che non l'avesse usato, non solo, spesso si trovano specifiche indicazioni di installarlo anche in prodotti enterprise per soddisfare dipendenze.
Vogliamo parlare della qualità dei binari distribuiti tramite Epel? Alcuni sono talmente obsoleti da essere imbarazzanti, sulla stabilità di altri ci sarebbe molto da discutere.

O prendiamo php, volente o nolente praticamente chiunque usa Remi repo, io trovo che il lavoro che c'è dietro sia ammirevole, e di una qualità in termini di supporto che veramente bagna il naso a multinazionali multimiliardarie, però non si può certo dire che sia all'altezza di standard di livello RHEL o Ubuntu LTS in termini di solidità, in fin dei conti è un tizio (che tra l'altro mi pare lavori in RedHat) che nel tempo libero fa tutto questo.

Ti dico cosa ho visto spesso in giro: server con versione di ubuntu non LTS, server con fedora non aggiornati e non aggiornabili pena applicativi che si spaccano. In quel caso, non avendo OS stabile e supporto per anni, sei fottuto e ti tocca rifare la macchina e metter mano agli applicativi.
Non lo metto in dubbio, però capiamoci, sono casi un po' diversi.
Un conto se parliamo di un sistema operativo installato ora, su una distribuzione attuale, con aggiornamenti attivi e costanti, servizi che ci girano sopra le cui dipendenze sono costantemente aggiornate, etc etc...
Altra cosa se parliamo di macchine mai aggiornate per anni, dove chiaramente lanciare un apt upgrade o yum update sarebbe cosa davvero azzardata.

Ben inteso, ne ho viste tante anch'io in quello stato, però non è un problema dell'os instabile, ma di un percorso di upgrade che non è stato seguito.
Ma lo stesso l'ho visto su Windows, mai aggiornati per anni e dove il cluster active/passive scoppia.

Centos Streams va avanti con rolling release e gli aggiornamenti sono le nightly builds di RH.

1. Puoi trovarti in situazioni dove gli aggiornamenti ti spaccano gli applicativi installati e ti tocca capire cosa ha spaccato cosa e perché e fare rollback degli update.
2. Tu sei veramente tranquillo sapendo che sul server ci finiscono delle nightly builds? Ok che sono NB di RH, ma cavolo, son sempre NB.

Insomma, come non userei mai una Ubuntu non LTS o una Fedora, non installerei mai CentOS Stream su un server.
Come ti dicevo io da anni ho deciso di applicare la politica "updates no matter what" e francamente di problemi ne avrò avuti un paio in anni e anni e presso tanti clienti e tanti scenari diversi; e non parlo solo di updates ufficiali di Rhel o della vecchia CentOS, ma anche di package installati con Epel, remi, rpmforge e altri.

Chiaramente non saprò mai quali problemi però ho evitato aggiornando sempre e comunque tutte le notti, soprattutto dal pdv della sicurezza.
Di certo c'è però che se si verifica un disguido per un package appena aggiornato è ovviamente spiacevole, ma se si verifica un problema per obsolescenza dei package o perchè non si aggiorna (e di solito lo vieni a scoprire a cose fatte perchè c'è una buona probabilità che si tratti di un problema di sicurezza) la situazione è decisamente più grave; i miei clienti tendono a essere moooolto più accondiscendenti nel primo caso, e giustamente molto meno nel secondo.

Riassumendo, rispetto al tua esperienza e concordo con te che lo scenario ideale sarebbe usare distribuzioni a prova di bomba (RHEL, Ubuntu LTS o Debian stable) però dal pdv tecnico non ci vedo tutto questo "casus belli", eticamente invece è un altro discorso e sono d'accordo al 100% con la polemica nata dopo le recenti decisioni di RedHat

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^