[debian-users:15161] Re: cracklib issue report

[Taketoshi Sano <xlj06203@xxxxxxxxxxx>]

佐野＠浜松です。

In article <14123.15562.689430.72159A@xxxxxxxxxxxxxxxxxxxxxxx>
 mizuhara@xxxxxxxxxxxxxx さん writes:

> つい先日私が「sendmail を exim に入れ替えたら /etc/rc2.d/S20sendmail が
> 残っていて、/usr/sbin/sendmail からシンボリックリンクが張られた exim が
> 実行されてしまう」というメールを出しまして、その後 debian のポリシーを
> 調べているのですが、どうも --purge しないと cron や rc スクリプトは削除
> しない、というのが debian 的には正しいようなんです。

 %%%%% 

 /usr/doc/debian-ja/FAQ/debian-faq-ja-6.html#ss6.5

設定ファイルは、通常/etc/の下に置かれますが、そのなかで
パッケージをアップグレードしてもパッケージ管理システムに
上書きされることのないものが、conffile に記述されています。
つまり、これらのファイルの内容のローカルな値が保存されることが
保証されます。また、稼動中のシステムのパッケージをきちんと更新
できるようにする、重要な機能です。

更新中、どのファイルが保存されるか正確に決定するには、
 dpkg --status package を実行して下さい。

 %%%%% 

 /usr/doc/debian-ja/FAQ/debian-faq-ja-6.html#ss6.11

6.11 パッケージ状態の unknown/install/remove/purge/hold とはどういう意味ですか?

これらの "want" フラグはユーザがそのパッケージをどう扱いたいかを
示しています。(ユーザが dselect を操作したときに "Select" セクションで
指示したか、ユーザが dpkg を直接起動したときに指示したように)。
それぞれの意味は以下の通りです。 

     unknown - インストールするかどうかユーザが表明していないパッケージ 
     install - ユーザがインストールまたはアップグレードしたいパッケージ 
     remove - パッケージの削除はしたいが、既存の設定ファイルは一つも
              削除したくないもの 
     purge - 設定ファイルを含め、完全に削除してしまうパッケージ 
     hold - 処理はしない、つまりどのような状態であれ現在の状態で現在の
            バージョンを維持するパッケージ 

 %%%%% 

  packaging.jis.html/ch-conffiles.html

9.1 dpkg による構築ファイルの自動操作 

パッケージは、conffiles と呼ばれるコントロール制御ファイル を含みます。
このファイルは、改行によって区切られた。自動構築のための設定 ファイル名
のリストです。リストされるファイル名は、絶対パスでなければいけ ません。
また、参照されるファイルはパッケージ中に含まれていなければいけま せん。

パッケージが更新されるとき、dpkg は、設定ステージにおいて、 設定ファイル
を処理します。設定ステージは、postinst スクリ プトを実行する直前です．

dpkg は、それぞれの設定ファイルについて、パッケージに含まれているものが
現在のバージョン(つまり、今アップグレードしようとしている)のパ ッケージ
に最初に含まれていたものと同一のものであるかをチェックします。同 時に、
現在のバージョンのパッケージで最初に提供されていたものと，現在システムに
インストールされているものとの比較も行います。

ユーザかパッケージ管理者のどちらがが設定ファイルを変更していない場合は、
設定ファイルはそのままインストールされます。どちらかが以前のバージョンの
設定ファイルを編集していた場合は、その編集されたバージョンが優先されます。
つまり、ユーザが設定ファイルを編集しており、パッケージ管理者が違った
バージョンを出していなかったなら、ユーザの変更はそのまま残されます。
けれども、パッケージ管理者が新しいバージョンを出していて、ユーザが設定
ファイルに手を加えていなかった場合は、新しいバージョンがインストール
されます(このとき、そのことを知らせるメッセージも表示されます)。
ユーザもパッケージ管理者も両方が設定ファイルを変更していた場合は、
ユーザが自分自身でこの問題を解決するように、入力を促すプロンプトを出力します。

この比較は、ファイル中の MD5 メッセージを計算することによって行なれます。
そして、そのインストールされた最新バージョンのファイル中の MD5 を同様に
保存します。 そのパッケージのインストールが初めてだったときは、dpkg は、
そのファイルが、現存システムのファイルを上書きするものでないかぎり、
そのままインストールします。

 %%%%% 

関連する資料を探してみました。

> 私はとても不便だと思うのですが、どうしてこういう仕様になっているか、
> ご存じの方いらっしゃいますか？

「dpkg --remove した際に設定ファイルを残す」という仕様自体は、
私は便利だと思っていました。ディスク容量の関係で一度にいろいろ
入れておけない場合など、設定を残したままで実行バイナリを入れたり
消したりできるので。

今回の sendmail -> exim	移行の問題については、 sendmail パッケージの
持つ設定ファイルである /etc/init.d/sendmail が "/usr/sbin/sendmail" を
デーモンの名前として呼び出しているのが原因だと思います。

 Debian Policy マニュアルを見ると (元を辿れば FSSTND によって) 
 "/usr/sbin/sendmail" は共通のメール送信インターフェイスとして
定められているので、 exim や smail が /usr/sbin/sendmail をリンク先に
持つのは当然だと言えます。

解決策としては、たぶん sendmail パッケージが実行バイナリの実体を
 /usr/sbin/sendmail ではなく、 /usr/sbin/sendmail-real のような
別の場所に置き、 /usr/sbin/sendmail へはリンクを張ること、また
 /etc/init.d/sendmail では /usr/sbin/sendmail ではなく実体の
置き場所を DAEMON として定義して start-stop-daemon に渡すようにする、
という方法が良いんではないでしょうか。

# Slink になって sendmail から exim に移行する人が増えたようだと、
# 既に BTS に登録されていたりするかもしれません。要確認。

-- 
     ＃わたしのおうちは浜松市、「夜のお菓子」で有名さ。
    <xlj06203@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)