2010年4月15日

新世代ATOM D510

 ネットワーク監視用に1台の物理鯖が欲しくなった。

 現在は監視も仮想マシン上で行っており、ホストが死ぬと障害に気づくことができないのだ。

 実家鯖と自宅鯖で互いに監視しているのだが、できれば監視専用の鯖があると何かと便利だ。


 ハードウェアの選定に悩む。監視だけなので低電力鯖がいい。まずはこれが大前提で、中古のPentium4デスクトップとかは絶対に選べない。

 玄柴(KURO-SHEEVA)がいいかなと思ったが、入荷瞬殺で買えない。

 玄箱は今更感がある。

 ぷらっとホームのOpenBlockSは高い。

 ネットブックの中古はどうだろうかと思った。

 2万円弱ぐらいからある。が、中古で1万以上払うのはなんか嫌だ。

 ATOM搭載コンパクトデスクトップはどうだろうか。

 しかし、ASUSのもacerのも、思いのほか高価格を維持している。

 EPSONのNP11(24,150円)なんてどうだろうかと思ったが、やはり新品でも2万円以内に抑えたい。


 ATOMベアボーンで探してみる。

 ATOMマザーは、新世代ATOMのD510搭載品が安く、旧世代との値段がほとんど変わらない。

 旧世代を選ぶ理由は皆無だと思った。

 ちなみに、新世代ATOMはチップセット機能の一部をCPUに取り込んでいる。これによりシステムのチップ数削減と、消費電力低下を実現している。だが、パフォーマンスはほとんど変わらないらしい。

 D510搭載ベアボーンを調べると、F510SD が安い。これでポチろうと思ったら、ソフマップでマザボをグレードダウンしたものがさらに安く売っていた。電源も90Wから60Wにダウングレードしている。型番はSMA510 D510/60W。

 ダウングレードしているとはいえ、チップセットは変わらずINTEL品だし、ピンヘッダだったシリアルとパラレルがバックパネルに出ているのも好感触。

 ということで、SMA510をポチった。ついでに 2.5inch HDDもポチった。合計2万円に収まった。メモリは手持ちの1GBx2を乗せるつもり。


 DualコアATOMの構成では、中古を含めても再安で入手できたのではないかと思う。もちろん、メモリ代金を乗せると再安ではなくなるかもしれないが。

Posted by rukihena at 01:11:24 | Comments [0] | Trackbacks [0]

2009年1月19日

移転作業中

 サーバの移転作業をしている。

 このブログは移転の対象外だが、昔々に作った、16エントリだけ書いたブログが移転対象で、どうしようか悩んでいた。

 MySQLの移転とかも必要なので面倒くさい。

 面倒なので、このブログに統合しちゃった。

 その他、バーチャルドメインで動かしていた各種メールサーバやWebサーバが移転対象だったが、殆ど移転できた。

 残るは http://www.rukihena.com/ のみ。これだけ残しちゃったのは、実験的にssiやらcgiやらphpやら動かしていて、動作検証が面倒くさいからだ。

 それと、昔のコンテンツを見るのは恥ずかしい。

Posted by rukihena at 23:05:20 | Comments [0] | Trackbacks [0]

2008年11月11日

フレッツ・ドットネットで大量ファイルコピー

 実家鯖から自宅鯖に、大量ファイルコピーをする必要があった。大量って本当に大量で、400GBぐらいである。

 プロバイダ経由でコピーするときっと帯域制限を掛けられるか、最悪の場合アカウント停止になる恐れがある。

 そこで、フレッツ・ドットネット経由でコピーした。

 フレッツ・ドットネットの趣旨からは外れるのだが、フレッツ・ドットネットはIPv6の閉域網を構成しているのを利用した。

 rsync でIPv6アドレスを指定してコピーしたら、20時間程度でコピーできた。平均するープットは60Mbpsといったところ。上出来。

 双方で315円のオプションを契約する必要があり、それだけのために契約するのはもったいない感じだが、まあIPv6の実験とかできて面白いので契約している。

Posted by rukihena at 20:33:51 | Comments [0] | Trackbacks [0]

2008年6月 1日

P7K500バグ遭遇?

 先日、このサーバが落ちた。落ちたというか妙な動作だった。

 各種デーモンの簡単な応答だけはするので、死活監視(nagios)では検知できなかった。検知したのはボクがボク用のp2にアクセスしようとしたときに応答がなかった時だ。

 調べてみると、/home がリードオンリーでマウントされている。「なんかエラーがあったのでリードオンリーでマウントしなおしました」というようなエラーメッセージが吐かれている。

 /home は2台目のドライブ、HGSTの500GBをワンパーティションで使っている。つまり、/dev/sdb1 に割り当てている。

 とりあえずリブートしてみると、/dev/sdb1 がぶっこわれているので fsck でなんとかしろと言われ、言われた通り fsck /dev/sdb1 をやったら何行か意味不明のメッセージをゲロゲロ吐いて終了した。ボクは fsck のエラーメッセージをまじめに読んだことがない。まじめに読んでも解決できそうにないし、とりあえずマウントして様子を見たいので読み飛ばしてしまう。

 で、とりあえずマウントできたので放置してみたら、数時間でまたリードオンリーマウントしやがった。

 しょうがないので近所のPCデポに買いに行った。秋葉原価格より高いがしょうがない。

 dd でコピーするか、cp -a でコピーするか迷ったが、論理矛盾までもコピーしてしまう dd はよろしくないだろうから cp -a でコピーした。このときはエラーはでなかった。

 どのファイルがぶっこわれているか未検証だが、これでとりあえず復旧できた。

 壊れた原因だが、そういえば HGST のドライブで不具合情報があったような。やじうまWatchで見たような。と思って過去ログを見る。hdparm -I /dev/sdb で型番を調べる。HDP725050GLA360(P7K500) だ! おめでとう!! 原因が特定できました!!!

 しかし、ddコマンドによる検証では問題はなく、本当にこれが原因だとは言い切れないのがツライところ。

 ちなみに環境はは Dell SC430 に Debian 4.0。

Posted by rukihena at 02:27:33 | Comments [0] | Trackbacks [0]

2008年4月17日

Windowsの名前解決が失敗する件

 常駐先で利用させていただき賜うているパソコン(XPproSP2)が名前解決に失敗あらせられる。

 WORKGROUP配下に一覧が出ないというレベルではなく、「ping コンピュータ名」 とかが漏れなくcould not find host になる。もちろん、「\\コンピュータ名」も使えない。

 ちゃんと解決するのは面倒なので hosts に書いて運用していた。見に行くサーバは1台だけだし。

 しかし、見に行くサーバが3台ぐらいに増えて、hosts の管理が面倒くさくなった。「1台、2台、たくさん、もっとたくさん」って感じ。

 これはちゃんと解決しなければならない。

 ipconfig /all をよく見ると、Node Type が Peer-Peer になっている。

 これは WINS鯖が存在する環境用の設定だ。ここの環境では特に指定がないので、Hybrid になるのが正解のはずだ。

 これをクリアすべく、ipconfig /renew とか、ipconfig /release とか、インターフェースの無効→有効とかいろいろ試したが、Peer-Peer のままだ。なお、デバイスドライバの削除→インストールは面倒なので試していない。

 レジストリを見ると、

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters

DhcpNodeType

2
だった。

 これを削除し、ipconfig /renew をしたら、今度は Unknown になった。でも周りのパソコンは漏れなく Unknown なので気にしない。

 これで名前解決ができるようになった。


 このパソコン、別の環境で誰かがセットアップして、宅配便で送られてきたものである。

 セットアップした環境では WINS鯖が居て、DHCP鯖ではNodeType(046)にPeer-Peer(2)が指定されていたのだろう。そんなMS的キッチリな環境から、ユビキタス的ユルイ環境に持ってくるとこの現象が起こるっぽい。

 クライアントPCに負担を掛けない解決策としては、ユビキタス的ユルイ環境のDHCP鯖において、NodeTypeを明示的にHybrid(8)(またはBroadcast(1))と指定しておくことだろうか。

 っていうかOSのバグだろこれ。

 http://support.microsoft.com/kb/903267/ja で解決できるから問題ナシとか考えてないだろうな?>MS

Posted by rukihena at 12:58:23 | Comments [0] | Trackbacks [0]

2008年1月27日

CentOS に ProFTPd をインストールする

 先日購入したML310G5には、CentOS をインストールした。

 ボクが管理するLinuxはDebianに統一しようという脳内規約があるのだが、ML310の管理ツールがやっぱりメジャー路線OSにしか対応しておらず、Red Hat Enterprise Linux(以下RHEL)互換のCentOSぐらいしか選択肢が残されていなかったのだ。

 CentOSを入れても、ML310管理ツールのインストーラーは「対応してねー」と言ってくるのだが、「/etc/redhat-release ファイル書き換え技」で、RHEL5のフリをしてやればインストールできる。


 さて、ProFTPdをインストールしようかなと思って yum install proftpd と打ったところ、「そんなのねー」と言われてしまった。
 うーむ、困った。

 ソースからコンパイルしてもいいのだが、それすなわちセキュリティパッチのリリースを自力で監視する必要があるということになる。それは避けたい。

 そもそもなんでメジャーOSのクセに ProFTPd というメジャーなFTPサーバに対応していないんだ!? と思う。

 RHELのメジャー具合と、パッケージの品揃えの中途半端さからすると、きっとサードパーティーの超便利なリポジトリが存在するはずだ!!!

 と思って探したら、RPMforge というものが、ソレっぽい。

 RPMforge のリポジトリを加えたら ProFTPd のインストールもコマンド一発!

 ということで、CentOS を入れたら RPMforge を追加するのはデフォっぽいなと思った。

 やり方の詳細はググってください。

Posted by rukihena at 00:47:50 | Comments [0] | Trackbacks [0]

2008年1月24日

APCのSmart-UPS1400(SU1400RMJ2U)購入

 洗濯乾燥機(1200W)を購入して以来、頻繁にブレーカーが飛ぶのでUPSを増やした。いや、購入前からも頻繁だったのだが。

 UPSはすでに自宅鯖&ボクPC用と、HDDレコ用の2台が存在する。だが妻PCには接続していなかったので、ちょっと可哀想だった。


 で、購入するなら電池残量とか電源負荷とかを調べられるヤツがいいよな、と思いつつ、UPSについて調べてみた。

 Linuxで使うなら apcupsd を使うよなってことで、APC製のに絞られてしまう。

 APC製で安いラインナップだと、電源タップデザインの ES500 がある。だがこれは電池残量が調べられるものの、電源負荷が調べられない。その上になると CS500 だ。そうすると5千円ぐらい高くなる。

 だが電源負荷を知りたいだけなのに、この価格差はボクの中の経理担当が許さない。

 ふとオークションを見てみた。

 すると、大容量ラックマウントの古いのが、安値でゴロゴロモリモリ出品されている!

 あんまし古いのも嫌だし新しいのは高いし、で、まあ悩んだプロセスはばっさり省略して、結果的には SU1400RMJ2U を\5,900-で落札した。CS500の3倍近い容量、価格は最安値の半分以下。

 落札したものは直接取りに行った。送ってもらう場合は梱包手数料(\2,000-)を取った上に着払いで送るというシステムだったので、自分で取りに行った。まあ、だからこそ安く出品されていたわけだが。

 ちなみに同機種を5台出品していて、落札者は2名だった。店頭の出入り口付近には2台置いてあった。もう一人の落札者も自力運搬なのだろう。

 限定5台から2台売れたはずだが、いま見たらまた限定5台で出品されている。まあそんなもんだろう。というのは店頭の中古品在庫の数々を見て思った。


 さて、買ってきた SU1400RMJ2U を自作通信ケーブルで接続して、apcupsd の apcaccess コマンドで情報をゲットするといろいろ情報が見れる。個人的に興味があるのは内部温度。MRTGでグラフ化したい。

 某所でも CS500 の内部温度をグラフ化しているのだが、結果は一直線だった。どうも、CS500の場合、ITEMPで返す値が29.2度で固定っぽい。ググってみると、apcaccess の実行結果を埋め込んだコンテンツがたくさん見つかる。検索条件の数字を変えると、とたんに0件に。

 負荷と残時間は次のとおり。

