Come installare Chrome su OpenSUSE Leap 15 da terminale

Repository corretto e pacchetto giusto su openSUSE Leap 15

Su openSUSE Leap 15 il punto non è “scaricare un .rpm qualsiasi”, ma fare in modo che Chrome entri nel sistema con un repository coerente, verificabile e aggiornabile. Se installi il pacchetto a mano e poi ti dimentichi l’origine, al prossimo refresh rischi dipendenze incoerenti o aggiornamenti mancati. Da terminale la strada pulita è: aggiungere il repository ufficiale di Google, importare la chiave, installare il pacchetto e verificare che il sistema lo veda come software gestito da zypper.

Qui sotto trovi una procedura pensata per Leap 15, quindi per un ramo stabile con gestione pacchetti tramite zypper e libzypp. L’obiettivo è semplice: ottenere Chrome installato, mantenibile e senza workaround inutili. Se il browser serve in desktop aziendale o su una macchina di test, questa è la via che riduce attrito operativo.

Verifica preliminare: architettura, privilegi e stato del sistema

Prima di toccare i repository, controlla tre cose: architettura, privilegi e spazio libero. Non sono formalità. Se stai su x86_64 va bene; se sei su una macchina con installazione non standard, conviene saperlo subito. Per il resto, serve un utente con sudo e un sistema che non abbia problemi di cache o filesystem pieni.

Esegui questi controlli:

uname -m
id
sudo df -h /
sudo zypper lr -u

Atteso: uname -m restituisce x86_64; id mostra che l’utente può elevare i privilegi; df -h / indica spazio sufficiente per scaricare metadati e pacchetti; zypper lr -u elenca i repository attivi senza errori di refresh. Se qui trovi già warning su repository rotti, conviene sistemare quelli prima di aggiungere Chrome.

Aggiungere il repository ufficiale di Google

Su Leap 15 il pacchetto Chrome non va preso da mirror casuali. Il repository ufficiale di Google è la base corretta, perché fornisce il canale aggiornamenti e la firma del pacchetto. La regola pratica è: aggiungi il repo, verifica il fingerprint/chiave, poi installa.

Usa questo comando:

sudo zypper addrepo -f https://dl.google.com/linux/chrome/rpm/stable/x86_64 Google-Chrome

Il flag -f abilita il refresh automatico del repository. Dopo l’aggiunta, controlla che l’URL sia corretto:

sudo zypper lr -u | grep -i chrome

Atteso: una riga con nome repo Google-Chrome e URL verso dl.google.com. Se non compare, il repository non è stato registrato come previsto e non ha senso procedere con l’installazione.

Chiave GPG e verifica dell’origine

Qui si evita il classico errore da copia-incolla: installare un pacchetto senza sapere se il repository è verificato. zypper in genere gestisce la chiave quando interroga il repo, ma è buona pratica controllare che la firma sia stata importata e che il pacchetto arrivi dal canale atteso.

Se al primo refresh zypper chiede l’import della chiave, confronta il fingerprint con quello pubblicato da Google nel canale ufficiale. Non fidarti di una chiave che arriva da un mirror terzo. Se il sistema mostra un prompt di fiducia, leggilo prima di accettare.

Per vedere le chiavi in cache e lo stato del repository, usa:

sudo rpm -qa gpg-pubkey\* | sort
sudo zypper refresh

Se zypper refresh termina senza errori e non segnala problemi di firma, sei a posto. Se invece la chiave non viene accettata, non forzare l’installazione: risolvi l’origine del repository o il problema di trust prima di andare avanti.

Installazione del pacchetto Chrome

A questo punto installi il browser vero e proprio. Il nome del pacchetto è google-chrome-stable, che è il ramo stabile usato nella maggior parte degli ambienti desktop. Non c’è bisogno di versioni beta o dev per un’installazione standard.

sudo zypper install google-chrome-stable

Durante l’installazione zypper risolve dipendenze e scarica il pacchetto dal repository appena aggiunto. Se ti propone cambi di vendor o sostituzioni strane, fermati e leggi bene il riepilogo. Su una macchina sana il flusso è lineare: conferma, download, installazione, completamento.

Se vuoi una verifica immediata del pacchetto installato:

rpm -qi google-chrome-stable
zypper info -i google-chrome-stable

Atteso: versione, vendor e architettura coerenti con il repository ufficiale. Se il pacchetto non risulta installato, guarda l’errore di zypper: spesso il problema è un refresh fallito o una cache metadati sporca.

Avvio del browser e verifica del collegamento desktop

Dopo l’installazione, Chrome dovrebbe comparire nel menu applicazioni del desktop. In ambiente grafico puoi avviarlo dal launcher; da terminale basta il comando dedicato:

google-chrome-stable

Se parte correttamente, il test minimo è aprire una pagina HTTPS e controllare che il profilo utente venga creato nella home dell’utente corrente. Il primo avvio genera directory locali, preferenze e cache. In caso di problemi, il log in console è spesso più utile della finestra grafica: lancia Chrome da terminale e osserva eventuali errori di sandbox, GPU o profilo corrotto.

Un controllo utile è verificare il file desktop entry:

