翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
代替パッチソースリポジトリを指定する方法 (Linux)
マネージドノードに設定されているデフォルトのリポジトリをパッチ適用オペレーションに使用すると、 の一機能Patch Managerである はセキュリティ関連のパッチを AWS Systems 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 LinuxCentOS など、YUM ベースのディストリビューション用の代替パッチリポジトリを指定する場合、パッチ適用動作は、リポジトリに完全で正しい形式のupdateinfo.xmlファイル形式で更新マニフェストが含まれているかどうかによって異なります。このファイルは、リリース日、分類、および各種パッケージの重要度を指定します。次のいずれかのパッチ動作に影響を与えます。
-
Classification や Severity でフィルターしても、それらが
updateinfo.xmlで指定されていない場合、そのパッケージはフィルターには含まれません。つまり、updateinfo.xmlファイルのないパッケージはパッチ適用に含まれません。 -
でフィルタリングしてもApprovalAfterDays、パッケージのリリース日が Unix エポック形式でない場合 (またはリリース日が指定されていない場合）、パッケージはフィルターに含まれません。
-
[パッチベースラインの作成] ページで [セキュリティ以外の更新を含める] チェックボックスをオンにした場合、例外が発生します。この場合、
updateinfo.xmlファイルを持たないパッケージ (または、このファイルが含まれていても、分類、重要度、日付について適切にフォーマットされた値が指定されていないパッケージ) は、事前にフィルタリングされたパッチのリストに含まれます。(インストールするには、パッチベースラインルールの他の要件を満たしていなければなりません。)
代替パッチソースリポジトリの使用例
例 1 - Ubuntu Server のセキュリティに関連しない更新プログラム
既に Patch Managerを使用して、 AWSが提供する事前定義されたパッチベースライン を使用してUbuntu Server、マネージドノードのフリートにセキュリティパッチをインストールしていますAWS-UbuntuDefaultPatchBaseline。このデフォルトに基づいて新しいパッチベースラインを作成できますが、デフォルトのディストリビューションに含まれるセキュリティに関連しない更新プログラムもインストールするように、承認ルールで指定できます。このパッチベースラインがノードに対して実行されると、セキュリティに関連する問題と関連しない問題の両方に対するパッチが適用されます。また、ベースラインに対して指定したパッチ例外で、セキュリティに関連しないパッチを承認することもできます。
例 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 オプション付きでそのドキュメントを再実行することで、アプリケーションを更新できます。
