よくある質問

Patch Management for SUSE Linux™ Enterprise についてさらに理解するために、以下の質問と回答を確認してください。

「ダウンロード・プラグインの管理」ダッシュボードはデータを反映していません。どうすればよいでしょう。
この問題のトラブルシューティングのために実施できる手順を以下に示します。
  • 最新の「パッチ・サポート」サイトを収集します。
  • 「パッチ・サポート」サイトから使用できる「ダウンロード・プラグインのバージョン」分析をアクティブにします。
  • BigFix コンソール・キャッシュをクリアします。
置き換えられるパッチとは何ですか?
置き換えられる Fixlet とは、古いパッケージが含まれた Fixlet のことです。Fixlet® が置き換えられると、新しいバージョンのパッケージが含まれた新規 Fixlet® が存在するようになります。新規 Fixlet® Fixlet の ID は、置き換えられた Fixlet® の説明で確認できます。
欠落しているパッチについてはどのように処置すればよいですか。
HCL は、Novell Patch Finder およびサポート対象リポジトリーで使用可能なパッチを対象とした Fixlet コンテンツのみ提供しています。詳しくは、「サポートされる Novell リポジトリー」を参照してください。
CVE 番号を使用してセキュリティー・パッチをインストールする場合の Zypper の最低バージョンを教えてください。
バージョン 1.5.3-3.2 以上の Zypper を使用してください。
パッチを適用する前にクライアントにインストールする必要があるパッケージはどれですか?
エンドポイントにインストールする必要がある前提条件パッケージは zlib と zypper です。
アクションがインストール失敗のレポートを返した場合はどうすればよいですか?
競合がベンダー提供のパッケージによって発生したのかどうかを調べてください。インストールを実行するには、それらの競合を削除する必要があります。
Novell アカウントからロックアウトされてしまいました。どうすればよいでしょう。
アカウント・ロックアウトの理由の 1 つとして、資格情報が無効であることが考えられます。必ず、ダウンロード・プラグインの登録または構成時に、Novell から取得したミラー・サーバーの資格情報を使用するようにしてください。アカウント・ロックアウトはよくあることですが、一時的なものです。アカウントからロックアウトされた場合は、Novell サポートに連絡してください。
アクションがダウンロードの失敗として報告されるのはなぜですか?
必ずダウンロード・プラグインを最新バージョンに更新し、適切な資格情報を使用してそのプラグインを登録してください。
クライアント・ログに、Fixlet が正常に完了しないプリフェッチ・プラグイン・エラーが表示されています。エラーの原因は何でしょうか。どうすればよいでしょう。
エンドポイントで実行されていた ActionScript がブラックリストに登録され、プリフェッチ・プラグインの問題が発生した可能性があります。
この問題を解決するには、BigFix クライアントを再始動してブラックリストをクリアしてください。スクリプトがブラックリストに登録されないように、_BESClient_ActionManager_PrefetchPlugInTimeoutSeconds クライアント構成設定に、パッチを処理するための十分な時間を設定してください。詳しくは、『プリフェッチ・プラグインのエラー』を参照してください。
/var ディレクトリーが noexec としてマウントされているエンドポイントの Fixlet にパッチを適用できません。どうすればよいでしょう。
回避策については、/var を noexec としてマウントした場合のエラーを参照してください。
SCC ダウンロード・プラグインが正しく登録されているかどうかは、どのように確認すればよいですか?
ダウンロード・プラグインが正しく登録されているかどうかを確認するには、アクション・タスクと共に、Fixlet® を実行します。パッチのダウンロードが成功したことを確認します。成功していない場合には、ダウンロード・プラグインを登録解除してから再登録することが必要な場合があります。
ダウンロード・プラグインを登録する方法を教えてください。ダウンロード・プラグインの登録タスクまたは「ダウンロード・プラグインの管理」ダッシュボードのどちらを使用すればよいですか。
ダウンロード・プラグインを登録するには、「Patching Support」サイトの「ダウンロード・プラグインの管理」ダッシュボードを使用する必要があります。既存のダウンロード・プラグインの登録タスクは使用しないでください。プラグインの登録について詳しくは、SUSE ダウンロード・プラグインの登録またはSCC ダウンロード・プラグインの登録を参照してください。
注: ダウンロード・プラグインの登録解除や構成を行う際にも、「ダウンロード・プラグインの管理 (Manage Download Plug-in)」ダッシュボードを使用する必要があります。このダッシュボードについて詳しくは、HCL 知識ベースの BigFix に関するコンテンツの「ダウンロード・プラグインの管理 (Manage Download Plug-ins )」ダッシュボードに関するトピックを参照してください。
どのファイルを確認すれば、ミラー・サーバーが動作していない理由が分かりますか。
この問題の原因が不正な URL によるものか、またはミラー・サーバーの資格情報によるものかを確認するために、<BES Server directory>/DownloadPlugins/SCCProtocol にある plugin.ini ファイルを確認してください。
拡張リポジトリー・リストだけを使用するように SCC ダウンロード・プラグインを構成できますか?
はい、plugin.ini の onlyUseExtendedRepoListFile フラグを「はい」に設定します。
SCC プラグインにアップグレード後、どのパッケージもインストールできなくなりました。すべてのタスクは、以下の行になります。「Failed add prefetch item {concatenation " ; " of lines of file (parameter "EDR_PkgRequest")}」。何が問題なのでしょうか?
BigFix 拡張セキュリティー・オプション -requireSHA256Downloads または BigFix 管理ツールの「SHA-256 ダウンロードが必要」オプションが有効になっている可能性があります。このオプションは、すべてのダウンロード検証で SHA-256 アルゴリズムのみを使用するように構成します。SCC ダウンロード・プラグインは、プラグインで使用される、リポジトリー内のパッケージについての SHA-256 値が含まれていない特定の SUSE リポジトリー・メタデータが原因で失敗する場合があります。
パッチを正常にデプロイするために、「SHA-256 ダウンロードが必要」オプションを無効にすることを検討してください。パッケージの GPG シグニチャーを使用して別の層の検査および検証が実行されるため、セキュリティーおよびパッケージの整合性が低下することはありません。ダウンロード・オプションについて詳しくは、『BigFix プラットフォーム・インストール・ガイド』を参照してください。
拡張リポジトリー・リスト・ファイルはどこに保存すればよいですか?
ダウンロード・プラグインがアクセスできる場所であれば、どこに保管しても構いません。BigFix サーバーがその場所に対するアクセス権を保持していることを確認する必要があります。
SUSE Linux Enterprise Software Developer Kit 12 などの拡張製品に対するサブスクリプションを保持しています。SCC ダウンロード・プラグインが、その製品に割り当てられたリポジトリーにアクセスするように構成できますか?
はい、できます。詳しくは、『SCC ダウンロード・プラグインの拡張』を参照してください。
DLSuSERepoList.json ファイルを編集してリポジトリーを追加するとどうなりますか?
BigFix が「パッチ・サポート (Patching Support)」サイトを更新すると、このファイルが上書きされるため、行った変更はこのときに削除されます。
SCC ダウンロード・プラグインの登録後に、プロキシーを再構成することはできますか?
はい。「ダウンロード・プラグインの管理 (Manage Download Plug-ins)」ダッシュボードからダウンロード・プラグインを構成することで、プロキシー設定とミラー資格情報を更新できます。
新バージョンのダウンロード・プラグインがインストールされると、SCC ダウンロード・プラグインの構成ファイル (plugin.ini) は上書きされますか?
いいえ。構成ファイルが上書きされることはありません。構成ファイルが上書きされるのは、ダウンロード・プラグインが再構成されたときだけです。
SCC ダウンロード・プラグインのログはどこにありますか? 使用できるログ・レベルにはどのようなものがありますか?
ロギングは plugin.ini ファイルによって制御されます。このファイルは、ダウンロード・プラグインの実行可能プログラムと同じ場所にあります。デフォルトでは、Windows システム上の %PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\SCCProtocol にあります。Linux システムの場合は、/var/opt/BESServer/DownloadPlugins/SCCProtocol にあります。ログ・ファイルは 1 日ごとに循環して使用されます。つまり、新規ログ・ファイルが作成されると、古いログ・ファイルの名前がその作成開始日に変更されます。
SCC ダウンロード・プラグインのログ・レベルを設定することはできますか?
必要な情報のレベルに応じたログ・メッセージを生成するように、ダウンロード・プラグインを設定することができます。

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

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

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

