よくある質問

このセクションの質問と回答は、Patch for Red Hat Enterprise Linux をよりよく理解するために役立ちます。

「ダウンロード・プラグインの管理」ダッシュボードはデータを反映していません。どうすればよいでしょう。

この問題のトラブルシューティングのために実施できる手順を以下に示します。

• 最新の「パッチ・サポート」サイトを収集します。
• 「パッチ・サポート」サイトから使用できる「ダウンロード・プラグインのバージョン」分析をアクティブにします。
• BigFix コンソール・キャッシュをクリアします。

置き換えられるパッチとは何ですか?

置き換えられる Fixlet とは、古いパッケージが含まれた Fixlet のことです。Fixlet が置き換えられると、新しいバージョンのパッケージが含まれた新規 Fixlet が存在するようになります。新規 Fixlet の ID は、置き換えられた Fixlet の説明で確認できます。

適用ログはエンドポイントのどこにありますか?

ログは、クライアント・フォルダーの下の EDRDeployData フォルダーにあります: /var/opt/BESClient/EDRDeployData。

「Linux RPM パッチ」サイトの「エンドポイントの依存解決 - 適用結果」を使用して、BigFix コンソール上で適用ログを表示できます。

最新のプラグインが登録されていてもダウンロードに失敗するのはなぜですか?

パッチ番号 8.0.627 には、動的ダウンロード用のホワイトリストを認識しないという既知の問題があります。この問題を解決するには、最新バージョンの BigFix にアップグレードしてください。ご使用のサーバー上のダウンロード・ホワイトリストに以下の行を追加することもできます。

• RHSMProtocol://.*
• http://software.bigfix.com/download/bes/dep/rhel/.*
• http://software.bigfix.com/download/bes/dep/pkgdeps/.*
• http://software.bigfix.com/download/bes/yum/rhel/6Servers390x/.*

アクションにより「EDR プラグインのエラー。無効な初期インストール・パッケージのセット (EDR Plug-in failure, Invalid set of initially installed packages)」というレポートが返された場合には、何を行う必要がありますか?

システムに存在するパッケージ間に、少なくとも 1 つの競合があります。競合するパッケージが削除されるまで、リゾルバーは機能しません。

適用の結果の中に XML があるのはなぜですか?

その XML は、リゾルバーがソリューションの生成に失敗したときに生成するリゾルバーのエラー出力からのものです。「errorType」タグの説明を見ることにより、失敗した理由についてよりよく理解することができます。

適用の結果に「依存関係リゾルバーのエラー。ソリューションがありません。(Dependency Resolver Failure, noSolution)」と表示された場合はどうすればよいですか?

リゾルバーがソリューションが存在しないことを検出すると、システムはすべての対象および依存関係をインストールできません。これは、これらのファイルとエンドポイント・ファイルとの間の競合が原因で発生します。

新しい依存関係グラフはどのくらいの頻度で生成されますか?

依存関係グラフは、毎週の月曜日、水曜日、および金曜日に生成されます。

アクションがインストール失敗のレポートを返した場合はどのようなステップを実行する必要がありますか?

競合がベンダー提供のパッケージによって発生したのかどうかを調べてください。インストールを実行するには、それらのパッケージを削除する必要があります。

リゾルバー機能が優先順位の高いパッケージよりも優先順位の低いパッケージを選択するのはなぜですか?

リゾルバーは、優先されるパッケージを選択することによって別のパッケージとの間で競合が生じる場合、そのパッケージを選択しません。したがって、優先順位の低いパッケージが選択される可能性があります。

RHEL 3 および 4 における依存関係の問題、およびその依存関係が適用に与える影響について教えてください。

本書のセクション『依存関係の問題』を参照してください。

ダウンロード・プラグインが正しく登録されていることは、どのように確認すればよいですか?

ダウンロード・プラグインが正しく登録されていることを確認するアクション・タスクと共に Fixlet を実行します。パッチのダウンロードが成功したことを確認します。成功していない場合には、ダウンロード・プラグインを登録解除してから再登録することが必要な場合があります。

ダウンロード・プラグインを登録する方法を教えてください。ダウンロード・プラグインの登録タスクまたは「ダウンロード・プラグインの管理」ダッシュボードのどちらを使用すればよいですか。

ダウンロード・プラグインを登録するには、「Patching Support」サイトの「ダウンロード・プラグインの管理」ダッシュボードを使用する必要があります。既存のダウンロード・プラグインの登録タスクは使用しないでください。プラグインの登録について詳しくは、『RHSM ダウンロード・プラグインの登録』を参照してください。

