Ubuntu 维护：83 软件包更新已验证

#Ubuntu 包更新的定义范围

这些包来自通常的 Ubuntu 存储库，其签名元数据经过验证。在安装之前，我们比较了已安装的版本、可用版本和预期的更改。最终结果与计划的 83 更新相符，没有添加或删除任何软件包。

Systemd 现在的版本为 259.9-0ubuntu0.1. 操作系统仍为 Ubuntu 26.04 LTS。此干预保留现有内核、Node.js、Docker 和 PostgreSQL 版本以及已部署的应用程序版本。它不需要您的项目中的 PRNext npm 包更新。

#内核安全仍然是一个单独的后续工作

重新启动后，两台服务器仍运行 3 11 月安装的 Ubuntu 7.0.0-43.43 软件包中的 7.0.0-43-generic。这些官方软件包是在经过具体决定和专门检查后从提议的测试口袋中选择的，但没有在全球范围内启用该口袋。

在 5 11 月检查时，Ubuntu 的官方跟踪器仍然将该版本描述为正在进行 Ubuntu 26.04 LTS 资格。因此，本次维护中的 83 软件包更新并不构成新的 CVE-2026-98432 修复。我们之前的文章解释了内核决策以及可用包、其分发渠道和实际运行的内核之间的区别。

Ubuntu 的官方追踪器

我们之前的文章

#为什么重新启动到相同的内核？

替换磁盘上的库不会自动更新正在运行的进程已加载的副本。安装后，我们的检查仍然发现使用旧库的服务。因此，我们按顺序重新启动 VPS 实例，检查第一个实例，然后再继续第二个实例。

每次重新启动后，新的 SSH 连接都会确认管理访问权限已恢复。最终检查报告没有任何服务仍在使用旧库。 SSH 配置和现有访问权限被保留。这就是为什么即使在维护期间没有安装新内核，重新启动也是这项工作的一部分。

#启动后检查服务

我们检查了 DNS 解决方案、公共 HTTPS 响应和 PostgreSQL 准备情况，包括确认数据库已答复的简单查询。五个本机应用程序端点还返回 HTTPS 200 响应以及正常的 TLS 验证。

重新启动后，三个容器最初处于休眠状态。对本机地址的 HEAD 请求通过平台的正常机制唤醒它们。然后观察到所有五个容器都使用相同的标识符和图像运行。这些检查确定测试的端点已恢复服务；他们不会验证应用程序内的每个业务工作流程。

临时网络过滤和 MPTCP 设置保持不变。我们在启动后检查了规则，并确认 MPTCP 在每个观察到的网络命名空间中都被禁用，包括在容器唤醒之后。这些保护保留其局限性，并且不会取代内核修复。

#持续审查分阶段更新

每台服务器上的七​​个软件包仍然受到 Ubuntu 的分阶段推出的影响。我们保留了这种机制，但没有强制安装它们。 Ubuntu 的文档解释说，它分阶段分发一些更新，以限制潜在回归的影响。

同一文档指出，安全更新永远不会分阶段进行。因此，有关延迟包的消息要求检查其实际状态，而不是应用通用命令来绕过该保护。

Ubuntu 的文档

#这对您的 VPS 意味着什么

83 包反映了我们的服务器在干预时的状态。您的发行版、存储库和安装的软件将产生不同的结果。将建议的更新计划与您的安装进行比较，准备恢复选项并在续订后检查您的应用程序所依赖的服务。

这是一个过时的帐户：今天可用的版本明天可能会发生变化。对于内核，请咨询 Ubuntu 的跟踪器以了解漏洞和您的软件包系列。对于应用程序，也可以执行对用户重要的功能。成功的 HTTP 响应提供了有用的证据，其范围需要保持清晰。