# cfengine [[Mark Burgess]] が開発したネットワーク管理エージェント(構成管理ツール)。[[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]] では、cfengine の異常検知手法(教師なし学習・遅延評価・制御された忘却による host normality の学習)を分析対象とし、その分散型アーキテクチャが集中型アーキテクチャに対して統計的な情報損失を伴うかを検証した。同論文はこの手法を「効率性に関する望ましい性質を多く持つ」と位置づける。 [[@1998__LISA__Computer Immunology]](Burgess の LISA '98 論文)では、cfengine は手続き型のシェル/Perl スクリプトと異なり、システムのあるべき状態を記述的に定義し、系がその状態に達すると不活性(quiescent)になる「収束的意味論(converging semantics)」を持つ点で先行の構成管理ツールと異なると位置づけられる。同論文は cfengine を計算機免疫系の phagocyte(貪食細胞、ガベージコレクションを担う)であり damage を修復するドローンだと比喩し、当時(1998年)時点での「今日構築できる最良の免疫系」の中核要素として、Bro/Network Flight Recorder・load average と組み合わせて紹介している。 *Principles of Network and System Administration*(第2版)第3章では、多様な機器・ソフトウェアを維持する現実的な妥協策として cfengine に一度だけ言及される——ハードウェア・ソフトウェアの均一化(Principle 6: Uniformity)と多様化(Principle 7: Variety)のトレードオフを論じる文脈で、「cfengine のような自動化エージェントは、多様な構成の維持コストを管理可能にしうる」と位置づけられる。また §3.8.9(分散ファイルシステムとミラーリング)では、ソフトウェア partition のミラーリング手段として `rdist`・`rsync` と並んで挙げられ、Windows でも利用可能な点が付記される。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] §3.3, §3.8.9) *Principles of Network and System Administration*(第2版)第2章の Unix と Windows の対比表(Table 2.3)では、cfengine は「Unix-like OS / Windows」双方の欄に挙げられ、Windows でも 1.5.0 以降で利用可能なソフトウェア概念の一例として一行だけ言及される。同章の中心的な議論の対象ではなく、Unix と Windows の機能対応を示す事例列挙の一項目としての言及にとどまる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 2 System components]]) 同書第4章「Host management」では、cfengine は2箇所で軽く言及される。§4.4.5(ファイルシステムレイアウト)では、`/etc/group`・`/etc/services`・`/etc/sendmail.cf` 等のマスターコピーをOS配布物から分離した専用ディレクトリに置き、各ホストの実際の配置場所へコピーする手段としてスクリプトと並んで名指しされる。§4.7.6(設定のセキュリティ)では、デーモンをroot権限で起動したのち非特権ユーザーへ権限を降格させる(`su -c 'command' user` の代替)手段として言及される。いずれも一文程度の軽い言及であり、詳細な設定例は示されない。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]] §4.4.5, §4.7.6) 同書第5章「ユーザー管理」では、cfengine はディスク資源制御(§5.6.1)の実装手段として登場する。`tidy` アクションを用いて `core` ファイル・`*.o`・ブラウザキャッシュなど種類ごとに異なる保持期間(age)を設定し、一定期間アクセスのないファイルをホームディレクトリ横断で自動削除する設定例(control/tidy スタンザ)が示され、硬いディスククォータの代替として「利用者の自由感情を損ないにくい」運用手段に位置づけられる(Principle 22: Freedom)。また §5.6.3 では、ログアウトし忘れたユーザーのプロセスなど、1日以上稼働し続ける古いプロセスを `processes` コマンドで検出・終了させる用途でも言及される。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 5 User management]] §5.6.1, §5.6.3) 同書第6章「Models of network and system administration」では、cfengine は§6.3の管理モデル類型学における具体的な実装例として位置づけられる——「メッシュ・トポロジ、部分的なホスト自律+ローカル強制」を特徴とするモデル4を採用するツールと明記され(§6.3)、サブコントローラによる階層的なポリシー編集を伴うモデル5も「創造的なスクリプティングによって cfengine で実装しうる」とされる。§6.5.6 では、各ホストが自発的にファイルを取得する pull 型配布方式の代表例として rsync と並んで挙げられ、中央の完全な特権をホストに要求しない点がセキュリティ上の利点として強調される。§6.6.4(免疫モデル)・§6.8(ポリシーによる設定自動化)では、cfengine のプリミティブが「可能な限り収束的意味論を満たす」ことで、系が理想状態から逸脱するたびにポリシーの再実行がそれを引き戻し、理想状態に達すると静止(quiescent)するという性質が改めて強調され、この収束性ゆえにポリシー駆動の管理はホスト数に対しほぼ線形にしかトラフィックが増えないと位置づけられる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] §6.3, §6.5.6, §6.6.4, §6.8) 同書第7章「Configuration and maintenance」は、cfengine が単発の実装例としてではなく主題そのものとして扱われる唯一の章であり(§7.11「Cfengine」に1節が丸ごとあてられる)、本エンティティの記述の中核をなす。本章は cfengine を「システムポリシーを自動化されたアクションへ変換する環境」と定義し、その設計思想を3点に要約する——(i) ネットワーク上の全ホストがどう設定されるべきかを定義し、(ii) それを全ホストが読む単一の「プログラム」として記述し、(iii) 各ホストがそのプログラムを実行して自らの設定を検査・修正する。cfengine の設定言語は Perl のような命令型言語ではなく Prolog に似た宣言的言語であり、`action-type: classes:: 宣言のリスト` という形式でアクション種別ごとに宣言をまとめ、実行順序は `actionsequence` という専用リストで明示的に制御する(§7.4「Declarative languages」で make・Prolog と対比され、§7.11 で構文が詳述される)。動作原理の核心は「実行のたびに何かをすべきかを判定し、何もすべきことがなければ何もしない」という冪等な収束操作であり、この性質ゆえ cfengine スクリプトは何度実行しても安全で、cron による日次・時間毎の反復実行に適する。ホストへのアクションの割り当ては if-then-else 分岐ではなく「クラス(class)」への帰属によって行われる——ホスト名・OS種別(hard class)・利用者定義グループ・曜日/時刻(time class)などの単純クラスを `.`(AND)・`|`(OR)・`!`(NOT)で結合した複合クラスが真であるときにだけ、対応するアクションが実行される。§7.7.5(cfagent を cron のフロントエンドとして使う手法)では、cfagent を全ホストで頻繁に(例: 15分ごとに)起動し、時刻クラスの評価だけで一元管理されたジョブスケジュールを実現する具体的な仕組みが示される。§7.12 のデータベース設定管理の議論では、cfengine のチェックサム保存が「低水準データベース」の一例として Windows レジストリ・LDAP と並んで挙げられる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4, §7.7.4–§7.7.5, §7.11–§7.11.7, §7.12) 同書第8章「Diagnostics, fault and change management」では、cfengine は2箇所で登場する。§8.9(ゲーム理論的戦略選択)では、ディスク容量管理ゲームにおける「自動整理システム」の具体例として名指しされ、その資源解放レート `r_a` は人間の日次周期より速い(実行周期 T_p は通常1時間以内で、人間の周期の約20倍の頻度)ことが前提とされる。§8.10(監視)では、cfengine の環境デーモン(environment daemon)が SNMP ベースの MRTG・RRDtool・Cricket とは異なる「非決定論的な異常検知」アプローチを長期的な時間スケールで採用し、自動化されたポリシー対抗策の起動に使えると位置づけられる(図8.15: 週次のシステム活動サマリ)。cfengine は本章では、確率的な故障の木・ゲーム理論という抽象的な道具立てを実装に落とし込む具体的なエージェントとして機能しており、第6章で位置づけられた「収束的意味論を持つポリシー実行エンジン」という役割が、本章では「障害の木の対抗戦略を自動実行する主体」として再解釈されている。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] §8.9, §8.10) 同書第9章「アプリケーションレベルサービス」では、cfengine は2箇所で軽く言及される。§9.9.2(NFSディスクのクライアント側マウント)では、`/etc/fstab` の編集作業を自動化する手段として名指しされる(「次章で詳しく論じる」と予告される)。§9.12.2(Tomcatによるサーブレット運用)では、`catalina_base` ディレクトリのパーミッション整合(`files:` スタンザ)、ユーザ用サーブレットディレクトリへのシンボリックリンク管理(`links:` スタンザ)、`tomcat` デーモンの再起動監視(`processes:` スタンザ)、`server.xml` の文字列置換(`editfiles:` スタンザ)、定時シャットダウン(`shellcommands:` スタンザ)を組み合わせた実践的な設定例が全文示され、単一ホストの資源管理だけでなくアプリケーションサービスの運用自動化にも cfengine が使えることを具体的に示している。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] §9.9.2, §9.12.2) 同書第10章「Network-level services」では、cfengine は§10.10(Service Level Agreements)の末尾で一文だけ言及される——SLAをコンピュータ上の機構に落とし込む(mechanizing)研究として、cfengineによるポリシーベースフィードバックと、より新しいファジー制御器の2アプローチが挙げられる。詳細な設定例は示されず、第8章§8.9・§8.10で確立した「cfengineは抽象的な数理的道具立て(ゲーム理論・確率的な故障の木)を実装に落とし込む具体的なエージェントである」という位置づけを、SLAという契約概念にまで一言で延長した言及にとどまる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] §10.10) 同書第12章「Security implementation」では、cfengine は§12.3.4(データ完全性検査)の具体例として図12.1に登場する。`/usr` ファイルツリーの所有者・パーミッション・MD5チェックサムを再帰的に検査する設定(`control: actionsequence = ( files )` / `files: /usr owner=root, bin mode=o-w checksum=md5 recurse=inf`)が全文示され、Tripwireのような専用の完全性検査ツールと同じ役割を、cfengineの通常のファイル操作(`files:` スタンザ)の一部として果たせることを示している。この用法は第7章§7.11で論じた「cfengineは設定を宣言的に記述し、実際の状態と照合して収束させるエンジンである」という一般論の、セキュリティ文脈への具体化にあたる——§7.11では設定ファイルの内容(所有者・パーミッション・存在)を理想状態に収束させる仕組みとして説明されていたのに対し、第12章ではその同じ照合機構を「ファイルが改ざんされていないか」という完全性検査に転用している。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 12 Security implementation]] §12.3.4) 同書第13章「Analytical system administration」では、cfengine は§13.1で技術と科学の関係を説明する導入例として一度だけ登場する——「著者の管理システム cfengine は、免疫モデル(the immunity model of system maintenance)という概念的な枠組みを実装し洗練させるために作られたツールである」と位置づけられ、道具(tool)と、その道具が実装しようとするアイデア(idea)は別物であるという本章冒頭の主張を具体化する役割を担う。第7章が cfengine を宣言的言語・収束操作という実装機構のレベルで詳述したのに対し、第13章での言及はごく短く、cfengine を「アイデアを検証可能にする技術」の実例として抽象的に位置づけるにとどまる。(Source: [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] §13.1) 『ウェブオペレーション』5章(2011、[[Adam Jacob]] 執筆)は、cfengine を「世界初のオープンソース構成管理ツール」と位置づけ、宣言的(declarative)・抽象化(abstraction)・べき等性(idempotency)・収束化(convergence)という4原則を cfengine が導入し、これらが AutomateIT・Bcfg2・[[Chef]]・[[Puppet]] など現代のさまざまな構成管理ツールに取り入れられていると説明する。具体例として、Cfengine 2 の `packages: sudo / action=installed` という宣言的構文を、命令的な `apt-get install sudo` と対比して示す。これは『ウェブオペレーション』3年前(2004年)刊行の *Principles of Network and System Administration* 第7章§7.4が cfengine を宣言的言語として make・Prolog と対比しつつ理論的に位置づけたのと同じ4性質(宣言的・べき等・収束的)を指しており、Web運用実務者コミュニティ側の理解が、Burgess 自身の理論的著作の記述と独立に同じ核心的性質へ収斂していることを示す。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1.1.3, [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] §7.4) [[@2003__LISA__ISconf - Theory, Practice, and Beyond]](USENIX LISA '03、[[Luke Kanies]])では、cfengine は congruence(合致)志向の ISconf と対比される convergence(収束)志向の CMS として位置づけられたうえで、Kanies 自身が両者を統合する実装を行った対象として登場する。Kanies は ISconf の host type と cfengine の class の書式がほぼ同一であることに着目し、パーサを Parse::Yapp / Parse::Lex で書き直して両者を相互に共有させ(ISconf の host type を cfengine の class として、cfengine の class を ISconf の host type として利用可能にする)、cfengine の完成度の高いファイルパーミッション・プロセス監視機能を ISconf の自作簡易ユーティリティの代替として即座に利用できるようにした。さらに、ISconf の stanza を host type 単位でしか部分展開できないというテスト上の制約を、cfengine の class によるより柔軟なグルーピングで緩和した。congruence 対 convergence を対立するパラダイムとして理論化してきた先行研究([[Steve Traugott]] ら)に対し、この統合実装は両者が直交し補完し合う関係にあることを実務的に示す反例として提示されている。(Source: [[@2003__LISA__ISconf - Theory, Practice, and Beyond]]) ## 関連 - ソース: [[@2000__LISA__Use of Cfengine for Automated, Multi-Platform Software and Patch Distribution]] / [[@2003__LISA__Seeking Closure in an Open World - A Behavioral Agent Approach to Configuration Management]] ## 出典 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](§5.1.1.3) — 世界初のオープンソース構成管理ツールとしての起源、宣言的・抽象化・べき等性・収束化の4原則 - [[@2005__Machine Learning__Principle Components and Importance Ranking of Distributed Anomalies]] - [[@1998__LISA__Computer Immunology]] — cfengine の収束的意味論と免疫系構想における位置づけ - [[@2004__Wiley__Principles of Network and System Administration - Chapter 2 System components]] — Unix/Windows比較表における一行言及 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 3 Networked communities]] — 多様な構成の維持コストを管理する自動化エージェント、ソフトウェアミラーリング手段としての言及 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 4 Host management]] — マスターファイルのコピー手段、デーモン権限降格手段としての軽い言及 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 5 User management]] — ファイル整理(tidy)・古いプロセスの終了によるユーザー資源制御 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 6 Models of network and system administration]] — 管理モデル類型学(モデル4)における実装例、pull型配布、収束的意味論による設定自動化 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 7 Configuration and maintenance]] — cfengine が主題として扱われる本拠地の章。宣言的言語としての設計、クラスによるアクション割り当て、冪等な収束操作、cronフロントエンドとしてのスケジューリング - [[@2004__Wiley__Principles of Network and System Administration - Chapter 8 Diagnostics, fault and change management]] — ディスク容量管理ゲームの自動整理システム、環境デーモンによる異常検知(図8.15) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 9 Application-level services]] — /etc/fstab編集の自動化、Tomcatサーブレット運用の設定例 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 10 Network-level services]] — SLAを機構化する2アプローチの一つとしての一文言及(§10.10) - [[@2004__Wiley__Principles of Network and System Administration - Chapter 12 Security implementation]] — MD5チェックサムによるデータ完全性検査(図12.1)、第7章の収束エンジン論のセキュリティ文脈への転用 - [[@2004__Wiley__Principles of Network and System Administration - Chapter 13 Analytical system administration]] — 「技術とアイデアは別物」を説明する導入例としての一文言及(§13.1) - [[@1998__LISA__Bootstrapping an Infrastructure]](執筆当時cfengineは開発初期段階だったため採用を見送り、makeベースの状態エンジンHostkeeperで代替した経緯。もし今から作るならcfengineを使っていただろうと述べる) - [[@2000__LISA__Use of Cfengine for Automated, Multi-Platform Software and Patch Distribution]] — cfengineのクラス機構を「RPM/MySQLで判定したインストール状態」を伝えるシグナル層として使い、構成編集・デーモン再起動などの後処理をcfengine本体の宣言的入力ファイルへ委譲する統合パターン。侵入検知(プロセス監視)と自動パッチ適用の実運用成功事例を報告 - [[@2003__LISA__Seeking Closure in an Open World - A Behavioral Agent Approach to Configuration Management]] — cfengineのようなconvergent(収束的)なツールでも、RPMインストールをリバースエンジニアリングしてcfengine宣言に置き換える慣行は既存のクロージャを破壊しうると批判し、コンダクト経由ではなく直接のファイル編集に頼る設計の限界を指摘する