gpg

毎日リモートにあるサーバのバックアップを ssh + tar + bzip2 + gpg で取っているのだが、7回に一回くらいの頻度で、tar の中から呼び出してる bzip2 が internal error number 1007 というエラーを出力してしまう。

クライアントは cygwin 環境。転送しているデータはだいたい数百メガバイトから数ギガバイトくらいのオーダー。下り 1.5Mbps の ADSL の回線で接続している。

bzip2/libbzip2: internal error number 1007.
This is a bug in bzip2/libbzip2, 1.0.3, 15-Feb-2005.
Please report it to me at: jseward@bzip.org.  If this happened
when you were using some program which uses libbzip2 as a
component, you should also report this bug to the author(s)
of that program.  Please make an effort to report this bug;
timely and accurate bug reports eventually lead to higher
quality software.  Thanks.  Julian Seward, 15 February 2005.


*** A special note about internal error number 1007 ***

Experience suggests that a common cause of i.e. 1007
is unreliable memory or other hardware.  The 1007 assertion
just happens to cross-check the results of huge numbers of
memory reads/writes, and so acts (unintendedly) as a stress
test of your memory system.

I suggest the following: try compressing the file again,
possibly monitoring progress in detail with the -vv flag.

* If the error cannot be reproduced, and/or happens at different
  points in compression, you may have a flaky memory system.
  Try a memory-test program.  I have used Memtest86
  (www.memtest86.com).  At the time of writing it is free (GPLd).
  Memtest86 tests memory much more thorougly than your BIOSs
  power-on test, and may find failures that the BIOS doesn't.

* If the error can be repeatably reproduced, this is a bug in
  bzip2, and I would very much like to hear about it.  Please
  let me know, and, ideally, save a copy of the file causing the
  problem -- without which I will be unable to investigate it.

エラーの内容は、bzip2/libbzip2 のバグか、メモリなどのハードウェア障害が考えられるというもの。散発的に発生するようなら ハードウェア障害の疑いがあるので、memtest86 などのメモリチェックツールで確認してとのこと。結構レアなエラーみたいだね。

私のマシンのメモリは 1GB * 2 の DDR-SDRAM ECC なし の Unbuffered なのがいけないの? でも、今までは問題なかった。もしかして私のマシン、壊れてきてるの? ネットワーク経由でやってるから、前段の ssh からうまくデータを受け取れてないとか? でもそれだったら bzip2 の内部エラーにはならず、もっと前の方でエラーになるだろうしなあ。

これだけじゃよくわからない。もっと詳細なログが必要だな。とりあえずログのレベルを上げた上でログを検分し、ハードウェアの交換も視野に入れた上で調査していこう。

scp + tar + gpg で経路とファイルを暗号化したネットワーク・バックアップをおこなう。

- 要するに 2004-03-19 の「ftp + tar + gpgで暗号化ネットワーク・バックアップ」の置き換え

2004-03-19 に「ftp + tar + gpgで暗号化ネットワーク・バックアップ」という記事を書いた。この方法だとファイル自体は gpg によって暗号化しているので、中身を解読される可能性は低い。しかし、ftp を使っているため 経路上で ID と パスワードを盗聴されるおそれがある。ファイルの安全とアカウントの安全は別の問題だ。

無料ホームページサービスのように ftp のみのサービスしているホストの場合は盗聴に対して有効な対策をとるのが難しい。しかし、ssh をサービスしているホストなら scp や sftp を使うことで通信の暗号化を実現できる。

ssh/scp/sftp のみを使った場合はデータが暗号化されるのは通信経路上だけだが、gpg を組み合わせればリモートマシンに送ったあともデータを暗号化された状態に保つことができる。このご時世に外部にデータを持ち出すなら、通信の暗号化とファイルの暗号化は必須だと思う。

- scp 用の鍵作成

2004-11-17 の「ssh scp sftp の正しい自動実行方法」のやり方で scp 専用かつ権限を限定した鍵を作成。これを使う。

2004-11-22 追記。
2004-11-17 に書いた、command="" の指定がない公開鍵を使った場合は権限の限定が不十分。command="" を使わずに scp 専用の鍵としたいならば、ファイル転送に特化したシェルを使うなどの対策を講じないと結果的にシェルへのアクセスを許してしまうおそれがある。詳しくは 2004-11-22 「authorized_keys に書く no-pty と command="" の意味」を参照。

- scp は標準入力からデータを読んでくれない

