本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
關於 AWS-RunPatchBaseline
SSM 文件
AWS Systems Manager 支援 AWS-RunPatchBaseline
,Patch Manager 的 Systems Manager 文件 (SSM 文件) (AWS Systems Manager 功能)。此 SSM 文件在受管節點上執行與安全相關和其他更新類型的修補操作。執行文件時,如果未指定修補程式群組,則會使用指定為作業系統類型之「預設」的修補基準。否則,它會使用與修補程式群組相關聯的修補基準。如需有關修補程式群組的資訊,請參閱 關於修補程式群組。
您可以使用 AWS-RunPatchBaseline
文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上,應用程式支援僅限於由 Microsoft 發行的應用程式更新。)
本文件支援 Linux、macOS,以及 Windows Server 受管節點。此文件會為各個平台執行適當的動作。
注意
Patch Manager 也支援舊版 SSM 文件 AWS-ApplyPatchBaseline
。不過,此文件僅支援 Windows 受管節點上的修補。建議您改為使用 AWS-RunPatchBaseline
,因為它支援在 Linux、macOS 和 Windows Server 受管節點上修補。SSM Agent 的 2.0.834.0 版或更新版本,才能使用 AWS-RunPatchBaseline
文件。
每個快照都是特定於 AWS 帳戶、修補程式群組、作業系統和快照 ID。快照是透過預先簽署的 Amazon Simple Storage Service (Amazon S3) URL 交付,快照會在建立後 24 小時過期。不過,URL 過期後,如果想要將相同的快照內容套用到其他受管節點,則您可以在建立快照後最多 3 天內產生新的預先簽署 Amazon Simple Storage Service (Amazon S3) URL。若要這麼做,請使用 get-deployable-patch-snapshot-for-instance 命令。
在安裝所有已核准且適用的更新,並視需要重新啟動之後,會在受管節點上產生修補程式合規資訊,並回報 Patch Manager。
注意
如果在 AWS-RunPatchBaseline
文件中將 RebootOption
參數設定為 NoReboot
,則在執行 Patch Manager 後不會重新啟動受管節點。如需詳細資訊,請參閱參數名稱:RebootOption。
如需有關檢視修補程式合規資料的詳細資訊,請參閱關於修補程式合規。
AWS-RunPatchBaseline
參數
AWS-RunPatchBaseline
支援五個參數。Operation
參數是必要參數。InstallOverrideList
、BaselineOverride
和 RebootOption
參數是選用的。Snapshot-ID
技術上是選用的,但我們建議您在維護時段之外執行 AWS-RunPatchBaseline
時提供自訂值,並讓 Patch Manager 在該文件做為維護時段操作的一部分執行時自動提供自訂值。
參數
參數名稱:Operation
用量:必要。
選項:Scan
| Install
。
- Scan
-
當您選擇
Scan
選項時,AWS-RunPatchBaseline
會判斷受管節點的修補程式合規狀態,並將此資訊回報至 Patch Manager。Scan
不會提示要安裝的更新或需要重新啟動的受管節點。反之,此操作會識別遺漏了哪些已核准且適用於節點的更新。 - 安裝
-
當您選擇
Install
選項,AWS-RunPatchBaseline
會嘗試安裝受管節點上遺漏的已核准且適用的更新。在Install
操作中產生的修補程式合規資訊不會列出任何遺失的更新,但如果因為任何原因導致未成功安裝更新,則可能會報告狀態為失敗的更新。每當更新安裝於受管節點時,節點將重新啟動,以確保安裝並啟動更新。(例外:如果AWS-RunPatchBaseline
文件中的RebootOption
參數設為NoReboot
,受管節點不會在 Patch Manager 執行之後重新啟動。如需詳細資訊,請參閱 參數名稱:RebootOption。)注意
如果在 Patch Manager 更新受管節點之前已安裝基準規則指定的修補程式,系統可能無法如預期重新啟動。當使用者手動安裝修補程式,或由其他程式自動安裝 (例如 Ubuntu Server 上的
unattended-upgrades
套件) 時,就會發生這種情況。
參數名稱:AssociationId
用量:選用。
AssociationId
是 State Manager (AWS Systems Manager 功能) 中的現有關聯 ID。它由 Patch Manager 使用,將合規資料新增至指定的關聯。此關聯與 Quick Setup 中的修補程式政策中設定的修補操作有關。
注意
使用 AWS-RunPatchBaseline
時,如果提供 AssociationId
值時發生修補程式政策基準覆寫,則修補會以 PatchPolicy
操作的形式完成,且 AWS:ComplianceItem
中報告的 ExecutionType
值也為 PatchPolicy
。如果未提供任何 AssociationId
值,則會以 Command
操作形式完成修補,而且提交的 AWS:ComplianceItem
中報告的 ExecutionType
值也為 Command
。
如果您還沒有要使用的關聯,則可以通過運行創建一個關聯create-association該命令。
參數名稱:Snapshot ID
用量:選用。
Snapshot ID
是 Patch Manager 使用的唯一 ID (GUID),確保在單一操作中修補的一組受管節點皆有一組完全相同的核准修補程式。雖然此參數定義為選用,但我們的最佳實務建議取決於您是否會在維護時段中執行 AWS-RunPatchBaseline
,如下表所述。
AWS-RunPatchBaseline 最佳實務 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
模式 | 最佳實務 | 詳細資訊 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
在維護時段內執行 AWS-RunPatchBaseline |
請勿提供快照 ID。Patch Manager 將會為您提供。 |
若您使用維護時段執行 如果您在此情況下指定值,則請注意修補基準的快照可能不會保留超過 3 天。之後,即使您在快照過期後指定相同的 ID,仍將會產生新的快照。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
在維護時段外執行 AWS-RunPatchBaseline |
為快照 ID¹ 產生及指定自訂 GUID 值。 |
如果您不是使用維護時段執行 例如,假設您正在直接透過 Run Command 執行 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
¹您可以使用任何能產生 GUID 的工具來為快照 ID 參數產生一個值。例如,在 PowerShell,您可以使用 |
參數名稱:InstallOverrideList
用量:選用。
使用 InstallOverrideList
,您可以將 https URL 或 Amazon Simple Storage Service (Amazon S3) 路徑樣式 URL 指定至要安裝的修補程式清單。此修補程式安裝清單 (以 YAML 格式維護) 會覆寫目前預設修補基準指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的受管節點。
請注意,合規報告根據修補基準中的指定來反映修補程式狀態,而非您在 InstallOverrideList
合規清單中的指定。換言之,掃描操作會忽略 InstallOverrideList
參數。這是為了確保合規報告根據政策而非已核准用於特定修補操作的內容,來持續反映修補程式狀態。
如需如何使用 InstallOverrideList
參數依不同的維護時段排程將不同類型的修補程式套用至目標群組的說明,同時繼續單一修補基準,請參閱在AWS-RunPatchBaseline或中使用 InstallOverrideList 參數的範例案例AWS-RunPatchBaselineAssociation。
有效的 URL 格式
注意
如果您的檔案存放在公開可用的儲存貯體中,則可以指定 https URL 格式或 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。如果您的檔案存放在私有儲存貯體中,則必須指定 Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL。
-
https URL 格式:
https://s3.
aws-api-domain
/DOC-EXAMPLE-BUCKET/my-windows-override-list.yaml -
Amazon Simple Storage Service (Amazon S3) 路徑樣式的 URL:
s3://DOC-EXAMPLE-BUCKET/my-windows-override-list.yaml
有效的 YAML 內容格式
您用於在清單中指定修補程式的格式,取決於您受管節點使用的作業系統。一般格式如下:
patches: - id: '{patch-d}' title: '{patch-title}' {
additional-fields
}:{values
}
雖然您可以在 YAML 檔案中提供額外的欄位,但是在修補程式操作過程中會略過這些欄位。
此外,我們建議您在 S3 儲存貯體中新增或更新清單之前,確認您的 YAML 檔案格式是有效的。如需 YAML 格式的詳細資訊,請參閱 yaml.org
範例修補程式清單
-
Amazon Linux
patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '32:9.8.2-0.62.rc1.57.amzn1' - id: 'glibc*' - id: 'dhclient*' title: '*12:4.1.1-53.P1.28.amzn1' - id: 'dhcp*' title: '*10:3.1.1-50.P1.26.amzn1'
-
CentOS
patches: - id: 'kernel.x86_64' - id: 'bind*.x86_64' title: '32:9.8.2-0.62.rc1.57.amzn1' - id: 'glibc*' - id: 'dhclient*' title: '*12:4.1.1-53.P1.28.amzn1' - id: 'dhcp*' title: '*10:3.1.1-50.P1.26.amzn1'
-
Debian Server
patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25'
-
macOS
patches: - id: 'XProtectPlistConfigData' - id: 'MRTConfigData.1.61' - id: 'Command Line Tools for Xcode.11.5' - id: 'Gatekeeper Configuration Data'
-
Oracle Linux
patches: - id: 'audit-libs.x86_64' title: '*2.8.5-4.el7' - id: 'curl.x86_64' title: '*.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:2.02-0.81.0.1.el7' - id: 'grub2.x86_64' title: 'grub2.x86_64:1:*-0.81.0.1.el7'
-
Red Hat Enterprise Linux (RHEL)
patches: - id: 'NetworkManager.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'NetworkManager-*.x86_64' title: '*1:1.10.2-14.el7_5' - id: 'audit.x86_64' title: '*0:2.8.1-3.el7' - id: 'dhclient.x86_64' title: '*.el7_5.1' - id: 'dhcp*.x86_64' title: '*12:5.2.5-68.el7'
-
SUSE Linux Enterprise Server (SLES)
patches: - id: 'amazon-ssm-agent.x86_64' - id: 'binutils' title: '*0:2.26.1-9.12.1' - id: 'glibc*.x86_64' title: '*2.19*' - id: 'dhcp*' title: '0:4.3.3-9.1' - id: 'lib*'
-
Ubuntu Server
patches: - id: 'apparmor.amd64' title: '2.10.95-0ubuntu2.9' - id: 'cryptsetup.amd64' title: '*2:1.6.6-5ubuntu2.1' - id: 'cryptsetup-bin.*' title: '*2:1.6.6-5ubuntu2.1' - id: 'apt.amd64' title: '*1.2.27' - id: 'apt-utils.amd64' title: '*1.2.25'
-
Windows
patches: - id: 'KB4284819' title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)' - id: 'KB4284833' - id: 'KB4284835' title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)' - id: 'KB4284880' - id: 'KB4338814'
參數名稱:RebootOption
用量:選用。
選項︰RebootIfNeeded
| NoReboot
預設:RebootIfNeeded
警告
預設選項為 RebootIfNeeded
。請務必選取適用於您使用案例的正確選項。例如,如果您的受管節點必須立即重新啟動才能完成組態程序,則請選擇 RebootIfNeeded
。或者,如果您需要維持受管節點的可用性,直到排定的重新啟動時間,則請選擇 NoReboot
。
重要
我們不建議使用Patch Manager用於修補亞馬遜 EMR 中的叢集執行個體 (以前稱為亞馬遜彈性 MapReduce). 特別是,不要選擇RebootIfNeeded
選項的RebootOption
參數。(此選項可在 SSM 命令文件中使用以進行修補AWS-RunPatchBaseline
,AWS-RunPatchBaselineAssociation
,以及AWS-RunPatchBaselineWithHooks
。)
用於修補的基礎命令Patch Manager使用yum
和dnf
命令。因此,作業會因為套件的安裝方式而導致不相容。如需在 Amazon EMR 叢集上更新軟體的慣用方法的相關資訊,請參閱使用預設值AMI適用於亞馬遜 EMR在亞馬遜 EMR 管理指南。
- 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
-
參數名稱:BaselineOverride
用量:選用。
您可以使用 BaselineOverride
參數在執行時間定義修補偏好設定。此基準覆寫會作為 S3 儲存貯體中的 JSON 物件進行維護。它可確保修補操作使用符合主機作業系統所提供的基準,而不是從預設修補基準套用規則
如需使用 BaselineOverride
參數的詳細資訊,請參閱 使用參 BaselineOverride 數。