如何安裝修補程式

Patch Manager是 中的工具 AWS Systems Manager，針對作業系統類型使用適當的內建機制，在受管節點上安裝更新。例如，在 Windows Server 上使用 Windows Update API，在 Amazon Linux 2 上使用 yum 套件管理員。

Patch Manager 不會安裝取代目前安裝之過時套件的新套件。(例外：新套件是正在安裝的另一個套件更新的相依性，或者新套件具有與過時套件相同的名稱。) 反之，Patch Manager 會報告並安裝已安裝套件的可用更新。此方法有助於防止系統功能意外變更，這些變更可能會在一個套件取代另一個套件時發生。

如果您需要解除安裝已過時的套件並安裝其替換套件，您可能需要使用自訂指令碼，或在 Patch Manager 的標準操作之外使用套件管理工具命令。

請從以下標籤選擇，了解 Patch Manager 如何在作業系統上安裝修補程式。

Amazon Linux 2 and Amazon Linux 2023

在 Amazon Linux 2 和 Amazon Linux 2023 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

6. 如果核准修補程式的多個版本，將會套用最新版本。

7. 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 動作 DescribeInstancePatches 查詢合規資料時，嚴重性等級 Medium 篩選會報告嚴重性等級為 Medium 和 Moderate 的修補程式。

     Amazon Linux 2023 的可轉移相依性處理

     對於 Amazon Linux 2023，Patch Manager 可能會安裝與等效 dnf 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。

     例如，dnf upgrade-minimal --security 會安裝為解決已知安全問題所需的最低可轉移相依性版本，而 Patch Manager 會安裝相同可轉移相依性的最新可用版本。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

CentOS Stream

在 CentOS Stream 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

   套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

2. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

3. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

4. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

5. 如果核准修補程式的多個版本，將會套用最新版本。

6. 對 CentOS Stream 的 DNF 更新將套用至核准的修補程式。

   注意

   對於 CentOS Stream，Patch Manager 可能會安裝與等效 dnf 命令所安裝的可轉移相依性不同的版本。可轉移相依性是會自動安裝的套件，以滿足其他套件的需求 (相依性的相依性)。

   例如，dnf upgrade-minimal ‐‐security 會安裝為解決已知安全問題所需的最低可轉移相依性版本，而 Patch Manager 會安裝相同可轉移相依性的最新可用版本。

7. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

Debian Server

在 Debian Server 執行個體上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

3. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

4. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   注意

   因為無法可靠地判斷 Debian Server 更新套件的發行日期，此作業系統不支援自動核准選項。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

   注意

   對於 Debian Server，修補程式候選版本僅限於 debian-security 中包含的修補程式。

5. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

6. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

7. APT 程式庫用於升級套件。

   注意

   Patch Manager 不支援使用 APT Pin-Priority 選項，將優先順序指派給套件。Patch Manager 會從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

macOS

在 macOS 受管節點上，修補程式安裝工作流程如下：

1. /Library/Receipts/InstallHistory.plist 屬性清單是使用 softwareupdate 和 installer 套件管理工具的已安裝和已升級軟體記錄。使用 pkgutil 命令列工具 (用於 installer) 以及 softwareupdate 套件管理工具時，會執行 CLI 命令來剖析此清單。

   對於 installer，對 CLI 命令的回應包括 package name、version、volume、location 和 install-time 詳細資訊，但 Patch Manager 僅使用 package name 和 version。

   對於 softwareupdate，對 CLI 命令的回應會包含套件名稱 (display name)、version 和 date，但 Patch Manager 只會使用套件名稱和版本。

   對於 Brew 和 Brew Cask，Homebrew 不支援其在根使用者下執行的命令。因此，Patch Manager 以 Homebrew 目錄的擁有者或屬於 Homebrew 目錄之擁有者群組的有效使用者身分查詢和執行 Homebrew 命令。這些命令類似於 softwareupdate 和 installer 並透過 Python 子程序執行命令，以收集套件資料，並解析輸出以識別套件名稱和版本。

2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

6. 如果核准修補程式的多個版本，將會套用最新版本。

