備忘録 for myself in the future

Debianのaptを使ってパッケージのアップデートを行っていると、パッケージが更新された場合に古いパッケージは自動的にremoveされる。しかし、purgeされるわけではないのでバージョン依存の設定情報があるパッケージなどは設定が削除されずに残ってしまう。そのため、dpkg –listでインストール済みのパッケージ一覧を取得すると先頭のパッケージの状態がrcとなっていつまでもゴミとして一覧に残り続けることになる。

まあ残っていても別に実害はないのだが、linux-imageなどはどんどん古いバージョンがrc状態で積み重なってしまうため、dpkg –listが無駄に長くなることになり精神衛生上よくない。そこで、このrc状態のパッケージを簡単に一掃したくなる。そんなときはこのコマンド。

dpkg –list | grep “^rc” | cut -d ” ” -f 3 | xargs sudo dpkg –purge

これでインストール済みのパッケージの一覧からrc状態のパッケージだけを抜き出し、そのパッケージ名だけを切り出した後、すべてpurgeしてくれる。一応、念のために最後のパイプだけを外した状態でリストを出してみて、ほんとにrc状態のパッケージだけが抜き出されているかをチェックした方が安全である。

dpkg –list | grep “^rc”

でrc状態の一覧を取得し、

dpkg –list | grep “^rc” | cut -d ” ” -f 3

でそのパッケージ名だけがちゃんと抽出されていることを確認したのちに、purge実行だ。

Debianでサーバーを運用していて生真面目にアップデートを当てていると、だいたいいつの間にか古いkernelが溜まってしまうことになる。Debian的お作法でいくとだいたい/bootパーティションは別に分けるので、あまりにもたくさんのkernelが溜まるにまかせるといつの間にか/bootパーティションが古いkernelでパンクして新しい更新されたkernelのインストールに失敗するなんてことになる。とはいえ、新しいkernelに問題があった場合に備えて古いkernelを少しは残しておきたいし、いちいち新しいkernelが降ってくるたびにインストールされたlinux-imageパッケージの一覧を取得してどのkernelを残すか考え、手動でpurgeする作業をしていたが、さすがに面倒になってきた今日この頃。そこで、とうとうbyobuスクリプトをインストールすることにした。byobuは本来はターミナルマルチプレクサをtmux上に実現するスクリプトだが、同梱されているスクリプトの中になぜかkernelを整理するスクリプトが存在する。tmuxを普段使わない身としてはそのスクリプトだけ別にパッケージ化してもらいたいものだが、そうもいかないのであきらめてbyobuと依存するtmux等も一緒にインストールする。インストールはDebianでも一発だ。

sudo apt install byobu

これで依存するtmuxやらなんやらと一緒にインストールされる。

さて、実際に古いカーネルをpurgeする場合は新しい順にいくつのkernelを残した状態にするかを指定してpurge-old-kernelsを実行する。例えば、今bootしている最新のkernelに加えて、一個前の古いkernelを安全のために残したい場合は、2個のkernelを残すということで以下のように実行する。

sudo purge-old-kernels –keep 2

あとはpurgeすべきkernelがあった場合は削除処理をしてくれるので、対話的に実行すればよい。このスクリプトは–keepオプション以外のオプションを単純にaptに渡すだけのwrapperなので、対話的にしたくなければaptですべての質問にyesと答える-qyオプションをつければいいだろう。

あとは、/bootが足りなくなってるなと思ったときにこれを実行するだけだが、毎日のサーバーのリポートメールでついついパーティションごとの空き容量をチェックするのを忘れちゃうんだよね。

予備機としてUbuntuをインストールして使っている予備機はグラボにAMD Radeon HD 7750が刺さっている。先日、このグラボが認識されなくなるトラブルが起き、原因はマザーボードの電池切れだったことが分かって電池を交換して組み立てなおしたのだが、そのついでにUbuntu19.10を入れたついでにAMD提供のLinux用ドライバーを入れようと思ったら、LTSバージョンのUbuntuにしか対応していない。どうすんの？と思ったら、どうやらこのドライバーのオープンソースバージョンはすでにLinux Kernel 5系列に取り込まれていて、それが単に有効化されていないだけだということが判明したので、有効化する方法を記録しておく。

