Discrepanza certificato hostname email causa sovraccarico coda sidekiq, grave instabilità sito

Mi occupo di self-hosting di Discourse da molti anni e ho avuto diverse istanze configurate e funzionanti su una macchina abbastanza potente.

Oggi ho notato che uno dei miei forum era offline. Il colpevole iniziale sembrava essere la mancanza di spazio su disco, che ho risolto. Ho quindi riavviato l’istanza di Discourse.

Tuttavia, da allora continua a bloccarsi regolarmente. Ogni volta che la avvio, vedo immediatamente sidekiq impazzire e un gran numero di processi di posta elettronica falliti, che causano anche a redis l’archiviazione di una quantità enorme di stato, che credo fosse la causa effettiva del problema dello spazio su disco. (Farò un flush la prossima volta che riuscirò a riavviare la macchina, perché altrimenti finirò presto lo spazio su questa macchina e non sarò nemmeno in grado di avviare Discourse per fare il flush. Ma il flush non sembra ridurre molto l’utilizzo del disco di redis.)

Il messaggio di errore indica qualcosa riguardo a una mancata corrispondenza del nome del certificato, il che trovo un po’ sorprendente poiché il server di posta che sto utilizzando è interno e non richiede TLS o autenticazione. Sono stato in grado di verificare su un’altra delle mie istanze (utilizzando la stessa configurazione di posta elettronica) che l’invio di email aveva smesso di funzionare. Tutto ciò che vedo nei log di produzione principali è un errore 422, ma quando invio qualcosa come un ripristino della password vedo un errore simile nei log di sidekiq:

Jobs::HandledExceptionWrapper: Wrapped OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)

Sono stato in grado di verificare di poter inviare email tramite la riga di comando, quindi questo non sembra essere un problema con il server di posta stesso, solo qualcosa di errato nella configurazione di Discourse.

Ecco la configurazione di posta originale che funzionava fino a poco tempo fa:

DISCOURSE_SMTP_ADDRESS: outbound-relays.techservices.illinois.edu
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_ENABLE_START_TLS: false

Di nuovo, questo server di posta è interno e non richiede nome utente o password, e queste impostazioni funzionavano fino a poco tempo fa. Ho sperimentato con DISCOURSE_SMTP_OPENSSL_VERIFY_MODE, ma non riesco a capire se è ancora supportato. Indipendentemente da ciò, non sembra aiutare. Ho notato alcune nuove impostazioni di posta elettronica che sono state aggiunte da quando ho configurato questi forum, ma non sembrano necessarie data la configurazione di questo server di posta.

Qualsiasi aiuto sarebbe apprezzato! A questo punto, ho davvero difficoltà anche a essere sicuro di cosa sia sbagliato o a iterare, poiché la ricostruzione del container richiede tempo e il messaggio di errore nei log di produzione ha solo l’errore 422 e non riesco a capire dove cercare la causa principale effettiva. (Deve essere da qualche parte, vero? Sono sicuro che me la sto solo perdendo.)

Come aggiornamento, seguendo il consiglio in un altro thread, questo comando invia correttamente email dall’interno del container Docker:

echo message | s-nail -r "noreply@myforum.com" -s testing -S "smtp=same.email-service.com:25" my@address.com

Il che è in linea con la configurazione email che stavo usando quando questo problema è iniziato. Si noti che ho anche eseguito un aggiornamento all’ultima versione di Discourse tramite un comando di pull da riga di comando (richiesto) venerdì, il che mi fa pensare se un commit recente abbia introdotto questo problema.

Quando è stata l’ultima volta che hai ricostruito il container?

Inoltre, hai svuotato la coda redis?

Venerdì mattina, credo. Un normale aggiornamento tramite l’interfaccia utente ha innescato la necessità di una ricostruzione dell'app del launcher. Quando ho esaminato i log di sidekiq in seguito, è sembrato che l’arretrato sia iniziato all’incirca nel momento in cui il container è stato ricostruito, ma ci sono volute circa 24 ore affinché i log di Redis consumassero tutto lo spazio disponibile sull’host e causassero effettivamente un’interruzione. Tuttavia, il forum era probabilmente lento fino a quel momento, dato che sidekiq stava disperatamente cercando di reinviare un numero crescente di processi di posta elettronica falliti con un utilizzo della CPU al 100%.

Sì.

Tuttavia, mi preoccupa il fatto che ciò non sembri aver ridotto l’utilizzo del disco di Redis. Ho una cartella redis_data che attualmente ha una dimensione di 29G, anche dopo lo svuotamento. Forse Redis è come MongoDB nel senso che può essere difficile fargli restituire le allocazioni del disco? Dato che questo è 1/3 del disco disponibile sulla macchina, diventerà un problema, ma per ora rimanderò quello per concentrarmi sul far funzionare di nuovo la posta elettronica.

