iどさにっき shuffle 〜2007年7月中旬〜

by やまや
<< = >>

2007年7月12日(木)

しつこく 503

_ mod_cern_meta は任意のヘッダを追加するという意味では mod_headers と似た動作をするモジュールなんだけど、試してみたら mod_headers と違ってステータスコードの変更も可能だった。こんな感じ。

Alias /hoge/ /somewhere/503.html/
<Directory /somewhere>
    AcceptPathInfo on
    MetaFiles on
</Directory>
さらに /somewhere/.web/503.html.meta というファイルを作成し、
Status: 503 service unavailable
と書いておく。すると、/hoge/ 以下へのアクセスが /somewhere/503.html にエイリアスされ、mod_cern_meta により .web/503.html.meta が読まれて 503 エラーとなる。/somewhere/503.html の中身は無視されるようなので、エラー画面をカスタマイズする場合は ErrorDocument 503 で設定する必要がある。逆に言うと、Alias する先の 503.html は存在していれば中身は空っぽでもかまわない(存在しないと 404 になる)。

_ mod_cern_meta は、その名前のとおり CERN HTTPD に由来する。 この前の mod_asisも Apache 1.0 にはすでに存在していた。どちらも太古の昔から使える由緒あるモジュールなんだけど、悲しいぐらい知られてないよね。まあ、たしかにそんなに使い道のあるモジュールではないんだけどさ、こういう用途では今でも便利に使えるんだからもう少し活躍の機会をあげてやってもいいんじゃないかなぁ。

_ ところで、503 のエラーを見かける機会はそれなりにあるけど、実はこんなふうに意図して設定した結果ではなく、過負荷などの外的要因で 503 エラーが出ることはほとんどない。ソースを grep するとわかるけど、Apache の標準モジュールの範囲では mod_proxy でプロクシ先につながらなかったときと mod_cgid で CGI デーモンにつながらなかったときだけ。なのになんで見る機会があるのかなー、というと、おそらくさくらインターネットのレンサバが 503 を頻繁に出すようなカスタマイズをされてるからだと思う:-)

_ てゆーか、ニコ動は混雑時は 200 じゃなくて 503 のステータスを返してくれないかな。


2007年7月13日(金)

標準入力を調べる

_ test -p でパイプかどうか調べるというのは、この場合は適切ではないと思う。

$ test -p /dev/stdin; echo $?
1
$ test -p /dev/stdin </dev/null; echo $?
1
$ cat /dev/null | test -p /dev/stdin; echo $?
0
つーわけで、パイプかどうかはわかるけど、標準入力が端末のときとリダイレクトされたときで区別できない。

_ で、じゃあ test -t 0 を使うかというと、まあそれで正しいんだけど、わしは使わない。こうする。

if tty > /dev/null; then
    # 標準入力が端末
else
    # パイプとかリダイレクトとか
fi
tty ってのは端末の名前を返すコマンド。標準入力が端末のときとそうでないときとで終了コードが違うのでそれで区別。処理としては test -t 0 と等価。

_ なんで test じゃなくて tty を使うかというと、オプションを覚えらんないんだよ悪かったな。そういうことができると知ってはいても、test って引数の種類が多すぎるから、書くときも後から読みかえすときも毎回いちいち man で確認しなきゃいけないんだもん。それに比べて、標準入力が TTY かどうか調べるのに tty というコマンドを使うのはとってもわかりやすいよね。

_ ところで、cat - ってナニ? いらんのに、なんでわざわざそんな指定するの?


2007年7月15日(日)

Varnish

_ まだ日本語の情報はあんまりないけど、リバースプロクシな Varnishをちょっといじってみる。数少ない日本語の情報は このへんとか このへんとか。

_ 先週、仕事の合間にちょっといじってたんだけど、もうひとつ別のプロクシを用意すればリバースプロクシではなくフォワードプロクシとしても使えることがわかったので、自宅に squid + varnish なフォワードプロクシ環境を作って暫定的にこれで過ごしてみた。

_ Varnish が接続する先は不特定多数ではなく、設定ファイルに定義されている必要があるんだけど、逆に言えば、特定の上位プロクシが定義されていればいいということ。また、リバースプロクシは接続元ホストは不特定多数からのアクセスがあるけど、フォワードプロクシは踏台にされないようにいらん接続は蹴らなきゃいけない。つーわけで、こんな感じで設定ファイルを書く。

