エージェントの自動更新

この設定を有効にする (Deploy plugin …​) 必要があります。 ここでは、たとえば、ルール継承を使用して、上位レベルのフォルダでデフォルトを設定し、必要に応じて個々のホスト/フォルダでこれを上書きすることができます。

エージェントアップデータ―を Checkmk サーバーに接続するためのオプションの設定データを入力できます。 この項目を設定していない場合は、エージェントアップデータ―を登録する際に、後で情報を入力する必要があります。

ここで設定された CA または自己署名証明書は、HTTPS 接続の認証のためにエージェントアップデータ―で使用できます。 あるいは、セントラルセットアップによる分散監視の場合、Checkmk サイトからエージェントアップデータ―に証明書を提供することもできます。 または、コマンドラインパラメータを使用して、接続中に直接インポートすることもできます。

重要：サーバーの証明書チェーンが公的 CA によって署名されている場合、通常、インポートした証明書がなくても接続を検証できます。 ただし、上記のソースからインポートした証明書がエージェントアップデータ―で使用可能になると、他のすべての CA 認証機関は無視されます。HTTPS の設定に問題がある場合は、以下の FAQ を参照してください。

ここでは、エージェントアップデータ―が、設定された 監視サーバーに更新があるかどうかを照会する間隔を指定します。指定した 間隔が経過しない限り、ネットワークの負荷をできるだけ抑えるため、キャッシュされた呼び出しが返されます。 通常、間隔は 10 分以上 に設定することをお勧めします。それより短い間隔に設定すると、Checkmk エージェントの数が多 い場合、ネットワークに非常に大きな負荷がかかる危険性があります。 ここに値を設定しない場合、デフォルト値の 1 時間が適用されます。

このルール設定も同様にオプションです。 エージェントアップデータ―は、プロキシ設定が構成されている場合でも、ターゲットホスト上の Checkmk サーバーに直接接続されていると想定し、すべてのローカルプロキシ設定を無視します。 これが望ましい動作である場合は、このルール設定は省略できます。 それ以外の場合は、プロキシ設定を手動で入力するか、ホストの既存の環境変数を使用してください。

プラグインをエージェントインストールパッケージに追加する方法をオプションで指定できます。 ルールのデフォルトの動作は、ターゲットシステムによって異なります。

それでも古い Python スクリプトを使用する必要がある場合は、システムに以下の要件が適用されます。

エージェントアップデータ―が受け入れる署名のキーを 1 つ以上選択してください。 オプションで複数のキーを指定することもできます。これは、たとえば、古いキーを使用不能にしたい場合などに 有用です。このためには 、その間、ホストのエージェントアップデータ―が両方のキーを受け入れるように設定する必要があります。

この最後の設定が完了すると、ルールは次のスクリーンショットのようになります。

すべての設定を保存するには、Save をクリックしてください。

次に、エージェントパッケージをホストにコピーし、rpm またはdpkg (Linux パッケージインストール) でインストールします。

インストール後、エージェントアップデータ―プラグインは、/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent ディレクトリにあります。3600 のサブディレクトリの値は、更新チェックの間隔（秒単位）を表します（ここではデフォルト値の 1 時間）。 同じ名前のスクリプトも/usr/bin/ に保存されているため、cmk-update-agent コマンドも使用できます。

次に、register 引数でエージェントアップデータ―を呼び出します。 必要な情報を順番に入力してください。

次のコマンドで、Linux ホストからエージェントアップデータ―を登録します。

または、コマンドラインオプションで必要なデータを入力して、非対話モードで登録を行うこともできます。 Linux では、ここでcmk-update-agent register --help を呼び出すと、設定可能なオプションが表示されます。

次に、エージェントパッケージをホストにコピーし、msiexec （Windows パッケージのインストール）でインストールします。

インストールが完了すると、エージェントアップデータ―は Windows エージェントのC:\Program Files (x86)\checkmk\service\check_mk_agent.exe に統合されます。 アップデータ―自体は、check_mk_agent.exe updater コマンドで制御できます。

register 引数でエージェントアップデータ―を呼び出します。 Windows では、管理者権限のあるコマンドプロンプトで実行する必要があります。 必要な情報を順番に入力します。

