1  USB Net Power 8800 Single Outlet Network AC Power Controller

以前から自宅のルータがインターネットに繋らなくなることがしばしばあり、ルータのファームをあげたり交換したり幾つか方法を試してみたのだがどうもうまくいかない。恐らくISPであるComcast側の問題なのだろう。
幸い殆どの場合は電源をOff/Onすれば繋がるのだが、最近頻度が高くなってきたのとなんにせよ面倒、かつ外から自宅への接続などは自宅にいないと復帰できない事もあり、なにか解決方法が無いかと思って見つけたのがこれ。

• USB Net Power 8800 Single Outlet Network AC Power Controller

端的に言えばUSBからオン・オフを制御できるAC電源のソケットである。 この手のものはサーバ管理用として幾つもあるが大抵は高価でサイズも大きい。これはそこまで多げさではなく、送料を入れても30ドル程度とお手軽である。基本は Windows 用の付属ソフトからの操作になるが、ちょっと調べてみると Linux からも Python で制御するコード usbnetpower8800.py を見つけた。 Ruby から使いたかったので ruby-usb を使ってポートした。

• usbnetpower8800.rb

ステータスを取るコードがどうも動かないのだが、とりあえず用途には足りるので置いておく。

うちではこのアダプタにルータの電源を繋ぎ、自宅の Debian から外の4,5箇所に 10分おきに Ping をうち、全てが Timeout した場合にルータの電源をオフ→オンして再起動する、というのを仕込んで以降、数日に1度くらい再接続しているようだが、こちらは殆どそれを意識せずに生活している。大変よい買い物をした。

基本的にはUSB経由で電源を操作できるということなので、なにかの監視系ソフトと組み合わせてアラートが出たら電源をONにして繋いだ回転灯をつける、なんて事もできるわけで、30ドルくらいで意外と使いでのあるデバイスである。日本でも取扱いがあればいいのに。唯一残念なのはUSB接続が切れた際の挙動が電源オフ固定であることくらいか。これを選べれば完璧なのだが。

1  APC Backup-UPS ES BE550R 550VA

この辺りは日本ほど電力供給が安定していないし夏になると雷も多いので、手軽なUPSが欲しくなり、しばらく前に APC Backup-UPS ES BE550R 550VA を買った。Costco で $45 くらいと安かったのは、新商品のBE550G が出ているからだろうか。まあUPSとしての機能には大差あるまい。こういうのがCostcoで売っているのがアメリカらしいという気もする。日本だと APC ES500 BACK-UPS ブラック BE500JP が相当品か?

USBケーブルでステータスをサーバに送れるので、Debian で apcupsd を入れて利用しているが、apcupsd.conf で設定変更したのはこれくらい。

UPSCABLE usb
UPSTYPE usb
DEVICE

実際に使い始めてみると思ったよりも Power Failue が発生しているのが見える。

Wed Dec 10 06:41:13 EST 2008  Power failure.
Wed Dec 10 06:41:15 EST 2008  Power is back. UPS running on mains.
Tue Dec 23 05:22:46 EST 2008  UPS Self Test switch to battery.
Tue Dec 23 05:22:54 EST 2008  UPS Self Test completed: Not supported
Wed Jan 07 07:53:55 EST 2009  Power failure.
Wed Jan 07 07:53:57 EST 2009  Power is back. UPS running on mains.
Tue Jan 13 09:25:21 EST 2009  Power failure.
Tue Jan 13 09:25:23 EST 2009  Power is back. UPS running on mains.

と言う具合で、月に1,2度は2秒程度の瞬断がある感じ。以前に時々サーバが落ちていたのはおそらくこれが原因だったんだろう。

self-test に失敗しているのは元々その機能が無いからか。新しいモデルの BE550G には Automatic self-test | Periodic battery self-test ensures early detection of a battery that needs to be replaced. と言う具合に機能があるようなので、ちょっと残念。

1  Interlink MyIP サービスで逆引きを設定

記録として。先日ふと Interlink MyIP サービスでいつの間にか逆引きが設定できるのを発見したため、逆引きを設定しました。zero.init.org の正逆引きが一致するようになっています。

なおサーバ内から外側にコネクションを張った場合には、基本的に MyIP ではなく eth0 から ISP接続ルータの Gateway 経由で外に出るマルチポリシールーティングをしているため、そちら側の IPアドレスがソースになり、もちろん逆引きもそちらになります。特に問題になるシーンは無いと思いますが利用者はご留意を。

1  fml → mailman 移行メモ

メモ書き。mailman で予め listname でメーリングリストを作成し、必要な設定をしておく。メンバーの移行は普通に fml の /var/spool/ml/listname/members などから Webインターフェイス経由で登録。

アーカイブの移行は fml 付随の packmbox.pl を使い