LOADPCT : 31.2 Percent Load Capacity
TIMELEFT : 43.0 Minutes

 話半分としても20分あり、ブレーカー対策だけにしては「役不足」な感じ。でもまあCS500より全然安いからいいや。

 バッテリの寿命が心配だが、ヘタったら互換バッテリーで安く済ませる予定である。1400用互換電池は CS500の最安値よりは高いが、通常店頭価格よりは安い感じ。

 このUPSは自宅鯖&ボクPC用となり、元のUPSは妻用に転用した。これで、宅内IT機器の電源保護が完了した。

 次は洗濯と食器洗いと炊飯の中断対策となるわけだが、これにはもう一クラス上の超絶にデカイUPSを付ける必要があるため、ちょっと難しい。

 根本的対策は契約アンペア数の変更になるのだが、建物的に30Aが限界でありすなわち「転居」が必要にってそれはムリ。

Posted by rukihena at 22:24:42 | Comments [0] | Trackbacks [0]

2008年1月18日

ML310 G5 に Debian Etch インストール

 某所に設置する ML310 G5 が届いた。

 今日は外が寒いので、サーバ本体も冷え冷えだ。部屋に入れたら速攻で結露し始めた。

 電源を入れたら確実に壊れそうである。

 本来なら、箱に入れたまま入り口付近に放置して温度を同調させるべきではあるが、もう開梱しちゃったので部屋に入れた。

 ホットスワップなハードディスクを抜いてみると、盛大に結露している。いまさらなので気にしないことにする。


 2時間ぐらいして、結露が解消されていることを確認して電源を入れたら正常に動作した。

 さて、Debian Etch r1 の CD-ROM を入れて、ブートして、日本語を選択して・・・

 CD-ROMドライブが認識されない!!!

 ML310 G5 のチップセットは Intel 3210 であり、すなわちサウスブリッジが ICR9 であり、Etchのカーネルは未対応だ。

 こんなときは http://kmuto.jp/debian/d-i/

 etch-custom-1013.iso をダウンロードして焼いてインストールしたらあっさり入った。

 この ML310 G5 には HP SmartアレイE200/128 BBWC も搭載しているのだが、これは難なく認識された。


 面白いのが iLO2 (Integrated Lights-Out 2) である。これは OSが入っていなくても、リモートから電源のON/OFFなどができる代物なのだが、もうBIOSつーレベルではなく、TCP/IPフル実装のネットワークOS(10年以上前の用語だな)が動いている。

 電源入れなくても、その部分は動いているわけで、待機電力が気になるが、待機している状態が長いわけではないからまあいいのか。

 ML310 G5 には iLO2用のEthernetPortがあり、そこにLANケーブルをさすとDHCPで勝手にIPアドレスを取得し、起動画面に表示される。そのアドレスにWebブラウザでアクセスすると管理画面が表示される!

 感覚としては、家庭用NASの管理画面みたいな雰囲気。FANスピードとかCPU温度とかも表示できて面白い。


 いや、そんなんで遊んでないで、メールサーバの設定とかしなきゃな。

Posted by rukihena at 22:21:32 | Comments [0] | Trackbacks [0]

2007年11月28日

VMAdditionsForLinux.MSI 発見

 Virtual Server 上で Linux を動かすのは可能といえば可能なのだが、Linux を動かすなら VMware の方がイイんじゃないの? と思う。

 その理由のひとつはゲストOSのインストールに妙に時間が掛かること。まじで3時間ぐらいかかる。

 また、ゲスト−ホスト連携(バーチャルマシン追加機能:VMwareでいうところの VMware Tools)入れるのが非常に面倒くさい点もなんかイヤだ。

 まあ、Microsoft で閉じた世界なら Virtual Server を使うのもいいかもね。という結論。


 だが、仕事上、Virtual Server 上に Linux をインストールする必要があった。

 で、

 http://download.microsoft.com/download/6/f/f/6ff609b3-7ffb-4aa7-8c4d-c2b0ed982820/WSW01_VS2005R2.pdf

 を読むと、VMAdditionsForLinux.MSI を入手しろと書いてある。それには Microsoft Connect にサインインして、「Microsoft Virtual Machine Additions for Linux」プログラムに申し込みして・・・ってそんなの無いじゃん!

 と、困ってしまってワンワンワワンなのだが、泣いてばかりいる子猫ちゃん状態で右Altキー(VMwareでいうところのCtrl+Alt)を駆使してGUIをいじっていた。

 そんな中、ふとしたことから

 http://www.microsoft.com/downloads/details.aspx?FamilyId=BF12642F-77DC-4D45-AE4E-E1B05E0A2674を発見。

 VMAdditionsForLinux.MSI でググれないのは、新しいのには32bit版と64bit版があり、ファイル名が変わってしまったからだろうか。

 そんなわけで、VMAdditionsForLinux.MSI でググれるようにSEOを意識しつつ、メモ。


 ちなみにゲストOSのインストール時間が長い問題は、物理CD-ROMドライブへのアクセスに時間が掛かっているのかも。ISOイメージをマウントすると普通の速さで動くっぽい。

Posted by rukihena at 00:32:22 | Comments [0] | Trackbacks [0]

2007年11月22日

Backup Exec 11d のディザスタリカバリで嵌った(その2)

 前回の予告、「DRファイルが必要な話と、Backup Exec の内部状態(タスクとか)を格納する mdb ファイルのバックアップの話があるのだが、それはまた後日。」について書く。

 DRファイルってハードウェア構成とかが格納されていると思っていた。同一ハードウェア構成なら一度作ればOKだと思っていた。

 しかし、「テープのオートローダーのどこのスロットに記録したか」とかもそこに入ってた。

 DRファイルがない状態で、手動で指定するのは非常に面倒だ。テープの場所を手動で設定する必要がある。その場合、テープのオートロードと早送りを待たなければならず、非常に時間が掛かって全然ディザスタじゃねー! と発狂することになる。

 DRファイルは別ファイルサーバとかにも置いておくようにしましょう。


 それと、「Backup Exec の内部状態(タスクとか)を格納する mdb ファイル」の件。

 「現在の状態」はDBオープン中なのでバックアップできない。なので、深夜にそれのバックアップファイルが自動的に作成されるようになっている。ディザスタリカバリした場合、そのバックアップファイルから復元するので、深夜の状態まで戻ることになる。通常運用ではそれで問題ないだろう。

 しかし、導入時にバックアップタスクを一通り設定して、1回バックアップしてリストアしてみようかなとかやるとどうなるか。

 深夜のバックアップが一度も実行されないままなので、リカバリするとタスクが空っぽになってしまう。せっかく月〜金のタスクをちまちま設定したのに〜〜〜〜!!

 バックアップする前に、深夜の保守実行しておきましょう。

 (「今すぐ実行」する方法が見つからなかったので、保守の時間を数分後にして動かした。)


 と、慣れないことをするとイロイロありますね。

Posted by rukihena at 01:32:34 | Comments [0] | Trackbacks [0]

2007年11月14日

The file IdrDisk.sys could not be found.

 symantec のバックアップソフト、Backup Exec 11d のディザスタリカバリで嵌った。

 ディザスタリカバリをしたいPCサーバ上で、CDブートするディスクを作成したのだが、それでブートすると表題のメッセージ「The file IdrDisk.sys could not be found.」が表示されて終わってしまう。

 何故なんだーと悩みまくって、IdrDisk.sys でググったら

 https://forums.symantec.com/syment/board/message?board.id=115&message.id=20459

 が出てきた。

 英語だ。

 解決したんだかしてないんだか一見して分からないのがツライ。読んで未解決だとしたらかなりガッカリだ。最後の人の一文を読むと、シマンテックのサポートと2時間話したようだ。

 これは難題っぽい。


 だが、ちゃんと読んだら簡単だった。

 IDRディスクを作成する際、デフォルトで出てくる C:\WINDOWS を指定したらダメで、OSインスコCDを挿してそのドライブを指定するのが正解。

 それだけ。

 it is fantastic.


 そのほかに、DRファイルが必要な話と、Backup Exec の内部状態(タスクとか)を格納する mdb ファイルのバックアップの話があるのだが、それはまた後日。

Posted by rukihena at 01:50:43 | Comments [2] | Trackbacks [0]

2007年10月12日

サーバープチトラブル

 Nagiosでサーバを監視しているのだが、最近警告メールが多い。

 ping で死活監視をしていて、死んだらメールが来るのだが、それはもう頻繁に死んだよメールが来て心臓に悪いを通り越してなんとも思わなくなった。まさにオオカミ少年の周りの大人状態。危険だ。

 ping のタイムアウトではなく、Host not found なので、DNSのクエリに失敗しているようだ。

 DNSはYAMAHAのルータにやらせており、YAMAHAのルータはプロバイダのDNSを見に行っている。

 どちらが不調なのか、はたまたゾーン情報を持っているレジストラのDNSが不調なのかは分からない。

 なにしろ、「死んだよメール」と「生き返ったよメール」が同時に届くものだからチェックのしようがない。

 とりあえずメールがウザイので、 /etc/resolv.conf に nameserver 行を3行書いて冗長化(?)してみた。これで様子を見ることにする。


 それと、今日の昼間、水道橋にいるときに、蛍光灯が一瞬消えた。ほどなくして、池袋に置いたサーバから、UPSが動いたよメールが来た。それによると、瞬停した時刻は 10/11 13:35:48。多分同時刻と思われる。

 水道橋と池袋だから、そこそこ広域な瞬停だと思いますが、みなさんいかがお過ごしでしたでしょうか?

Posted by rukihena at 00:59:08 | Comments [0] | Trackbacks [0]

2007年4月10日

Debian GNU/Linux 4.0 etch インストール

 とりあえず、VMWare上にインストールしてみた。

 デーモンが全然起動してないのは最近の流行だな。
 net-inst でインストールして、思わず ssh をインストールした状態で、ディスク使用量 430MB(430604KB)。

 今日はここまで。明日以降は・・・放置の予感。

Posted by rukihena at 00:56:52 | Comments [0] | Trackbacks [0]

2007年4月 9日

Debian GNU/Linux 4.0 etch リリースキテター

 ということで、ダウンロード中。

Posted by rukihena at 00:39:40 | Comments [0] | Trackbacks [0]

2007年3月14日

IP8は/29で、255.255.255.248。IP16は/28で255.255.255.240。

 ネットワーク機器をいじっているときに、ネットマスクに何を入れればいいのか迷うことがよくある。

 ということで、自分用にメモ。タイトルの2個が分かれば、ほとんど足りるだろう。

 /24 が 255.255.255.0 なのは言うまでも無い。

 /30 で 255.255.255.252 は、unnumberedじゃない、正統派(古典的)ルータ設定を行う場合に使うかもしれない。


 ちなみに、暗算の方法。

 最後のオクテットの数字は、IPアドレス数を、256から引けば出てくる。IP16なら256-16=240。

 スラッシュの数字は、IPアドレス数を表現できるビット数を、32から引けば出てくる。IP16なら4bitで、32-4=28。

Posted by rukihena at 00:15:37 | Comments [0] | Trackbacks [0]

2007年3月 1日

