# ISconf: Theory, Practice, and Beyond Navigation: [[index]] | [[overview]] ## Abstract(和訳) ISconf は、構成管理を自動化してきた長年の実務経験から発展した構成管理システム(CMS)である。利用可能な CMS の数が増えるにつれ、cfengine のような**収束(convergence)**に依拠するツールと、**合致(congruence)**を志向する ISconf との間に際立った対比を設けたうえで ISconf を使うべき理由を説明する試みがなされてきた。本論文は ISconf の本番運用経験——何が良く何が悪かったか——を論じ、ISconf の優位性を説明するために近年発展した理論を分析する。さらに、ISconf の受容された利用原則と真っ向から対立する、ISconf と cfengine を統合する経験についても論じる。この経験に基づけば、ISconf の実用上には深刻な限界があり、その利用を支持する提案済みの理論は不十分で説得力を欠く。ISconf は有用なツールであることは判明したが、任意の構成管理ニーズに対する十分に有用・強力な単独の解とはみなせない。 ## 論文情報 - 著者: [[Luke Kanies]](Reductive Consulting, LLC) - 会議: USENIX LISA '03(17th Large Installation Systems Administration Conference)、San Diego, CA、2003-10-26〜31 - 収録: Proceedings pp. 115–124 - 入手元: `full_papers/kanies/kanies.pdf`(HTML版もあり `full_papers/kanies/kanies_html/index.html`) - 著者の [[Luke Kanies]] は本論文執筆当時 Reductive Consulting, LLC を経営する独立コンサルタント。Reed College でChemistry(化学)の学士号を取得後、Unix による自動化・抽象化を専門としてきた。本論文での ISconf・cfengine への批判的検討の延長線上で、翌年以降 [[Puppet]](Puppetlabs)を開発することになる人物である(本論文自体には Puppet への言及はない)。 ## 概要 ISconf は元々 make のファイル(makefile)として始まったツールで、各ホストを make のターゲットとして扱い、ホストに対して実行すべきコマンド列を依存関係付きの stanza として記述する。2 度の全面書き直しを経ても、「ホスト名とコマンド列の対応をコマンド実行順に維持する」という基本機能は変わっていない。本論文は、ISconf の理論的基盤(決定論的順序決定・アトミック性)が実際には make の能力の範囲でしか実現できていないこと、実運用で頻発する具体的な失敗パターン、Traugott らが提示した「停止性問題への免疫」という理論的主張への批判、そして著者自身が行った ISconf と cfengine の統合実験という 4 部構成で ISconf を再評価する経験論文(position/experience paper)である。 ## 問題設定 ISconf は「収束(convergence)ではなく合致(congruence)を志向する CMS」として、cfengine のような収束型ツールと対比される形で理論武装が進められてきた。congruence とは、仕様から逸脱したホストを収束によって元の状態へ戻すのではなく、逸脱を検出したら仕様どおりに一から再構築するという立場である。著者はこの対立図式そのものと、それを支える理論的主張(決定論的順序決定・停止性問題への免疫)の妥当性を、自身の実務経験に照らして検証することを課題として設定する。 ## 提案手法(ISconf の仕組みと著者の統合実験) **ISconf の決定論的順序決定(deterministic ordering)**: make が持つ3つの性質——状態維持(stamp ファイルによる完了記録)・エラー時の即時停止・トポロジカルソートによる一貫した順序決定——を流用し、あるホストに対するコマンド列を「必ず記録された順序どおりに」実行することを保証する。この3性質はすべて make が本来持つ機能であり、ISconf 固有の実装ではない。 **アトミック性(atomicity)の欠如**: 決定論的順序決定には、失敗時にシステムを未変更の状態へ戻すアトミック性が本来必要だが、make にはこの機能がない。ISconf のシーケンス全体だけでなく、個々の stanza(例: 設定ファイルを変更しサービスを再起動する複数コマンドの組)についても、途中で失敗すると部分的に適用された変更が残り、人手による復旧が必要になる。stanza をべき等(idempotent)に書くことでこの問題を緩和できるが、それは ISconf が提供する簡潔さを損なう。 **cfengine との統合**: 著者は ISconf の host type と cfengine の class が概念的にほぼ同じフォーマットであることに着目し、パーサを Parse::Yapp / Parse::Lex で書き直して両者のフォーマットを一致させ、ISconf の全 host type を cfengine の class として、cfengine の全 class を ISconf の host type として相互に参照可能にした。cfengine 側の `istypes.cf`(ISconf の型情報から生成)を `AddInstallable` で読み込ませることで、cfengine が ISconf の状態を把握し、ISconf のブートストラップスクリプトを cfengine のファイル転送機能で置き換えるといった実装を行った(Listing 2 に設定例)。 ## 新規性 - 収束(convergence)対合致(congruence)という、Traugott らの理論的枠組みが前提としてきた対立図式そのものを、実運用者の視点から「直交していて両立可能」と再定義した点。 - Traugott らが「ISconf のみが停止性問題(Halting Problem)に免疫を持つ」と主張した理論([[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]])に対し、テスト済みシーケンスの本番成功が保証されない以上その免疫は他の CMS との差別化にならないと反証を試みた点。 - congruence 志向のツールと convergence 志向のツールを「対立するパラダイム」ではなく「補完的な機能」として統合する具体的な実装(ISconf の host type と cfengine の class の相互接続)を提示した点。 ## 実験設定(運用経験の位置づけ) 本論文に定量的な実験やベンチマークはなく、著者自身の Reductive Consulting における ISconf の長期本番運用経験と、ISconf–cfengine 統合プロジェクトの実装経験を根拠とする経験論文である。示される事例(Sun Solaris のパッケージ管理、`/etc/services` の追記・修正、DiskSuite のミラーリングスクリプトの SCSI→IDE 移行失敗など)はいずれも著者自身が実運用で遭遇した障害事例であり、統制された比較実験ではない。 ## 実験結果(観察された運用上の問題) - **latent precondition(潜在的な前提条件)問題**: `add_goodpkg` stanza が副作用として `/etc/services` に `goodpkg` エントリを追加していたことに気づかず、別の stanza `add_newservice` が同じファイルへ重複追記する事例。ISconf の stanza 間の暗黙の前提条件は、コメント等でドキュメント化されない限り把握できない。 - **stanza の書き換え不能性による cruft の蓄積**: 一度実行された stanza は名前も内容も変更できない(make が新規ターゲットと誤認するか、テスト済みでない新バージョンを別ホストで実行するリスクがあるため)。パッケージ管理を個別 stanza からワイルドカード方式のスクリプト(`pkg/%`)に刷新した後も、旧 stanza を置き換えられず、両方式が並存し続けた。 - **ソフトウェア老朽化(software rot)**: SCSI ディスクを前提に書かれた DiskSuite ミラーリングスクリプトが、Sun が IDE ディスク搭載機を出荷した後に無条件で失敗した事例。前提条件の変化を組み込みで検知する手段がない。 - **テストの限界**: テスト環境固有の前提条件(IP アドレス・ホスト名・ドメイン名など)にシーケンスが依存していると、テストでは成功し本番でのみ失敗する。著者はホストインストール・パッケージインストール・ホスト名長に関する障害を実際に経験している。 - **cfengine 統合後の具体的な効果**: cfengine の完成度の高いファイルパーミッション・プロセス監視機能を、ISconf 側で自作していた簡易ユーティリティの代替として即座に利用可能になった。ISconf の stanza 単位のテストが困難だった問題(ホスト type 全体にしか部分展開できない)も、cfengine の class による柔軟なグルーピングで緩和された。 ## 考察 著者は、ISconf が抱える問題の多くが make というエンジンの実装上の限界に起因するように見えても、根本的には「ISconf はホストと具体的なコマンドの対応関係を管理しているに過ぎず、コマンドが何をするかを理解していない」という設計そのものに起因すると論じる。コマンドをシンボリックな情報へ抽象化しようとすれば、それは ISconf の順序原則(exact order の維持)と直接衝突する——順序の一貫性を検証するには、何が行われているかを正確に知る必要があるからである。この点で、ファイル内容をシンボリックに管理する psgconf のようなツールとは設計思想のレベルで異なるとする。 Traugott らの停止性問題論への反論は、ISconf の理論的優位性の主張を実務的な観点(テストは本番成功を保証しない)から突き崩す一方で、著者自身も「この比較自体をあまり検討する価値があるとは思わない」と留保をつけており、議論の力点はむしろ実務経験に基づく限界の指摘に置かれている。cfengine との統合実験は、congruence と convergence を「二者択一のパラダイム」として理論化してきた先行研究への反例として提示され、両者を組み合わせることで「ISconf はホストへの作業列の割り当てに優れるが機能が乏しく、cfengine は機能が豊富だが順序制御に弱い」という相補的な関係を実証している。 > [!contradiction] [[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]](Traugott & Brown、congruence 志向・ISconf は停止性問題に免疫)と、本論文の主張(congruence と convergence は直交しており対立しない、免疫の主張は実務的に無意味)は正面から対立する。[[Steve Traugott]] 自身の主張と本論文の批判は突き合わせて読む必要がある。 ## 強み・弱点 **強み**: - 特定ツールの布教ではなく、5年以上の実運用経験に基づいて自身が長年使ってきたツールの限界を率直に指摘する、実務者による批判的検証として価値が高い。 - 「収束か合致か」という二項対立の理論的言説に対し、実装で両者を統合するという反証を提示した点は、後年 Puppet を開発することになる著者の設計思想の萌芽として読める。 - 停止性問題(Halting Problem)やチューリング等価性といった理論的主張に対して、テストの限界という実務的な観点から反論を試みている。 **弱点**: - 定量的な評価がなく、示される失敗事例はすべて著者個人の経験に基づく逸話(anecdote)であり、一般化可能性は検証されていない。 - 停止性問題への反論は「テストは本番成功を保証しない」という一般論にとどまり、Traugott らの理論の数学的な妥当性そのものには立ち入っていない。 - cfengine 統合の実装詳細(パーサ書き換え、`istypes.cf` の生成スクリプト)は具体性を欠き、再現性の検証が難しい。 ## 関連 - [[Luke Kanies]] — 著者。本論文での ISconf・cfengine への批判的検討がのちの Puppet 開発の土台になった。 - [[Steve Traugott]] — congruence 志向の理論的主張者。本論文はその理論(停止性問題への免疫)を批判する。 - [[cfengine]] — 本論文で ISconf と統合される convergence 型 CMS。 - [[収束型システム管理]] — congruence 対 convergence の対立図式そのものを扱う concept。 - [[べき等性]] — ISconf stanza のアトミック性議論に関連。 - [[@1998__LISA__Bootstrapping an Infrastructure]] — ISconf の起源となった makefile ベースの構想(Traugott らによる)。 - [[@2002__LISA__Why Order Matters - Turing Equivalence in Automated Systems Administration]] — 本論文が批判する停止性問題への免疫論の一次資料。 ## 出典 - Kanies, L., "ISconf: Theory, Practice, and Beyond," Proc. LISA XVII, 2003, pp. 115–124. https://www.usenix.org/legacy/event/lisa03/tech/full_papers/kanies/kanies.pdf