Debian オレオレ証明書の更新

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と合ってないと拒否されることはないだろう。

Debian jcode.plがなぜか動かない

古いCGIなどでPerlで日本語を扱うものがjcode.plを要求する。もう動かしてる意味もほとんどないけれど過去の情報が見えなくなるのも嫌なので動かし続けてるのだが、Stretchへのアップデート後にCGIが動いていなかった。これは例によってはは~ん、jcode.plが読めてないなと直感。

調べてみるとちゃんとjcode.plのパッケージであるlibjcode-perlパッケージはインストールされてるし、/usr/share/perl5/jcode.plも存在する。

じゃあ、Perlのパスに入っていないのかとおもって@INCを表示させてみる。

perl -E ‘say for @INC’

すると/usr/share/perl5もパスに通ってる。うぬぬ。

しょうがないので手動でjcode.plの上位互換ライブラリであるjacode.plをパスが通った場所に置くことにする。入手元はCPAN(http://search.cpan.org/dist/jacode/)でアーカイブをほどいてjacode.plを手に入れる。

あとは/usr/local/lib/site_perlにコピーする。このディレクトリはDebianの標準では掘られてないのでroot権限で掘る必要があった。

最後にjcode.plを要求するCGIでjcode.plでなくjacode.plを要求する様に変更する。

require ‘jcode.pl’ -> require ‘jacode.pl’

動作を確認するとちゃんと動くようになっていた。まあ、jcode.plもjacode.plも枯れたライブラリなのでアップデートすることもないだろうから、この対処で十分だろう。

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

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

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

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