# cd /var/spool/ml/listname/spool/
# perl /.../packmbox.pl > /tmp/listname.mbox
# mv /tmp/listname.box /var/lib/mailman/archives/private/listname.mbox/
# cd /var/lib/mailman/archives/private/listname.mbox/
# /usr/lib/mailman/bin/arch listname listname.mbox

だーっと過去メールが流れて html の index が作成される。閲覧権限には要注意。

mailman 1:2.1.9-9 では fml 風の [listname:01234] 的な通番付き Subject を作ることが標準で出来る。fml で使っていた通番をそのまま引き継ぐにはホームサーバー非定期日記（風） を参考に

# /var/lib/mailman/bin/withlist listname
listname のリストを読み込中 (ロック解除)
変数 `m' が mlname の MailList インスタンスです
>>> m.Lock()
>>> m.post_id = (/var/spool/ml/listname/seq より1多い数字)
>>> m.Save()
>>> m.Unlock()
>>> ^D
最終処理中 

とする。

1  Debian lenny での postfix + mailman install 備忘録 (専用サブドメイン利用型)

ここでは 素のドメイン名 (listname@example.com) ではなく、mailman 専用サブドメイン (@lists.example.com) を利用する。全ての専用サブドメイン宛メールは mailman が処理するものとして扱われる。サブドメインを使わず aliases を用いる方法は GNU Mailman インストールマニュアル 等を参照の事。

導入は例によって aptitude 一発で完了。

 # aptitude install mailman
...
 # dpkg -l mailman
ii  mailman        1:2.1.9-9      Powerful, web-based mailing list manager

導入時に利用する言語を聞かれるので、en と ja を選択し ja をデフォルトにしておく。ja で利用すると cli の日本語が euc-jp で出力されてしまい、utf-8 等の terminal 環境では文字化けするのが難だが、それ以外は特に問題ないようだ。

2  Postfix の設定

設定は /usr/share/doc/mailman/README.Debian にある通り、/etc/mailman/postfix-to-mailman.py の記述に従う。

/etc/postfix/main.cf

    relay_domains = ... lists.example.com
    transport_maps = hash:/etc/postfix/transport
    mailman_destination_recipient_limit = 1

/etc/postfix/transport

lists.example.com   mailman:

これで @lists.example.com 宛のメールは全て postfix の mailman service に渡される。mailman service は master.cf で定義される。lenny では external service として標準で入っていた。

/etc/postfix/master.cf

mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

/etc/mailman/mm_cfg.py は以下のようにする。

MTA = None # No MTA alias processing required
# alias for postmaster, abuse and mailer-daemon
DEB_LISTMASTER = 'postmaster@example.com'

MTA = Postfix での alias 共有は利用しないので注意。

3  Webインターフェイスの設定

apache では特定の VirtualHost でのみ mailman interface を表示させたいので、sites-available/lists.example.com に以下の行を入れる。

Include /etc/mailman/apache.conf

URL から /cgi-bin/ を省略したい場合は /etc/mailman/mm_cfg.py を以下のように設定しておく。

DEFAULT_URL_PATTERN = 'http://%s/mailman/'

併せて /etc/mailman/apache.conf も編集

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/

この設定をする前にメーリングリストを作成した場合は、メーリングリスト個別の設定の方も変更する必要があるようだ。

4  短いドメインパート形式への対応

ちなみにこうした @lists... を使う設定の上で listname@example.com のように lists. を省いたメールアドレス形式を使いたい場合、当該 listname のメールアドレスやそれに付随する listname-action@ コマンドメール類を @lists. へ流し込む virtual map / regexp virtual map を書く必要がある。後者には postfix-pcre が必要。

/etc/postfix/virtual

listname@example.com  listname@lists.example.com

/etc/postfix/virtual_regexp

/^(.+)-(unsubscribe|off|leave)@example\.com$/ $1-$2@lists.example.com
/^(.+)-(post|admin|request|owner|join|leave|confirm)@example\.com$/ $1-$2@lists.example.com

メールアドレスを regexp match させての処理は色々と危険なので、動作を理解していない場合はやらない方がいいだろうし、新しい list を作る度に virtual の方は編集が必要だし、こんなケレン味のある方法より素直に aliases/virtual を使った方がいい気もするが、まぁ移行上の都合と趣味の問題ということで。

1  Debian の PermitRootLogin が yes なのは意図的らしい

Debian lenny の openssh-server で、/etc/ssh/sshd_config の default では PermitRootLogin yes になっていた。今時 ssh での root login が有効になっているのはどうかと思ったんだが、/usr/share/doc/ssh-client/README.Debian には

この設定は upstream の default に従っている。(中略) root での ssh login を禁止しても su で root になれるアカウントがある限り、攻撃者は簡単にそこから root 権を奪取できるんだから安全性は向上しないよ。
これはバグじゃないからデフォルト設定が間違ってるなんていうバグレポートを送ってくるなよ! (超訳)

とある。言われてみればその通りではあるんだが、まぁ知られたユーザ名 (root) で brute force attack を喰らっても嬉しくないので私は no にしておく。

1  メールサーバの再移行

先月前半にトラブルがあった際にメールサーバだけ一時的に他所に移していたが、ハードウェアを更新した後は特に問題なく稼働しているので、新サーバに再移行した。今回のサーバ移行手順は以下の通り。

1. 旧サーバの設定・メール・HOMEを新サーバに移行
2. 新サーバで一通りの MTA 設定等を完了して稼働開始
3. 現サーバの MTA を停止 (セカンダリMXサーバはそのまま稼働)
4. 現サーバの Maildir 内メールを新サーバにrsync
5. DNS で Primary MX の Aレコード向け先を現サーバから新サーバに切り替え
6. 外部 MTA 及びセカンダリMXから新サーバに向けてメールが流れ出すのを確認

作業は昨晩 0時には完了。spamd が動いてなかったり、 courier-imap/pop3d & cyrus-saslauthd を dovecot に移行統合したりした都合で幾つか小さな問題はあったが、特に大きな問題なく移行できたと思う。特に設定に変更は無いはずだが、パスワードが旧サーバのものに戻っているので注意されたし。利用者・メール送信者で不具合がある人はご連絡ください。なおメーリングリストは fml から mailman に移行した上で近日中に動かします。

1  Debian lenny install to HP ProLiant ML115

というエントリを書こうと思ったが、正直拍子抜けするくらい何の問題もなくインストールが終わった。インストールには CD-ROM に焼いた Debian-Installer netinst amd64 を利用。一部に書かれていた PS/2 キーボードが認識しなくなるという事象も無い。

Dual Core の AMD Opteron 1210 は問題なく 2CPUs として認識。

SMP: Allowing 2 CPUs, 0 hotplug CPUs
...
Dual-Core AMD Opteron(tm) Processor 1210 stepping 03
...
Calibrating delay using timer specific routine.. 3602.83 BogoMIPS (lpj=7205669)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)

Onboard NIC も問題なく認識。ドライバは tg3 のようだ。

eth0: Tigon3 [partno(N/A) rev 4201 PHY(5750)] (PCI Express) 
  10/100/1000Base-T Ethernet 00:1c:xx:xx:xx:xx

SATA HDD は udev から /dev/sda として認識されている。UATA Slave に繋いだ HDD は /dev/hdb として認識。ちなみに UATAとSATAの両方にHDDを繋いでいたら、UATA側が優先BootデバイスになっていたのでBIOSから起動順序を変更した。トラブルといえるのはこの程度か。USB, Serial, ACPI, CD-ROM Drive の認識もインストーラお任せで特に問題無し。

チップセットは NFORCE-MCP55 というものなのだが、i2c-nforce が attach は出来るものの CPU core temp 程度しか取得できない。M/B温度、電圧、ファン速度の取得は出来ないんだろうか。HDD に関しては SATA, UATA 共に temp は hddtemp / smartctl で取得が可能、S.M.A.R.T 情報は smartctl から普通に取得が可能。

ところで Debian での package install や build が体感的に以前のマシン(P4 1.7GHz) と比べてものすごく速くなったんだが、DualCore の恩恵なのか、それとも SATA に繋いだ Barracuda 7200.11 (ST3500320AS) のお陰だろうか。

1  HP ProLiant ML115

HP の格安サーバ ProLiant ML115 を購入した。12月27日までのキャンペーン価格で、以下の構成で送料込み 28,350円。注文から納品まで5日間と、なかなか優秀。

CPU: Opteron 1210 (1.8GHz DualCore, L2 1MBx2) (+9,450)
Memory: 512MB (PC2-5300 Unbuffered DDR2 ECC, slot*4)
M/B: MicroATX, FOXCONNオリジナルM/B, Chipset nVidia MCP55S Pro
Network: オンボード NC320i PCI Express Gigabit server adoputer
グラフィックカード: オンボード Matrox G200e
拡張バス: PCI Express x16 x1, PCI Express x8x1, PCIx2
HDD: SATA 80GB
光学ドライブ: CD-ROM (ATAケーブルの空きに UATA HDD搭載可能)
その他: OS無し、サウンド無し、

最小構成では15,750円。今回はCPUだけ Athron 64 3500+ から Opteron 1210 にアップグレード(+9,450)した。HDD, Memory は後から自分で足す予定。送料が3,150円かかったが、ベスト電器やヤマダのHP法人窓口を通すと送料無料で入手出来るとか。詳しくはhp鯖-ProLiant-ML115(格安Server) - wiki@nothing 等を参照。

筐体は格安とはいえサーバ機だけあり、冷却系や内部へのアクセスがよく出来ている。ただ MicroATX と言うこともあり、内部の配線や拡張カードの導入には結構苦労する。HDDにはフロントパネル側からアクセスでき、HDD取り付け用の予備ネジがフロントパネルの内側に収納されているのは嬉しい。ML115はトルクネジ(T15)だが、マイナスドライバ用の溝があるのでサイズさえ合えばマイナスドライバでも取り付けは可能だった。HDD は SATA 4スロット(RAID0,1,5可)と、CD-ROM ドライブが繋がっている ATA ポートに UATA ドライブ最大2個(Master,Slave) が追加可能。3.5インチベイは4スロットある。

気になる騒音だが、一昔前のデスクトップマシンといった感じで、お世辞にも静かではないが、許容範囲ではある。ケースファンがうるさいようなので、気になる人は静音のファンに交換するといいが、チップセットやHDDにはファンが無いので、それなりに風量があるものが良さそうだ。

お手軽なサーバ用途としては必要十分かつ安価で素晴らしい。個人的には非常に満足している。ただ、デスクトップ機のベースとして使うには追加で買わないといけないものが多い(グラフィックカード、サウンドカード、OS が必須で、HDD とメモリも恐らく増設が必要)ので気をつけた方がいい気はする。全部買ってもまだ安く仕上げられるとは思うが、その値段だと他の選択肢も出てくるだろう。その辺は事前にパーツ価格を計算しておくと良さそうだ。

1  sendmail でのセカンダリMX設定 備忘録

以前使っていたセカンダリMXが使えなくなっていたのを放置していたので、某サーバの sendmail を設定した備忘録。基本的な考え方は

1. DNS の MX レコードに primary より大きな数字の MX として FQDN を登録
2. 自分が第三者から受け取って relay していいドメインを設定する
3. relay 先の static な経路として primary サーバを指定する

DNS にはセカンダリMXに使うサーバを数字の大きな MX で登録する。

mydomain.example.com.   IN MX 10 mail.mydomain.example.com
mydomain.example.com.   IN MX 20 secondarymx.mydomain.example.com

sendmail 側の設定は、概ね NETWORKWORLD Online - メールサーバ運用管理 一問一答！ 第2回 の通り。リレー配送を許可するドメインは /etc/mail/relay.domains に記載。

mydomain.example.com

primary サーバへの配送は sendmail.cf で mailertable の設定が有効になっていない場合は .mc から以下の設定を組み込んだ上で cf を再構築しておく。

FEATURE（`mailertable', `hash /etc/mail/mailertable'）

