SSM用於修補的命令文件:AWS-RunPatchBaselineWithHooks - AWS Systems Manager

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

SSM用於修補的命令文件:AWS-RunPatchBaselineWithHooks

AWS Systems Manager 支援AWS-RunPatchBaselineWithHooks、Systems Manager 文SSM件 (文件Patch Manager) 的功能 AWS Systems Manager。本SSM文件會針對安全性相關及其他類型的更新,在受管節點上執行修補作業。

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

  • 包裝文件AWS-RunPatchBaselineWithHooksAWS-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 Server 上,應用程式支援僅限於由 Microsoft 發行的應用程式更新。)

本文件支援 Linux 和Windows Server受管理節點。此文件會為各個平台執行適當的動作。

注意

AWS-RunPatchBaselineWithHooks不支援macOS。

Linux

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

  • Amazon Linux 1、Amazon 2、CentOS 和 RHEL 7 個受管節點使用YUM。Oracle Linux對於YUM操作,Patch Manager需要Python 2.6或更高版本支持的版本(2.6-3.10)。

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

  • Debian ServerRaspberry 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)。

Windows Server

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

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

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

注意

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

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

AWS-RunPatchBaselineWithHooks 操作步驟

AWS-RunPatchBaselineWithHooks 執行時,會進行下列步驟:

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

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

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

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

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

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

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

  3. 預先修補程式掛接作業-您為第一個生命週期勾點提供的SSM文件會在受管理的節點上執行。PreInstallHookDocName

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

  5. 安裝後勾點作業-您為第二個生命週期掛接提供的SSM文件會在受管理的節點上執行。PostInstallHookDocName

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

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

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

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

      2. Patch Manager 偵測到一或多個修補程式在安裝操作期間狀態為 INSTALLED_PENDING_REBOOT。此INSTALLED_PENDING_REBOOT狀態可能表示上次執行 Install 作業時已選取該選項NoReboot,或是Patch Manager自上次重新啟動受管理節點以外的地方安裝修補程式。

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

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

  8. 重新開機後掛接作業-您為第三個生命週期掛接提供的SSM文件會在受管理的節點上執行。OnExitHookDocName

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

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

AWS-RunPatchBaselineWithHooks 參數

AWS-RunPatchBaselineWithHooks 支援六個參數。

Operation 參數是必要參數。

RebootOptionPreInstallHookDocNamePostInstallHookDocNameOnExitHookDocName 是選用參數。

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

AWS-RunPatchBaselineWithHooks 最佳實務
Mode 最佳實務 詳細資訊
在維護時段內執行 AWS-RunPatchBaselineWithHooks 請勿提供快照 ID。Patch Manager 將會為您提供。

若您使用維護時段執行 AWS-RunPatchBaselineWithHooks,您不應提供自己產生的快照 ID。在這個案例中,Systems Manager 會根據維護視窗執行識別碼提供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 會產生單一基準快照,用於評估和修補所有受管節點,以確保它們最終處於一致的狀態。

¹ 您可以使用任何能夠產生快照 ID 參數值的工具。GUID例如,在中 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、和的 SSM Command 文件AWS-RunPatchBaselineAssociation中使用AWS-RunPatchBaselineWithHooks。)

使用 Patch Manager 進行修補時所使用的基礎命令使用 yumdnf 命令。因此,相關操作會因套件的安裝方式而導致不相容。如需在 Amazon EMR 叢集上更新軟體的偏好方法的相關資訊,請參閱 Amazon EMR管理指南EMR中的使用 Amazon 預設值AMI

RebootIfNeeded

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

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

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

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

    Patch Manager此INSTALLED_PENDING_REBOOT狀態可能表示上次執行Install作業時已選取該選項NoReboot,或是自上次受管理節點重新啟動後已安裝在以外的地方。

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

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 資源名稱 (ARN)。您可以提供受 AWS 管理文件的名稱,或是您已建立或ARN已與您共用的自訂SSM文件的名稱或名稱。(對於從其他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 資源名稱 (ARN)。您可以提供受 AWS 管理文件的名稱,或是您已建立或ARN已與您共用的自訂SSM文件的名稱或名稱。(對於從其他SSM文件與您共用的文件 AWS 帳戶,您必須指定完整資源ARN,例如arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument。)

您指定的SSM文件會在Install with NoReboot作業之後執行,並執行支援的任何動作SSM Agent,例如在重新開機之前安裝協力廠商更新的 shell 指令碼。(如需動作清單,請參閱 命令文件外掛程式參考)。默認SSM文檔名稱是AWS-Noop,它不會在託管節點上執行任何操作。

如需有關建立自訂SSM文件的資訊,請參閱建立SSM文件內容

參數名稱:OnExitHookDocName

用量:選用。

預設AWS-Noop

要為OnExitHookDocName參數提供的值是您選擇的SSM文件的名稱或 Amazon 資源名稱 (ARN)。您可以提供受 AWS 管理文件的名稱,或是您已建立或ARN已與您共用的自訂SSM文件的名稱或名稱。(對於從其他SSM文件與您共用的文件 AWS 帳戶,您必須指定完整資源ARN,例如arn:aws:ssm:us-east-2:123456789012:document/MySharedDocument。)

您指定的SSM文件會在受管理的節點重新啟動作業之後執行,並執行任何支援的動作SSM Agent,例如在修補作業完成後驗證節點健康狀態的 shell 命令檔。(如需動作清單,請參閱 命令文件外掛程式參考)。默認SSM文檔名稱是AWS-Noop,它不會在託管節點上執行任何操作。

如需有關建立自訂SSM文件的資訊,請參閱建立SSM文件內容