关于免费的RHEL，这些你需要知道

（原标题：关于免费的RHEL，这些你需要知道）

Red Hat Enterprise Linux（RHEL）以稳定且一致的方式为应用程序提供全生命周期托管支持，极大简化了用例开发体验。而作为用户，我们也应主动积极如何在开发中有效运用RHEL，以可预测且可重复的方式保证开发成果在转移至生产环境时不会发生任何意外。

近来，红帽正式宣布将Red Hat Enterprise Linux (RHEL) 面向个人生产用户以及部分符合特定要求的开发者团队免费开放。这不仅给整个RHEL用户社区带来颠覆性变化，同时也让之前只能使用下游或“重现版”RHEL的个人及开发者真正获得原汁原味的系统体验。在本文中，我们一起聊聊RHEL给开发者带来的额外助益。

"简单来说，免费RHEL才是RHEL。"这看着像句废话，但背后却有不少潜台词。

多年以来，红帽一直在公开发布操作系统源代码，且覆盖范围远超GNU公共许可（GPL）等各类开源许可的要求。因此，其他各方可以使用这批宝贵的源代码重构RHEL的各类替代方案——CentOS Linux、Scientific Linux等就是典型代表。如果需要，开发者及个人完全可以使用这些“重现版”系统构建应用程序，并确保开发成果能够在RHEL上稳定部署。但随着此次面向个人及开发团队的正式开放，RHEL将可直接供大家用于构建应用程序、并免费在个人生产场景下进行部署。

过去25年间，红帽在与众多客户的交互当中积累起关于操作系统方案的广泛运营知识。经过提炼，这些知识化为基于AI/ML的云服务，即Red Hat Insights。Red Hat Insights能够显著减轻RHEL带来的管理负担。而在此次RHEL全面免费之后，各合格开发团队及个人都能获得Insights带来的便利，其成果也将获得相应的认证与技能资质。

如果源代码相同、又经过RHEL认证，那么各衍生版本是否相当于同时得到了认证？

作为一家企业，红帽投入了大量时间与资金才得以满足各行业、国际与国内法规提出的认证与许可要求。具体要求往往与特定RHEL的二进制版本或测试/验证条件相关。在大多数情况下，无论是二进制文件还是特定测试条件/结果都无法轻松重现，因此相关认证并不能直接适用于采用相同源代码的其他衍生版本。而且除了源代码之外，各同源操作系统之间还存在配置差异、库差异与模块差异，强行给予认证将缺乏现实意义。

但是，各版本间的源代码还是相同的吗？

只能说大体相同，但二进制文件会存在差别。这种差异源自构建过程、编译器版本与配置选项，再加上对RHEL发行版做出的具体优化——这一切都会给二进制文件造成重大影响。红帽投入了大量精力并配合强有力的流程，才维持起目前这套包含编译器、工具与清洁底层架构的完整供应链。而这一切，都是为了在用户群体内建立信心，证明红帽核心操作系统稳定且值得信赖。

那么，认真进行重构能不能解决问题？

重构当然应该认真谨慎，但这里也要提醒大家，除非准确选取完全相同的编译器版本、优化与软件包组合，否则二进制文件必然会有所不同。例如，CentOS Linux包与RHEL包非常相似，但二者的编译库与可执行文件仍有区别。这就是相似，但不相同。这一点在认证方面非常重要，也是RHEL发布认证硬件、软件与应用程序的根本原因。而新的开发者计划允许直接获取RHEL二进制文件，就是说在需要投入生产或获取支持时，能够直接更新订阅而不再重新安装任何操作系统、应用程序或者其他组件。一切都已准备就绪，可以直接使用。

最近，GSA的FedRAMP项目也就此事对CentOS Linux做出重申。作为RHEL的下游衍生方案，CentOS Linux社区致力于对RHEL的加密模块进行重构与重新编译。但是，CentOS上所运行的Red Hat加密模块并未经过FIPS-140验证，因此FedRAMP无法在CentOS（包括CentOS 7）上对这些模块做出FIPS-140验证保证。

源代码完全一致，二进制文件也大差不差，能有什么问题？

源代码一致、二进制文件相似，但配套的软件包仍然不同——这非常重要。认证工作的核心，就是在两种高度相似的二进制文件之间找出兼容性差异。这事有点像照着食谱做蛋糕——虽然每个人都能尝试，但最终成品往往与食谱里的图片相差甚远。而认证则像是对实际成品的验证，参照食谱但却不限于食谱。在中立第三方的验证之下，符合或优于某些既有标准的方案就会赢得用户们的信任。但除非RHEL源代码的各衍生重现版本也接受相同的认证过程，否则我们绝不能说其属于认证版本。

安全与信任紧密相关，其中二进制文件的保障至关重要。下面来看几个具体案例。美国国家标准与技术研究院（NIST）负责管理着加密模块验证计划（CMVP），此项计划负责验证模块的二进制文件是否符合联邦信息处理标准140-2与140-3。提交至计划的各加密模块将经过第三方的测试与审查，以验证其是否符合既定FIPS标准。只有通过审查，我们才能断言相关模块拥有可靠的正确运行效果。

更重要的是，RHEL的多个发行版及库都经历了这样的验证。

NIST将使用未经验证的密码技术，视为未对信息或数据加以保护——换言之，视为将数据以未保护明文形式使用。如果机构称其信息或数据受到加密保护，则必须符合FIPS 140-2（有效期至2026年9月22日）或FIPS 140-3（自2020年9月22日起）。若需要使用加密技术，则必须进行验证。如果加密模块未能通过审查，即代表不得使用该模块。

大家当然可以不理FIPS验证，但至少不能认定未经验证的加密模块默认满足FIPS要求。随着对供应链安全问题的持续关注，安全管理者们越来越抗拒使用来自未知来源、也未经过任何验证的技术方案。

再来看一个例子。国防信息系统局（DISA）与供应商合作发布了针对各供应商产品的安全技术实施指南（STIG）。DISA还维护着一套Linux/Unix STIG内容列表，RHEL在其中多次出现。美国国防部的多项计划都曾针对STIG进行全面的测试及/或操作，用以证明系统变更与配置切实符合安全控制要求。值得注意的是，指南中甚至明确禁止将STIG与某些衍生操作系统共同使用。也就是说，RHEL STIG不适用于CentOS Linux，RHEL的安全测试结果只适用于RHEL自身。将测试结果直接推广至衍生操作系统属于一类安全发现（CAT 1），即最高严重性级别。CAT 1问题不存在争议，必须立即处理。

RHEL向个人及开发团队的免费开放实现了Red Hat技术储备的真正大众化推广。RHEL Insights等衍生系统所不具备的成果将给希望简化运营、并保持合规性水平的个人及团队带来巨大价值。当然，对于某些特定用例，此次免费开放也可能没有任何影响。总之，请大家务必明确区分认证与许可用例的区别，Red Hat免费开放RHEL的意义也正在于此。衍生系统供应商当然可以主动申请相同的认证与许可，但绝不能直接宣称RHEL认证也适用于他们的版本。