Questo avviso durante la ricostruzione di Discourse. Un messaggio simile è apparso durante la ricostruzione di mail-receiver: WARNING: containers/mail-receiver.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/mail-receiver.yml.
È un avviso da ignorare o a cui agire? Grazie.
Quali parole dovrebbe includere per farti pensare che dovresti fare esattamente ciò che raccomanda?
A prima vista sembra che tu stia sarcasticamente (e insinuando che sia ovvio che dovrei fare ciò che raccomanda) ma di solito sei molto educato e disponibile, quindi non sono sicuro.
Se dicesse “Devi…” invece di “Puoi…”, sarei più felice di fare ciò che raccomanda senza controllare qui.
Inoltre, a volte ho segnalato avvisi qui e mi è stato detto di non preoccuparmene perché, ad esempio, è stata presa la decisione di continuare a fare le cose in un certo modo nonostante il messaggio di avviso (ad esempio, “Puoi ignorare quegli avvisi”: Warnings: overcommit_memory and Transparent Huge Pages).
Mi chiedo anche se seguire la raccomandazione possa causare qualche conseguenza indesiderata.
No. Questo è qualcosa che tu, a quanto pare, fai. Volevo sapere quali parole includere che ti facessero fare quello che dicevano piuttosto che chiedere se dovessi farlo.
Ma alla luce dei tuoi altri tre argomenti che riguardano cose da ignorare, la mia sincera domanda ha poco senso. (Ognuno di questi riguarda output che dovrebbero essere ignorati.)
Dato che probabilmente hai solo un utente root che può accedere, avere qualcosa di scrivibile da chiunque non è un grosso problema, quindi non è chiaro (a me) perché qualcuno abbia deciso che valesse la pena di dedicare tempo a questo.
Quindi penso che la risposta alla mia domanda sarebbe “non ci sarebbe bisogno di stampare un sacco di avvisi che non sono, di fatto, avvisi”. Ti sembra giusto?
Quello che potrebbe aiutare qui è se il “perché” fosse spiegato nell’avviso. Il tuo file è leggibile da chiunque, se ci sono altri utenti che hanno accesso SSH a questa macchina, saranno in grado di rubare la password del tuo database, usa chmod per risolvere questo problema.
(Eviterebbe anche confusione se rispondessi alla domanda e poi chiedessi i dettagli (“No, puoi ignorarlo, supponendo che tu sia l’unico utente. Quali parole…”))
Grazie per aver chiarito. Non stavo essendo sarcastico: credevo sinceramente che tu fossi solitamente educato e disponibile, e ora credo che lo sia sempre 
Ho frainteso la tua risposta e mi scuso per questo.
Sì, ho seguito le istruzioni di configurazione attuali che non creano un utente non root. Ho la sensazione che istruzioni precedenti lo facessero, ma non ricordo con certezza. Ignorerò l’errore.
Una qualche formulazione che chiarisca che l’avviso proviene dal team di Discourse o è da esso approvato, e che deve essere seguito, avrebbe avuto l’effetto che ti chiedevi.
Una spiegazione all’interno dell’avviso/consiglio aiuterebbe, come proposto sopra, poiché in questa occasione non è il caso che debba essere sempre seguito.
Bene, grazie, ma
Richard ha di nuovo ragione. Avrei dovuto fornire una risposta.
Dopo l’aggiornamento di Discourse ho anche questo avviso riguardo a app.yml e faccio: chmod o-rwx containers/app.yml tutto funziona bene.
Se stai seguendo l’installazione standard, il messaggio è piuttosto errato e non richiede alcuna azione.
Non significa che tutto il mondo possa leggere il file, ma solo altri utenti con accesso remoto al file system. È sicuro ignorarlo.
È di questo che parla la nuova riga nella guida di installazione standard?
sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
chmod 700 containers
Fondamentalmente, sì. I permessi sono solitamente indicati come tre cifre ottali, la prima sono i permessi dell’utente:
0 – niente
1 – esecuzione
2 – scrittura
3 (1+2) – esecuzione e scrittura
4 – lettura
5 – lettura ed esecuzione
6 (2+4) – scrittura e lettura
7 (1+2+4) – lettura, scrittura ed esecuzione
La seconda è il gruppo di file e la terza è il mondo.
Oh. Non me ne ero accorto. Se crediamo davvero che queste autorizzazioni siano ora importanti, dovremmo farle gestire da discourse-setup, o magari anche da launcher.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.