スパム対策・Spamassassin

 メールサーバに、スパム対策ソフトのSpamassassinをインスコした。

 実はもうずっと前から運用しようと思ってパッケージだけは入っていたのだが、設定が分からず放置状態だった。かれこれ1年ぐらい経っていたかもしれない。まあサーバでスパムフィルタをしなくても、クライアントサイドでフィルタすれば問題ナッシングなので本気で設定する気になれていなかった。

 しかし、状況が変わってきた。

 カイシャのアドレスはあまり汚れていなくて、ケイタイに転送しても問題なかったのだが、最近はSPAMが非常に鬱陶しくなった。カイシャのアドレスをSPAMフィルタしつつケイタイに転送するにはSpamassassinの運用が必須だ! と思い、インスコするにいたった。


 メールサーバはVine Linux 3.2上で動かしている。例によって amavis-new と ClamAV でウィルスフィルタをしている。とりあえず、amavis-new の設定で Spamassassinを使うよう設定したら、メールが届かなくなった。

 どこをどういじればいいんだコラ。

 わけわかめなので、rpm -evh spamassassin でアンインスコしてから、apt-get install spamassassin したら動くようになった。万歳。まるでWindows。


 ルールセットを更新しれくれるシステムの sa-update も動かしてみた。そしたら設定ファイルが反映されない。

 http://www.emaillab.org/spamassassin/docs/plugin-OSC20061028.pdf を見て解決。


 ベイシアンフィルタを動かしてみるが、ヘッダが付加されない。

 これは学習が進んでいないからだった。spam を 1000通とか、ham を100通とか学習させないとヘッダすら付加しない仕様のようだ。

 設定がミスっているか学習不足なのかわからねーのが嫌だな。debugモードとかで動かせば分かるのか? 簡単に分かる方法きぼんぬ。


 SPAMじゃないメールにおいて、ヘッダが付加されない問題もある。scoreが低いとヘッダを付加してくれないのだろうか。その閾値はいくつだ? 必ず付加させる設定は無いのか?もちろん、amavisd.conf では $sa_tag_level_deflt = 0.0 と設定しているぞ!

 あー、これマイナス値も設定可能なんですかね??


 などなど、問題発生したり問題解決したり未解決だったりするが、1日程度運用してみた結果、なかなかいい感じ。

 ケータイ転送プログラムubiqun の設定で X-Spam-Flag: YES があったら転送しないようにしたら、ものすごく快適。

 Becky! の BkASPil をアンインスコ(DLL の拡張子部分をリネーム)し、ヘッダでの振り分けにしたらものすごく快適。今まで BkASPil によるオーバーヘッドは感じていなかったのだが、外したら高速に動いてビックリ。

 Outlook Express 6.0 はヘッダによる振り分けに対応しておらず、ガッカリ。Subject を書き換えちゃうのが常套手段のようだが、なんかそれは嫌だ。

 もうちょっと運用してから、scoreが高すぎのメールはサーバできれいサッパリ捨ててしまう設定をしてみようかと思う。

Posted by rukihena at 23:48:52 | Comments [2] | Trackbacks [0]

2007年1月20日

鯖移転作業失敗

 仕事で鯖移転して、さて設定! と思ったら、移転先のOCNの開通通知書が行方不明。

 戻るにも鍵が無い。

 担当者は中国出張で電話できねー。

 どうするオレ。

 旧契約はベーシックタイプで、新契約はマンションタイプなので、旧契約を流用できねー。

 と悩んでいるところで、同じサーバー室に引いてある協力会社さんの回線がベーシックタイプであることに気づいた。

 ONUにはVoIPアダプタ&ルータ内蔵機器っぽいモノがぶら下がっており、今時のモノはPPPoEパススルーがデフォルトでONかも?

 つなげたら旧契約で繋がっちゃうかも?

 で、勝手に接続したらアッサリ繋がった。協力会社様との関係とか回線ダウンの影響とか考えたら、まあ、それもアリでしょう。


 中国専用線の移転も同時に行う。

 開通確認するみかかcomの担当者が早く帰りたい様子で、30分おきに電話してきやがる。電話している時間の分だけ帰る時間が遅くなることに気づいていないのだろうか。最後には切れて「しつこいですよ」とか逝ってしまった。


 専用線の機器は「アラートがなるから電源を切るときはシールに書かれている電話番号に電話してネ」と言われているが、アラートが来たためしがない。太い電源ケーブルに3P-2P変換をつけて抜け落ちやすくなっており、抜けたことが3回ぐらいあるのだが、真っ先にアラートを投げるのは利用者である。そしてみかかcomからのアラートは受けたことが無い。

 試しに、移転元の機器の電源を抜いて放置してみた。

 電源を抜いたのがおよそ17時。そしたら翌03:28にアラートの電話が来た。経過時間10時間以上。

 氏ね。

 しかも、移転元と移転先のどちらでアラートが出ているか聞いたら、「わかりません」「確認して折り返す」と。

 折り返しは 04:05 に来た。経過時間37分。

 氏ね。

 試すんじゃなかった orz

Posted by rukihena at 04:22:45 | Comments [0] | Trackbacks [0]

2006年9月11日

雷で停電

 早朝の雷で停電しやがった。

 自宅鯖やハードディスクレコーダなどにUPSを接続して準備OKだったので、期待の停電でもあった。

 UPSを用意して以来、ブレーカーが飛んだことはあったが、ちゃんとした停電は初めてだ。

 それで気づいたのだが、マンションのMDFにあるVDSL集合装置はUPSで保護されていない。自宅のVDSLモデム・ルータ・HUBをUPSに繋いでいるのだが、そんな努力は無駄だったのだ。

 まあ、ブレーカー対策ということで、そのまま接続していますが。


 自宅鯖はレアケースだと思うのでまあいいのだが、需要の多いIP電話が問題だ。VDSLにIP電話を乗っけていると、停電時に電話できないことになる。もともと停電時は電話できない仕様なのだが、宅内設備をUPSで保護したとしても無理と。

 宅内まで光ファイバが来ている場合は、宅内で努力すれば、停電時通話が可能と思われる。その点では、Bフレッツ マンションタイプ/ビルタイプ 光配線方式は有利だ。

 光スプリッタって電源不要なんですヨ。

Posted by rukihena at 23:09:12 | Comments [0] | Trackbacks [0]

2006年9月 1日

VALUE DOMAIN


 ボクがよく利用しているレジストラVALUE DOMAINで、期間限定割引を行っている。

 通常でも、990円/年と激安なのだが、期間限定で790円/年と、超お買い得。さらに、.netなら690円/年! .infoの新規登録なら390円/年!

 12月31日までの期間限定なので、期限切れがまだ先の方も、この機会に移管しておくとお得です。

Posted by rukihena at 23:09:04 | Comments [0] | Trackbacks [0]

2006年8月18日

Namazu以降の全文検索エンジン

 Webサイトに検索エンジンを組み込むとしたら、まずNamazuが思い浮かぶことであろう。しかし、最近はもっと高性能の検索エンジンが出来ている。

 Namazuは分かち書きに、既存の形態素解析エンジンを用いている。これだと、新語や固有名詞に弱く、検索漏れの恐れがある。

 イマドキの全文検索は、N-gram方式が主流のようだ。インデックスのサイズはでかくなるが、検索漏れは無くなる。

 イマドキの全文検索エンジンを評価してみた。

Freya-SX
 特徴は、DeleGateの作者が開発しているという点である。DeleGateの特徴そのまま。ゴテゴテと機能追加を重ねて多機能。多機能だがドキュメントが少ない。MLアーカイブを全部読めってことですか??

Rast
 Software Design誌 2006年2月号 で知った。特徴はよくわからない。強いて言えばインデックス登録が遅いと自覚しているところか。

Senna
 未来検索ブラジルが作っている。たぶん、2ちゃんねる検索を作るために作ったのだろう。
 個人的には設計方針が気に入った。とくに、「ACID特性の実現は高コスト→未コミット読み取りは許容」とか。
 しかし、まだ新しすぎて手を出しにくい。
 それと、検索コアに力を入れすぎで、周辺ツールが整っていない。NamazuのようにWebサーバーの検索ページを作るには、APIを使って作りこみが必要。

Hyper Estraier
 これらのなかで、おそらくたぶんきっと、一番マトモと思う。
 開発メモを読むと、ドキュメントカンパニーの社員ですか? いや、最近は大手SNSの中の人になっちゃってますね。


 ・・・全然評価になってないな。

 いろいろ読んで、Hyper Estraier ラブになったので、コレの検索に H.E. を利用しようかと思っている。

Posted by rukihena at 23:08:19

2006年8月17日

sshのセッションが切れる件

 sshとかtelnetで作業しつつアイドルのままほっとくと、いつの間にかに切れてしまうことがある。これは通信路の間にあるルータのNATテーブルのタイムアウトによるものと思われる。

 ある人はPCがルータ直結なのに切れると言って困っていた。サーバー側は静的NATである。静的NATの場合、NATテーブルは不要なはずだ。しかしSPIフィルタがある場合は切れるかもしれない。

 まあ、とにかく、TCP通信は未通信時間が長いと、間のルータに切られてしまうことがある。


 イマドキの対策として、一番カンタンなのは keep alive をONにすることである。UTF-8 TeraTerm Pro with TTSSH2では、デフォルトでONになっている。PuTTYではOFFなので、自分でONにしなければならない。いじるのは Enable TCP keepalives のところではなく、Seconds between keepalives のところに数字を入れる。300(5分)ぐらいでいいと思う。

 そのほか、NAT環境で放置したSSH接続が切れる問題への対処という文章がある。


 もっと上位層での対策として、screenコマンドを使うという人がいた。screenは仮想端末管理ソフトであり、切れる対策専用というわけではないが、切れても仮想端末に再接続できる機能がある。その他、いろいろ嬉しい機能があるので愛用しているとのこと。

 自分は使ってないのでよくわからんが、screenのススメなどを読むと良いかも。


 ちなみにボクは切れて困っていたのだが、なんら対策をしていなかった。切れたらログインしなおすし。でも、最近なぜか切れないなぁと思っていたら、最近乗り換えたTTSSH2で、デフォルトでONになっていた。

Posted by rukihena at 23:08:19 | Comments [0] | Trackbacks [0]

2006年7月27日

MovableTypeバージョンアップ

 Movable Typeのバージョンアップと移転とMySQLのダウングレードを同時に行った。

 今まではカイシャの鯖に突っ込んでいたのだが、自宅鯖に移転した。CentOS4.3からDebian3.1にしたため、パッケージ管理されたMySQLのバージョンが 4.1から4.0にダウングレードすることになった。

 日本語を使う場合、MySQLの4.1は鬼門である。自動変換が変に働いて文字化けに苦しめられることになる。

 そんな事情を今まで知らずに、4.1でなんとなく動いていた。動いてはいるが、phpmyadmin で見ると化け化けだった。でも使えているので気にしていなかった。

 しかし、移転するときにハマった。phpmyadmin でエクスポートしたファイルが化け化けでどーしようもない。

 バイナリダンプしてみたところ、UTF8のコードをさらにUTF8でエンコードしているっぽい。UTFの複数バイトになった各バイトを、0x80以降の8bit値としてエンコードしやがっている。

 しょうがないので PHP のコマンドライン版でコンバートプログラムを書いた。しかし、半角カナが化けたり、} が化けたり、どうにもうまく行かない。

 PHPの関数に頼らず、Cで UTF-8の変換をチマチマやるコードを書いたが、やはり半角カナとか } で引っかかる。} でハマる現象は初めて経験した。UTF-8では鬼門文字なのだろうか。

 さまざまな変換コードを書いたが、最終的には、mysqldump コマンドの引数に --default-character-set=binary を付けたら文字化けせずにエクスポートできた。マニュアルちゃんと読んだけど --default-character-set オプションの説明はなかったぞ! トンだ回り道させられたよ。

 --default-character-set オプションに気づいたのは Software Design 誌を読み返したときだった。ありがとう、SoftwareDesign.

Posted by rukihena at 23:07:28 | Comments [0] | Trackbacks [0]

2006年7月12日

VMWare Server キタ

 VMWare Server が無料になって久しいですが、今までは正式版じゃなく、ベータの扱いだった。(最近はRC)。

 正式版になるのを待ってたのだが、昨日、我慢できなくてRC2を入れた。

 そしたら今日になって正式版が出ているではないですか!

 まあ、多分アップデートインストールしても大丈夫だとは思うけど、なんかレジストリが汚れそうな気がしていやだなぁ。

 あ、でも昨日 KNOPPIX で起動して、dd コマンドで C: ドライブのバックアップを作ったばっかりだった。

Posted by rukihena at 22:40:56 | Comments [0] | Trackbacks [0]

2006年7月11日

PXEブートでKNOPPIX

 ネットワークブートって結構昔からあるんだけれども、使い勝手の良いモノはあまりなかった。どんな機種でもブートできるようにしようと考えると、デバイスドライバを大量に用意しなければならず、面倒くさい。

 大学のコンピュータールームみたいな、同機種がいっぱい、かつ、センター長が環境整備ヲタというところでしか実用にならないような。


 しかし、最近は、デバイスドライバ・デバイス自動認識方面はKNOPPIXで実績がある。PXEブート用のちょろっとした仕組みを用意すれば、カンタンにネットワークブートできるんじゃないの? と思った。

 で、調べてみたら、KNOPPIX Terminal Server というものがあった。しかし、これはサーバとなるマシンで、CDブートしなければならない。それはそれで手軽で良いんだけれども、マシンを1台占有するわけで、なんだかモッタイナイ。既存のLinuxマシンにサーバを展開できないかなぁと思った。

 面倒くせーから、VMWareでも入れて、サーバを起動しましょうかね。

Posted by rukihena at 22:39:24 | Comments [0] | Trackbacks [0]

2006年6月30日

SSH辞書攻撃

 LogWatchでログを監視していると、ssh で辞書攻撃された痕跡が目に付く。目に付きすぎて邪魔なので、Invalid user(システムに存在しないユーザーでログインしようとした)は報告しないようにスクリプトを変更してしまった。これでかなりの行数が減る。

 しかし、今日はエラーの行数が多かった。良く見ると見覚えのあるアカウント。つーか、システムにあるアカウントを調べて攻撃してないかコレ!? /etc/shadow は無事だけど /etc/passwd が漏れたか!? ピーンチ!!! と冷や汗が出た。

 ログを精査しなければ!

 そしたら、単に日本でありそうなアカウント名で辞書攻撃されているだけだった。LogWatchを改造していたから、システムに存在しないユーザーは報告せず、存在するユーザーだけ"Failed password"で報告されていた。

 ホッと一安心。

 ついでなので、利用された辞書をログから再現してみた。コチラ。801件。

 悪用厳禁でおながいしまつ。

Posted by rukihena at 23:45:50 | Comments [2] | Trackbacks [0]

2006年6月27日

TIME_WAIT タイムアウト

 某所で、「たまにネットに繋がらなくなる」という現象が起きていた。しかし、チョト経つと自然復旧する。

 結論としては、NAPTセッション数が足りなかった。

 ここでは マイクロ総研のNetGenesis SuperOPT90 を利用している。

 最初の調査では、OPT90のログを見ても何も異常はなかった。しかし、SYSLOGのオプションを全部ONにしたところ、"IP Masquerade session table full"が表示された。

 解決策としては、コチラをみて、セッション情報保持時間を減らしてみた。最初、2分30秒にしてみたら現象の発生頻度が下がった。思い切って1分にしてみたら現象が出なくなった。

 しかし、3分とか1分とかって短いよな。たとえばTELNETとかSSHとかしていて、1分で切られると面倒くさい。ログインしなおさなきゃならないは、サーバー側のプロセスが残っているはで面倒。

 自宅の Aterm WB7000H は「NAT タイマ(秒)」という項目があり、デフォルト値は3600秒だ。

 差がありすぎる。何故だ?


 TCPの切断処理は、切断したい側がFINを投げて、ACKを貰う。ACKを投げたほうもFINを投げて、ACKを貰う。このとき、最後のACKを投げた側(=切断したい側)は、TIME_WAIT状態になる。

 コチラの状態遷移図を見ると分かりやすいかもしれない。

 TIME_WAIT状態は何を待っているのかというと、相手がACKを受け取れなくて、もう一度FINを投げてくることがあるからなんだそうな。

 NAPTルータの立場からすると、クライアントがTIME_WAIT状態の場合も、NAPTセッションテーブルは維持しなければならない。NAPTセッションテーブルを破棄するのはTIME_WAITと同じタイムアウト時間後だ。だがこれは明確な秒数が決まっておらず、実装依存である。一般的には30〜120秒らしい。


 このTCPの状態遷移を考えると、NAPTセッションテーブルのタイムアウト値は、2種類必要のような気がする。FIN後のTIME_WAIT状態のタイムアウトと、ESTABLISHED状態での無通信タイムアウトの2種類。

 OPT90で設定する値は、もしかしするとTIME_WAITのタイムアウト値なのだろうか。いや、両方とも同じ値で管理しているのかな? ナゾだ。


 ところで、タイムアウト値のチューニングって面倒くさいから、テーブルから一番古いのを追い出して使えばいいんじゃねぇの? とか思った。さらに、HTTPはキープアライブで無駄なセッション使ってそうだから積極的に切っちゃえとか、TELNET/SSHだけは切らずに温存とか、いろいろ妄想が広がっていく。


 最初に戻るが、問題が起こった某所は、人が10人も居ない程度の事務所である。そこで2048セッションを使い切ってしまうというのは中で何をやっているのだろうか? 3分間に2048セッションということは1秒間に11セッションぐらい消費している計算になる。「人力でネットサーフィン」では到底無理なアクセス数だ。

 今度、パケットキャプチャしてみようかと思っている。

Posted by rukihena at 23:45:23 | Comments [0] | Trackbacks [0]

2006年6月21日

1秒間に5億回

 昨日、2chがダウンしていた。

 ITmedia によると、外部から「1秒間に5億回」という猛烈なアクセスに見舞われ、たんだそうな。これを読んだ瞬間、違和感を覚えた。

 1アクセスが仮に1ビットだとしても、5億回というと500Mbpsになってしまう。現実的に、イーサネットの最小パケットである64バイトで計算すると、0.5*64*8=256Gbps になってしまう。

 そもそも、それだけのパケットを送出することが可能だろうか? いや、DDoS攻撃なので、合計256Gbpsにするのは可能だろう。1Mbpsを256000台で送出すれば可能。

 だがその総数をデーターセンターで検知できるのだろうか?

 データセンタの外側のルータでパケットロスを起こしてしまい、データセンタ内ではルータの性能の上限のパケット数しか観測できないはずだ。

 横のつながりで大調査したのだろうか?

Posted by rukihena at 23:39:42 | Comments [0] | Trackbacks [0]

2006年6月18日

中国にメールが届かない

 中国のインターネットは特殊だ。国家によるフィルタリングシステムがあり、ひょんなことで通信が切れてしまう。「ひょんなこと」にはアダルトも含まれるが、中国国家批判のほうが規制が強いらしい。なんて書いてしまったので、このブログも中国からは読めなくなっているものと思われる。

 日本では、ぷららがWinnyを全面規制しようとしたら総務省に怒られた。通信の秘密の原則があるからだ。日本と中国の、インターネットに対する対応は、非常に対称的だ。

 で、しょっちゅう切れてしまうので、メールが実用にならない。UUCP時代と違って、今はメールは瞬時に届くものと思われている。それが3日後にエラーで返ってきても意味が無い。せいぜい1時間以内にエラーで返ってこないと、次のアクションが取れずにビジネスが停滞する。

 良く中国にメールを送ることがある某メールサーバは3日に設定されていた。これはDebianにpostfixを入れたときのデフォルトである。postfix自身のデフォルト値は5日である。いずれにしても悠長すぎる。

 再送信間隔はインターネットの思想と同じく、指数関数的に伸ばしつつ再送信する。最初1000secで、4000secまで伸ばす。これも悠長だよな。

 つーことで、5分おきに再送。1時間であきらめて、エラーメールを返すよう設定した。具体的には、main.cf に以下の行を追加する。

minimal_backoff_time = 5m
maximal_backoff_time = 5m
maximal_queue_lifetime = 1h
queue_run_delay = 5m

notify_classes=resource, software, delay
delay_warning_time = 30m

 最初の4行だけで良いと思う。queue_run_delay はキューを調べる間隔なので、minimal_backoff_time と同じに設定するものだと思う。

 最後の2行は、管理者に警告を出すための設定である。最初、notify_classes に bounce を入れていたのだが、大量にくるSPAMのbounceが全て報告されてウザイので消した。そのかわり、「送れないメールがキューにあるよ」ってのを報告させるようにした。

 対中ビジネスをしていなくても、メールが1時間届かないのは異常事態だろう。メールサーバを自分で管理しているところでは設定しておくことをオススメする。

Posted by rukihena at 23:39:59 | Comments [0] | Trackbacks [0]

2006年6月15日

DELL PowerEdge SC430キタ

 とりあえず Vistaβ2を入れてみる。64bit版を入れたらメモリ使用量が素の状態で580MBぐらいになってひどい有様。32bit版なら430MBぐらい。512MBのメモリでもなんとか使える。でも余裕がない。

 とりあえず、ゲームをやってみた。マインスイーパーとかソリティアとかフリーセルとかが無駄に3D(?)になっていた。オンボードグラフィックだとゲームにならん。

 ーーーVista体験終了ーーー

 Debian Sarge をインスコしてみる。

 SATAドライブが認識されない。そうだ、boot: プロンプトで linux26 だっけか。いや、それでもダメ。SC430搭載のE7230チップセット(ICH7)は非対応! ぐは!!

 ICH7のSATAは2.6.12以降で対応されているのだが、Sargeのカーネルは2.6.8なのでインスコできない。そんなときはムトゥ神d-i imageを使うと良いらしい。

 しかし! インスコされたカーネルはSMP非対応! PenDの意味無し! カンニングの竹山状態!(← 相方が動いてない)

 さて、今後どう活用しようか・・・。

Posted by rukihena at 23:34:55 | Comments [0] | Trackbacks [0]

2006年5月13日

DOS窓で動くエンタープライズアプリケーション

 Write Ones, Run Anywhere を信じる若かったあの頃。Weblogicを使用した某システム構築に当たり、開発だけWindows上でやって、運用はLinux上でやろうと思っていた。

 で、作ってLinux上で動かそうとしたらちゃんと動かねー。なんか文字化けしてるし、他にも変な挙動するし。

 どうするよ? えーい、面倒くせー Windowsで動かしちゃえー! デバッグに掛かる工数よりWindowsのライセンス料の方が安いぜ!!

 しかし、Windowsのサービスで動かす方法が分からない。一応、方法は用意してあるのだが、古いJREでしか動作保証されていない。それって新しいJDKで開発しちゃったらコンソールで動かせってコトですか!? いまさら新しいクラスを外すなんて出来ませんヨ!!

 つーことで、当初の予定は大幅に変更して、Windowsにログインして起動するというダサいシステムになってしまった。

 しかし、起動の度にログインするのは面倒だ。Windows2000Serverを使っているので、自動ログインできない。ぬぉぉぉ面倒すぎ! ナントカしなければ!! と思ってチョコチョコ調べていたら窓の手で自動ログインの設定が出来ることに気づいて解決。Javaの起動はもちろんスタートアップに登録。

 これで、OS再起動しても勝手に動いてくれるシステムになった。


 某所でも似たようなシステムがあり、窓の手で(正確にはレジストリをいじって)自動ログインさせたいのだが、客が「セキュリティーポリシー上、あかん」というので、手動ログイン→手動起動のまま放置されているものもある。

 放置という言葉は良くないかもしれない。「起動手順書」をちゃんと作ってIDCに提出しており、何かあったときはIDCにお願いして起動手順書を実行してもらうという素晴しいソリューションになっている。

Posted by rukihena at 23:55:43 | Comments [0] | Trackbacks [0]

2006年5月 7日

