AWS Systems Manager Change Manager は新規顧客に公開されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「AWS Systems Manager Change Manager の可用性の変更」を参照してください。
パッチのインストール方法
AWS Systems Manager のツールである Patch Manager は、オペレーティングシステムの組み込みパッケージマネージャーを使用してマネージドノードに更新プログラムをインストールします。例えば、Windows Server に Windows Update API を使用して、Amazon Linux 2023 に DNF を使用します。Patch Manager は、ノード上の既存のパッケージマネージャーおよびリポジトリの設定に従います。これには、リポジトリのステータス、ミラー URL、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 マネージドノードでは、パッチのインストールワークフローは次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
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 -yAmazon 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 -yAmazon Linux 2023 の場合、同等の dnf コマンドは次のようになります。
sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y注記
yumまたはdnfコマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。Amazon Linux 2023 の追加パッチ適用の詳細
- 重要度レベル「なし」のサポート
-
Amazon Linux 2023 は、DNF パッケージマネージャーによって認識されるパッチの重要度レベル
Noneもサポートしています。 - 重要度レベル「中」のサポート
-
Amazon Linux 2023 の場合、パッチの重大度レベル
Mediumは、一部の外部リポジトリで定義されている重大度レベルModerateと同等です。パッチベースラインにMedium重要度パッチを含めると、外部パッチからのModerate重要度パッチもインスタンスにインストールされます。API アクション DescribeInstancePatches を使用してコンプライアンスデータをクエリすると、重要度レベル
Mediumのフィルタリングによって、重要度レベルがMediumとModerateの両方のパッチがレポートされます。 - Amazon Linux 2023 の推移的な依存関係処理
-
Amazon Linux 2023 の場合、Patch Manager は、
dnfコマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、
dnf upgrade-minimal --securityは既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。
-
-
-
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
注記
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に
skip_if_unavailable=Falseを追加します。skip_if_availableオプションの詳細については、「パッチソースへの接続」を参照してください。 -
- CentOS Stream
-
CentOS Stream マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
CentOS Stream の DNF 更新は、承認済みパッチに適用されます。
注記
CentOS Stream の場合、Patch Manager は、
dnfコマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。例えば、
dnf upgrade-minimal ‐‐securityは既知のセキュリティ問題の解決に必要な推移的依存関係の最小バージョンをインストールしますが、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールします。 -
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
-
- Debian サーバー
-
Debian Server インスタンスの場合、パッチのインストール手順は次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
InstallOverrideListまたはAWS-RunPatchBaselineドキュメントのAWS-RunPatchBaselineAssociationパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
更新が可能な場合、
python3-apt(Python ライブラリインターフェイスのlibapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
注記
Debian Server の更新プログラムパッケージのリリース日は確定できないため、このオペレーティングシステムでは自動承認オプションがサポートされていません。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
注記
Debian Server では、パッチの候補となるバージョンは
debian-securityに含まれているパッチに限定されます。 -
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
APT ライブラリを使用してパッケージをアップグレードします。
注記
Patch Manager では、APT
Pin-Priorityオプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。 -
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
-
- macOS
-
macOS マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
-
/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が含まれますが、パッチマネージャーで使用されるのは、パッケージ名とバージョンのみです。Brew と Brew Cask の場合、Homebrew は root ユーザーで実行されるコマンドをサポートしていません。その結果、Patch Manager は Homebrew ディレクトリの所有者、または Homebrew ディレクトリの所有者グループに属する有効なユーザーとして、Homebrew コマンドを照会して実行します。コマンドは、
softwareupdateとinstallerに似ており、Python サブプロセスを介してパッケージデータを収集し、出力を解析してパッケージ名とバージョンを識別します。 -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
マネージドノードで適切なパッケージ CLI を呼び出し、承認されたパッチを次のように処理します。
注記
installerには、更新プログラムを確認してインストールする機能がありません。したがって、installerでは、Patch Manager はインストールされているパッケージのみをレポートします。その結果、installerパッケージはMissingとして報告されることはありません。-
AWS によって事前定義されたデフォルトのパッチベースライン、ならびに [セキュリティ以外の更新プログラムを含める] チェックボックスが選択されていない状態のカスタムのパッチベースラインには、セキュリティ更新プログラムのみが適用されます。
-
[セキュリティ以外の更新プログラムを含める] チェックボックスが選択されていいる状態のカスタムのパッチベースラインには、セキュリティ更新プログラムおよびセキュリティ以外の更新プログラムの両方が適用されます。
-
-
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
-
- Oracle Linux
-
Oracle Linux マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
バージョン 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コマンドによってインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、
dnf upgrade-minimal --securityは既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。 -
[セキュリティ以外の更新プログラムを含める] チェックボックスが選択されていいる状態のカスタムのパッチベースラインには、
updateinfo.xmlにあるパッチおよびupdateinfo.xmlにないパッチの両方が適用されます (セキュリティ更新プログラムおよびセキュリティ以外の更新プログラム)。このワークフローに該当する yum コマンドは次のとおりです。
sudo dnf upgrade --security --bugfix
-
注記
yumまたはdnfコマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。 -
-
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
注記
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に
skip_if_unavailable=Falseを追加します。skip_if_availableオプションの詳細については、「パッチソースへの接続」を参照してください。 -
- AlmaLinux, RHEL, and Rocky Linux
-
AlmaLinux、Red Hat Enterprise Linux、および Rocky Linux マネージドノードで、パッチのインストール手順は次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
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 -yAlmaLinux、RHEL 8、および Rocky Linux の場合、このワークフローに対応する dnf コマンドは次のとおりです。
sudo dnf update-minimal --sec-severity=Critical --bugfix -y ; \ sudo dnf update-minimal --sec-severity=Important --bugfix -y注記
AlmaLinu、RHEL、Rocky LinuxRocky Linux の場合、Patch Manager は、
dnfコマンドでインストールされる推移的な依存関係とは異なるバージョンの推移的依存関係をインストールする場合があります。推移的な依存関係は、他のパッケージ (依存関係の依存関係) の要件を満たすために自動的にインストールされるパッケージです。例えば、Patch Manager は同じ推移的な依存関係の利用可能な最新バージョンをインストールしますが、
dnf upgrade-minimal --securityは既知のセキュリティ問題を解決するために必要な推移的依存関係の最小バージョンをインストールします。
シナリオ 2: セキュリティ以外の更新が含まれる
-
適用先: カスタムパッチベースライン。
-
[セキュリティ以外の更新を含める] チェックボックス: オン。
-
適用されるパッチ:
updateinfo.xmlにあるパッチと、updateinfo.xmlにないパッチが適用されます (セキュリティ更新とセキュリティ以外の更新)。 -
コマンド: RHEL 7 の場合、このワークフローに対する yum コマンドは次のとおりです。
sudo yum update --security --bugfix -yAlmaLinux 8 および 9、RHEL 8 および 9、および Rocky Linux 8 および 9 の場合、このワークフローに相当する dnf コマンドは次のとおりです。
sudo dnf update --security --bugfix -y
注記
yumまたはdnfコマンドを Patch Manager の外で実行すると、古くなったパッケージに代わる新しいパッケージが別の名前でインストールされます。ただし、同等の Patch Manager オペレーションではインストールされません。 -
-
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
注記
Linux ディストリビューションのパッケージマネージャーのデフォルト設定では、エラーなしでアクセスできないパッケージリポジトリをスキップするように設定されることがあります。このような場合、リポジトリから更新プログラムをインストールせずに、関連するパッチ適用オペレーションは続行されて正常に終了されます。リポジトリの更新を実施するには、リポジトリ設定に
skip_if_unavailable=Falseを追加します。skip_if_availableオプションの詳細については、「パッチソースへの接続」を参照してください。 -
- SLES
-
SUSE Linux Enterprise Server (SLES) マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
複数のバージョンのパッチが承認されている場合は、最新バージョンが適用されます。
-
Zypper 更新 API は、承認済みパッチに適用されます。
-
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
-
- Ubuntu Server
-
Ubuntu Server マネージドノードの場合、パッチのインストール ワークフローは次のとおりです。
-
パッチのリストが https URL または Amazon Simple Storage Service (Amazon S3) パススタイルの URL を使用して、
AWS-RunPatchBaselineまたはAWS-RunPatchBaselineAssociationドキュメントのInstallOverrideListパラメータを使用して指定されている場合、リストされたパッチがインストールされ、手順 2〜7 はスキップされます。 -
更新が可能な場合、
python3-apt(Python ライブラリインターフェイスのlibapt) は最新バージョンにアップグレードされます。(このセキュリティ以外のパッケージは、[Include nonsecurity updates (セキュリティ以外の更新プログラムを含める)] オプションが選択されていなくてもアップグレードされます。) -
パッチベースラインの指定どおりに GlobalFilters を適用し、追加処理のために対象のパッケージのみを保持します。
-
パッチベースラインの指定どおりに ApprovalRules を適用します。各承認ルールは、承認されたとおりにパッケージを定義できます。
注記
Ubuntu Server の更新プログラムパッケージのリリース日は確定できないため、このオペティングシステムでは自動承認オプションがサポートされていません。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [Include nonsecurity updates (セキュリティ以外の更新を含める)] チェックボックスがオンになっているかどうかによっても影響を受けます。
セキュリティ以外の更新が除外されている場合、暗黙のルールを適用してセキュリティリポのアップグレードを持つパッケージのみを選択します。選択対象の各パッケージは、セキュリティリポに属する適切なバージョン (通常は最新バージョン) のパッケージであることが必要です。
セキュリティ以外の更新が含まれている場合は、他のリポジトリからのパッチも考慮されます。
ただし、承認ルールは、パッチベースラインの作成時または最終更新時に [セキュリティ以外の更新を含める] チェックボックスがオンになっているかどうかによっても影響を受けます。
注記
Ubuntu Server の各バージョンのパッチ候補バージョンは、次のように、そのバージョンの関連リポジトリに含まれるパッチに限定されます。
-
Ubuntu Server 16.04 LTS:
xenial-security -
Ubuntu Server18.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)
-
-
パッチベースラインの指定どおりに ApprovedPatches を適用します。承認済みパッチについては、GlobalFilters によって破棄されている場合や、ApprovalRules に指定された承認ルールから承認が付与されていない場合でも、更新が承認されます。
-
パッチベースラインの指定どおりに RejectedPatches を適用します。承認済みパッチのリストから削除された拒否済みパッチは、適用されません。
-
APT ライブラリを使用してパッケージをアップグレードします。
注記
Patch Manager では、APT
Pin-Priorityオプションを使用したパッケージへの優先順位割り当てはサポートされていません。Patch Manager は、有効なすべてのリポジトリから利用可能な更新を集約し、インストールされた各パッケージのベースラインに一致する最新の更新を選択します。 -
更新がインストールされると、マネージドノードは再起動されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。)
-
- Windows Server
-
Windows Server マネージドノードに対してパッチ適用オペレーションを実行すると、このノードは該当するパッチベースラインのスナップショットを Systems Manager にリクエストします。このスナップショットには、デプロイ用に承認されたすべての使用可能な更新がパッチベースラインとして含まれています。この更新のリストが Windows Update API に送信されて、マネージドノードに適用できる更新が確認され、必要に応じてインストールされます。Windows では、KB の使用可能な最新バージョンのみをインストールできます。Patch Manager は、KB の最新バージョンまたは以前のバージョンの KB が、適用されたパッチベースラインと一致する場合に KB の最新バージョンをインストールします。更新のインストール後に、マネージドノードが必要な回数だけ再起動されて、すべての必要なパッチが適用されます。(例外:
RebootOptionパラメータがAWS-RunPatchBaselineドキュメントのNoRebootで設定されている場合、パッチマネージャーの Patch Manager 実行後にマネージドノードは再起動されません。詳細については、「パラメータ名: RebootOption」を参照してください。) パッチ適用オペレーションの概要は、Run Command リクエストの出力で確認できます。詳細なログは、マネージドノードの%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logsフォルダにあります。KB のダウンロードとインストールには Windows Update API が使用されるため、Windows Update のすべてのグループポリシー設定が適用されます。Patch Manager の使用には、グループポリシー 設定は必須ではありませんが、ユーザー定義のすべての設定 (マネージドノードのターゲットを Windows Server Update Services (WSUS) サーバーにするなど) が適用されます。
注記
Windows では、Patch Managerは Windows Update API を使用して KB のダウンロードとインストールを行うため、デフォルトではすべての KB が Microsoft の Windows Update サイトからダウンロードされます。そのため、マネージドノードは Microsoft Windows Update サイトに接続できる必要があります。そうでないと、パッチ適用は失敗します。別の方法として、WSUS サーバーを KB レポジトリとして設定し、グループポリシーを使用して WSUS サーバーをターゲットとするようマネージドノードを設定できます。
Patch Manager は、承認済みパッチリストまたは拒否済みパッチリストがベースライン設定に含まれている場合など、Windows Server のカスタムパッチベースラインを作成するときに KB ID を参照することがあります。Patch Manager がインストールするのは、KB ID が Microsoft Windows Update または WSUS サーバーに割り当てられている更新のみです。KB ID がない更新は、パッチ適用のオペレーションに含まれません。
カスタムパッチベースラインの作成に関する詳細は、以下のトピックを参照してください。