よくある質問

BigFix Patch for CentOS をよりよく理解するために、以下の質問と回答を確認してください。

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

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

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

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

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

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

ログは、EDRDeployData にあるクライアント・フォルダー内の /var/opt/BESClient/EDRDeployData という名前のフォルダーにあります。

アクションがダウンロードの失敗として報告されるのはなぜですか?

ダウンロード・プラグインが最新バージョンに更新されており、正しい資格情報で登録されていることを確認してください。

アクションがインストール失敗のレポートを返した場合はどうすればよいですか?

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

/var ディレクトリーが noexec としてマウントされているエンドポイントの Fixlet にパッチを適用できません。どうすればよいでしょう。

回避策については、/var を noexec としてマウントした場合のエラーを参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ログによって、リポジトリーに対する通常の YUM プロセスを使用しているかどうか分かりますか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Patch Management for CentOS 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 クライアントが YUM リポジトリーを使用するように構成している場合でも、「YUM トランザクション履歴」ダッシュボードが適用環境に悪影響を及ぼすことはありません。ローカルの YUM リポジトリーを既に使用している場合は、ロールバック用のパッケージを指定する方が簡単な場合があります。

クライアント・ログに、Fixlet が正常に完了しないプリフェッチ・プラグイン・エラーが表示されています。エラーの原因は何でしょうか。どうすればよいでしょう。

エンドポイントで実行されていた ActionScript がブラックリストに登録され、プリフェッチ・プラグインの問題が発生した可能性があります。

この問題を解決するには、BigFix クライアントを再始動してブラックリストをクリアしてください。スクリプトがブラックリストに登録されないように、_BESClient_ActionManager_PrefetchPlugInTimeoutSeconds クライアント構成設定に、パッチを処理するための十分な時間を設定してください。詳しくは、「プリフェッチ・プラグインのエラー」を参照してください。

CentOS ダウンロード・プラグイン R2 のログ・レベルを設定することはできますか?

必要な情報のレベルに応じたログ・メッセージを生成するように、ダウンロード・プラグインを設定することができます。

ロギング・レベルは、CentOS プラグイン R2 がログ・ファイルに書き込む詳細情報の量を決定します。%PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\CentOSR2Protocol\plugin.ini ファイルでロギング・レベルを設定します。

注: ロギング・レベルの値では、大/小文字が区別されます。

以下のロギング・レベルは、ログに記録される情報量が少ない順にリストされています。

ERROR

ダウンロード・プラグインの実行に関連するエラーが出力されます。このようなエラーは、致命的エラーが発生する直前であることを示している場合があります。

WARNING

ダウンロードの失敗と、失敗の理由に関する情報が出力されます。

INFO

ダウンロードの進行状況とダウンロードの成功に関する一般情報が、最小限のトレース情報とともに出力されます。

DEBUG

問題のトラブルシューティングに使用される詳細情報が出力されます。これは、使用可能なレベルの中で最も詳細なレベルです。

注: ロギング・レベルを DEBUG に設定すると、ログに記録する情報の量が増えるため、パフォーマンスに影響が及ぶ可能性があります。ロギング・レベルを DEBUG に上げるのは、問題を調査するときだけにとどめる必要があります。

CentOS ダウンロード・プラグイン R2 のログはどこにありますか? 使用できるログ・レベルにはどのようなものがありますか?

ロギングは plugin.ini ファイルによって制御されます。このファイルは、ダウンロード・プラグインの実行可能プログラムと同じ場所にあります。デフォルトでは、Windows システム上の %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\CentOSR2Protocol にあります。Linux システムの場合は、/var/opt/BESServer/DownloadPlugins/CentOSR2Protocol にあります。ログ・ファイルは 1 日ごとに循環して使用されます。つまり、新規ログ・ファイルが作成されると、古いログ・ファイルの名前がその作成開始日に変更されます。

新バージョンのダウンロード・プラグインがインストールされると、CentOS ダウンロード・プラグイン R2 の構成ファイル (plugin.ini) は上書きされますか?

いいえ。構成ファイルが上書きされることはありません。構成ファイルが上書きされるのは、ダウンロード・プラグインが再構成されたときだけです。

CentOS ダウンロード・プラグイン R2 の登録後に、プロキシーを再構成することはできますか?

はい。「ダウンロード・プラグインの管理」ダッシュボードからダウンロード・プラグインを構成することで、プロキシー設定を更新できます。

DLCentOSRepoList.json ファイルを編集してリポジトリーを追加するとどうなりますか?

BigFix が「パッチ・サポート (Patching Support)」サイトを更新すると、このファイルが上書きされるため、行った変更はこのときに削除されます。