2004-03-19 の「ftp + tar + gpgで暗号化ネットワーク・バックアップ」の利点の一つに、gpg が出力したデータを直接 ftp の標準入力に渡してアップロードする、というものがある。これのおかげで余計な中間ファイルを作らずに済む。

scp でも同じ事をしようと思ったのだが、なんと scp には標準入力からデータを読んで直接アップロードという機能がない。scp の man page を読んでみたが、代替の機能は見つけられなかった。仕方がないので一度ファイルに書き出すことにした。

scp man scp.0
http://www.unixuser.org/~euske/doc/openssh/jman/scp.html

- scp + tar + gpg で暗号化ネットワークバックアップするシェルスクリプト

というわけでできたのが以下のスクリプト。これを cron で自動実行する。

#!/bin/sh

# setup
PASS_PHRASE="MY SECRET PASS PHRASE STRING"
TAR_TARGET="/home/hiroaki/log.txt /home/hiroaki/etc /cygdrive/s/cvsroot"
OUTPUT_FILE="backup`date +%F-%H%M%S`.tar.bz2.encoded"
OUTPUT_PATH="/home/hiroaki/tmp/$OUTPUT_FILE"
REMOTE_SERVER=backup.example.com
REMOTE_USER=hiroaki
REMOTE_UPLOAD_DIR=/home/hiroaki/backup

date
echo $TAR_TARGET
echo $PASS_PHRASE | { tar --bzip2 -cf - $TAR_TARGET |gpg --batch -c --cipher-algo AES256 --force-mdc --passphrase-fd 3;} 3>&0 >$OUTPUT_PATH

echo output to $OUTPUT_PATH
scp -oIdentityFile=$HOME/.ssh/auto $OUTPUT_PATH $REMOTE_USER@$REMOTE_SERVER:$REMOTE_UPLOAD_DIR
if [ $? -ne 0 ]; then
  echo "`date` scp error" >&2
  exit 1
fi
rm -f $OUTPUT_PATH

echo backup complete
date

- scp では今回の目的には力不足

やっぱり標準入力から渡したデータをアップロードしたい。gpg の生成したファイルのハッシュをチェックしたり、scp以外のプログラムでも gpg の出力を利用したり、ローカルにもファイルをため込んだりしたい場合は一度ファイルに出力する方がいいのだが、今回はそんなことはしないし。

また、ファイルをアップロードした後にパーミッションを落としておきたいんだけど、scp では chmod などを発行できないようなのでそれもできない。umask を 077 にしておくだけじゃなくて、アップロードしたファイルに 600 を明示的に指定したいんだけどなあ。

scp コマンドがバージョンアップして機能が強化される見込みもなさそうだし。

OpenSSH FAQ
http://www.ie.openbsd.org/openssh/ja/faq.html#2.10

2.10 - scp に (なにかの機能) を追加してくれない?
短い答え: だめです。

長めの答え: scp は標準化されていないのです。それにもっとも近いものは「rcp が何をやるか」という仕様だけです。これは接続の両側で同じコマンドが使われるため、機能やオプションを追加すると異なる実装の間で相互運用できなくなる危険性があります。

新しい機能は sftp のほうが追加されやすいでしょう。なぜならこのプロトコルは標準化されていますし (まあ、 ドラフト標準ですが)、クライアントとサーバが別々になっているからです。

今回の目的には scp はあまり適していないようだ。明日は sftp を試してみよう。

--cipher-algo オプションで使用する暗号化アルゴリズムを指定できる。

--cipher-algo NAME        use cipher algorithm NAME

使用できる暗号アルゴリズムは gpg --version したときに表示される。

$ gpg --version
gpg (GnuPG) 1.2.4
Copyright (C) 2003 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, SHA256
Compression: Uncompressed, ZIP, ZLIB, BZIP2

2004-01-08 で書いた「gpg でファイルをパスワードだけで 暗号化/復号する」の共通鍵暗号で使われるデフォルトは CAST5。米国政府が AES として採用したそうだし、今後使うならは AES がいいのかな。

サンプル。2004-11-09 の「GMail をバックアップストレージとして使う」シェルスクリプトから抜粋。

echo $PASS_PHRASE | { tar --bzip2 -cf - $TAR_TARGET 2>/dev/null |gpg --batch -c --force-mdc --cipher-algo AES256 --passphrase-fd 3;} 3>&0 >$OUTPUT_PATH

GMail の 1GB という容量を生かして、バックアップストレージとして使う方法。