dd conv=sync,noerror

 定期的にやってくるサーバダウン。

 HDDがたまにエラーを出しているのにもかかわらず放置していたボクが悪かった。

 しかし、HDDだけでなく、本体もイカレていた。たまたま似たスペックのPCがあったので助かった。

 不良セクタ満載のHDDは適当なPCに繋いで knoppix を起動して、

 dd if=/dev/hda of=~/backup bs=4096 conv=sync,noerror

 でバックアップした。conv=sync,noerror は、不良セクタがあるHDDをバックアップするときのおまじないである。noerror はエラーがあっても継続。sync はエラーの分を0パディングする。これをつけないとデータがずれて大変なことになる。

 ブロックサイズ(bs)に指定する値は、512(セクタサイズ)が理想だが、速度を考慮すると大き目がいい。しかし、不良セクタがあった場合にブロックサイズ分が全部消える(と思う)ので、大きすぎは良くない。ここでは、ファイルシステムのクラスタサイズに合わせた。

 あーと、これをやる前に hdparm でDMAを有効にするのを忘れないようにしたい。速度が数倍速くなる。

 その後、移転先HDDに乗せ換えて

 dd if=~/backup of=/dev/hda bs=8225280

 でリストア。ここでのブロックサイズは、fdisk とかで見たときの Units = cylinders of 16065 * 512 = 8225280 bytes を指定した。この値は多分きっと全容量の約数になっているはず。

Posted by rukihena at 23:50:45 | Comments [2] | Trackbacks [0]

2006年4月 5日

PacketIX→OpenVPN

 深夜0時、VPNが死んだ。調べてみたら、PacketIX(旧Softether)のライセンスが切れてた。

 もうFreeライセンスは取得できないので、別の手段でどうにかしなければならない。今すぐどうにかしなければならない。深夜だというのに。

 多くのユーザーは OpenVPN に乗り換え始めているようである。

 いままで、PacketIX ではブリッジを使っていた。ブリッジの方が管理が楽だからだ。しかし、欠点もある。

 ひとつ思ったのはルータの送受信LEDの点滅がウザいことである。ブロードキャストを全部転送するので、非常に目障りな点滅を続けている。ウルセー黙ってろハゲと常々思っていた。それと、Windowsのネットワークコンピューターで、なぜかワークグループが表示できない。ブリッジの向こうにあるSAMBAサーバーがなんか邪魔してんじゃないかなぁと思いつつ、\\192.168.0.3 とかやってしのいでいた。しかし、Susie でサムネイル表示させたときに、左のツリーで表示が失敗してエラーメッセージが出たりしてウザかった。ドライブレターをつければ問題が回避できるので、それでなんとかしていた。

 そんなわけでブリッジはやめて、ブロードキャストドメインを分離した。そのためには家庭内LANのネットワークアドレスの変更が必要になる。

 ルータの設定を変更して、固定で設定している機器のアドレスを変更して終わり。ではなく、プリンタの指定とかポートマッピングの設定とかこまごました設定がいろいろあった。面倒だな。面倒だから今までブリッジのまま運用していたわけだが。

 IPアドレスの変更を終えてから、OpenVPNでLAN間接続する例をググリはじめた。しかし少ない。つーか見つからない。接続形態の絵を書いてくれよみんな! とも思った。文字での解説もなしにいきなり設定方法が書いてあったりする。ぬぉームダだ!

 って、この文章も多分ムダなんですがね。

Posted by rukihena at 23:24:30 | Comments [1] | Trackbacks [0]

2006年3月22日

APOPとかSMTP-AUTHとかSAMBAとかのパスワード暗号化

 POPとかSMTP-AUTHとかSAMBAとかのパスワードを暗号化しようと思うと、それぞれのパスワード保存方法(一方向ハッシュ関数)が違うために、それぞれのプロトコル用のパスワードファイルを生成しなければならない。それには生のパスワードが必要になる。自宅鯖程度なら、ユーザーの皆さんに再設定してもらえばよいかもしれないが、ちょっと中規模になると面倒くさくてやってられなくて放置ってことになってしまう。

 無理やりパスワードを再発行して、「今後はコレ使え」という方法もアリかもしれないが、スマートではない。

 なんとかならんものか。

 暗号化する理由は、盗聴に弱いからであり、盗聴しちゃえば生のパスワードが得られるのではないか。そう考えた。

 幸いなことに(?)、盗聴ツールは数多く存在する。しかし、さらっと探したらWindows対応の物しか見つからなかった。すなわち別マシンで盗聴するわけで、そのためにはバカHUBを間に入れるとか、ARP Spoofing(ARP Poisoning) するとか、どうにもスマートじゃないような感じのことをしなければならない。サーバ上で、(Linux上で)動くやつの方がいいよなぁ。

 だれか作ってねーのかよ。と思いながら、英語もググッて探したのが、krippというツール。

 Can sniff and display ICQ, AIM TOC, FTP, HTTP, CVS and POP3 passwords. ということである。perlで書かれたスクリプトで、tcpdumpを呼び出して出てきた結果からパースしてパスワードを取り出すらしい。

#./kripp > password_log.txt &

 って感じで起動して2〜3日放置すれば、パスワードがゲットできるだろう。

 ただ、なんか作りこみが甘い。krippをkillするとtcpdumpのプロセスが残ってしまう。プロトコル毎に起動するので7個ぐらい残ってしまう。後始末が微妙に面倒。それとリダイレクトがバッファリングされているらしく、バッファ単位から余った最後の数kBytesが保存できない。

 まあ、致命的なバグ(仕様?)ではないので、これを使おう。他を探すの面倒だし。

Posted by rukihena at 23:20:57 | Comments [0] | Trackbacks [0]

2006年3月 8日

ネットワーク管理者必携

 前のカイシャでは、向かい合った机と机の間に隙間があった。その隙間にはケーブルが無造作に這っており、また、奥行きの長いCRTを最適位置に設置するための空間となっていた。

 その隙間にモノを落とすとタイヘンである。抜いたケーブルやら、文房具やら、CRTの上に飾ってあるボトルキャップやらがその空間に吸い込まれていく。そんな事態になると、CRTをよけて入っていくか、身を乗り出して手を伸ばしてなんとかするか、どちらにしてもタイヘンな状況になる。

 そんなタイヘンな状況で、ニヤニヤしながらカラフルなオモチャを差し出す先輩がいた。

便利?かも。カラフルアイアンハンド

 !!!!!!

 無茶苦茶実用的だ!!!!!

 実用性の無いおもちゃだと思っていたが、利用シーンによってはこんなにも便利なものだったとは!!


 さらに、下記のブツは実用度が増している。価格は殆ど同じで、全長が長い。上のは実測で63cmぐらいである。下のは85cm。

これは便利!【超軽量・マジックハンド】高い所やベッドサイドの小物も楽々キャッチ!

 一般的な机の高さは70cmなので、できればそれより長いほうが良いかもしれない。しかし、肘から手までの長さを足せば、上のヤツでも十分だろう。

 「ウケ狙い」の意図も含めるのなら、上のヤツがいいかな。

Posted by rukihena at 23:10:20 | Comments [1] | Trackbacks [0]

2006年3月 7日

DNSセカンダリ

 DNSを自前で運用しようと思うとセカンダリの設置に悩む。

 ボクの場合、IP8な固定IPを使っているので、そこに2台立てていた。しかし、RFC的には、別の Class C に分けて立てなければならないらしい。

 というのは、DNS reportで調べて、ワーニングが出たことで知った。

 まあ、ワーニングなのでほっといても動くのだが、やはりワーニングが出ている状況はキモチ悪い。なのでどうにかしようと思った。


 以前、無料のセカンダリとしてZoneEditを使っていたことがあった。しかし、無料で管理できるドメイン数が5個までである。アカウントを複数とればいくらでも管理できそうな気はするが、管理が面倒くさい。

 ドメイン数の制限が無い無料DNSを探したところ、XNameを見つけた。ちょっと使ってみたが、管理画面の動作がモッサリしている。

 よくよく考えたら、ボクが使っているレジストラである VALUE-DOMAIN.COMは無料のDNSサーバをサービスしてくれている。多分、以前から知っていたのだが、「自前主義」が頭から離れなくて、使っていなかったんだと思う。(セカンダリだけ VALUE-DOMAIN.COM に頼もうとしても、そういう運用は出来ず、預けるならマスタも全部預けなければならない。)

 また、今更ながら、ゾーンサーバとキャッシュサーバを分離しようとも考えていたので、全部 VALUE-DOMAIN.COM にやらせることにした。

 そしたら管理画面もサクサク動いて快適。

 それと、DNSサーバは閲覧者に近い場所にあったほうがいい。海外のDNSを使うと、名前解決に時間がかかってしまう。さらにDDNSを運用しようと思うとTTLを短くする必要があるため、名前解決の頻度が上がる。そういったことも考えると、国内のサービスを使ったほうが有利だと思う。

 DDNSも使えるので、何かに使ってみようと思う。使い道がまだ思いつかないのだが・・・。


 国内レジストラで老舗のお名前.comは、高いうえに無料DNSサーバサービスが無い。さすが老舗である。

Posted by rukihena at 23:09:48 | Comments [0] | Trackbacks [0]

2006年3月 3日

マシントラブル

 RAID1(ミラー)の1台が死んだ。

 /proc/mdstat の内容を毎日メールで送っているので、それで気づいた。これが無ければ2台とも死ぬまで気づかなかったかもしれない。

 ソフトウェアRAIDの復旧は面倒だよなぁ。実戦も練習もしたことないし。

 いっそ、再インストールしたいよな。RedHat 8.0 だし。

 そういや、apt-get update/apt-get upgrade しても、新しいパッケージが来ないよなぁと思ってよくよく調べてみると、RedHat 8.0 のアップデートパッケージはリリースされていない。つまり、セキュリティホールがあってもそのまま放置される。つまり、非常に危険だ。

 RedHat社からのパッチはないけど、The Fedora Legacy Projectのパッチがあると思っていた。しかし、これもとっくに終了していた。

 やべえ、1年以上パッチ当たってないんじゃないの?

 つーことで、chkrootkitを走らせて見た。LKM trojans が発見された orz

 あーもーディスク2台とも壊れたことにしてしまえ!

Posted by rukihena at 23:57:58 | Comments [0] | Trackbacks [0]

2006年2月21日

UPS

 先日の自宅のブレーカー作動事件により、UPSが欲しくなった。しかし、40A契約による月額273円アップと、3年持てばラッキーと思われる1万円のUPSを比べると、ほぼ同額。悩む。

 一方、実家鯖にはUPSを接続している。

 モノは APC の Smart-UPS 3000RM (SU3000RMJ3U) である。泣く子もだまるラックマウント。運動不足エンジニアの腰をぶっ壊す重厚長大デバイス。なぜそんなブツを持っているのかというと、某社の「お片づけ」の手伝いをしたからだ。

 3000RM は 30Aの専用コンセントに接続しなければならないらしいが、それを 15A の回路に繋げている。でも、問題が発生したことはない。UPSにぶら下げた機器が消費しなければ問題ないだろう。充電電流もたいしたこたーない。スペック上、最大消費電力が230Wと書いてあるので、きっとそれが充電電力なのだろう。高々2.3Aである。仮に力率が50%で、さらに安全率を掛けたとしても、15Aにぶら下げることに危険はない。15A以上使ってたら安全装置であるブレーカーが落ちるハズだし。

 その他に、APCの小型のUPSもある。こっちはONUの為だけに使っている。ONUは室内レイアウト上、サーバ群と離れてしまうからだ。光ファーバーをのた打ち回らせてONUを近づけるのは断線リスクを高めそうな悪寒がするし、電源コードをONUまで引っ張るのも美しくない。ってゆーか面倒。ってゆーかUPS余ってるから使っちゃえ。ということで使っている。


 このUPS、自宅で使おうかな、と思った。

 美しくないけど、電源コードを買ってきて、デッカイUPSからONUに配線するだけで、チッチャイUPSは開放される。

 電源コードよりも、変なところに転がっているチッチャイUPSの方が美しくないという話もある。


 ちなみに自宅の自室にも、自費購入したUPSがあり、どっかのパソコンに繋がっているはずだが、どこにどう繋げたか忘れてしまった。机の裏にあるので調べるのが面倒くさい。ルータと電話には繋がっているようであるが、ONUには繋がっていないという全く意味のない接続である。

 ・・・ 実家をいじる前に、自室のUPSをリビングのHDDレコに繋いでしまおうか。と、書きながら思った。

 自室のは薄型なのでリビングのラックに置きやすいかも。で、後日、実家のモッサイUPSを持ってきて自室に置こう。