/etc/mail/mailertable にて

mydomain.example.com smtp:[mail.mydomain.example.com]

のように記載し、db を構築

# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable

その後、sendmail を再起動。設定後は 3rd relay の設定等を色々と確認しておこう。

2  secondary mx に溜まったメールの強制配送

mailq にメールが溜まっている場合、sendmail で mailq を flush するには

# sendmail -qf

を実行する。基本的には queuerunner が自動的に再送信してくれるので、急ぐとき以外は実行する必要はない。

1  HP ProLiant ML115 到着

先週日曜に注文した HP ProLiant ML115 が到着したので、早速サーバ構築。今回は Debian を scratch build しているのでサービスは順次復旧している。本日のところはアカウントと HOME を移行した後、sshd と一部の Web サーバを復旧させた。メールは仮サーバの方でとりあえず動いているので後日にタイミングを見て移行を行う予定。

利用者で、何か以前使えていたものが使えないなどあるようならばご連絡を。

1  サーバのバージョンは隠すのが常識?

仕事でもプライベートでも相当台数のサーバを運用してきた身から言わせてもらえば、結論は バージョンなんて隠すも出すもお好きなように。その程度じゃ安全性なんて大差ないよ だ。

犯罪者がどのように攻撃するか？を考えればなぜ隠す必要があるのか理由は明白です。サーバのバージョン情報が詳しく公開されていれば、その情報を使うに決まっています。yohgaki's blog - サーバシグニチャは隠すのが当たり前