注: ダウンロード・プラグインの登録解除、構成、およびアップグレードを行う際にも、「ダウンロード・プラグインの管理」ダッシュボードを使用する必要があります。既存のダウンロード・プラグインの登録解除および編集タスクは使用しないでください。ダッシュボードについて詳しくは、BigFix インフォメーション・センターの「ダウンロード・プラグインの管理」ダッシュボードに関するトピックを参照してください。

パスワードが難読化されるはずですが、平文のままです。なぜでしょうか?

ご使用のダウンロード・プラグインのバージョンが 2.1 より前である場合、資格情報を平文で保管する古いバージョンのダウンロード・プラグインをまだ使用していることになります。資格情報を暗号化するには、「パッチ・サポート」サイトの「ダウンロード・プラグインの管理」ダッシュボードを使用して、ダウンロード・プラグインをバージョン 2.1 以降にアップグレードしてください。

どのバージョンの YUM ネイティブ・ツールを使用する必要がありますか?

RHEL ネイティブ・ツール用パッチ・サイトでは、バージョン 3.2.19-18 以降が必要です。

アクションが失敗し、ログには YUM 固有のエラーが表示されています。失敗したアクションはどのようにトラブルシューティングすればよいですか?

YUM および関連するエラーについて詳しくは、http://yum.baseurl.org の YUM の資料および Red Hat Customer Portal の YUM 関連の記事を参照してください。

RHEL カスタム・リポジトリー・ダッシュボードを使用するには、どのバージョンの YUM が必要ですか?

最小でも 3.2.19-18 の YUM バージョンが必要です。

RHEL カスタム・リポジトリー・ダッシュボードではどの Red Hat Enterprise Linux がサポートされますか?

このダッシュボードは、Red Hat Enterprise Linux バージョン 5 および 6 をサポートします。

「RHEL カスタム・リポジトリー」ダッシュボードをサポートするのはどのバージョンの BigFix サーバーですか?

「RHEL カスタム・リポジトリー」ダッシュボードは、バージョン 8.2 以降の BigFix をサポートします。

パッチを適用するときには、既存の方法とカスタム・リポジトリーを介する方法のどちらを使用すればよいですか? この 2 つの方式は共存できますか?

この 2 つの方式は併存できます。ただし、単一クライアントのパッチを適用する場合は、ネイティブ・ツールとカスタム・リポジトリー方式のどちらを使用するのか選択する必要があります。

RHEL カスタム・リポジトリー・ダッシュボードを使用した場合、依存関係はどのようにして解決されますか?

YUM は、メタデータを使用して依存関係を解決し、必要なパッケージを認識します。

ソフトウェアのインストールでカスタム・リポジトリーを使用できますか?

はい、ソフトウェアのインストールでカスタム・リポジトリーを使用できます。ソフトウェアのインストールにカスタム・リポジトリーを使用するには、以下のステップに従ってください。

1. クライアントがカスタム・リポジトリー・ダッシュボードを介して登録されていることを確認します。
2. アクション yum install<space><package name> を実行して、カスタム・サイトで Fixlet を作成します。適切な関連度または成功条件 (つまり Fixlet がそのクライアントまたはエンドポイントに対してアクションを実行すべきかどうか) を確実に設定します。Fixlet の作成について詳しくは、「コンソール・オペレーター・ガイド」を参照してください。

注: リポジトリーとサテライトが確実に更新されるようにすることは重要です。パッケージを使用できないと、アクションが失敗する可能性があります。

サテライトの場合: ダッシュボードがサポートするのは、ブートストラップ・スクリプトと「 rhnreg_ks」コマンドの実行のみです。エンドポイントをサテライト・サーバーにサブスクライブできます。エンドポイントが使用するチャネルは、サテライト・サーバーを介して構成する必要があります。

リポジトリーの登録中にアクティベーション・キーの入力を求めるプロンプトが出されました。このアクティベーション・キーはどこで入手できますか?

Red Hat Network Satellite 管理者がアクティベーション・キーを作成して管理します。アクティベーション・キーについて詳しくは、https://access.redhat.com/site/documentation/en-US/ を参照してください。

以前に構成したリポジトリーを再び構成できますか?

はい、以前に構成したことのあるリポジトリーを再び構成できます。

ログによって、自分がログでサテライトまたはリポジトリーに対する通常の YUM プロセスを使用しているかどうか分かりますか?