拡張製品のサブスクリプションがあります。各製品に割り当てられたリポジトリーにアクセスするように CentOS ダウンロード・プラグイン R2 を構成できますか?

はい、できます。詳しくは、「CentOS ダウンロード・プラグイン R2 の拡張」を参照してください。

拡張リポジトリー・リスト・ファイルはどこに保存すればよいですか?

ダウンロード・プラグインがアクセスできる場所であれば、どこに保管しても構いません。BigFix サーバーがその場所に対するアクセス権を保持していることを確認する必要があります。

CentOS プラグイン R2 にアップグレードした後、どのパッケージもインストールできなくなりました。すべてのタスクは、以下の行になります。「Failed add prefetch item {concatenation " ; " of lines of file (parameter "EDR_PkgRequest")}」。何が問題なのでしょうか?

BigFix 拡張セキュリティー・オプション -requireSHA256Downloads または BigFix 管理ツールの「SHA-256 ダウンロードが必要」オプションが有効になっている可能性があります。このオプションは、すべてのダウンロード検証で SHA-256 アルゴリズムのみを使用するように構成します。リポジトリー内には、CentOS ダウンロード・プラグイン R2 が使用するパッケージの SHA-256 値が含まれていない、特定の CentOS リポジトリー・メタデータがあるため、このプラグインは失敗する可能性があります。

パッチを正常にデプロイするために、「SHA-256 ダウンロードが必要」オプションを無効にすることを検討してください。パッケージの GPG シグニチャーを使用して別の層の検査および検証が実行されるため、セキュリティーおよびパッケージの整合性が低下することはありません。ダウンロード・オプションについて詳しくは、BigFix Platform インストール・ガイド (https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Installation/c_security_settings.html) を参照してください。

拡張リポジトリー・リストだけを使用するように CentOS ダウンロード・プラグイン R2 を構成できますか?

はい、onlyUseExtendedRepoListFile の plugin.ini フラグを「yes」に設定します。

ベースライン内の複数の Fixlet を適用するときに、破損した依存関係をスキップして、残りのパッケージのインストールを続行することはできますか?

「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクは、依存関係が破損したパッケージを可能な限りスキップします。ただし、CentOS の依存関係に関する問題が含まれるパッケージはスキップできません。パッケージがスキップされないもう 1 つのシナリオは、インストール中に依存関係エラーが発生した場合です。これは、次のエラー・メッセージで示されます。File conflicts happen when two packages attempt to install files with the same name but different contents。このような場合は、インストールが取り消され、エンドポイントにパッチがインストールされません。

複数パッケージのベースラインのインストール方式を使用したときに障害が発生する原因として考えられるものは何ですか?

Fixlet のインストールに失敗した理由は以下の可能性があります。

• カスタム・サイトに、「複数パッケージのベースラインのインストール (multiple-package baseline installation)」タスクを同時に実行するベースラインが複数存在していた。
• 複数の Fixlet で、同一パッケージの複数のバージョンを更新するよう要求された。
• 複数の Fixlet で、同一のパッケージ依存関係を更新するよう要求された。
• ベースラインが複数パッケージのインストール方式を実行した直後に Fixlet が適用された。複数パッケージのインストールで、すべての YUM トランザクションを完了し、エンドポイントのステータスを更新するための十分な時間が取られなかった。
• YUM ツールにパッチが適用されていないのに、ベースラインに CentOS リリース・パッケージが含まれている。
• 「複数パッケージのベースラインのインストール機能を有効化 (Enable the Multiple-Package Baseline Installation feature)」タスクは、残りのコンテンツと同じベースライン内にある必要があります。このタスクは、パッチ Fixlet および複数パッケージのインストール・タスクより前に追加する必要があります。
• 複数パッケージのベースラインのインストール機能は、有効化タスクとインストール・タスクの両方が同じベースライン内に存在する場合にのみ動作します。詳しくは、「ベースラインでの複数パッケージのインストール」を参照してください。
• 以下のクリーンアップ・タスクのいずれかの後に、「複数パッケージのベースラインのインストール機能を有効にする」タスクを追加する必要があります。複数パッケージのベースラインのインストール用に CentOS 6 パッケージ・リスト・ファイルを削除 (Delete CentOS 6 Package List File for Multiple-Package Baseline Installation) またはトラブルシューティング: CentOS 7 パッチ・デプロイメント・ログ - クリーンアップ (TROUBLESHOOTING:CentOS 7 Patching Deployment Logs - Cleanup)。
• 正しい CentOS ディストリビューション、オペレーティング・システム・バージョン、サービス・パック・レベル、およびアーキテクチャーを使用するインストール・タスクをベースラインの最後に追加する必要があります。