ストレージというと大げさな感じがするが、やってることは暗号化したアーカイブファイルを GMail にメール送信するスクリプトを書き、これを cron で一時間ごとに実行するだけ。GmailFS などを使ってファイルシステムとしてマウントするのも一つの方法だとは思うが、バックアップなんだから安定性重視でいきたいし、こういうのはシンプルな方がいい。

今日の戯言 ChangeLog 主にテキストファイルを gmail にバックアップ
http://apollo.u-gakugei.ac.jp/~sunaoka/clog/2004-11.php#2004 ...

主にテキストファイルを gmail にバックアップするつもりででっち上げてみたが，車輪の再開発のような気がしてならない．

1GB の容量を与えられたらそれを活用しようとする人はたくさんいるし、実装もたくさんあるようなので確かに車輪の再発明かもしれないですね。でも、自分好みの機能やインターフェイスにしたいなら、スクリプトを書いちゃう方が良いと思います。File::MMagic と Compress::Zlib を使って、テキストだったら圧縮するという機能は面白いと思いましたし。

- GMail をバックアップストレージとして使う - 私の場合

私の場合、シェルスクリプトで tar と gpg を呼び出して圧縮と暗号化をおこない、2004-10-09 と 2004-11-01 で書いた「添付ファイル付メールを送信する Ruby スクリプト」である samail で SMTP サーバに投げている。

送信先は GMail をはじめとするメールボックス容量に余裕のあるアドレス。メールなので数十メガバイトのファイルのバックアップという用途には適さない。ChangeLog メモのファイルや自分用 CVS リポジトリ、etc ディレクトリなど、小さなものだけをバックアップしている。Gmail のアカウントを取得する前は一日一回だったが、Gmail ができてからは一時間に一回に実行頻度を上げた。

内容にもよるが、外部にデータを持ち出すなら暗号化は必須だと感じている。GnuPG を使えばフリーで強力な暗号を利用可能。具体的には 2004-01-08 で書いた「gpg で標準入力からパスワードを渡してバッチ処理で暗号化」を利用し、GPG の共通鍵暗号で暗号化している。

暗号化アルゴリズムには AES256 (256bit Advanced Encryption Standard) を指定。gpg のデフォルトの CAST5 でも良いと思うけど、AES は NIST (National Institute of Standards and Technology 米国商務省技術標準局) 御用達の暗号化アルゴリズムとのことなので、これを使うことにした。

Perl だったら Crypt::CAST5 や Crypt::Rijndael とか使うのが一般的なのかな?

#!/bin/sh

# gmail_backup.sh
# Archiving, Crypting, and mail sending script
# Copyright (C) 2004 Saito Hiroaki <sonic64@infoseek.jp>
# http://sonic64.com/

# setup
PASS_PHRASE="MY SECRET PASS PHRASE STRING"
TAR_TARGET="/home/hiroaki/log.txt /home/hiroaki/etc /cygdrive/s/cvsroot"
OUTPUT_PATH="/home/hiroaki/tmp/backup.tar.bz2.encoded"
to_address="to@example.com, to@gmail.example.com"
optional_adderss="to@daily.example.com"
from_address="from@example.com"
smtp_server="smtp.example.com"


date
echo $TAR_TARGET
echo $PASS_PHRASE | { tar --bzip2 -cf - $TAR_TARGET |gpg --batch -c --cipher-algo AES256 --force-mdc --passphrase-fd 3;} 3>&0 >$OUTPUT_PATH

echo output to $OUTPUT_PATH
echo archiving complete

if [ `date +%H` -eq 23 ]; then
  to_address="$to_address $optional_adderss"
fi

/usr/local/bin/ruby /home/hiroaki/script/samail -v --to "$to_address" --from $from_address --smtp $smtp_server --subject "[GMail Backup] `date +%c`" --attachment $OUTPUT_PATH

date
echo mail send complete

以前は暗号化した圧縮ファイルの md5 ハッシュを取っておいて、前回と異なったときのみメール送信という動きにしていたが、その機能は外してしまった。そういう意味では一度ファイル出力せずに直接 samail の標準入力に渡した方がシンプルだな。よし、samail の次のバージョンでは標準入力から読み込んだデータを添付ファイルとして送信できるようにしよう。

- gmail_backup.sh の設定方法

# setup のところに設定を書く。
PASS_PHRASE に gpg に渡すパスフレーズ、TAR_TARGET にバックアップしたいファイルやディレクトリのパス、OUTPUT_PATH に暗号化した圧縮ファイルの出力先を記述。あとは To と From と SMTP サーバ名を書いて完了。Ruby のパスを /usr/local/bin/ruby と samail のパスを /home/hiroaki/script/samail とハードコーディングしてるのはあまり良くないかも。

