./discourse-setup non popola DISCOURSE_SMTP_DOMAIN

Ciao,

lo script bash ./discourse-setup non popola DISCOURSE_SMTP_DOMAIN nel file di configurazione PUPS.

Ho usato rake admin:create all’interno del container, per trovare il seguente impatto sulla GUI;

Per un certo periodo è stato popolato con il nome host, ne sono abbastanza sicuro. Ma anche, nella maggior parte dei casi non ha importanza.

c’è qualche regex che possiamo usare per estrarre il dominio dell’email dopo la @ in DISCOURSE_NOTIFICATION_EMAIL

comprendendo i casi di deployment in cui il dominio dell’email è diverso dal dominio web.

Qualcosa come:

DISCOURSE_SMTP_DOMAIN=$(echo "$DISCOURSE_NOTIFICATION_EMAIL" | sed -E 's/^[^@]+@(.+)$/\\1/')

Questa variabile imposta l’hostname EHLO utilizzato dal client durante la conversazione SMTP.

Quasi nessuno ne ha bisogno e quasi non importa a cosa sia impostata.

(Non ho incontrato nessuna situazione in cui sia importante)

2 Mi Piace

questo era perché DO blocca la porta 587, avrei dovuto usare la 2525 - ma non sono sicuro di come funzioni con Brevo

Si potrebbe sostenere che dovrebbe impostarsi di default sulla porta 2525 o suggerire alle persone che la maggior parte delle VM blocca le porte SMTP e che la maggior parte dei servizi SMTP consente sulla porta 2525 (ma questo sta diventando un sacco di parole)

Il fatto che Digital Ocean blocchi la porta 587 è una decisione terribile e non informata senza alcuna base di buone pratiche.

Sono sorpreso che non abbiano iniziato a bloccare anche la 2525 per lo stesso motivo.

Non sono d’accordo. Sono abbastanza sicuro che non siano gli unici a farlo (ma ho difficoltà a dimostrarlo). La cosa strana è che lo hanno sempre fatto in qualche modo, ma poi lo scorso aprile (?) lo hanno imposto a tutti. Ma “tutti” significa qualcosa di molto simile a “tutti dopo il prossimo riavvio” (potrebbe dipendere da qualcos’altro che richiede un riavvio), quindi potrebbero passare mesi prima che tu riavvii (o ridimensioni il tuo droplet o altro) e poi inizi a succedere.

E non offrono nemmeno un servizio SMTP, quindi una volta bloccata la 2525 non ci sarà modo di inviare email. Ho molte persone su DO dato che CDCK li ha raccomandati fin dall’inizio (o almeno da quando ho iniziato io).

2 Mi Piace

Come l’hai scoperto? Hai provato il task rake emails:test e, se sì, ti è stato utile? Sapevi che esisteva?

Grazie, Michael, ecco cosa è successo durante l’installazione di oggi e come ho scoperto che la porta 587 era la causa principale.

Quando ho eseguito per la prima volta ./discourse-doctor a 50:30, ha mostrato chiaramente che l’SMTP in uscita sulla porta 587 stava fallendo. Non c’erano email di prova riuscite in nessuna parte di quel processo. Per questo motivo, a 51:38 ho cambiato la porta SMTP in 2525 e ricostruito il container. Non appena l’applicazione è tornata online, il primo test di posta a 57:46 è riuscito immediatamente.

A 57:58 ho notato che il mio account Mailgun non era ancora stato attivato, quindi il dottore aveva ragione nel dire che il fallimento dell’SMTP non era dovuto alle credenziali, ma al blocco della porta da parte di DigitalOcean.

Dato che Brevo è più veloce da avviare, ho cambiato provider: ho iniziato la configurazione a 58:40, selezionato il piano gratuito a 1:01:12, scambiato i record DNS a 1:02:29 e aggiornato le impostazioni SMTP in app.yml a 1:04:37. A 1:06:08 ho sottolineato che la GUI visualizza DISCOURSE_SMTP_DOMAIN anche quando la variabile non è popolata da ./discourse-setup, motivo per cui il campo vuoto inizialmente mi ha fatto pensare che qualcosa non fosse configurato correttamente.

Dopo aver completato la configurazione di Brevo, ho rieseguito ./discourse-doctor a 1:42:10 e a 1:42:25 ha confermato un’email in uscita riuscita, sempre utilizzando la porta 2525.

Per rispondere alle tue domande specifiche:

  • Come ho scoperto che DigitalOcean stava bloccando la 587?
    ./discourse-doctor ha segnalato immediatamente il fallimento della 587 e il passaggio alla 2525 lo ha risolto all’istante. Il video mostra chiaramente questa sequenza.
  • Ho usato rake emails:test?
    Non in quel momento: mi affidavo a ./discourse-doctor e al test email dell’interfaccia di amministrazione. Non sapevo che esistesse emails:test finché non l’hai menzionato. Lo userò assolutamente in futuro poiché fornisce una diagnostica più chiara all’interno del container.
  • La mancanza di DISCOURSE_SMTP_DOMAIN era correlata?
    No: il campo vuoto nella GUI era un depistaggio. Il problema reale era DigitalOcean che bloccava la porta 587; una volta passato alla 2525, sia Mailgun (una volta attivato) che Brevo hanno funzionato bene.

Grazie ancora: la tua spiegazione di ciò che DISCOURSE_SMTP_DOMAIN influenza effettivamente (solo EHLO) ha aiutato a chiarire perché il valore mancante non aveva importanza.