私の問題:cfengine3ポリシーはサーバー(ポリシーハブ)で手動で作成/更新され、クライアントは定期的に(約5分ごとに)サーバーからポリシーをプルします:/ var/cfengine/masterfilesそれぞれのsomeclient:/ var/cfengine /入力(必要に応じて)。
しかし、これは時々一貫性のない動作をします。サーバー内の更新されたファイルは、しばらくするとクライアントに反映されない場合があります。突然更新が「認識」されるまで、30分以上かかる場合があります。これは、私が作成/更新したものが./masterfilesの下のサブディレクトリにある場合に特に発生します。
各クライアントが実際に5分ごとにcfengineポート(5308)を介してマスターサーバーと通信していることをtcpdumpで確認しました。
ポリシーファイルが更新されない理由がわかりません。
誰かが同じことを経験したか、提案がありますか?ありがとう。
(cfengine 3.3.1にアップグレードしたばかりで、CentOS/Fedoraが分離された環境が混在しています。残りのネットワークはcf2で正常に動作します)。
デビッド、
更新されたファイルがコピーされており、ローカルのcf-agentが変更に反応しませんか?それとも、更新されたファイルはずっと後になるまでコピーされませんか?
頭の中で考えられる理由の1つは、システム間のクロックが同期していないことです。/var/cfengine/input/cf_promises_validatedを確認します-このファイルには、サーバーでPromiseが最後にチェックされた時刻が入力され、クライアントはこのタイムスタンプを使用してローカルポリシーを再読み込みします。
また、質問を CFEngineヘルプフォーラム に投稿することもできます。ここでは、より多くのCFEngineエキスパートが質問を見ることができます:)
CFEngineを3.3.1にアップグレードしたとのことですが。
3.3.1の/ var/cfengine/masterfiles/cf_promises_validatedに新しいタイムスタンプがあります(以前のバージョンは私が推測した空白のファイルです)。これは、ファイルを「mtime」から「digest」にコピーする方法を変更できることを意味します。システムクロックの問題を回避するための現在のfailsafe.cf。 /var/cfengine/share/CoreBase/failsafe.cfも参照してください。bodycopy_fromu_rcpには、すでに「ダイジェスト」複合本体があります。
他の人と同じように、私はクロックスキューを疑っています。時間を確認してください。リモートエージェントの/ var/cfengine/inputsにあるcf_promises_validatedファイルを削除することもできます。次に、ポリシーハブの/ var/cfengine/masterfilesにあるcf_promises_validatedファイルが異なることがわかり、ポリシーの完全な更新が続行されます。
3.3.0以降、cf_promises_validatedには日時スタンプが含まれている必要があります。これにより、ポリシーの更新に適切な時刻同期に依存しなくなります。
デフォルトのbootstrapポリシーを使用している場合は、failsafe.cfを確認してください。
3.3.1または3.3.0(私が見ているフェイルセーフを生成したものが不明)のポリシーには、必要に応じてu_rcpを使用してcf_promises_validatedファイルを更新するハンドル「check_valid_update」の約束があります。 promiseを修復すると、validated_updates_readyクラス/コンテキストが発生し、ハンドルupdate_files_inputs_dirを持つpromiseが制限されて残りのポリシーが更新されます。比較属性に使用されているものをu_rcpから本文にチェックインします。ダイジェストの場合は、タイムスタンプだけでなく、ファイルのコンテンツを使用する必要があります。
デビッド、
ディエゴのように、クロックスキューも疑っています。 http://cfengine.com/blog/cfengine-330-release-notes でcf_promises_validatedを検索すると、いくつかのリソースが得られる可能性があります。重要なのは、failsafe.cfのコピープロミスです。