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へのアップグレードは完了だ。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください