Discourse を古い動作するバージョン(例えば 2.8.0 stable や 2.9.0 beta3)に「ダウングレード」して、この問題が解決するまで待つ方法はありますか?
さらに30分かけて調べたところ、原因が見つかったようです。
これはRails 7への移行に関連していると思われ、net-smtpが0.1.0から0.3.1に更新され、デフォルトが変更されました。
smtp gemがnet-smtpを呼び出す方法は、enable_starttls_autoとopenssl_verify_modeを無効にするのではなく、有効になっている場合にのみ有効にします。
素晴らしい仕事だ、リチャード!私なら2時間、いや、その倍はかかっていたところだ。私にとっては、新しいデフォルトに対処することに屈する方が簡単だ。
なるほど。だから、私はある意味正しかったのだ。ただ、PRで修正するのはそれほど難しくないかもしれないということだ。
Nice job @RGJ!
修正を待つ間、ちなみに、この問題が私のフォーラムを完全にダウン寸前に追い込んだ一連の問題を引き起こさなかったらよかったのにと思います。具体的には:
- メール送信の失敗が非常に速くリトライされるようで、これによりSidekiqキューが爆発的に増加し、これらのタスクによってCPU使用率が約100%になります。
- さらに、何か(クラッシュまたは再起動のいずれか)が原因でRedisが巨大な一時ファイルを書き込んでいました。これはSidekiqキューの状態を含んでいると推測されます。これらは削除しても安全でしたが、すぐにディスクを使い果たし、さらなるクラッシュを引き起こしました。フォーラムを再起動して何が起こっているのかを把握するために解放できるディスクスペースがいくつかありましたが、これはすべての人に当てはまるわけではありません。(この場合、Redisの一時ファイルを削除しても安全であることを確認するのはやや困難でもあります。)
最も簡単な解決策は、失敗したメールジョブのリトライを遅くすること、または少なくともパスワードリセットのような時間的制約のないジョブのリトライを遅くすることだと思います。メールの問題はすぐに解決する可能性が低く、ほとんどすべてのメーラーがメッセージを受信すると独自の再試行を行うことを考えると、これは適切だと思われます。
私の場合は、アップグレード後に障害が発生した際、サードパーティサーバーとのTLSを使用していましたが、証明書の名前はSMTPサーバー名と一致していました。ただし、障害は1回だけでした。さらなる問題を避けるため、再起動やアップグレードは行っていません。パッチがリリースされたら、アップデートを試して様子を見るつもりです。
+1
本当にイライラするバグ
gemをロールバックすることはできませんか?これは「コア」機能であり、電子メールを送信する機能であるため、注目されないとは思えません。また、一部のユーザーにとっては、一時ファイルやCPUがサーバーをオーバーランすることによるサービス停止も引き起こしています。フォーラムのコアの安定性がここで損なわれています。
メールサーバーを適切に設定することで、この問題は簡単に解決できることを忘れないでください。
AFAIK、私のサーバーは正しく設定されているはずです。証明書の名前はSMTPホスト名と一致し、ポート587でSTARTTLSを使用しています。なぜ問題が発生したのか疑問に思っています。
新しいチケットを開いていただきありがとうございます。ご理解を踏まえ、YMLファイルで指摘された2つの変数の組み合わせについて、さまざまなシナリオでどのように使用すべきか、ご説明いただけますでしょうか。
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
たとえば、セキュリティ上の理由から、ポート587でのSTARTTLSのみを使用し、他のポートはSMTPで使用していません。両方の変数をYMLファイルに指定する必要がありますか、それとも一方のみですか?
それは状況によります。
SMTPサーバーが正しく設定されていれば、どちらも必要ないはずです。
しかし、現在の問題は、それらが全く機能していないことです。
SMTPサーバーの名前を付けてプライベートメッセージを送ってください。確認して、なぜ機能しないのか調べてみます。
ローカルSMTPサーバーでTLS/SSLサポートがなく、StartTls=falseを使用しても機能しません ![]()
もっともな点ですが、必ずしも「私たちの」メールサーバーとは限りません。私は別のグループが管理している内部メールサーバーを使用しており、証明書の問題やメールサーバーの設定を制御できません。
とはいえ、この問題で苦労している他の人にとっては、ローカルホストに独自のメールサーバーをセットアップし、メールを転送するだけにすることも1つの選択肢かもしれません。そうすれば、Discourseが接続するメールサーバーを制御でき、ローカルホストのメールサーバーは、発生する可能性のある上流の問題に対処するように構成できます。以前はこれを実行していましたが、Discourseが直接上流のメールサーバーと通信する方が簡単だったので、いつか削除しました。(やっちまった。)
だからこそ、Standard Install では、既存のソリューションやセルフホストのソリューションを使用しようとするのではなく、サードパーティのメールプロバイダーを推奨しています。
メールは多くの理由で困難です。今日機能しているからといって、正しく設定されているとは限りません。単に、設定ミスが元の目的に影響を与えていないだけです。
私がディスコースを選んだ理由は、小規模なセルフホストデプロイメントにとって、インストールとメンテナンスが容易であると期待されていたからです。
そして、それは推奨事項に従っていれば、そうなります。
別の道を選択した場合、保証することは実際には不可能です。
要約すると、TLS、SSL、またはStartTLSなしでSMTPサーバーを使用することは、もはやDiscourseでは不可能であるということですね?
誰もそのようなことを示唆しているとは思いません。これは問題が発生した経緯と、根本原因を見つけるのに時間がかかったことに関連するだけです。
ここで少数のケースしか見られない理由は、更新されたgemのインストール数が比較的少なく、かつ、何らかのセキュアなトランスポート経由でメールを中継していないためです。
Richardはすでにバグに関するトピックを開始しています。
これをより早く機能させる必要がある人は、メールサーバーでTLSを有効にするか、一時的にセキュアなトランスポートを提供するメールプロバイダーに切り替えることもできます。
最初から有効な証明書と一致するホスト名でTLSを有効にしていますが、BETA 4 (461936f211) のアップグレード後に問題が発生し、以下のトピックにログを投稿しました。他のユーザーも問題を抱えており、彼の証明書も正常であるとのことです。
私にはそのように聞こえます。このスレッドの一部のコメントは、まったく腹立たしいものでした。
私はDocker-Discourseをセルフホストしており、Dockerホストをメールサーバーとして使用しています。6年前から、Discourseは内部Dockerインターフェイス経由でメールを配信するためにポート25(TLSなし)を使用しています。これは完全に合理的で完全に安全な構成です。トランザクションは完全に私のホスト内で行われました。以前の構成については、スレッドの上の方を参照してください。
私の場合、回避策は次のとおりでした。
ホストの内部DockerインターフェイスIPアドレスを、ドメインのDNSゾーンファイル内の有効なホストとして追加します。つまり:
discourse-mail.jag-lovers.com A 172.17.0.1
注意:ワイルドカード証明書(CN = *.jag-lovers.com)を使用しているため、jag-lovers.comドメイン内の任意のホスト名を自由に設定できます。ワイルドカード証明書がない場合は、証明書の有効なCNまたはSANであるホスト名を使用してください。
また注意:上記で使用したIPアドレスは、ホストがDockerインターフェイス上でDiscourse-Dockerコンテナと通信するために使用する内部IPアドレスです。これはプライベートでルーティング不可能なIPアドレスです。
次に、Discourseのapp.yml構成を変更して、作成したばかりのホストに接続し、TLSを使用し、ポート587に接続し、各メールトランザクションのためにホストにログインするためにSASLを使用するようにします(そうしないと、リレーが拒否されたというエラーメッセージが表示されます)。
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
次に、Discourseを再構築します。これで問題は解決しました。