私が仮に無差別攻撃者なら、「脆弱性のあるバージョンを宣言しているサーバ」と「バージョンを見せないサーバ」に攻撃を仕掛けるな。心情的には「バージョンを隠してる」サーバって、脆弱性への対処管理をサボるためにやってるんじゃないかとも思えるので手を引く理由が無い。

防衛側として考えれば、相手が自動総当たりスクリプトならばバージョンを見て手を引いてくれるなんて期待をする方が愚かだ。そもそも Apache にも IIS 用の攻撃コードが飛んでくるんだよ? 個別にターゲットをしぼったスピアーアタックならばなおさら、出来ることは全部仕掛けてくるから意味が無い。つまりバージョン隠しは、もしかしたら総当たり攻撃の被害をほんの僅かに軽減してくれる可能性があるかもしれないが、基本的には自己満足以上の意味は無い。

スラドのコメントにもあるように、セキュリティスキャナの類が警告してくるのが鬱陶しい(既にパッチ当ててても区別してくれない)ので隠すというのは確かにあるんだけど、それはそれで安全性を警告してくれる手段を一つ捨てていることになるんだから、内部でよほど真面目にバージョンと脆弱性の管理をし続けているんでも無い限り、警告が消えることの危険性は認識しておいた方がいい。

個人的にはWebサーバ管理が本業なら毎日の脆弱性の管理はしておけと思うし、本業じゃないならばサーバアプリのバージョンアップ等のマネージド付きのホスティングに出してしまう事をお勧めする。個人でサーバを管理するなら Debian のように自動アップグレードの仕組みを持っているものを選ぼう。必要の無いサービスは落とす、可能ならアクセス元・認証手段は絞る、継続的にメンテナンスを続ける、といった基本を十分かつ継続してやることが何より先決だ。

