Come installare Chrome su Rocky Linux o AlmaLinux 8

Su Rocky Linux 8 e AlmaLinux 8 la via più pulita per avere Google Chrome non è scaricare un RPM a mano e sperare che resti stabile nel tempo. La scelta sensata è usare il pacchetto ufficiale Google, che aggiunge il repository dedicato e porta aggiornamenti gestiti da DNF. Così eviti di inseguire dipendenze mancanti, conflitti con librerie di sistema o installazioni “una tantum” che si rompono al primo update.

La differenza pratica rispetto a molte guide trovate in giro è questa: non stai installando solo un browser, stai agganciando una sorgente software che dovrà convivere con il ciclo di aggiornamento della macchina. Per questo conviene verificare prima architettura, stato del sistema e disponibilità della rete verso i mirror Google, poi installare e infine controllare che il repository sia stato registrato correttamente.

Prerequisiti e controlli rapidi prima di iniziare

Chrome è disponibile solo per architetture supportate dal pacchetto ufficiale. Su Rocky 8 e AlmaLinux 8, nella pratica, il target è x86_64. Se sei su una VM o su una macchina fisica con architettura diversa, fermati qui e verifica prima il supporto reale del software che vuoi usare.

Prima di installare, controlla tre cose: versione del sistema, architettura e raggiungibilità del repository. Sono verifiche banali, ma ti evitano di confondere un problema di rete con un problema di pacchetto.

cat /etc/redhat-release
uname -m
curl -I https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm

Atteso: la prima riga deve indicare Rocky Linux 8 o AlmaLinux 8, la seconda deve restituire x86_64, la terza deve rispondere con un codice HTTP valido, tipicamente 200 o un redirect gestito correttamente. Se il curl -I fallisce, il problema non è Chrome: è connettività, DNS, proxy o filtro in uscita.

Metodo consigliato: installazione dal pacchetto ufficiale Google

Il metodo più lineare è scaricare il pacchetto RPM ufficiale e installarlo con DNF. Il pacchetto, oltre al browser, aggiunge il repository Google in modo che gli aggiornamenti successivi passino dal normale flusso di update del sistema.

sudo dnf install -y https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm

Se il comando va a buon fine, DNF installa il pacchetto e registra il repository. A quel punto Chrome compare nel menu applicazioni e nel sistema degli aggiornamenti come pacchetto gestito. Su macchine con policy restrittive, è possibile che il download venga bloccato da proxy o ACL: in quel caso il punto da analizzare non è il pacchetto ma il percorso verso dl.google.com.

Se preferisci un approccio più controllato, puoi prima scaricare il file e poi installarlo localmente. È utile quando vuoi verificare checksum, passare il file attraverso un repository interno o avere una copia temporanea per ambienti con accesso limitato.

curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm
sudo dnf install -y ./google-chrome-stable_current_x86_64.rpm

Verifica del repository e degli aggiornamenti

Dopo l’installazione, conviene confermare che il repository sia stato aggiunto e che DNF lo veda davvero. Questo passaggio è importante perché un browser installato ma non aggiornabile è una fonte di problemi di sicurezza nel medio periodo.

dnf repolist | grep -i google
rpm -qi google-chrome-stable

Nel primo comando dovresti vedere un repository Google elencato tra quelli disponibili. Nel secondo, il pacchetto deve risultare installato con versione e architettura coerenti. Se dnf repolist non mostra nulla, il pacchetto potrebbe essere stato installato senza registrare correttamente il repo, oppure il file repo potrebbe essere stato rimosso o disabilitato.

Un controllo utile è anche il file di configurazione del repository, che di solito finisce sotto /etc/yum.repos.d/. Non serve modificarlo in condizioni normali, ma sapere dove si trova aiuta quando devi auditare l’origine degli update.

ls -l /etc/yum.repos.d/ | grep -i google
cat /etc/yum.repos.d/google-chrome.repo

Se il file esiste, verifica che il baseurl o il mirrorlist puntino a Google e che il repository non sia disabilitato. In ambienti gestiti, può capitare che il file venga distribuito ma poi sovrascritto da policy di configurazione o strumenti di compliance.

Installazione con GUI: quando ha senso e quando no

Su workstation con desktop grafico puoi anche aprire il file RPM con il gestore pacchetti e procedere da interfaccia. È meno efficiente rispetto alla shell, ma può essere comodo per un’installazione singola su una macchina usata da un operatore non abituato al terminale.

Detto questo, su Rocky e AlmaLinux 8 la via CLI resta più affidabile per tre motivi: mostra subito eventuali errori di dipendenza, è ripetibile, e lascia una traccia chiara del comando eseguito. Se stai lavorando in produzione o su una macchina remota, la GUI aggiunge solo attrito.

Problemi tipici e come leggere gli errori

Il primo errore comune è il fallimento del download. In quel caso controlla subito DNS, proxy e filtraggio egress. Un test minimale è questo:

getent hosts dl.google.com
curl -vI https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm

Se getent non risolve il nome, hai un problema di DNS o di resolver locale. Se la risoluzione funziona ma curl -vI si ferma durante la connessione, il collo di bottiglia è più probabilmente firewall, proxy o TLS inspection. Se invece il download parte ma DNF segnala errori di checksum o file non valido, il file potrebbe essere stato intercettato o corrotto lungo il percorso.

Il secondo errore comune riguarda le dipendenze. Sul ramo 8, Chrome in genere si installa senza interventi manuali, ma se il sistema è stato alleggerito troppo o è fuori standard, DNF potrebbe chiedere librerie base mancanti. In quel caso non forzare installazioni casuali: prima verifica quali pacchetti sono davvero assenti.

sudo dnf repoquery --requires google-chrome-stable | head -n 20
sudo dnf provides '*/libX11.so.6'

Il terzo caso è il conflitto con browser già presenti o con policy aziendali. Chrome non va in conflitto con Firefox, ma può esserci una gestione centralizzata che blocca l’aggiunta di repository esterni. Qui il punto non è tecnico ma di governance: controlla eventuali strumenti di hardening, configurazioni di DNF o baseline di sicurezza.

Avvio del browser e controllo del contesto desktop

Dopo l’installazione, Chrome dovrebbe comparire nel menu applicazioni. Da terminale puoi avviarlo così:

google-chrome-stable &

Se il comando non è trovato, verifica il binario installato. In alcuni casi il nome del pacchetto e quello del comando coincidono, ma su sistemi con PATH alterato o installazioni parziali è meglio controllare direttamente il file presente nel filesystem.

command -v google-chrome-stable
rpm -ql google-chrome-stable | grep '/google-chrome$'

Su server senza ambiente grafico, l’installazione può essere corretta ma il browser non sarà avviabile in modo utile. Non è un errore del pacchetto: manca semplicemente un display server o una sessione desktop. In quel caso il controllo corretto è capire se la macchina è davvero destinata a uso workstation o se hai installato Chrome per sbaglio su un host che non dovrebbe averlo.

Aggiornamenti e manutenzione nel tempo

Una volta installato, Chrome va trattato come qualsiasi software esposto a Internet: aggiornamenti regolari, repository funzionante e nessuna deriva di configurazione. Il controllo periodico più semplice è includerlo nel normale ciclo di update del sistema.

sudo dnf update -y google-chrome-stable

Se usi repository interni o mirror aziendali, verifica che il pacchetto continui a essere servito dalla fonte attesa. Un browser vecchio è un rischio inutile, perché naviga contenuti non fidati e gestisce codice complesso, quindi la finestra di esposizione va tenuta corta.

Per un audit minimo, conserva almeno questi elementi: versione installata, sorgente del pacchetto e data dell’ultimo update. Sono informazioni che aiutano quando devi ricostruire la storia di una workstation o spiegare perché un’istanza non riceve patch.

Installazione offline o in ambienti controllati

In reti chiuse o segmentate, il download diretto da Internet può non essere possibile. In quel caso la procedura cambia poco, ma va spostato il file RPM in una zona di staging o in un repository interno approvato.

Il flusso corretto è: scarico su macchina con accesso, verifica del file, trasferimento, installazione locale. Se la tua organizzazione usa un repository privato, meglio pubblicare lì il pacchetto e lasciare che i client lo consumino dal canale standard, invece di distribuire file manualmente su ogni host.

sha256sum google-chrome-stable_current_x86_64.rpm
scp google-chrome-stable_current_x86_64.rpm user@host:/tmp/
sudo dnf install -y /tmp/google-chrome-stable_current_x86_64.rpm

La verifica dell’hash è il controllo minimo da fare quando il file passa tra ambienti diversi. Non serve complicarsi la vita con procedure pesanti se il contesto è semplice, ma non ha senso saltare l’integrità del pacchetto quando stai distribuendo software a una flotta di sistemi.

Quando conviene non usare Chrome

Su sistemi server puri, Chrome spesso non serve proprio. Se la macchina deve erogare servizi, aggiungere un browser aumenta superficie software, update da seguire e potenziali dipendenze desktop inutili. In quel caso è più corretto lasciare il server pulito e usare una workstation separata per test e navigazione.

Se invece ti serve per test di compatibilità web, automazione o debug di frontend, allora il browser ha senso, ma va installato su una macchina con interfaccia grafica coerente e con un ciclo di patching già definito. Mischiare ruoli diversi sullo stesso host è quasi sempre un compromesso che prima o poi presenta il conto.

Checklist finale operativa

Se vuoi chiudere la procedura senza lasciare dubbi, questa è la sequenza minima che uso in pratica:

1. Verifico che il sistema sia Rocky Linux 8 o AlmaLinux 8 e che l’architettura sia x86_64.
2. Controllo che il download da dl.google.com sia raggiungibile con curl -I.
3. Installo il pacchetto RPM ufficiale con dnf install -y https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm.
4. Confermo che il repository Google sia presente in /etc/yum.repos.d/ e visibile con dnf repolist.
5. Avvio google-chrome-stable e verifico che parta senza errori di librerie o display.
6. Inserisco Chrome nel normale ciclo di update del sistema.

Questo approccio è semplice, ma soprattutto è controllabile. Non dipende da passaggi opachi e non crea installazioni “fantasma” che poi nessuno sa aggiornare. Se il tuo ambiente ha vincoli particolari, il punto da chiudere non è il browser: è la policy di rete, il repository aziendale o il controllo di configurazione che sta interferendo con DNF.