はい、ログには、サテライトまたはリポジトリー内の通常の YUM プロセスが使用されているかどうかが記録されます。

リポジトリーの登録とリポジトリーのインポートの違いは何ですか?

ダッシュボードの「リポジトリー」リストに含まれていない既存のリポジトリーがある場合は、インポート機能を使用します。「リポジトリー」リストにリポジトリーがすでにある場合でも、そのリポジトリーをエンドポイントにリンクする必要がある場合は、登録機能を使用します。

リポジトリーにパッケージが含まれていないとどうなりますか?

パッケージが見つからない場合、Fixlet は失敗します。YUM 出力のログが記録される EDR_DeploymentResult.txt からトラブルシューティングを実行できます。

カスタム・リポジトリー・ソリューションで問題が発生するとどうなりますか?

カスタム・リポジトリーの解決で問題が発生した場合、ユーザーは標準の BES サーバー・ソリューションに戻すことができます。ユーザーは、「カスタム・リポジトリー・サポートの無効化 - Red Hat Enterprise Linux」と呼ばれるタスクを実行することができます。

RHEL カスタム・リポジトリー管理ダッシュボードの「エンドポイント」タブで、ウィンドウ下部にリストされているリポジトリーは順番に使用されますか?

「エンドポイント」タブにリストされるリポジトリーに順番はありません。YUM がリポジトリーを照会すると、最初にフェッチ照会を受けたリポジトリーが、パッケージとその依存関係を含めて応答を返します。

RHEL カスタム・リポジトリー管理ダッシュボードにより、製造元のサイトのミラーではないカスタム・リポジトリーを介してパッチが適用されました。適用が失敗し、EDR ログに rpm ファイルを開けなかったことが記録されています。どうすればよいでしょう。

ベンダー・サイトのミラーではないカスタム・リポジトリーが使用された場合は、インストールの一環としてデフォルトの gpgcheck が実行され、gpg シグニチャー・ファイルが含まれない可能性があります。rpm ファイルに対して認証チェックが行われず、インストールが失敗する可能性があります。この問題を解決するには、RHEL カスタム・リポジトリー管理ダッシュボードでエンドポイントを登録するときに、「追加フィールド (Additional Fields)」に「gpgcheck=0」を追加したことを確認してください。

BigFix では Red Hat サテライト・サーバーがサポートされますか?

BigFix では Red Hat サテライト・サーバーをサポートせず、Fixlet も提供しません。Red Hat Enterprise Linux 用の BigFix サポートの範囲について詳しくは、https://help.hcl-software.com/bigfix/9.5/patch/Patch/Patch_RH/c_supported_platforms.html を参照してください。

BigFix には、カスタム・リポジトリー機能を使用して、既存のサテライト・リポジトリーをエンドポイントに登録および接続する機能があります。カスタム・リポジトリーについて詳しくは、https://help.hcl-software.com/bigfix/9.5/patch/Patch/Patch_RH/c_manage_custom_repositories.html を参照してください。

「タスク: YUM を使用したパッケージのインストール (Task: Install packages by using YUM)」を使用して複数のパッケージをインストールできますか?

はい、このタスクで複数のパッケージをインストールできます。各 rpm 名をスペースで区切ってください。

Fixlet をデプロイしようとしていますが、次の警告メッセージを受け取りました: 警告: 完了するために 2 秒を超えるプリフェッチ・プラグイン・コマンドを実行してください。4 秒かかりました。(It took 4 seconds.)ActionLogMessage: (action:1343) 必要な引数のサイズ不足 = (Missing required argument size=)エラーの原因は何ですか? これを解消するにはどうしたらよいですか?

EDR サイトおよびネイティブ・サイトにサブスクライブしているユーザーもこのメッセージを受け取ることがあります。適用の失敗をトラブルシューティングするには、以下のアクションを試行してください。

• gpg 鍵がインストールされて有効になっているかどうかを確認します。
• RHEL 用パッチ・サイトの最新バージョンを収集します。
• /var/opt/BESClient/yum folder を削除して、アクションを再実行してください。
• sha1 が EDR_PackageSpec ファイルに存在するかどうかを確認します。EDR_PackageSpec ファイルは、RHEL 7 フォルダーの /var/opt/BESClient/_BESDATA/Patches にあります。
• bzip2 が環境内で使用可能かどうかを確認します。そうでない場合は、bzip2 をインストールします。

「YUM トランザクション履歴」ダッシュボードがサポートする YUM のバージョンは何ですか?

最小でも 3.2.28 の YUM バージョンが必要です。

