如何减轻大规模修补Linux和Windows系统的痛苦

修补可能需要大量的人工和时间，需要大量的协调和过程。在本文中，担任25年以上UNIX系统管理员的Tony Green，为您提供了一些最佳技巧，以消除对Linux和Windows系统进行修补的烦恼。

在担任系统管理员的所有这些年中（我已经成为UNIX系统管理员已有25年以上），修补程序始终是每个人生存的祸根。修补需要手动进行。集中信息几乎不存在。它需要进行大量的协调才能安排停机时间，并且在不同的操作系统，发行版甚至发行版之间，流程存在巨大差异。

有很多不同的解释，但是出于我们的目的，这就是修补程序的含义：将更改应用于计算机软件，以解决功能或安全性错误，提高可用性，可靠性或性能。

痛点

众所周知，未修补的漏洞是一个巨大的问题，使组织面临巨大风险。即使您知道一个漏洞，要跟踪受影响的服务器也需要手动工作，专用工具，自定义工具开发或上述各项的组合。

列出受影响的服务器后，如何实际应用更新？IT团队对流程进行集中控制是一种常见的方法，这种方法可以很好地起作用，但是，在某些方面，这还不够。选择补丁窗口，防止服务器被补丁，并控制是否应应用所有补丁或仅应用安全补丁。

自助服务选项可以解决其中一些问题，但可以解决其他问题。想到培训，访问控制和标准执行。

修补完成后，您需要验证成功并确保您的报告系统已更新为新状态。

确保所有利益相关者都可以访问服务器的补丁程序状态，并确保数据及时准确。

如果存在这种风险，为什么还那么困难呢？

等一下，我有个主意！

作为Puppet用户，我已经有一个可以集中数据的位置，一种使数据保持准确的方法，一个RBAC系统以及触发节点上临时工作的能力。不仅如此，我所需的大多数内容已经由API和Web控制台驱动并通过其报告。那么，我还等什么呢？

我立即开始从事最终成为os_patching模块的工作。该模块在Linux（RedHat，Debian和Suse）上具有全部功能，并且从V0.11.0开始增加了对Windows的支持。正在积极开发对其他操作系统类型的支持。

它需要做什么？

• 通过自定义事实将服务器上的补丁程序状态报告回PuppetDB

• 显示哪些更新与安全性相关（如果可能）

• 允许将服务器分配给“补丁程序窗口”，以进行简单的调度

• 允许为服务器设置停电时间，以防止任何修补活动

• 能够控制是否执行修补后重新引导

• 在定义的一组服务器上启用“补丁运行”的执行，包括：

• 能够清理软件包缓存

• 限制安全补丁

• 为OS软件包命令的参数提供替代

• 能够从命令行，控制台或通过API触发补丁运行

• 控制谁可以执行补丁程序运行

• 将规范的修补状态数据存储在节点上

最后一项是最重要的一项。无论发生什么事情，我都想确保节点上的事实是修补信息的真相之源，而其他一切都是从那里得到的。

它是如何做到的？

要开始使用该模块，您只需要在节点上声明os_patching模块即可。它将设置一个计划任务来刷新补丁信息，并允许访问任务以执行补丁。

自定义事实是整个模块的基础，因此确保我们拥有一个良好的结构和管理系统是关键。

自定义事实从缓存的值中提取其值，其中一些是由计划的脚本/任务生成的，而另一些是由os_patching类生成的。我们将这些值缓存为每次运行Facter时都有数百个节点命中apt / yum服务器会导致一些非常大的问题。默认情况下，计划的脚本每小时刷新一次缓存数据，但是可以通过分类覆盖它。

事实分为两部分：

陈述事实

这些事实表明了节点的状态。

• 是否有要应用的补丁？

• 如果是这样，多少？

• 它们与安全相关吗？

• 是否需要重启节点？

• 是否需要重新启动应用程序？

• 补丁被阻止了吗？

控制事实

这些事实控制着修补的执行。

• 我们是否定义了遮光窗口？

• 节点是否已分配给修补窗口？

• 该节点是否应覆盖重新启动参数？

事实使我们可以访问审核车队和控制补丁运行所需的所有信息。

可以将节点分配给apatch_window进行分组（例如“ Group 1”，“ Week 4”）。可以为中断冻结或无法修补的节点定义中断窗口。

结合这些事实，可以编写查询，例如：

