Scaricare CentOS Stream 9: ISO e immagini cloud

CentOS Stream 9: quale immagine ti serve davvero

Se devi scaricare CentOS Stream 9, la prima scelta non è il mirror ma il tipo di immagine. In pratica hai tre famiglie utili: ISO per installazione classica, immagini cloud per ambienti virtualizzati o provider, e varianti minime o netinstall per chi vuole controllare tutto dal primo pacchetto. Sbagliare qui significa perdere tempo dopo, non prima.

La regola semplice è questa: ISO se stai installando su hardware fisico, VM con boot da DVD/virtual media o vuoi una procedura standard; cloud image se lavori in OpenStack, KVM, Proxmox, VMware o su un provider che accetta QCOW2/RAW; netinstall se vuoi un sistema ridotto e una repository policy precisa fin dal provisioning.

CentOS Stream non è un clone “congelato” del vecchio CentOS Linux: segue il flusso di sviluppo immediatamente precedente a Red Hat Enterprise Linux. Questo non è un difetto, ma va capito. Se cerchi stabilità statica da ciclo lungo, la strategia di update va valutata con più attenzione rispetto a una release puntuale tradizionale.

Dove prendere le immagini senza inventarsi mirror a caso

Il punto di partenza corretto è il sito ufficiale CentOS e i mirror elencati nella sua infrastruttura. Evita link presi da blog, forum o repository terzi se non hai un motivo preciso: per un download OS la fiducia nella sorgente conta quanto il checksum.

Per una verifica rapida del percorso ufficiale, il dominio da usare è quello del progetto CentOS. In genere troverai le immagini sotto i percorsi dedicati a Stream 9, con directory distinte per ISO, cloud e altarch. Il nome dei file cambia con le build, ma la struttura resta leggibile.

Se vuoi automatizzare, il metodo più pulito è usare il mirrorlist o il repository ufficiale del progetto, ma per un download manuale la pagina del progetto è più sicura e più facile da controllare a vista. Se il nome del file non include chiaramente architettura e tipo di immagine, fermati: non è la build che ti serve.

ISO, DVD, minimal e boot: non sono la stessa cosa

Le ISO di CentOS Stream 9 si dividono in modo abbastanza classico. La DVD ISO contiene un set ampio di pacchetti e permette installazioni offline o quasi offline. La Minimal ISO è più leggera e fa scaricare il resto dai repository durante l’installazione. La Boot ISO serve soprattutto come punto d’innesco per un’installazione via rete o tramite repository esterni.

La scelta cambia la postazione di lavoro. Su una macchina in datacenter con accesso Internet controllato, la minimal può essere perfetta. In un ambiente isolato, la DVD ISO evita blocchi durante il setup. Se invece stai preparando una golden image o un build pipeline, la boot ISO ha senso solo se hai già la repository interna pronta.

Un dettaglio che spesso si trascura: la ISO grande non è solo “più comoda”, è anche più prevedibile in ambienti con proxy, DNS non affidabile o repository filtrate. Se la rete è rumorosa, l’installazione minima può diventare una fonte di errori casuali difficili da distinguere dai problemi di mirror.

Immagini cloud: quando il formato conta più del contenuto

Le immagini cloud servono quando non installi da supporto ottico o USB, ma importi direttamente un disco già preparato. Qui il formato è decisivo: QCOW2 per molti hypervisor KVM/QEMU, RAW quando vuoi semplicità o compatibilità ampia, talvolta VMDK o formati convertiti in base alla piattaforma.

Se non sai quale scaricare, parti dal formato nativo della tua piattaforma. Convertire dopo è possibile, ma non è gratis in termini di tempo e spazio. Un esempio classico: importare un QCOW2 in un ambiente KVM è lineare; convertirlo in RAW può avere senso se vuoi performance prevedibili o snapshot gestiti altrove.

In contesti cloud, la differenza non è solo tecnica ma operativa. Una cloud image preparata bene include boot rapido, cloud-init e una configurazione adatta all’inizializzazione automatica. Se il tuo provisioning passa da metadata service o user-data, controlla che l’immagine sia compatibile con quel flusso prima di distribuirla in massa.