ERROR
ダウンロード・プラグインの実行に関連するエラーが出力されます。このようなエラーは、致命的エラーが発生する直前であることを示している場合があります。
WARNING
ダウンロードの失敗と、失敗の理由に関する情報が出力されます。
INFO
ダウンロードの進行状況とダウンロードの成功に関する一般情報が、最小限のトレース情報とともに出力されます。
DEBUG
問題のトラブルシューティングに使用される詳細情報が出力されます。これは、使用可能なレベルの中で最も詳細なレベルです。
注: ロギング・レベルを DEBUG に設定すると、ログに記録する情報の量が増えるため、パフォーマンスに影響が及ぶ可能性があります。ロギング・レベルを DEBUG に上げるのは、問題を調査するときだけにとどめる必要があります。
トラブルシューティング時の終了コードの意味は何ですか?
終了コード 251 および 252 が出力される場合は、問題の性質が予期しないものであり、ご使用の環境に固有のものである可能性があるため、HCL BigFix サポートに連絡する必要があります。%PROGRAM FILES%\BigFix Enterprise\BES Server\DownloadPlugins\SCCProtocol にある該当するダウンロード・プラグインのログと、/var/opt/BESClient/EDRDeployData にある適用ログを、必ず提供してください。
上記以外の終了コードは、Zypper の公式の終了コードに基づいています。定義を確認するには、コマンド・プロンプトから zypper man を実行してください。
EDR ログが削除されないようにする方法はありますか?
Fixlet のアクション・スクリプトを編集して、アクションの debug_level を 10 に設定すると、ログが保持されます。
アクションが失敗し、EDR ログには失敗したアクションに関する情報が何も出力されません。どうやってトラブルシューティングすればよいですか?
Fixlet アクションで、debug_level を 10 に設定して、デバッグ用のより詳細な情報を取得するように指定してから、Fixlet を再実行してください。
アクションが失敗し、ログには Zypper 固有のエラーが表示されています。どうやってトラブルシューティングすればよいですか?
Zypper とそれに関連するエラーについて詳しくは、http://www.suse.com にある Zypper に関する文書、および Novell カスタマー・センターの Zypper 関連の記事を参照してください。
Zypper が使用する構成設定はどれですか?
SUSE Fixlet サイトは、/etc/zypp/zypp.conf のすべての Zypper 設定を使用します。
以下の Zypper 構成設定は、別のファイル (Fixlet の実行時に動的に作成されるファイル) から取得される値に設定されます。
  • cachedir
  • configdir
  • metadatadir
  • packagesdir
  • reposdir
  • repo.add.probe
  • repo.refresh.delay
  • solvfilesdir
