[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:12257] Re: historical info



In <19990124234206W.oka@debian.or.jp>
[debian-users:12224] Re: historical info, Jan.24 '99 23:42 JST
oka@debian.or.jp says:
=   
=   タフなシステムは、最悪、人間が直接修正に入れる余地を残してお
=   いた方が無難で、完全に信頼できるブラックボックスを目指すと痛
=   い目に遭うと思います。だから dpkg と apt の二階層で、apt は
=   強要しないというDebianのスタンスは悪くないと思います(テキス
=   トなので、最悪、dpkg レベルのデータベースも手作業で修正でき
=   るし)。

そうですね。
問題解決の基本姿勢として「単純で機械的な作業は機械にやらせれば
いい。その分だけ人間は楽ができる」くらいでいいだろうと思います。
本質的な複雑さからくる脆弱さをfool-proofで糊塗するよりは、「こ
こはもう、どーもならん!」というところを明確にすることを考えた
ほうがいい。「押え込むのではなく、畳み込んでおく」です。


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

ところがこれじゃだめなんですよ ^^;
例えば、インストール当初は/varパーティション内の/var/spool/news
としてディレクトリを割り当ててもらったとしますよね、そのあと、
購読Newsgroupの増加にともなってnewsspoolを別パーティションに割っ
て/news にした、とかいうことが考えられますから。

つまり、これはシステムの構成管理の領域なんです。パッケージ/ パッ
ケージングシステム/ インストール・アンインストールのシステムが
参加する局面での管理対象として扱うのには無理があります。

システム全体としてSCM(Software Configration Management) の仕組
みがあって、その一部、または、それと連係する形で、パッケージ管
理を考える必要があると思います。で、それは、極力分けて考えたい。
「管理対象として考えてない」というのは、そういう意味です。

で、(引用前後します)

=   kenn> 単に一貫性をチェックするだけでなく、どの程度まで一貫性が失われ
=   kenn> たのかを計る事ができればなお有用でしょうね。
=   
=   そのためには、「一貫性」を明文化/仕様化するなりして、機械的
=   に扱えるよう準備をする必要がありますね。

これは構成管理側でやろう、と思ってます。

#難しい点はいっぱいありますが、別の話になるので。


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

#というより、それってまさしくGNU/Hurdの開発モチベーションです。


 -.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence