サーバとかネットワークに関するいろいろなこと
先週ぐらいから amatsukami.jp サーバから恐ろしい音が聞こえていた。それは「カラン……カラン……」という金属同士がぶつかるような音。HDD が壊れたときの音である。このくっそ忙しいのに……。やっぱり猛暑が堪えたんだろうなぁと思った。壊れた HDD は 2009 年の 2 月に導入された 1.5TB x 4 台構成のいずれかである。
amatsukami.jp サーバは 3 年ごとに HDD を交換していたのだが、だいたい 3 年以内に容量が足りなくなって交換というサイクルが続いていた。が、今回 3 年を越えても容量は満杯にならなかったため、そのまま使い続けていたのである。
というわけで、この 1.5TB x 4 を 4TB x 2 の構成に構築し直した。
いちおう異音がし始めてから HDD そのものは耐えてくれ、データ欠損などはなく、無事に移行出来た。
4 台から 2 台に減ったことで消費電力も下がるし、音も若干静かになるしで、少しホッとしている。
そういえば、4TB より容量の大きな HDD が出ないなぁ。
朝日新聞に、こんな記事が載った。
実は技術系の掲示板『スラッシュドット』でもこの手の話題がチラホラ出るようになった。
これらの記事を鵜呑みにするならば、SSL 通信を米国当局が復号出来るということになるわけだが、本当かなぁ～～～。本当だとするとこれは非常に心理的にイヤだ。
しかし量子コンピュータがすでに実用化されていて、ばんばん SSL 通信をリアルタイムで解読しているというのも考えにくい。
問題点はいくつかある。
で、1 に関してはひょっとして Verisign などの認証局を陥落させたってことなんじゃないかなぁ、と何となく想像している。つまり認証局から直接秘密鍵を取得する何らかのルートなりなんなりを手に入れたのではないかと。そうすれば、認証局に登録された SSL 通信ならば解読出来ることになる。
もしそうだとするなら、正規の証明書はアメリカに解読されてしまう脆弱な証明書で有り、オレオレ証明書と言われる、個人が勝手に発行した証明書こそがアメリカに解読されない安全な証明書と言うことになってしまう（汗）。
2 に関してはわりと簡単にクリア出来そうだ。まぁそもそも米国の IP 通信網を流れないデータについては無視しても良いだろうし、DNS もしくは各国の IX に働きかけて、どんなデータでも米国を経由するようにすることは出来る。もっともそんなことをすれば、アメリカの回線がそうとう圧迫されそうだが（汗）。
んー、取り越し苦労なのか、もはや対抗する手段がないのかは解らないが、将来的に Linux 系にサーバを移行した方がいいのではないかと漠然と思い始めている。というのも Microsoft はアメリカ当局に手の内を漏らしそうだし、アメリカ当局が復号出来ないような暗号形式を実装するとも思えない。そういうのは Linux 陣営の方が実装が早いだろうし、アメリカ当局の干渉を比較的受けないのかなぁと思っている。
ボクはネットワーク管理者なわけだけど、最近困ったことがある。それはメーリング・リストにメールを投稿する際に、送信したい相手も To に入れて出す人が多いと言うことだ。どういうことかもう少し詳しく解説する。まずメーリング・リストというのは、メーリング・リスト用のアドレスを造り、そこにメール・アドレスを登録しておく。するとそのメーリング・リスト宛てに出したメールは、登録したメール・アドレスに配信されるという仕組みである。
例えば、プロジェクト・メンバーとか、飲み会のメンバーとか、ある集まりに対して、その集まりのメンバー全員のメール・アドレスを登録しておき、そのメンバー全員に一度にメールが送れるシステムである。
ボクらの業界ではプロジェクトが立ち上がると、だいたいそのプロジェクト・メンバー全員に配信されるためのメーリング・リストを造り、そこでプロジェクトに関する連絡のやりとりをする。例え自分に関係のないことであっても、そのメーリング・リストでやりとりすることによって、他の状況も解るからだ。
つまりメーリング・リストにはあらかじめそのプロジェクトに関係している人たちが登録されているわけである。で、そのメーリング・リストのアドレスと、そしてそのメーリング・リストのメンバーにもメールを出す人がいるのである。するとどういうことが起きるかというと、相手には同じメールが二通届くことになる。
ボクは様々なプロジェクト・リーダであるため、社内の様々なメーリング・リストの管理者でもある。で、ボクに用事があるたびに、メーリング・リストとボク宛にメールを出されるものだから同じ内容のメールがいくつも来るのだ。
いや、わかってるっちゅーねん！ 一個出せばええ。つーか、メーリング・リストがあるんだから、そこだけに出せ！！
他にもメーリング・リストに流れているメールがボクに行ってないと勘違いして、ボクに転送してくる人もいる。いや、いいから To を落ち着いて確認しろ！ 転送だと何か別のメールと勘違いするじゃないか。
そんなわけで、こう言うのも IT リテラシって言うのかねぇ？
あんまりそういう言葉で責めたくはないけど……IT あんまり関係ない気がする。とにかくちゃんと From と To を確認しようぜ！ っていうか、してください、イヤマジで（ぁ
ボクの勤め先のメール・サーバはボクが立てた glace.me ドメインのモノがある。ただこのメアドは当然うちのブランド用にしか使えない（汗）。親会社は別のメール・サーバを持っているわけだが、メーリング・リストやその他、メールの様々な機能は提供されておらず、現状 glace.me サーバに依存している。
とはいえ、親会社の仕事に glace.me というドメインは使えない。
で、今まではどうしていたかというと、親会社のメール・サーバに転送専用のアドレスを作り、その転送先を glace.me にしておいたのだ。こうすることによってメーリング・リストや新入社員の新しいメアドなどは実体を glace.me 上に作っておき、クライアントや名刺などには親会社のドメインを入れておくわけだ。
ところが困ったことが生じている。それは親会社の分のメールの管理もボクがしなければならないと言うことだ。特にメーリング・リストではプロジェクト・メンバーの出入りがあるとその都度ボクが追加・削除しなければならなかったし、今誰がメンバーに入っているかをプロジェクト・リーダに伝えなければならなかった。
ちなみにメーリング・リストにはリスト・プロセッサという機能があり、そのメーリング・リストにコマンドを書いて送ると、メーリング・リストへの加入や脱退、そして加盟者の一覧を取り寄せることが出来るのだが、これはセキュリティ上殺している。万一、メーリング・リストのアドレスが洩れた場合に第三者から情報を引き出されるのを防ぐためだ。
で、思いついたのが本社用のメール・サーバを別に立てて、本社の人に管理してもらうこと。この時、メール・サーバは LAN 内専用のサーバとなってしまう（つまりインターネットからはアクセス出来ない）。というのもプロバイダは一つしか契約していないし、外向きのメール・サーバはすでに glace.me が稼働しているからだ。ただ、どうせメーリング・リストにしか使わないサーバだから、社外から見えなくても良いのだ。これがメール・ボックスも設置するとなると、外向きのことを考えないといけないが（その場合はルータに仕掛けが必要になる）。
メールの流れはこうだ。
うちでは XMail というメール・サーバを使っているのだが、どこをどう探しても任意のドメインだけ他の SMTP サーバに飛ばすという設定が見つからない。単純にドメイン転送ってのはあるんだけど、この方法だと転送元にも同じユーザがなければ機能しない。つまり ml.glace.me に hoge という名前のメーリング・リストを作った場合、glace.me にも hoge というメーリング・リストを作らなければならないのだ。なんだそれ！？ それじゃぁ、ml.glace.me でメーリング・リストを作るたびに、glace.me でも同じものを作らないといけないではないか。
というわけで色々と英語と格闘したり、いろんな掲示板を徘徊したりして、どうやらカスタム・ドメインという設定があるというのにようやくたどり着く。XMail の MailRoot ディレクトリにある custdomains というディレクトリの中に転送したいドメイン名のファイル名を作り（この場合、ml.glace.me.tab）、そのファイルの中に転送したい SMTP サーバを指定すると、転送したいメールが来たときにすべてその SMTP サーバに転送してくれることが解った。
ml.glace.me.tab の中身
“smtprelay” “listserver.glace.local”
こうすることによって、めでたく ml.glace.me 宛てのメールはすべて listserver.glace.local というサーバに転送されるようになった。ちなみにこの listserver.glace.local は仮想サーバである。いやー、ホント、仮想マシンは便利だ。ちょっと何か新しいサービスを立てたいとき、実験したいとき、仮想サーバを立ててそこに入れればすぐに動かせる。昔は何か実験するんでも余っているマシンとかパーツとかを見つけてきて組み立てて、OS インストールしてとかやっていたんだけど、今や、ほぼボタン一発でもう一つサーバが出来てしまう。うーむ、恐ろしい。
最後に、ここであげているドメイン名はあくまでも説明のためにテキトーにつけたモノなので、実際はこれらの名前で運用されているワケではない。
発端は 7/1 の glace.me サーバのログがおかしいことだった。どうおかしいかというと、特に新しい更新ぶつも何もないのに、1 日 15,000 ユニーク IP 来ていたからだ。ハテ？ どっかのニュースサイトに載ったのかなぁ？と思いながら、Referer を調べて見ると……。
あ、ちなみに Referer とは glace.me 上のデータがどこのサイトから参照（reference）されたかが記録されている、ログの中の一項目である。HTML に限らず、ブラウザでアクセス出来るすべてのデータはブラウザでアクセスすると、その前はどこのページにいたか記録されるのだ。ただこれはブラウザがサーバに返している情報なので、ブラウザ側で偽装は可能である。例えばセキュリティ対策ソフトではこの Referer を返さないようにできるものもある。
ただ Referer を返さないとちゃんとページを表示しないサイトもあるので要注意だ。fc2 さんや itmedia さんなんかは Referer がちゃんと設定されていないと画像ファイルにアクセス出来なかったりする。
で、ウチに大量にアクセスが増えていた原因は、海賊版の BitTorrent のインデックス・ファイルを配布しているサイトだった……orz しかも 2 サイトもある。その時の twitter の記録は、以下の通り。
この用は違法ダウンロードサイトからオフィシャル・サイトにリンクを張るという神経がよう解らんｗ 掴まるリスクはないと踏んでいるのかなぁ？ ちなみにその後も別のダウンロード・サイトにバナーを貼られ、その時は DDos 攻撃化してしまい、バナーを置いてある dl.glace.me がダウンしかかった。
やっぱり凄いんだな、違法ダインロード・サイトの人気。アフィリを貼っておいたら、きっと笑いが止まらないほど儲かるんだろうな。
ただここでもう一つの希望が。
前に日記にも書いたけれど、「寄付画面」ってやっぱり意味があるんじゃないかなってこと。最低でも英語で「このソフトを無料で手に入れた方へ」とか言うボタンを作っておいて、コピーへの影響を説明し、寄付先及び寄付の方法を記した画面をつけたら寄付をしてくれる人がいるんじゃないだろうか？
まったく無駄じゃないとおもうんだよねー。
もしくは、OVER DRIVE さんがやっていたような amazon の欲しいものリストの公開とかね。
4 月頃からかなぁ…… twitter に検索単語を仕込んで、それを表示させるようにした。どういうことかというと、twitter に検索文字列を仕掛けておくと、世界中のツイートからその検索文字にマッチするツイートがあったら、そのツイートを表示してくれるというヤツだ。
個人的にはやりたくなかったのだけど、なんつーか、もっと意思表示した方がいいと思い直し、仕掛けたしだいである。
まず三つの項目に分けた。
具体的な引っかけている文字列は以下の通り。
“glace.me” で引っかけると、Galette も上がってきちゃうんだけどね。なにせ、Galette のサイトのアドレスも glace.me なので。「いろは」や「翼をください」「C2H6O」が入ってないのは、一般的な単語過ぎて自分の作品以外のことしか引っかからないから（汗）。なんかこの辺、うまい検索の仕方があるといいんだけどなぁ。
で、関連するツイートがあったら積極的にリツイートしたり、引用したりするようにしている。まー、今のところは「生きてるよ～」って表明ぐらいにしかなってないけど……。もっと同人とかで自分の作品が作れていればねぇ、こういうツイートも意味があるのかもしれないが……。
そんなわけで、ツイートでいろいろと邪魔をするかもしれませんが、生暖かく見守って下さいませ。
ブランドの公式サイトを運営するサーバを一つ上のコースに変更した。具体的に言うと、SAKURA VPS の 1G コースから 2G コースへ。1G コースではメモリがまったく足りず、土日は Apache の同時接続数を上回ってしまうという状況になっていた（関連記事：落ちる glace.me）。
関連記事にあるようにこれの原因は WordPress をつかっているからで、WordPress を使わずにすべて静的 HTML に移行すれば解決するのだが、年齢認証の所やメニューの構造などでべったりと WordPress に頼り切ってしまっていて、今更静的 HTML とか無理っす！ ってことで、2G コースに移行することに（ぁ
で、石狩のデータセンタだと初期費用無料という言葉に目にくらみ、石狩にしてしまった。けど、ダウンロード・サーバも石狩なのよね（汗）。なので、旧公式サイトをダウンロード・サーバにして（こちらは大阪）、公式サイトを石狩にすることにする。
まぁこれらのサーバは Linux なのでボク自身がやるんじゃないんだけどね（ぁ
というわけでアクセスが少なくなり始めた AM3:00 頃、公式サイトを停止し、作業は 1 時間ほどで終了。2G コースにして、CPU コア（仮想）が 2 から 3 に、そしてメモリは 1GB から 2GB に。問題はメモリだったので、メモリはほぼ倍増したことになる。んで、同時接続数を倍に……とはせずに、30 から 50 にした。それでも重くてガタガタということはなくなったようだ。ちなみに Apache の同時接続数のデフォルト値は 200 なので WordPress をつかっていることにより 1/4 にパフォーマンスが落ちていることになる。うーむ……。VPS で WordPress ってのがやっぱりキツいのかなぁ。
グラフで見ると、ちょうど真ん中ら辺の Fri 00:00 アタリがぴったり 30 で頭打ちになっている。この間はめっちゃ重くなってしまっていた。Fri 12:00 で 30 を越えてグラフが伸びているのはもう 2G コースになっているからである。