Verifica dell’integrità: checksum e firma non sono optional

Scaricare una ISO non basta. Devi verificare almeno l’hash e, se disponibile, la firma GPG del materiale pubblicato. Questo chiude due problemi diversi: file corrotto durante il download e file alterato o sostituito alla fonte.

Di solito il progetto pubblica file come CHECKSUM, CHECKSUM.sig e la chiave di firma associata. Il flusso corretto è: scarichi l’immagine, scarichi i file di verifica, importi la chiave se non è già presente, controlli la firma, poi confronti l’hash del file locale con quello atteso.

Esempio operativo:

wget https://mirror.example/centos/9-stream/isos/x86_64/CentOS-Stream-9-latest-x86_64-dvd1.iso
wget https://mirror.example/centos/9-stream/isos/x86_64/CHECKSUM
wget https://mirror.example/centos/9-stream/isos/x86_64/CHECKSUM.sig

sha256sum CentOS-Stream-9-latest-x86_64-dvd1.iso

# verifica firma, dopo aver importato la chiave corretta del progetto
# gpg --verify CHECKSUM.sig CHECKSUM

Se l’hash non coincide, il download è da rifare. Se la firma non valida, non cercare scorciatoie: il problema è a monte e va chiarito prima di usare quell’immagine in produzione o in un laboratorio condiviso.

Step numerati per scaricare l’immagine giusta senza errori

La procedura sotto è quella che uso per evitare di prendere al volo il file sbagliato e accorgermene solo al boot.

1. Definisci il caso d’uso: installazione fisica, VM, cloud o build automatica.
2. Scegli il tipo di immagine: DVD ISO, minimal ISO, boot ISO o cloud image.
3. Controlla architettura e formato: x86_64, aarch64, QCOW2, RAW, ISO.
4. Scarica dal sito o mirror ufficiale, evitando sorgenti non tracciabili.
5. Verifica checksum e firma prima di montare o importare l’immagine.
6. Solo dopo la verifica, procedi con scrittura USB, mount in hypervisor o upload nel cloud.

Questa sequenza sembra banale, ma in ambienti misti salva tempo. Il costo di un download errato non è solo riscaricare il file: è perdere il boot slot, confondere i test e, nei casi peggiori, importare una base immagine non allineata al parco macchine.

Download da terminale: esempi pratici e controlli rapidi

Se lavori da shell, il vantaggio è che puoi integrare subito il controllo dell’integrità. Un approccio semplice è salvare tutto in una directory dedicata e non mischiare immagini diverse nello stesso percorso.

mkdir -p ~/downloads/centos-stream-9
cd ~/downloads/centos-stream-9

curl -O https://mirror.example/centos/9-stream/isos/x86_64/CentOS-Stream-9-latest-x86_64-dvd1.iso
curl -O https://mirror.example/centos/9-stream/isos/x86_64/CHECKSUM
curl -O https://mirror.example/centos/9-stream/isos/x86_64/CHECKSUM.sig

ls -lh
sha256sum CentOS-Stream-9-latest-x86_64-dvd1.iso

Se vuoi evitare errori di battitura nei nomi file, usa tab completion o copia il path esatto dalla pagina ufficiale. Una lettera sbagliata nel nome non è solo un fastidio: può portarti a scaricare una build vecchia o un’immagine per architettura diversa.

Su sistemi con proxy o firewall restrittivi, il problema più comune non è il mirror ma il TLS inspection mal configurato. Se il download fallisce in modo intermittente, controlla prima il certificato presentato al client e poi la reachability del mirror. In molti casi il DNS risolve correttamente, ma la sessione HTTPS viene interrotta da policy locali.

Scrivere la ISO su USB senza rovinare il supporto

Per l’installazione su hardware fisico, la fase successiva è la scrittura su chiavetta. Qui il rischio classico è scegliere il device sbagliato. Prima di lanciare qualsiasi comando, identifica con precisione il disco o la USB.

lsblk -o NAME,SIZE,MODEL,TYPE,MOUNTPOINT

