如何安装补丁 - Amazon Web Services Systems Manager
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

如何安装补丁

补丁程序管理器,一种Amazon Web Services Systems Manager,使用操作系统类型的相应内置机制在实例上安装更新。例如,在Windows Server,则使用 Windows Update API;在 Amazon Linux 上,yum软件包管理器。

请从以下选项卡中进行选择,了解 Patch Manager 如何在操作系统上安装补丁。

Amazon Linux and Amazon Linux 2

在 Amazon Linux 和 Amazon Linux 2 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  7. 对已批准的补丁应用 YUM 更新 API,如下所示:

    • 对于 Amazon 提供的预定义的默认补丁基准,以及 Approved patches include non-security updates (已批准的补丁包括非安全性更新) 复选框选中的自定义补丁基准,则仅应用 updateinfo.xml 中指定的补丁(仅安全性更新)。

      此工作流程的等效 yum 命令为:

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y
    • 对于自定义补丁基准,其中批准的补丁包括非安全性更新” 复选框,这两个修补程序都在updateinfo.xml和那些不在updateinfo.xml(安全和非安全更新)。

      此工作流程的等效 yum 命令为:

      sudo yum update --security --bugfix
  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

CentOS

在 CentOS 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

    ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  2. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

  3. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  4. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  6. YUM 更新 API(在 CentOS 6.x 和 7.x 版本上)或 DNF 更新(在 CentOS 8 上)应用于批准的补丁。

  7. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

Debian Server

在 Debian Server 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. 仅在 Debian 服务器 8 上:因为一些 Debian 服务器 8.* 实例引用了一个过时的软件包资料库(jessie-backports),Patch Manager 会执行以下其他步骤来确保修补操作成功:

    1. 在您的实例上,对 jessie-backports 存储库的引用将从源位置列表 (/etc/apt/sources.list.d/jessie-backports) 中注释掉。因此,不会尝试从该位置下载补丁。

    2. 将导入 Stretch 安全更新签名密钥。此密钥为 Debian Server 8.* 发行版上的更新和安装操作提供必要的权限。

    3. 将运行 apt-get 操作,以确保在修补过程开始之前已安装最新版本的 python3-apt

    4. 安装过程完成后,将恢复对 jessie-backports 存储库的引用,并从 apt 源密钥环中删除签名密钥。这样做是为了使系统配置保持修补操作之前的状态。

    下次 Patch Manager 更新系统时,将重复执行同一过程。

    补丁安装工作流程中的其余步骤适用于 Debian Server 8 9 和 10。

  3. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  4. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    注意

    由于无法可靠地确定 Debian Server 更新程序包的发布日期,因此该操作系统不支持自动审批选项。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

    注意

    对于 Debian 服务器,修补程序候选版本仅限于debian-security

  5. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  6. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

  7. 使用 APT 库升级软件包。

  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

macOS

在 macOS 实例上,补丁安装工作流程如下:

  1. 这些区域有:/Library/Receipts/InstallHistory.plist属性列表是已安装和升级的软件的记录,该记录使用softwareupdateinstaller程序包管理器。使用pkgutil命令行工具(用于installer)和softwareupdate软件包管理器,则运行 CLI 命令来解析此列表。

    适用于installer,则对 CLI 命令的响应包括package nameversionvolumelocation, 和install-time详细信息,但只有package nameversion由修补程序管理器使用。

    适用于softwareupdate,则对 CLI 命令的响应包括软件包名称 (display name),version, 和date,但修补程序管理器只使用软件包名称和版本。

    对于 Brew 和 Brew 桶,自制软件不支持在 root 用户下运行的命令。因此,修补程序管理器以自制文件夹的所有者或属于自制文件夹的所有者组的有效用户身份查询并运行自制命令。这些命令类似于softwareupdateinstaller并通过 Python 子进程运行以收集包数据,并对输出进行解析以识别包名称和版本。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  7. 在实例上调用相应的包 CLI 以处理批准的修补程序,如下所示:

    注意

    installer缺乏检查和安装更新的功能。因此,对于installer,则修补程序管理器仅报告安装了哪些软件包。因此,installer软件包从来没有报告为Missing

    • 对于由Amazon,对于自定义修补程序基准,其中批准的补丁包括非安全性更新” 复选框为,则仅应用安全更新。

    • 对于自定义补丁基准,其中批准的补丁包括非安全性更新” 复选框,则同时应用安全更新和非安全更新。

  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

Oracle Linux