1  池田信夫 blog IPアドレスは枯渇していない

池田氏の書いていることは概ね正しいが、現実がそちらの方向に進む可能性は低い気がしている。記事に書かれている通り、米国には未使用のIPアドレスが大量にある。実際、米国で商売をしている企業では IPv6 対応の優先度は(他国市場から要請を受けない限りは)に低い。将来に渡って絶対数の不足が無いという予想には同意できないが、そこはまぁ本筋では無い。
こうした状況の一方で、ICANNの指導にも関わらず現在も余剰アドレスが返還されておらず、故に日本が使うために割り当てられる APNIC 持ち分が2010年にも枯渇する可能性が高い、という話は、現時点では純全とした一方の事実である。

この問題、国ごとの損得の話を抜きには出来ない。オークションでIPv4アドレスを買い取るのも一つの案ではあろうが、日本にしてみれば「IPv4 アドレスに今から金を払って、将来的にも米国中心のインターネット構造に甘んじるくらいなら、それ以上にコストを払っても全世界が自由に使える IPv6 アドレスを普及させた方が理にかなう」と言う考え方は充分に有り得る。IPv6 普及には、IPv4 アドレスの枯渇対応や Internet Protocol の高機能化と言った目的以外にも、次世代のインターネットに関して米国vs.それ以外の国での利害関係をどう考えていくかと言う事情が存在している。また現在の IPv4 保持側も「返却にはコストがかかる」から返していないという面も大きく、オークションをしたからといって需要側が払える値段で出てくると言う保証はどこにもない。

なにより IPv6 は現状「IPv4 が枯渇しないと流行っこない」のであり、IPv6 を普及させたいのであればむしろ「枯渇」を叫ぶのは戦略としても当然と言える。とは言えこれは後付けの理由で、現場レベルで見えているのは「早ければ2010年にIPv4の日本割り当てアドレスが枯渇する」と言う事だけなので、枯渇対応をしなければならないのは必然だというだけの話でもある。

2  日本の IPv6「対応」は意外に進んでいる

ちなみに池田氏の記事にも誤解があるようなので書いておくと

またIPv6普及・高度化推進協議会の調べでも、v6を商用サービスで提供するISPは、200社中わずか1社という状態だ。池田信夫 blog IPアドレスは枯渇していない

これは事実誤認だろう。1社というのはあくまで「対象約200社中、返答のあった22社中1社」であり、記事でも IPv6 を提供しているプロバイダは NTTコミュニケーションズ(OCN)、ニフティ、IIJ、KDDI、NTT東西にNTT-ME が挙げられており、これを見れば逆に国内の大規模ISPは殆どが提供済みとも言える。
機器レベルでも、最近導入されるルータならば IPv6 対応は(実装レベルは違えども)ほぼ当然になりつつあるし、バックボーンレベルの対応は機器の経年更新にともなってかなり進んでいる。

また

また、IPv6は「枯渇」の対策にはならない。v6サイトはv4サイトからは見えないので、v6は実際には携帯電話などの（v4から接続する必要のない）ローカルなアドレスとしてしか使えない。池田信夫 blog IPアドレスは枯渇していない

と言うのも全くその通りなのだが、IPv4 アドレス枯渇からの過渡期では、例えば回線サービス(クライアント)側は dual stack ではなく IPv6 アドレスをプライベートアドレスとして使い、IPv4 アドレスへは NAPT を通して通信するモデルでアドレスを節約することになるだろう。
この場合、裏が IPv6 である必要性については、サーバ側が IPv6 対応している場合に NAPT を介さない IPv6 native での通信が出来るので、NAPT の負荷/IPv4アドレス数を節約することが出来るという点は挙げられる。そうして過渡期を経ながらアドレス空間自体の移行を進めていくことになる。

1  ハードディスクに関する4つの都市伝説 - GIGAZINE

Bianca Schroeder氏によるレポートDisk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?によれば

1. 高価なSCSI/FCドライブの方が安価なSATAドライブよりも信頼できる
2. RAID5が安全なのは2台のドライブが同時に故障する確率がとても低いため
3. 初期の故障しやすい時期を超えれば耐用年数に達するまで壊れないという信頼が高まる
4. ハードディスクメーカーのいうMTBF（平均故障間隔）はハードディスクドライブを比較するのに有益な尺度である

