Raspbian アップグレードでapt sources更新に盲点

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 Stretch ufwによるiptables設定

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で確認しておこう。

WordPress BackWPup エラー

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もエラーを出さずにジョブ完了するようになった。

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してるので特に問題はないと判断して無視した。しかし、データベースをダイレクトにいじらないといけないことになった時は、ちょっと困るなあ。いつかちゃんと再設定しよう。

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

Debian mDNSで名前解決して接続する

Raspbianマシンが最初からavahiが入ってるおかげでmDNSで名前を解決して接続できるのが便利なので、DebianサーバーでもmDNSで名前が解決できるようにavahiをセットアップすることにした。

まずは関連パッケージをインストール。必要な/etc/nsswitch.confの書き換え等は全部パッケージがやってくれる。

sudo apt-get install avahi-daemon libnss-mdns

avahiが稼働するとmDNSで解決できる名前は/etc/hostnameに書かれた名前に.localをつけたものになる。

mDNSの設定に必要な作業は基本はこれだけだが、手元のDebianサーバーはファイヤーウォールで余計な接続をすべてブロックする設定になってるので、名前解決のためにはクエリを受け入れるようにポートを開放する必要がある。なので、/etc/iptables/rules.v4のどこかに以下の設定を追記する。

-A INPUT -d 224.0.0.251/32 -p udp -m udp –dport 5353 -j ACCEPT

mDNSのクエリはマルチキャスト(224.0.0.251)でUDPのポート5353に届くので、これをファイヤーウォールが受け入れる様にすればいい。

同様にせっかくデフォルトでavahiはIPv6でも答えるのだから/etc/iptables/rules.v6にも追記。

-A INPUT -d ff02::fb/128 -p udp -m udp –dport 5353 -j ACCEPT

IPv6のマルチキャストアドレスはサービスごとに割り当てられてるのでmDNSに割り当てられた[ff02:fb]を聞く様にポートを開く。

面倒なので、avahi-daemonの起動とファイヤーウォールルールの反映のために再起動すれば、以後、mDNSで名前解決をこころみるとちゃんと答えてくれるようになる。

Debian Transmissionをdaemon起動する

不在時に自動的にBitTorrentでダウンロードするため、これまではDebianサーバーにログインしてscreen上のセッションでtransmission-cliを使っていたのだが、これだと同時に一つしかインスタンスを起動出来ないので困っていた。というわけで、Debianサーバー上でTransmissionをdaemonで起動し、ブラウザ経由でコントロール出来るようにすることにした。

まずはtransmission-daemonをインストールする。自動起動されてしまうが、設定を書き換えるためにすぐに停止させる。

sudo apt-get install transmission-daemon

sudo systemctl stop transmission-daemon

デフォルトのダウンロードフォルダでは/varを圧迫してイヤんなので、新しくダウンロードフォルダを余裕のある/homeに掘る。掘ったフォルダはtransmission-daemonのユーザー(debian-transmission)とグループ(debian-transmission)に所有させる。

sudo mkdir /home/torrent

sudo mkdir /home/torrent/downloads

sudo chown -R debian-transmission:debian-transmission /home/torrent

sudo chmod -R g+w /home/torrent

後でダウンロードファイルを自分でコピーしたり削除したり出来るように自分自身をtransmission-daemonの実行グループに追加しておく。

sudo /usr/sbin/usermod -aG debian-transmission <user>

ここまで準備できたら、設定ファイルをいじる。設定ファイルはセッション終了時に上書きされる仕組みなので、設定ファイルをいじる時は必ず先にセッションを終了させてからすること。

sudo vi /etc/transmission-daemon/settings.json


“download-dir”: “/home/torrent/downloads”,

“rpc-password”: “password”,

“rpc-whitelist”: “127.0.0.1,192.168.*.*”,


