• 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)。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 如何指定替代修補程式來源儲存庫 (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` 選項更新應用程式以再次執行該文件。