• AWS Systems Manager CloudWatch 控制面板在 2026 年 4 月 30 日之后将不再可用。客户可以像现在一样继续使用 Amazon CloudWatch 控制台来查看、创建和管理其 Amazon CloudWatch 控制面板。有关更多信息，请参阅 [Amazon CloudWatch 控制面板文档](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。
# Patch Manager 操作是如何工作的
本节介绍一些技术细节，说明Patch Manager（AWS Systems Manager 中的一项工具）如何确定安装哪些补丁，以及如何在每个受支持的操作系统上安装这些补丁。对于 Linux 操作系统，其还提供有关在自定义补丁基准中为补丁指定源存储库（而非托管式节点上配置的默认源存储库）的信息。此节还提供了有关补丁基准规则在不同的 Linux 操作系统分发版上的工作原理的详细信息。
**注意**
无论您使用哪种配置方法或类型进行修补操作，以下主题中的信息都适用：
Quick Setup 中配置的补丁策略
Quick Setup 中配置的主机管理选项
运行补丁 `Scan` 或 `Install` 任务的维护时段
按需 **Patch now**（立即修补）操作
**Topics**
+ [如何计算软件包发布日期和更新日期](patch-manager-release-dates.md)
+ [如何选择安全性补丁](patch-manager-selecting-patches.md)
+ [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)
+ [如何安装补丁](patch-manager-installing-patches.md)
+ [补丁基准规则在基于 Linux 的系统上的工作原理](patch-manager-linux-rules.md)
+ [Linux 和 Windows Server 之间的补丁操作差异](patch-manager-windows-and-linux-differences.md)
# 如何计算软件包发布日期和更新日期
**重要**
本页面上的信息适用于 Amazon Elastic Compute Cloud（Amazon EC2）实例的 Amazon Linux 2 和 Amazon Linux 2023 操作系统（OS）。这些 OS 类型的软件包由 Amazon Web Services 创建和维护。其他操作系统的软件包和存储库的发布日期和更新日期的计算方式受其制造商管理方式的影响。对于除 Amazon Linux 2 和 Amazon Linux 2023 之外的操作系统，如 Red Hat Enterprise Linux，请参阅制造商的文档，以了解有关如何更新和维护其软件包的信息。
在您创建的[自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom)设置中，对于大多数操作系统类型，您可以指定补丁在特定天数后自动批准安装。AWS 提供了几个预定义的补丁基准，其中包括 7 天的自动批准日期。
*自动批准延迟*是发布补丁后到自动批准补丁用于修补前等待的天数。例如，可以使用 `CriticalUpdates` 分类创建规则，并将其配置为自动批准延迟为 7 天。此时，发布日期或最后更新日期为 7 月 7 日的新关键补丁将在 7 月 14 日自动获得批准。
为了避免在 Amazon Linux 2 和 Amazon Linux 2023 上出现自动批准延迟的意外结果，了解其发布日期和更新日期的计算方式至关重要。
**注意**
如果 Amazon Linux 2 或 Amazon Linux 2023 存储库未提供软件包的发布日期信息，则Patch Manager会将软件包的构建时间用作自动批准日期规范的日期。如果无法确定软件包的构建时间，Patch Manager 会使用默认日期 1970 年 1 月 1 日。这将导致 Patch Manager 绕过补丁基准（配置为批准 1970 年 1 月 1 日之后任一日期发布的补丁）中的所有自动批准日期规范。
在大多数情况下，安装补丁之前的自动批准等待时间根据 `updateinfo.xml` 中的 `Updated Date` 值，而不是 `Release Date` 值计算。以下是有关这些日期计算的重要细节：
+ `Release Date` 是指*通知*发布的日期。但这并不意味着该软件包在相关存储库中可用。
+ `Update Date` 是指通知最后更新的日期。通知的更新可以指文本更新或描述更新这样的小更新。但这并不意味着该软件包在该日期发布，也不意味着在相关存储库中可用。
这意味着如果软件包的 `Update Date` 值为 7 月 7 日，可能直到（例如）7 月 13 日才能安装。假设在这种情况下，如果补丁基准指定的自动批准延迟为 7 天，则会在 7 月 14 日的 `Install` 操作中运行。因为 `Update Date` 值是运行日期前 7 天，所以软件包中的补丁和更新将在 7 月 14 日安装。即使自软件包可用于实际安装以来仅过了 1 天，安装仍会进行。
+ 包含操作系统或应用程序补丁的软件包在首次发布后可以更新多次。
+ 软件包可以发布到 AWS 托管存储库中，但如果以后发现它有问题，则可以回滚。
在某些补丁操作中，这些因素可能并不重要。例如，如果补丁基准配置为安装严重性的值为 `Low` 和 `Medium`，且分类为 `Recommended` 的补丁，则任何自动批准延迟都可能几乎不会对您的操作产生影响。
但是，如果关键或高严重性补丁的安装时间较为重要，您可能需要对补丁的安装时间进行更多的控制。执行此操作的建议方法是使用替代补丁源存储库，而不是默认存储库来执行托管节点上的补丁操作。
您可以在创建自定义补丁基准时指定备用补丁源存储库。在每个自定义补丁基准中，您可以为多达 20 个版本的受支持的 Linux 操作系统指定补丁源配置。有关更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
# 如何选择安全性补丁
Patch Manager（AWS Systems Manager 中的一项工具）的主要设计意图在于在托管式节点上安装与安全性相关的操作系统更新。默认情况下，Patch Manager 并非安装所有可用的补丁，而只安装一小部分旨在提高安全性的补丁。
默认情况下，除非安装其他软件包更新需要替换，Patch Manager 不会将软件包存储库中标记为已过时软件包替换为任何具有不同名称的替换软件包。而对于更新软件包的命令，Patch Manager 仅会报告已安装但已过时的软件包并为其安装缺失的更新。这是因为替换已过时软件包通常需要卸载现有软件包并安装其替换软件包。替换已过时软件包可能会引入不在计划内的重大更改或额外功能。
这种行为与 YUM 和 DNF 的 `update-minimal` 命令一致，后者也侧重于安全更新而不是功能升级。有关更多信息，请参阅 [如何安装补丁](patch-manager-installing-patches.md)。
**注意**
当您在补丁基准规则中使用 `ApproveUntilDate` 参数或 `ApproveAfterDays` 参数时，Patch Manager会使用协调世界时 (UTC) 评估补丁发布日期。
例如，对于 `ApproveUntilDate`，如果您指定一个日期（例如 `2025-11-16`），则在 `2025-11-16T00:00:00Z` 到 `2025-11-16T23:59:59Z` 之间发布的补丁将获得批准。
请注意，托管节点上的本机软件包管理器显示的补丁发布日期可能因系统本地时区而异，但Patch Manager始终使用 UTC 时间进行审批计算。这确保了与官方安全公告网站上发布的补丁发布日期保持一致。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布商报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如[常见漏洞评分系统](https://www.first.org/cvss/) (CVSS)），或者[国家漏洞数据库](https://nvd.nist.gov/vuln) (NVD) 发布的指标中获取严重性级别。
**注意**
在 Patch Manager 支持的所有基于 Linux 的系统中，您可以选择为托管式节点配置的不同源存储库，以便通常用于安装非安全性更新。有关信息，请参阅[如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
请从以下选项卡中进行选择，了解 Patch Manager 如何为您的操作系统选择安全补丁。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
在 Amazon Linux 2 上处理预配置存储库的方式与在 Amazon Linux 2023 上不同。
在 Amazon Linux 2 上，Systems Manager 补丁基准服务使用托管节点上的预配置存储库。节点上通常有两个预配置存储库（存储库）：
**在 Amazon Linux 2 上**
+ **存储库 ID**：`amzn2-core/2/architecture`
**存储库名称**：`Amazon Linux 2 core repository`
+ **存储库 ID**：`amzn2extra-docker/2/architecture`
**存储库名称**：`Amazon Extras repo for docker`
**注意**
*架构*可以是 x86\$164 或（对于 Graviton 处理器）aarch64。
当您创建 Amazon Linux 2023（AL2023）实例时，它包含 AL2023 版本和您选择的特定 AMI 中可用的更新。AL2023 实例在启动时不会自动接收其他重大和重要的安全更新。相反，通过 AL2023 支持的默认开启的*版本化存储库功能进行确定性升级*，您可以根据满足您特定需求的计划应用更新。有关更多信息，请参阅《Amazon Linux 2023 User Guide》**中的 [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)。
在 AL2023 上，预配置的存储库如下所示：
+ **存储库 ID**：`amazonlinux`
**存储库名称**：Amazon Linux 2023 存储库
在 Amazon Linux 2023（预览版）上，预配置的存储库与程序包更新的*锁定版本*相关。AL2023 的新 Amazon Machine Images（AMIs）在发布后会锁定到特定版本。对于补丁更新，Patch Manager 会检索补丁更新存储库的最新锁定版本，然后根据该锁定版本的内容更新托管式节点上的程序包。
**软件包管理器**
Amazon Linux 2 托管节点使用 Yum 作为软件包管理器。Amazon Linux 2023 使用 DNF 作为软件包管理器。
两个程序包管理器都将*更新通知*概念作为名为 `updateinfo.xml` 的文件使用。更新通知只是修复特定问题的软件包的集合。Patch Manager 将更新通知中的所有软件包视为安全性软件包。单个软件包未分配分类或严重性级别。因此，Patch Manager 会向相关软件包分配更新通知属性。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
有关**包括非安全性更新**选项的更多信息，请参阅[如何安装补丁](patch-manager-installing-patches.md)和[补丁基准规则在基于 Linux 的系统上的工作原理](patch-manager-linux-rules.md)。
------
#### [ CentOS Stream ]
在 CentOS Stream 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。以下列表提供了虚构 CentOS 9.2 的示例 Amazon Machine Image (AMI)：
+ **存储库 ID**：`example-centos-9.2-base`
**存储库名称**：`Example CentOS-9.2 - Base`
+ **存储库 ID**：`example-centos-9.2-extras`
**存储库名称**：`Example CentOS-9.2 - Extras`
+ **存储库 ID**：`example-centos-9.2-updates`
**存储库名称**：`Example CentOS-9.2 - Updates`
+ **存储库 ID**：`example-centos-9.x-examplerepo`
**存储库名称**：`Example CentOS-9.x – Example Repo Packages`
**注意**
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
CentOS Stream 节点将 DNF 用作软件包管理器。软件包管理器使用更新通知概念。更新通知只是修复特定问题的软件包的集合。
但是，CentOS Stream 默认存储库不配置更新通知。这意味着 Patch Manager 不检测默认 CentOS Stream 存储库上的软件包。要允许 Patch Manager 处理更新通知中未包含的软件包，您必须启用补丁基准规则中的 `EnableNonSecurity` 标记。
**注意**
支持 CentOS Stream 更新通知。带有更新通知的存储库发布后即可供下载。
------
#### [ Debian 服务器 ]
在 Debian Server 上，Systems Manager 补丁基准服务使用实例上的预配置存储库（存储库）。这些预配置存储库用于提取可用软件包升级的更新列表。在这一点上，Systems Manager 的作用类似于 `sudo apt-get update` 命令。
然后，在 `debian-security codename` 存储库中筛选软件包。这就表示，在 Debian Server 的每个版本上，Patch Manager 仅识别属于该版本关联存储库一部分的升级，如下所示：
+ Debian Server 11：`debian-security bullseye`
+ Debian Server 12：`debian-security bookworm`
------
#### [ Oracle Linux ]
在 Oracle Linux 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。节点上通常有两个预配置存储库。
**Oracle Linux 7**：
+ **存储库 ID**：`ol7_UEKR5/x86_64`
**存储库名称**：`Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)`
+ **存储库 ID**：`ol7_latest/x86_64`
**存储库名称**：`Oracle Linux 7Server Latest (x86_64)`
**Oracle Linux 8**：
+ **存储库 ID**：`ol8_baseos_latest`
**存储库名称**：`Oracle Linux 8 BaseOS Latest (x86_64)`
+ **存储库 ID**：`ol8_appstream`
**存储库名称**：`Oracle Linux 8 Application Stream (x86_64)`
+ **存储库 ID**：`ol8_UEKR6`
**存储库名称**：`Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)`
**Oracle Linux 9**：
+ **存储库 ID**：`ol9_baseos_latest`
**存储库名称**：`Oracle Linux 9 BaseOS Latest (x86_64)`
+ **存储库 ID**：`ol9_appstream`
**存储库名称**：`Oracle Linux 9 Application Stream Packages(x86_64)`
+ **存储库 ID**：`ol9_UEKR7`
**存储库名称**：`Oracle Linux UEK Release 7 (x86_64)`
**注意**
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
Oracle Linux 托管式节点将 Yum 用作软件包管理器，并且 Yum 将更新通知表现为名为 `updateinfo.xml` 的文件。更新通知只是修复特定问题的软件包的集合。单个软件包未分配分类或严重性级别。出于这个原因, Patch Manager 会向相关软件包分配更新通知属性，并根据补丁基准中指定的分类筛选器安装软件包。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。节点上通常有三个预配置存储库。
所有更新都是从托管式节点上配置的远程存储库下载。因此，节点必须具有对 Internet 的出站访问权限才能连接到存储库，以便执行修补。
**注意**
如果在**创建补丁基准**页面中选中了**包括非安全性更新**复选框，则未分配到 `updateinfo.xml` 文件中的软件包（或包含一个没有正确格式的分类、严重性和日期值的文件的软件包）可以包含在补丁的预筛选列表中。但是，为了应用补丁，补丁仍必须符合用户指定的补丁基准规则。
Red Hat Enterprise Linux 7 托管式节点将 Yum 用作程序包管理器。AlmaLinux、Red Hat Enterprise Linux 8 和 Rocky Linux 托管式节点使用 DNF 作为程序包管理器。两个程序包管理器都将更新通知概念作为名为 `updateinfo.xml` 的文件使用。更新通知只是修复特定问题的软件包的集合。单个软件包未分配分类或严重性级别。出于这个原因, Patch Manager 会向相关软件包分配更新通知属性，并根据补丁基准中指定的分类筛选器安装软件包。
RHEL 7
以下存储库 ID 与 RHUI 2 相关联。RHUI 3 于 2019 年 12 月推出，并为 Yum 存储库 ID 引入了不同的命名方案。根据您从中创建托管式节点的 RHEL-7 AMI，您可能需要更新命令。有关更多信息，请参阅 *Red Hat 客户门户*上的 [Repository IDs for RHEL 7 in AWS Have Changed](https://access.redhat.com/articles/4599971)。
+ **存储库 ID**：`rhui-REGION-client-config-server-7/x86_64`
**存储库名称**：`Red Hat Update Infrastructure 2.0 Client Configuration Server 7`
+ **存储库 ID**：`rhui-REGION-rhel-server-releases/7Server/x86_64`
**存储库名称**：`Red Hat Enterprise Linux Server 7 (RPMs)`
+ **存储库 ID**：`rhui-REGION-rhel-server-rh-common/7Server/x86_64`
**存储库名称**：`Red Hat Enterprise Linux Server 7 RH Common (RPMs)`
AlmaLinux、8、RHEL 8 和 Rocky Linux 8
+ **存储库 ID**：`rhel-8-appstream-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)`
+ **存储库 ID**：`rhel-8-baseos-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)`
+ **存储库 ID**：`rhui-client-config-server-8`
**存储库名称**：`Red Hat Update Infrastructure 3 Client Configuration Server 8`
AlmaLinux 9、RHEL 9 和 Rocky Linux 9
+ **存储库 ID**：`rhel-9-appstream-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)`
+ **存储库 ID**：`rhel-9-baseos-rhui-rpms`
**存储库名称**：`Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)`
+ **存储库 ID**：`rhui-client-config-server-9`
**存储库名称**：`Red Hat Enterprise Linux 9 Client Configuration`
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 托管式节点上，ZYPP 库从以下位置获取可用补丁的列表（软件包集合）：
+ 存储库的列表：`etc/zypp/repos.d/*`
+ 软件包信息：`/var/cache/zypp/raw/*`
SLES 托管式节点将 Zypper 用作软件包管理器，并且 Zypper 使用补丁的概念。补丁只是修复特定问题的程序包的集合。Patch Manager 处理补丁中所有引用为与安全性相关的软件包。因为没有为单个软件包提供分类或严重性，所以 Patch Manager 为软件包分配它们属于的补丁的属性。
------
#### [ Ubuntu Server ]
在 Ubuntu Server 上，Systems Manager 补丁基准服务使用托管式节点上的预配置存储库（储存库）。这些预配置存储库用于提取可用软件包升级的更新列表。在这一点上，Systems Manager 的作用类似于 `sudo apt-get update` 命令。
然后，将从 `codename-security` 存储库筛选软件包，其中的代号对应唯一的发行版本，例如 `trusty` 适用于 Ubuntu Server 14。Patch Manager 只识别包含在这些储存库的升级：
+ Ubuntu Server 16.04 LTS：`xenial-security`
+ Ubuntu Server 18.04 LTS：`bionic-security`
+ Ubuntu Server 20.04 LTS：`focal-security`
+ Ubuntu Server 22.04 LTS：`jammy-security`
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
------
#### [ Windows Server ]
在 Microsoft Windows 操作系统上，Patch Manager 检索 Microsoft 通过其发布至 Microsoft 更新的以及 Windows Server Update Services (WSUS) 自动获取的可用更新的列表。
**注意**
Patch Manager 仅为支持 Patch Manager 的 Windows Server 操作系统版本提供可用补丁。例如，Patch Manager 不能用于修补 Windows RT。
Patch Manager 持续监控每个 AWS 区域 中的新更新。每个区域每天至少刷新一次可用更新的列表。在处理来自 Microsoft 的补丁信息时，Patch Manager 会删除已被其补丁列表中的后续更新取代的更新。因此，Patch Manager 只显示最新更新，以供您安装。例如，如果 `KB4012214` 取代了 `KB3135456`，则 `KB4012214` 会显示为 Patch Manager 的更新。
同样，Patch Manager 仅可安装在修补操作期间托管节点上可用的补丁。默认情况下，Windows Server 2019 和 Windows Server 2022 会移除由较新更新所取代的更新。因此，如果您在 Windows Server 补丁基准中使用 `ApproveUntilDate` 参数，但 `ApproveUntilDate` 参数中选择的日期*早于*最新补丁发布的日期，则会出现以下情况：
+ 取代的补丁已从节点中删除，因此无法使用 Patch Manager 进行安装。
+ 节点上存在最新的替换补丁，但尚未批准按照 `ApproveUntilDate` 参数的指定日期进行安装。
这意味着托管节点在 Systems Manager 操作方面是合规的，即使可能未安装上个月的关键补丁亦是如此。使用 `ApproveAfterDays` 参数时也可能出现同样的情况。由于 Microsoft 取代的补丁行为，可以设置一个数字（通常大于 30 天），这样，如果 Microsoft 的最新可用补丁是在经过 `ApproveAfterDays` 中的天数之前发布的，则绝不会安装 Windows Server 的补丁。请注意，如果您修改了 Windows 组策略对象（GPO）设置，以使取代的补丁在托管式节点上可用，则此系统行为不适用。
**注意**
在某些情况下，Microsoft 会为未指定更新日期和时间的应用程序发布补丁。在这些情况下，系统会默认提供 `01/01/1970` 的更新日期和时间。
------
# 如何指定备用补丁源存储库 (Linux)
当您使用托管式节点上配置的默认存储库执行修补操作时，Patch Manager（AWS Systems Manager 中的一项工具）会扫描或安装与安全性相关的补丁。这是 Patch Manager 的默认行为。有关 Patch Manager 如何选择和安装安全性补丁的完整信息，请参阅 [如何选择安全性补丁](patch-manager-selecting-patches.md)。
不过，在 Linux 系统中，您还可以使用 Patch Manager 安装与安全性无关的补丁，或安装与托管式节点上配置的默认源存储库不同的源存储库中的补丁。您可以在创建自定义补丁基准时指定备用补丁源存储库。在每个自定义补丁基准中，您可以为多达 20 个版本的受支持的 Linux 操作系统指定补丁源配置。
例如，假设您的 Ubuntu Server 实例集同时包括 Ubuntu Server 25.04 托管节点。在这种情况下，您可以在相同的自定义补丁基准中为每个版本指定备用存储库。对于每个版本，您提供名称，指定操作系统版本类型 (产品)，并提供存储库配置。您也可以指定适用于所有版本的受支持的操作系统的单个备用源存储库。
**注意**
运行为托管式节点指定备用补丁存储库的自定义补丁基准，不会使这些存储库成为操作系统中的新默认存储库。修补操作完成后，以前配置为节点操作系统的默认存储库的存储库仍为默认存储库。
有关使用此选项的示例场景的列表，请参阅本主题后面的[备用补丁源存储库的示例用法](#patch-manager-alternative-source-repository-examples)。
有关默认和自定义补丁基准的信息，请参阅 [预定义和自定义补丁基准](patch-manager-predefined-and-custom-patch-baselines.md)。
**示例：使用控制台**
要在 Systems Manager 控制台中指定备用补丁源存储库，请使用**创建补丁基准**上的**补丁来源**部分。有关使用 **Patch sources (补丁源)** 选项的信息，请参阅[创建适用于 Linux 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-linux.md)。
**示例：使用 AWS CLI**
有关将 `--sources` 选项与 AWS Command Line Interface (AWS CLI) 结合使用的示例，请参阅 [创建对不同操作系统版本使用自定义存储库的补丁基准](patch-manager-cli-commands.md#patch-manager-cli-commands-create-patch-baseline-mult-sources)。
**Topics**
+ [备用存储库的重要注意事项](#alt-source-repository-important)
+ [备用补丁源存储库的示例用法](#patch-manager-alternative-source-repository-examples)
## 备用存储库的重要注意事项
使用备用补丁存储库计划修补策略时，请注意以下几点：
**强制执行存储库更新验证（YUM 和 DNF）**
如果无法建立与存储库的连接，Linux 发行版上软件包管理器的默认配置可能会设置为跳过无法访问的软件包存储库。要强制执行存储库更新验证，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
**只指定用于修补的存储库**
指定备用存储库并不意味着指定*额外* 存储库。您可以选择指定除托管式节点上配置为默认存储库以外的存储库。但是，如果需要应用默认存储库更新，还必须在备用补丁源配置中指定默认存储库。
例如，在 Amazon Linux 2 托管式节点上，默认存储库为 `amzn2-core` 和 `amzn2extra-docker`。如果需要在修补操作中包括 Extra Packages for Enterprise Linux (EPEL) 存储库，您必须将所有三个存储库都指定为备用存储库。
**注意**
运行为托管式节点指定备用补丁存储库的自定义补丁基准，不会使这些存储库成为操作系统中的新默认存储库。修补操作完成后，以前配置为节点操作系统的默认存储库的存储库仍为默认存储库。
**基于 YUM 的分发版本的修补行为取决于 updateinfo.xml 清单**
为基于 YUM 的分发版本（如 Amazon Linux 2 或 Red Hat Enterprise Linux）指定备用补丁存储库时，修补行为取决于存储库是否包含一个采用正确格式的完整 `updateinfo.xml` 文件形式的更新清单。此文件指定各软件包的发行日期、分类和严重性。以下任一项都会影响修补行为：
+ 如果筛选**分类**和**严重性**，但并未在 `updateinfo.xml` 中指定它们，筛选器将不会包含此软件包。这也意味着没有 `updateinfo.xml` 文件的软件包不会包含在修补中。
+ 如果按 **ApprovalAfterDays** 筛选，但软件包的发行日期不是 Unix Epoch 格式（或未指定发行日期），筛选器将不会包含此软件包。
+ 如果您在**创建补丁基准**页面中选择了**包括非安全性更新**复选框，则存在例外。在这种情况下，没有 `updateinfo.xml` 文件（或包含此文件但 **Classification**（分类）、**Severity**（严重性）和 **Date**（日期）值格式不正确）的软件包*将*包含在补丁的预筛选列表中。（它们仍必须满足其他补丁基准规则要求才能安装。）
## 备用补丁源存储库的示例用法
**示例 1 – Ubuntu Server 的非安全性更新**
在使用 AWS 提供的预定义补丁基准 `AWS-UbuntuDefaultPatchBaseline` 的 Ubuntu Server 托管式节点机群上，您已经在使用 Patch Manager 安装安全性补丁。您可以创建基于此默认补丁基准的新补丁基准，但在批准规则中指定您也希望安装属于默认分配的与安全性无关的更新。当对节点运行此补丁基准时，将应用针对安全性和非安全性问题的补丁。您还可以选择在为基准指定的补丁异常中批准非安全性补丁。
**示例 2 – Ubuntu Server 的个人软件包存档 (PPA)**
Ubuntu Server 托管式节点正在运行通过 [Ubuntu 个人软件包归档 (PPA)](https://launchpad.net/ubuntu/+ppas) 分发的软件。在这种情况下，需创建补丁基准，用于指定已在托管式节点上配置为修补操作源存储库的 PPA 存储库。然后使用 Run Command 在节点上运行补丁基准文档。
**示例 3：受支持 Amazon Linux 版本上的企业内部应用程序**
您需要在 Amazon Linux 托管式节点上运行满足行业监管合规性要求所需的一些应用程序。您可以在节点上为这些应用程序配置存储库，使用 YUM 对这些应用程序进行初始安装，然后更新或创建新的补丁基准以包括此新企业存储库。此后，您可以使用 Run Command 运行 `AWS-RunPatchBaseline` 文档，并通过 `Scan` 选项查看企业软件包是否列在已安装软件包中以及在托管式节点上是否为最新。如果它不是最新的，可以使用 `Install` 选项再次运行该文档来更新应用程序。
# 如何安装补丁
Patch Manager 是 AWS Systems Manager 中的一个工具，使用操作系统内置的软件包管理器在托管式节点上安装更新。例如，在 Amazon Linux 2023 上的 Windows Server 和 `DNF` 上使用 Windows 更新 API。补丁管理器会考虑节点上现有的软件包管理器和存储库配置，包括存储库状态、映像 URL、GPG 验证等设置以及 `skip_if_unavailable` 等选项。
Patch Manager 不会安装新软件包来替换当前安装的已过时软件包。（例外情况：新软件包是正在安装的其他软件包更新的依赖项，或者新软件包与已过时软件包同名。） 相反，Patch Manager 会报告已安装的软件包并安装可用的更新。这种方法有助于防止在用一个软件包替换另一个软件包时，可能导致的系统功能意外更改。
如果需要卸载已过时软件包并安装替换软件包，则可能需要使用自定义脚本或软件包管理器命令，而不是使用标准的 Patch Manager 操作。
请从以下选项卡中进行选择，了解 Patch Manager 如何在操作系统上安装补丁。
------
#### [ Amazon Linux 2 and Amazon Linux 2023 ]
在 Amazon Linux 2 和 Amazon Linux 2023 托管节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. YUM 更新 API（Amazon Linux 2）或 DNF 更新 API（Amazon Linux 2023）用于已批准的补丁，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。这是因为未选中**包括非安全性更新**复选框。预定义的基准等同于具有以下内容的自定义基准：
+ 未选中**包括非安全性更新**复选框
+ 严重性列表为 `[Critical, Important]`
+ 分类列表为 `[Security, Bugfix]`
对于 Amazon Linux 2，此工作流程的等效 yum 命令为：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
对于 Amazon Linux 2023，此工作流程的等效 dnf 命令为：
```
sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y
```
如果选中了**包括非安全性更新**复选框，则 `updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都会应用（安全更新和非安全性更新）。
对于 Amazon Linux 2，如果基准选中了**包括非安全性更新**，并且严重性列表为 `[Critical, Important]`，分类列表为 `[Security, Bugfix]`，则等效的 yum 命令为：
```
sudo yum update --security --sec-severity=Critical,Important --bugfix -y
```
对于 Amazon Linux 2023，等效的 dnf 命令为：
```
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
**Amazon Linux 2023 的更多修补详细信息**
支持严重性级别“无”
Amazon Linux 2023 还支持补丁严重性级别 `None`，DNF 软件包管理器可识别该严重性级别。
支持严重性级别“中”
对于 Amazon Linux 2023，补丁严重性级别 `Medium` 相当于可能在某些外部存储库中定义的 `Moderate` 严重性。如果您在补丁基准中包含 `Medium` 严重性补丁，则外部补丁中的 `Moderate` 严重性补丁也会安装在实例上。
使用 API 操作 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) 查询合规性数据时，筛选严重性级别 `Medium` 会报告严重性级别为 `Medium` 和 `Moderate` 的补丁。
Amazon Linux 2023 的传递依赖项处理
对于 Amazon Linux 2023，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的**最新可用版本。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ CentOS Stream ]
在 CentOS Stream 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 对已批准的补丁应用 CentOS Stream DNF 更新。
**注意**
对于 CentOS Stream，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal ‐‐security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Debian 服务器 ]
在 Debian Server 实例上，补丁安装工作流程如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
**注意**
由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
**注意**
对于 Debian Server，补丁候选版本仅限于 `debian-security` 中包含的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 使用 APT 库升级软件包。
**注意**
Patch Manager 不支持使用 APT `Pin-Priority` 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ macOS ]
在 macOS 托管式节点上，补丁安装工作流如下：
1. `/Library/Receipts/InstallHistory.plist` 属性列表是软件的记录，已使用 `softwareupdate` 和 `installer` 软件包管理器安装和更新了这些软件。使用 `pkgutil` 命令行工具（适用于 `installer`）和 `softwareupdate` 软件包管理器，运行 CLI 命令来解析此列表。
对于 `installer`，对 CLI 命令的响应包括 `package name`、`version`、`volume`、`location` 和 `install-time` 详细信息，但只有 `package name` 和 `version` 被 Patch Manager 使用。
适用于 `softwareupdate`，对 CLI 命令的响应包括软件包名称 (`display name`)、`version` 和 `date`，但 Patch Manager 只使用软件包名称和版本。
对于 Brew 和 Brew 桶，自制软件不支持在根用户下运行的命令。因此, Patch Manager 以 Homebrew 目录的所有者或属于 Homebrew 目录的所有者组的有效用户身份查询并运行 Homebrew 命令。这些命令类似于 `softwareupdate` 和 `installer` 并通过 Python 子进程运行以收集软件包数据，并对输出进行解析以识别软件包名称和版本。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 在托管式节点上调用相应的软件包 CLI 以处理批准的补丁，如下所示：
**注意**
`installer` 缺乏检查和安装更新的功能。因此，对于 `installer`、Patch Manager 仅报告安装了哪些软件包。因此, `installer` 软件包从未作为 `Missing` 来报告。
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用安全性更新。
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，安全性和非安全性更新都将应用。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Oracle Linux ]
在 Oracle Linux 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 在版本 7 托管式节点上，对已批准的补丁应用 YUM 更新 API，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。
此工作流的等效 yum 命令为：
```
sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y
```
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，`updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都将应用（安全性和非安全性更新）。
此工作流的等效 yum 命令为：
```
sudo yum update --security --bugfix -y
```
在版本 8 和 9 托管式节点上，对已批准的补丁应用 DNF 更新 API，如下所示：
+ 对于 AWS 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `updateinfo.xml` 中指定的补丁（仅安全性更新）。
此工作流的等效 yum 命令为：
```
sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important
```
**注意**
对于 Oracle Linux，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
+ 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，`updateinfo.xml` 中的补丁和未在 `updateinfo.xml` 中的补丁都将应用（安全性和非安全性更新）。
此工作流的等效 yum 命令为：
```
sudo dnf upgrade --security --bugfix
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. YUM 更新 API（在 RHEL 7 上）或 DNF 更新 API（在 AlmaLinux 8 和 9、RHEL 8、9 和 10 以及 Rocky Linux 8 和 9 上）根据以下规则应用于已批准的补丁：
**场景 1：排除非安全性更新**
+ **适用对象**：AWS 提供的预定义默认补丁基准和自定义补丁基准。
+ **包括非安全性更新**复选框：*未*选中。
+ **应用的补丁**：仅当 `updateinfo.xml` 中指定的补丁（仅安全性更新）与补丁基准配置相匹配且位于所配置的存储库中时，*才会*应用这些补丁。
在某些情况下，在所配置的存储库中，`updateinfo.xml` 中指定的补丁可能不再可用。配置的存储库通常只有最新版本的补丁，这是先前所有更新的累积汇总，但是最新版本可能与补丁基准规则不匹配，因此在修补操作中会省略。
+ **命令**：对于 RHEL 7，此工作流的等效 Yum 命令为：
```
sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y
```
对于 AlmaLinux、RHEL 8 和 Rocky Linux，此工作流的等效 DNF 命令为：
```
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \
sudo dnf update-minimal --sec-severity=Important --bugfix -y
```
**注意**
对于 AlmaLinux、RHEL 和 Rocky LinuxRocky Linux，Patch Manager 可能会安装与等效 `dnf` 命令安装不同的传递依赖项版本。传递依赖项是为了满足其他包的要求而自动安装的包（依赖项的依赖项）。
例如，`dnf upgrade-minimal --security` 安装解决已知安全问题所需的传递依赖项的*最低*版本，而 Patch Manager 安装相同传递依赖项的*最新可用版本*。
**场景 2：包括非安全性更新**
+ **适用对象**：自定义补丁基准。
+ **包括非安全性更新**复选框：选中。
+ **应用的补丁**：`updateinfo.xml` 中的补丁*和*未在 `updateinfo.xml` 中的补丁（安全性和非安全性更新）都会应用。
+ **命令**：对于 RHEL 7，此工作流的等效 Yum 命令为：
```
sudo yum update --security --bugfix -y
```
对于 AlmaLinux 8 和 9、RHEL 8 和 9 以及 Rocky Linux 8 和 9，此工作流的等效 DNF 命令为：
```
sudo dnf update --security --bugfix -y
```
**注意**
如果您在 Patch Manager 之外运行这些 `yum` 或 `dnf` 命令，则会使用不同的名称安装新软件包，来替换现已过时软件包。但是，这些软件包*无法*通过等效的 Patch Manager 操作安装。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
**注意**
Linux 发行版上软件包管理器的默认配置可以设置为跳过无法访问但没有错误的软件包存储库。在这种情况下，相关的修补操作将在不安装存储库更新的情况下继续进行，并成功结束。要强制执行存储库更新，请将 `skip_if_unavailable=False` 添加到存储库配置中。
有关 `skip_if_available` 选项的更多信息，请参阅 [与补丁源的连接](patch-manager-prerequisites.md#source-connectivity)。
------
#### [ SLES ]
在 SUSE Linux Enterprise Server (SLES) 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 如果批准了补丁的多个版本，则应用最新版本。
1. 对已批准的补丁应用 Zypper 更新 API。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Ubuntu Server ]
在 Ubuntu Server 托管式节点上，补丁安装工作流如下：
1. 如果使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文档的 `InstallOverrideList` 参数，使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL来指定补丁列表，则会安装列出的补丁，并跳过步骤 2-7。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。
如果包含非安全更新，也会考虑来自其他存储库的补丁。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
**注意**
对于 Ubuntu Server 的每个版本，补丁候选版本仅限于作为该版本关联存储库一部分的补丁，如下所示：
Ubuntu Server 16.04 LTS：`xenial-security`
Ubuntu Server 18.04 LTS：`bionic-security`
Ubuntu Server 20.04 LTS：`focal-security`
Ubuntu Server 22.04 LTS：`jammy-security`
Ubuntu Server 24.04 LTS (`noble-security`)
Ubuntu Server 25.04 (`plucky-security`)
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。
1. 依照补丁基准中的规定应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。
1. 使用 APT 库升级软件包。
**注意**
Patch Manager 不支持使用 APT `Pin-Priority` 选项为软件包分配优先级。Patch Manager 汇总所有已启用存储库的可用更新，并选择匹配每个已安装软件包基准的最新更新。
1. 如果安装了任何更新，则会重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。）
------
#### [ Windows Server ]
在 Windows Server 托管式节点上执行修补操作时，节点从 Systems Manager 请求相应补丁基准快照。此快照包含已批准部署的补丁基准中可用的所有更新的列表。系统会将更新列表发送到 Windows 更新 API，Windows 更新 API 确定哪些更新适用于托管式节点并根据需要安装更新。Windows 仅允许安装最新可用版本的 KB。当 KB 或 KB 的任何先前版本与应用的补丁基准匹配时，Patch Manager 会安装 KB 的最新版本。如果安装了任何更新，则系统会根据完成所有必要修补所需的次数重启托管式节点。（例外：如果将 `AWS-RunPatchBaseline` 文档中的 `RebootOption` 参数设置为 `NoReboot`，则在 Patch Manager 运行后不会重启托管式节点。有关更多信息，请参阅 [参数名称: `RebootOption`](patch-manager-aws-runpatchbaseline.md#patch-manager-aws-runpatchbaseline-parameters-norebootoption)。） 可在 Run Command 请求输出中找到修补操作摘要。其他日志可在托管式节点上的 `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` 文件夹中找到。
因为使用 Windows Update API 下载和安装 KB，所以操作遵循 Windows Update 的所有组策略设置。使用 Patch Manager 时不需要任何组策略设置，但会应用已定义的所有设置，以便（例如）将托管式节点定向到 Windows Server Update Services (WSUS) 服务器。
**注意**
默认情况下，Windows 从 Microsoft 的 Windows Update 站点下载所有 KB，这是因为 Patch Manager 使用 Windows Update API 驱动 KB 的下载和安装。因此，托管式节点必须能够访问 Microsoft Windows 更新站点，否则修补将失败。或者，您也可以将 WSUS 服务器配置为 KB 存储库，然后使用组策略将托管式节点配置为将该 WSUS 服务器设为目标。
Patch Manager可能会在为 Windows Server 创建自定义补丁基准时引用 KB ID，例如基准配置中包含**已批准的补丁**列表或**已拒绝的补丁**列表时。只有在 Microsoft Windows Update 或 WSUS 服务器中分配了 KB ID 的更新才由Patch Manager安装。修补操作中不会包含缺少 KB ID 的更新。
有关创建自定义补丁基准的信息，请参阅以下主题：
[创建适用于 Windows Server 的自定义补丁基准](patch-manager-create-a-patch-baseline-for-windows.md)
[创建补丁基准（CLI）](patch-manager-create-a-patch-baseline-for-windows.md)
[适用于 Windows 操作系统的软件包名称格式](patch-manager-approved-rejected-package-name-formats.md#patch-manager-approved-rejected-package-name-formats-windows)
------
# 补丁基准规则在基于 Linux 的系统上的工作原理
对于 Linux 分发版，补丁基准中规则的工作方式因分发版类型的不同而有所差异。与 Windows Server 托管式节点上的补丁更新不同，将在每个节点上评估规则，以便考虑实例上配置的存储库。Patch Manager（AWS Systems Manager 中的一项工具）使用本机软件包管理器推动安装补丁基准批准的补丁。
对于报告修补程序严重性级别的基于 Linux 的操作系统类型，Patch Manager 将软件发布者报告的严重性级别用于更新通知或单个修补程序。Patch Manager 不会从第三方来源（例如[常见漏洞评分系统](https://www.first.org/cvss/) (CVSS)），或者[国家漏洞数据库](https://nvd.nist.gov/vuln) (NVD) 发布的指标中获取严重性级别。
**Topics**
+ [补丁基准规则在 Amazon Linux 2 和 Amazon Linux 2023 上的工作原理](#linux-rules-amazon-linux)
+ [补丁基准规则在 CentOS Stream 上的工作原理](#linux-rules-centos)
+ [补丁基准规则在 Debian Server 上的工作原理](#linux-rules-debian)
+ [补丁基准规则在 macOS 上的工作原理](#linux-rules-macos)
+ [补丁基准规则在 Oracle Linux 上的工作原理](#linux-rules-oracle)
+ [补丁基准规则在 AlmaLinux、RHEL 和 Rocky Linux 上的工作原理](#linux-rules-rhel)
+ [补丁基准规则在 SUSE Linux Enterprise Server 上的工作原理](#linux-rules-sles)
+ [补丁基准规则在 Ubuntu Server 上的工作原理](#linux-rules-ubuntu)
## 补丁基准规则在 Amazon Linux 2 和 Amazon Linux 2023 上的工作原理
**注意**
Amazon Linux 2023（AL2023）使用版本控制的存储库，这些存储库可以通过一个或多个系统设置锁定到特定版本。对于 AL2023 EC2 实例的所有修补操作，Patch Manager 使用最新的存储库版本，与系统配置无关。有关更多信息，请参阅《Amazon Linux 2023 User Guide》**中的 [Deterministic upgrades through versioned repositories](https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html)。
在 Amazon Linux 2 和 Amazon Linux 2023 上，补丁选择过程如下：
1. 在托管节点上，YUM 库（Amazon Linux 2）或 DNF 库（Amazon Linux 2023）将访问每个已配置存储库的 `updateinfo.xml` 文件。
如果未找到 `updateinfo.xml` 文件，是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 CentOS Stream 上的工作原理
CentOS Stream 默认存储库不包含 `updateinfo.xml` 文件。不过，您创建或使用的自定义存储库可能包含该文件。在本主题中，对 `updateinfo.xml` 的引用仅适用于这些自定义存储库。
在 CentOS Stream 上，补丁选择过程如下：
1. 在托管式节点上，DNF 库可访问每个已配置存储库的 `updateinfo.xml` 文件（如果该文件存在于自定义存储库中）。
如果未找到 `updateinfo.xml`（其中始终包含默认存储库），是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. 如果存在 `updateinfo.xml`，该文件中的每个更新通知都包含几个属性，这些属性表示通知中软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 在所有情况下，托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 Debian Server 上的工作原理
在 Debian Server上，补丁基准服务提供对*优先级*和*部分*字段的筛选。这些字段通常存在于所有 Debian Server 软件包中。为确定补丁基准是否选择了某个补丁，Patch Manager 执行以下操作：
1. 在 Debian Server 系统上，运行等效于 `sudo apt-get update` 的程序刷新可用软件包列表。不配置存储库，从 `sources` 列表中配置的存储库提取数据。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 接下来将应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 列表。
**注意**
由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。在这种情况下，对于 Debian Server，补丁候选版本仅限于以下存储库中包含的补丁：
这些存储库的命名如下：
+ Debian Server 11：`debian-security bullseye`
+ Debian Server 12：`debian-security bookworm`
如果包含非安全更新，也会考虑来自其他存储库的补丁。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
要查看 *Priority* 和 *Section* 字段的内容，运行以下 `aptitude` 命令：
**注意**
您需要先在 Debian Server 系统上安装 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在对此命令的响应中，按以下格式报告所有可升级软件包：
```
name, priority, section, archive, candidate version
```
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 macOS 上的工作原理
在 macOS 上，补丁选择过程如下：
1. 在托管式节点上，Patch Manager 访问 `InstallHistory.plist` 文件的已解析内容并标识软件包名称和版本。
有关解析过程的详细信息，请参阅 [如何安装补丁](patch-manager-installing-patches.md) 中的 **macOS** 选项卡。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 Oracle Linux 上的工作原理
在 Oracle Linux 上，补丁选择过程如下：
1. 在托管式节点上，YUM 库可访问每个已配置存储库的 `updateinfo.xml` 文件。
**注意**
如果存储库不是由 Oracle 管理的，则可能不存在 `updateinfo.xml` 文件。如果未找到 `updateinfo.xml`，是否安装补丁将取决于**包括非安全性更新**和**自动批准**设置。例如，如果允许非安全更新，则会在自动批准时间到达时安装这些更新。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 AlmaLinux、RHEL 和 Rocky Linux 上的工作原理
在 AlmaLinux、Red Hat Enterprise Linux（RHEL）和 Rocky Linux 上，补丁选择过程如下：
1. 在托管式节点上，YUM 库 (RHEL 7) 或 DNF 库（AlmaLinux 8 和 9、RHEL 8、9 和 10 以及 Rocky Linux 8 和 9）访问每个已配置存储库的 `updateinfo.xml` 文件。
**注意**
如果存储库不是由 Red Hat 管理的，可能不存在 `updateinfo.xml` 文件。如果找不到 `updateinfo.xml`，则不会应用任何补丁。
1. `updateinfo.xml` 中的每个更新通知都包含几个属性，它们表示通知中的软件包的属性，如下表所述。
**更新通知属性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
1. 托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 Product 键属性的值。
1. 根据以下准则为更新选择程序包。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/systems-manager/latest/userguide/patch-manager-linux-rules.html)
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
## 补丁基准规则在 SUSE Linux Enterprise Server 上的工作原理
在 SLES 上，每个补丁包括以下表示补丁中的软件包的属性的属性：
+ **类别**：对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中的 **Classification** 键属性的值。表示更新通知中包含的补丁的类型。
可以使用 AWS CLI 命令 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 或 API 操作 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** 来查看受支持值的列表。您也可以在 Systems Manager 控制台中**创建补丁基准**页面或**编辑补丁基准**页面中的**审批规则**区中查看列表。
+ **严重性**：对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中的**严重性**键属性的值。表示补丁的严重性。
可以使用 AWS CLI 命令 **[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)** 或 API 操作 **[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)** 来查看受支持值的列表。您也可以在 Systems Manager 控制台中**创建补丁基准**页面或**编辑补丁基准**页面中的**审批规则**区中查看列表。
托管式节点的产品由 SSM Agent 确定。此属性对应于补丁基准的 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html) 数据类型中 **Product** 键属性的值。
对于每个补丁，补丁基准用作筛选器，只允许更新包含符合条件的软件包。如果应用补丁基准定义后有多个软件包适用，则使用最新版本。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
## 补丁基准规则在 Ubuntu Server 上的工作原理
在 Ubuntu Server上，补丁基准服务提供对*优先级*和*部分*字段的筛选。这些字段通常存在于所有 Ubuntu Server 软件包中。为确定补丁基准是否选择了某个补丁，Patch Manager 执行以下操作：
1. 在 Ubuntu Server 系统上，运行等效于 `sudo apt-get update` 的程序刷新可用软件包列表。不配置存储库，从 `sources` 列表中配置的存储库提取数据。
1. 如果某个更新可用于 `python3-apt` （一个 `libapt` 的 Python 库接口），则将升级到最新版本。（即使您没有选择**包括非安全更新**选项，该非安全软件包也会更新。）
1. 接下来将应用 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)、[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches) 和 [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches) 列表。
**注意**
由于无法可靠地确定 Ubuntu Server 的更新程序包的发布日期，因此此操作系统不支持自动批准选项。
但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。
如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。在这种情况下，对于 Ubuntu Server，补丁候选版本仅限于以下存储库中包含的补丁：
+ Ubuntu Server 16.04 LTS：`xenial-security`
+ Ubuntu Server 18.04 LTS：`bionic-security`
+ Ubuntu Server 20.04 LTS：`focal-security`
+ Ubuntu Server 22.04 LTS：`jammy-security`
+ Ubuntu Server 24.04 LTS (`noble-security`)
+ Ubuntu Server 25.04 (`plucky-security`)
如果包含非安全更新，也会考虑来自其他存储库的补丁。
有关已批准的补丁和已拒绝的补丁列表的已接受格式的信息，请参阅 [已批准补丁和已拒绝补丁列表的程序包名称格式](patch-manager-approved-rejected-package-name-formats.md)。
要查看 *Priority* 和 *Section* 字段的内容，运行以下 `aptitude` 命令：
**注意**
您需要先在 Ubuntu Server 16 系统上安装 Aptitude。
```
aptitude search -F '%p %P %s %t %V#' '~U'
```
在对此命令的响应中，按以下格式报告所有可升级软件包：
```
name, priority, section, archive, candidate version
```
有关补丁合规性状态值的信息，请参阅 [补丁合规性状态值](patch-manager-compliance-states.md)。
# Linux 和 Windows Server 之间的补丁操作差异
本主题介绍Patch Manager（AWS Systems Manager 中的一项工具）中 Linux 和 Windows Server 修补之间的重要差异。
**注意**
要修补 Linux 托管式节点，节点必须运行 SSM Agent 2.0.834.0 版或更高版本。
如果有新工具添加至 Systems Manager 或者对现有工具进行了更新，则将发布 SSM Agent 的更新版本。无法使用代理的最新版本可能会阻止托管式节点使用 Systems Manager 的各项工具和功能。因此，我们建议您自动完成确保机器上的 SSM Agent 为最新的过程。有关更多信息，请参阅 [自动更新到 SSM Agent](ssm-agent-automatic-updates.md)。要获得有关 SSM Agent 更新的通知，请在 GitHub 上订阅 [SSM Agent 发布说明](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)页面。
## 区别 1：补丁评估
Patch Manager 在 Windows 托管式节点和 Linux 托管式节点上使用不同的进程，以评估应该存在的补丁。
**Linux**
对于 Linux 修补，Systems Manager 会评估补丁基准规则以及 *每个*托管式节点上已批准和已被拒绝的补丁列表。Systems Manager 必须在每个节点上评估修补，因为该服务从托管式节点上配置的存储库中检索已知补丁和更新列表。
**Windows**
对于 Windows 修补，Systems Manager *直接在服务中*评估补丁基准规则以及已批准和已拒绝的补丁列表。它可以执行此操作是因为 Windows 补丁从单个存储库 (Windows 更新) 拉取。
## 区别 2：`Not Applicable` 补丁
因为 Linux 操作系统有大量可用的软件包，所以 Systems Manager 不报告处于*不适用*状态的补丁的详细信息。例如，A `Not Applicable` 补丁是在实例未安装 Apache 时的 Apache 软件的补丁。Systems Manager 确实会在摘要中报告 `Not Applicable` 补丁的数量，但如果为某个托管式节点调用 [DescribeInstancePatches](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribeInstancePatches.html) API，则返回的数据中不包含状态为 `Not Applicable` 的补丁。这一行为不同于 Windows。
## 区别 3：SSM 文档支持
`AWS-ApplyPatchBaseline` Systems Manager 文档（SSM 文档）不支持 Linux 托管式节点。如需对 Linux、macOS 和 Windows Server 托管式节点应用补丁基准，则推荐的 SSM 文档是 `AWS-RunPatchBaseline`。有关更多信息，请参阅[适用于修补托管式节点的 SSM 命令文档](patch-manager-ssm-documents.md)和[用于修补的 SSM 命令文档：`AWS-RunPatchBaseline`](patch-manager-aws-runpatchbaseline.md)。
## 区别 4：应用程序补丁
Patch Manager 的主要目的是将补丁应用到操作系统。不过，您也可以使用 Patch Manager 将补丁应用到托管式节点上的某些应用程序。
**Linux**
在 Linux 操作系统上，Patch Manager 使用配置的存储库进行更新，不会区分操作系统补丁和应用程序补丁。您可以使用 Patch Manager 来定义从哪些存储库获取更新。有关更多信息，请参阅 [如何指定备用补丁源存储库 (Linux)](patch-manager-alternative-source-repository.md)。
**Windows**
在 Windows Server 托管式节点上，您可以为 Microsoft 发布的应用程序（如 Microsoft Word 2016 和 Microsoft Exchange Server 2016）应用已批准规则，以及*已批准*和*已被拒绝*补丁例外。有关更多信息，请参阅 [使用自定义补丁基准](patch-manager-manage-patch-baselines.md)。
## 区别 5：自定义补丁基准中已拒绝的补丁列表选项
创建自定义补丁基准时，您可以为此**已拒绝的补丁**列表指定一个或多个补丁。对于 Linux 托管节点，如果它们是基准允许的其他补丁的依赖项，则也可以选择允许安装它们。
但是，Windows Server 不支持补丁依赖项的概念。您可以将补丁添加到 Windows Server 的自定义基准的**已拒绝的补丁**列表中，但结果取决于（1）被拒绝的补丁是否已安装在托管节点上，以及（2）您为**被拒绝的补丁操作**选择了哪个选项。
有关 Windows Server 上已拒绝的补丁选项的详细信息，请参阅下表。
| 安装状态 | 选项：“作为依赖项允许” | 选项：“语句块” |
| --- | --- | --- |
| 补丁已安装 | 报告状态：INSTALLED\$1OTHER | 报告状态：INSTALLED\$1REJECTED |
| 尚未安装补丁 | 补丁已跳过 | 补丁已跳过 |
Microsoft 发布的每个 Windows Server 补丁通常都包含成功安装所需的所有信息。但是，有时可能需要必备程序包，您必须手动安装该程序包。 Patch Manager 不报告有关这些先决条件的信息。有关相关信息，请参阅 Microsoft 网站上的 [Windows 更新问题排查](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)。