書き換える場所はこの三ヶ所で十分。パスワードは平文で書いておくとセッション起動時に自動的にハッシュされた文字列に置き換わる。LAN内からしかリモートコントロールへのアクセスを認めない方がセキュリティによいので、LAN内のネットワークアドレスだけをrpc-whitelistに追加しておく。

このままではファイヤーウォールにブロックされているので、リモートコントロールにアクセス出来るようにポートを開く。

sudo vi /etc/iptables/rules.v4


-A INPUT -p tcp -m tcp –dport 9091 -j ACCEPT


sudo vi /etc/iptables/rules.v6


-A INPUT -p tcp -m tcp –dport 9091 -j ACCEPT


適当な場所にリモートコントロールのポートである9091でTCP接続を受け入れる様に追加する。

ファイヤーウォール設定の更新とデーモンの起動をするのに手っ取り早いので、ここで再起動する。

後は、http://<server private IP address>:9091/にブラウザからアクセスする。認証を求められるので、username:transmission、パスワードは設定したもので認証すればTransmissionのリモートコントロールパネルにアクセス出来る。daemonで起動しているのでデフォルトでは最大5つまで同時にダウンロードされる。増やしてもいいけど、まあ、負荷を考えるとデフォルトでいいだろう。

OS Xで別バージョンバックアップの作成法

復活したMacBook Proには古い750GBのHDDを戻したので、MacBook Proで使っていた2.5 inch 1TBのハードディスクが余った。なので、USB3.0なケースを買ってそれに突っ込んでみた。このドライブを一時帰国時等で念の為に携帯するメインマックのユーザーフォルダの持ち運びディスクとして使おうという算段だ。

さて、通常のバックアップはTimeMachineに依存しているのだが、TimeMachineでフルバックアップをこのハードディスクにもう一個作るには容量が足りないの。できれば、ユーザーフォルダだけ差分バックアップしたい。で、考えたのが、Cmd-Rで起動できるレスキューディスクのターミナルからrsyncでバックアップするとういう方法だ。

さて、Cmd-Rを押しながら起動し、メニューからターミナルを起動するが、rsyncがレスキューディスクには見当たらない。とはいえ、メインのハードディスクにはOS Xがインストールされているので、この中のrsyncを使えばいい。

/Volume/<OS X Volume>/usr/bin/rsync -av /Volume/<OS X Volume>/Users/<Username> /Volume/<Backup Volume>

これでユーザーフォルダ全体がバックアップ用ハードディスクにコピーされる。以後は同じコマンドを使うことでタイムスタンプの差分を見て必要なファイルだけをコピーしてくれるはずだ。

OS X インストーラーが検証に失敗する

先日、お茶を盛大にぶっかけてしまってお亡くなりになったMacBook Pro、分解してお茶がかかったロジックボードやアッパーケースを超純水で丹念にすすぎ、もう一度組み立てたところ、無事にまた起動するようになった。

というわけで、スペアMacとして活用するために購入時のHDD(750MB)を戻し、リカバリーパーティションから起動(Cmd-Rを押しながら起動する)してオリジナルのOS(といってもこのHDDが入っていた時の最新バージョン)を再インストールしようとしたのだが、エラーが出て再インストールが出来ない。

ならばとEl CapitanのインストーラーをDiskMaker Xを使ってUSBメモリに作成し、こちらから起動したのだが、こちらもアップルとの通信で検証に失敗してインストール出来ない。

いろいろ調べてみると、Macの内蔵時計が正しくないと検証に失敗するとな。ところが、インストーラーからは起動ディスク以外のシステム環境設定にアクセス出来ないので、時計の設定が出来ない。

ま、こういう時こそOS XがUnixであるという便利さを感じる時。メニューバーからターミナルを起動し、コマンドラインで設定すれば良いのだ。

/bin/date mmddHHMMyyyy

月・日・時・分・年のフォーマットなのが釈然としないが、これで正しい日付に設定し直したところ、アップルと通信しての検証がパスして無事にインストールが始まった。これでスペアMacとしての余生を送る事が出来る。よかったよかった。