前回まででスタンドアローンでは展開が終って、複数サーバでの管理はどうするのかなとマニュアルを眺めていました。
cfengine2の時と同じように公開鍵を準備してサーバプロセスを起動して、クライアントからアクセスすればmasterfilesに置いたポリシーファイルが配られるのかなぁ、と考えていたのですが、どうやらcfengine3では商用のNovaでないとその機能は使えないようでした。
ポリシーファイルの同期が取れないのはcfengine2から後退している気もしますが、cf-runagent自体は動きました。 もっとも動くだけで、あまり使い勝手はないですけどね。
一般ユーザでもcfengineは動かせますが、とりあえずroot権限でcf-serverdやらcf-agentやらを実行することを考えています。
cf-runagentを動かしてみる
とりあえず2台のcfengine3が動いている環境を準備してから、cf-runagentで他のサーバのrunagentを起動しようと思います。
工夫すれば起動するスクリプトを変更することはできますが、普通はcf-agentをリモートで起動することができます。
クライアント側の設定
cf-runagentを実行する側の設定をします。 まずはkeyファイルを作成しておきます。
$ sudo cf-key
/var/cfengine/ppkeys/localhost.priv
/var/cfengine/ppkeys/localhost.pub
次にpromises.cfファイルを編集します。
body runagent control
{
hosts => { "10.0.0.3" };
trustkey => "true";
}
trustkeyは設定しなくても、/var/cfengine/ppkeys/root-10.0.0.3.pub
のようなcf-runagentを実行するユーザIDと接続先のIPアドレスを名前にして、相手方の/var/cfengine/ppkeys/localhost.pubを配置しておく事でも同じ結果になります。
trustkeyを"true"に設定しておくと、root-10.0.0.3.pubのようなファイルは自動的に作成されます。
またここで"hosts"に指定したサーバにcf-runagentは接続します。
サーバ側の設定
接続先のcf-serverdの設定を行ないます。 こちらでもkeyファイルを作成しておきます。
$ sudo cf-key
こちら側ではpromises.cfファイルとsite.cfファイルの2個所を編集します。
body server control
...
allowconnects => { "127.0.0.1" , "::1", "10.0.0.0/16" };
allowallconnects => { "127.0.0.1" , "::1", "10.0.0.0/16" };
trustkeysfrom => { "127.0.0.1" , "::1", "10.0.0.0/16" };
...
}
bundle server access_rules()
{
access:
...
"/var/cfengine/bin/cf-agent"
admit => { "127.0.0.1", "10.0.0.0/16" };
...
}
まぁ設定はしてみましたが、cf-runagentが動いても任意のcfengineスクリプトを実行できないようなので、cronから5分間隔でcf-agentが起動している現状では使いどころがなさそうです。
気がついたところ
cf-runagentでunit_*.cfを起動することができない
cf-runagentがcf-serverdに接続すると、body server control
の中でcfruncommandで指定されているプロセスが"--inform"オプション付きで起動されます。
このcfruncommandで指定するコマンドを自作のスクリプトなどに変更すれば、起動するプロセスをコントロールできます。
しかしcf-runagentでは$ sudo cf-runagent -o '-f unit_syslog.cf'といったオプションは受け付けてもらえません。 そのため任意のcfengineスクリプトを実行するといったことはできません。
設定ファイルの複雑化が気になる
cfengine3では body 構文を使って右辺値をグループ化することはできますが、ファイル数が増えていった時にパーミッションを管理したいといった場合には自動生成できると便利なのですが、そういう連携は少し難しそうに思えます。
cfengine3をスタンドアローンで使う場合には、それなりに便利に使う事はできそうです。 ただ統計情報はbdb形式で出力してくれますが、machine readableなログファイルを生成するといった機能は強くないため、他のツールとの連携にはカスタマイズしたログファイルパーサーなどが必要かもしれません。
問題があった場合に自動的に修復するっていうアプローチが正しいとは限らないんですよね…。 特に日本だと全部のインシデントをトラッキングしないといけない場面もあるように思えます。
問題の検出と修正を分けて管理しないといけないような場面ではよくないでしょうね。
0 件のコメント:
コメントを投稿