Windows ホスト用のエージェントアップデータ―はエージェント自体に統合されているため、登録用のコマンドは次のようになります。

または、コマンドラインオプションで必要なデータを入力して、非対話モードで登録を行うこともできます。 登録用の完全なコマンドは、次のとおりです。

ワンタイム登録は、オートメーションユーザーを介して行うこともできます。 この場合、コマンドラインで、ユーザーは-U/--user 、オートメーションパスワードは-S/--secret として渡されます。

登録に関する注意事項:

登録が正常に完了すると、ホストのシークレットはエージェントの/etc/cmk-update-agent.state ファイルに保存されます。 サーバーでは、~/var/check_mk/agent_deployment/myhost に保存されます。 この時点から、ホストはパスワードを入力しなくても、サーバーから自分のエージェントをダウンロードできるようになります。 他のホストからエージェントをダウンロードすることはできません。他のホストのエージェントには、機密データが含まれている可能性があるためです。

この時点で、リモートサイトからセントラルサイトにアクセスするための URL を、プロトコルと文字列check_mk を含めて指定する必要があります。 たとえば、https://myserver.org/mysite/check_mk などです。 Checkmk サイトは、他のすべての欠落している設定を自動的に識別しようとしますが、この URL の指定は必須です。 そうしないと、セントラル構成の場合、この接続方向が確立されません。プロトコルが HTTPS の場合、 リモートサイトは、接続の認証にセットアップで利用可能な CA または自己署名証明書を 自動的に使用します。Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL 。 リモートサイトでは、セントラルサイトにログインするために、事前に作成されたオートメーションユーザーも必要です。 これは、ここで選択することもできます。何も指定されていない場合、 リモートサイトは「Automation」という名前のオートメーションユーザーを検索します。

リモートサイトは、必ずしも各監視対象ホストからセントラルサイトと同じ URL でアクセスできるとは限りません。そのため、この目的のために URL をここで設定することができます。この URL は、Checkmk サイトへの接続時に、ホスト（または要求元のエージェントアップデータ―）に自動的に通知されます。 ここでは、サイト固有のグローバル設定として設定することが特に有効です。 URL が指定されていない場合、リモートサイトは、セントラルサイトと監視対象ホストの両方から同じ URL でアクセスできるものとみなされます。HTTPS 接続の場合は、適切な証明書をホストに自動的に提供することもできます。このためには、セントラル CA ストアを使用することはできないため、この時点で適切な証明書を指定しておく必要があります。 あるいは、エージェントアップデータ―のルールで証明書を指定することもできます。

エージェントアップデータ―は、常に HTTPS 接続の認証を試み、認証できない場合は接続を終了します。 認証用の証明書は、エージェントアップデータ―が以下のソースから入手できます。

エージェントアップデータ― デフォルトでは、エージェントアップデータ―には、必要なモジュールを含む Python ランタイム環境が付属しています。 また、Mozilla プロジェクトの証明書コレクションに基づくCertifi モジュールの証明書バンドルも付属しています。 これにより、オペレーティングシステムの更新がペンディングの場合でも、公開 CA がエージェントアップデータ―にタイムリーに認識されます。

エージェントベーカリー経由の証明書： 次のいずれかの方法で 1 つ以上の証明書がインポートされると、Certifi モジュールに含まれる証明書は無視されます。 次のソースからの証明書は、ホストにローカルに保存され、エージェントアップデータ―のみによって使用されます。

証明書ストア： エージェントアップデータ―は、エージェントアップデータ―が、付属の Python ランタイム環境ではなくSystem-Pythonを使用するように設定されており、System-Python に Certifi モジュールが設定されていない場合にのみ、オペレーティングシステムの証明書ストアを使用できます。 インストールパラメータや_PIP_STANDALONE_CERT 環境変数など、多くの要因が関係するため、このような設定は公式にはサポートしておりません。

コマンドラインによる証明書 - 証明書のインポート： コマンドライン引数--trust-cert を使用して、エージェントアップデータを呼び出すこともできます。 これにより、サーバー証明書が取得され、インポートされます。 これは、証明書のタイプに関係なく行われます。 自己署名証明書、公開証明書チェーンの末尾にある証明書、内部 CA で署名された証明書など、チェーンの可能性についてさらにチェックを行うことなく、証明書は信頼されます。