エンドポイントが隔離された環境にあります。これらのエンドポイントにパッチを適用するには、BigFix をどのように構成すればよいですか?

隔離された環境の場合は、エンドポイントにパッチを適用するために必要なパッケージをホストするサポート対象 CentOS リポジトリーに対して、必ずミラーリングを行ってください。これを行うには、CentOS ダウンロード・キャッシャー R2 を使用して、BigFix サーバーからアクセスできる場所にローカル・リポジトリーを作成します。この場所は、ローカル・キャッシュと呼ばれます。

注: 依存関係の解決時に問題が起こらないように、ローカル・キャッシュには必要なリポジトリーがすべて含まれている必要があります

適用時にファイルをダウンロードする際にローカル・キャッシュを使用するには、ダウンロード・プラグインの構成ファイル plugin.ini を構成します。以下の手順に従ってください。

1. ローカル・キャッシュの構成 localCache を、ダウンロード・キャッシャー・ツールを使用してダウンロードしたファイルの場所に設定します。
   注: この場所は、BigFix サーバーからアクセス可能でなければなりません。
2. ダウンロード・キャッシュからのファイルのみをダウンロードし、ベンダーのサイトからはダウンロードしないよう localCacheOnly フラグを yes に設定します。

「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクを使用してベースラインを実行しました。そのベースラインで失敗した Fixlet のリストを確認するには、どうすればよいですか?

「アクション情報の表示」ダイアログを使用すると、ベースライン適用の全体的な進行状況をモニターすることや、各サブアクションの詳細なステータスを確認することができます。

このダイアログにアクセスするには、以下の手順を実行します。

1. ナビゲーション・ツリーで「アクション」アイコンをクリックします。
2. アクション・リスト・パネルでアクションを選択します。
3. 作業域で「コンピューター」タブを選択します。
4. リストの任意のコンピューターを右クリックします。
5. コンテキスト・メニューから「アクション情報の表示」を選択するか、「編集」メニューから「アクション情報の表示」を選択します。

失敗した Fixlet に関する詳細情報を調べるには、ターゲット・エンドポイントの /var/opt/BESClient/__BESData/__Global/Logs にあるクライアント・ログを確認してください。

複数パッケージのインストール・タスクを使用して実行したベースラインが正常に完了しましたが、まだ関連するものとして表示されるのはなぜですか?

依存関係が破損したパッケージを、Fixlet コンポーネントがインストールできなかったことが原因と考えられます。「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクは、デフォルトでは、依存関係に問題がないパッケージがターゲット・エンドポイントに正常に適用されるように、破損した依存関係を無視します。

サポートされる CentOS リポジトリーにアクセスできるかどうかを確認する方法はありますか?

コマンド・ラインから --check-baserepos コマンドと --check-allrepos コマンドを使用して、サポート対象の CentOS リポジトリーにアクセスできるかどうかを確認できます。これらのコマンドについて詳しくは、CentOS ダウンロード・キャッシャー R2 の使用情報を参照してください。

BigFix がサポートする CentOS リポジトリーのリストについては、サポート・マトリックスを参照してください。

CentOS ダウンロード・キャッシャー R2 ツールを使用してリポジトリー・メタデータおよびパッケージをキャッシングするときに必要なスペースを調べる方法はありますか?

ストレージ・スペース所要量を調べるには、check-storagereq サブコマンドを使用します。

CentOS ダウンロード・キャッシャー R2 ツールを使用してリポジトリー・メタデータおよびパッケージをキャッシングするときに、スペースを節約するにはどうすればよいですか?

--sha1_download_dir を使用することで、スペース節約のベンチマークが設定されます。

--sha1_download_dir を使用することで、同じ CentOS バージョンの複数のリポジトリーをキャッシュする際のストレージ・サイズ、ダウンロード・サイズ、および時間が大幅に削減されます。これは、同じ CentOS バージョン (たとえば、centos-6.8-x64、centos-6.7-x64、centos-6.6-x64) のリポジトリー間で、多くのパッケージが重複しているためです。CentOS バージョン (たとえば、centos-6.8-x64、centos-7.1-x64) ごとにリポジトリーを 1 つだけキャッシュする場合、スペースは節約されません。

出力例を以下に示します。

Caching centos-6.8-x64, centos-6.7-x64, centos-6.6-x64 
(with --sha1_download_dir):
Total Repo Metadata and Packages will take up 28 GB of space 
instead of 37 GB (23% space saved)