[Nuova Guida] Google Chrome

[frapox]

) Salve,

Esattamente 3 giorni fa hai chiesto:

) Salve, c'è qualcuno in grado di verificare questa wiki ?

E io questo ho fatto, ho verificato la wiki, in particolare l'aggiunta manuale dei repo, e ho riportato anche altre osservazioni per migliorarla, che ovviamente non hai nemmeno calcolato.

Non sai neanche quello che scrivi a distanza di 3 giorni.

So quello che dattilografo, il 16 Agosto u.s. cercavo qualcuno per fare le prove, e poco dopo con un P.S. v'ho aggiunto gli indirizzi recuperandoli al telefono.

Il giorno dopo, il 17 Agosto u.s. in serata verso le 19:00, ho avuto modo di fare le prove post avanzamento di release di 3 Panthen Focal 20.04.4 LTS a Jammy 22.04.1 LTS, era arrivato l'avviso della disponibilità dell'avanzamento ed il proprietario, ristoratore, sa benissimo che l'aiuto lo baratto sempre volentieri in cambio d'un buon pasto.

Ho rimosso i repository terzi e i ppa, fatto l'avanzamento e poi rimessi i repository terzi e ppa, preverificando la disponibilità per Jammy, e già che c'ero ho provato la nuova procedura. pel Google Chrome.

Al termine, verso le 22:00, ho provveduto ad aggiornare la wiki, dandone notizia in questa discussione con un altro P.S..

Stamane di prima mattina, circa 07:40, avendo un paio d'ore libere mi sono messo a verificare la procedura pure in Bionic & Focal, terminata con successo.

Tutti questi dettagli sono irrilevanti e OT. Tu hai scritto"c'è qualcuno in grado di verificare questa wiki ?" e nei PS successivi non hai specificato che l'avevi verificata 3 volte. Per di più hai dimenticato di mettere la dicitura "verificata per ubuntu 22.04" nella wiki stessa, poi aggiunta da Xavier oggi. E anche per questo mi sono attivato.

Ma anche se fosse, non ho bisogno del tuo consenso/permesso per verificare una wiki che è di dominio pubblico su un forum di Foss, è una mia libertà, spero che questo ti sia chiaro. Come al solito con te tocca perdere un sacco di tempo per delle questioni banali.

Ah sì dimenticavo, l'ho letti tuoi appunti sulle impostazioni root, dato che ho avuto spiacevoli esperienze nel non darli, in specie colla stessa procedura usata con Vivaldi e Palemoon ma non so perché, preferisco mettere i 2 comandi essendo innocui se inutili.

Sì saranno anche innocui ma se non servono a niente perché metterli? Chiunque può verificare con un veloce test (in un ambiente di test pulito) che sia l'owner sia i permessi sono già impostati bene.

Aggiungere passaggi inutili rende più faticosa l'esecuzione della procedura, specie per chi la ripete di frequente, e contribuisce a confondere le idee a chi non abbia una conoscenza approfondita di questi aspetti in quanto porta a fare errate deduzioni.

[xavier77]

Sì saranno anche innocui ma se non servono a niente perché metterli? Chiunque può verificare con un veloce test (in un ambiente di test pulito) che sia l'owner sia i permessi sono già impostati bene.

Aggiungere passaggi inutili rende più faticosa l'esecuzione della procedura, specie per chi la ripete di frequente, e contribuisce a confondere le idee a chi non abbia una conoscenza approfondita di questi aspetti in quanto porta a fare errate deduzioni.

Io non mi perderei in un bicchier d'acqua.
Abbiamo una guida wiki che su come controllare/cambiare i permessi dei file e una (apposita) che spiega come cambiare i permessi delle chiavi gpg.
Mettere un passaggio generico del tipo:

Codice: Seleziona tutto

Assicurarsi che il file e i relativi permessi di esecuzione siano siano attribuiti all'utente root. In caso contrario modificarli con le istruzioni di questa guida.

?????
Ovviamente le guide sarebbero:
AmministrazioneSistema/PermessiFile#Visualizzare_i_permessi
Repository/GestioneRepositoryTerzeParti#Installazione_diretta_del_file_gpg

[frapox]

Io non mi perderei in un bicchier d'acqua.
Abbiamo una guida wiki che su come controllare/cambiare i permessi dei file e una (apposita) che spiega come cambiare i permessi delle chiavi gpg.
Mettere un passaggio generico del tipo:

Codice: Seleziona tutto