# rischio: sovrascrive il device indicato; verifica due volte /dev/sdX
sudo dd if=CentOS-Stream-9-latest-x86_64-dvd1.iso of=/dev/sdX bs=4M status=progress oflag=sync

Il comando sopra è efficace ma non perdona. Se vuoi un margine maggiore, smonta prima tutte le partizioni della chiavetta e controlla che non abbia mountpoint attivi. Dopo la scrittura, espelli il device in modo pulito per evitare corruzione del contenuto appena scritto.

Su workstation dove preferisci meno rischio operativo, puoi usare un tool grafico o un writer dedicato. La CLI resta comunque la scelta più ripetibile quando devi documentare il processo o inserirlo in una procedura interna.

Cloud-init e immagini cloud: il punto spesso trascurato

Scaricare una cloud image non basta se poi l’istanza non riceve i parametri iniziali. Il primo problema da chiarire è la presenza di cloud-init e la compatibilità con il provider o l’hypervisor. Senza quello, ti ritrovi un sistema avviato ma non configurato secondo aspettativa.

Per esempio, se devi preconfigurare hostname, chiavi SSH e rete, verifica che l’immagine supporti il datasource che userai davvero. In ambienti OpenStack o simili, il metadata service è parte del flusso. In una VM locale, invece, potresti dover passare user-data tramite strumenti specifici del tuo stack.

Un errore frequente è importare una cloud image come se fosse una ISO generica. Non è un supporto avviabile da usare con la stessa logica del DVD installer. Va trattata come base disco già preparata, con l’aspettativa che il provisioning avvenga al primo boot e non durante un wizard interattivo.

Buone pratiche per ambienti di test e produzione

In laboratorio puoi essere più elastico, ma in produzione conviene standardizzare. Conserva il link ufficiale, il checksum verificato, la data di download e il motivo della scelta del formato. Se l’immagine entra in una pipeline, registra anche il digest nel sistema di build o nel CMDB interno.

Per gli ambienti esposti o multi-tenant, tieni conto anche della superficie d’attacco. Un’immagine scaricata da fonte certa ma non verificata resta un rischio operativo: la firma e l’hash sono il minimo. Inoltre, se la tua procedura distribuisce SSH key, token o altri segreti nel bootstrap, non metterli mai in chiaro in file riusabili: usa vault, secret manager o meccanismi equivalenti.

Se lavori in team, la differenza la fa la ripetibilità. Una procedura scritta bene evita che ognuno scarichi una build diversa “quella volta lì”. Per una piattaforma omogenea, le immagini devono essere versionate come qualsiasi altro artefatto infrastrutturale.

Errore tipico: immagine giusta, architettura sbagliata

Uno degli errori più noiosi è scaricare l’immagine corretta per il sistema sbagliato. Succede quando si confonde x86_64 con aarch64, oppure quando si prende una cloud image destinata a un hypervisor diverso. Il file può anche sembrare sano, ma non partirà nel contesto previsto.

Se il boot fallisce, controlla prima il formato e poi l’architettura. Nella pratica, bastano pochi minuti per falsificare questa ipotesi: leggi il nome completo del file, verifica la piattaforma della VM o del server, e controlla l’output di identificazione hardware del nodo host.

uname -m
cat /etc/os-release

Il primo comando ti dice l’architettura della macchina su cui stai lavorando; il secondo non ti aiuta a scegliere l’immagine, ma ti ricorda su quale sistema stai operando. In ambienti misti, l’errore umano nasce spesso dal presupposto che tutto sia x86_64. Non lo è più da anni.

Conclusione operativa: scarica meno, verifica di più

Per CentOS Stream 9, la vera competenza non è trovare il link più veloce, ma scegliere l’immagine giusta, verificare che sia integra e usarla nel contesto corretto. ISO e cloud image risolvono problemi diversi; trattarli come equivalenti porta quasi sempre a un secondo giro di lavoro.

Se vuoi una procedura robusta, tieni questa sequenza: sorgente ufficiale, formato corretto, checksum, firma, solo poi deployment. È semplice, ma in ambito sysadmin le procedure semplici sono quelle che sopravvivono quando il resto cambia.