コマンドラインによる証明書 - 証明書を無視： エージェントアップデータ―が有効な証明書をまったく使用できない場合、呼び出しにコマンドライン引数--insecure を使用することで、証明書検証をバイパスすることができます。 これは、有効な証明書が次の接続でサーバーから取得されるのを待っているが、 この証明書がないためにエージェントアップデータ―が「ロックアウト」されている場合に役立ちます。

リモートサイトからセントラルサイトに接続する場合、セットアップ手順をまったく実行する必要がないため、証明書の配布が簡単になります。 リモートサイトは、Global settings > Site management > Trusted certificate authorities for SSL にある Checkmk 証明書ストアを使用できます。 したがって、必要に応じて、セントラルサイトが複数の URL でアクセス可能な場合は、Site specific global settings 経由で証明書をインポートするだけで十分です。

独自の認証インフラストラクチャを使用している場合は、有効期間が非常に長く、関連付けられているキーが中間証明書の作成に定期的に使用されるルート証明書を使用するのが理想的です。これらの証明書は、サーバー証明書の署名に使用されます。 この場合、中間証明書は、Checkmk サーバーに証明書チェーンとして展開されます。 自動エージェントアップデートを受信するホストには、ルート証明書のみを認識させる必要があります。

新しいサーバー証明書に新しいルート証明書が必要かどうか不明な場合は、次のコマンドを使用してください。 このコマンドを使用して、サーバー証明書の署名に使用されるルートキーの識別子を特定します。

表示された識別子が新旧の証明書で同じであれば、それ以上の操作は必要ありません。 このルート証明書を信頼するホストは、証明書チェーンが変更されても、そのチェーンがシステム Apache に正しく保存されていれば、引き続き更新を取得できます。

これまで自己署名証明書または内部 CA の有効期間が短いルート証明書を使用していた場合、または内部 CA のいずれかの以前のルートキーが不正に取得された場合、証明書を置き換える際には、次のようにしてください。

エージェントアップデータ―は、実際には更新間隔内に 1 回だけ実行されます。 そのため、プラグインを手動で呼び出すか、次の間隔がペンディングになるまで、エラーが継続的に表示されます。 手動で再インストールした後、エージェントが登録されない

エージェントアップデータ―は、独自のステータスファイルcmk-update-agent.state を独立して作成します (Linux/Unix では/etc 、Windows ではconfig フォルダ)。 このファイルは、アンインストール後もホストに残り、レジストリ情報が失われることを防ぎます。 新しいインストールでは、このファイルが検出され、引き続き使用されます。 この状況が望ましくない場合は、アンインストール後にcmk-update-agent.state ファイルを手動で削除してください。

Monitor > System > Agent Update Status ページには、監視対象であり、Checkmkサーバーにステータスファイルが存在するすべてのホストが表示されます。 ホストが実際にCheckmkサーバーに自動更新をレポートしているかどうかは関係ありません。 ここで予期しないホストが表示された場合は、/omd/sites/mysite/var/check_mk/agent_deploymentフォルダを確認してください。おそらく、古いレジストリまたは誤って作成されたレジストリが原因であると考えられます。

エージェントアップデータ―は、通常、Agent updater (Linux, Windows, Solaris) の HTTPS 設定で指定されている証明書のみを明示的に信頼するように設計されています。 特に、ローカルにインストールされた証明書は無視されます。 また、ブラウザから Checkmk サーバーにアクセスできるにもかかわらず、 設定が間違っているためにエージェントアップデータ―が接続できない場合もあります。

エージェントアップデータ―の HTTPS 設定では、Checkmk サーバーへの接続を検証できるルート証明書 を指定する必要があります。 つまり、Checkmk サーバーの サーバー証明書に含まれる証明書チェーンは、ここで指定した証明書で検証できる必要があります。 多くの場合、サーバー証明書がここに指定されていますが、これは この目的には適していません。

