Debian busterからbullseyeへのアップグレード

先日、ObsoleteになるPython2.7に依存したmailman2をmailman3へと移行したのは、busterで動いていたこのサーバーをbullseyeへアップグレードするためだ。ファイルシステム全体のバックアップもできるようになったので、念のためファイルシステムを一度全部dumpした後、Debianを最新に更新することにした。

busterからbullseyeへのアップグレードはいろんなところに情報があるので割愛。まあ、いつも通り/etc/apt/sources.listをbullseyeに書き換えて、apt updateからのapt full-upgradeをするだけだ。

途中、mailman3のパッケージの更新時にデータベース設定の対話的ダイアログが出てきた。本来ならすでに設定済みのmailman3ではこれを聞いてはいけないはずだが、最初のダイアログで自分でやるから勝手にすんな、を選んでやれば設定をぶち壊されずに済む。あと、mailman3-webも設定を新しいデフォルトに置き換えようとするが、すでに設定済みのローカルファイルを残すように指示してあげる必要がある。

すべてのパッケージが更新されたら再起動して、サービスがちゃんと動いているかを確かめると、あらら、いろいろ動いていないじゃないの。具体的にどんなサービスが動いていないかは以下のコマンドで見ることができる。

systemctl list-units –type=service

サービス起動に失敗したサービスは赤字で表示される。

このうち、uwsgiのサービスが動いていない理由は、どうやらsystemctlの古いユニットファイルが残っていて、そのユニットファイルに基づいて起動しようとして失敗しているようだ。このような問題はrcステートになっている設定だけが残骸で残っているパッケージを総パージしてあげればよい。

apt purge $(dpkg -l | awk ‘/^rc/ { print $2 }’)

これで大丈夫かと思ったら、なんとmailman3が動いていない。いろいろと調べてみるとどうも/var/lib/mailman3/data/内にlist:listな所有権でないファイルがパッケージの更新によって出現してしまったからのようだ。というわけで、このディレクトリ内の所有権が間違ってるファイルをlist:listにchownしてあげればサービスが起動する。

あと、sslまわりの証明書を用意しないと文句を言って起動しないdovecotはこのサーバーでは必要ないので自動起動しないように設定した。

サービスがなぜ起動しないのかについては、実際に

systemctl start サービス名

でサービスを起動してみると、エラーメッセージがちゃんと表示されるので、それを見ると原因追及がはかどる。

これで必要なサービスを一通りちゃんと起動できるようにしたら、実際にそれらのサービスが外部から見て正しく動いているかどうかを確認して、ようやくDebianのbullseyeへのアップグレードは完了だ。

minissdpdの再設定

いつの間にやらminissdpdというデーモンがDebian busterなこのサーバーで動いていた。というか、動いていなかった。というのも先日、USB接続のNICを交換した後、どうやら立ち上がっていなかったようなのだ。

このデーモン、いったい何をするものなのかというとどうやらLAN内のUPnPなサービスのアナウンスを自動的にキャッシュしてUPnPなサービスのディスカバリーを高速化するためのものらしい。

で、これが動いていないと何が問題かというとbusterからbullseyeへのアップグレードを行ったときに、minissdpdのパッケージが更新された後、サービスの起動に失敗してapt full-upgradeの進行がその時点で中断してしまうからだ。

で、このデーモン、やっかいなことにパッケージインストール時の対話的なダイアログを使ってその時点でのネットワークインターフェースを/etc/default/minissdpdに書き込んでしまう。これがデーモン起動時のデフォルト設定として使われ、それ以外にはユーザーが変更可能な設定ファイル等をおかないというはなはだ時代錯誤な仕組みになっているのだ。

というわけで、NICが変更されるたびにパッケージの再設定が必要になる。

dpkg-reconfigure minissdpd

デーモンを自動起動するかどうか、有効にするインターフェース名、IPv6を使用するかどうかを答えれば再設定される。しかし、UPnPというユーザー側がわざわざ設定しなくても自動で接続できるサービスのためのツールが、いちいち手動でインターフェースを明示的に再設定しないと動かないというのは本末転倒だよな。

余談だが、これを行えばパッケージのアップグレードは進行するようになるものの、このデーモン、ネットワークが有効になるのを待たずに起動しようとするという、systemctlのお作法でちゃんと依存関係を設定してないバカなデーモンなのだ。結果、USBデバイスが有効になるまでインターフェースが起動しないUSBなNICではスタートアップ時の起動に失敗する。

このminissdpdはどうやらtransmission-daemonの依存上流で入っているものの、transmission-daemon自体はこれがサービスで動いていなくても問題なく動くらしいので、さっきの対話的設定でスタートアップ時に起動しないように設定することにした。さらば。