backend default {	# 接続先サーバの指定。今回は上位プロクシ。
    set backend.host = "127.0.0.1";
    set backend.port = "3128";
}
acl local {
    "127.0.0.1";
    "192.168.1.0"/24;	# CIDR の指定のしかたが変態的。
}
sub vcl_recv {		# いらんホストからの接続を蹴る
    if (! client.ip ~ local) {
        error 403 "access denied";
    }
}
ログを NCSA 形式で吐かせると URL がおかしいけど、リバースプロクシ前提の設計がされているものをフォワードプロクシで使うというアホなことをやってるからで、varnish のせいではない。

_ で、これで2日ほど使ってみたけど、体感的にはほとんど変わらんね。ユーザがわしひとりじゃまあそんなもんだ。だいたいの挙動はわかったからそれでいいよね。重要なポイントをいくつか書いておくと、

手元のメモにはもっと書いてあるけど、大きなものはこんなもん。細かいことは後で別のところに吐き出しておく予定。

_ いちおうバージョンは 1.0.4 だけど、機能としてはまだアルファ版だなぁ。安定性とか性能とかはまったく測ってないからこっちはかなり優れてるのかもしれないけど、セキュリティ的によろしくないところがいくつかある。このへんをしっかりしたものにしないで 1.0 を名乗るのはどうかと。まあ、バージョン番号なんて飾りみたいなもんだけどそれでも。

_ リバースプロクシを使う仕事はときどきあるんだけど、キャッシュしてくれるリバースプロクシってまともなのは squid しかないんだよねぇ。Apache の mod_cache はキャッシュされたオブジェクトに対する操作が一切不可能だしそのほか機能がぜんぜん足りないので問題外。キャッシュしないリバースプロクシならばいろいろあるんだけど。varnish は squid の代替になるかと期待したんだけど、うーん、どうかなー。最低限以上のことはできるので、うまく使えばなんとかならんこともなさそうだけど、どうも謎な部分がいくつかあるんだよなぁ。ろくなドキュメントがないし。そういう部分を潰していけば実用レベルにはもっていけるかも。


2007年7月18日(水)

varnish つづき。

_ バグみっけ。varnish で management port に telnet して子プロセスを stop/start して抜けると、CPU を食い潰す。FreeBSD、Linux どちらでもかならず再現する。↓ps の出力

squid    63633 97.7  0.2  9848  1224  ??  Rs    3:18PM   1:31.39 varnishd: Varnish-Mgr (varnishd)
squid    63645  0.0  0.5 323264  2684  ??  S     3:18PM   0:00.02 varnishd: Varnish-Chld (varnishd)
こんなかんじで CPU 97.7%。発狂してるのは実際のプロクシ処理をおこなう Varnish-Chld ではなく、管理用プロセスの Varnish-Mgr の方。stop した後で管理ポートからいったん抜けて、再度接続してから start した場合は発生しない。

_ 開発版でどうなるかはまだ試してないけど、再現するようなら報告しておいた方がいいかな。ただし、この状態でも各種処理はとくに問題なくこなしている(ように見える)ので、完全に暴走しているわけではなさそう。


2007年7月19日(木)

バックアップ

_ rsyncを使った熟練者レベルのバックアップ

_ ……いつから rsync がバックアップツールになったんだろう。名前が示すとおり、ただの同期ツールでしかないと思うんだけど。

_ 前回同期したものからの差分を上書きしたらバックアップにならないでしょ。バックアップは間隔が長いとその間におこなわれた変更を救えなくなるから、できるだけ頻度を高くするのが基本。が、rsync は同期の頻度を高くすると逆に間違えた状態を同期してしまって間違える前の状態に復旧できないことがある。復旧できない偽バックアップに用はない。こういうのはバックアップではなく、よくいって「ある時点のスナップショットを保存するツール」といったところ。

_ もちろん、ファイルの同期ないしはスナップショットの保存というのもいろいろ用途が多いし運用上でも重要な位置を占めるけど(というか、実際のところ最新のスナップショットだけあれば十分な場合の方がむしろ多いかも)、バックアップとの区別はちゃんとつけておかないと。


<< = >>
やまや