HD 7750は命令セットがSouthern Islandsと呼ばれる世代である。通常のUbuntu19.10のKernelはradeonドライバーが有効になっているので、これを無効にして代わりにamdgpuドライバーをSouthern Islandsのグラボであることを明示して有効化する。有効化に必要な場所は二か所。一つはGRUB2の設定。これを有効にしておかないとブートが途中で止まってしまう。もう一つはKernelのmoduleの設定を変更する。

まずはGRUB2の設定。/etc/default/grubにパラメーターを追加する。追加するのはGRUB_CMDLINE_LINUX_DEFAULTの項目。すでに書いてあるであろうパラメーターの前に以下のパラメーターを追加する。

radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=0

これでradeonドライバーが起動時に無効になり、amdgpuドライバーのSouthern Islands用が有効になる。

次はKernelモジュールの設定。/etc/modprobe.d/に二つファイルを追加する。

一つはradeonドライバーの無効化。/etc/modprobe.d/radeon.confというファイルを以下の内容で作成する。要root権限。

options radeon si_support=0
options radeon cik_support=0

もう一つはamdgpuドライバーのSouthern Islands用の有効化。/etc/modprobe.d/amdgpu.confというファイルを以下の内容で作成する。もちろんこちらも要root権限。

options amdgpu si_support=1
options amdgpu cik_support=0

GURB2の設定のアップデートとinitramfsのアップデートが必要。要root権限。

update-grub2
update-initramfs

これで再起動すれば読み込まれるディスプレイドライバーがradeonドライバーからamdgpuドライバーに切り替わる。

Debian 9 Stretchで運用してきたこのサーバーをまだ当分この状態で運用したいので、この機会にDebian 10 Busterにアップグレードすることにした。

まずはDebian 9 Stretchにアップグレードした時に放置していたネットワークインターフェースの名称変更を実施。Debian 8までは伝統的なeth*というインターフェース名が使われていたが、10ではこれがデバイスのハードウェア的な接続場所に応じた固定的な名前しか使えなくなる。だから、移行措置期間の9のうちにインターフェース名を変えておく必要がある。

公式のリリースノートに従って新しい名前を調べ、/etc/network/interfacesにあるインターフェース名を変更し、新しい名前を有効にしてinitramfsを再構築させたが、実際は起動したら全然違うインターフェース名だった。どうやらUSB接続されているインターフェースの命名規則はMACアドレスを使う命名法になるので、リリースノートの手順では正しい名前が得られないらしい。というわけで、冷静に/sbin/ifconfig -aで新しいインターフェース名を一覧から取得し、これで設定しなおして無事にインターフェース名の変更が終了。

あとはパッケージリポジトリをStretchからBusterに変更してインストール済みパッケージをroot権限になって更新する。

apt update

apt-get upgrade

apt full-upgrade

途中、コンソールのLANGをen_US.UTF-8に戻しておくのを忘れてコンソールのメッセージが全く読めなくて焦ったが、9から10へのアップグレードは予想以上に何も聞いてこなかったので助かった。エラーもなく全パッケージのアップデートが完了したので再起動。最初、ネットワークインターフェースが上がらなくて起動しないトラブルが起きたが、一度電源を切ってから再起動したら問題なく起動したので良しとする。

バージョンが確かに10に上がってることを確認したのちに、サーバーのサービスがちゃんと動いているか調べたところ、WordPressだけが正しく動いていなかった。調べてみると、php7.0とphp7.3が重複インストールされた状態になっていたので、php7.0をアンインストール。それにともなってapache2のphp7.3モジュールがアンロードされた状態になっていたので、a2enmodコマンドで明示的に有効化。これで大丈夫と思ったらアクセスしても何も表示されなくて焦ったが、単にブラウザのキャッシュの問題だったので、リロードしたら無事に表示された。

最後にobsoleteになったパッケージを以下のコマンドでチェック。

aptitude search ‘~o’

ほとんどのパッケージが移行のためのダミーパッケージか、もっと新しいバージョンがすでにインストールされているかなので問題なく削除できるのだが、phpmyadminがobsoleteになってしまったのは困った。これは非常に多くのphpやmariaDBがらみのパッケージが依存関係で入っているので、普通にremoveするとおそらくWordPressに必要なパッケージまでautoremoveされてしまう。そこで、この記事を参照してBuster環境でWordPressを手動でインストールするときに推奨されているパッケージを手動でインストールして、パッケージをautoremoveされないように「手動でインストールしました」フラグを立てておいた。その後、phpadminが依存関係で自動的に入れた状態になっているパッケージをphpadminごとautoremoveで取り除いた。

で、その状態でもWordPressが正しく動いているのを確認できたので、無事にBusterにサーバーのアップグレードを完了。

唯一心残りだったのが、Debian 10に至っても内蔵のRTL8111Gのドライバがおかしくてネットワークが使えないことか。結局、USB2-Gigabitという情けないアダプターをこれからも使い続けることに。

また新たなCPU脆弱性が発見された。今度の奴はMDSと呼ばれるらしい。以前にもSpectreやMeltdownなどのCPU脆弱性が発見されているが、またしても同じような脆弱性の発見である。

このサーバーはユーザーがログインして勝手にプロセスを走らせたりできない純粋に個人使用のサーバーなので、外部から悪意をもったコードを無理やり走らせることはほぼ不可能であるが、さすがにこうもCPU脆弱性の発見が相次ぐと念には念を入れてCPU脆弱性対策をしておいた方がいいような気がしてきた。

さて、このサーバーはIntel Celeron 847で動いているので、もろもろのCPU脆弱性をばっちり抱えているので対策が必要である。この手のCPU脆弱性に対処するには、何らかの方法でCPUの挙動を修正する対策済みMicrocodeで本来のCPUが持っているMicrocodeを上書きしてあげる方法がSpectre/Meltdown騒ぎの時に確立した。IntelのCPUごとの対策状況の資料を見ると、最新のIntelのMicrocodeはCeleron 847で動作検証済みということなので、この方法で対処できることが判明した。Microcodeを読み込ませる方法はいくつかあるが、最も安心なのはBIOSで上書きする方法である。しかし、残念ながらこのサーバーのマザーボードは古いので、何年も前からBIOSの更新が止まっている。となると、OSレベルでMicrocodeを読み込ませるしか方法がない。というわけでDebianの起動時にMicrocodeを読み込ませることにする。

Microcodeのアップデートは二段階である。まずKernelが脆弱性対策済みのバージョンになっていることである。これは、常時Kernelパッケージを最新に更新しているこのサーバーでは問題なくクリアしている。

次に必要なのがintel-microcodeパッケージのインストールである。とりあえずパッケージツリーに含まれているか、探してみる。最近、ようやくapt-getを捨ててaptコマンドに移行したので、以下のコマンドで探してやる。

apt search intel-microcode

パッケージツリーには存在するものの、インストールはされていないことが分かる。もし、ツリーに見つからないときはおそらくcontribとnon-freeのパッケージが/etc/apt/sources.listから欠落しているので足してあげよう。次に、パッケージをインストールする。

sudo apt install intel-microcode

これで依存関係のあるiucode-toolと一緒にintel-microcodeパッケージがインストールされる。intel-microcodeパッケージは起動時に修正済みMicrocodeをCPUに上書きするので、起動時に必要なファイルが収められているinitramfsの内容が自動的に更新される。あとは、再起動させてやると起動プロセス中にMicrocodeの上書きが行われて脆弱性対策は終了である。

一応、正しくMicrocodeの上書きが行われたかを確認しておく。

