代替パッチソースリポジトリを指定する方法 (Linux)
マネージドノードに設定されているデフォルトのリポジトリをパッチ オペレーションに使用すると、AWS Systems Manager の一機能である Patch Manager はセキュリティに関連するパッチをスキャンまたはインストールします。これがPatch Managerのデフォルトの動作です。Patch Manager がセキュリティ関連のパッチを選択してインストールする方法の詳細については、「セキュリティに関連するパッチの選択方法」を参照してください。
ただし、Linux システムでは、Patch Manager を使用して、セキュリティに関連しないパッチや、マネージドノードに設定されているデフォルトのリポジトリとは異なるソースリポジトリにあるパッチをインストールすることもできます。カスタムのパッチベースラインを作成するときは、代替パッチソースリポジトリを指定できます。各カスタムのパッチベースラインでは、サポートされている Linux オペレーティングシステムの最大 20 バージョンにパッチソース設定を指定できます。
例えば、Ubuntu Server フリートに Ubuntu Server 14.04 および Ubuntu Server 16.04 マネージドノードの両方が含まれているとします。この場合、同じカスタムパッチベースラインで、各バージョンの代替リポジトリを指定できます。バージョンごとに、名前、オペレーティングシステムのバージョンタイプ (製品)、リポジトリ設定を指定します。サポートされているオペレーティングシステムのすべてのバージョンに適用される 1 つの代替ソースリポジトリを指定することもできます。
注記
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
このオプションを使用するシナリオの例のリストについては、このトピックの後半の「代替パッチソースリポジトリの使用例」を参照してください。
デフォルトおよびカスタムのパッチベースラインについては、「事前定義されたパッチベースラインおよびカスタムパッチベースライン」を参照してください。
例: コンソールを使用する場合
Systems Manager コンソールでの作業時に代替パッチソースリポジトリを指定するには、[Create patch baseline (パッチベースラインの作成)] ページの [Patch sources (パッチソース)] セクションを使用します。[Patch sources (パッチソース)] のオプションの使用については、「Linux 用 カスタムパッチベースラインの作成」を参照してください。
例: AWS CLI を使用する場合
AWS Command Line Interface (AWS CLI) で --sources オプションを使用する例については、「異なる OS バージョン用にカスタムリポジトリのパッチベースラインを作成する」を参照してください。
代替リポジトリに関する重要な考慮事項
代替パッチリポジトリを使用してパッチ適用戦略を計画する際は、次の点に注意してください。
指定されたリポジトリのみがパッチ適用に使用されます
代替リポジトリの指定は、追加リポジトリの指定を意味しません。マネージドノードにデフォルトとして設定されているリポジトリ以外のリポジトリを選択することができます。ただし、更新を適用する場合は、代替のパッチソース設定の一部としてデフォルトのリポジトリも指定する必要があります。
例えば、Amazon Linux 2 マネージドノードでは、デフォルトのリポジトリは amzn2-core と amzn2extra-docker です。パッチ適用オペレーションで Extra Packages for Enterprise Linux (EPEL) リポジトリを含める必要がある場合は、3 つのリポジトリすべてを代替リポジトリとして指定する必要があります。
注記
マネージドノードの代替パッチ リポジトリを指定したカスタム パッチベースラインを実行しても、それらがオペレーティングシステム上の新しいデフォルト リポジトリになることはありません。パッチ適用オペレーションが完了すると、ノードのオペレーティングシステムのデフォルトとして以前に構成されたリポジトリーはデフォルトのままです。
YUM ベースのディストリビューションのパッチ適用の動作は、updateinfo.xml マニフェストに依存します
Amazon Linux 1、Amazon Linux 2、Red Hat Enterprise Linux、CentOS など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに更新マニフェストが完全で正しい形式の updateinfo.xml ファイルで含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。
-
Classification や Severity でフィルターしても、それらが
updateinfo.xmlで指定されていない場合、そのパッケージはフィルターには含まれません。つまり、updateinfo.xmlファイルのないパッケージはパッチ適用に含まれません。 -
ApprovalAfterDays でフィルターしても、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合)、そのパッケージはフィルターに含まれません。
-
[パッチベースラインの作成] ページで [セキュリティ以外の更新を含める] チェックボックスをオンにした場合、例外が発生します。この場合、
updateinfo.xmlファイルを持たないパッケージ (または、このファイルが含まれていても、分類、重要度、日付について適切にフォーマットされた値が指定されていないパッケージ) は、事前にフィルタリングされたパッチのリストに含まれます。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。)
代替パッチソースリポジトリの使用例
例 1 - Ubuntu Server のセキュリティに関連しない更新プログラム
AWS が提供する事前定義されたパッチベースライン AWS-UbuntuDefaultPatchBaseline を使用して、セキュリティパッチを Ubuntu Server マネージドノードのフリート上にインストールするために Patch Manager を既に使用しているとします。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがノードに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。
例 2 - Ubuntu Server の PPA (Personal Package Archives)
Ubuntu Server マネージドノードで、Personal Package Archives (PPA) for Ubuntu
例 3 - Amazon Linux の社内アプリケーション
Amazon Linux マネージドノードで、業界の規制コンプライアンスに必要なアプリケーションを実行する必要があるとします。ノードでこれらのアプリケーションのリポジトリを設定し、YUM を使用してアプリケーションをまずインストールしてから、この新しい企業リポジトリを含むように、新しいパッチベースラインを更新または作成できます。その後、Run Command を使用し、Scan オプション付きで AWS-RunPatchBaseline ドキュメントを実行することで、企業パッケージがインストールされたパッケージに含まれており、マネージドノードで最新かどうかを確認できます。最新でない場合は、Install オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。
