"家庭内乱"管理を少しでもラクにするには

このサイトをご覧いただいている方には、自宅のネットワークを仕切っている方、また実家や親戚の家のネットワーク（家庭内乱）管理をついつい頼まれてしまい、なかなか断れずに面倒をみるハメになっている方なんて、そこそこ多いのではないでしょうか？少なくとも私は実家や親戚宅のネットワーク管理にたびたびかり出されています。

また、ネットに繋がるようにして帰ってくるのは簡単ですが、いざしばらくすると「ネットに繋がらなくなった」と電話がかかってきたり、いろいろな都合でネットワークの変更が必要になるケースがあり、とっても面倒なものです。私は、そういう時のために、（内容はケースバイケースですが）簡単な設定資料を作っていたりします。


このネットワークにおいて、以前機器の移設時に配線ミスによる混乱があったため、この資料は、どちらかといえば物理配線にフォーカスした内容となっています。とはいえクライアント側の設定に必要な項目は網羅されているので、この資料があれば

• 問い合わせを受けたときに何がどうなっているかを思い出せる
• ユーザ自身で有る程度の配線見直しなどが可能
• クライアントの設定方法を書いておけばユーザが自分たちで新ノードを追加できる。もしくは設定業者が対応できる
• 大きなトラブルがおきたとしても、他の人に対応を引き継げる・・・ことがある

などのメリットが生まれます。

ところで、今回紹介した図は2006年1月時点の私の実家のネットワーク構成に基づいたものです。私は実家から東名高速道路で約300km離れた地点に住んでいるため、なかなか度々面倒を見に行くことはできません。その後実家のネットワークはADSLからひかり電話にサービスを変更するためファイバの引き込みONUなどを設置したのですが、その作業の担当者にこの資料を見せることで、スムーズにWAN側の切り替えを済ませることができたそうです。

パスワードなどの機密情報も含めて記載されている点など、賛否両論はあるでしょうが（そもそもセキュリティ要求が高いような場所ではWANの切り替え工事を電話工事の担当者にやらせないと思いますが:-）、この手の資料は、「備えあれば憂いなし」です。


なお、構成が変わったときにはドキュメントの更新もお忘れなく。

404のかわりに任意のレスポンスコードおよびエラーメッセージを返すには

mhag が、存在しない URL にアクセスされたときに 404 ではなく別のレスポンスコードを返そうと頑張っていました。詳しくはこちら。

最初は目的のレスポンスコードを返す CGI スクリプトを書いて、 mod_rewrite で URL を書き換えて実現していましたが、この方法では 404 のたびに CGI スクリプトが起動されるため効率面ではあまり思わしくありません。

ErrorDocument でレスポンスコードおよびエラー時のドキュメントファイルを指定することもできますが、他の方法として、（静的でよければ） mod_asis を使うと、レスポンスコードもエラーメッセージも自由に設定できます。

これらの方法であればプロセスが毎回 fork したりせずにすむので、アクセスが多い Web サイトでも安心ですね。

その他の解としては mod_perl などで任意のレスポンスを返すハンドラを書いてしまう手もあるでしょう。この方法ならヒット毎の fork を防ぎつつ、動的にレスポンスコードやメッセージを自由に制御できます。

iTunesにID3v2タグを破壊される

去年の春から本格的に Mac ユーザとなった私ですが、新型 MacBook への乗り換えにともない MP3 も新しいマシンに移しました。

もともと Windows の iTunes で管理していたファイルを MacBook に移した段階で ID3 タグが一部化けたりしていて、ちょっとだけ困っていたのですが、 MacBook から新型 MacBook にファイルを移して iTunes に再度インポートしたところ、これまで大丈夫だったファイルまで多数文字化けしてしまいました。

面倒だったのでこれまで放置していたのですが、忙しい中の現実逃避がてら復旧作業にやっととりかかった、、、のですが、、、、

Perl モジュールの MP3::Tag をインストールしていじりはじめたところ、思ったよりも状況は深刻なことがわかりました。当初の想定では Windows 時代に作成した MP3 の ID3 タグが UTF-16LE ベースで記録していないのでバケているのだろう、だからインポート前に UTF-16LE にエンコードをかえてやればいいと思っていたのですが... 実際には、iTunes がバケた ID3 タグをファイルに rewrite してしまっていて、文字化けがどういう経緯でどうなったのか判断が不能な状態になっていました....

まあ手作業でタグをつけ直せる範囲なので(ライブラリ全体で3500曲ぐらい)、気がむいたときに気になるところから直していくことにします。なお、だいたい影響を受けているデータは2001年〜2003年頃にリッピングし、ちまちま手でタグをうっていた頃のファイルなどがメインでした。 MacBook 上の iTunes でリッピングしたファイルもいくらかおかしくなっていましたが.....

しかし、勝手に ID3 タグ書き換えられるのは正直困りますね。いや、最近はそんなことされても（心の奥底で否定しつつ）文句言わずに使ってあげるアポー信者として堕落した日々を過ごしているわけですが:)

時代は 802.11n なので...

先日、無線LANのアクセスポイントのファームウェアをアップデートしたわけですが、それ以後、実は新しい問題が発生してしまいました。

なぜか新 MacBook がレジューム復旧後にアクセスポイントに再接続できないのです。

