Debian JessieからStretchにアップデート

ずっとDebian Jessieのままで放置しておくわけにも行かないので、Stretchにえいやっとアップデート。

MySQLからMariaDBに変更されたおかげでphpMyAdminのアップデートに失敗(データベース中のphpMyAdminのレコードの変換に失敗してインストールが進まない)したが、WordPressのインストール時の管理にしか使わず、以後はDisableしてるので特に問題はないと判断して無視した。しかし、データベースをダイレクトにいじらないといけないことになった時は、ちょっと困るなあ。いつかちゃんと再設定しよう。

それ以外については特に問題は生じなかった模様。外部から見えるサービスは無事に動いてる様子。やれやれ一安心。

「Debian JessieからStretchにアップデート」への3件のフィードバック

  1. その後、apt-get autoremoveを使って不要なパッケージを全部ごっそり削除したらWordPressがデータベースに繋げないというエラー発生。腹が立つのでついでのObsoleteになったパッケージも全部お掃除したあと、一から設定し直すかと覚悟。

    ところが、よくよく調べてみると旧PHP5のapacheモジュールがautoremoveで削除されてapacheでPHPが使えなくなっていたのが原因だった。というわけで、再度有効化してapacheを再スタートして無事回復。

    sudo a2enmod php7.0; systemctl restart apache2

    一時、ブラウザのキャッシュのお陰で自分のブログだけ何にも表示されてなくて焦ったけど、ブラウザのキャッシュをクリアしたら回復。

    ついでにphpMyAdminはMariaDB上の壊れたphpmyadminデータベースを削除して再インストールしてローカルLANからアクセスできるように再設定したけど、いらないからdisableしておこう。

  2. ずっと気がついていなかったのだが、Stretchにアップデートしてからiptablesのルールがずっと読み込まれてなかったらしい。iptables-persistentがどのランレベルで動いているのかチェックして見るためにsysv-rc-confで見るとiptables-persistentがどのランレベルでも動かない設定になぜかクリアされている。

    しかし、sysv-rc-confでiptables-persistentのランレベル2-5でチェックを入れて実行されるようにしても、正しくルールが読み込まれていない。おかしいと思って/etc/init.dを見てみるとどこにもiptables-persistentがないではないか。これではいくらサービスにチェックを入れたところでルールが読み込まれるはずもない。

    でよくよく調べてみるとどうやらiptables-persistentパッケージの依存で入るnetfilter-persistentパッケージが本体になった様に思える。実際、Stretchのiptables-persistentパッケージのファイルを見てもドキュメントしか含まれていない。一方、netfilter-persistentはちゃんと/etc/init.dの中に含まれている。ということはnetfilter-persistentを実行すれば読み込まれるのかと思ったが、よくよく調べてみるとnetfilter-persistentに実体が切り替わっただけではなく、Jessieの時点でSysV互換のinit.dからsystemdに起動システムが変更されたために、sysv-rc-confで設定しても意味がないことが判明。もしかすると、Jessieに上げた時点からiptablesのルールは無効になっていたのに気づいていなかっただけかもしれない、ひー。

    というわけで、systemdのサービス設定コマンドであるserviceコマンドを使ってnetfilter-persistentが起動するように設定する

    まずはsudo service –status-allでnetfilter-persistentのサービスが起動しない[-]の状態になってることを確認し、serviceコマンドを使って起動時にスタートする様に設定する。

    sudo service netfilter-persistent start

    もう一度サービスの起動ステータスを一覧して[+]になっていることを確認したら再起動。再起動したらちゃんとrules.v4とrules.v6が反映していることを確認する。

    sudo iptables –list
    sudo ip6tables –list

    何度か再起動して確認したけど問題なさそう。

    1. 残念ながら問題だらけだった。起動時に頻繁にルールの読み込みに失敗している。しかし、service netifilter-persistent reloadでちゃんとルールは読み込めているので、エラーの理由がまったくわからない。というわけで、信頼性の低いiptables-persistentは見限ることにする。

コメントを残す

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