ls -l /usr/share/applications/ | grep -i chrome
cat /usr/share/applications/google-chrome.desktop

Questo ti dice se il menu grafico punta all’eseguibile corretto. In ambienti con più browser installati è un dettaglio che evita confusione agli utenti.

Aggiornamenti futuri: come mantenerlo senza interventi manuali

Il vantaggio del repository ufficiale è che Chrome si aggiorna come qualsiasi altro pacchetto gestito da zypper. Questo è il punto che molti saltano quando installano da file scaricato a mano: il software resta fermo mentre il resto del sistema evolve. Qui invece il browser entra nel normale ciclo di patching.

Per controllare se ci sono aggiornamenti disponibili:

sudo zypper list-updates | grep -i chrome

Per applicarli insieme agli altri pacchetti:

sudo zypper refresh
sudo zypper update

Se gestisci più workstation o VM, il comportamento è quello che vuoi in produzione: un repository stabile, un pacchetto firmato e aggiornamenti ripetibili. Non serve inventarsi script strani, a meno che tu non debba automatizzare il provisioning.

Problemi tipici e lettura rapida degli errori

Gli errori più comuni non riguardano Chrome in sé, ma il contesto di sistema. Il primo è il repository non raggiungibile: in quel caso zypper fallisce sul refresh e l’installazione non parte. Il secondo è una chiave non accettata o una firma non verificata. Il terzo è un problema di dipendenze su un sistema con repository terzi in conflitto.

Se vedi errori di rete, controlla prima DNS e connettività verso il dominio del repo:

getent hosts dl.google.com
curl -I https://dl.google.com/linux/chrome/rpm/stable/x86_64

Se il problema è lato pacchetti, leggi il dettaglio di zypper senza andare a tentativi. La diagnostica utile spesso è già nel testo dell’errore. Su sistemi desktop il classico errore di dipendenza è meno frequente di quanto si creda, ma quando c’è di mezzo un repository aggiuntivo va trattato con attenzione.

Per avere un quadro più pulito dei repository attivi, puoi eseguire:

sudo zypper lr -d

Se trovi repository duplicati, mirror obsoleti o priorità incoerenti, sistemali prima di ripetere l’installazione. Su openSUSE la salute del sistema dipende molto dalla qualità dei repository abilitati.

Rimozione pulita e rollback

Se devi tornare indietro, la rimozione è semplice e reversibile. Prima disinstalla il pacchetto, poi rimuovi il repository se non ti serve più. Questo mantiene il sistema pulito e riduce il rischio di confusione futura con altri browser o con una reinstallazione successiva.

sudo zypper remove google-chrome-stable
sudo zypper removerepo Google-Chrome

Prima di rimuovere il repository, verifica che non ci siano altri pacchetti che lo usano. Il rollback non è solo “disinstallare”: è anche evitare di lasciare riferimenti inutili in /etc/zypp/repos.d/. Se vuoi controllare i file del repo, puoi elencarli così:

ls -l /etc/zypp/repos.d/

Se il pacchetto è stato rimosso ma il launcher resta in cache desktop, fai logout/login o aggiorna il menu dell’ambiente grafico. In alcuni desktop il menu non si pulisce istantaneamente e l’icona può restare visibile fino al refresh della sessione.

Comandi riassuntivi per un’installazione lineare

Se vuoi una sequenza essenziale, senza passaggi superflui, questa è la traccia minima da terminale. È la versione che userei su una workstation pulita, con repository in ordine e connettività normale.

sudo zypper addrepo -f https://dl.google.com/linux/chrome/rpm/stable/x86_64 Google-Chrome
sudo zypper refresh
sudo zypper install google-chrome-stable
google-chrome-stable

Se uno di questi quattro passaggi fallisce, non saltare al successivo: leggi l’errore, identifica se il blocco è rete, trust, dipendenze o avvio grafico, e correggi il layer giusto. È il modo più veloce per evitare di trasformare un’installazione banale in una sessione di troubleshooting inutile.

Quando conviene usare il repository e quando no

Il repository ufficiale ha senso quando vuoi mantenere Chrome aggiornato con il normale ciclo di patch. Se invece devi fare una prova temporanea in una VM usa e getta, puoi anche installare un pacchetto locale, ma perdi il controllo sul lifecycle. In contesti desktop reali, soprattutto con più macchine, il repository è la scelta corretta perché rende prevedibile il comportamento nel tempo.

Un dettaglio spesso ignorato è la compatibilità con policy aziendali e proxy. Se il sistema esce su Internet solo tramite proxy, devi verificare che zypper lo rispetti, altrimenti il refresh del repository fallisce anche se la rete “sembra” funzionare. In quel caso il test giusto non è aprire un sito dal browser, ma validare il download del metadato del repository da terminale.

Per chiudere il cerchio, l’installazione su openSUSE Leap 15 è meno una questione di browser e più una questione di igiene del sistema: repository giusto, firma verificata, pacchetto gestito dal package manager, aggiornamenti automatici e rimozione pulita. Se questi quattro punti sono a posto, Chrome si comporta come qualsiasi altro componente ben integrato del sistema.