母方の祖母が亡くなりました。 享年97歳でした。 冥福を祈りつつ。
家族葬で送ることにしていたため、親族と、ごく親しい知人のみにお知らせしていました。
祖母の告別式を執り行いました。
本人の希望で検体を行うことになっていたため、告別式のあと病院まで車で移送しました。
医学部の２回生による解剖実習が行われるのは毎年４月〜６月であるため、来年のその頃まで保管されるとのことでした。
来年に納骨を行うことになります。
どうやらHDDが物理的に壊れたらしい。 しばらくはceres.dti.ne.jpの方しか見えないかな？
長い間 BIBLO NC313がおうちサーバをやっていたが、そろそろ次のマシンに世代交替することにしよう。
BIBLO NC313って 1998年3月29日に買ったのか。
実に9年も動作し続けた(今でも別に壊れているわけではない)。
あの頃の日本製マシンの強度は異常だ。
今度おうちサーバにするのは退役してしばらく寝ていたACER Travel Mate C100。
こちらは2002年12月19日に購入したもの。
ノートPCなのにネジ一本で内蔵HDDが交換できるスグレモノだ。
早速、11,800円で購入した HITACHI 2.5inch 12mm height 160GB HDD へサクっと換装する。
これは本当に楽だ。
正直、デスクトップPCよりもHDD換装が楽だ。
デスクトップPCに入れたのがFreeBSD 6.1だったので、それに合わせてノートPCにもFreeBSD 6.1-RELEASEをインストール。
2002年代のPCでは、BIG DRIVE(120GBを越えるATA HDDにアクセスする機能)を持っていない場合があるので、インストール時のfdisk指定で120GB以下のスライスを作成して、そこにインストールする。
後でデスクトップ側で作ったpackagesからpkg_addする予定。
復活したのはいいけど、「一応内容を確認してねー」という意味から、別のディレクトリの中に復活。 ここからは手動で復活させんといかん。
さて、問題は ftp.yk.rim.or.jpはpassiveモードのFTPを受け付けない点。 そして、ウチのルーターはNTT-ME BA5000 SOHOなのだが、これがpassiveではない普通のFTPと猛烈に相性が悪く、数ファイル転送した所で止まってしまうのだ。 今回のように、ふきとんだ全ページを復活させようと一気に大量のファイルを転送しようとすると、止まりまくりでマジに死ねる。 元データ自体はローカルマシンに全部保存されているので、yk.rimが飛んでも問題ないんだけどねー。
そろそろルータ買い替えるかな。
これを機会にWebサイトの構成見直すかなぁ。 うーん。
とりあえず、cgiのカウンタを動かすことからはじめよう。
yk.rim上の自作カウンタは、恐ろしい事にC言語で書いてあるのだ。
その昔、リムネットではshellアカウントサービスというものがあって、telnetでログインしてUNIXコマンド(Cコンパイラ含む)を使えていたりしたのだ。
当時はソレを使ってCGIをコンパイルしてWWWサーバに置いていた。
時代は変わって、現代。
shellアカウントサービスは既に無く、手元のFreeBSDマシン郡は最新版に入れ替わった。
既にwww.yk.rim.or.jp上で動作するバイナリファイルを作る環境が無くなっている。
そんなわけで、ぷちぷちとperlでアクセスカウンタを作成。
参考元はCodeZine モジュールを使わないシンプルなアクセスカウンタ GIF表示型。
上の例では近代的にGIFのバイナリを生成して出力するのだが、自作のperlスクリプトではx-bitmap形式のグラフィックデータをテキスト形式で出力する。 x-bitmap形式とは、下みたいな感じで画像イメージをテキスト出力したもの。
Content-Type: image/x-xbitmap
Content-Length: 575
#define count_width 64
#define count_height 10
static unsigned char count_bits[]={
0x3c, 0x3c, 0x3c, 0x3c, 0x3c, 0x3c, 0x30, 0x3c,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x30, 0x66,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x38, 0x60,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x38, 0x60,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x34, 0x38,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x34, 0x60,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x32, 0x60,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x7e, 0x60,
0x66, 0x66, 0x66, 0x66, 0x66, 0x66, 0x30, 0x66,
0x3c, 0x3c, 0x3c, 0x3c, 0x3c, 0x3c, 0x78, 0x3c
};
こんな感じの文字列を生成してテキスト形式でCGIプログラムからprintすると、ちゃんとグラフィックとして表示してくれるブラウザって偉いよなー。
とか言ってたらWindows XP SP2以降のIE6だと表示しねえええ。
Mozilla/SeaMonkey/FireFox系だけか...表示してくれるのは。
どうやらこんな裏事情があったらしい。
XBM画像が表示できない!? WinXP SP2の横暴。
上のサイトによれば、以下のようなレジストリー・エントリー・ファイル (.reg ファイル) を用意してXBM画像を表示するように設定することもできるらしい。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE¥SOFTWARE¥Microsoft¥Internet Explorer¥Security] "BlockXBM"=dword:00000000
これはこれで設定するのが面倒だな。 そのうちになんか適当な画像フォーマット出力に対応するかのう。
ファイルは自宅FreeBSDマシンのMakefileをいじって再転送をかけた。 相変わらずftpの調子が悪いので、転送成功したファイルはリストから削っていき、何度もftp試行するというブルートフォースな方法を用いた。 これで一通りは復活したかな。