[quote=“pfaffman, 帖子:10, 主题:141817”]
如果你不为 Let’s Encrypt 提供电子邮件地址，./discourse-setup 将提供 HTTP 页面。[/quote]
我认为情况已不再如此。
3 个赞
完全同意 @jomaxro。这就是为什么我说：
3 个赞
哦，抱歉，我错过了这个变更。
所以，如果用户未提供 Let’s Encrypt 通知邮箱地址，discourse-setup 现在会盲目启用 Let’s Encrypt，而不会验证域名是否解析到当前服务器。但如果提供了邮箱地址，则会执行该检查。这似乎不是一个好主意。
为什么在域名无效的情况下强制使用 HTTPS？如果计划是强制所有人始终使用 HTTPS，那么我们应该先验证域名是否有效，若无效则拒绝运行，而不是提供一个无法使用的安装。
目前的机制是：如果你未提供 Let’s Encrypt 邮箱地址，且域名未解析到服务器，discourse-setup 看似成功，但实际上启动了一个无法接受连接的 Web 服务器，因为 Nginx 找不到证书。我认为更好的做法是：不要求用户提供 Let’s Encrypt 邮箱地址，而是使用（第一位）开发者的邮箱进行 Let’s Encrypt 申请，同时仍然执行 DNS 检查。不过，这个问题似乎不太适合在当前主题中讨论。
2 个赞
不，Let’s Encrypt 的工作原理并非如此。电子邮件与域名验证无关。它仅在证书即将过期且无法续期时用于通知用户。验证始终通过 DNS 进行。
Let’s Encrypt 无法为不符合验证要求的地址颁发证书。如果它这样做，整个 Let’s Encrypt 体系将一夜之间崩溃。
4 个赞
不。这是 discourse-setup 的工作原理，或者曾经是。它过去会在确定请求证书几乎肯定会失败时保护用户。现在，它会继续前进，在根本不可能成功的情况下请求证书，并且没有任何方式向用户报告失败，因此现在它会静默失败，没有任何警告。
1 个赞
再次请问，为什么会失败？域名验证并不要求提供电子邮件。
即使验证失败，系统也从未发送过邮件。
邮件的唯一用途是：当 Let’s Encrypt 无法成功续期且证书即将过期时，通知用户。如果证书顺利续期，用户将不会收到任何邮件。
我认为这并非该变更的初衷。其初衷是无论是否提供电子邮件，都应启用 SSL。我们仍应检查域名解析情况，cc @Falco
2 个赞
如果域名无法解析到主机，将会失败。电子邮件地址无关紧要，但如果存在该地址，Discourse 设置会警告用户该地址无法解析。
4 个赞
域名解析 必须 通过 @falco，否则设置应中止。这是一个糟糕的更改。
4 个赞
因此，我在一分支中做了一些修改。其工作方式如下：
使用错误的 hostname：
root@droplet:/var/discourse# ./discourse-setup
您的 Discourse 的 hostname 是？bad-domain.com
正在检查您的域名 . . .
警告：此服务器似乎无法在 bad-domain.com:443 上访问。
连接到 http://bad-domain.com（端口 80）也失败。
这表明 bad-domain.com 解析到了错误的 IP 地址，
或者流量未被路由到您的服务器。
请在 Google 搜索“开放端口 您的云服务”以获取解决此问题的信息。
如果您仍想继续，则需要运行 cp samples/standalone.yml containers/app.yml，
并手动编辑 containers/app.yml 文件。
使用正确的 hostname：
root@droplet:/var/discourse# ./discourse-setup
您的 Discourse 的 hostname 是？good-domain.com
正在检查您的域名 . . .
连接到 good-domain.com 成功。
管理员账户的电子邮件地址？：
相关更改已提交至：
@pfaffman @codinghorror，这样看起来可以吗？
3 个赞
关于为何最初需要此变更的评论
首先，令我惊讶的是，在此变更实施近三个月以来，竟然没有收到大量投诉，甚至引发我注意的那个话题本身也并非因这一变更而遇到麻烦，所以也许这件事的影响远没有我想象的那么大。
我真正不理解的第一点是：你们真的希望通过 discourse-setup 让无法设置仅使用 HTTP 的网站成为不可能吗？我猜他们为了邮件功能已经做了一系列 DNS 配置，所以让他们再创建 A 记录或许也不算什么大问题。
关于此变更的反馈
除非你们做了我尚未注意到的变更，否则脚本会在开始提问之前先创建 app.yml。因此，你们完全可以提示类似这样的信息：“不支持未配置 DNS 的 Discourse 安装。若要在未配置 DNS 的情况下继续，请编辑 app.yml 以满足您的需求，然后运行 ./launcher rebuild app”，随后直接退出，无需进行引导安装。
此外，如果你们打算强制所有人必须使用 Let’s Encrypt 和 HTTPS，那么或许应该相应地修改 standalone.yml 和 web_only.yml，这样那些繁琐的 sed 语句就可以被移除了。
更多的思考
从我遇到的实际问题来看，我当前的安装脚本会在用户配置 DNS 之前运行：我为他们创建 Droplet，设置 Discourse，发送包含 DNS 配置说明的邮件，等待 DNS 生效，然后再修改 app.yml 以启用模板并设置 Let’s Encrypt 地址。不过，我想这仅仅是历史原因所致。我本应该做的是：先创建 Droplet，配置 Mailgun，等待 DNS 生效，然后再进行安装。这样做仍然可以让我的脚本使用 discourse-setup，而我经常用它来测试其是否正常运行（我不认为你们团队会对 discourse-setup 进行自动化测试，对吧？）
2 个赞
是的。
关于这一变更，我从未收到过任何投诉。自其上线以来，我也没有看到大量仅使用 HTTP 的 Discourse 实例。因为当你们将某事标记为可选时，所有人都会不加考虑地跳过它。在我看来，这是为 Discourse 设置安全默认值的一个绝佳改进，而这正是我们在“30 分钟指南”中所致力的一切。
[quote=“pfaffman, 帖子：11, 主题：141911”]
除非你做了我没注意到的变更，否则脚本在开始提问之前就已经创建了 app.yml。因此，你可以简单地提示：“不支持未配置 DNS 的 Discourse 安装。若要继续而不配置 DNS，请编辑 app.yml 以满足您的需求，然后运行 ./launcher rebuild app
3 个赞
tl;dr：是的，加上我推荐的那个小语言调整，这看起来不错。
同意。零投诉！看来这是个胜利。
不！并没有破坏。（！）我只是在完成了启用 HTTPS 的第二阶段安装之前，才隐约察觉到网站无法访问。而且我的设置并不是你的责任。（哦，现在它确实会破坏我的脚本，但无论如何，在 DNS 设置完成之前不进行安装会更好。我至少有一年没有进行过非 HTTPS 的安装了。）
我喜欢让我的脚本使用 discourse-setup 的原因是，它能特别确保我的安装客户获得的是标准安装。这样当有人说“我进行了安装但没成功”时，我可以运行我的脚本，完全按照他们应该做的步骤操作，然后说“嗯，我刚刚进行了一次安装，它成功了。”但我回想过去三年，似乎从未发现过任何问题，所以也许我的“测试”对任何人都没多大帮助。
5 个赞
太好了，感谢分析和审查！
已合并 PR，因此我们现在将始终验证 DNS。
4 个赞
本主题已在 25 小时后自动关闭。不再允许新回复。