在 Oracle Linux 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  7. 在版本 7 实例上,YUM 更新 API 应用于已批准的补丁,如下所示:

    • 对于 Amazon 提供的预定义的默认补丁基准,以及 Approved patches include non-security updates (已批准的补丁包括非安全性更新) 复选框选中的自定义补丁基准,则仅应用 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 实例上,Dnf 更新 API 应用于已批准的补丁,如下所示:

      • 对于 Amazon 提供的预定义的默认补丁基准,以及 Approved patches include non-security updates (已批准的补丁包括非安全性更新) 复选框选中的自定义补丁基准,则仅应用 updateinfo.xml 中指定的补丁(仅安全性更新)。

        此工作流程的等效 yum 命令为:

        sudo dnf upgrade-minimal --security --sec-severity Moderate --sec-severity Important
      • 对于自定义补丁基准,其中批准的补丁包括非安全性更新” 复选框,这两个修补程序都在updateinfo.xml和那些不在updateinfo.xml(安全和非安全更新)。

        此工作流程的等效 yum 命令为:

        sudo dnf upgrade --security --bugfix
  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

RHEL

在 Red Hat Enterprise Linux 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  7. YUM 更新 API(在 RHEL 7 上)或 DNF 更新 API(在 RHEL 8 上)应用于批准的补丁,如下所示:

    • 对于 Amazon 提供的预定义的默认补丁基准,以及 Approved patches include non-security updates (已批准的补丁包括非安全性更新) 复选框选中的自定义补丁基准,则仅应用 updateinfo.xml 中指定的补丁(仅安全性更新)。

      对于 RHEL 7,此工作流程的等效 yum 命令为:

      sudo yum update-minimal --sec-severity=critical,important --bugfix -y

      对于 RHEL 8,此工作流程的等效 dnf 命令为:

      sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y
    • 对于自定义补丁基准,其中批准的补丁包括非安全性更新” 复选框,这两个修补程序都在updateinfo.xml和那些不在updateinfo.xml(安全和非安全更新)。

      对于 RHEL 7,此工作流程的等效 yum 命令为:

      sudo yum update --security --bugfix -y

      对于 RHEL 8,此工作流程的等效 yum 命令为:

      sudo dnf update --security --bugfix -y
  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

SLES

在 SUSE Linux Enterprise Server (SLES) 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

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

  7. 对已批准的补丁应用 Zypper 更新 API。

  8. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

Ubuntu Server

在 Ubuntu Server 实例上,补丁安装工作流程如下:

  1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路径样式 URL 指定补丁列表,使用InstallOverrideList参数AWS-RunPatchBaseline或者AWS-RunPatchBaselineAssociation文档,则会安装列出的修补程序,并跳过步骤 2-7。

  2. ApplyGlobalFilters,只保留符合资格的软件包做进一步处理。

  3. ApplyApprovalRules依照补丁基准中的规定。每条批准规则可以将一个软件包定义为已批准。

    注意

    由于无法可靠地确定 Ubuntu Server 更新程序包的发布日期,因此该操作系统不支持自动审批选项。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

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

    如果包含非安全更新,也会考虑来自其他资料库的修补程序。

    但是,批准规则也取决于包括非安全更新复选框是在创建或上次更新修补程序基线时选中的。

    注意

    对于 Ubuntu 服务器,修补程序候选版本仅限于trusty-securityUbuntu 服务器 14.04 LTS),xenial-securityUbuntu Server 16.04 LTS),bionic-security(Ubuntu Server 18.04 LTS),focal-securityUbuntu Server 20.04 LTS)或groovy-gorilla(乌布图服务器 20.10 STR)。

  4. ApplyApprovedPatches依照补丁基准中的规定。已批准的补丁即使被丢弃,也会批准更新;GlobalFilters或者如果未指定批准规则ApprovalRules授予它批准。

  5. ApplyRejectedPatches依照补丁基准中的规定。从已批准的补丁列表中删除已拒绝的补丁,并且不会应用已拒绝的补丁。

  6. 使用 APT 库升级软件包。

  7. 如果安装了任意更新,则重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。)

Windows

当执行修补操作时Windows Server实例时,实例从 Systems Manager 请求相应补丁基准的快照。此快照包含已批准部署的补丁基准中可用的所有更新的列表。将更新列表发送到 Windows Update API,Windows Update API 确定哪些更新适用于实例并根据需要进行安装。如果安装了任意更新,则根据完成所有必要修补所需的次数重启实例。(例外:如果RebootOption参数设置为NoReboot中的AWS-RunPatchBaseline文档中,Patch Manager 运行后不会重启实例。 有关更多信息,请参阅 。参数名称: RebootOption。) 可在 Run Command 请求的输出中找到修补操作摘要。其他日志可在实例上的 %PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs 文件夹中找到。

因为使用 Windows Update API 下载和安装补丁,所以操作遵循 Windows Update 的所有组策略设置。使用 Patch Manager 时不必进行任何组策略设置,但已定义的任何设置都有效,例如,将实例定向到 Windows Server Update Services (WSUS) 服务器。

注意

默认情况下,Windows 从 Microsoft 的 Windows Update 站点下载所有补丁,这是因为 Patch Manager 使用 Windows Update API 驱动补丁的下载和安装。因此,实例必须能够访问 Microsoft Windows Update 站点,否则修补将失败。或者,您也可以将 WSUS 服务器配置为补丁存储库,然后使用组策略将实例配置为将此 WSUS 服务器指定为目标。