[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