Discourse 3.5.0.beta2-dev 的问题 - SMTP 和后台作业

错误
1

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.size 返回 0）。
  • 手动重启 Sidekiq（sv restart sidekiq）失败，因为 Sidekiq 作为服务缺失。
  • Redis 正在运行（redis-cli ping 返回 PONG），但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 个赞
2

这是预料之中的，因为这是当前版本。
相当多的人在使用相同的最新版本，并且 sidekiq 正常工作，因此电子邮件也能正常发送。

所以你可能需要帮助，因为那样你也无法重建。

并且可能有人更了解情况，可以接管这个话题，但我会说我们这里有关于 sidekiq 停止运行的话题。搜索可能会有帮助。

4 个赞
3

我继续在安装 Discourse 时遇到困难。这是 ChatGPT 整理的另一份报告。我相信它准确地反映了我的经历。

报告：Discourse 安装和 Sidekiq 服务缺失问题

背景：
我们尝试在 Vultr 实例上全新安装 Discourse，旨在建立一个稳定且可用的部署。然而，我们遇到了重大问题，特别是 Sidekiq 等服务缺失，这导致电子邮件发送和后台作业处理失败。

遇到的问题摘要

  1. 安装了意外的版本
  • 安装默认选择了 tests-passed，而不是预期的 v3.4.0.beta4-dev，这可能是一个不稳定的版本。
  • 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 可能存在的问题 – 在检索版本的方式上是否存在问题？

在我们继续重新安装之前，任何见解都将有所帮助。提前感谢！

4

它实际上并不不稳定。它现在是所有论坛的默认设置。Discourse 不会将不稳定的分支设为默认。

嗯……当你在你的论坛上访问 /sidekiq 时，你看到了什么？

你打算安装哪个分支？也许这个指南会有帮助？

3 个赞
5

我认为无论需要什么，都需要一些关于您的VPS配置的详细信息。CPU、内存、磁盘空间，以及Ubuntu LTS 24。

当你说你测试过邮件时，是用Discourse的测试功能并收到了电子邮件吗？

在我的XP中，你的app.yml文件中应该有3行关于SMTP的主要配置：

  • 用户名：
  • 密码
  • 端口：

现在根据你的描述，你以前在Discourse安装中已经让它工作了吗？

如前所述，"Tests-Passed"是推荐安装的版本。稳定版据我理解更适合带有自定义插件和主题的用户——这可能需要更频繁地更新以避免破坏。

你能分享一份包含错误的重建日志吗？记得在捕获日志时向上滚动，因为最后的错误只是一个失败的结果。你也可以遮盖敏感数据，比如SMTP用户名和密码等详细信息。

关于SMTP邮箱问题，也有一些主题可能提供解决方案。

1 个赞
7

抱歉回复晚了。正如我在回复另一条评论时所写的那样，我无法提供关于我上次失败尝试的详细信息，因为我已经删除了大部分软件以便重新尝试。一旦我能做到，我会尽快汇报。

8

感谢您详细的评论。抱歉回复迟缓。

我正在尝试使用早期版本的各种软件进行另一次安装。这使得我很难回答您关于我之前失败尝试的问题。一旦我完成下一次安装，我会及时汇报。

1 个赞
9

如果需要，可以考虑将其作为额外的测试。在 https://www.brevo.com 上设置一个免费帐户；他们有每天免费发送 300 封电子邮件的套餐。我目前就使用这个。

如果您在发送邮件时遇到问题，这或许有助于测试是否与您的邮件提供商有关。

2 个赞
10

简而言之，不要依赖 ChatGPT，这些都是虚惊一场。

寻求帮助是好的，但依赖它是个坏主意，我将在下面展示。
感谢您让我放心，我不会很快被 ChatGPT 抢走工作。 :wink:

beta4-dev 和 tests-passed 一样可能不稳定。

没有这样的文件。

Discourse 容器内不应存在这样的目录。

我对此表示怀疑。

这是预料之中的。

如果您在不是您拥有的目录下使用 git，这是正常行为。

这没有意义。而且 tests-passed 比您“预期”的要新，而不是旧。

这是因为您尝试了太多次。

6 个赞
11

我想强调这一点。
大多数时候，如果你建议 ChatGPT 存在问题，它就会找到问题，即使问题并不存在。它还会很快让我们陷入它不断建议的“修复”的无限循环中。

5 个赞
12

非常感谢！

关于人工智能，很明显 ChatGPT 并不是一个可靠的向导。另一方面，我发现调试很困难，所以像我这样的人很容易倾向于依赖它。

我刚刚成功完成了一次安装。ChatGPT（付费版）未能帮助我达成目标，但 Anthropic 的 Claude（也是付费版；我同时使用两者）最终做到了。它帮助我修复了 ChatGPT 引入的问题。

我稍后会尝试写下更多关于我的经历。感谢您所有有用的评论！

2 个赞
13

我同意。根据我的使用经验，Claude 更易于使用，并且通常能立即给出正确答案。

很高兴你成功了！

5 个赞
14

谢谢！对于某些任务来说，它们的不同之处确实很显著——几乎就像拥有不同个性的人一样。Claude 似乎更“深思熟虑”，而 ChatGPT 则倾向于得出结论并稍微跑得更快一些。我也遇到过 ChatGPT 更擅长的情况。我希望它们都能进步。人工智能帮助我写了很多实际可行的脚本，尽管我不是脚本编写者。它有潜力成为像我这样的技术困难者的绝佳工具，但它确实需要改进。被引入死胡同真的令人沮丧。:frowning:

4 个赞
15

这是关于我成功安装的简要报告，并附有一个关于如何继续的问题。

我仍然不确定为什么最近尝试 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 个赞
16

我刚刚完成了对之前 Discourse 社区的备份恢复。恢复似乎很顺利，并且可能也更新了 Docker（上面提到的问题）：

Screenshot 2025-03-02 at 9.55.48
Screenshot 2025-03-02 at 9.55.48670×179 14.4 KB

我对恢复后立即收到的这条消息感到疑惑：“非员工用户的电子邮件发送已禁用。”

参考这里的另一个帖子：

我找到了更改设置的地方。

Screenshot 2025-03-02 at 10.04.03
Screenshot 2025-03-02 at 10.04.03710×149 6.56 KB

所以，我现在假设一切都准备就绪，但如果可能的话，我希望能得到确认。“否”是正确的设置，对吗？我认为普通用户需要接收电子邮件通知，所以我对禁用设置感到有些困惑。我想知道在什么情况下需要禁用电子邮件。

17

我在全新的 Discourse 安装中遇到了类似的邮件发送问题，我在以下链接中详细说明了：

问题在于 app.yml 中的 notifications 电子邮件地址尚未与我的 SMTP 提供商（SendGrid）进行身份验证。

Discourse 主日志或 SendGrid 日志中均未显示任何内容。运行 discourse-doctor 时出现了错误：

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

如果您还没有这样做，我建议运行 discourse-doctor，因为它可能会提供更多关于邮件未发送原因的见解。

2 个赞
18

非常感谢！！

非常好的建议。我之前不知道 Discourse-doctor 这个工具，但我觉得它可能为我节省了很多时间。

如果我遇到其他问题，我会记住它的。 :slight_smile:

1 个赞