[debian-users:12224] Re: historical info

[Mitsuru Oka <oka@debian.or.jp>]

岡＠情報科学.高知大です。


"kenn"すなわち"Ken N."さんより:
kenn> =   もうちょっと現実的な事を挙げます。システム管理者がまだ未熟だっ
kenn> =   たり、冒険を冒して、とんでもない操作ミスをしてしまうっていう
kenn> =   のはどうでしょうか。

kenn> なるほど、人間系ですか。基本的にはfool-proofなものは作りたくな
kenn> いので、人間系によるものでない障害と同じリカバリプロセスを適用
kenn> することを考える事にしたいです。つまり、クリティカルな管理デー
kenn> タを明確にしておくことだけをシステム側ではやることにして、その
kenn> でーたをどう守るかについては、たとえばバックアップ運用をユーザ
kenn> 側で策定する(それほど大袈裟でなくてもいいけど)とかですね。

そう思います。複雑なものを抑え込もうとするとそれ自体が複雑さ
を作り出してしまうので駄目です(某NTとかいうのがそっち方向で
走っているような..)。

タフなシステムは、最悪、人間が直接修正に入れる余地を残してお
いた方が無難で、完全に信頼できるブラックボックスを目指すと痛
い目に遭うと思います。だから dpkg と apt の二階層で、apt は
強要しないというDebianのスタンスは悪くないと思います(テキス
トなので、最悪、dpkg レベルのデータベースも手作業で修正でき
るし)。

kenn> 単に一貫性をチェックするだけでなく、どの程度まで一貫性が失われ
kenn> たのかを計る事ができればなお有用でしょうね。

そのためには、「一貫性」を明文化/仕様化するなりして、機械的
に扱えるよう準備をする必要がありますね。


kenn> =   データの回復っていうのでちょっとまた変な考えが出てきました。
kenn> =   微分方程式系とか差分方程式系には、解の安定度みたいなのがあり
kenn> =   ますが、Debian システム(=系)をこういった式でシステムの状態空
kenn> =   間を大雑把にモデル化して安定度を判定できないかなー、と思った
kenn> =   りしました。

kenn> ＃くぅー、離散力学系ですか？非線形数学全開ですね。岡さんってそっ
kenn> 　ち方面の専攻なんでしたっけ？そういえば、ロジスティックスとか
kenn> 　やられてるようですが... それとも自動制御、非線形振動物理...

# 今の研究室はなぜかカオス・フラクタル系ですが、確かに自動制
  御でも安定性はだいぶやりましたね。でもフィードバック制御な
  んて計算機モデルとは対極的な気が...。
  # シーケンス制御ってことか。すみません、話逸れ過ぎです。


kenn> ただ、私のような業務アプリケーション方面のプログラマはたいてい
kenn> はもうちょっと還元主義的なアプローチをしますね(^^;つまり、複雑
kenn> さを取り払いあるいは畳み込む、簡素なものを組み合わせて複雑な問
kenn> 題に挑む、というような。

むろんそっちが正攻法ですよね。そのうち計算機パワーがあり余っ
てくると網のような自律システムに利点が見えてくるかもしれませ
んが。


kenn> あと、全然関係ないけど、自己回復能力が安定度に貢献しない場合も
kenn> ありますよ。アトラクタの中には重力源に接近すればする程系が不安
kenn> 定になるものもありますから。ご存知でしょうけど。

うむむ...。やっぱり修復は人間が手動でって事ですか。まあ勝手
にいじられる感覚はWindows的で嫌ですけど。診断ツール程度に留
めておけば、ある程度受け入れられるかな。


kenn> 一般的なモデルが出て来ないと思うんですよ。INN ならまだはっきり
kenn> していて、/var/lib/news/{history*,active} とかすぐに列挙できま
kenn> すが、より一般的に、あるアプリケーションがそのインストールから
kenn> アンインストールまでのライフサイクル中に生成したり継続して維持
kenn> したりするデータがあるとして、それをどうパッケージ構成管理側で
kenn> 把握するか、ということです。ファイル単位でこまごまと管理するプ
kenn> リミティブな管理か、さもなくば各パッケージ毎特化したものになる
kenn> か... いずれにしろ「管理開始」をインストール時におこない、アン
kenn> インストール時に「管理終了」するという切り方では無理だと思いま
kenn> す。

kenn> やるならディレクトリ単位の管理でしょうか。パッケージのインストー
kenn> ル事前条件として「私はライフサイクルスパン中で独自データを生成
kenn> する(そしてそのおき場所として/var/lib/newsを期待する)」という
kenn> のを設けておけば、これは管理下に置く事ができますね。

もちろんこれです。パッケージは、dpkgシステムを通して、ディレ
クトリの使用要求を行い、最後にはディレクトリごと解放される、
とか。でも tetex 系の /usr/lib/texmf 以下とか複雑ですよねぇ。
複数のパッケージが同じディレクトリを共有するために、リファレ
ンスカウンティングを導入してやらないと駄目ですね。あと、よく
ある同じファイル名だけど、ディレクトリだったりシンボリックリ
ンクだったりの競合とかをどう見るか。

ファイルのアクセス権限を最小限に制限するには、今のUIDやGIDを
階層化したり、動的に割り付けたりとか、気軽に使えるようにして
おくといいかもしれないです。いちいち root が vipw で編集なん
ていうのがどうかしてます。

# UNIX を切り込んでもきりがないなぁ...。
--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生