Discourse 3.5.0.beta2-dev の不具合 - SMTPとBackground Jobs

ChatGPT が作成した以下のレポートを共有します。これは、Discourse のインストールに関する私の実際の経験に基づいています(私はあまり技術に詳しくないので、難しい作業には AI の助けを借りています)。現時点では助けは必要ありませんが、このレポートが 3.5.0.beta2-dev に関する有用なフィードバックとなることを願っています。

==================

Discourse チーム各位

Discourse 3.5.0.beta2-dev を実行中に発生したメールの問題に関するトラブルシューティングの詳細を共有したいと思います。最新の開発バージョンにおける潜在的な問題の特定に役立つことを願っていますが、直接のサポートは必要ありません。私は 3.4.0.beta4-dev に戻すことにしました。


1. 問題の概要

新しい Vultr インスタンスに Discourse をクリーンインストールし、20i の SMTP サービスsmtp.stackmail.com)を使用しました。しかし、以下のにもかかわらず、メールは一度も配信されませんでした。

  • SMTP 接続テストは成功しました(openssl s_client -connect smtp.stackmail.com:587 -starttls smtp)。
  • 20i のメールログにエラーは表示されませんでした(Discourse が実際にメールを送信していなかったことを示唆しています)。
  • Sidekiq がメールジョブを処理できませんでした

これは予想外でした。なぜなら、数週間前に同一のインスタンスDiscourse 3.4.0.beta4-dev を正常にインストールし、メールの問題は発生しなかったからです。

徹底的なデバッグの後、現在のインストールで予期せず Discourse 3.5.0.beta2-dev がインストールされていたことが判明し、これが問題の原因である可能性が高いです。


2. 特定された主な問題

A. メールが配信されなかった

  • SMTP 設定は正しかった。手動テスト(swaks および openssl テストは成功)で確認済み。
  • メールは Sidekiq にエンキューされたが、受信されなかった
  • 20i のメールログには、拒否または配信試行の記録がなかった(メッセージが Discourse から送信されなかったことを示唆)。
  • production.log にはメール関連のエラーは表示されなかったgrep "smtp" は何も返さなかった)。

B. Sidekiq および Redis の問題

  • 当初、Sidekiq は実行されていなかったSidekiq::Workers.new.size0 を返した)。
  • Sidekiq を手動で再起動しようとすると(sv restart sidekiq)、Sidekiq がサービスとして存在しないため失敗した。
  • Redis は実行中だった(redis-cli pingPONG を返した)が、Discourse のログには Redis 接続エラーErrno::ECONNREFUSED)が依然として表示されていた。
  • Sidekiq のログは、Redis がアクティブであることが確認されていたにもかかわらず、Redis 接続の問題によるジョブの失敗を示していた。
  • Sidekiq を手動で起動bundle exec sidekiq)するとジョブは処理されたが、メールは依然として送信されなかった

C. インストール間のバージョン不一致

  • **以前のインストール(正常に動作した)**は 3.4.0.beta4-dev でした。
  • 現在のインストールでは、同じセットアップ方法を使用したにもかかわらず、予期せず 3.5.0.beta2-dev がインストールされていました
  • 3.4.0.beta4-dev ではメールが正常に機能したため、3.5 での回帰または破壊的な変更を疑っています

3. 実施したアクション(すべて失敗)

以下のソリューションを体系的に試しました。

:white_check_mark: SMTP 接続を確認:

openssl s_client -connect smtp.stackmail.com:587 -starttls smtp  # 成功
swaks --to my-email --server smtp.stackmail.com --port 587 --auth LOGIN  # 成功

:white_check_mark: メールがエンキューされていることを確認:

Jobs.enqueue(:user_email, type: :test_message, to_address: 'masden@kumagaku.ac.jp')  # ジョブ ID が返された
Sidekiq::Queue.new("default").size  # 0 を返した(ジョブが処理されたことを示唆)

:white_check_mark: Discourse ログを確認:

grep "smtp" /shared/log/rails/production.log  # SMTP 関連のエラーなし
  • Redis 接続の失敗production.log 内の Errno::ECONNREFUSED)。

:white_check_mark: サービスを再起動および手動でトリガー:

sv restart sidekiq  # 失敗、サービスが存在しない
redis-cli ping  # 実行中であることを確認
bundle exec sidekiq  # ジョブは処理されたが、メールは送信されなかった

:white_check_mark: メールが 20i によってブロックされているか確認:

  • 20i のメールログに拒否または配信試行の記録なし
  • メールが拒否された場合、ログエントリがあるはずですが、何も表示されませんでした

4. 結論:3.4.0.beta4-dev へのロールバック