7. 在受管節點上叫用適當的套件 CLI，以處理核准的修補程式，如下所示：

   注意

   installer 缺乏檢查和安裝更新的功能。因此，對於 installer，Patch Manager 只會報告已安裝的套件。因此，installer 套件永遠不會報告為 Missing。

   • 針對 AWS提供的預先定義預設修補基準，以及未選取包含非安全性更新核取方塊的自訂修補基準，則只會套用安全性更新。

   • 針對已選取包含非安全性更新核取方塊的自訂修補基準，會套用安全性和非安全性更新。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

Oracle Linux

在 Oracle Linux 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

6. 如果核准修補程式的多個版本，將會套用最新版本。

7. 在版本 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 操作安裝。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

AlmaLinux, RHEL, and Rocky Linux

在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

6. 如果核准修補程式的多個版本，將會套用最新版本。

7. 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 操作安裝。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

SLES

在 SUSE Linux Enterprise Server (SLES) 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

3. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

4. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

5. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

6. 如果核准修補程式的多個版本，將會套用最新版本。

7. Zypper 更新 API 將套用至核准的修補程式。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

Ubuntu Server

在 Ubuntu Server 受管節點上，修補程式安裝工作流程如下：

1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineAssociation 文件的 InstallOverrideList 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。

2. 若有可用於 python3-apt (libapt 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 Include nonsecurity updates (包含非安全性更新) 選項)。

3. 套用修補程式基準中指定的 GlobalFilters，以便僅進一步處理合格的套件。

4. 套用修補程式基準中指定的 ApprovalRules。每個核准規則皆可將套件定義為已核准。

   注意

   因為無法可靠地判斷 Ubuntu Server 更新套件的發行日期，此作業系統不支援自動核准選項。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。

   如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。

   然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 Include nonsecurity updates (包含非安全性更新) 核取方塊。

   注意

   對於每個 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)

5. 套用修補程式基準中指定的 ApprovedPatches。已核准的修補程式即使被 GlobalFilters 捨棄或 ApprovalRules 中沒有指定核准規則授予其核准，仍將會核准用於更新。

6. 套用修補程式基準中指定的 RejectedPatches。已遭拒的修補程式會從核准的修補程式清單中移除，而且將不會套用。

7. APT 程式庫用於升級套件。

   注意

   Patch Manager 不支援使用 APT Pin-Priority 選項，將優先順序指派給套件。Patch Manager 會從所有已啟用的儲存庫彙總可用的更新，並選取符合每個已安裝套件基準的最新更新。

8. 如有安裝任何更新，受管節點將會重新啟動。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

Windows Server

在 Windows Server 受管節點上執行修補操作時，節點會從 Systems Manager 請求適當修補基準的快照。此快照包含已核准部署之修補基準中所有可用更新的清單。此更新清單會傳送至 Windows Update API，決定哪些更新適用於受管節點並視需要安裝這些更新。Windows 只允許安裝最新版本的 KB。如果最新版本的 KB 或任何舊版 KB 符合套用的修補基準，Patch Manager 會安裝最新版本的 KB。如有安裝任何更新，受管節點將會重新啟動，重新啟動的次數依據完成所有必要修補的需要而定。(例外：如果 AWS-RunPatchBaseline 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。) 在 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 Update 網站，否則修補將會失敗。或者，您可以設定 WSUS 伺服器作為 KB 儲存庫，並設定您的受管節點以 WSUS 伺服器為目標使用群組政策。

在建立 Windows Server 的自訂修補基準時，Patch Manager 可能會參考 KB ID，例如當基準組態中包含已核准修補程式清單或已拒絕修補程式清單時。只有在 Microsoft Windows Update 或 WSUS 伺服器中獲得 KB ID 指派的更新，才會由 Patch Manager 安裝。缺少 KB ID 的更新不會包含在修補操作中。

如需有關建立自訂修補基準的資訊，請參閱下列主題：

• 建立 Windows Server 的自訂修補基準

• 建立修補基準 (CLI)

• 適用於 Windows 作業系統的套件名稱格式