關於 AWS-RunPatchBaselineWithHooks SSM 文件

AWS Systems Manager 支援AWS-RunPatchBaselineWithHooks，Systems Manager 文件 (SSM 文件)Patch Manager，的 AWS Systems Manager功能。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。

AWS-RunPatchBaselineWithHooks 在以下方面不同於 AWS-RunPatchBaseline：

• 包裝文件–AWS-RunPatchBaselineWithHooks 是 AWS-RunPatchBaseline 的包裝，並依賴 AWS-RunPatchBaseline 進行其操作。

• Install 操作 – AWS-RunPatchBaselineWithHooks 支援在受管節點修補期間在指定點執行的生命週期掛鉤。由於修補程式安裝有時需要受管節點重新啟動，因此修補操作會分為兩個事件，總共有三個支援自訂功能的掛鉤。第一個掛鉤是在 Install with NoReboot 操作之前。第二個掛鉤是在 Install with NoReboot 操作之後。受管節點重新啟動後，第三個掛鉤可用。

• 不支援自訂修補程式清單 – AWS-RunPatchBaselineWithHooks 不支援 InstallOverrideList 參數。

• SSM Agent 支援 – AWS-RunPatchBaselineWithHooks 需要 SSM Agent 3.0.502 或更新版本安裝在要修補的受管節點上。

執行文件時，如果未指定修補程式群組，則會使用當前指定為作業系統類型之「預設」的修補基準。否則，它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊，請參閱 關於修補程式群組。

您可以使用 AWS-RunPatchBaselineWithHooks 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows 上，應用程式支援僅限於由 Microsoft 發行的應用程式更新。)

本文件支援 Linux、macOS，以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。

Linux

在 Linux 受管節點上，AWS-RunPatchBaselineWithHooks 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。此修補基準快照使用已定義的規則，以及已核准與已封鎖的修補程式清單，為各個節點類型推動適當的套件管理員：

• Amazon Linux 1、Amazon 2、CentOS 和 RHEL 7 個受管節點都使用百勝。Oracle Linux針對 YUM 操作，Patch Manager 需要 Python 2.6 或更新版本的支援版本 (2.6 - 3.10)。

• RHEL 8 受管節點使用 DNF。針對 DNF 操作，Patch Manager 需要 Python 2 或 Python 3 的支援版本 (2.6 - 3.10)。(預設不會在 RHEL 8 上安裝兩個版本。您必須手動安裝其中一個。)

• Debian Server、Raspberry Pi OS 及 Ubuntu Server 執行個體使用 APT。針對 APT 操作，Patch Manager 需要 Python 3 的支援版本 (3.0 - 3.10)。

• SUSE Linux Enterprise Server 受管節點使用 Zypper。針對 Zypper 操作，Patch Manager 需要 Python 2.6 或更新版本的支援版本 (2.6 - 3.10)。

macOS

在 macOS 受管節點上，AWS-RunPatchBaselineWithHooks 文件會叫用 Python 模組，進而下載套用至受管節點的修補基準快照。接下來，Python 子程序會在節點上叫用 CLI，以擷取指定套件管理工具的安裝和更新資訊，並為每個更新套件驅動適當的套件管理工具。

Windows Server

在Windows Server受管理的節點上，AWS-RunPatchBaselineWithHooks文件會下載並叫用 PowerShell 模組，進而下載套用至受管理節點的修補程式基準快照。此修補基準快照集包含已核准修補程式清單，這些修補程式是藉由查詢修補基準針對 Windows Server 更新服務 (WSUS) 伺服器進行編譯。此清單會傳遞至 Windows Update API，視需要控制下載和安裝核准的修補程式。

每個快照都專屬於修補程式群組、作業系統和快照 ID。 AWS 帳戶快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付，快照會在建立後 24 小時過期。不過，URL 過期後，如果想要將相同的快照內容套用到其他受管節點，則您可以在建立快照後最多三天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做，請使用 get-deployable-patch-snapshot-for-instance 命令。

在安裝所有已核准且適用的更新，並視需要重新啟動之後，會在受管節點上產生修補程式合規資訊，並回報 Patch Manager。

注意

如果在 AWS-RunPatchBaselineWithHooks 文件中將 RebootOption 參數設定為 NoReboot，則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊，請參閱 參數名稱：RebootOption。

