# An Analysis of UNIX System Configuration
> [!abstract] 概要(abstract の日本語訳)
> オペレーティングシステムの構成ファイル管理は、UNIXシステム管理の本質的な一部である。これは特に、多数のコンピュータを抱える環境において特に困難である。
> 本論文はUNIX構成ファイル管理に関する研究を提示する。文献にある既存のシステムおよびツールを比較し、実務における構成ファイル管理のケーススタディをいくつか提示し、1つのサイトを詳細に検査し、構成プロセスに関する数多くの観察を行う。
## 論文情報
- タイトル: *An Analysis of UNIX System Configuration*
- 著者: [[Remy Evard]]([[Argonne National Laboratory]])
- 会議: 11th Systems Administration Conference (LISA '97)、1997年10月26日〜31日、サンディエゴ
- 掲載: Proceedings of LISA '97, pp. 179-193
- URL(公式ページ・HTML全文): https://www.usenix.org/legacy/publications/library/proceedings/lisa97/full_papers/20.evard/20_html/main.html
- PDF: https://www.usenix.org/legacy/publications/library/proceedings/lisa97/full_papers/20.evard/20.pdf
- 原本: `.raw/papers/lisa97-evard.pdf`(17ページ)
## 概要
本論文は、UNIXの構成ファイル(operating system configuration files。`/etc/passwd`・root の crontab・`/etc/inetd.conf` など)の管理を扱う研究である。著者は約30の異なるグループへの非公式インタビューをもとに、うち9サイトを匿名のケーススタディとして詳述し、加えて自身が4年間関わった Northeastern University 大学の設定を、構成ファイルごとのバージョン数・改訂回数という観点で詳細に分析する。これらの観察から、計算機のライフサイクルモデルと、ファイルの変化量に関する予想(conjecture)という2つの抽象化を提案し、より強力な構成管理の抽象化に向けた考察で締めくくる。
## 問題設定
システム管理はますます困難になっており、その最大の理由は分散システムにおける「サービスつまみ」(service knob、Rob Kolstad の比喩)が絶えず引き上げられ続けていることにある。ソフトウェア工学では複雑さを抽象化(関数・オブジェクト・データ構造)によって管理するのに対し、システム管理における抽象化はまだ未成熟である。
構成ファイルは、単一の計算機上では比較的単純で理解が進んでいる一方、数千台規模のネットワークでは綿密に計画された戦略を要する、複雑さの好例である。各構成ファイルはそれ自体は自己完結した問題だが、実際にはグループ化されて扱われるため、サイト全体の構成管理を包み込む抽象化の候補になりうる。著者は、構成ファイル管理の理解がシステム管理の他の側面(サイトの管理モデルや政治的な力学を含む)を理解するための足がかりになるとして、この主題を研究対象に選ぶ。
対象は主にUNIXの異種混在ネットワークに限定される。背景として、LISA I(1987年、Ken Stoneのディスククローニング論文)からLISA VIII(1994年、Anderson の lcfg・Harlander の GeNUAdmin・Imazu の OMNICONF・Rouillard と Martin の Config という4つの構成システムが同時に発表された年)に至る構成管理システムの歴史を概観し、それぞれが「既存ツールへの不満から生まれた」「個々のホストに適用すべき構成の中央データベースを保持する」という共通点を持つと指摘する。
## 提案手法
研究は3つの手法を組み合わせる。
1. **文献レビュー**: LISA を中心とした既存の構成管理システム(lcfg・GeNUAdmin・OMNICONF・Config・cloning + rdist 方式など)の歴史を概観する。
2. **サイトインタビュー**: 約30グループへの非公式インタビュー(電話・ホワイトボード越し・昼食時の会話)のうち、9サイト(Northeastern University 以外は匿名)を選んでケーススタディとして詳述する。各サイトについて環境規模・ビルド方式・構成方式(configure)・版管理(revision control)の有無を Figure 1(表1参照)にまとめる。
3. **1サイトの詳細分析**: Northeastern University の中央構成システム(NFSでエクスポートされた中央リポジトリ、RCS 管理、ホスト名・アーキテクチャ別の複数バージョン切り替え機構)を4年間観察し、構成ファイルごとの「バージョン数」(ホスト名/アーキテクチャ別に異なる版がいくつ存在するか)と「改訂回数」(RCS上の変更回数)を集計する(Figure 2・Figure 3)。
この分析から、著者は2つの抽象化候補を導出する。
**計算機のライフサイクルモデル**: 計算機は New(新規)・Clean(OSインストール済みだが未構成)・Configured(環境の要件どおりに構成済み)・Unknown(設定が崩れた/古くなった状態)・Off(退役)の5状態を遷移する。状態間を繋ぐプロセスは Build(OSインストール)・Initialize(構築直後の初期設定)・Update(要件変化に応じた更新)・Entropy(構成が崩れて Unknown 状態になる過程)・Debug(Unknown 状態から Configured 状態へ戻すデバッグ)・Rebuild(初期化からやり直す再構築)・Retire(退役)である。
![[fig04-machine-lifecycle.png]]
*図4(Figure 4): 計算機のライフサイクル。New・Clean・Configured・Unknown・Offの5状態と、Build・Initialize・Update・Entropy・Debug・Rebuild・Retireの7プロセスからなる。*
**変化量の予想(Change Magnitude Conjecture)**: Northeastern の観察(passwd や amd.home のようにユーザ単位の情報を持つファイルが最も頻繁に変化し、環境全体を定義するファイルほど変化が少ない)を一般化し、ファイル集合を次の4種に分ける。
- U: 特定ユーザの利用形態に関する情報を持つファイル
- G: 特定グループの利用形態に関する情報を持つファイル
- E: ネットワーク内で機能するサービスや環境のアーキテクチャを定義するファイル
- I: 中央集約された情報資源を参照してサービスを初期化するファイル
このとき、ある定数 k>1 が存在して C(U) ≥ kC(G) ≥ k²C(E) ≥ k³C(I) が成り立つと予想する(C(X) は X型ファイルが変更された回数)。著者自身、この予想は未だ形式的に証明されておらず、各集合のより厳密な定義が今後必要だと明記している。
## 新規性
- LISAコミュニティにおける構成管理システムの個別事例研究(cloning・NIS・lcfg等)を横断的に比較し、9サイトの実務パターンを匿名ケーススタディとして体系的に提示した点。
- 単一サイト(Northeastern University)の構成ファイル群を4年分にわたり「バージョン数」と「改訂回数」という2軸で定量化し、ファイルの性質(ユーザ単位/グループ単位/OS単位/サービス単位)ごとに変化パターンが異なることを示した点。
- 計算機の状態(New/Clean/Configured/Unknown/Off)とそれらを結ぶプロセス(Build/Initialize/Update/Entropy/Debug/Rebuild/Retire)からなるライフサイクルモデルを提案し、構成管理の抽象化に必要な要件(環境定義へのアクセス、build/initialize/update/debugの各プロセスの実行・代替能力)を導出した点。
- ファイルの変化頻度が対象範囲(ユーザ<グループ<環境<初期化)に応じて桁単位で異なるという変化量の予想を提示し、「最も頻繁に変わるファイルほど、変更が及ぼす影響範囲を小さく保つべきだ」という設計指針を導いた点。
## 実験設定
- サイトインタビュー: 約30グループとの非公式インタビューのうち9サイトを選定。規模は30台(Site 5)から6000台規模(Site 3: 1000 Sun + 5000 X端末)まで幅がある。
- Northeastern University の詳細分析: 中央NFSリポジトリでRCS管理された構成ファイル群を対象に、4年間(投稿時点)のバージョン数・改訂回数を集計。加えてNISで配布される主要マップ(passwd・group・netgroup・amd.home等)についても同期間の改訂回数を集計。
## 実験結果
9サイトの環境属性は次の表(Figure 1)にまとめられる。
| Site | 環境 | ビルド方式 | 構成方式 | 版管理 |
|---|---|---|---|---|
| 1 | 100台各種 | メディア + スクリプト | NIS, file push | RCS |
| 2 | 70台 dataless Sun | コピー | NIS, 編集 | RCS |
| 3 | 1000台 Sun | ディスククローン | NIS, rdist | - |
| 4 | 900台 Sun | JumpStart | NIS, rdist | .bak |
| 5 | 30台 SGI | メディア | NIS, 編集 | - |
| 6 | 350台 Sun | JumpStart / クローン | NIS, cronコピー | - |
| 7 | 100台各種 | メディア + スクリプト | NIS, 編集 | - |
| 8 | 100台各種 | メディア + スクリプト | NIS, rdist | RCS |
| 9 | 50台 Alpha | Digital UNIX install | rdist | RCS |
*表1(Figure 1): 9サイトの環境属性(規模・ビルド方式・構成方式・版管理の有無)。*
主な観察:
- ほぼ全サイトがNISを利用するが、対象マップ数はサイトによって大きく異なる。NIS+を使うサイトは(Sun専業サイトでも)皆無だった。
- 単一の「正しいやり方」に落ち着いているサイトは無く、大半のサイトが複数のビルド方式・複数の構成方式を併用する(Site 6はJumpStartとディスククローニングを併用)。
- 50台以上のサイトはほぼ例外なく集中管理・自動ビルドの仕組みを持つが、サーバ群自体は10台規模のサイトが自分の全環境を管理するのと同様の、より場当たり的な方法で管理される傾向がある。
- 一度採用した戦略(JumpStart、Auspexなど)から離れることは非常に困難であり、これがOSの大規模アップグレードや新アーキテクチャ導入を難しくする一因になっている。
- 更新配布はすべてpushベースであり、ホストやユーザ起点の明示的なpullを行うサイトは無かった。
Northeastern University の構成ファイル分析結果は次の表(Figure 2、抜粋を含む全項目)にまとめられる。
| ファイル | バージョン数 | 改訂回数 | 種別 |
|---|---|---|---|
| amd | 2 | 1-2 | 管理ツール |
| cops.cf | 3 | 1 | 管理ツール |
| etherdown | 1 | 1 | 管理ツール |
| newsyslog | 2 | 1-3 | 管理ツール |
| rotlogs | 1 | 1 | 管理ツール |
| staticroutes | 1 | 1 | 管理ツール |
| sudoers | 1 | 1 | 管理ツール |
| super-users | 3 | 50 | 管理ツール |
| watchmerc | 11 | 1-4 | 管理ツール |
| crontab | 7 | 1-4 | cron関連 |
| daily | 16 | 2-26 | cron関連 |
| hourly | 5 | 3-11 | cron関連 |
| monthly | 4 | 1 | cron関連 |
| weekly | 10 | 2-11 | cron関連 |
| bootparams | 1 | 1 | OS |
| bootptab | 1 | 5 | OS |
| exports | 3 | 1 | OS |
| format.dat | 2 | 2/3 | OS |
| fstab | 1 | 1 | OS |
| group | 4 | 1-2 | OS |
| hosts.equiv | 1 | 1 | OS |
| inetd.conf | 11 | 4-15 | OS |
| magic | 1 | 1 | OS |
| nis | 1 | 6 | OS |
| passwd | 45 | 1-10 | OS |
| securenets | 1 | 3 | OS |
| securettys | 3 | 1 | OS |
| services | 4 | 1-2 | OS |
| shells | 2 | 1-3 | OS |
| svc.conf | 2 | 1 | OS |
| syslog.conf | 8 | 1-7 | OS |
| termcap | 2 | 3 | OS |
| ttys | 2 | 1 | OS |
| ttytab | 10 | 1-2 | OS |
| rc | 5 | 2-3 | OS bootup |
| rc.local | 11 | 4-14 | OS bootup |
| rc.priv | 25 | 1-17 | OS bootup |
| hosts.lpd | 1 | 1 | printer |
| printcap | 10 | 1-10 | printer |
| aliases | 1 | 2 | service |
| ftpusers | 1 | 1 | service |
| hosts.allow | 9 | 6-16 | service |
| hosts.deny | 6 | 3-6 | service |
| lbcd | 1 | 1 | service |
| mrouted.conf | 4 | 1-6 | service |
| ntp.conf | 4 | 3 | service |
| resolv.conf | 6 | 1-4 | service |
| sendmail | 2 | 1 | service |
| sendmail.cf | 2 | 2 | service |
| zshenv | 1 | 5 | shell |
| profile | 1 | 5 | shell |
| profile.bash | 1 | 4 | shell |
| tcsh.cshrc | 1 | 6 | shell |
| Xconfig | 1 | 1 | X config |
| xlogin | 1 | 1 | X config |
| Xsession | 1 | 1 | X config |
| Xsetup | 1 | 1 | X config |
| Xstartup | 1 | 1 | X config |
*表2(Figure 2): Northeastern の構成ファイル一覧。「バージョン数」はホスト名/アーキテクチャ別に存在する版の数、「改訂回数」は4年間のRCS上の変更回数(版ごとの範囲)。*
NISで配布される主要マップの改訂回数は次の表(Figure 3)のとおりである。
| ファイル | バージョン数(改訂回数相当) |
|---|---|
| amd.ftp | 5 |
| amd.home | 3241 |
| amd.net | 132 |
| amd.proj | 127 |
| archtree | 4 |
| bootparams | 3 |
| ethers | 2 |
| group | 415 |
| hosts | 4 |
| netgroup | 2000+ |
| netgroups.aux | 3 |
| netmasks | 1 |
| networks | 1 |
| passwd | 3913 |
| protocols | 1 |
| publickey | 1 |
| rpc | 3 |
| services | 22 |
| ypservers | 38 |
*表3(Figure 3): Northeastern におけるNIS主要マップの改訂回数。*
これらのデータから、著者はファイルをO(1000)・O(100)・O(10)・O(1)の桁でおおまかに分類できるとする。O(1000)のamd.home・passwd・netgroupはアカウント作成・利用に直結しユーザ数に比例して変化し、O(100)のamd.net・amd.proj・groupはグループ単位のディスク追加や可視化の変更に対応し、O(10)のservices・ypserversは新サービス追加や組織変更に対応し、O(1)のファイルはほぼ未使用または一度設定されて放置される。
配布責任(Figure 5)については、システム管理者が全ての変更領域(OS・ソフトウェア・ユーザ空間・glue)の「構成」に関与するが、「初期の責任」はOSがベンダ、ソフトウェアがサードパーティ、ユーザ空間がシステム管理者、glueがシステム管理者と分かれる。
| 領域 | 初期責任 | 構成責任 |
|---|---|---|
| OS | ベンダ | システム管理者 |
| ソフトウェア | サードパーティ | システム管理者 |
| ユーザ | システム管理者 | ユーザ |
| Glue | システム管理者 | システム管理者 |
*表5(Figure 5): 変更領域ごとの初期責任と構成責任。*
## 考察
著者は、経験豊富なシステム管理者の間では「システム構成管理は既に理解されている分野で目新しいことはない」という認識がある一方、調査対象のほぼ全員が現行システムへの強い不満を表明しているという「不穏な二律背反」を指摘する。LISAコミュニティが開発してきた高度なツールが、訪問先のどのサイトでも実際には使われておらず、各サイトは rdist や NIS の上に自作ツールを重ねている実態を報告する。
構成管理の抽象化を強化するための方向性として、(1) ホストへの変更をプッシュする発想から「環境全体を更新する」という発想への転換、(2) aliasesファイルの例のように変更をネットワーク側(ホストから離れた場所)へ移行させるモデル、(3) 現状から目標状態へ変更を加える「configure from」に対し、望む最終状態だけを記述してホスト側が到達方法を決める「configure to」(MIT Athenaプロジェクトが採用したが広く普及しなかった)、(4) ツール・手法を計測・評価するための計装(instrumentation)、を挙げる。
## 強み / 弱点・課題
- 強み: 文献レビュー・9サイトの匿名ケーススタディ・1サイトの4年分の定量分析という3つの異なる粒度の証拠を組み合わせ、構成管理の実務パターンを抽出している点。ライフサイクルモデルと変化量の予想という2つの抽象化候補を、単なる思弁ではなく実データの観察から導出している点。
- 弱点・課題(本文に明記された限界): サイト数(9)は「業界全体を代表するには小さすぎる」と著者自身が明記しており、一般化には注意が必要である。変化量の予想はU/G/E/Iという集合の厳密な定義を欠いたままの「疑似数学的」な提案にとどまり、著者自身「まだ形式的に証明されていない」と述べる。Northeastern の分析は同一著者が長年関与した単一サイトに基づくため、他サイトへの適用可能性は未検証である。