C’è un modo per “effettuare il downgrade” di discourse a una versione precedente funzionante (ad esempio 2.8.0 stabile o 2.9.0 beta3) finché questo non sarà risolto?
1 Mi Piace
Ho deciso di dedicare ancora mezz’ora a indagare su questo e penso di aver trovato la causa.
Sembra essere correlato al passaggio a Rails 7, che ha aggiornato net-smtp da 0.1.0 a 0.3.1, modificando i valori predefiniti.
Il modo in cui la gemma smtp chiama net-smtp non disabilita enable_starttls_auto e openssl_verify_mode, li abilita solo quando sono abilitati.
10 Mi Piace
Bel lavoro, Richard! Ci avrei messo due ore, se non il doppio. Per me è più facile soccombere e accettare le nuove impostazioni predefinite.
Aha. Quindi avevo in parte ragione, è solo che potrebbe non essere troppo difficile per una PR risolverlo.
4 Mi Piace
Bel lavoro @RGJ!
Mentre anticipiamo una soluzione, a parte, sarebbe bene se questo problema non causasse la cascata di problemi che ho sperimentato, che hanno quasi mandato in crash il mio forum. Nello specifico:
- I fallimenti delle email sembrano essere ritentati molto rapidamente, il che fa esplodere la coda di sidekiq in termini di dimensioni e causa un utilizzo della CPU del ~100% dovuto a questi task.
- Inoltre, qualcosa (crash o riavvii) stava causando a Redis la scrittura di enormi file temporanei, presumibilmente contenenti lo stato della coda di sidekiq. Sebbene fosse sicuro rimuoverli, hanno rapidamente riempito il disco, causando altri crash, e così via. Avevo altro spazio su disco che sono riuscito a liberare per poter riavviare il forum e capire cosa stesse succedendo, ma questo potrebbe non essere vero per tutti. (È anche piuttosto difficile confermare che, in questo caso, i file temporanei di Redis siano effettivamente sicuri da eliminare.)
La mia ipotesi è che la soluzione più semplice sia rallentare il ritentativo sui job email falliti, o almeno su quelli che non hanno vincoli di tempestività come il reset della password. Il che sembra appropriato dato che i problemi di posta elettronica difficilmente si risolveranno rapidamente, e la maggior parte / tutti i mailer effettueranno i propri ritentativi una volta ricevuta una richiesta.
8 Mi Piace
Nel mio caso, quando ho riscontrato il problema dopo l’aggiornamento, stava utilizzando TLS con un server di terze parti e il nome sul certificato corrispondeva al nome del server SMTP. Ho avuto solo un errore, tuttavia. Non ho riavviato né aggiornato da allora per evitare ulteriori problemi. Proverò un aggiornamento una volta che la patch sarà stata rilasciata e vedrò come andrà.
2 Mi Piace
Inizierò creando un topic in Bug ma dato che tecnicamente è un problema in una gemma upstream non sono sicuro di quanta priorità otterrà.
3 Mi Piace
+1 :preoccupato: bug davvero frustrante
1 Mi Piace
La gemma non può essere ripristinata? Sarei sorpreso se non ricevesse attenzione dato che si tratta di una funzionalità “core”, la capacità di inviare email e per alcuni sta anche causando un’interruzione a causa di file temporanei e CPU che sovraccaricano il server. La stabilità principale del forum è compromessa qui.
2 Mi Piace
Non dimenticare che questo può essere facilmente risolto anche configurando correttamente il tuo server di posta.
1 Mi Piace
Per quanto ne so, il mio server è configurato correttamente. Il nome del certificato corrisponde al nome host smtp, STARTTLS sulla porta 587. Mi chiedo perché ho riscontrato il problema?
Grazie per aver aperto un nuovo ticket. Data la tua comprensione, potresti fare luce sulle combinazioni delle due variabili che hai indicato nel file YML - come dovrebbero essere utilizzate per scenari diversi?
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
Ad esempio, ho solo STARTTLS sulla porta 587 e nessun’altra porta utilizzata da SMTP per motivi di sicurezza. Entrambe le variabili dovrebbero essere specificate nel file YML o solo una?
2 Mi Piace
Dipende.
Se il tuo server SMTP è configurato correttamente, non dovresti aver bisogno di nessuna delle due.
Ma il problema al momento è che non stanno facendo nulla.
Inviami un PM con il nome del tuo server SMTP e darò un’occhiata per vedere se riesco a capire perché non funziona per te.
2 Mi Piace
Ho un server SMTP locale senza supporto TLS/SSL e quando uso StartTls=false non funziona 
1 Mi Piace
[quote=“Richard - Communiteq, post:56, topic:225778, username:RGJ”]anche il tuo mail server correttamente.
[/quote]
Giusto, ma non è sempre il nostro mail server. Sto usando un mail server interno gestito da un altro gruppo e quindi non ho alcun controllo sui problemi del certificato o sulla configurazione del mail server.
Detto questo, per altri che lottano con questo, un’opzione potrebbe essere quella di impostare il proprio mail server su localhost e farlo semplicemente inoltrare la posta in uscita. In questo modo avrai il controllo sul mail server a cui Discourse si connette, e il tuo mail server su localhost potrà essere configurato per gestire qualsiasi tipo di problema a monte si possa incontrare. Avevo già fatto questo in precedenza, ma l’avevo rimosso a un certo punto poiché era più semplice far comunicare Discourse direttamente con il mail server a monte. (Ops.)
1 Mi Piace
Ecco perché l’installazione standard consiglia provider di posta elettronica di terze parti, anziché tentare di utilizzare una soluzione esistente o self-hosted.
La posta elettronica è complessa per una moltitudine di ragioni, solo perché qualcosa funziona oggi non significa che sia configurato correttamente, solo che la configurazione errata non influisce sullo scopo originale.
1 Mi Piace
Ho scelto Discourse perché si suppone che sia facile da installare e mantenere per piccole distribuzioni self-hosted.
1 Mi Piace
E lo è se segui le raccomandazioni.
Se scegli di prendere un percorso diverso, non è davvero possibile fare alcuna garanzia.
1 Mi Piace
Quindi, in sintesi, stai dicendo che con Discourse non è più possibile utilizzare un server SMTP senza TLS, SSL o StartTLS?
1 Mi Piace
Non credo che nessuno lo stia suggerendo. Questo si riferisce solo a come è sorto il problema e ha richiesto tempo per trovarne la causa principale.
Il motivo per cui vediamo solo una manciata di casi qui è a causa del numero relativamente piccolo di installazioni con la gemma aggiornata che inoltre non inoltrano la posta tramite una qualche forma di trasporto sicuro.
Richard ha già avviato un argomento sul bug:
Chiunque abbia bisogno che questo funzioni prima può anche abilitare TLS sul proprio server di posta o passare temporaneamente a un provider di posta che offre un trasporto sicuro.
1 Mi Piace
Ho TLS abilitato con un certificato valido e hostname corrispondente fin dall’inizio e poi ho riscontrato il problema dopo l’aggiornamento BETA 4 (461936f211) e ho pubblicato i log nell’argomento sottostante. Anche un altro utente sta avendo problemi e secondo lui anche i suoi certificati sono in ordine:
1 Mi Piace
Questo è quello che mi sembra. Alcuni commenti in questo thread sono stati decisamente irritanti.
Faccio l’hosting di Docker-Discourse e uso il mio host Docker come server di posta elettronica. Ho fatto in modo che Discourse utilizzasse la porta 25, senza TLS, per inviare e-mail tramite l’interfaccia Docker interna fin dall’inizio, sei anni fa. Questa è una configurazione perfettamente ragionevole e sicura. Le transazioni erano al 100% interne al mio host. Vedi più su nel thread per la mia vecchia configurazione.
Per me, la soluzione è stata fare quanto segue:
Aggiungere l’indirizzo IP dell’interfaccia Docker interna dell’host come host valido nel file di zona DNS per il mio dominio. Cioè:
discourse-mail.jag-lovers.com A 172.17.0.1
Nota: Potrei inventare qualsiasi nome host nel dominio jag-lovers.com, poiché utilizzo un certificato wildcard (CN = *.jag-lovers.com). Se non si dispone di un certificato wildcard, assicurarsi di utilizzare un nome host che sia un CN o SAN valido sul proprio certificato.
Nota anche: L’indirizzo IP che ho usato sopra è l’indirizzo IP interno che il mio host utilizza sull’interfaccia Docker per comunicare con il container Discourse-Docker. È un indirizzo IP privato e non instradabile.
Successivamente, modificare la configurazione di Discourse app.yml per connettersi al nome host che ho appena creato, per utilizzare TLS, per connettersi sulla porta 587 e per utilizzare SASL per accedere all’host per ogni transazione e-mail (altrimenti si otterrà un messaggio di errore relaying denied).
DISCOURSE_SMTP_ADDRESS: discourse-mail.jag-lovers.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: REDACTED
DISCOURSE_SMTP_PASSWORD: "REDACTED"
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: jag-lovers.com
Successivamente, ricostruire Discourse. Questo ha risolto il problema per me.
2 Mi Piace