SPF (Sender Policy Framework) という、送信元アドレスの偽装を検出する仕組みがあります。 実は主要な携帯キャリアはSPFに対応しています。ドコモ、auは去年の12月に、WILLCOM、Vodafoneがつい先日の2006年3月に対応しました。 報道発表資料 : 「なりすましメール」防止に向けた取り組みを推進 | お知らせ | NTTドコモ KDDI 会社情報: ニュースリリース > 送信ドメイン認証技術の導入開始について WILLCOM｜送信ドメイン認証サービスの開始について 迷惑メール対策を強化｜ボーダフォン 携帯電話のメールアドレスはドメインパートが決まっているので、 送信元メールアドレスのドメインパートが携帯電話のものかどうか。 SPFチェック失敗していないかどうか。 という判別をすれば、携帯電話からのメールのみを受け付けることができ、envelope f

Cでプログラムを書いていて大量のメモリを確保したくなったとき、大抵は mallocを使うと思いますが、その際には戻り値がNULLかどうかを判断してエラー処理に飛ばすと思います。しかし、Linux のメモリ管理サブシステムには「メモリ・オーバーコミット」という機構があり、実装されているメモリ以上の領域を確保できてしまいます。 #include <stdio.h> #include <stdlib.h> int main() { int i; char *p; for(i=0;i<65536;i++){ p = (char *)malloc(65536); if(0 == (long)p){ break; } } printf("SIZE=%dMB\n",i*65536/1024/1024); return(0); } swapoff したメモリ 1G のマシンでこれを実行するとこんな感じにな

今回は少々マニアックというか，重箱の隅的お話です． bash(1) には，複数のコマンドをまとめたり，コマンドの実行結果をコマンドラインに取り込むための記法が複数あります．それらのコマンドを実行するために，bash は必要に応じてサブシェルを起動しますが，どういう記述をした際にサブシェルが起動されるのか，いまいちはっきりしなかったため，実際に試してみました．今回試したのは，( ), $( ), { }, <( ) です． を実行して，ps コマンドの親プロセスがどれになっているかで確認しています．bash が設定する $PPID 変数を見ないのは，変数の展開をどのシェルがするかに依存するために，確認しにくいからです．ps コマンドを --forest オプション付きで単純に起動すると $ ps --forest PID TTY TIME CMD 20218 pts/18 00:00:00

「こんなに簡単！ Linuxでロードバランサ」のシリーズでは、 こんなに簡単！ Linuxでロードバランサ (1) 〜 LVS + NATで負荷分散をしてみよう こんなに簡単！ Linuxでロードバランサ (2) 〜 keepalivedでWebサーバのヘルスチェック こんなに簡単！ Linuxでロードバランサ (3) 〜 VRRPでロードバランサを無停止にする こんな流れでNATによる負荷分散システムを構築してきました。 今回はこれを DSR(Direct Server Return) 方式に変更してみます。 「DSRとはなんぞや？」という方は、 ロードバランサの運用.DSRって知ってますか? L4スイッチはDSR構成にすべし こちらでわかりやすく説明されていますので参考にしてみてください。 一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調

DSASのロードバランサは高価なアプライアンス製品ではなく、LinuxのLVS (Linux Virtual Server)を利用しています。 安価、というか、ハードウエア以外は金銭的コストがゼロなので、一般のクライアントからのアクセスを受ける外部ロードバランサのほかに、内部サービス用のロードバランサも配置しています。それぞれactive, backupで2台ずつあるので合計で4台もロードバランサがあることになります。(こんな構成を製品を使って組んだら数千万円すっとびますね) また、ネットワークブートでディスクレスな構成にしているので、ハードディスが壊れてロードバランサがダウンした、なんてこともありません。 ですので「ロードバランサは高くてなかなか導入できない」という話を耳にする度にLVSをお勧めしているのですが、どうも、 なんか難しそう ちゃんと動くか不安 性能が出ないんじゃないか 等々

qmailではdot-qmailと呼ばれるファイルで届いたメールの処理を制御できます。典型的なdot-qmailファイルは、ユーザのホームディレクトリの下の~/.qmailや~/.qmail-XXXですね。 今回は、dot-qmailを使う上で知っておきたいことをTIPSを交えて紹介したいと思います。 例として、kbora@klab.org宛てのメールが~kbora/.qmailに届く場合を考えます。 qmailにはextension addressというものがあり、ユーザ名に続けて「-XXX」を指定することができます。例えば、kbora-oboko@klab.org宛てのメールは、~kbora/.qmail-obokoに届きます。このextension addressを活用すれば、管理者の手を煩わすことなくメールアドレスを増やすことができますね。 では、~/.qmail-inaが無い状態

