• 2026 年 4 月 30 日之後將不再提供 AWS Systems Manager CloudWatch Dashboard。客戶可以繼續使用 Amazon CloudWatch 主控台來檢視、建立和管理其 Amazon CloudWatch 儀表板，就像現在一樣。如需詳細資訊，請參閱 [Amazon CloudWatch Dashboard 文件](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` 參數時， 會使用國際標準時間 (UTC) Patch Manager評估修補程式發行日期。
例如，對於 `ApproveUntilDate`，如果您指定日期，例如 `2025-11-16`，`2025-11-16T23:59:59Z`則會核准 `2025-11-16T00:00:00Z`和 之間發行的修補程式。
請注意，受管節點上原生套件管理員顯示的修補程式發行日期可能會根據您系統的本機時區顯示不同的時間，但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 修補基準服務會使用受管節點上預先設定的儲存庫。節點上通常會有兩個預先設定的儲存庫 (repos)：
**在 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 或 aarch64 (適用於 Graviton 處理器)。
如果您建立 Amazon Linux 2023 (AL2023) 執行個體，它包含 AL2023 版本中可用的更新，以及您選取的特定 AMI。AL2023 執行個體不會在啟動時自動接收其他關鍵和重要的安全性更新。而藉由 AL2023 支援的*透過版本化儲存庫進行確定性升級*功能 (預設為開啟)，您可以根據滿足特定需求的排程套用更新。如需詳細資訊，請參閱《Amazon Linux 2023 使用者指南》**中的[透過版本化儲存庫使用決定性升級](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 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。下列清單提供虛構 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`
**注意**
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
CentOS Stream 節點使用 DNF 作為套件管理工具。套件管理工具使用更新通知的概念。更新通知僅只是修復特定問題的套件集合。
不過，CentOS Stream 預設儲存庫並未設定更新通知。這表示 Patch Manager 不會偵測預設 CentOS Stream 儲存庫上的套件。若要啟用 Patch Manager 來處理不包含在更新通知中的套件，您必須在修補基準規則中啟用 `EnableNonSecurity` 旗標。
**注意**
支援 CentOS Stream 更新通知。啟動後，可下載含有更新通知的儲存區。
------
#### [ Debian Server ]
在 Debian Server 上，Systems Manager 修補基準服務會使用執行個體上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，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 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有兩個預先設定的儲存庫。
**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)`
**注意**
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
Oracle Linux 受管節點使用 Yum 做為套件管理工具，且 Yum 使用更新通知的概念，以做為名為 `updateinfo.xml` 的檔案。更新通知僅只是修復特定問題的套件集合。個別套件不會被指派分類或嚴重性等級。出於此原因，Patch Manager 會為相關套件指派更新通知的屬性，並根據修補基準中指定的分類篩選條件安裝套件。
**注意**
如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `updateinfo.xml` 檔案中未分類的套件 (或包含檔案但未正確格式化分類、嚴重性和日期值的套件) 可包含在預先篩選的修補程式清單中。但是，若要套用修補程式，修補程式仍必須符合使用者指定的修補基準規則。
------
#### [ AlmaLinux, RHEL, and Rocky Linux ]
在 AlmaLinux、Red Hat Enterprise Linux 和 Rocky Linux 上，Systems Manager 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。節點上通常會有三個預先設定的儲存庫。
所有更新會從受管節點上設定的遠端儲存庫下載。因此，此節點必須具有傳出至網際網路的存取權，以便連線至儲存庫以執行修補。
**注意**
如果您在**建立修補基準**頁面中選取**包含非安全性更新**核取方塊，則在 `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 [RHEL 客戶入口網站上 AWS 變更的 中 7 的儲存庫 IDs](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 修補基準服務會使用受管節點上預先設定的儲存庫 (repos)。這些預先設定的儲存庫可用於提取更新的可用套件升級清單。因此，Systems Manager 執行相當於 `sudo apt-get update` 命令。
然後套件會從 `codename-security` 儲存庫中進行篩選，其中的代號名稱為發行版本專屬，例如 Ubuntu Server 14 的 `trusty`。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 透過更新服務發佈的可用更新清單，並自動對 Windows Server Update Services (WSUS) 可用。
**注意**
Patch Manager 僅為 Patch Manager 支援的 Windows Server 作業系統版本提供可用的修補程式。例如，Patch Manager 無法用於修補 Windows RT。
Patch Manager 持續監控每個 AWS 區域中的新更新。各個區域中可用的更新清單將至少每天重新整理一次。Microsoft 的修補程式資訊經處理後，Patch Manager 會從其修補程式清單中刪除已被更新版本取代的更新。因此，只有最新的更新會顯示出來並提供安裝。例如，如果 `KB4012214` 取代了 `KB3135456`，Patch Manager 中只會有 `KB4012214` 可供更新。
同樣地，Patch Manager 只能在修補操作期間安裝受管節點上提供的修補程式。依預設，Windows Server 2019 和 Windows Server 2022 會移除更新，而這些更新會由稍後的更新取代。因此，如果您在 Windows Server 修補基準中使用 `ApproveUntilDate` 參數，但 `ApproveUntilDate` 參數中選取的日期*早於*最新修補程式的日期，則會發生下列情況：
+ 取代的修補程式會從節點中移除，因此無法使用 Patch Manager 進行安裝。
+ 節點上存在最新的替代修補程式，但尚未根據 `ApproveUntilDate` 參數指定的日期核准安裝。
這表示即使可能未安裝上個月的關鍵修補程式，受管節點在 Systems Manager 操作方面也符合規範。使用 `ApproveAfterDays` 參數時，可能會發生相同的情況。由於 Microsoft 取代了修補程式行為，可以設定數字 (通常大於 30 天)，這樣，若在 `ApproveAfterDays` 的天數之前發行 Microsoft 最新的可用修補程式，則永遠不會安裝 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 主控台中工作時指定替代的修補程式來源儲存庫，請使用 **Create patch baseline** (建立修補基準) 頁面上的 **Patch sources** (修補程式來源) 區段。如需使用 **Patch sources (修補程式來源)** 選項的詳細資訊，請參閱[建立適用於 Linux 的自訂修補基準](patch-manager-create-a-patch-baseline-for-linux.md)。
**範例：使用 AWS CLI**
如需在 AWS Command Line Interface (AWS CLI) 中使用 `--sources` 選項的範例，請參閱 [建立包含不同作業系統版本之自訂儲存庫的修補基準](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` 檔案。此檔案指定各種套件的發行日期、分類和嚴重性。以下項目將會影響修補行為：
+ 如果您篩選 **Classification (分類)** 與 **Severity (嚴重性)**，但是在 `updateinfo.xml` 中並未指定這些項目，則該套件將不會被篩選條件所包含。這也表示沒有 `updateinfo.xml` 檔案的套件不會包含在修補中。
+ 如果您篩選 **ApprovalAfterDays**，但套件發行日期並非 Unix Epoch 格式 (或沒有指定發行日期)，該套件將不會被篩選條件所包含。
+ 如果您選取**建立修補基準**頁面中的**包含非安全性更新**核取方塊，則會有例外狀況。在這種情況下，沒有 `updateinfo.xml` 檔案的套件 (或包含此檔案但未正確格式化**分類**、**嚴重性**和**日期**值的套件)，*會*包含在預先篩選的修補程式清單中。(它們必須仍符合其他修補基準規則的要求，才能進行安裝。)
## 替代修補程式來源儲存庫使用範例
**範例 1 – Ubuntu Server 的非安全性更新**
您已使用 Patch Manager，使用 AWS提供的預先定義修補程式基準，在Ubuntu Server受管節點的機群上安裝安全修補程式`AWS-UbuntuDefaultPatchBaseline`。您可以建立以此預設為基礎的新修補基準，但在核准規則中指定，您希望也安裝預設分發中非安全性相關的更新。當此修補基準在您的節點上執行時，將會套用安全性與非安全性問題的修補程式。您也可以選擇在您為基準指定的修補程式例外狀況中，核准非安全性修補程式。
**範例 2 - Ubuntu Server 的個人套件存檔 (PPA)**
您的 Ubuntu Server 受管節點執行透過 [Ubuntu 個人套件封存 (PPA) 分發的軟體](https://launchpad.net/ubuntu/+ppas)。在此案例下，您建立一個修補基準，指定您已在受管節點上設定的 PPA 儲存庫做為修補操作的來源儲存庫。然後，使用 Run Command 執行在節點上的修補基準文件。
**範例 3 - 支援的 Amazon Linux 版本上的內部公司應用程式**
您需要在您的 Amazon Linux 受管節點上執行一些應用程式，以符合產業法律合規需求。您可以在節點上為這些應用程式設定儲存庫，使用 YUM 初步安裝應用程式，然後更新或建立新的修補基準，以包含這個新的公司儲存庫。在此之後，您可以使用 Run Command，執行具有 `Scan` 選項的 `AWS-RunPatchBaseline` 文件，查看公司套件是否列在已安裝的套件中，並且在受管節點上是否為最新狀態。如果不是最新的，您可以使用 `Install` 選項更新應用程式以再次執行該文件。
# 如何安裝修補程式
Patch Manager是 中的工具 AWS Systems Manager，使用作業系統內建套件管理員在受管節點上安裝更新。例如，它在 Amazon Linux 2023 Windows Server和 `DNF`上使用 Windows Update API。修補程式管理員會遵守節點上現有的套件管理員和儲存庫組態，包括儲存庫狀態、鏡像 URLs、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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 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)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 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)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
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 Server ]
在 Debian Server 執行個體上，修補程式安裝工作流程如下：
1. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
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 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
**注意**
對於 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` 詳細資訊，但 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 子程序執行命令，以收集套件資料，並解析輸出以識別套件名稱和版本。
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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 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)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 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)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 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)。每個核准規則皆可將套件定義為已核准。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
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. 如果使用 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL (使用 `AWS-RunPatchBaseline` 或 `AWS-RunPatchBaselineAssociation` 文件的 `InstallOverrideList` 參數) 指定修補程式清單，系統會安裝列出的修補程式，並略過步驟 2-7。
1. 若有可用於 `python3-apt` (`libapt` 的 Python 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
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 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **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`)
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 Update 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 Update 網站，否則修補將會失敗。或者，您可以設定 WSUS 伺服器作為 KB 儲存庫，並設定您的受管節點以 WSUS 伺服器為目標使用群組政策。
在建立 Windows Server 的自訂修補基準時，Patch Manager 可能會參考 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 使用者指南》**中的[透過版本化儲存庫使用決定性升級](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_tw/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) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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. 在受管節點上，如果 `updateinfo.xml` 檔案存在於自訂儲存庫中，則對於每個已設定儲存庫，DNF 程式庫都會存取此檔案。
如果沒有找到一律包含預設儲存庫的 `updateinfo.xml`，是否安裝修補程式取決於**包含非安全性更新**和**自動核准**的設定。例如，如果允許非安全性更新，則會在自動核准時間到達時進行安裝。
1. 如果存在 `updateinfo.xml`，則在檔案中的每個更新通知皆包含數個屬性，以表示通知中的套件的屬性，如下表所述。
**更新通知屬性**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
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 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **Include nonsecurity updates** (包含非安全性更新) 核取方塊。
如果非安全更新被排除，將會套用隱含規則，以僅選擇安全儲存庫中包含升級的套件。對於每個套件，套件的候選版本 (通常是最新版本) 必須是安全儲存庫的一部分。在這種情形下，對於 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) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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_tw/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) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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_tw/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) 資料類型中的產品金鑰屬性的值。
1. 已根據以下指導方針選取欲更新之套件：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/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) 資料類型中的**分類**金鑰屬性的值。表示包含在更新通知中的修補程式類型。
您可以使用 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 主控台之 **Create patch baseline** (建立修補基準) 頁面或 **Edit patch baseline** (編輯修補基準) 頁面的 **Approval rules** (核准規則) 區域中檢視清單。
+ **嚴重性**：對應至修補基準之 [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 主控台之 **Create patch baseline** (建立修補基準) 頁面或 **Edit patch baseline** (編輯修補基準) 頁面的 **Approval rules** (核准規則) 區域中檢視清單。
受管節點的產物取決於 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) 資料類型中的**產品**金鑰屬性的值。
對於每個修補程式，修補基準做為篩選條件使用，只允許更新中包含合格的套件。如果在套用修補基準定義後，有多個套件可以適用，將使用最新的版本。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](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 程式庫界面) 的更新，它會升級到最新版本。(這個非安全性套件會升級，即使您未選取 **Include nonsecurity updates** (包含非安全性更新) 選項)。
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 更新套件的發行日期，此作業系統不支援自動核准選項。
然而，核准規則也受限於建立或最後更新修補基準時，是否已選取 **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`)
如果包含非安全性更新，則也會考慮來自其他儲存庫的修補程式。
如需已核准修補程式和已拒絕修補程式清單之可接受格式的相關資訊，請參閱 [已核准與遭拒的修補程式清單的套件名稱格式](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 的更新版本。若未使用最新版本的 Agent，您的受管節點可能會無法使用 Systems Manager 中的各種工具及功能。因此，我們建議您讓機器的 SSM Agent 自動保持最新狀態。如需相關資訊，請參閱[自動化 SSM Agent 更新](ssm-agent-automatic-updates.md)。請訂閱 GitHub 上的 [SSM Agent 版本備註](https://github.com/aws/amazon-ssm-agent/blob/mainline/RELEASENOTES.md)頁面，以便接收有關 SSM Agent 更新的通知。
## 差異 1：修補程式評估
Patch Manager 會在 Windows 受管節點以及 Linux 受管節點上使用不同的程序，藉此評估哪些修補程式應該出現。
**Linux**
對於 Linux 修補，Systems Manager 會評估修補基準規則，以及*每個*受管節點上已核准與已拒絕修補程式的清單。Systems Manager 必須評估各個節點上的修補，因為服務會從受管節點上已設定的儲存庫擷取已知修補程式與更新的清單。
**Windows**
對於 Windows 修補，Systems Manager 會*直接在服務中*評估修補基準規則，以及已核准與已拒絕修補程式的清單。它可以這麼做，因為 Windows 修補程式皆來自於單一儲存庫 (Windows Update)。
## 差異 2：`Not Applicable` 修補程式
由於 Linux 作業系統有大量的可用套件，Systems Manager 不會報告狀態為*不適用*之修補程式的詳細資訊。例如，執行個體未安裝 Apache 時，`Not Applicable` 修補程式是 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 Update 問題疑難解答](https://learn.microsoft.com/en-us/troubleshoot/windows-client/installing-updates-features-roles/windows-update-issues-troubleshooting)。