OpenSSLツールを使用して、Checkmk サーバーの証明書チェーンを確認してください。 チェーンが長いので、わかりやすくするために、ここでは関連するセクションのみを表示し、省略したセクションは[...]

最後のエントリ（この例ではsubject=/CN=mymonitoring.example.net）には、有効なルート 証明書が必要です。これは、この例のように、必ずしも証明書の発行者である必要はありません。 通常、発行者のチェーンになります。

次に、使用されている証明書を確認します。ここでも、長さを考慮して 上記の例のように短縮しています。

上記の抜粋にある最上位の証明書は、他の証明書に依存することはできません。 発行者 (Issuer) と項目 (Subject) が同一であり、CA:TRUE オプションが含まれていることがわかります。さらに、オブジェクトを認証する発行者のチェーンは 、最後のエントリまで一貫している必要があります。 したがって、最後の証明書の発行者が CA でない場合は、すべての中間証明書も必要になります。 エラーメッセージ：self cmk-update-agent またはアーカイブ cmk-update-agent.pkg を開けません。

一部の Linux システムでは、Prelinkプログラムがインストールされており、クーロンジョブ が起動して、システム上のすべてのバイナリファイルを定期的に検査し 、必要に応じてプログラムを高速化するためにそれらを適応させます。しかし、エージェント アップデータ―プラグインは、このような動作と互換性のないPyInstallerプログラムでパッケージ化されているため 、破損しています。そのため、Checkmk には deb/rpm パッケージのブラックリストエントリが/etc/prelink.conf.d に保存されており、prelink が存在する場合、既存の/etc/prelink.conf ファイルにエントリを設定します。この問題は処理が難しいため 、これらの対策が有効にならない場合があります。特に、prelink を後でセットアップした場合に発生しやすいです。

そのため、prelink を後でインストールする場合は、エントリを自分で設定し、 次のコマンドで次の行をファイルに追加してください。

このエラーメッセージは、/tmp ディレクトリがnoexec フラグでマウントされている場合に発生します。この問題を解決するには、 フラグを削除するか、または、意図的に フラグを設定して要求している場合は、CheckmkサーバーのSetup でAgents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, Unix) ここで、Directory for storage of temporary data (set TMPDIR environment variable)オプションで tmp ディレクトリを自分で定義できます。これにより、エージェントアップデータ―プラグインは、今後、定義したディレクトリに一時ファイルを 書き込みます。これは、/usr/bin/cmk-update-agent

特に Red Hat/CentOS システムで、自動アップデートによってトリガーされるrpm の呼び出しが繰り返し失敗し、cmk-update-agent を手動で呼び出すとプロセスは正常に実行されるという現象が時折発生していました。この問題の原因は 、rpm がxinetd の子プロセスによって呼び出された場合に、エラーのない呼び出しを SELinux ポリシーが禁止していたためでした。この問題 は、SELinux ログを分析して原因を突き止め、audit2allow ツールを使用してポリシーを適宜調整することで解決できます。

Check_MK Agent サービスが警告「No valid signature found 」を表示した場合、エージェントベーカリーでホスト用に指定されているエージェントパッケージが、承認されたキーのいずれかで 署名されていないことを意味します。

最も単純なケースでは、エージェントベーカリーの「Sign agents 」機能を使用して、Signature keys the agent will accept に表示されているキーのいずれかでエージェントに署名するだけで済みます。

エージェントアップデータ―が影響を受けるホストから Checkmk サーバーに次のレポートを送信し、サービスのキャッシュ間隔が経過すると、警告は表示されなくなります。

ただし、ホストに Checkmk サーバーにある単一の署名キーがない（またはなくなった）場合は、ベイクを繰り返し、 Signature keys the agent will accept に表示されているキーで署名してから、ベイクしたエージェントを影響を受けるホストにコピーして再インストールする必要があります。

影響を受けたホストで、cmk-update-agent -v またはcheck_mk_agent.exe updater -v を実行すると、このエラーの詳細を確認できます。 詳細なエラーメッセージには、エージェントアップデータ―プラグインの設定ファイルにある、Checkmk サーバーで受け入れられている（つまり、設定されている）対応するキーがない署名が明示的にリストされます。