sudo dmesg | grep “microcode updated early to”

起動プロセス中の動作はdmesgに出力されているので、実際に上書きが行われていればそのログに上書きされたMicrocodeのリビジョンが出力されている。以後は、普通にいつもどおりパッケージのアップデートを怠らずに実行していれば、将来のCPU脆弱性についてもパッケージのアップデート操作で追加対策が自動的に行われるはずである。

DebianのパッケージアップデートでPostfixが更新された後、妙な警告がログに出ていることに今更気が付いた。メールを送る流量が極端に低いサーバーだから、むしろよく気が付いたと自分を褒めたい。

出ていた警告は以下の通り。

Postfix is running with backwards-compatible default settings

To disable backwards compatibility use “postconf compatibility_level=2” and “postfix reload”

See http://www.postfix.org/COMPATIBILITY_README.html for details

どうやらPostfixのバージョン3.0以降、なんらかの機能の変更があった場合に自動的に旧バージョンの動作と互換性がある安全な動作をするように設定されて、手動で変更を有効にしてあげないと後方互換モードで動いてるという警告がログに吐かれる仕組みになったらしい。

URLで示されたドキュメントには後方互換性のために保持されている設定項目が列挙されているのだが、それと同時にcompatibility_levelという設定で一気にすべてをモダンな動作に変更することが出来るようだ。現在のPostfixのバージョンの最新の動作にするにはlevelをいくつにしなければいけないかがログに書かれるので、その指示通りにすればいい。

というわけで、管理者権限で言われた通りに設定。

sudo postconf compatibility_level=2

sudo postfix reload

さて、これでログから警告が消えるはず。

 

DebianがStretch(9)に更新されたタイミングでラズパイに入れてあるRaspbianもDebianの普通のお作法でStretchにアップグレードしてあったのだが、一箇所だけ盲点があった。

基本的に通常のお作法の過程でapt で取ってくるパッケージリストのソースをStretchに変更するのでソースはちゃんと変更されていると思って安心していたのだが、Raspbianにはもう一個、専用のソースを指定してあるファイルがあった。

/etc/apt/sources.list.d/raspi.list

ここの中にもRaspbian専用のパッケージリストのソースが書いてあって、それがずっと旧バージョン(Jessie)のものを参照するようになったまま残っていた。最近になって、Jessieのパッケージリストが空だとエラーが出るようになって気付いた次第。ということは、ずっとうちのRaspbianはJessieとStretchのハイブリッドで運用されていたのか。怖い。

というわけで、このファイル内のjessieという記述をstretchに変更してapt-get update & apt-get dist-upgradeで一件落着。

Debianのiptables-persistentの実体がnetfilter-persistentというsystemdのserviceになったのでserviceコマンドによる管理に移行したのだが、どうもちゃんと動いていない。ログを見ると、時折、netfilter-persistentの起動時のip6tablesのルール読み込みでエラーで実行できていないことがある。そうなると、サービスがオフにされて、次に再起動したときにはIPv4のルールまで読み込まれないという情けないことになる。いろいろ調べても同じようなトラブルに困ってる人はいるものの、単純なシェルスクリプトであるが故に解決できた人を見つけられなかった。

このままでは危険極まりないので、もともとあんまり使い勝手のいいわけではないiptables-persistentをこの際見限って、最近台頭してきたユーザーフレンドリーなiptablesフロントエンドであるufw(Uncomplicated FireWall)に移行することにした。

さて、まずはiptables-persistentをアンインストール。すると、netfilter-persistentをapt autocleanで除去する様に言われるので、これも実行する。iptablesのフロントエンドがなくなってまっさらになったところで、念のため一度再起動してiptablesに(sshguardを除いて)何もルールが登録されていない状態にしたら、ufwパッケージをインストールする。

apt-get install ufw

さて、設定は簡単(sudoで管理者権限で実行すること)。まずはデフォルトで全接続を禁止にしておく。

ufw default deny