ハードディスクに関する4つの都市伝説 - GIGAZINE

これらは全てガセ！統計的に十分な相関が見出せないという。うーん、そんなものか。

ちなみに業務では数百台の HDD を使うサービスに関わる立場にいるが、3,4年前だとサーバ用 SCSI HDD と ATA の HDD ではスペック上の MTBF でも 5倍以上違っていて、実際に長時間運用するとその差がはっきり分かった。ATA との比較では無く SCSI HDD 同士でも有意な差があったと記憶している。

今の民生用 (S)ATA HDD はスペック上の MTBF でも SCSI と並ぶくらいであり、メーカー間でもスペック上の数値差はさほど大きくない。とは言え long term の試験・運用をすると、SCSI/ATA に関わらずメーカーや製品によって有意な差が生じると言うのは Google のレポート Failure Trends in a Large Disk Drive Population (pdf) でも述べられている通り。それを考えると確かに現時点では MTBF の数値比較では役立たないというのはその通りかもしれない。

1  samba のパスワード有効期限を無期限にする方法

Samba では 無期限がデフォルトらしいが、Debian だと有効期限が 21日間に設定されているらしく、smbpasswd を叩くのが鬱陶しかったので無期限に変更。

 # pdbedit -P "maximum password age" -C -1

あるユーザのみそうしたいときは -c オプションで Account Flags に X フラグを足せばいいらしい。

 # pdbedit -u yoosee -c "[X]"

ldap で管理したほうが綺麗なんだろうが、1台しかないので軽い方法で。

ところで Debian の man-ja pdbedit は 2002-07-09 版になっていて、情報が古いのかもしれないがオプションの説明が違ったり情報が足りなかったりする。samba-doc-ja パッケージ自体がここ数年更新されていないようだ。samba.gr.jp の翻訳 は新しいようなのでこちらに追従すればいいと思うのだけど、BTS に投げておくべきかな。

1  ここ数ヵ月のメール流量推移が大きく上昇傾向

あまり具体的な数字は出せないのだが、某処メールサーバでのメール数がここ数ヵ月恐ろしい程増えている。半年前のざっと 3,4倍はきている感じ。Graylisting や Tapping をかけると結構な割合で落ちるので spam bot なのだろうけど、何か大規模な感染でもあったのだろうか。IPアドレス分布はあまり真面目に調査していないが、ざっと見た感じでは全体的にばらけている。国としては米国・中国・韓国が相変わらず多いが日本もそれなりに。

1  今更ながら munin を試す

ネットワーク対応のリソース情報収集・グラフ化ツールである munin を試してみる。導入は Debian なら例によって

 # aptitude install munin munin-node 

するだけ。munin-node を入れると自動的に /usr/share/munin/plugins/ にある各種 plugin が /etc/munin/plugins/ 以下に symlink され、有効になる。幾つかのファイルは symlink 時にデバイス名を含むようにリンクされる。例えば

 # ln -s /usr/share/munin/plugins/if_ /etc/munin/plugins/if_eth0

と言った具合。設定は /etc/munin/plugin-conf.d/ の下に適当にファイルを置いて書けば読まれる。各 plugin ファイルは perl のスクリプトで、ソースを覗くと先頭の方に設定可能なパラメータも書いてある。ちなみに個別の設定は env. を頭に付ける必要がある。

munin-node.conf は munin (サーバ側) が localhost にいるならば特にいじる必要無し。別のサーバにいる場合はその IP アドレスを許可リストに書いておく。ちなみに munin-node が動いている状態で telnet localhost 4949 とすると対話が出来る。list で node 一覧を出して fetch [node名] でデータが取れる。これを見れば自分で plugin を作るのが容易だというのもよくわかるだろう。

/etc/munin/munin.conf は同じサーバ内で node を動かすなら

[some.server.name]
address 127.0.0.1
use_node_name yes

この程度。あとは cron が自動的に画像を生成する。個人的には動的生成の方がうれしいんだけど。グラフ自体は rrdtool 1.2 だからか、blur がかかってぼやけるのが微妙な感じ。HotSaNIC の方が好みかも。取れる情報はこちらの方が多いし、作りもスマートで良いと思う。

ちなみに rrdtool の bug #397691 - rrdtool - causes munin-graph to consume all memory に注意の事。うちでも apache_* を読ませたら再現した。

1  さくらレンタルサーバのブラックリスト登録状況について - Open MagicVox.net

さくらのレンタルサーバサービスが spam の発信源になっているらしいという話。

さくらインターネット管理下のほぼ全てのIPアドレスが、 spambag.org というブラックリストに載っているため、 相手にメールが届かない可能性があるが、さくら側では手の打ちようがないとのことでした。 さくらレンタルサーバのブラックリスト登録状況について - Open MagicVox.net