如需有關檢視修補程式合規資料的詳細資訊，請參閱關於修補程式合規。

AWS-RunPatchBaselineWithHooks 操作步驟

當 AWS-RunPatchBaselineWithHooks 執行時，會進行下列步驟：

1. 掃描 – 在受管節點上執行使用 AWS-RunPatchBaseline 的 Scan 操作，並產生並上傳合規報告。

2. 確認本機修補程式狀態 – 執行指令碼，以確定將根據所選的操作和步驟 1 的 Scan 結果執行什麼步驟。

   1. 如果選取的操作為 Scan，則操作會標示為完成。操作結束。

   2. 如果選取的操作為 Install，則 Patch Manager 會評估步驟 1 的 Scan 結果，以確定接下來要執行的內容：

      1. 如果未偵測到遺漏的修補程式，且不需要擱置中的重新開機，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。

      2. 如果未偵測到遺漏的修補程式，但有所需的擱置中重新開機，且所選重新開啟選項為 NoReboot，則操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。

      3. 否則，操作會繼續至下一個步驟。

3. 修補程式前掛鉤操作 - 您為第一個lifecycle hook PreInstallHookDocName 提供的 SSM 文件在受管節點上執行。

4. 安裝方式 NoReboot-在受管理的節點上執行具AWS-RunPatchBaseline有NoReboot使用重新開機選項的Install作業，並產生並上傳符合性報告。

5. 安裝後掛鉤操作 - 您為第二個lifecycle hook PostInstallHookDocName 提供的 SSM 文件在受管節點上執行。

6. 確認重新啟動 – 執行指令碼以判斷受管節點是否需要重新開機，以及需要執行哪些步驟：

   1. 如果選取的重新開機選項為 NoReboot，則操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。

   2. 如果選取的重新開機選項為 RebootIfNeeded，則 Patch Manager 會檢查步驟 4 中所收集的庫存是否有所需之任何擱置中的重新開機。這意味著在下列任一情況下，作業會繼續執行步驟 7，且受管節點會重新啟動：

      1. Patch Manager 已安裝一個或多個修補程式。(Patch Manager 不評估修補程式是否需要重新啟動。即使修補程式不需要重新啟動，系統也會重新啟動。)

      2. Patch Manager 偵測到一或多個修補程式在安裝操作期間狀態為 INSTALLED_PENDING_REBOOT。INSTALLED_PENDING_REBOOT 狀態可能意味著上次執行安裝操作時已選取 NoReboot 選項。

      如果找不到需要符合這些條件的修補程式，則受管節點修補操作即完成，且操作會直接進行到最後一個步驟 (步驟 8)，其中包括您提供的掛鉤。兩者之間的任何步驟都會略過。

7. 重新啟動和報告 – 具有 RebootIfNeeded 重啟啟動選項的安裝操作在使用 AWS-RunPatchBaseline 的受管節點上執行，還會產生並上傳合規報告。

8. 重新啟動後掛鉤操作 – 您為第三個lifecycle hook OnExitHookDocName 提供的 SSM 文件在受管節點上執行。

對於 Scan 操作，如果步驟 1 失敗，則執行文件的程序會停止並報告為失敗，儘管後續步驟會報告為成功。

對於 Install 操作，如果有任何 aws:runDocument 步驟在操作期間失敗，則這些步驟會報告為失敗，而且操作會直接進行到最後一個步驟 (步驟 8)，其中包含您提供的掛鉤。兩者之間的任何步驟都會略過。此步驟會報告為失敗，最後一個步驟會報告其操作結果的狀態，而兩者之間的所有步驟都會報告為成功。

AWS-RunPatchBaselineWithHooks 參數

AWS-RunPatchBaselineWithHooks 支援六個參數。

Operation 參數是必要參數。

RebootOption、PreInstallHookDocName、PostInstallHookDocName 和 OnExitHookDocName 是選用參數。

Snapshot-ID 在技術上是選用的，但建議您在維護時段以外執行 AWS-RunPatchBaselineWithHooks 時，為其提供自訂值。當文件以維護時段操作的一部分執行時，讓 Patch Manager 自動提供值。

參數名稱：Operation

用量：必要。

選項：Scan | Install。

Scan