広範なトラブルシューティングの後、インストールをワイプし、3.4.0.beta4-dev を再インストールすることにしました。以前のインストールは、そのバージョンで問題なく動作したからです。

直接のヘルプは必要ありませんが、これらの問題を報告したいと思った理由は次のとおりです。

  • メール処理が 3.5 で変更された可能性があり、SMTP ハンドオフが妨げられている。
  • Sidekiq のサービス欠落と Redis エラーは、3.5 におけるバックグラウンドジョブ処理の問題を示唆している。
  • 3.4.0.beta4-dev は問題なくインストールできたため、3.5 での回帰の可能性が示唆される。

このレポートが Discourse 3.5.0.beta2-dev の潜在的な問題の特定に役立つことを願っています。

敬具、
Kirk

「いいね!」 2

それは予想通りでした。なぜなら、それが現在のバージョンだからです。

同じ最新バージョンを使用しているユーザーはかなり多く、sidekiq も動作しており、そのためメールも送信されます。

したがって、再構築もできないため、ヘルプが必要になるかもしれません。

このトピックについては、もっと詳しい人がいるかもしれませんが、sidekiq が停止したというトピックはすでにいくつかあります。検索で役立つかもしれません。

「いいね!」 4

Discourse のインストールで引き続き問題が発生しています。ChatGPT がまとめた別のレポートを以下に示します。私の経験を正確に表していると思います。

レポート:Discourse のインストールと Sidekiq サービスの欠落に関する問題

コンテキスト:
Vultr インスタンスに Discourse の新規インストールを試み、安定した動作するデプロイメントをセットアップすることを意図していました。しかし、特に Sidekiq のようなサービスの欠落により、電子メール配信やバックグラウンドジョブの処理が妨げられるなど、重大な問題に遭遇しました。


発生した問題の概要

  1. 予期しないバージョンのインストール
  • 予想される v3.4.0.beta4-dev の代わりに、インストールはデフォルトで tests-passed になり、不安定なバージョンが取得されました。
  • VERSION ファイルが欠落しており、正確なインストールバージョンが不明でした。
  1. Sidekiq サービスの欠落
  • Discourse コンテナ内に /etc/service/sidekiq ディレクトリが存在しませんでした。
  • これにより、すべてのバックグラウンドジョブ(メール、通知、スケジュールされたタスク)が実行されませんでした。
  1. Discourse Git リポジトリの問題
  • コンテナ内で git rev-parse --abbrev-ref HEAD を実行すると tests-passed が返され、意図しないバージョンがインストールされたことが確認されました。
  • Git は 「検出された疑わしい所有権」 エラーを発生させ、手動介入(git config --global --add safe.directory /var/www/discourse)が必要でした。
  1. 潜在的な依存関係の問題
  • Discourse の古いバージョンがチェックアウトされた場合でも、インストール中に新しい依存関係(Ruby、Redis、Sidekiq)が取得され、互換性の問題が発生する可能性があるという懸念があります。
  • Discourse の依存関係が正しくピン留めされていない場合、環境によってインストールの動作が一貫しない可能性があります。
  1. SSL 証明書のレート制限
  • Let’s Encrypt SSL 証明書の新規取得を試みたところ、レート制限を超過したため失敗しました。
  • これにより、Nginx は期待される証明書ファイルをロードできなかったため、起動に失敗しました。

計画されている次のステップ

  1. 完全なワイプと再インストールを実行する
  • /var/discourse を完全に削除し、リポジトリを再クローンします。
  • インストールを実行する前に、安定したバージョン(例:v3.4.1)を手動でチェックアウトします。
  • デフォルトに依存するのではなく、./discourse-setup を使用して、正しいパラメータを確実にします。
  1. Sidekiq がインストールされていることを確認する
  • 再ビルドする前に、sidekiq サービスがビルドプロセスに正しく含まれていることを確認します。
  • 再ビルド後に Sidekiq が見つからない場合は、bundle list | grep sidekiq を使用して手動でインストールを確認します。
  1. 依存関係を安定したバージョンにピン留めする
  • 既知の安定した Discourse Docker イメージ(例:discourse/discourse:2.0.20240101)を明示的に使用して、依存関係の問題を回避します。
  • コンテナ内の gem バージョンをロックします(bundle install --deployment --without test development)。
  1. SSL 証明書の発行を再試行する
  • Let’s Encrypt のレート制限リセットを待ってから、SSL 証明書生成を再試行します。
  • 問題が続く場合は、一時的なトラブルシューティングのために自己署名証明書の使用を検討してください。

フィードバックのお願い