アクセスポイント側を再起動すると解決することから、アクセスポイント側のソフトウェア的な問題だと思われます。とはいえ 2003 年頃の製品だけにアップデートもう期待できないので、あきらめて新しいものに交換することにしました。

悩んだ末、最終的に Aterm WR4500N を選定。 8,000 円をきる価格で入手できる 802.11n & b/g 対応アクセスポイントです。最初は WR8500N も検討したのですが

• ギガビットイーサポート ... でもそんなにたいしたスループットが期待できないからよくね？（クライアント的に）


• IEEE802.11a対応 ... X31 の頃は g 対応の無線モジュールが乗ってなかったから a つかってたけど、今は a 付き端末はあんまり使わないから、もう g でよくね?


• 300Mbps 対応 ... でも MacBook どうやら 150Mbps モジュールらしいよ?

などなど、ここでがんばって倍近い投資をしたところでなんのご利益も得られず、そもそもアクセスポイントも昔は2万以上出して買ってたわけですが、今時はアクセスポイントという製品群自体がずいぶん安くなったし、本当に高いスペックの製品がほしくなったらその時のハイスペック機に買い直せばいいやという結論にいたり WR4500N に落ち着きました。

今ってルータモードのほかにアクセスポイントモードってのがあるんですね。そのほかにも、最近の AP は設定項目などもすっきりしたように思います。6年ぶりに無線LAN親機の設定をして感動しました。

時代は 802.11n だけど....

ご無沙汰してます。ファームウェアアップデートには無頓着なブログ主であります。

新型 MacBook を購入しウハウハなワタクシですが、 MacBook-MacBook 間で大きなデータの転送をかけると、無線LANルータの WR7600H が死ぬので、久々にファームウェアのアップデートをかけてみました。

この無線LANルータはもともと 2003 年の ThinkPad X31 リリース直後に IEEE802.11a の無線LAN環境を構築するために購入したものです（当時、私の実家にはオレ専用の 802.11a と家族用の 802.11b の２つのAPがありました）。

アップデート前のファームウェアバージョンは 7.8 ぐらい。どうやら2003年上旬リリースのファームウェアのままこれまで動かしていたようです。一気に2006年リリースの最終版ファームウェアと思われる 8.6b へアップグレード。データ転送中にAPが死ぬことはなくなりました。

しかし今時のマシンだと IEEE802.11n とかいうヨクワカラナイ規格で、理論値150Mbpsとか電波到達距離200mとか意味がわからないスペックになってますね。今時は無線LANメインの生活だし、そろそろAP買い換えてもいいかな〜。

使用していないハードディスクを積極的にスピンダウンするには

24時間稼働させるサーバでは、ハードディスクは原則24時間稼働させなければいけません。しかし、ハードディスクは内部にモータやヘッドなどのメカを持っており、動かしておくということは電力の消費、発熱、騒音を発するということになります。

LinuxのATAドライバでは、 hdparm コマンドを利用すると、ディスクアクセスが少ないときに積極的にスピンダウンさせることができます。

/sbin/hdparm -S 60 /dev/sdb

制御対象のディスクは/dev/sdb, -S オプションのパラメータとして、スピンダウンまでのアイドル時間（5秒単位）を指定します。60を指定した場合、60秒*5=300秒、つまり５分間アイドルの状態になったらディスクをスピンダウンさせます。

実際には、ファイルやディレクトリの読み書き、アクセス時間(atime)の更新などさまざまな操作がI/O発生の要因になります。特にライト要求は、Linuxでは原則5秒ごとにコミットされるため、I/Oが発生してから5秒以内にスピンアップしてしまいます。スピンアップしてしまう要因をきちんと取り除かなければ、スピンダウンとスピンアップを繰り返しディスクを痛めることにもなり得ますので注意が必要です。また、経験上ハードディスクは回しっぱなしの状態が一番安定すると言えます。スピンダウンを積極的に行うこと自体がライフタイムに影響すると考えられます。このため、メリットとデメリットは意識した上で検討しなければなりません。


積極的なスピンダウンを行うためには、以下のような点を検討するとよいでしょう。

• ファイルシステムのオートマウントを有効化し、普段はアンマウント状態としておく


• アクセス時間(atime)の更新を抑制するために noatime オプションをつけてファイルシステムをマウントする


• ディスクの利用目的を明確化し、I/Oをコントロールする
  例１）バックアップ用ディスクは毎晩4:00にマウントし、バックアップ終了後アンマウントする
  例２）MP3プールをシステムディスクと分離しておき、オートマウントする構成にしておく
  
  例３）参照メインであれば、ライト操作を防止するため、普段は可能であればroマウントにしておく
  などなど...

Firefox 3 で、検索バーの結果は新しいタブに表示したい

Sleipnir をしばらく使っていた身としては、 Firefox 3 に乗り換えると気になるのが『検索バーでの検索結果が、今見ているタブに開かれてしまう』ことです。Slepinirでは新しいタブとして検索結果を開いてくれるのですが....

この挙動を変えるには、 about:config を開き、 browser.search.openintab を true に設定するとよいようです。

ただし、 Tab Mix Plus を有効化している場合は、アドオンの「タブを開く」タブページの中に、検索バーを新しいタブで開くためのチェックボックスがあります。


その他、デフォルトの検索バーの機能を置き換えるタイプのプラグインを導入している場合は、プラグイン側に設定がないか探してみるといいかもしれません。