私が使っているサーバも見事に Black List 入り。まぁメールサーバとしては使っていないのでそちらの影響は無いのだが。

以前に Load Average が 〜20になり続けた時には管理者に駄目元で連絡した後に回復したのだけど、多分あれも spammer のツールを停止するなりの措置を取ったということなのだろう。その後しばらくは落ち着いていたが、今日くらいからまた 〜15 程度の高負荷状態が続いている。

最近の風潮としては ISP 等による OB25B が取られはじめてきたため、一般回線を渡り歩いての spam 行為がやりづらくなったというのも、こうした固定IPアドレスのホスティングサービスが攻撃元として狙われるようになった一因なのかなと思う。ともあれ根本的になんとかしてほしいところだが、結局は個別にアカウント停止なりの処置を地道に続けるしかないだろうな。頑張れさくらのなかの人。

1  「25番ポートブロック」を2006年11月より順次実施 - ASAHIネット:プレスリリース

気づいていなかったが、9月22日のプレスリリースでASAHIネットも OP25B を適用する予定と発表していたらしい。

Q. 自宅サーバーを設置し、メールサーバーとして利用する場合、25番ポートブロックの影響を受けますか？

A. 固定IPアドレスをご利用の場合は影響はありません。ASAHIネット : よくあるご質問 （Q&A）

と言うことで、光回線なら無料/ADSLでは月額525円で使える固定IPアドレスオプションで使っている人は影響が無いようだ。うちは更に interlink MyIP を使っているのでそもそも影響を受けないはずだが。

それにしても普通、動的IPアドレスでメールサーバを立てようなんて人はいないよなぁ。と思うんだけど意外と見るんだよなこれが。DynamicDNS で運用なんてしてたら、IPアドレスが変わった瞬間に全然関係の無いマシンにメールが流れる可能性があるわけなんだけど、それはいいんだろうか。

1  nobilog2: Stupid Networkと25番ポート

この記事を読んであれれと思った。

迷惑メールの受信は自分でアプリケーションで防御すればいいだけの話だが、送信となると他人に迷惑をかけることになるし、同じ話じゃない、という人もいるかもしれない。
　しかし、それにしたってBIGLOBEのSMTPサーバーのポートを変えるとか、認証サービスを使うとかしてくれればいいわけであって、25番ポートを閉じるのはおかしい。nobilog2: Stupid Networkと25番ポート

BIGLOBEのSMTPサーバのポートを変えたり認証サービスを使うことの何がこの問題の解決になるのかが全くイメージできなかった。世ではもしかして、 OP25B がなんの目的で実施されているのかあまりよく知られていないのだろうか。

2  OP25B とはどういったものか

OP25B は 、ISP の回線契約者(主に動的IPアドレスの利用者)に対して、自 ISP メールサーバ以外への port 25 宛通信を遮断する措置を言う。最近はウィルスを仕込まれた PC を利用した、いわゆる botnet からの迷惑メール送信も非常に多いため、こうした回線契約者からの spam 送信は非常に多い。

OP25B により、「ISPの回線(ADSL, Bフレッツ等)契約者が、動的IPアドレスから他のメールサーバ(の25番ポート)に大量のspamを送りつける行為」を抑制することができる。解説としては IAJapan の OP25B 解説 がわかりやすい。

3  ISP が OP25B を適用する理由

昨今では、こうした回線契約からの送信者を放置するとそのISPは「spam業者を野放しにしている」と言う非難を受けるため、特に携帯メール向けに関しては OP25Bを実施しているISP が大半になってきている。

そもそも動的IPアドレスからのspamは、IPアドレスが頻繁に変わるという性質上、メール受信サーバ側では個別IPアドレスでの拒否設定がしにくい。勢いどうなるかというと、そのISPの利用しているIPアドレスブロック全てをまとめて拒否、という処理を取られかねず、実際に海外の ISP が日本の ISP のメールを全て遮断してしまいトラブルになったケースもある。

4  OP25B によって影響を受けるユーザとその回避策

ちなみに通常のユーザは、例えば BIGLOBE の回線契約者なら BIGLOBE回線からBIGLOBEのSMTPサーバを送信サーバとして設定するはずで、その場合はport25でも送信できるようにしてある事が多い。ISPからすれば、自社のSMTPサーバを経由してくれる分には外部への流量制限やリレー遮断をすることが出来るため、迷惑メールの遮断もやりやすい (OP25B+流量制限しておいて「大量送信は別料金で承り」なんていう商売の ISP もあるのはどうかと思うが…)。

外部のISPのメールサーバやホスティング先サーバ、会社のサーバ等を MTA として使いたい場合には、RFC2476 で定められた Submission (587/tcp) port の利用が推奨される。
Submission(587) の方では認証のない接続を一切受け付けないようにすれば、spammer が Submission めがけてメールを投げてくると言うリスクは排除できる。POP before SMTP では「ユーザ」ではなく「IPアドレス」の認証のため、認証強度(?)が弱いため、最近の認証には SMTP-AUTH を利用するのが一般的だろう。