これらの課題を考慮すると、Discourse チームおよびコミュニティから以下の点についてフィードバックをいただければ幸いです。

  • 新規インストールで /etc/service/ から Sidekiq が欠落している – 他にこの問題に遭遇した方はいらっしゃいますか?
  • 依存関係の安定性を確保するためのベストプラクティス – Discourse インストールの依存関係バージョンをピン留めするための推奨される方法はありますか?
  • デフォルトで tests-passed がインストールされることによる潜在的な問題 – バージョンの取得方法に問題がある可能性がありますか?

再インストールを進める前に、どのような洞察でも役立ちます。事前に感謝いたします!

実際には不安定ではありません。現在、すべてのフォーラムでデフォルトになっています。Discourse は不安定なブランチをデフォルトにしません。

うーん…フォーラムで /sidekiq にアクセスすると何が表示されますか?

どのブランチのインストールを意図していますか?おそらくこのガイドがお役に立つかもしれません。

「いいね!」 3

私は必要なものはあなたのVPSの構成に関する詳細だと思います。CPU、RAM、ディスク容量、Ubuntu LTS 24について。

メールのテストをしたと言いますが、Discourseのテストを使用してメールを受信しましたか?

私のXPでは、あなたのapp.ymlファイルにSMPT用のメイン設定の3行があるはずです。

  • ユーザー名:
  • パスワード
  • ポート

あなたの言ったことから、以前のDiscourseのインストールではこれを動作させていたのですか?

「Tests-Passed」が推奨されるバージョンのインストールです。安定版は私の理解では、カスタムプラグインやテーマを使用している人向けです。これらはより頻繁に更新が必要となることがあり、障害を避けるためです。

エラーのあるリビルドログを共有できますか? ログをキャプチャするときは、最終エラーは単なる失敗の結果であることを考慮して、上にスクロールしてください。敏感なデータ(SMPTのユーザ名やパスワード)については常に伏字にできます。

メールのSMPT問題に関するトピックもいくつかあり、解決策があるかもしれません。

「いいね!」 1

返信が遅くなり申し訳ありません。他のコメントへの返信でも書きましたが、もう一度やり直すために多くのソフトウェアを削除してしまったため、前回の失敗の詳細についてお答えすることはできません。分かり次第、またご報告します。

詳細なコメントありがとうございます。返信が遅くなり申し訳ありません。

現在、さまざまなソフトウェアの以前のバージョンで再インストールを試みています。そのため、以前の失敗した試みに関するご質問にお答えするのが困難です。次のインストールが完了次第、改めてご報告いたします。

「いいね!」 1

必要に応じて追加テストとして検討できることがあります。www.brevo.comで無料アカウントを設定してください。1日300通の無料メール枠があります。現在私はこれを使用しています。

メール送信に問題がある場合、メールプロバイダーに関連しているかどうかをテストするのに役立つ可能性があります。

「いいね!」 2

TL;DR ChatGPT を頼りにしないでください。これらはすべて誤報です。

助けを求めるのは良いことですが、それに 頼る のは悪い考えです。以下に示します。
ChatGPT に職を奪われる心配がないことを確認していただきありがとうございます。 :wink:

beta4-devtests-passed と同様に不安定な可能性があります。

そのようなファイルはありません。

そのようなディレクトリは存在しないはずです。

疑わしいです。

これは予期された動作です。

これは、所有者でないディレクトリで git を使用した場合の通常の動作です。

これは意味が通りません。また、tests-passed はあなたが「期待」したものよりも新しいものであり、古いものではありません。

これは、あなたが何度も試したためです。

「いいね!」 6

これを強調したいと思います。
ほとんどの場合、ChatGPTに問題を見つけるように提案すると、実際には問題がない場合でも、問題を見つけます。また、継続的に提案する「修正」の無限ループに私たちを陥らせるのも早いです。

「いいね!」 5

どうもありがとうございます!

AIに関して、ChatGPTが信頼できるガイドではなかったことは明らかです。一方で、デバッグが難しいと感じているため、私のような人間にとってはそれに頼りたくなる誘惑は大きいのです。

私はちょうど、正常にインストールを完了しました。ChatGPT(有料版)では目標に到達できませんでしたが、AnthropicのClaude(こちらも有料版、両方使用しています)が最終的に達成してくれました。ChatGPTが引き起こした問題を修正するのに役立ちました。

後ほど、私の経験についてもっと詳しく書きたいと思います。皆様の親切なコメントに感謝いたします!

「いいね!」 2

私も同意します。私の使用経験から、Claudeはより快適で、通常はすぐに正しい答えを出してくれます。

成功して嬉しいです!

「いいね!」 5