で、必要なサービスについてポートを開けていく。特にsshについては必ず開けておかないとufwを有効にした時にssh接続できなくなるので注意。ufwはプロファイルが存在するアプリケーションについてはアプリ名を指定するだけで必要なポートを全部開けてくれる。このサーバーはOpenSSHとWWWとPostfixを動かしてるので、これらを指定する。

ufw allow OpenSSH

ufw allow WWW

ufw allow Postfix

avahiによるmDNSの名前解決をしているので、以下も指定。

ufw allow Bonjour

プロファイルがあるアプリについては指定するだけでIPv4とIPv6の両方のルールが自動的に登録されるので便利。

transmission-daemonのウェブ設定インターフェースもローカルネットワークからだけアクセスできるようにマニュアルで登録する。こいつはIPv4でしかアクセスできないので、明示的にIPv4でのルールを登録する。

ufw allow proto tcp from 192.168.xxx.0/24 to any port 9091

以上、設定が完了したら、ufwを有効にする。

ufw enable

sshによる接続がぶった切られるかもしれないよという警告が出るが、ちゃんと許可してあるのでそのまま実行する。

再起動しても正しく設定がされていることをiptables/ip6tables –listで確認しておこう。

DebianのアップグレードでMySQLがMariaDBに更新されてから、WordPressのBackWPupプラグインでバックアップするたびにエラーが表示されるようになった。バックアップ自体は動いているようなのだが、気持ち悪い。

Cannot load from mysql.proc. The table is probably corrupted.

調べてみるとMySQLのバージョンが上がった時によく出るエラーらしい。内部のデータベースをMySQLのバージョンアップに合わせてアップグレードしないと出るのだそうだ。おそらくMariaDBの対応するMySQLバージョンがアップグレード前のMySQLのバージョンよりも進んでいるのだろう。というわけで、MySQLのお作法を調べると、コマンドラインからアップグレードが指示できるらしい。

mysql_upgrade -u root -p –force

MySQLのデータベースのrootパスワードを要求されるので入力するとデータベースのアップグレード作業が実行される。最後に作業ログを吐き出すのだが、書き出す権限がないと怒られる。大事なサーバーならsudoして作業したほうがいいかもしれない。まあ、自分サーバーなので気にしないことにする。

作業後はSQLサーバーを再起動させろということなので、えいやっとサーバーごと再起動。BackWPupもエラーを出さずにジョブ完了するようになった。

Niftyを使ってる知人からのメーリングリストへの投稿が半日以上も遅れて配信されるという不可解な事象が発生。調べてみると、知人がNiftyからメールを送信した時刻から、実際にmailmanがメールを受け取った時刻までの間、NiftyのメールサーバーがSMTP接続時にSTARTTLSを試みて断念するというエラーがずっと記録されていた。

postfixの設定を見ると、知らないうちにTLSが有効化されて謎の/etc/ssl/certs/ssl-cert-snakeoil.pemなる公開鍵なんかを使うように設定されている。調べてみると、これはSSL関連のパッケージをインストールした時にデフォルトで作成されるオレオレ証明書らしい。なので、サーバー間通信の暗号化だけならデフォルトからpostfixは対応してるわけだ。ところがよくよく調べてみると、このオレオレ証明書は最初のインストール時に作成されてしまうのでFQDNが設定される前に作られることになる。結果、FQDNと照合して合ってないと文句を言って拒否する厳格な相手とは逆に通信できないのだとか。Niftyが鍵照合でハンドシェイクに失敗してるのももしかしたらこれかもしれない。

というわけで、FQDNが設定された状態でオレオレ証明書を作り直しておくことにする。まずはFQDNが設定されてるかを確認。

hostname -f

問題なければsnakeoil証明書を強制的に再作成させる。

sudo make-ssl-cert generate-default-snakeoil –force-overwrite

これでデフォルトの証明書が強制的に上書きされる。これで少なくともFQDNと合ってないと拒否されることはないだろう。