• Amazon Systems Manager CloudWatch 控制面板在 2026 年 4 月 30 日之后将不再可用。客户可以像现在一样继续使用 Amazon CloudWatch 控制台来查看、创建和管理其 Amazon CloudWatch 控制面板。有关更多信息，请参阅 [Amazon CloudWatch 控制面板文档](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)。

# 如何安装补丁
<a name="patch-manager-installing-patches"></a>

Patch Manager 是 Amazon 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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

1. 如果批准了补丁的多个版本，则应用最新版本。

1. YUM 更新 API（Amazon Linux 2）或 DNF 更新 API（Amazon Linux 2023）用于已批准的补丁，如下所示：
   + 对于 Amazon 提供的预定义默认补丁基准，仅应用 `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.amazonaws.cn/systems-manager/latest/APIReference/API_DescribeInstancePatches.html](https://docs.amazonaws.cn/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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。
**注意**  
由于无法可靠地确定 Debian Server 更新程序包的发布日期，因此该操作系统不支持自动审批选项。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。
**注意**  
对于 Debian Server，补丁候选版本仅限于 `debian-security` 中包含的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

1. 如果批准了补丁的多个版本，则应用最新版本。

1. 在托管式节点上调用相应的软件包 CLI 以处理批准的补丁，如下所示：
**注意**  
`installer` 缺乏检查和安装更新的功能。因此，对于 `installer`、Patch Manager 仅报告安装了哪些软件包。因此, `installer` 软件包从未作为 `Missing` 来报告。
   + 对于 Amazon 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用安全性更新。
   + 对于*已*选中**包括非安全性更新**复选框的自定义补丁基准，安全性和非安全性更新都将应用。

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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches)。从已批准的补丁列表中删除已拒绝的补丁，并且不会应用已拒绝的补丁。

1. 如果批准了补丁的多个版本，则应用最新版本。

1. 在版本 7 托管式节点上，对已批准的补丁应用 YUM 更新 API，如下所示：
   + 对于 Amazon 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `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，如下所示：
     + 对于 Amazon 提供的预定义默认补丁基准，以及*未*选中**包括非安全性更新**复选框的自定义补丁基准，则将仅应用 `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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/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：排除非安全性更新**
   + **适用对象**：Amazon 提供的预定义默认补丁基准和自定义补丁基准。
   + **包括非安全性更新**复选框：*未*选中。
   + **应用的补丁**：仅当 `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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules)。每条批准规则可以将一个软件包定义为已批准。

   但是，批准规则也取决于在创建或上次更新补丁基准时是否选中**包括非安全更新**复选框。

   如果不包含非安全更新，则应用一条隐式规则，以便只选择在安全存储库中有升级的软件包。对于每个软件包，软件包的候选版本（通常为最新版本）必须包含在安全存储库中。

   如果包含非安全更新，也会考虑来自其他存储库的补丁。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters)，只保留符合资格的软件包做进一步处理。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/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.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovedPatches)。已批准的补丁即使被 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-GlobalFilters) 丢弃，也会批准更新；如果 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules](https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-ApprovalRules) 中未指定任何批准规则，则给予批准。

1. 依照补丁基准中的规定应用 [https://docs.amazonaws.cn/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#EC2-CreatePatchBaseline-request-RejectedPatches](https://docs.amazonaws.cn/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)

------