Come nota di debug: esiste un modo per inviare un’email di test dalla riga di comando all’interno del container, utilizzando lo stesso flusso di codice che verrebbe utilizzato da Discourse? (Ovvero, non dalla riga di comando utilizzando un altro strumento, cosa che ho già verificato funzionare.) Questo sarebbe utile per il debug, poiché attualmente l’invio di un’email di test richiede di armeggiare con l’interfaccia utente web e quindi di scavare nei log per capire cosa è andato storto. (E finora ho trovato solo errori 422, e nient’altro di utile, tranne nei log di sidekiq che non vengono creati quando si utilizza il flusso di email di test.) O forse l’interfaccia utente delle email di test potrebbe mostrare maggiori informazioni di debug?

Nel complesso, sospetto che la maggior parte delle persone configuri Discourse e non arrivi a questo punto senza che l’email funzioni, poiché è necessaria per inviare inviti iniziali e così via. Ma trovo limitata la debuggabilità nel caso in cui l’email funzionasse e improvvisamente smettesse di funzionare. (Inoltre, la logica di ripetizione potrebbe necessitare di qualche aggiustamento, poiché sembra fin troppo veloce per riprovare in questo caso. Un errore di certificato è probabilmente improbabile che venga risolto pochi secondi dopo il tentativo iniziale…)

Forse dai un’occhiata a Troubleshooting email on a new Discourse install. Penso che tu voglia
\n
rake emails:test[user@domain]

Grazie! Questo è utile. Ecco il risultato:

Testing sending to user@domain using outbound-relays.techservices.illinois.edu:25, username: with plain auth.
======================================== ERRORE ========================================
                                    ERRORE IMPREVISTO
SSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)
====================================== SOLUZIONE =======================================
Questo non è un errore comune. Non esiste una soluzione raccomandata!
Si prega di segnalare il messaggio di errore esatto sopra a https://meta.discourse.org/
(E una soluzione, se ne trovi una!)
=======================================================================================

Ora ricostruirò il container per assicurarmi che sia sincronizzato con app.yml. Ma nel complesso sono un po’ confuso sul perché dica che sta usando l’autenticazione in chiaro, dato che né un nome utente né una password sono forniti nel file di configurazione app.yml.

Vale la pena riclassificare questo come un bug? Inizialmente ero esitante, dato che si tratta di email e ci sono molti modi in cui questo potrebbe funzionare male, molti dei quali sarebbero una combinazione di colpa mia / cambiamenti esterni. Ma per quanto ne so, questa rappresenta una configurazione che ha funzionato per diversi anni e ha improvvisamente smesso di funzionare con un aggiornamento all’ultima edizione di discourse_docker. È possibile che qualcosa nel modo in cui vengono elaborati i file di configurazione sia cambiato di recente?

Per quanto riguarda il messaggio di errore stesso, sono stato in grado di ottenere un certificato per quella macchina e, in effetti, il certificato elenca un altro hostname (un CNAME diverso per la stessa macchina). Tuttavia, il certificato stesso ha diversi anni ed è scaduto circa un anno fa, ma ha iniziato a generare questo errore solo di recente. Quindi questo mi fa pensare che non sia stato un cambiamento nel certificato a causare il problema.

Quando mi connetto a quell’host e testo STARTTLS ottengo un certificato che non corrisponde all’hostname:

Certificate chain
 0 s:/C=US/ST=California/L=Sunnyvale/O=Proofpoint, Inc./OU=ESP/CN=*.pphosted.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=Thawte RSA CA 2018
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

e non è ancora scaduto:

notBefore=Jun 12 00:00:00 2020 GMT
notAfter=Sep 14 12:00:00 2022 GMT

Eseguendo una ricerca forward e reverse si vede che i server di posta sono effettivamente chiamati mx0a-00007101.pphosted.com e mx0b-00007101.pphosted.com

outbound-relays.techservices.illinois.edu. 22 IN A 148.163.139.28
outbound-relays.techservices.illinois.edu. 22 IN A 148.163.135.28

28.139.163.148.in-addr.arpa name = mx0b-00007101.pphosted.com.
28.135.163.148.in-addr.arpa name = mx0a-00007101.pphosted.com.

Prova a cambiare l’hostname a cui ti connetti a uno di questi invece del nome .edu. Non è necessario che sia una modifica al certificato, potrebbe essere stata una modifica all’hostname o al codice. Ma l’errore è corretto: c’è effettivamente una discrepanza tra hostname e certificato.

Grazie @RGJ! Ci proverò.