當您選擇 Scan 選項時，系統會使用 AWS-RunPatchBaseline 文件判斷受管節點的修補程式合規狀態，並將此資訊回報至 Patch Manager。Scan 不會提示要安裝的更新或需要重新啟動的受管節點。反之，此操作會識別遺漏了哪些已核准且適用於節點的更新。

安裝

當您選擇 Install 選項，AWS-RunPatchBaselineWithHooks 會嘗試安裝受管節點上遺漏的已核准且適用的更新。在 Install 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時，節點將重新啟動，以確保安裝並啟動更新。(例外：如果 AWS-RunPatchBaselineWithHooks 文件中的 RebootOption 參數設為 NoReboot，受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

注意

如果在 Patch Manager 更新受管節點之前已安裝基準規則指定的修補程式，系統可能無法如預期重新啟動。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 unattended-upgrades 套件) 時，就會發生這種情況。

參數名稱：Snapshot ID

用量：選用。

Snapshot ID 是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用，但我們的最佳實務建議取決於您是否會在維護時段中執行 AWS-RunPatchBaselineWithHooks，如下表所述。

AWS-RunPatchBaselineWithHooks 最佳實務
Mode	最佳實務	詳細資訊
在維護時段內執行 AWS-RunPatchBaselineWithHooks	請勿提供快照 ID。Patch Manager 將會為您提供。	若您使用維護時段執行 AWS-RunPatchBaselineWithHooks，您不應提供自己產生的快照 ID。在此案例中，Systems Manager 會根據維護時段執行 ID 提供 GUID 值。這可確保維護時段中所有 AWS-RunPatchBaselineWithHooks 呼叫皆使用正確的 ID。 如果您在此情況下指定值，則請注意修補基準的快照可能不會保留超過 3 天。之後，即使您在快照過期後指定相同的 ID，仍將會產生新的快照。
在維護時段外執行 AWS-RunPatchBaselineWithHooks	為快照 ID¹ 產生及指定自訂 GUID 值。	如果您不是使用維護時段執行 AWS-RunPatchBaselineWithHooks，我們建議您為每個修補基準產生並指定唯一的快照 ID，特別是如果您在相同的操作中，在多個受管節點上執行 AWS-RunPatchBaselineWithHooks 文件時。如果您在此情況下沒有指定 ID，Systems Manager 將為命令傳送至的每個受管節點產生不同的快照 ID。這可能會導致在節點間指定不同的修補程式集合。 例如，假設您正在直接透過 Run Command 執行 AWS-RunPatchBaselineWithHooks 文件 (AWS Systems Manager 的功能)，並以 50 個受管節點群組為目標。指定自訂快照 ID 會產生單一基準快照，用於評估和修補所有受管節點，以確保它們最終處於一致的狀態。
¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如，在中 PowerShell，您可以使用指New-Guid令程式來產生格式為的 GUID。12345699-9405-4f69-bc5e-9315aEXAMPLE

參數名稱：RebootOption

用量：選用。

選項︰RebootIfNeeded | NoReboot

預設：RebootIfNeeded

警告

預設選項為 RebootIfNeeded。請務必選取適用於您使用案例的正確選項。例如，如果您的受管節點必須立即重新啟動才能完成組態程序，則請選擇 RebootIfNeeded。或者，如果您需要維持受管節點的可用性，直到排定的重新啟動時間，則請選擇 NoReboot。

重要

我們不建議使Patch Manager用修補 Amazon EMR 中的叢集執行個體 (先前稱為 Amazon 彈性 MapReduce)。特別是，請勿為 RebootOption 參數選取 RebootIfNeeded 選項。(此選項在用於修補 AWS-RunPatchBaseline、AWS-RunPatchBaselineAssociation 和 AWS-RunPatchBaselineWithHooks 的 SSM 命令文件中可用。)

使用 Patch Manager 進行修補時所使用的基礎命令使用 yum 和 dnf 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需有關在 Amazon EMR 叢集上更新軟體的慣用方法的詳細資訊，請參閱《Amazon EMR 管理指南》中的使用 Amazon EMR 的預設 AMI 一節。

RebootIfNeeded

當您選擇 RebootIfNeeded 選項時，受管節點在下列情況下會重新啟動：

