我们刚刚发布了一个支持 TLS 1.3 的新基础镜像
。
用户需要通过命令行重新构建以获取此新功能。我们还更新了一些依赖项,从 Ubuntu 16.04 迁移到了 Debian Buster,更新了 SSL 加密套件列表以匹配 https://ssl-config.mozilla.org/ 的中间配置,并将 Ruby 升级到了 2.6.4。
由于上述更新,我们将在本周晚些时候强制要求通过命令行进行重新构建。
我们刚刚发布了一个支持 TLS 1.3 的新基础镜像
。
用户需要通过命令行重新构建以获取此新功能。我们还更新了一些依赖项,从 Ubuntu 16.04 迁移到了 Debian Buster,更新了 SSL 加密套件列表以匹配 https://ssl-config.mozilla.org/ 的中间配置,并将 Ruby 升级到了 2.6.4。
由于上述更新,我们将在本周晚些时候强制要求通过命令行进行重新构建。
只是好奇,从 Ubuntu 迁移到 Debian 的动机是什么?
系统管理员出于某些原因更倾向于使用它,而我们新的托管基础设施(几乎已完全切换)基于 Debian。Ubuntu 源自 Debian 上游,因此从某种意义上说,这是在向源头靠拢。一个好处是它相对较新,Debian 非常保守,但我们时机把握得很好,因为 Buster 在一两个月前刚刚发布。
此更改将如何影响自托管实例?
我没想到这会有什么太大影响。在我自托管的实例中,服务器运行的是 Ubuntu,但这涉及的是 Discourse Docker 容器内部运行的内容(可以是任何系统——许多 Docker 容器使用轻量级操作系统,如 alpine)。这不会影响服务器操作系统。
嗯,我明白你的意思。我几个小时前更新了实例,但除了 SSL 版本升级到 1.3 之外,似乎没有任何变化。我原以为需要对服务器操作系统进行某种升级,但事实并非如此。
2 篇帖子已拆分到新主题:不使用 nginx 使用基础镜像