# Towards a High-Level Machine Configuration System Navigation: [[../index|index]] | [[../overview|overview]] > [!abstract] 概要(abstract の日本語訳) > 本論文は、すべての設定パラメータを中央の「データベース」に格納する機械設定システムを提示する。このシステムは、機械が再起動するたびにデータベース内の変更を反映して自身を再構成するという意味で動的である。中央データベースを用いることで、設定を検証したり、ポリシー規則とネットワークの高レベルな記述から正しい設定を自動生成したりできる。すべての機械設定の永続的な記録が常に利用可能であり、新しいサブシステムの設定をモジュール式に扱えるようシステムは拡張可能である。本論文には、これまでに発表された関連研究と、ワークステーションのクローン作成・設定に関する一般的な技法のレビューを含む。 ## 論文情報 - 著者: [[Paul Anderson]]([[University of Edinburgh]] Computer Science Department, Laboratory for Foundations of Computer Science) - 会議: LISA VIII(USENIX Systems Administration Conference, 1994) - 公式ページ: https://www.usenix.org/conference/lisa-viii/towards-high-level-machine-configuration-system - **PDF は非公開**。オンライン公開版は ASCII テキスト(`anderson.a`)と PostScript(`anderson.ps`)のみで、PDF シグネチャを持つ原本は存在しない。本ページの本文抽出は ASCII テキスト版に基づく。 - この論文は後年 `lcfg`(local configuration system)として発展する設定管理システムの初出報告であり、著者自身が参考文献 [7] で引用する内部技術レポート(CS-TN-38, 1991)の後継にあたる。 ## 概要 エジンバラ大学計算機科学科(300〜400 台のワークステーション、約 2000 ユーザーの規模)向けに開発された `lcfg`(local configuration)システムを報告する論文。全ての機械固有の設定情報を中央データベースに保持し、機械はジェネリックなシステムソフトウェアとデータベースの情報だけから完全に再構築・複製できる。Sun ワークステーションを対象に実装されているが、プラットフォーム非依存な統一インタフェースを目指しており、Sun auto-install と連携する静的設定部分だけがプラットフォーム依存になる見込みだと述べている。 ## 問題設定 ベンダー提供のインストール手続きは大規模サイトでは以下の点で不十分だと整理する。 - ベンダー提供ソフトウェアしか対象にできず、ローカル・サードパーティ製ソフトウェアへ拡張できない。 - インタフェースが GUI 中心で、大量の機械を扱う自動化に向かない。 - 手続きが不完全で、`crontab` の手動設定や `inetd.conf` の手編集など追加の手作業が要る。 - 設定情報が機械自身に保存されるため、再インストールのたびに再入力が必要で、機械がダウンしている間は参照できない。 - 手続きがベンダー固有で、ヘテロジニアスな環境に向かない。 論文はこれらの問題への既存対応として、クローン作成(単一のテンプレートファイルシステムを手作りして複製する手法。Ohio State University・Athena・typecast・mkserv など)と、外部データベースへ設定情報を明示的に保存する手法(sad など)をレビューし、後者が前者より優れるとしつつも、その情報を「静的」(クローン作成時に焼き込み、以後データベースに依存しない)に使うか「動的」(起動のたびにデータベースを読む)に使うかで運用特性が変わると論じる。 ## 提案手法 - 全ての設定資源を `host.subsystem.attribute = value` 形式でマシンごとのフラットファイルに保持し、NIS で配布する(将来的には専用の低レベルプロトコルへの置き換えを想定)。 - 資源は C プリプロセッサを通して編集され、`#include` による共通ブロックの再利用や条件分岐で構造化されている(付録1・付録2 に実例)。典型的な大規模サーバは 70〜100 個、クライアントはその半分程度の資源で完全に記述できる(利用可能な全資源は約 400 個)。 - インストール時には静的設定として、データベースの情報から Sun auto-install 用の設定ファイル(機種・ディスクレイアウト・基本ソフトウェア構成)を生成する。初回リブート後にさらに追加のクライアント登録やソフトウェアロードを行うスクリプトが走る。 - 起動のたびに、`boot.services` 資源が指定するサブシステム一覧を読み、対応するクラススクリプト(約30種類。`auth`・`amd`・`dns`・`www`・`xdm`・`inet` など)を実行して各サブシステムを動的に設定する。`cron` から定期実行されるサブシステム(`updatelf`・`patch`・`update` など)もある。 - リモート操作クライアント `om` とデーモン `omd` により、ユーザー・ホスト・サブシステム・メソッドに基づくアクセス制御を伴った遠隔でのサブシステム停止・再起動・状態確認ができる。 - 独立プロセスがデータベースから情報を抽出できる性質を利用し、Perl スクリプトによる整合性検証(機械単位・機械間の依存関係チェック、例えば ethernet セグメントから最後の bootparam サーバを削除する際の警告)を行う。データベース内容の一部は WWW サービスとしても公開され、クライアントとサーバ・個人ワークステーションと所有者のホームページの間にハイパーリンクを自動生成する。 ## 新規性 - ベンダー非依存かつプラットフォーム横断を志向した、中央データベース駆動の動的設定システムという設計を、単一サイトでの実運用(数百台規模)に基づいて具体的に報告した点。 - 設定情報の「静的な焼き込み」と「動的な読み込み」という二分法を明示し、それぞれの利点・欠点(可用性への依存、変更の即時反映、ハードウェア関連パラメータの起動時変更不可能性など)を整理した点。 - 低レベルな資源記述("machine A is the name server for the research group" のような機械間の関係)から、名前サーバソフトウェアの導入・デーモン起動・クライアント側 `resolv.conf` 変更までを自動生成するという高レベル設定の構想、およびポリシー規則(例: 学生は教員の個人ワークステーションにログインできない)を明示的な規則として設定生成に組み込むという構想を提示した点。これは後年の宣言的な専用設定言語(§「高レベル設定」で議論、参考文献 [10] の Site 言語などを参照)の必要性の論拠となっている。 ## 実験設定 正式なベンチマークやユーザースタディは行っていない。エジンバラ大学計算機科学科の実運用環境(300〜400 台の Sun ワークステーション・X 端末、約 2000 ユーザー、約30種類のサブシステムクラス)での運用実績の記述と、付録に実際の設定ファイル例(サーバ機 Staffa、ディスクレスクライアント Gasker)を示すことで具体性を担保している。 ## 実験結果 正式な定量評価はない。運用上の効果として以下を報告する。 - 設定の変更・機械の完全な再構築が容易になり、設定が「腐る(rot)」ことなく常に最新の状態を保てるようになった。 - 新しいサブシステムを既存の機械に、他のサブシステムに干渉せずに容易に導入・設定できるようになった。 - データベースから明示的な機械設定を検証・閲覧できるようになったことで、サーバ撤去時の依存関係忘れなどによるエラーが減少した。 - 機械が自動的にデータベースの設定を反映するため、設定規則で指定したポリシーが実際に機械へ強制されているという確信が持てるようになり、セキュリティ面で改善した。 欠点として、機械の起動に要する時間が長くなること、正しい低レベル設定情報を手作業で作成する難しさを挙げている。 ## 考察 論文は、より高レベルにネットワーク上の役割や関係・ポリシーを記述し、そこから低レベル設定情報を自動生成するという方向性を今後の課題として位置づける。単純な例(名前サーバの割り当てなど)は既存の C プリプロセッサの機能で対応できるが、規則と相互作用が複雑化するにつれて専用の設定言語が必要になると論じ、そのような言語は高レベルな規則を明快に表現できると同時に、低レベル設定情報を生成できる拡張可能な設計でなければならないとする。短期的な課題として、追加サブシステムの組み込み、他プラットフォームへの移植、資源の保存・配布機構(NIS の限界)の改善を挙げている。 ## 強み / 弱点・課題 - 強み: 実運用規模(数百台)での長期的な知見に基づき、静的/動的設定のトレードオフを明快に整理している。中央データベースによる検証・依存関係チェックという、後の Infrastructure as Code / [[宣言的設定管理]] に通じる発想を早期に具体化している。 - 弱み・課題: 定量評価がなく、効果は定性的な記述に留まる。設定資源の配布に NIS を使う設計は、著者自身が「理想的ではない」と認めており(変更のたびに全データベースを配布する必要がある)、スケーラビリティの限界を内包する。高レベル設定言語は本論文の時点では構想段階(「現在調査中」)であり、実装や評価は示されていない。