Assicurarsi che il file e i relativi permessi di esecuzione siano siano attribuiti all'utente root. In caso contrario modificarli con le istruzioni di questa guida.

?????
Ovviamente le guide sarebbero:
AmministrazioneSistema/PermessiFile#Visualizzare_i_permessi
Repository/GestioneRepositoryTerzeParti#Installazione_diretta_del_file_gpg

Se il file viene creato da tee con sudo, per forza di cose l'ownership è root:root, e i permessi del nuovo file sono 644 a meno di aver modificato la variabile UMASK sotto /etc/login.defs (non l'ho mai visto fare qui sul forum né fuori) che di default è 022.

Per sicurezza ho appena verificato quanto ho appena scritto sulle live delle 3 LTS ancora supportate. In tutte l'umask è 022 e in tutte il risultato del comando restituisce un file con permessi 644 posseduto da root.

Ma va bene, io non ho problemi ad accettare un compromesso, al massimo si può scrivere di controllare i permessi che sono l'unica cosa che effettivamente può essere diversa nello 0,0001% dei casi, mentre l'{user,group}ownership è certamente di root.

[xavier77]

Ma va bene, io non ho problemi ad accettare un compromesso, al massimo si può scrivere di controllare i permessi che sono l'unica cosa che effettivamente può essere diversa nello 0,0001% dei casi, mentre l'{user,group}ownership è certamente di root.

Ho letto tutto il tuo ultimo post e condivido tutto che dici.
Tuttavia, da una breve ricerca su Google, mi sono comparsi dei risultati di utenti che (chi per un motivo, chi per un altro) hanno dovuto cambiare i permessi/proprietario del file .gpg.
Quindi direi che, per sicurezza, almeno un controllo dopo aver scaricato la chiave è consigliabile farlo.

@wilecoyote
Va bene quindi se si sintetizza il tutto con:

Codice: Seleziona tutto

Assicurarsi che il file e i relativi [[AmministrazioneSistema/PermessiFile#Visualizzare_i_permessi|permessi di esecuzione]] siano siano attribuiti all'utente root. In caso contrario modificarli con le istruzioni contenute in [[Repository/GestioneRepositoryTerzeParti#Installazione_diretta_del_file_gpg|questa guida]].

(con calma poi modifichiamo anche le altre guide)
???

[wilecoyote]

) Salve,

Ma va bene, io non ho problemi ad accettare un compromesso, al massimo si può scrivere di controllare i permessi che sono l'unica cosa che effettivamente può essere diversa nello 0,0001% dei casi, mentre l'{user,group}ownership è certamente di root.

Ho letto tutto il tuo ultimo post e condivido tutto che dici.
Tuttavia, da una breve ricerca su Google, mi sono comparsi dei risultati di utenti che (chi per un motivo, chi per un altro) hanno dovuto cambiare i permessi/proprietario del file .gpg.
Quindi direi che, per sicurezza, almeno un controllo dopo aver scaricato la chiave è consigliabile farlo.

@wilecoyote
Va bene quindi se si sintetizza il tutto con:

Codice: Seleziona tutto

Assicurarsi che il file e i relativi [[AmministrazioneSistema/PermessiFile#Visualizzare_i_permessi|permessi di esecuzione]] siano siano attribuiti all'utente root. In caso contrario modificarli con le istruzioni contenute in [[Repository/GestioneRepositoryTerzeParti#Installazione_diretta_del_file_gpg|questa guida]].

(con calma poi modifichiamo anche le altre guide)
???

Sì, direi che può andare bene, posso pure provvedere ad un 1° test introducendo la modifica in 3 mie pagine di prova, tra circa un'oretta verranno usate.

:: Ciao

[wilecoyote]

) Salve, test superato dalla sintetizzazione, 5 aggiunte di repository su 5 sono andate bene e funzionano tranquillamente.

:: Ciao

[xavier77]

) Salve, test superato dalla sintetizzazione, 5 aggiunte di repository su 5 sono andate bene e funzionano tranquillamente.

:: Ciao

Scusa, ma cosa c'era da testare?
Le righe del mio post precedente dicono, parafrasando: "Scarica la chiave nella cartella indicata e, giusto per scrupolo, controlla che abbia root come proprietario ecc. Giusto nel remoto caso non fosse root cambia i permessi al file."
Sono operazioni e arcinote.
Cosa c'è da verificare?????

[wilecoyote]

) Salve, hai chiesto se andavano bene, e vanno bene, già che c'ero l'ho fatte testare facendo aggiungendo dei repository senza eseguire a prescindere i 2 passaggi sui permessi root.