「YUM トランザクション履歴」ダッシュボードがサポートされる Red Hat Enterprise Linux のバージョンはどれですか?

ダッシュボードは Red Hat Enterprise Linux 6 以降のバージョンをサポートしています。

「YUM トランザクション履歴」ダッシュボードの「ロールバック」と「元に戻す」の違いは何ですか?

ロールバック・コマンドは、指定したトランザクションの時点までのトランザクションをすべて取り消します。元に戻すコマンドは、選択したトランザクションのみを元に戻します。

YUM トランザクション履歴ログと YUM ログ分析の違いは何ですか?

Patch Management for Red Hat Enterprise Linux は、「YUM トランザクション履歴」ダッシュボードで実行されるアクションの結果を記録する YUM トランザクション履歴ログを生成します。ログは、/var/opt/BESClient/EDRDeployData/yum_history.log にあります。

YUM ログは、YUM がデフォルトで /var/log/yum.log に生成する正式なログです。デフォルトの場所を変更するには、/etc/yum.conf のログ・ファイルの設定を変更します。

「YUM トランザクション履歴」ダッシュボードに表示されるのは yum -update all だけですか?

yum -update all だけでなく、ダッシュボードの「コマンド・ライン」列に、以下のインストール・コマンドなどのさまざまなトランザクションが表示されます。

• install bzip2
• install net-tools
• install vim enhance
• install wget

YUM コマンドについて詳しくは、Red Hat Enterprise Linux の Web サイト (https://access.redhat.com/) を参照してください。

BigFix クライアントが YUM リポジトリーまたはサテライト・サーバーを使用するように構成している場合、「YUM トランザクション履歴」ダッシュボードはどのように動作しますか?

BigFix client が YUM リポジトリーまたはサテライト・サーバーを使用するように構成している場合、「YUM トランザクション履歴」ダッシュボードが適用環境に悪影響を及ぼすことはありません。ローカルの YUM リポジトリーまたはサテライト・サーバーを既に使用している場合は、ロールバック用のパッケージを指定する方が簡単な場合があります。

RHSM ダウンロード・プラグインを使用する予定ですが、Fixlet を適用する前にいくつかのタスクを適用することが強く推奨されていることが分かりました。これらのタスクの適用が必要になるのはなぜですか?

ユーザーは、GPG キーの問題およびプリフェッチ・プラグインの実行における問題を回避するために、Fixlet を適用する前に所定のタスクを適用することが強く推奨されています。

Red Hat では GPG キーを使用する必要があります。以下の 2 つのタスクは GPG キーをエンドポイントにインポートします。

• RPM-GPG-KEY-redhat-release のインポート - RHEL 6 (Import RPM-GPG-KEY-redhat-release - RHEL 6) (「RHEL6 ネイティブ・ツール向けパッチ (Patches for RHEL6 Native Tools)」サイトから入手)
• RPM-GPG-KEY-redhat-release のインポート - RHEL 7 (Import RPM-GPG-KEY-redhat-release - RHEL 7) (「RHEL 7 向けパッチ (Patches for RHEL 7)」サイトから入手)

プリフェッチ・プラグインの実行におけるエラーを回避するには、「パッチ・サポート」サイトにある「プリフェッチ・プラグインのタイムアウトの変更」タスクを使用します。このエラーは、プリフェッチ・タイムアウト設定が短いために発生します。この問題を解決するには、このタスクを実行して、タイムアウトを 30 分に変更します。

タスクを実行してタイムアウト設定を変更した後に、「トラブルシューティング: RHEL/SUSE での BES クライアントの再始動 (TROUBLESHOOTING: Restart BES Client on RHEL/SUSE)」タスクを使用して BES クライアントを再始動します。このタスクは BES サポート・サイトにあります。

EDR ログに、何もインストールできないため、最新のカーネルを使用しているかどうか確認するよう警告するメッセージが表示され、Fixlet のインストールが失敗しました。この場合の対処方法を教えてください。

このメッセージは、カーネル・パッケージをデプロイする Fixlet の場合にのみ表示されます。エンドポイントにターゲット・カーネル・パッケージがインストールされていない場合、またはエンドポイントのアクティブ・カーネルがターゲット・カーネル・パッケージより低いバージョンである場合、カーネル Fixlet が関連状態になります。エンドポイントに最新のカーネルがインストールされているもののアクティブに使用していない場合も、カーネルの脆弱性の対象と見なされます。

To remediate the issue, restart the endpoint and ensure it is using the latest kernel available.