puppet task run os_patching::patch_server --query='nodes[certname] { facts.os_patching.patch_window = "Week3" and facts.os_patching.package_update_count > 0 and facts.os_patching.blocked = false }'

此任务将修补分配给修补程序窗口“ Week3”，未被阻止且有修补程序等待应用的任何节点。

控制事实

如果需要，您还可以配置许多其他设置：

• patch_window：一个字符串描述符，用于“标记”一组计算机，即Week3或Group2

• blackout_windows：日期时间开始/结束日期的哈希值，在此期间阻止更新

• security_only：布尔值，启用后，仅会更新security_package_updates软件包和依赖项

• reboot_override：boolean，覆盖任务的重启标志（默认值：false）

• dpkg_options/yum_options：分别是dpkg或yum的附加标志/选项的字符串

您可以在hiera中进行设置。例如，我的全局配置在接下来的几年中会出现一些中断窗口：

其实是打补丁

由于我将要使用任务，因此我不必担心如何实现RBAC或如何触发补丁程序运行。

我设置了3个任务：

• clean_cache：清除节点上的程序包缓存（例如，yum clean all）

• refresh_fact：强制重新生成修补缓存数据

• patch_server：实际上运行修补程序

patch_server现在，我们将更详细地介绍这个任务。

触发后，任务将首先检查事实的值os_patching.blocked。如果将其设置为true，则由于无法继续修补的原因而导致任务退出。这通常意味着节点位于中断窗口内。

如果有要应用的补丁程序，则该任务会在超时值（默认为3600秒）下启动OS补丁程序命令。它等待完成，然后拉回作业信息以进行报告。

然后刷新事实并将其推送到puppetserver（puppet fact upload），然后我们进入Reboot Town。

要重启还是不重启

请记住，修补节点没有任何好处，除非您重新启动使用受影响软件包的进程。这可以像重新启动应用程序一样简单，也可以像完全重新启动一样具有侵入性。那么我们如何控制呢？

您可以使用reboot参数来控制任务将执行的重新启动操作。它接受以下值：

• always：无论任务执行过程中发生了什么，都请重新启动节点。这将总是触发重启

• never：无论任务执行过程中发生了什么，都不要重新引导节点。这绝不会触发重启

• patched：如果应用了任何补丁，则触发重启

• smart：使用操作系统工具（needs-restarting在redhat上，/var/run/reboot_required在debian上）确定修补后是否需要重新启动。这只会触发重启内核/核心库的更新。

您还可以使用该事实os_patching.reboot_override在粒度级别上自定义行为，例如，将所有节点设置为重启（三个节点除外），never因为您知道这些节点将在以后手动重启。

流程图

这有点复杂，在流程图中可能会更容易。

输出量

以下是任务输出的示例，可从命令行，通过控制台或通过API看到。

条目是：

• pinned_packages：任何在操作系统层锁定/固定的软件包版本

• debug：修补命令的完整输出

• start_time/end_time：任务开始/停止的时间

• reboot：使用的重新启动参数

• packages_updated：受影响的软件包

• security：使用的安全性参数

• job_id：yum作业ID（仅在RedHat系列节点上填充）

• message：状态信息

TL; DR

上面有很多信息，但是您可能只想开始使用该os_patching模块，所以这里是步骤。

• 添加mod 'albatrossflavour-os_patching'，'0.11.0'您Puppetfile和部署控制回购

• 对您希望能够与os_patching模块 打补丁的节点进行分类

• include os_patching在修补配置文件中

• 使用PE控制台

• 在这些节点上运行puppet并期望进行以下更改：

• 该文件/usr/local/bin/os_patching_fact_generation.sh将被安装（c:programdataos_patchingos_patching_fact_generation.ps1在Windows上）

• 将设置Cron作业以每小时（使用fqdn_rand）并在重新启动时运行脚本

• 目录/var/cache/os_patching将被创建

• /usr/local/bin/os_patching_fact_generation.sh 将运行并将文件填充到 /var/cache/os_patching

• 新的事实（os_patching）将可用

• os_patching在分类的节点上查看事实的内容：

• facter -p os_patching

• puppet-task run facter_task fact=os_patching --nodes centos.example.com

• 使用控制台查看事实

• 在以下节点上执行补丁程序运行：

• puppet task run os_patching::patch_server --query='nodes[certname] { facts.os_patching.package_update_count > 0 and facts.os_patching.blocked = false }'

• 通过控制台运行任务。