Tuttavia, sono un po’ nervoso riguardo all’uso di questi nomi, dato che potrebbero essere soggetti a modifiche in futuro e non corrispondono al nome host fornito per l’uso nel campus a tale scopo. C’è un modo per disabilitare questo errore tramite le impostazioni di app.yml o in qualche altro modo?

Il mio approccio è stato quello di far tornare tutto in funzione prima, poi capire come migliorarlo.

Dovresti essere in grado di impostare DISCOURSE_SMTP_OPENSSL_VERIFY_MODE su false, ma hai detto di averci già provato.

Sì, assolutamente! Ha senso.

Credo di aver provato a impostare quel valore su none, ma non su false. Proverò con false.

OK, posso confermare che false non funziona. Riproverò con none.

Può anche verificare che none non funzioni.

Suppongo di essere un po’ perplesso qui sul fatto che questo sia un comportamento ragionevole. DISCOURSE_SMTP_ENABLE_START_TLS è impostato su false, il che, almeno per i non esperti di email come me, renderebbe confuso che un certificato svolga un ruolo in questo fallimento. Se la macchina non avesse affatto un certificato, si verificherebbe lo stesso problema? (Ovviamente non posso testarlo.) Se no, sembra ancora più strano.

Comunque, per ora mi accontenterò della soluzione temporanea, ma qualcosa in merito mi sembra strano.

Certamente. Posso immaginare che se un server di posta richiede starttls, questo sovrascriverà l’impostazione starttls, ma DISCOURSE_SMTP_OPENSSL_VERIFY_MODE dovrebbe comunque essere in grado di prevenire un errore.

Qualcuno è in grado di riprodurre questo problema?

@Geoffrey_Challen come hai risolto?\n\nOggi ho aggiornato il mio forum alla versione 2.9.0.beta4 (c99a6b10fb) e ora ho lo stesso errore, discourse non riesce a inviare email:\nSSL_connect returned=1 errno=0 state=error: certificate verify failed (Hostname mismatch)\n\nNon ho cambiato la configurazione del VPS e delle email!\n\nIl mio app.yml:\n\n DISCOURSE_SMTP_ADDRESS: smtp.mydomain.info\n DISCOURSE_SMTP_PORT: 25\n DISCOURSE_SMTP_USER_NAME: info@mydomain.info\n DISCOURSE_SMTP_PASSWORD: \"mypassword\"\n DISCOURSE_SMTP_ENABLE_START_TLS: false # (optional, default true)\n DISCOURSE_SMTP_DOMAIN: mydomain.info # (required by some providers)\n #DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.example.com # (address to send notifications from)\n\n\n[quote="Richard - Communiteq, post:10, topic:225778, username:RGJ"]\nDovresti essere in grado di impostare DISCOURSE_SMTP_OPENSSL_VERIFY_MODE su false, ma hai detto che ci hai già provato.\n[/quote]\n\nCi ho provato e non cambia nulla…\n\nPer favore, ora non posso inviare email e non posso usare TLS, cosa posso fare?

Emetti questo comando e vedi per quale nome host è il certificato

openssl s_client -connect  smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"

Sostituendo smtp.mydomain.info con l’indirizzo del tuo server SMTP, ovviamente.

Quindi prova a vedere se riesci a raggiungere il server SMTP utilizzando quel nome host.

Grazie per il tuo aiuto @RGJ

l’hostname è CN = *.aruba.it quindi è diverso da mydomain.info e sì, posso raggiungere il server SMTP usando l’hostname e telnet.

Tutto ha funzionato perfettamente prima di ./launcher rebuild app

Ma… ho DISCOURSE_SMTP_ENABLE_START_TLS: false perché continua a cercare il certificato?

Puoi accedere all’host utilizzando un nome che corrisponda al certificato. Puoi chiedere all’amministratore del server di aggiungere il nome host desiderato al certificato.

Questa è una buona domanda, ma puoi renderla irrilevante seguendo il consiglio di cui sopra, o almeno così credo.

Un’altra domanda, penso, è perché l’amministratore di posta elettronica ti ha causato questo problema?

Forse quella impostazione funzionava prima e ora non più. Non è chiaro se sia più facile rintracciare quel bug o cambiare il nome host e vedere se questo risolve il tuo problema.

Nessuno ha apportato modifiche, ne sono sicuro, ho solo eseguito ./launcher rebuild per installare questo plugin.

Quindi dovrei cambiare il nome host del VPS in qualcosa che termina con .aruba.it?

Sembra di sì.

È possibile che ci sia una regressione che ha causato il problema, ma penso che tu possa risolvere il tuo problema immediato cambiando l’hostname.