元々、SMTPが「メールサーバ間(MTA)」と「クライアントからのメールを受け付ける(MSA)」と言う別の役割で同じポートを使っていると言うのがそもそもの問題だという話もあり、と言ってもインターネットのようなものでは現状の仕組をいきなり変えるわけにもいかないので、議論しながら変えていくことになるのだろう。

5  ISP は土管であるべきか

OP25B は結局のところ ISP が自衛のためにやる事なので、ISPが代替手段を用意しろというのも一理ある。とかく固定IPアドレスが高いISPが多すぎるわけで、無料で固定IPアドレスを提供している国内ISPなんて ASAHIネットくらいしか思い付かない。また Submission port にしても世間的に十分普及しきっているとは言いがたい。

そういうこともあり、以下の部分

これらの意見には、私もまったく同感で、ISPも含めたインフラ部分には「Stupid Network」に徹して欲しいと思うnobilog2: Stupid Networkと25番ポート

ISP回線土管主義には私も基本的に賛成だ。とは言え ISP にしても、こうした制限をするためには追加機器の導入なり余計なサポートの発生なり規約の改定なりのコストをかける必要があり、喜んでやるような話ではない。spam と言う悪に対しての必要悪だと言える。

将来的にこうした上流でのコントロールが行きすぎてしまうのは確かに問題になりうるが、日本での話に限れば、現実にはいわゆる「通信の秘密」を基本とする総務省の意向的にも、あまり面倒な制御は ISP でも現状やりにくいと言う事情もあり、さほど心配するような問題では無いと思う。

1  Rgrey - S25R + greylisting

postfix に Rgrey の方法で smtp spam filtering を入れた。ささださんの真似。1日動かした時点での効果としては、amavis の bannedmail フォルダに落ちるメールが、約 1/10 に減少している。spam filter で spam フォルダに落ちるメールは 1/3〜1/4程度になった。これだけで spam を遮断することにはならないが、後段の amavis や spamassassin に比べて処理がかなり軽いので負荷軽減にもなる。

2  Greylisting + S25R

基本的な発想は Greylisting と言う方法。

一定時間が経過するまで一時拒否(4xx)して、それでも接続してきたら、たぶんopen proxyじゃないと思われるので受け取ることにしよう。

つまり「smtp 接続に 450 (一時的な拒否) を返して再送要求すると、まともな MTA なら再送するけど spam tool や virus は再送しないから spam を遮断できる」というもの。一度再送が行われた IPアドレスと From, To の組合わせは記録され、1ヶ月間は再度の再送要求無く処理される。

しかしこれだと「でもそれってまともな MTA にも余計な負担をかけるよね」と言われるのももっともな話。「じゃあ怪しげな接続元だけにこの手を使おう」と言うことにして、S25R にあるような

有効なスパム対策は、メール中継サーバからのSMTPアクセスを受け入れる一方で、エンドユーザー用回線からのSMTPアクセスを拒絶することである。それらは、IPアドレスの逆引き名の特徴に基づいて識別できる。

に基づき、「逆引き出来ないか、逆引き結果がいかにも回線系サービス」のものに Greylisting を適用する。

こうした接続元逆引きパターンによる判別は、postfix の場合は main.cf の設定のみで対応出来る。設定内容は rgrey そのままだが、一応書いておくと

/etc/postfix/main.cf

 smtpd_recipient_restrictions = ... , regexp:/etc/postfix/check_client_fqdn
 smtpd_restriction_classes = check_greylist
 check_greylist = check_policy_service inet:60000 

/etc/postfix/check_client_fqdn

 /^unknown$/                                  check_greylist
 /^[^\.]*[0-9][^0-9\.]+[0-9]/                 check_greylist
 /^[^\.]*[0-9]{5}/                            check_greylist
 /^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z]/ check_greylist
 /^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9]/            check_greylist
 /^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\./    check_greylist
 /^(dhcp|dialup|ppp|adsl)[^\.]*[0-9]/         check_greylist

postgrey は Debian なら公式パッケージが用意されているので apt 一発。と言うことで導入は容易だ。check_client_fqdn の正規表現は色々試してみるのが良さそうか。

3  導入雑感

結局これは逆引き名が「怪しい」サーバに負担を強いることになるが、実際の効果がそれなりにあるのと 1度再送してもらえば当分はスルーするので許容できるレベルではなかろうか。将来的には OP25B で解決される部分ではあるが、全ての ISP がそれを行うわけでもなかろう。ちなみに現在うちの MTA では Rgrey の他にも NS による Reject や 添付ファイル(.scr|.pif)の拒否もしている。MTA での総合的な spam 対策は spam対策まとめ が詳しい。