• Patch Manager 已安裝一或多個修補程式。

  Patch Manager 不會評估修補程式是否需要重新開機。即使修補程式不需要重新開機，系統也會重新開機。

• Patch Manager 偵測到一或多個修補程式在 Install 操作期間狀態為 INSTALLED_PENDING_REBOOT。

  INSTALLED_PENDING_REBOOT 狀態可能表示上次執行 Install 作業時已選取 NoReboot 選項。

  注意

  安裝於 Patch Manager 之外的修補程式，一律不會具有 INSTALLED_PENDING_REBOOT 狀態。

在這兩種情況下重新啟動受管節點，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新啟動行為一致。

NoReboot

當您選擇 NoReboot 選項時，即使受管節點在 Install 作業期間安裝了修補程式，Patch Manager 也不會重新啟動受管節點。如果您知道您的受管節點在套用修補程式之後不需要重新啟動，或是您在節點上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制受管節點重新啟動的時間時 (例如使用維護時段)，此選項也很有用。

注意

如果您選擇 NoReboot 選項並安裝修補程式，則會為修補程式指派 InstalledPendingReboot 的狀態。但是，受管節點本身會標示為 Non-Compliant。重新啟動並執行 Scan 操作之後，節點狀態會更新為 Compliant。

修補程式安裝追蹤檔案：若要追蹤修補程式安裝，特別是自上次系統重新啟動後已安裝的修補程式，Systems Manager 會在受管節點上維護檔案。

重要

請勿刪除或修改追蹤檔案。如果此檔案已刪除或損毀，則受管節點的修補程式合規報告會不正確。如果發生此情況，請重新啟動節點並執行修補程式掃描作業以還原檔案。

此追蹤檔案存放於受管節點的下列位置：

• Linux 作業系統：

  • /var/log/amazon/ssm/patch-configuration/patch-states-configuration.json

  • /var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json

• Windows Server 作業系統：

  • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json

  • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json

參數名稱：PreInstallHookDocName

用量：選用。

預設︰AWS-Noop。

提供給 PreInstallHookDocName 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供受 AWS 管理文件的名稱，或是您已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。(對於已與您共用不同的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument。)

您指定的 SSM 文件會在 Install 操作之前執行，並執行 SSM Agent 支援的任何動作，例如用於在受管節點上執行修補之前進行應用程式運作狀態檢查的 shell 指令碼。(如需動作清單，請參閱 命令文件外掛程式參考)。預設 SSM 文件名稱為 AWS-Noop，它不會對受管節點執行任何操作。

如需建立自訂 SSM 文件的詳細資訊，請參閱 建立 SSM 文件內容。

參數名稱：PostInstallHookDocName

用量：選用。

預設︰AWS-Noop。

提供給 PostInstallHookDocName 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供受 AWS 管理文件的名稱，或是您已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。(對於已與您共用不同的 SSM 文件 AWS 帳戶，您必須指定完整的資源 ARN，例如arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument。)

在 Install with NoReboot 操作之後執行您指定的 SSM 文件，還會執行 SSM Agent 支援的任何操作，例如重新開機前安裝第三方更新的 shell 指令碼。(如需動作清單，請參閱 命令文件外掛程式參考)。預設 SSM 文件名稱為 AWS-Noop，它不會對受管節點執行任何操作。

如需建立自訂 SSM 文件的詳細資訊，請參閱 建立 SSM 文件內容。

參數名稱：OnExitHookDocName

用量：選用。

預設︰AWS-Noop。

提供給 OnExitHookDocName 參數的值是您所選 SSM 文件的名稱或 Amazon Resource Name (ARN)。您可以提供受 AWS 管理文件的名稱，或是您已建立或已與您共用的自訂 SSM 文件的名稱或 ARN。(若是來自不同 AWS 帳戶 且已與您共用的 SSM 文件，您必須指定完整資源 ARN，例如 arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument。)

您指定的 SSM 文件會在受管節點重新啟動操作之後執行，並執行 SSM Agent 支援的任何動作，例如用於在修補操作完成之後確認節點運作狀態的 shell 指令碼。(如需動作清單，請參閱 命令文件外掛程式參考)。預設 SSM 文件名稱為 AWS-Noop，它不會對受管節點執行任何操作。

如需建立自訂 SSM 文件的詳細資訊，請參閱 建立 SSM 文件內容。