Checkmk 支持这些操作系统

在进行持续集成（CI）、打包和各种测试时，要考虑的一个重要因素是支持多少和哪些操作系统。因此，必须在尽可能多的用户需求与高效的 CI 之间达成妥协。过去，我们是在 Checkmk 版本发布前不久确定结果。自 Checkmk 2.2.0 开始，我们推出了系统支持政策。这使用户对Checkmk未来的更新计划和即将支持的系统更有信心。Ubuntu 的用户尤其应该阅读这篇文章。

在Checkmk 2.1.0之前，确定支持哪些操作系统是一个独立的决定，主要根据用户调查和下载数据分析决定。一方面，在客户的要求下，实际上已经停产（或转移到 ESM）的 Ubuntu 版本可能仍然得到支持。另一方面，已经在市场上销售了很长时间的Checkmk Enterprise却被遗弃了，其实它本可以在即将推出的 Checkmk 版本的生命周期内获得更新。

定义时间框架，不再单独决定

自 2.2.0 版发布以来，明确的时间框架取代了以往在发布前不久才做出决定的做法。

新的 Checkmk 版本将只支持那些在 Checkmk 主版本发布日期之后至少三个月宣布终止支持的发行版。

我们会考虑以下支持期限规则：

• 对于企业级发行版（RHEL 及其衍生版本和 SLES），发行商通常提供10年的支持年限。
• RHEL: 维护支持
• SLES：长期服务和支持（LTSS）
• 对于社区发行版（Ubuntu 和 Debian），社区通常提供 5 年的免费支持，并且明确过此期限后不会提供有偿更新。
• Ubuntu:长期支持（LTS）
• Debian：长期支持（LTS）

如果发行商对于发行版本提供的支持年限低于2年，Checkmk将不再支持该发行版本。

此外，我们不希望为每个发行版制定过多的版本：如果一个发行版有四个以上的版本需要同时支持，我们会停止支持那些会最先不被支持的版本以及那些受支持期限很短的版本（将在发布 Checkmk 时公布）。以 SLES 为例，这意味着从当前的 2.2 版本开始，我们将不再支持版本 15 SP1：

图表说明： 红色条 “12 SP4”表示在 Checkmk 2.2 中将不再支持的 SUSE 版本，我们会在Checkmk 发布后的三个月内终止支持。在 12 SP5 和 15 SP1 至 SP4 的绿条中，15 SP1 的剩余时间最短，因此Checkmk 2.2也不会将其考虑在内。

对受支持期限很短的版本我们也将停止支持，这主要会影响到Ubuntu 半年一次的短期服务版本（STS），这些版本只提供9个月的更新。 而在偶数年的四月份发布的 LTS 版本将继续得到全面支持。

不再有短期服务版本（STS）？

有规则就有例外，或者更准确地说，是有一个经过精心安排的过渡时期。当我们在2023年6月的Checkmk大会上提出这一政策时，Checkmk 2.1.0和2.2.0已经发布，适配Ubuntu 22.10 STS版本。鉴于官方不支持将 Ubuntu STS版本 降级到之前发布的 LTS版本，我们很快意识到执行该政策会给那些已经在 Ubuntu 22.10 上使用 2.1.0 和 2.2.0 Beta 版的用户带来不必要的麻烦，因为唯一可行的解决方案就是备份、重新安装和恢复。

因此，我们的目标不是降级到 22.04，而是软升级：即 22.10 STS > 23.04 STS > 23.10 STS > 24.04 LTS。从 24.04 LTS 版本开始，受影响的 Ubuntu 用户可重新开始跟着LTS 版本的发布和支持周期走，这样我们将完全停止对 STS版本的支持。

硬件支持如何？

支持 Ubuntu STS 版本的一个常见理由是其有更好的硬件支持。毕竟，Ubuntu 23.10 配备的是内核 6.5，而 Ubuntu 22.04 配备的是内核 5.15。后者是在 2021 年 10 月发布的，因此对近两年发布的硬件的支持较差。

Canonical 意识到了这个问题，因此从 2016 年开始，就在 STS 发布几周后将 STS 版本的内核移植回最新的 LTS。它们会以附加软件包 linux-generic-hwe-22.04 的形式存在。 从点版本 .2 开始，即继LTS版本后首个STS发布后的四个月，Canonical 还将提供包含 STS 内核的安装镜像。具体如下： 2023 年 2 月发布的 Ubuntu 22.04.2 将包含 Ubuntu 22.10 的内核，2023 年 8 月发布的 Ubuntu 22.04.3 将包含 Ubuntu 23.04 的内核 6.2，2024 年 2 月发布的 22.04.4 将包含 23.10 的内核 6.5。

Ubuntu 24.04 LTS 发布四个月后，Ubuntu 22.04.5 将获得其内核，并不再发布任何 STS 内核。然后Ubuntu 24.04也会再一次重复这个过程。

因此，如果对最新硬件的支持对您来说非常必要，请务必使用最新的安装镜像。如果您使用 debootstrap 或镜像构建工具，请务必集成 HWE 内核。

面向开发人员的灵活选项

开发人员喜欢使用最先进的发行版是完全可以理解的，这样可以及时获得最新技术，并能及早发现哪些变化可能会导致未来发行版出现问题。

但这并不意味我们须为每个 STS 版本提供一版 Checkmk。虚拟化是在 STS Linux 上以客户身份运行 LTS 操作系统的最灵活方式。如果你喜欢更方便的方式，可以使用我们现成的 Docker 镜像。

方便的更新安排

即使现在规划未来更容易了，但之前在对Checkmk 旧版本进行更新时，您也需要查各 个操作系统版本对应的Checkmk版本是什么。为了简化这一过程，我们创建了更新矩阵。从这些表格中，您可以看到何时应该将 Checkmk 更新与操作系统更新结合起来，以及如何以最少的步骤完成影响多个操作系统或 Checkmk 版本的更新。例如，这里是 Ubuntu下 2.1.0 到 2.2.0 的更新矩阵截图：

我们偶尔会收到在新版本操作系统上构建旧版本 Checkmk 的请求，或者将相对较新的 Checkmk 与早已停用的发行版结合使用的请求。为了回答这些问题，我们在手册的各个章节中都加上了这些图表。具体来说，这意味着您可以找到全部信息，哪怕是要将 Ubuntu 14.04 上的“可能不知道放在哪里的”Checkmk 1.5.0升级到最新的 2.2.0 版本并在Ubuntu 22.04上使用。