どのバージョンの BigFix が SUSE 向けのカスタム・リポジトリーをサポートしますか?
BigFix V8.2 以降が、SUSE Linux Enterprise Desktop および SUSE Linux Enterprise Server バージョン 11 および 12 向けのカスタム・リポジトリーをサポートします。
カスタム・リポジトリーとは何ですか?
カスタム・リポジトリーという用語は、Novell カスタマー・センターによってネイティブにサポートされていないソフトウェア・リポジトリーを表します。カスタム・リポジトリーには、リポジトリーの内容を正確に制御できるという利点があります。「SLE カスタム・リポジトリー管理」ダッシュボードでは、カスタム・リポジトリーという用語はリポジトリーを表す場合も Subscription Management Tool (SMT) を表す場合もあります。
リポジトリーの目的は何ですか?
リポジトリーは、パッケージの集合と使用可能なパッケージに関するメタデータを含む保管場所です。これらのリポジトリーは、オンライン・サーバー、CD、DVD、またはその他のメディアに置くことができます。
SMT とは何ですか?
SMT は Subscription Management Tool を表します。SMT はリポジトリーと登録のターゲットを示し、このターゲットは Novell カスタマー・センターと同期されます。SMT を使用することで、企業のお客様は SUSE Linux Enterprise のソフトウェア更新とサブスクリプション・ライセンスの管理を最適化できます。SMT について詳しくは、https://www.suse.com/documentation/smt11/ を参照してください。
「SLE カスタム・リポジトリー管理」ダッシュボードを使用するために必要な Zypper のバージョンはどれですか?
最小要件はありません。SUSE Linux Enterprise バージョン 11 で使用されているすべてのバージョンの Zypper が正常に機能します。
リポジトリーの作成方法を教えてください。
リポジトリーの作成方法については、以下の SUSE 資料を参照してください。
前に構成したリポジトリーを再構成できますか?
はい、前に構成したリポジトリーは clientSetup4SMT.sh スクリプトを使用して再構成できます。このスクリプトは SMT と一緒に提供され、エンドポイントを、SMT サーバーを使用するように構成したり別の SMT サーバーを使用するように再構成したりします。
SMT とリポジトリーのどちらに対して通常の Zypper プロセスを使用しているかを、ログで判断できますか?
はい、ログには、標準リポジトリーと SMT のどちらに対して通常の Zypper プロセスが使用されているかが示されます。
リポジトリーの登録とリポジトリーのインポートの違いは何ですか?
ダッシュボードの「リポジトリー」リストに含まれていない既存のリポジトリーがある場合は、インポート機能を使用します。「リポジトリー」リストにリポジトリーがすでにある場合でも、そのリポジトリーをエンドポイントにリンクする必要がある場合は、登録機能を使用します。
リポジトリーにパッケージが含まれていないとどうなりますか?
パッケージが見つからない場合、Fixlet は失敗します。Zypper 出力のログが記録される /var/opt/BESClient/EDRDeployData/EDR_DeploymentResults.txt からトラブルシューティングを実行できます。
カスタム・リポジトリー・ソリューションで問題が発生するとどうなりますか?
「カスタム・リポジトリー・サポートの無効化 – SUSE Linux Enterprise」タスクを実行して、標準 BigFix サーバー・ソリューションに戻すことができます。
依存関係の解決方法を教えてください。
依存関係は Zypper によって解決します。
「SLE カスタム・リポジトリー管理」ダッシュボード内の「エンドポイント」タブの 2 番目のテーブルにリストされているリポジトリーは順番に使用されますか?
リポジトリーの登録時に追加注記として優先順位を指定していた場合でも、「エンドポイント」タブにリストされているリポジトリーに順序は設定されません。Zypper がリポジトリーを照会すると、最初にフェッチ照会を受けたリポジトリーが、パッケージとその依存関係を含めて応答を返します。
「SLE カスタム・リポジトリー管理」ダッシュボードを使用して、ベンダー・サイトのミラーではないカスタム・リポジトリーを使用してパッチを適用しました。適用アクションは失敗となり、ログはファイルを開けないことを示しています。何をすべきですか?
ベンダー・サイトのミラーではないカスタム・リポジトリーを使用する場合、インストールの中でデフォルトの gpgcheck が行われる可能性があります。そのリポジトリーには GPG 署名ファイルが含まれていない場合があります。それらのファイルは認証性がチェックされず、インストールの失敗の原因となる可能性があります。この問題を解決するには、必ず「SLE カスタム・リポジトリー管理」ダッシュボードへのエンドポイントの登録時に gpgcheck=0 を「追加フィールド (Additional Fields)」に追加してください。
インストール・タスクを使用して複数のカスタム・パッケージをインストールすることはできますか?
はい、使用可能なタスクを使用して複数のカスタム・パッケージをインストールすることができます。パッケージ名を区切るために、スペースを使用してください。
カスタム・リポジトリー・アーキテクチャーで、帯域幅スロットリングは使用可能ですか。
カスタム・リポジトリー・アーキテクチャーは BigFix インフラストラクチャーの外部にあるため、帯域幅スロットリングはサポートされていません。
カスタム・サイトから Fixlet を適用しようとしましたが、失敗しました。なぜでしょうか? どうすればよいでしょう。
Fixlet サイト名は、Fixlet の関連度内でハードコーディングされています。これは、関連度で指定できる値は 1 つだけであるためです。そのため、カスタムの Fixlet を適用する場合は、すべての関連サイトを取得できるように、元の Fixlet サイトに対してエンドポイントをサブスクライブする必要があります。
元の Fixlet サイトに対してサブスクライブせずに、カスタムの Fixlet を正常に適用できるようにするには、以下のステップを実行します。
  1. 必要なサイト・ファイルのカスタム・コピーを作成します。
  2. 必要なサイト・ファイルを、カスタム・サイトまたはオンラインでホストします。
  3. カスタムの Fixlet ファイルを適切に変更します。
