./launcher start app - non funziona (necessario riconfigurare SMTP)

Ho dovuto riconfigurare SMTP ed eseguire il comando ./launcher start app.
Tuttavia, non mi è stato chiesto di reinserire i dati di installazione: email, SMTP, ecc…

Il comando è stato eseguito, quindi è uscito alla riga di comando dopo la reinstallazione.

Pensieri?

Questo avvia solo il container, non ti chiede nulla. La configurazione si trova in /var/containers/app.yml

Tuttavia, penso che tu stia confondendo questo comando con ./discourse-setup? (che invece chiede)

2 Mi Piace

Grazie Robert. Quindi per reinserire le informazioni SMTP dovrei usare ./discourse-setup?

Se stai aggiornando variabili d’ambiente come le credenziali SMTP, non puoi semplicemente riavviare il container affinché vengano recepite.

Dovrai eseguire un ./launcher destroy app prima di ./launcher start app affinché il container inizi a utilizzare i nuovi valori.

2 Mi Piace

Se non sai cos’è nano e preferisci che ti vengano chieste le modifiche, allora è quello che vuoi fare.

1 Mi Piace

Grazie a tutti per il vostro aiuto! Sono riuscito a modificare le informazioni. Ora sto aspettando di vedere se ricevo il messaggio che ho appena pubblicato. Incrociamo le dita. :pray:

Stephen, dato che sono riuscito a modificare le informazioni durante l’esecuzione di ./discourse-setup, devo ora occuparmi dei comandi ./launcher destroy app / ./launcher start app??

Se la configurazione ha eseguito una ricostruzione, allora no. Quanto sopra è nel caso in cui si desideri evitare di attendere la ricostruzione della propria istanza.

1 Mi Piace

Capito e grazie.

1 Mi Piace

Inseguimento: vedo che il mio post ha avviato l’invio di email MA vedo anche che tutti i messaggi sono in coda ma non inviati “250 Ok: queued as

Sto usando Sendgrid.

Pensieri?

Sono abbastanza sicuro che “sent” e “queued” siano sinonimi. Lo sono nei tuoi log di SendGrid? Se usi il test e-mail, puoi inviare a mail-tester.com?

SMTP è transazionale, quindi dal punto di vista di:

  • il tuo sistema: “il messaggio è stato inviato, il sistema remoto lo ha messo in coda come ABC1234567” → “il messaggio è stato consegnato al prossimo MTA responsabile”
  • sendgrid: “il messaggio è stato accettato e messo in coda con ID coda ABC1234567”

Ciò che non vedi (non puoi vedere) è il passaggio successivo in cui un altro agente nel sistema di SendGrid esamina la coda, preleva il tuo messaggio e lo consegna al prossimo MTA.

L’identificatore di coda aiuta nel tracciamento: se dovesse andare perso, potresti rivolgerti all’amministratore di sistema di SendGrid e chiedere “cosa è successo all’ID coda ABC1234567 dopo che il tuo sistema lo ha accettato?”

Ciao Jay. È nei log di Discourse. Farò anche il test via email. Grazie!

Grazie Michael. Ti farò rapporto quando riceverò un’email dal sistema. Ovviamente devo ricevere l’email.

Vedi Risolvere i problemi di posta elettronica in una nuova installazione di Discourse..\n.devi assicurarti che la tua email di notifica sia una che il tuo servizio di posta accetterà