私の場合 cygwin ネイティブのファイルシステムと /cygdrive の両方にバックアップしたいファイルがあるため、/ からフルパスで TAR_TARGET を記述している。このせいで tar に以下のようなメッセージを表示されるけど、実害がないので問題ないだろう。

tar: Removing leading `/' from member names

- GMail 側の設定

Gmail といえども 1GB しか容量がないので、古いバックアップファイルは削除する必要がある。Gmail の Trash ディレクトリは 30日過ぎると削除されるという性質があるので、これを利用する。この性質は Trash を開いたときに出るメッセージに書かれていた。

Note: Trashed messages more than 30 days old will be automatically deleted.

メール送信時に Subject に特徴的な文字列を入れておき、その文字列でフィルタリング。マッチしたメールは自動的に Trash 行きになるように設定する。こうすることで「30日を過ぎたバックアップファイルは自動的に削除」を実現できる。

- メール送信の頻度はどれくらいがよいか

これはもうお好みで良いと思う。一日一回くらいでも充分なんじゃないかと思うが、せっかく容量があるんならいっぱい送っちゃえ、ということで一時間に一回にしている。

一回 1MB のファイルを送るとして、1MB * 24時間 * 30日 = 720MB 、Base64 すると 3分の4倍くらいになるので、それを含めても 1MB * 24時間 * 30日 * 4 / 3 = 960MB。24時間稼働のマシンでなければ頻度はもっと減るし、一日一回にしておけばさらに余裕。ところで、GMail って添付ファイルは Base64 デコードした状態でファイルサイズを計算している気がするんだけど気のせいかな。

- 一日一回だけ別のアドレスを追加して送信

このスクリプトは cron で一時間ごとに起動しているが、23時台に起動したときだけ optional_adderss にセットされた送信先を追加している。Gmail ほどメールボックス容量に余裕がないアドレスなので、一日一回だけの送信にしたいからだ。Gmail の予備として使っている。

if [ `date +%H` -eq 23 ]; then
  to_address="$to_address $optional_adderss"
fi

- 分割すれば巨大ファイルでも OK?

分割すれば数十メガバイト単位の巨大ファイルでもバックアップできるが、いざリストアしようと思ったときに分割したメールを連結するという手間をかけたくない。標準で POP で受信できない場合はなおさら。そういう巨大ファイルは他の方法を使うべきでだ。どうしてもネットワーク経由でのバックアップがしたいなら、2004-03-19 で書いた「Linux: gpg: ftp: ftp + tar + gpgで暗号化ネットワーク・バックアップ」などが使えるかもしれない。

- 正常に復号して圧縮ファイルを展開できるかどうかのテストを忘れずに

バックアップしただけで安心してはいけない。いざという時にに迅速にリストアできなければ意味がない。私は以下のようにして復号と圧縮ファイルの展開をしている。

$ echo "MY SECRET PASS PHRASE STRING" |gpg --passphrase-fd 0 -o - backup.tar.bz2.encoded |tar -x --bzip2
Reading passphrase from file descriptor 0
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

bzip2: (stdin): trailing garbage after EOF ignored

--force-mdc オプションなしで暗号化したファイルの場合、以下のメッセージが表示されるかも知れない。これについては私も詳しくないので言及しない。とりあえず --force-mdc を付ければ警告は出なくなる。

gpg: WARNING: message was not integrity protected

bzip2 の警告は、末尾になにか余計なデータがあるので無視するよ、というもの。理由は不明。tar の出力を直接 gpg の標準入力に渡しているから?

- 「フッフッフッフッフッフッ まぬけめ! Gmail」「や…やろう まさか!」「きさまのおかげで ストレージ利用がしやすくなったぞッ!」

追記。Gmail が POP3 をサポートするとのこと。

ITmediaニュース：GmailがPOP3サポート、ウイルス対策も提供へ
http://www.itmedia.co.jp/news/articles/0411/11/news010.html

これでさらにストレージとして利用するのが簡単になった。そのうち 読み書き用の API を書く人も出てくるだろうな。POP/SMTP ベースだと遅延があるのでリアルタイム性を要求するアプリケーションには使えないだろうけど、用途を選べば充分使える。

ftp を使ったネットワークバックアップについての記事を 2003-12-01 に書いた。この手法の欠点の一つは、暗号化されないことだ。ftp に暗号化機能がないので仕方がないが、他のツールを組み合わせれば、暗号化できる。

- 何を暗号化するか

暗号化には通信経路上の暗号化とファイルの暗号化がある。通信経路上の暗号化だと、バックアップ先サーバへたどり着いた後のファイルは生のままになる。ファイルの暗号化だと、バックアップ先サーバに到達した後もファイルはずっと暗号化されたままだ。

通信経路の暗号化とファイルの暗号化のどちらが良いかは場合による。もちろん両方やっても良い。バックアップ先が共用のファイルサーバで、そのサーバの管理者を含め、自分以外のユーザがアクセスする可能性があるなら、ファイルそのものを暗号化したほうがいいだろう。

一方、バックアップ先が自分しかアクセスしないサーバだったら、通信経路上だけを暗号化してファイルを生で保存しておいた方が便利だろう。いざディスクがクラッシュして復旧しようとしているのに、暗号化解除のパスワードがわからない、といったトラブルも防げる。また、ファイルを暗号化しただけでは ftp のアカウントのパスワードが生のままネットワーク上を流れてしまうが、通信経路自体を暗号化すればこれも解決できる。

- 通信の暗号化

通信の暗号化を組み合わせたネットワークバックアップは、やったことがないのでとくに書かない。ssh、scp、sftp を使ったり、VPN を使ったり、方法はいくらでもあると思う。一応 ssh を使ったやり方について記事を見つけたのでメモしておく。

Q. cron 等から起動されるバッチ処理の中で ssh を利用したいのですが、ログインを自動化するにはどうすればよいですか?
http://www.jp.freebsd.org/QandA/HTML/2255.html

- ファイルの暗号化

暗号化できるならどんなツールでもいいが、今回の用途で使うならば、自動化ができて、強い暗号強度を持ち、無償で利用できるものがいい。この条件を満たす暗号化ツールとしては gpg がある。2004-01-08 に書いた「gpg: ファイルをパスワード/パスフレーズだけで暗号化/復号する」や「gpg: 標準入力からパスフレーズを渡してバッチ処理でファイルを暗号化」が参考になるだろう。

tar の出力を gpg に通して暗号化してやればいいのだが、私が使っている ftp コマンドは送信ファイル指定部分にパイプを使ったコマンドラインを記述できないようなので、該当部分はシェルスクリプトにした。

以下のようなスクリプトを用意して、tar で固めたデータを暗号化して出力できるようにする。

#!/bin/sh

PASS_PHRASE="passphrase"
TAR_TARGET="script etc"
BASE_DIR=/home/hiroaki

echo $PASS_PHRASE | { tar -C $BASE_DIR -zcf - $TAR_TARGET 2>/dev/null |gpg --batch -c --passphrase-fd 3;} 3>&0

これを 2003-12-01 の ftp バックアップスクリプトで呼ぶだけだ。tar で出力したファイルを暗号化しているので、拡張子に .gpg を付けている。

ftp -i -v -n 10.39.38.89 << END
user USER_ID PASSWORD
cd /d/backup
bin
put |/home/hiroaki/script/hgpg.sh "backup_`date +%a`.tar.gz.gpg"
quit
END

gpg 自体が圧縮機能を持っているので、gzip する必要性は薄いかもしれない。そのあたりはお好みで。

--batch オプションと --passphrase-fd を組み合わせることで、標準入力からパスフレーズを渡して暗号化できる。

$ echo passphrase | gpg --passphrase-fd 0 --batch -c data.txt

--passphrase-fd オプションは、gpg --help には記載されていないので man を参照のこと。

--passphrase-fd n
        Read the passphrase from file descriptor n. If you use 0  for
        n,  the  passphrase  will be read from stdin.  This can
        only be used if only one passphrase is supplied.  Don't  use
        this option if you can avoid it.

ファイルをパスフレーズとして使うこともできる。

$ cat keyfile | gpg --passphrase-fd 0 --batch -c data.txt

GnuPGを対称鍵暗号ツールとして使う Symmetric key encryption by GnuPG
http://home.catv.ne.jp/pp/ginoue/memo/gpg-symmetric.html

パスフレーズだけを使った暗号化。暗号化と復号で同じ鍵を使うので、対称鍵暗号方式や共通鍵暗号方式と呼ばれる。
-c オプションを使う。

-c, --symmetric encryption only with symmetric cipher

- 暗号化

$ gpg --symmetric data.txt
Enter passphrase:

- 復号

$ gpg data.txt.gpg
gpg: CAST5 encrypted data
Enter passphrase:

文書の暗号化と復号化
http://homepage3.nifty.com/peterpan/gphnode7.html