前回に引き続き届いたメールの処理の仕方を解説します。 今回のテーマは、届いたメールをプログラムに処理させるにはどうすればよいか、です。 まず、dot-qmailの書き方から。 kbora-todo@klab.orgに届いたメールを、コマンド/home/kbora/bin/process-todoに処理させたい場合は~kbora/.qmail-todoにこう書きます。 | /home/kbora/bin/process-todo 行頭を「|」にすると、残りの部分はコマンドとして実行されます。オプションや引数を書くこともできます。 届いたメールの内容は、process-todoの標準入力に渡されます。 例えば、とあるメールアドレスにメールを送ると、メールの内容を社内のグループウェアのToDoリストに追加できる、なんてこともできますね。 環境変数 さて、dot-qmailの中で実行されるコマンド

前回の後半で、dot-qmailで実行したコマンドの終了コードによって、次の配送を行うかどうかを制御できると書きました。 今回は、この仕組みを活用した例を2つ紹介したいと思います。 携帯電話からのメールをあるプログラム(process-ktai-mailとします)で処理したいとします。 携帯メールのenvelope fromのドメインパートはキャリア毎に決まっているので、ドメインパートを見れば携帯メールかどうかを判断することができます。 しかし、この判断ロジックを同じようなプログラムのそれぞれに実装するのは面倒ですしDRY (Don't Repeat Yourself)の原則からも外れるので、こんな風にしてみましょう。 mobile-valveというプログラムが、携帯メールかどうかの判断を行う。 mobile-valveは、携帯メールの場合はexit 0(後続の配送命令を実行する)し、そう

前回は、openssl コマンドの -CAfile オプションでCA証明書を指定してみました。 しかし、この方法だと検証したいサーバ証明書がどの認証機関で署名されているのかをあらかじめ知っておかないといけません。「うちはぜ〜んぶべり☆☆☆だもん」みたいな運用ならばさほど困らないかもしれませんが、サービスによって利用している認証機関が異なっていたり、独自に組織別CAを構築して運用しているような場合は少々面倒です。やはりCA証明書は勝手に選択して欲しいものです。 特に弊社のDSASでは、様々なコンテンツが同じシステムに同居しているため、どのサイトがどの認証機関を使っているかを全て把握することは至難の業だったりします。 -CApath というオプションがあります。 使い方は -CAfile と同様で $ openssl s_client -connect localhost:4433 -CApa

先日の投稿で、 openssl s_client コマンドを使って軽く通信試験をしてみました。 実際にやってみた方はお気づきかもしれませんが、あのコマンドだと以下のようなエラーがでます。 $ openssl s_client -connect localhost:4433 CONNECTED(00000003) depth=0 (subject) verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 (subject) verify error:num=27:certificate not trusted verify return:1 depth=0 (subject) verify error:num=21:unable to verify the first certifi

netstat コマンドは，routing テーブルを表示したり統計を表示したりのにも使えますが，なんと言っても一番よく使うのは，現在開かれている TCP や UDP のポートの一覧を得たいときでしょう．サーバを管理する上でこの一覧は非常に重要で，日々お世話になっています．ただ，最近時々困った場面に出くわすことが度々ありました．それは，netstat コマンドで IPv6 アドレスを使ったコネクションのリストを取得しようとすると，アドレスの(表示上の)長さによっては途中でとぎれてしまうのです．これはどうやら， netstat コマンドがアドレスを表示するのに使用する文字幅が(端末の横幅に関係なく)固定になっているみたいで，その決められた幅に収まらないと省略するようなのです．そして一番問題なのは，それが省略されたアドレスなのかそうでないのかが明示されないので，表示されたアドレスが信用できない

サーバの管理なんぞしていると、「SSLのサイト作りたいからこの証明書を設置して欲しい」などと言われることは日常茶飯事・・・とまではいきませんが普通にあることだと思います。 でも、せっかく安全に気を配ってサーバに転送して設置して設定しても、「実はもらったファイルは違う鍵ファイルだった」なんて事はありませんか？　まあ・・・実際あんまりないんですけど、そんな事があったら気が滅入って寝込んでしまいそうになるので、実環境へ持って行く前に軽く動作チェックをするようにしています。 mod_ssl いれてブラウザでアクセス・・・でもいいんですが、それだと気が短い人には耐えられないので、以下のようなコマンドを叩きます。 $ openssl s_server -cert [ファイル名] -key [秘密鍵ファイル名] Using default temp DH parameters ACCEPT こうなれば成

今回はシステムの構築や運用をしている中で、各種設定ファイル(httpd.confとか)を記述する際に注意している点などを書きたいと思います。最初にお断りさせていただきますが、この内容は「こうあるべき」とか「こうしなければならない」といった押しつけがましいものでは決してなく、単に普段の生活の中で心がけている事などをご紹介させて頂いているだけですので気軽に眺めてやって下さい。 ファイル全体の見通しを良くすることで、設定変更時やトラブルシューティングの際のストレスを軽減出来ると思います。消してしまうのがどうしても心配であれば、デフォルトの設定ファイルは自分のホームにでも置いておけばよいですし、大抵は manやら付属ドキュメントを参照しつつ記述するので、実運用で利用するファイルにコメントを残しておく必要性は感じられません。それに、バージョンアップしたときに、そのコメントの内容自体が古くなってしまう

レイヤを問わず (ethernet から HTTP や SMTP まで) 、ネットワーク絡みのトラブルシューティングや挙動の確認をするときにパケットの流れが見られると非常に有益です。 開眼すると「パケットの流れが目で見える」そうですが、私などはまだまだ修行が足りず裸眼では見えないので、tcpdump というツールを使って見ています。 tcpdump はその名前があまりよくないと私は思っていて、"tcp" だけでなく udp やICMP や ethernet フレームまで覗ける超強力ツールです。 というわけで tcpdump の簡単な説明を書いてみます。 tcpdumpについて tcpdump は UNIX 系の OS で使えるツールなのですが、Windows 用にはWinDumpという CUI のツールがあり、tcpdump と同じように使えます。 GUI がお好みの方は、後でも紹介するE

Linuxには、kernl oopsが出た場合に自動的にrebootできる仕組みがあります。 この機能を使えば、OSが不意に停止してしまった場合に自動的にrebootしてサービスを再開することができます。 ただ、kernelメッセージは障害原因特定のヒントになりうるので採取できた方が好ましいのですが、自動rebootの場合はコンソールなどに出力されているかもしれないkernelメッセージを採取することができません。 というわけで、今回はkernel 2.6で実装されたnetconsoleを使い、kernel oops発生時にそれを記録しつつ自動rebootする方法を紹介したいと思います。 まずは、kernel oopsが発生した場合、動作を継続するのではなくkernel panicになるようにするのと、kernel panicが発生したらrebootするように設定します。 この設定は/pr

弊社のLinuxサーバ、ネットワークインフラのDSASの特徴のひとつに、100台近くある全てのサーバの内容が(数個の役割設定ファイルを除いて)同期されているという点があります。 これにより、 スケーラビリティ 予備機をサービス投入するだけで済むので、テレビCMなど突発的な高アクセス時にも迅速な対応が可能です。 増強が容易 サーバをラックマウントしたら適当なサーバからまるまんまコピーすればクラスタに参加可能です。まとまった台数の増強をする際に、いちいちCD-ROMからOSをインストールしていると日が暮れちゃいます。 役割の変更が容易 ディスクの内容が同じなので、もし、メールサーバが故障しても、適当なWebサーバの役割設定ファイルを変更して再起動するだけでメールサーバに早変わりできます。 メンテナンスが容易 ディスク上のファイルを更新した場合は、rsyncなどで全サーバに同期コピーすれば更新完

Linux 2.6 kernel の IPsec と NAT -- 2.6.15 と 2.6.16 の IPsec の違い 先に結論から書くと，2.6 kernel の IPsec を NAT と絡めて使う場合，NAT の方向によっては 2.6.16 以後のカーネルを使う必要がある，というお話です．2.6.15 系までのカーネルでは，意図したとおりに NAT が適用され無いことがあります．これは，IPsec のチャンネルを通るパケットが ESP パケットにカプセル化されるタイミング，に依るものです． ここ(日本語のページはこちら)にある図のように，iptables の各テーブルとチェインを順に辿っていきます．次のように IPsec 接続されたネットワークがあるとします． IPsec LAN 1 -- GW1 ======= GW2 -- LAN2 この場合，LAN1 から LAN2 に流れ