カスタム・リポジトリー内のカスタム・パッケージをインストールするにはどうすればよいですか?
「パッチ・サポート」サイトの「zypper を使用したパッケージのインストール」タスクを使用してください。
詳しくは、『カスタム・リポジトリーからのパッケージのインストール』を参照してください。
SUSE Linux Enterprise 11.0 で Zypper のバージョンを 1.5.3-3.2 以上に更新した場合、CVE 番号を使用してパッチをインストールすることはできますか?
はい。バージョン 1.5.3-3.2 の Zypper を使用している場合は、CVE 番号を使用してパッチをインストールすることができます。
「SLE カスタム・リポジトリー管理」ダッシュボードでサポートされている SUSE Linux Enterprise のバージョンを教えてください。
「SLE カスタム・リポジトリー管理」ダッシュボードでは、バージョン 11 および 12 の SUSE Linux Enterprise Desktop と Linux Enterprise Server がサポートされます。
SUSE Linux Enterprise 12 を使用している場合、エンドポイントを新しい SMT に登録する前にリポジトリーまたは SMT の登録を解除する必要があるのはなぜですか?
SUSE Linux Enterprise 12 の場合、新しい登録情報によって古い登録情報が上書きされることはありません。そのため、登録を行う前に、SLE カスタム・リポジトリー管理ダッシュボードを使用して、エンドポイントの登録を解除する必要があります。
SUSE Linux Enterprise 12 を使用している場合、エンドポイントを新しい SMT に登録する前にいずれかのファイルを削除する必要がありますか?
エンドポイントの登録を解除する際に SLE カスタム・リポジトリー管理ダッシュボードを使用しない場合は、以下のファイルを削除する必要があります。
  • /etc/SUSEConnect
  • /etc/zypp/credentials.d/*
ext3 や btrfs などのファイル・システムが混在しているシステムでロールバックを実行することはできますか?
「SLE Btrfs スナップショット管理」ダッシュボードでサポートされるのは Btrfs ファイル・システムだけです。.ext3 や btrfs などのファイル・システムが混在している場合、ロールバックは実行できません。
「スナップショットから /var/opt/BESClient/* ディレクトリーを除外」タスクに関する情報はどこで参照できますか?
このログ・ファイルは /etc/snapper/filters/logfiles.txt ディレクトリーにあります。
スナップショットのロールバック機能に関するトラブルシューティングを行う場合、どのログを使用すればよいですか?
var/opt/BESClient/EDRDeployData ディレクトリーにある snapper_rollback.log ファイルを使用してください。
ロールバック機能を有効にするには、どのディレクトリーをスナップショットから除外すればよいですか?
「SLE Btrfs スナップショット管理」ダッシュボードでロールバック機能を有効にするには、スナップショットを取得する際に、/var/opt/BESClient/* ディレクトリーを除外する必要があります。
スナップショットに関する追加情報はどこで参照できますか?
SUSE 製品資料 (https://www.suse.com/documentation/sles11/book_sle_admin/data/cha_snapper.html) を参照してください。
SUSE Linux Enterprise 12 のエンドポイントが 「SLE Btrfs スナップショット管理」ダッシュボードに表示されません。なぜでしょうか?
現在、バージョン 12 の SUSE Linux Enterprise Server または Desktop のエージェントを使用できるのは BigFix V9.2 だけです。該当するバージョンが使用されていることを確認してください。
複数パッケージのインストール・タスクを使用して実行したベースラインが正常に完了しましたが、まだ関連するものとして表示されるのはなぜですか?
依存関係が破損したパッケージを、Fixlet コンポーネントがインストールできなかったことが原因と考えられます。「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクは、デフォルトでは、依存関係に問題がないパッケージがターゲット・エンドポイントに正常に適用されるように、破損した依存関係を無視します。
「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクを使用してベースラインを実行しました。そのベースラインで失敗した Fixlet のリストを確認するには、どうすればよいですか?

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

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

  1. ナビゲーション・ツリーで「アクション」アイコンをクリックします。
  2. アクション・リスト・パネルでアクションを選択します。
  3. 作業域で「コンピューター」タブを選択します。
  4. リストの任意のコンピューターを右クリックします。
  5. コンテキスト・メニューから「アクション情報の表示」を選択するか、「編集」メニューから「アクション情報の表示」を選択します。
失敗した Fixlet に関する詳細情報を調べるには、ターゲット・エンドポイントの /var/opt/BESClient/__BESData/__Global/Logs にあるクライアント・ログを確認してください。
ベースライン内の複数の Fixlet を適用するときに、破損した依存関係をスキップして、残りのパッケージのインストールを続行することはできますか?
「複数パッケージのベースラインのインストール (Multiple-Package Baseline Installation)」タスクは、依存関係が破損したパッケージを可能な限りスキップします。ただし、SUSE 製品 (SLED-12-0.x86_64 など) の依存関係に関する問題が含まれるパッケージはスキップできません。パッケージがスキップされないもう 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 が適用された。複数パッケージのインストールで、すべての zypper トランザクションを完了し、エンドポイントのステータスを更新するための十分な時間がとられなかった。
  • zypper ツールにパッチが適用されていないのに、ベースラインに SUSE リリース・パッケージが含まれている。
  • 「複数パッケージのベースラインのインストール機能を有効化 (Enable the Multiple-Package Baseline Installation feature)」タスクは、残りのコンテンツと同じベースライン内にある必要があります。このタスクは、パッチ Fixlet および複数パッケージのインストール・タスクより前に追加する必要があります。
  • 複数パッケージのベースラインのインストール機能は、有効化タスクとインストール・タスクの両方が同じベースライン内に存在する場合にのみ動作します。詳しくは、『ベースラインでの複数パッケージのインストール』を参照してください。
  • 以下のクリーンアップ・タスクのいずれかの後に、「複数パッケージのベースラインのインストール機能を有効にする」タスクを追加する必要があります。複数パッケージのベースラインのインストール用に SUSE 11 パッケージ・リスト・ファイルを削除 (Delete SUSE 11 Package List File for Multiple-Package Baseline Installation) または のトラブルシューティング: SUSE 11 パッチ・デプロイメント・ログ - クリーンアップ (SUSE 11 Patching Deployment Logs - Cleanup)。
  • 正しい SUSE ディストリビューション、オペレーティング・システム・バージョン、サービス・パック・レベル、およびアーキテクチャーを使用するインストール・タスクをベースラインの最後に追加する必要があります。
エンドポイントが隔離された環境にあります。これらのエンドポイントにパッチを適用するには、BigFix をどのように構成すればよいですか?
隔離された環境の場合は、エンドポイントにパッチを適用するために必要なパッケージをホストするサポート対象 SUSE リポジトリーに対して、必ずミラーリングを行ってください。これを行うには、SCC ダウンロード・キャッシャーを使用して、BigFix サーバーからアクセスできる場所にローカル・リポジトリーを作成します。この場所は、ローカル・キャッシュと呼ばれます。
注: 依存関係の解決時に問題が起こらないように、ローカル・キャッシュには必要なリポジトリーがすべて含まれている必要があります

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

  1. ローカル・キャッシュの構成 localCache を、ダウンロード・キャッシャー・ツールを使用してダウンロードしたファイルの場所に設定します。
    注: この場所は、BigFix サーバーからアクセス可能でなければなりません。
  2. ダウンロード・キャッシュからのファイルのみをダウンロードし、ベンダーのサイトからはダウンロードしないよう localCacheOnly フラグを yes に設定します。
EDR ログに、何もインストールできないため、最新のカーネルを使用しているかどうか確認するよう警告するメッセージが表示され、Fixlet のインストールが失敗しました。この場合の対処方法を教えてください。
このメッセージは、カーネル・パッケージをデプロイする Fixlet の場合にのみ表示されます。エンドポイントにターゲット・カーネル・パッケージがインストールされていない場合、またはエンドポイントのアクティブ・カーネルがターゲット・カーネル・パッケージより低いバージョンである場合、カーネル Fixlet が関連状態になります。エンドポイントに最新のカーネルがインストールされているもののアクティブに使用していない場合も、カーネルの脆弱性の対象と見なされます。

問題を修復するにはエンドポイントを再起動し、使用可能な最新のカーネルを使用していることを確認します。