ありがとうございます!特定のタスクにおいては、まるで異なる個性を持つ人々のようであるほど、驚くほど違いがあるのですね。Claudeはより「思慮深い」ようですが、ChatGPTは結論に飛びつき、少し先走る傾向があります。それでも、ChatGPTの方が良い状況もありました。両方とも改善されることを願っています。AIは、スクリプトライターではない私でも、実際に機能する多くのスクリプトを書くのに役立ちました。私のようなテクノロジーに不慣れな人々にとって、素晴らしいツールになる可能性を秘めていますが、間違いなく改善が必要です。行き止まりに導かれるのは本当にイライラします。 :frowning:

「いいね!」 4

インストールが成功したことに関する簡単なレポートと、今後の進め方についての質問です。

最近の試みでSMTPに問題があった理由はまだわかりません。実際、数週間前の最初の試みは成功しましたが、Vultrサーバーを使用していました。これは必要以上に大きいと判断し、ダウングレードする唯一の方法は新しい小さなサーバーを取得してから大きい方を削除することでした。

受信したメールによると、数週間前にインストールしたDiscourseのバージョンは3.4.0.beta4-devでした。メールでは3.4.0.beta4にアップグレードすることが推奨されていました。

3.4.0.beta4-devでSMTPに問題があったため、以前の安定版Discourseをインストールしようと思いました。ChatGPT(信頼性は低いですが)との議論で、3.4.1をインストールすることにしました。そのバージョンは安定していると思っていました。最終的にインストールしたのは次のとおりです。

• Discourseバージョン:3.5.0.beta2-dev
• Dockerバージョン:23.0.6
• sidekiq:6.5.12
• PostgreSQLバージョン:PostgreSQL 15.12 (Debian 15.12-1.pgdg120+1)
• Redisバージョン:7.0.15
• NGINX:1.26.2
• Ubuntuバージョン:22.04 LTS (Jammy Jellyfish)
• Gitバージョン:2.39.5

以前の安定版をインストールするという私たちの意図(つまり、AIの支援を受けた私の意図)にかかわらず、結局Discourse 3.5.0.beta2-devをインストールしたのだと思います。

多くの試行錯誤や、うまくいかないものを修正するためにAIから提供されたコマンドを使用したため、困難でしたが、Discourseはようやく稼働しました。

いくつか質問があります。

  1. 私の認識が間違っていなければ、現在のユーザーはまだ3.5.0へのアップグレードを推奨されていません。おそらく、まだ完全にテストされていないためでしょう。もしそうなら、なぜ私のような新規ユーザーがインストールを余儀なくされるのでしょうか?

  2. Dockerのバージョンが古い(非推奨)と思います。ターミナルを使用して最新バージョンにアップグレードすべきでしょうか?Discourseは現在動作しており、この時点に至るまで多くの問題があったため、何かを台無しにしたくありません。

  3. 他のソフトウェアバージョンはかなり新しいと思います。問題が発生する可能性のあるものやアップグレードが必要なものがあれば教えてください。

  4. このコミュニティには、技術的な「ケアとメンテナンス」の問題に対処するページやセクションはありますか?コミュニティを健全に機能させ続け、問題が発生した場合に備えてバックアップなどを準備しておきたいです。

「いいね!」 2

以前のDiscourseコミュニティのバックアップからの復元が完了しました。問題なく完了したようで、Docker(上記で言及された問題)も更新された可能性があります。

復元直後に受信したこのメッセージについて疑問に思っています。「一般ユーザーのメール送信が無効になっています。」

ここの別のスレッドを参照して

設定を変更する場所を見つけました。

これで問題ないはずですが、可能であれば確認していただけると幸いです。「無効」が正しい設定ですよね?通常のユーザーはメール通知を受け取る必要があると思うので、無効にする設定には少し戸惑っています。どのような状況でメールを無効にする必要があるのでしょうか。

私も同様に、新規インストールしたDiscourseでメールが送信されない問題が発生しました。詳細は以下の投稿で説明しています。

問題は、app.ymlnotificationsメールアドレスが、私のSMTPプロバイダー(SendGrid)で認証されていなかったことでした。

Discourseのメインログにも、SendGridのログにも何も表示されませんでした。エラーはdiscourse-doctorを実行した際に表示されました。

Reason: 550 The from address does not match a verified Sender Identity.

まだ実行していない場合は、discourse-doctorを実行することをお勧めします。メールが送信されない理由についての洞察が得られるかもしれません。

「いいね!」 2

どうもありがとうございます!!

素晴らしいアドバイスです。Discourse-doctor については知りませんでしたが、これで多くの時間を節約できたかもしれません。

他に問題が発生した場合は、覚えておきます。 :slight_smile:

「いいね!」 1