Posted by rukihena at 23:59:59 | Comments [0] | Trackbacks [0]

2006年2月 9日

Debian 3.1 sarge インストール

 このブログを以前のサーバに引っ越してみたら、再構築が絶望的に遅かった。

 絶望的なので新しいサーバを作ることにした。

 ディスククラッシュしたPCと、1ヶ月に3回ぐらい勝手にリブートしてしまうPCが転がっていたので、ニコイチにした。

 ニコイチだと信頼性が劣るが、MEMTEST86 と、Drive Fitness Test でテストしまくってエラーが出ないので信頼することにした。

 ちなみに3枚あったメモリのうちの1枚が、MEMTEST86でエラーを出したのでリストラした。


 OSを何にするか悩んだ。

 FreeBSD は以前インストールして、「2度と使わねー」と思った。パッケージはバイナリではなく、パッケージインストールの度にコンパイルが走る。コンパイル至上主義である。思想が10年前である。

 以前のサーバは Vine を使っていた。Vineは恐ろしく保守的である。いまだに apache 1.3 って。それと、ロードマップをみて、なんとなく不安になった。

 実験的に CentOS (Red Hat Enterprise Linux 互換OS)を使っているサーバもある。これは MySQL と phpMyAdmin で EUC を使う設定がいまだに分からなくて文字化けしたまま放置している。アプリからは EUC で読み書きできているので問題ないのだが、新規でインストールする気にはなれない。

 Fedora Core はアップグレードの早さで有名で、サーバには向かない。

 Debian は昔使っていた。bo とか表示されていたような気がするので、1.3 だったのだろうか。その時代は dselect が前面に出ていた。それが面倒で使わなくなった。その後も気にはしていたのだが、リリースの間隔が長くて使う気になれずにいた。

 他にメジャーなディストリビューションを知らない。メジャーでなければ将来性が無いので選択肢に入らない。

 いろいろ悩んだ結果、Debian も今では dselect の呪縛から逃れて使いやすくなっているかな? と思って Debian 3.1 sargeを入れてみた。


 インストールは bo とかの時代に比べたら恐ろしく簡単になった。フツーにインストールできた。日本語の設定もいつのまにかに行われていた。

 TeraTerm+TTSSHでログインできなかった。version 1 を受け付けないようだ。適当にいじって解決した。

 vi で日本語が文字化けしたが、vim をインストールすることで解決した。パッケージのインストールは aptitude install packagename 一発で終了する。

 MySQL も phpMyAdmin も aptitude でラクラク入った。日本語もフツーに表示されている。

 RedHat系とは違う管理コマンドに戸惑うことが多いが、Debian GNU/Linux スレッドテンプレなどを見ながらいじればなんとかなりそうな感じ。

 Movabletype の移行も済んで、Webサーバだけは稼動可能な状態になった。あとはログ解析とかトラフィック監視とかを既存のにまとめるとかこまごました作業が残っている。「マシンを実家に置きに行く」という重要な作業もあるな・・・。

Posted by rukihena at 23:21:50 | Comments [2] | Trackbacks [0]

2006年1月 3日

神田明神で初詣してIT情報安全守護ゲット

 初詣は田無神社にするか、東伏見稲荷神社にするか悩んだりせず、神田明神に行った。

 もう3年ぐらい前から神田明神IT情報安全守護を買いたいと思っていた。秋葉に行ったついでに、と思いつつ3年が過ぎていた。やはり「ついで」ではダメだ。目的意識を持って行かなければダメだ。

 ということで神田明神に行って「サーバが落ちませんように」とお願いしてから、IT情報安全守護(800円)をゲット。

 ついでに、しごとのおまもり(1000円)もゲット。これは名刺入れになっている。プラスチック製で厚いので、アルミ製のモノよりもスペース効率が悪いような気がするが、まあいいや。


神田明神の境内から見る秋葉原再開発ビル↓


 しかし、3日だというのに混雑している。周辺道路は路駐だらけで大渋滞。ボクも右へ倣えしようと思いつつも、最初に空いているスペースを発見した場所がTimesの駐車場で、10分100円だけどそこに停めた。400円かかった。

 秋葉原もなんだか混んでいる様子だった。プチバブルなんですかね。

Posted by rukihena at 23:40:21 | Comments [0] | Trackbacks [0]

2005年12月20日

新世代FTPについて考える

 いまだにWebページのアップロードはFTPが主流である。

 FTPは非常に古いプロトコルであり、多くの問題がある。

 まず、コンテンツはおろか、パスワードさえも平文である。

 データ転送のためのコネクションをサーバーからクライアントに対して行うのも問題である。NATとの相性が悪い。この問題を回避するためにPASVモードがあるが、これはサーバ側のパケットフィルタのポートを多く空けなければならない問題が付いてくる。(最近やっと頭の中が整理できたのだが、従来のPORTモードはクライアント側のNATとの相性が悪く、PASVモードはサーバ側のパケットフィルタとの相性が悪い。)

 また、ファイル毎にデータコネクションを張るので、TCPのスロースタートとの相性が悪い。小さいファイルを沢山転送するときはスループットが落ちる。

 制御コマンドの方言も多々ある。ls のフォーマットさえ、クライアント側で方言を解釈しながらなんとか正常に読み取っている状態だ。


 ということで、そんな各種問題をクリアできるプロトコルを考えたらなんかイイコトあるかな? と思った。

 しかし、いろいろ考えたら WebDAVになってしまう・・・。WebDAVが普及すれば万事解決!!

 いや、でも、WebDAVの最大の欠点は port 80/443 であることだと思う。WebDAVを使おうと思ったら、Webサーバ自身の設定をいじって使用可能にしなければならない。なんだかWebサーバに穴を開けるような感じで、セキュリティホールを作りこんでいるような感じで、「なんかイヤ」と思う管理者が多いのではないかと思う。


 やはり、専用のポート・専用のプログラムを用意したほうが使いやすいのではないだろうか。rpm -ivh hogehoge.rpm で OK! って感じに。

 あー、でも、WebDAV専用ポートを勝手に定義して、apache をちょっと改変した rpm を作るのが手っ取り早いかもしれない・・・。

Posted by rukihena at 23:12:07 | Comments [0] | Trackbacks [0]

2005年12月 5日

cisco初体験

 cisco初体験である。しかも、いきなり海外(中国)接続である。関係ないが、初めての飛行機は国際線だった。(ハネムーンでオーストラリア)

 ciscoのドキュメントをWebサイトで探しても、なんだかまとまってない。離散的なドキュメントを離散的に読んで適当に設定して・・・つながらない。

 1時間半ぐらい悩んで、中国側に相談してみた。そしたら繋がった。おまえら、準備OKって言っていたのはウソだったのか? それが中国クオリティなのか??


 とりあえず、経歴書を書く機会があったら、Yamaha, Allied Telesis, NetScreen の他に Cisco も書けるようになった。

Posted by rukihena at 18:44:08 | Comments [0] | Trackbacks [0]

2005年11月16日

SSHD辞書攻撃とLogWatch

 SSH の辞書攻撃が流行っている。そのせいで、ログが大量に出る。攻撃対象IPも総当りなので、そこらじゅうのサーバで無駄なログが生成されているものと思われる。

 サーバには LogWatch を入れているので、長大な報告メールが作成されてしまう。しかも、デフォルト設定ではエラー部分しか作らないので、意図しない正常ログインを知ることができない。すげー意味のないログ加工である。一応、レポートレベルを上げると正常ログインも知ることができるが、長大なのが更に長大になってしまう。

 過去に CodeRed などが流行ったとき、アクセス数の半分以上が CodeRed というサーバもあった。なので今時のアクセスログ解析ツールでは、ウィルスによるアクセスはカウントしないようにできている。

 ということで LogWatch を最新版に入れ替えたら改善されているかな? と思ったが、7.0 でも同様に長大メールを生成する。

 どうしたものか。

 あんまりやりたくなかったが、LogWatch のスクリプトに手を入れた。思いのほかカンタンで、変えたのは /etc/log.d/scripts/services/sshd の