:: Ciao

[xavier77]

Se scrivo:

Va bene quindi se si sintetizza il tutto con:

Codice: Seleziona tutto

Assicurarsi che il file e i relativi [[AmministrazioneSistema/PermessiFile#Visualizzare_i_permessi|permessi di esecuzione]] siano siano attribuiti all'utente root. In caso contrario modificarli con le istruzioni contenute in [[Repository/GestioneRepositoryTerzeParti#Installazione_diretta_del_file_gpg|questa guida]].

???

mi sembra che voglia dire "va bene scriviamo così al posto di quello che c'era scritto prima?".
Alla luce di ciò, non ho ancora capito quali test fossero da farsi.
Ciao

[wilecoyote]

) Salve, intendo il test d’intelligibilità, fatto da 5 diversi avanzatori di versione, un esempio in forma di nota è in questa pagina di prova wilecoyote/Browser/InstallazioneDaRepositoryEsterni#Da_Repository_Ubuntuzilla.

:: Ciao

[xavier77]

) Salve, intendo il test d’intelligibilità, fatto da 5 diversi avanzatori di versione, un esempio in forma di nota è in questa pagina di prova wilecoyote/Browser/InstallazioneDaRepositoryEsterni#Da_Repository_Ubuntuzilla.

Continuo a non vedere il nesso diretto.
Però OK, chiudiamo qui la digressione se no andiamo avanti fino all'anno prossimo

[wilecoyote]

) Salve, coerentizzata la procedura d'installazione a quella della wiki InternetRete/Navigazione/GoogleEarth.

:: Ciao

[wilecoyote]

) Salve, verificata per 22.10 & 23.04.

:: Ciao

[wilecoyote]

) Salve, nuova stringa pell'aggiunta repository:

Codice: Seleziona tutto

echo -e "# Google-Chrome repository\n\nTypes: deb\nURIs: http://dl.google.com/linux/chrome/deb/\nSuites: stable \nComponents: main \nSigned-By: /etc/apt/keyrings/google-archive-keyring.gpg\nArchitectures: amd64\n" | sudo tee /etc/apt/sources.list.d/google-chrome.sources

Verificata con successo in Focal 20.04, Jammy 22.04 & Noble 24.04.

:. Ciao

[xavier77]

) Salve, nuova stringa pell'aggiunta repository:

Codice: Seleziona tutto

echo -e "# Google-Chrome repository\n\nTypes: deb\nURIs: http://dl.google.com/linux/chrome/deb/\nSuites:stable \nComponents: main \nSigned-By: /etc/apt/keyrings/google-archive-keyring.gpg\nArchitectures: amd64\n" | sudo tee /etc/apt/sources.list.d/google-chrome.sources

Verificata con successo in Focal 20.04, Jammy 22.04 & Noble 24.04.

:. Ciao

Aggiunta verifica con 24.04. Grazie!

[wilecoyote]

) Salve, c'è un errore da copia incolla, manca lo spazio in Suites:stable.

Dev'essere Suites:#stable. (Il diesis rappresenta lo spazio.)

L'ho scoperto per caso mentre postavo lo stesso aggiornamento per Google-Earth.

Errore mio copiando per trascinamento dall'editor, visualizzando il file appoggio, nel 1° a capo presente in riga 12,.



:: Ciao

P.S. non dattilografavi di semplificare le wiki ? È per questo che sto verificando che la stringa conforme a RFC822 funzioni in tutte le LTS supportate.

Riporta Sù per ribadure d'aggiungere lo spazio mancante.

[xavier77]

Riporta Sù per ribadure d'aggiungere lo spazio mancante.

corretto

[wilecoyote]

) Salve, riprovo a spiegare l'errore, visto che c'è ancora ed ha creato grattacapi in Errore nell'installazione di chrome.

Il comando per creare il file col repository d'installazione per Noble 24.04 è così:

Codice: Seleziona tutto

echo -e "# Google-Chrome repository\n\nTypes: deb\nURIs: http://dl.google.com/linux/chrome/deb/\nSuites: stable \nComponents: main \nSigned-By: /etc/apt/keyrings/google-archive-keyring.gpg\nArchitectures: amd64\n" | sudo tee /etc/apt/sources.list.d/google-chrome.sources

Nella wiki c'è questo # di troppo Suites:#stable.

:: Ciao