####if (keys %IllegalUsers) {
if(0){

 だけ。

 とりあえず快適になった。

Posted by rukihena at 23:34:42 | Comments [0] | Trackbacks [0]

2005年11月10日

vncserverにVMWareでメモリ不足でDDR2-533 1GBx2購入へ

 以前、PowerEdge800を買ったのだが、それを大活躍させようと思ってVMWareを入れてみた。PE800にはLinux(CentOS4.0)を入れてあって、普段はXを使っていない。普段はというか遠隔地にあるのでXを起動しても触れません。ということで、VNC server をまず入れた。

 Windows では VNCを使いまくりなボクだが、Linuxでは使ったことが無かった。ちょっと試した程度のことはあったが。

 で、適当に yum install xxx して、エラーが出たら適当に yum install xxx して、適当に入れてたらなんとか動いた。ウィンドウマネージャが古いヤツで見た目が寂しいが、かえって省メモリでよろしい。

 vncserver を立ち上げて、それにWindowsから接続した状態で VMWare をインストールし、さらにその中に Windows 2000 を入れてみた。

 すると、激おそ。耐えられん。多分メモリ不足である。そういや、256Mしか積んでない。Linuxで使うのに256Mなんて豪華すぎとか思って増設していなかった。単なる自鯖ならたしかに豪華だが、VMWareを入れるには少なすぎる。


 ということでメモリが欲しくなった。


 PowerEdge800のメモリは DDR2-533 である。AKIBA PC Hotline!メモリ最安値情報を見ると、最安値が 7550円。メモリは現在の需要が一番多い規格が最安値になる傾向があり、DDR2-533 は最安値である。古い規格のほうが返って高い。容量で見ると、512MBと1GBの容量単価が同値で最安値。ここは1GBを買うべきか。

 しかし、土曜の最安値を今日(木曜)買うのはまず無理だ。まあ、平均価格程度で買えれば良いかなと思いつつ、秋葉に行く。

 そしてまず最安値の店に行ってみる。そしたら普通にあった。思わず4枚買いたくなったが、あらかじめ2枚分の金額しか財布に入れておらず、2枚購入で踏みとどまった。

 しかし、メモリってそんなに在庫が動かないモノに成り下がってしまったのか・・・。

 ということで、サックリ買って帰ったが、PE800は遠隔地にあるので交換はまた後日。non-ECC が認識されるのか、確認せずに買っている。

 ちなみに妻の Dimension4700C も DDR2-533 なので、入れてみた。使えた。DELL の Diagnoseユーティリティで確認し、さらに Memtest86 でも確認し、途中までOKだったので多分大丈夫。全部は時間かかりすぎてやってられません・・・。

Posted by rukihena at 23:47:08 | Comments [0] | Trackbacks [0]

2005年10月10日

LogWatch を Vine にインストール

 LogWatch を Vine にインストールした。

 日々大量生産される自鯖のログを目で追うのは現実的ではない。ということで、LogWatch をインストールしてみた。

 参考にしたのはコチラ

 つまづいたところをメモ。

 rpm のバージョンが古いと、rpmbuild コマンドが存在しないようである。そんなときは、rpmbuild --rebuild とするところを rpm --rebuild とすればよいらしい。

 それで rpm が出来上がる場所が、/usr/src/vine/RPMS/noarch/ だったり ~/rpm/RPMS/noarch/ だったりする。まあ見つからなかったら一度 slocate を動かしてから locate で探してみるのもいいだろう。(find でもいいけど。)

 crontab への登録は不要で、/etc/cron.daily 以下にシンボリックリンクが作られてた。さすが rpm。ファイル名の頭に 0 が付くのは、logrotate などよりも先に実行するようにするためだろうか。

 さて、出てくるレポートもプチ長くて無視しそうな予感。最近は ssh が攻撃されやすく、ログイン失敗が大量に残る。無視する設定にしたいなぁ。でも調査面倒。いまのところ、読み飛ばしで暫定回避。

Posted by rukihena at 23:07:49 | Comments [0] | Trackbacks [0]

2005年10月 9日

Celeron300A寿命?

 Celeron300A を、自作界スタンダード速度で動作させていたのだが、調子が悪くなっていた。何度かハングアップしたのでIntel規定速度に戻してみた。それでかなり安定動作するようになった。しかし、こないだまたハングアップしてしまった。

 ファイル鯖&SoftEther仮想HUBとして動作させている重要なマシンなので、なんとかしたい。

 某所で余った PentiumII400MHzマシンをいくつかもらってきてあるので、交換しようかなぁと思っている。

 つーか、これらミドルタワー、いい加減邪魔なんですけど。まあ、もらってきたボクが悪いんですけど。

Posted by rukihena at 23:50:17 | Comments [0] | Trackbacks [0]

2005年9月22日

Iとlの勘違いで1.5時間無駄

 某所でBフレッツベーシックを引き、NetScreenの設定をした。NetScreenってのはファイヤウォールである。超有名どころよりは安価だが、家庭用的感覚からすると超高価だ。

 そんな微妙な層を狙う NetScreen をいじる機会は少ない。ボクがいじるのは2回目である。正直言うと慣れてない。慣れない中、設定をしたが正常動作しない。PPPoEの認証に失敗し、リトライし続けている。

 前にBフレッツの設定したとき、線を抜いて切断した後はしばらく再接続できなかった、という経験がある。5分ぐらいだろうか。正常切断してないと2重ログインと判断されてしまうのだろう。前の接続がタイムアウトするまで待たされる感じだった。今回もそれかと思った。

 しかし、いくら待ってもつながらない。そもそも1度も接続に成功して無いから、2重ログインもなにもないだろう。余計なところをいじって悩んだ。悩み続けて1.5時間。

 ID,パスワードはテキストファイルをプリントアウトした紙でもらっていた。しかし、よく考えるとプロバイダからの通知って郵送だよな。手でタイプしたってことか。しかし、これを疑うのもアレだよな。でも、もう手は尽くした。っていうか最初から疑っていたフシもある。依頼主(シャチョー)に聞いてみた。

 「OCNからの開通の通知ってありますか?」

 出てきた紙には、文字の「読み」が書いてあった。「ゼロ,イチ,エル」とか・・・。

 タイトルでもうお分かりかと思うが、l(エル)をI(アイ)と読んでいたボクが間違ってました。

 そのl(エル)はたまたま1(イチ)の隣にあり、「へへ、初心者ってここよく間違えるんだよな。ボクは20年の経験から間違えることは無いぜ!イチ,イチじゃなくてイチ,アイだよな!!」って思ったのが間違いの始まりだった。それと、最近は極力コピペするようにしているので、文字判読力というか、間違いやすい文字を思い浮かべる能力が衰えていた。

 愚痴ってもしょうがないので前向きな話を。

 「失敗する可能性のあるものは失敗する」というナントカの法則が教えていることは、失敗する可能性を排除しましょうということだ。つまり、プロバイダは、失敗する可能性のある文字をID,パスワードとして発行するべきではない。

-----------------------------------------------------------
  # 失敗しなさそうな文字のリスト↓
  $matigainai_char = '234567abcdefghmnprstuvwxzABCEFGHJLMNPRSTWXYZ';
  $password = '';
  for ( $i=0 ; $i<8 ; $i++ ) {
    $index = int(rand(length($matigainai_char))); # 何番目の文字を使うか、ランダムに選択
    $password .= substr($matigainai_char,$index,1); # 選んだ1文字を追加
  }
-----------------------------------------------------------

 こんな感じでID,パスワードを作って欲しいなぁ。コールセンターの業務も減りますよきっと。

 選択基準は以下のとおり。

1,I,l : ボクが間違えた。
o,O,0 : 基本。
8 : スラッシュ付きの0と間違えるかも?
D : 多分大丈夫だと思うけど、Oと勘違い
i,j : なんとなく
V,U : なんとなく
q,Q,9 : 口頭だと間違える。
k,K : 信じられんが間違えた人がいた。

 コールセンターがあるなら、統計を取って、実際の誤認識率から取捨選択したほうが良いかもしれない。あんまり外すとセキュリティが低下するから。

Posted by rukihena at 23:50:10 | Comments [0] | Trackbacks [0]

2005年8月13日

停電対策

 ブレーカーが落ちて、UPSで動いていたことに気づかずバッテリー切れまで放置、という最近どこかで聞いたようなミスを自分もやらかしてしまった。

 UPSの制御線を繋いで対応ソフトを入れてアラートを出すようにすべきなのだが、面倒なのでやっていなかった。停電なんてブレーカーが落ちる以外には殆ど無い。ブレーカーが落ちれば自分で気づくだろうと思っていた。不在のときにブレーカーが落ちることは無いだろうし。

 しかし、メインのブレーカーは無事で、サーバールームのブレーカーだけ落ちたので誰も気づかなかったという事態が発生したのだ。


 さて、じゃあ制御線繋ごうかと思ったが、ケーブルをどこにしまったか忘れた。どうしよう。

 面倒なので、転がっていたボロルータを、UPSを通さない電源に繋いで、それへのPING応答を監視するようにした。停電するとPINGが通らずアラートが上がる。

 監視用のソフトはすでに nagios を運用しているので、それの設定をちょっといじれば完成。

 ボクって頭イイ!と思ったが、バッテリー低下時のシャットダウン操作には未対応だ。最近のはハード的に壊れないのはもちろん、ソフト的にもジャーナリングファイルシステムなのでそうそうひどいことにはならないと思う。

 考えが甘いかな・・・。

Posted by rukihena at 22:55:28 | Comments [0] | Trackbacks [0]

2005年8月 2日

多重化

 羽田の管制の電源が落ちて飛行機が離着陸できなくなった。

 折角、バックアップ電源に切り替わったのに、それに気付かずに電池切れ(燃料切れ?)という原因。

 ダサい障害だが、なんだか自分も気をつけなきゃとも思う。似たような障害に、RAID1 とか RAID5 にしたのだが1台目が壊れていることに気付かずに運用し続け、2台目が壊れて運用できなくなってから気付いたというものがある。

 そういや、あの RAID1 にしているシステム、障害が発生したらどんなアラートがあがるんだろう・・・。確認しておかなきゃ。

Posted by rukihena at 23:03:02 | Comments [0] | Trackbacks [0]

2005年8月 1日

FFFSとかext3とか

 昔々(90年代)、FreeBSD と Linux の比較の話を聞いた。Linux は何でもアリの雰囲気。FreeBSDは由緒正しいモノ。Linux に NFSとかをやらせると遅い。などなど。

 その後、Linuxが妙に脚光を浴びてしまって、妙に作りこまれちゃったりして、Linuxが追い越したんじゃないかと漠然と思っていた。もはや FreeBSD のメリットはディストリビューションが1つであり混乱しないという消極的な利点しかないのではないだろうか。

 そんな風に思っていたとき、ファイルシステムについて調べることがあった。FreeBSDのファイルシステムはUFSである。Unix File System を略してUFS。単純すぎ。そしてそのバリエーションで FFS(First File System) とか FFFS(Fat Fast File System) がある。64ビット化した UFS2というのもある。狭義のUFSは初代UFSのことを指すが、広義のUFSはそれら全部ひっくるめてそう呼ぶらしい。ちょうど、VFATやFAT32を単にFATと呼ぶようなものか。

 FFFSなどは名前は速そうなのだが、それは昔に比べて速いのであって、現代から見ると遅い。Linux の ext3 のほうが全然速いらしい。

 やっぱりLinuxは追い越してるじゃん!!

 Portsの仕組みを知ったときも衝撃的だった。rpmとかaptの類を想像していたのだが、Portsはコンパイルするための情報の集まりなのである。Portsでラクラクインストールってコマンド一発なんだが、コマンド打ってからソースをダウンロードしてきて悠長にコンパイルを始めやがるのである。

 搭載CPUに最適化されたバイナリが出来上がるとか、メリットはあるのだろうが、どうにもこうにも面倒なんですが!!

 ということで FreeBSD が嫌いになった。

Posted by rukihena at 23:02:35 | Comments [3] | Trackbacks [0]

2005年7月24日

地震情報収集に遅れ

 昨日の地震の情報が気象庁に届くのが遅れたのは都庁のシステムが古かったため、という話。

 システムが古くても地震の発生具合は変わらないだろ、と思う。どう考えても最大負荷は都内の地震計の数になるわけで、パフォーマンステストの仕様は考えるまでも無くその数だけデータを送りつければよい。

 なのに何故過負荷になる?

 産経では

 雨量や川の水位などのデータを地震のデータと同時に処理したためにサーバーの能力を超えたことなどが原因
 としている。

 読売では

 このサーバーを導入した当時、都内の震度計は14か所にしかなく、都では「その後の増設分が計算に入っていなかった」としている。
 としている。

 どっちも理解できない。高々99件のデータである。しかも、こないだの新潟中越地震で一斉動作しているものと思う。そのときに問題にならなかったのは何故なのだろうか。

 ボクが考えているのは、震度情報(高々4ビットに収まる)だけでなく、揺れの波形も送っているというもの。揺れている時間が長いと、情報量が増える仕組み。大きな地震だと「揺れ時間」が長く、情報量が増大→過負荷になると。

 うーん、でも新潟中越地震の「揺れ時間」も長かったよなぁ。

 ナゾ。

Posted by rukihena at 23:59:34 | Comments [0] | Trackbacks [0]

2005年7月19日

802.3xフローコントロールとTCPスロースタート

 10M とか 100M が混在するネットワークで、フローコントロールに対応していない機器があると輻輳してパケットロスして激遅になる。

 最初に経験したのは前の前のカイシャで、当時すげー高価だった100MのHUBを入れたときだった。担当はボクじゃなかったので、詳細は分からないが、「なんか遅いので10Mに設定したら普通になったんでとりあえずそのまま」と言っていた。きっと、フローコントロールに対応していなかったのだろう。

 次に経験したのは某IDCと某社をCANで繋いだ時だった。このときも担当はボクじゃないので口出しできなかったのだが、IDCの担当者が「全部10M/Half に汁」と言ったのでそのとおりにして激遅からは逃れられた。

 機器を調べると、サーバ機の内蔵NICがフローコントロールに対応していない。10Mにしなくても、100M/Halfにすればバックプレッシャーでなんとかなるんじゃないかと思うのだが、試してみないと分からない。提案だけしてみた。今後に期待。


 ところで、TCPって、輻輳制御のためにスロースタートアルゴリズムを採用しているわけなんですが、それならレイヤ2でのフローコントロールをしなくても、パケットロスは頻発しないんじゃないの? との疑問を持った。

 もしかして、同じネットワーク(ブロードキャストドメイン内)宛ての通信はスロースタートしないでいきなりガンガン送りつけちゃうんですかね。

 ググってもわからんかった。プロトコルスタックのソースでも読もうかと思ったけど、多分読みきれません。

Posted by rukihena at 23:52:26 | Comments [4] | Trackbacks [0]

2005年5月25日

sftpのログって残らないの?

 ふと気付いたのだが、sftpでアクセスされたログが残らない。

 某FTP鯖のユーザから「なんか遅いぞゴラァ」と言われて調査したがログが無い。しかし、なにか通信している様子。tcpdumpで調べたら Port 22 (SSH) を使用しまくり。どうも sftp のトラフィックらしい。

 最初、proftpd の設定でいけると思った。それでその設定を変えて、sftp してみた。しかし、ログが出ない。色々調べていたら、sftpはOpenSSHのオマケのsftp-serverが実現している機能なので、proftpdは関係ないようだ。今更そんなことに気付いた。

 だが、sftp-serverが作られてから5年は経っていると思うので、ログ機能とか細かいアクセス制御機能とか無いのか!?と思って調べたが、無いようだ。どうも、sftpを使う/使わない、という設定以外を見つけられない。

 インターネットの暗号化って実に中途半端である。HTTPはHTTPSが普及しているので、まあ、いい。しかし、メールもFTPも、平文垂れ流しだ。

 なぜそのような状況で放置されているのか。ボクはIPv6が原因であると考えている。

 インターネットの明日を引っ張る先進的な人たちは、暗号化はHTTPSのようにレイヤ4以上(アプリ)でやるものではなく、レイヤ3以下(通信路)でやるべき、と考えているようだ。ということで、IPv6では通信路で暗号化するのが普通。すると、アプリは通信路の暗号化のことを考えずに済む。スバラシイ理論である。

 しかし、IPv6元年と言われたのが2001年か2002年あたりである。それなのにいつまでたっても普及しない。それなのにアプリ側での暗号化は放置されっぱなし。それが現状なんだと思う。

Posted by rukihena at 19:09:00 | Comments [0] | Trackbacks [0]

2005年5月13日

RHELクローンのCentOSをBitCometでダウソしたにょ

 RHELとは、RedHat Enterprise Linuxの略である。名前の通り、エンタープライズということなので、サーバー系のリナックスである。クライアント向けは Fedora Project に移管され、Fedora Core という名前になった。

 サーバ用途で使うには、Fedora Core は先進的というかむしろ動きが激しすぎなので、もうちょっと保守的なディストリビューションはないかな、というのが鯖管の思うところである。しかし RHELは高い。他のは「メジャー感」に欠ける。

 そんな中、RHELクローンの認知度が上がってきた。商標・ロゴなどを取り除いただけのクローン。違いはそれだけで、入手にかかる費用はタダ。セキュリティパッチなどのアップデートも無料で可能。最初に知ったのは Software Design誌で紹介されていた WhiteBox Linux である。が、最近はアップデートの速さで定評のある CentOS がメジャーのようだ。

 それで、CentOSをダウンロードしてみた。CD4枚組みで2Gほどの容量がある。

 この手の巨大ファイルのダウンロードでは BitTorrent が有名である。いわゆるP2Pなファイル配信プロトコルなのであるが、ダークさが薄い。匿名性などは無視して、とにかく著名ファイルを高速にダウンロードすることが目的のモノだ。人気のあるファイルほど高速にダウンロードできる、というコンセプトで作られている。

 これを実現するアプリであるが、純正モノは見た目がショボイ。いや、見たことないんですがね。そこで一番メジャーとされている BitComet を使った。

 それでダウンロードしたら、2MBytes/sec! 16Mbpsですか! 激早!! って思ったけど、理研のFTPから普通にダウンロードしてみたら普通に4MBytes/secでた。意味ねーよ!!

 尚、匿名性が無い割には、アレなファイルも流通しているようである。

 BitTorrent を知ったのも Software Designだったかな。会社を離れると業界に疎くなってしまうので、雑誌を読まないと世間から置いてかれてしまう。Software Designはボクの方向性にあっている記事が多いので重宝してます。




Posted by rukihena at 19:17:34 | Comments [0] | Trackbacks [0]

2005年3月20日

地下鉄サリン事件から10年

 地下鉄サリン事件から10年の年月が経過した。

 事件当時、ボクは苗場プリンスでバイトをしていた。事件を知ったのは休憩室のテレビからである。テレビを見ている社員(地元採用)は

 「へぇ、やっぱ東京はコワイねぇ〜。」

 まったく他人事というか外国の出来事のような言葉を発していたのが印象的である。

 ボクはバイトをしてパソコンを買おうと思っていた。まだWindows95が発売されていない時期である。いわゆるWindowsPCが、AT互換機と呼ばれていた頃。AT互換機を買うなら香港旅行のついでに買ってくると 国内PC価格>香港旅行+香港PC価格 になりお得、という時代が終焉しつつあるというか完全に終わって普通にアキバで買えよ、という頃。そして、オウム系のマハーポーシャというパソコンショップが「超超超激安〜」とかいいながらビラを配っていた頃である。バイト始めた当初は、「安い」という理由だけでマハポーシャで買おうと思っていた。

 バイトを終えても、マハーポーシャで買おうと思っていたが、もう存在してなかった。仕方なく、ドスパラで買ったPCは CPUがAm5x86P75-133 でメモリ8Mぐらいで HDD 540MB ぐらいだっただろうか。これに Windows3.1を入れて、Trumpet Winsock で大学にダイヤルアップしてインターネットに接続して Mosaic でネットサーフィンしていた。

 研究室の SUN4/LX に NCSA HTTPd をインストールしてショボイホームページを作っていたような気もする。しかしロボット検索はおろか、Yahoo! さえ存在しない時代であり、ボクが誰かにURLを教えなければ誰も訪問してこない状態だった。

 研究室の扉には、教授と生徒の居場所を示す表と磁石があるが、それをCGIで実現しようとしてCGIの勉強もした。Perlを覚えるのが面倒でC言語で作ったような記憶がある。

 あれ、何の話だっけか。

 そう、地下鉄サリン事件から○年というのは、ボクのインターネット暦○年に相当する。情報発信サイドという見方でも10年。ボクのプチ自慢の一つだ。

Posted by rukihena at 21:48:05 | Comments [0] | Trackbacks [0]

2005年3月18日

apache 大量のバーチャルホストの動的な設定

 もっともメジャーなHTTPサーバである apache には、バーチャルホストと呼ばれる機能がある。IISにもあるので、まあ普通の機能なのだろう。

 これは1つのサーバ機で、あたかも複数のHTTPサーバが動いているように見せかける機能である。NAT+と並び、IPv6の存在意義を否定する機能でもある。

 比較的簡単にドメインを増やすことが出来るからといって、調子に乗って増やすと壁にぶち当たる。ログファイルを開けなくなるのだ。通常、1つのサイトはアクセスログとエラーログで2つのログファイルを開いている。普通のOSはファイルを同時に1024個しか開けないので512サイトが上限になってしまう。正面から対処すると、リコンパイルという大げさな話になってしまう。

 そこで、Dynamically configured mass virtual hosting を読むのだか、なぜか日本語訳が無い。リンクのタイトルまでは日本語になってるのに。

 要約すると

VirtualDocumentRoot /www/hosts/%0/docs
VirtualScriptAlias /www/hosts/%0/cgi-bin
って書いておくと、
http://任意のホスト名/任意のパス
にアクセスしたときに
/www/hosts/任意のホスト名/docs/任意のパス

のファイルが使われる。
それだけである。

 サイトを増やす際は、フォルダを増やして、DNSの設定をすれば終わり。httpd.conf をいじる必要が無い。apacheの再起動も不要だ。ログファイルも1個なので、ファイル数制限に引っかからない。ただし、どのサイトへのアクセスか分からなくなってしまうので

LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog logs/access_log vcommon

ってしておくと、ログの行の先頭にホスト名が来る。
アクセス解析ソフトを使っている場合は、ちょっと面倒なことになるかもしれないが、まあ何とかなるだろう。

 ただ、この %0 を使った設定と、スペシャルな設定をするための静的なサイトを混在させようと試みたが、できなかった。IPを複数使えば出来そうな気がするが、勿体無いので検証していない。

 それと、例えば商品カテゴリ別にドメインを作ろうとか、そうゆう用途であれば、バーチャルホストの機能を使わず、CGIとかでSERVER_NAMEを見て判断してページを生成するのがラクなんじゃないかと思う。

Posted by rukihena at 23:10:14 | Comments [1] | Trackbacks [0]

2005年3月12日

クラック

パッチあててないLinuxがクラックされた _| ̄|○
パッチをあててないと1年持たないことが実証された。
本番環境で試すなよ。>ボク
いや、あれはハニーポットだったんですよ。ええ。
勝手に垢作りましたねzmeuさん。

Posted by rukihena at 23:30:11 | Comments [0] | Trackbacks [0]

2005年2月22日

RTFM

某大手DB屋に勤めるY氏からチャットで
http://ore.dyndns.org/web/RTFM.html
が送られてきた。客先なので返事しなかった。すまん。

 まあ、耳が痛い話だ。ボクのhttpd.confにそうゆう記述があるよ。

 先日の GDI+ と VC++ と日本語 で、「全体的にVC++の話はググっても情報が少ない。」と書いたが、VC++ユーザーは間違いに対して神経質なのではないだろうか。歴史の古い言語なので、「歴史的事情」が多い。一見正しそうなちゃんと動いているコードでも、厳密には間違っている、ということに頻繁に出くわす。正直言って、永遠に正しいコードにはならないんじゃないかと思いつつも、限定的なテストだけに通ればリリースしちゃうのである。それで、自分の現在の知識は正しくないかもしれないという意識がある。なので間違っているかも知れない自分の知識を広めてはいけないという良心から、情報を発信しない。

 正確さの重要性を知っている人間ほど、情報を発信しない。ということは、世にあふれる情報は伝言ゲームで捻じ曲げられた間違った情報だらけということになるのだろうか。

Posted by rukihena at 23:53:30 | Comments [1]

2005年2月 3日

awstats

 アクセスログ解析プログラムをいままで入れてなかった。ログは前回引越し時から全部保存していて、2003年7月ぐらいからで、600MBytesぐらいになっている。

 フリーの解析ソフトでは analog が古くからあり、有名である。しかし、某所で awstats がいいらしいといことで導入したので、ウチでもそれを使ってみることにする。インストールしたのは3日前ぐらい。

 このウェブログ分のログは少ないので、比較的短時間で解析できた。しかし、www.rukihena.comのほうは、いまだ処理が終了しない。ここ3日ほど、鯖が重くなっていると思う。

 ちなみに、有料のパッケージソフトでは、Urchin(アーチン)が有名らしい。これも某所で使っている。やはり有料モノは滞在時間などが詳細に見れていい。ネットショップなどでは有料のモノを導入したほうが良いだろう。

Posted by rukihena at 23:53:41 | Comments [0]

2004年12月16日

DNSのキャッシュ

某サイトがアクセス不能になった。DNSの管理とWEBサーバの管理は別会社なのだが、先方はWEBサーバ管理会社を疑った。しかし、原因はDNSの期限切れだった。DNS管理会社に電話で連絡したら、すぐに復旧した。昔は1〜2週間は浸透せずダメだったような気がするが・・・。
昔は、正しい情報も、ダメな情報も、キャッシュで記憶している時間が同じだった。それが週レベルの時間になっていたため、一度ダメな情報がキャッシュされると、困ったことになっていた。よくやってしまうのが、設定前に念のためにnslookupしてしまうことである。たとえば、これから www.rukihena.com を設定しようとしたら、思わず nslookup www.rukihena.com と手が滑ってしまうのである。それにより、www.rukihena.com は存在しないよ、という情報が1週間の期限付きでキャッシュされてしまう。その後いくら正しい設定をしても、キャッシュが can't find とか答えてしまう。DNSの設定の難しさの原因はそこらへんにあると思う。
そこで、RFC2308 で、ダメキャッシュはもっと短い時間にするよう提唱された。1998年のことである。しかし、一度広まった設定例は多くの自宅鯖房にコピーされ、設定メモとしてWEBで公開され、都市伝説のように古い設定例のまま広まってしまっている。
また、DynamicDNSが普及して、ダメキャッシュも普通のキャッシュも短く設定するのが流行のようだ。意図的にキャッシュを短くすれば、かなり短時間のうちに復旧できるようになる。
昔に比べて桁違いに早くなった処理能力と回線速度を考えれば、キャッシュの時間を桁違いに短くしても、そう問題が起きる事は無いのだろう。

Posted by rukihena at 16:23:00 | Comments [0]