Linuxの最近のブログ記事

昨日。いや、カーネルの更新があったので、リブートしたんですよ。そしたらば、不幸な偶然が重なって、サーバが音信不通になってしまいました(^^;;

いえ、もう、あれこれ面倒くさいので、家の中のIPアドレスはルータ以外は全部、DHCP管理なんですよ。基本、DHCPなんだけれど、DHCPで固定割り当てしているんです。

で、DHCPサーバは、ルータ自身と、他に二台のLinuxサーバに提供させています。固定割り当てが大半だから、度のサーバも同じ答えを返すわけですが、万が一に備えて、多重化しているわけです。

で、リブートしたのはそのうちの一つだったのです。すると、この時点で、実はルータのDHCPサーバは、頓死状態にありました。このサーバ、時々意識を失うんですよ。だからこその多重化だったのですが。でも、もう一台生き残っているから問題ない……はず、だったのですが、たまたま、この人のアドレスのリース期限が切れたために、アドレスの再取得へと走ったタイミングだったようで、誰も応答しないので、この人がアドレスを失い、結果、この人がサーブしていたDHCPサーバが頓死してしまったという……。そしてリブートしてきたサーバはアドレスをもらいたいのだけれど、だれもくれずに…… oTL

間抜けな話で、希少な当ブログの読者の皆様にはご迷惑をおかけしました。申し訳ありませんでした。次回、リブートすることがあったらば、もう少し、慎重に、DHCPサーバの状態を確認してからにしたいと思います(^^;;

我が家では、家庭内LANのIPアドレスはすべからくDHCPで割り当てられるようになっています。新しくマシンを導入するときに設定が楽だからです。それでも、勝手なIPが割り当てられると面倒なので、DHCPサーバで固定IPアドレスを割り当てるようにしています。

基本的には、サーバが死んでいても、ルータが生きていれば外へ行けるようにと、ルータがDHCPサーバも兼ねてきたのですが、このDHCPサーバ、時々意識不明になるんです。意識不明になっているのに気づかないで、リース期限がやってくると、それぞれの端末は再割り当てを要求にいくのですが、この返事がないために、次々とIPアドレスを手放して……つまり到達不能になってしまうのです。

昨日夕方から夜にかけて一時的に、当ブログなどが意識不明になっていたのはこのためでした。いやはや、お粗末な話です。結局ルータをリブートして、さらにはこのサーバもリブートしました。何しろ到達できないので、dhcpcd を走らせて、IPを再取得することができなかったモノで。玄箱PROの方は、サーバとシリアルコンソールでつながっていたので、サーバが復活した後に、リブートすることなく、IPの再取得ができましたが……。

よくよく考えてみると、ルータが生きていても、DNSはルータにはやらせていないので、家庭内のDNSが全滅すれば、外へは事実上いけなくなるので、だったら、DNSマシンにDHCPもさせればいいんじゃないのか? ……と、いうことで、まず、メインのDNS上で、DHCPDを動かし始めてみました。様子を見ながら、もう片方にも同じ設定のモノを投入して、ルータのDHCPサーバ機能は無効にしようと思っています。もう、固定IP割り当てようのテーブルも枯渇していたところだし。

我が家のバックアップ/メディアサーバを担当している、玄箱PRO。Debian GNU/Linux 5.0で運用しているのだけれど、カーネルの更新があった。カーネルの更新は当然リブートを伴う。

前回は、リブートしたら、なぜか fsck が走って、再起動するまでに、偉く時間がかかったのだが、今回は、全然そんなことなくて、さくっと再起動。前回の反省を活かして、メインのサーバにシリアルコンソールを立ち上げて待ち構えていたのに(^^;; ^*1 謎は深い……。

先週の木曜日に頓死してしまった我が家のデスクトップPC。経験的にケミコン抜けだと思ったわけで、速攻でマザーボードとCPU、メモリを買いそろえて交換してしまったわけです。もちろん、入れ替えた方はあっさり動作したわけですから、ケミコン抜けで間違いなかったと思われます。

およそ50ヶ月にわたって、我が家で、重たい仕事をさせられてきたPCですが、そんなわけで、引退となりました。こうしてみると、Socket939 の最後期のマザーですが、SATAが四本あったり、内部向けのIEEE 1394やらUSBやらが二つずつもあったり、IDEもまだ二本も内蔵していて、非常に贅沢な構成だったように思います。

いや、あんまり高くないヤツを選んだはずだったんですけれどね。当時は、このくらいのマザーが結構安かったので、助かりました。

今回も、安めに押さえようと思っていたのですが、買っていくらも経たないうちに、Socket 939はSocket AM2に取って代わられ、CPUのアップグレードもなにもあったものではなくなってしまったのは、既に書いたとおり。そんなわけで、多少高くても、と、AMD890GX搭載のマザーにしたわけです。コンデンサも、固体コンデンサを多く使って長寿命、らしいので、やはりそういう意味でも、次まで、長くアップグレードできるようになっていた方がきっといいのです。

Socket AM3/最大16GBまでサポートするこのシステムは、6コアのプロセッサにも対応できるので、プロセッサのアップグレードもありか?! と思っていたりもします。

そこまでしないでも、たとえば、30分弱の番組をH.264でエンコードしてPSPにいれて持ち出すのに、30分以上の時間がかかっていたのが、5分でエンコードが済むし、とにかく、想像以上に快適になって大満足なのです。

さらに、ASUSのマザーにExpress Gateというオマケがついていて、Windows 上から、付属のDVDを使ってインストールしておくと、起動時に、5秒くらいでLinuxベースの簡易システムが起動して、ウェブメールだとか、ウェブアクセスだとか、YouTubeの閲覧だとかができてしまうのです。へぇ、面白いじゃないですか。VAIOだとか、ネットブックとかにも使われているようなアレですよね。

日本語入力に難があったり、Windows 自体もそれほど待たされずに使えるので、ほとんど使うこともありませんが、結構面白く、意味もなくメール見たり YouTube見たりしてしまいました。

さて、仮想化にも対応していることだし、そのうち、どれかの、仮想化システム入れて、何かインストールして遊んでやろうかなぁ？ Virtual PCか、VMWare Playerか、それとも VirtualBoxか……さてさて。

いつの間にやら、5.1がリリースされていたので、いつものように、我が家のサーバもアップグレードです。マイナーアップグレードで、かつ、DBなど、モノによっては、データの待避を行なう必要のあるような面倒くさいモジュールは含まれていないので、ざっくりと行きます。

aptの行き先を、5.0から5.1へと変更してから、aptで、一気に更新をかけます。うちの場合で、39パッケージが更新されました。ものの5分程ですべて終了しましたが、こまめにアップデートしてないともっと時間がかかるかもしれません。

SNMP+MRTGでシステムの監視を、玄箱の時からしていたので、玄箱/PROにも当然のように導入しようとしたのですが、どういうわけか、dskEntryの項目が、まるっと、snmpdの管理から抜けてしまっています。原因不明(/_T)

特に、妙なところはないと思うのだけれど、.1.3.6.1.4.1.2021.9.1 ^*1 が存在していないのです。snmpd.cfgには他のサーバと特に違いは見あたらないのだけれど。

とりあえず、ディスク容量の監視は別のフレームワークを考えることにしようかと思っています。ふむー、先はまだ少し長いかもしれない。

あまり特殊な環境は、セキュリティホールなどの手当にかかる手間も多ければ、拡張性も低いので、最初からDebian化することに決めていました。

玄箱/PROは、ARM9ベースのCPUを使っていて、Etchまでの Debianでは、EABI/OABIの問題がありましたが、Lennyからは、正式にEBIがサポートされ、さらに、玄箱/PROもサポートしているので、手間なく、Debianになる……はず、でした。

Debian化については、エレキジャックのサイトで、詳しく触れられているので、そのやり方でインストールすることにします。必須ではないけれども、シリアルコンソールがあった方が色々安全そうなので、玄箱/PROと一緒に、SCON-KITも購入しておきます。SCON-KITは、キワモノ扱いで、玄箱/PROのUSB0のスルーホールコネクタに、ピンを半田付けしてやる必要があり、しかも、これをやってしまうと、玄箱/PROの保証もなくなってしまうと言う、強烈なキットですが、結果的にコレがなかったら、全くお話にならなかったので、そんなことを気にする人は、Debian化などしちゃいかん、ということでしょう。

普通は、起動チェックくらいしてから、やるんですが、ちょっと時間的にタイトだったので、いきなりSCON-KITを半田付け。よい子はまねしてはいけません。デバイスドライバをダウンロードしておけとか書いてありますが、Windows7は、勝手にネットワークからダウンロードしてデバイスドライバをインストールしてしまいます。

玄箱/PROの電源を入れると、起動シーケンスがターミナルの画面に表示され、最後に、AAのサングラス男が現れて、ログインプロンプトとなります。ここで、debian-lenny.tar.gzを、指示通りに、’\\kurobox-pro\mtd device\’にコピーします。特に何もしなくても、LAN上のPCからこの通りに見えていました。よくできています。

玄箱/PROにログインして、/mnt/mtd で、展開して、/mnt/mtd/InitDisk1.sh を走らせると、あとは、一気にインストーラが起動します。が、ここで、最初のはまり道。エレキジャックのサイトで配布されている debian-lenny.tar.gzに入っている、uImage.buffalo, initrd.buffaloが古いため、インストール中に、「カーネルモジュールが見つからない」といって、インストール出来なくなってしまいます。 ^*1

なので、InitDisk1.shを起動する前に、/mnt/mtdに出てきた、この二つのファイルを、ftp.debian.org:/debian/dists/lenny/main/installer-armel/current/images/orion5x/netboot/buffalo/kuroboxpro にあるファイルで置き換えます。これで、インストール中に、カーネルモジュールが見つからないというエラーは起きなくなります。

さて、インストールの様子は、エレキジャックのページに詳しく出ている通りなので、あとは、その通りにやるだけなのですが、この後に更にもう一つの大きな落とし穴がありました。

全てのインストールが終わり、リブートされて、ログインプロンプトにたどり着いたので、ユーザを作ったり、必要なディレクトリを掘り、exportsやらsambaやらの設定もし、sshを、公開鍵でのみログインできるようにし、ntpなどのツールも導入し、設定し……さあ、では、シリアルコンソールのために、外しっぱなしだったフェイスパネルをはめて、設置場所に移動して、起動……あれ、全然立ち上がらない oTL

再び回復して、シリアルコンソールに繋いだら、rootパーティションのマウントに失敗したとかでtftpをかけに行っては死に、またかけに行っては……と言う状態になっていました。シャットダウンしたときに、スーパーブロックを壊したか、と思って、再度クリアインストールしたものの、リブートではびくともしないのに、シャットダウンをすると起動できなくなるというまか不思議な状態になってしまいました。

フラッシュから起動させると、HDDのパーティションは全てマウントでき、つまりHDDが壊れているワケではありません。フラッシュのuBootの設定やら、なにやらを散々チェックして、結論として得られたのは、どうも、bootcmdに設定されている ‘ide reset’が、電源投入直後だと、うまく動かないようで、ide resetをもう一つ挟み込んでやったら、きちんとブートするようになりました oTL

これは、必ずこうなる、というわけではなく、HDDとの組み合わせによって起こる問題だと思います。とはいえ、これで丸一日を棒に振ったのかと思うと、げんなりでした。

月曜日、ブレーカを落とされるという災難に遭ったため、我家のサーバ環境は一時的に停止しておりました。そして、そのうち玄箱は、内蔵しているHDDが逝ってしまったために永久にお亡くなりになってしまいました。

データおよびバックアップDNSなどのバックアップを担当していた箱なので、ないと困るのですが、今更、パラレルIDEのHDDを買ってきて復旧させるのもナンです。玄柴を待つというのもあるのですが、次回販売分も確実に買えるかどうかは判らない上に、それまでバックアップなしで凌ぐのも不安です。

というわけで、玄箱/PROを買って、これで玄箱の代替としました。ついでに、グラタンの担当しているメディアサーバ機能も移行してしまえば、箱をひとつ減らせるので、万々歳だとかいうことも企んでいたりします。

が、玄箱/PROを稼働可能な状態に持って行くまでが、非常に大変だったのです……。

SheevaCPU (ARM 1.2GHz)搭載の小さな Linuxマシン、玄柴。eSATAやUSBを内蔵しているし、もちろんGbEポートもあるので、老朽化が懸念される、玄箱 + グラタンの後継バックアップサーバとして買おうと思ったのだけれど……。

限定50台だから厳しいかなーと思っていたら、案の定……完売御礼でした oTL

PHP 5.3 に対応したフレッシュリーダーを公開しました

PHP 5.3 に対応したフレッシュリーダー (バージョン 2.1.09101500) を公開しました。

とりあえず、Linux版のみ、PHP5.3対応のioncube loaderが同梱されています。うちのサーバ的には、ソレで充分ですので、早速インストール!!

無事に、フレッシュリーダが動作するのを確認しました。Google リーダーを使っていた間に更新されたフィードを取り込んで、環境を再構築しました。嬉しい!!

今朝、サーバのカーネルをアップグレードした関係で、リブートをかけたのですが、シャットダウン時に、PostgreSQLがきれいに落ちきっていませんでした。

結果、ブートアップ時に、サービスをスタートできず、カウンタがでなくなってしまっていました。推定、30名弱/日の読者の皆様、ご迷惑をおかけいたしました。ご指摘下さった snapperさん、感謝感謝です。

何しろ、今日は、朝から、息子に部屋を明け渡すための作業をしていまして、リブートしたところだけ確認して、細かなチェックを全然していなかったものですから(怠惰)。

余談ですが、息子に部屋を明け渡す作業が完了すると、めでたく、ワタシは、自宅に部屋を失います。しくしく。まぁ、しばらくは、自宅から仕事する時などは、息子の部屋を専有してやる予定ですが(^^;;

せめて、購読リストだけでも取り出せませんか？ そういう問い合わせをしたら、「できます」というお知らせをいただきました。教えていただいたコマンドを通すことで、購読していたサイトに関するリストが出てきました。助かりました。ionCubeなんて使っているのはアレですが、サイドフィードは非常に親切な会社だと思いました。

購読リストは、フレッシュリーダのディレクトリ内の db/userの下に、u-u402dfa.db のようなファイル名で格納されているそうで、これを、次のように処理させれば、UTF-8でリストの一覧が取り出せるそうです。同様のお悩みの方はご参考まで。

九月リリースだというから待っていた、PHP5.3対応版のionCube loaderが、今日、ダウンロードページを見に行くと「2～3ヶ月後のリリース」とかいう巫山戯た状態に書き換わっていました(- -#)

この手のものは、PHPが開発版の時から常に動作検証して、必要な対策を講じ続ける必要があるのに、いかにもやってませんでしたという感じがにじみ出ていて、不快。

こんなツール、個人的には使いたくもないのだけれど、FreshReaderがこれを必要としていたから、使っていたのだが、こうなると、もうFreshReaderも見切りをつけるしかなさそうだ。問い合わせたところ、PHP5.2をインストールしろとかいうし。

ようやく、問題点を発見しました。OpenPNEのバグでした。公式SNSで一応レポートしておいたけれど、コレしかバグがなくてもすぐリリースするよ、というのとは開発体制が違うので、すぐには反映されないでしょうけれど、明らかすぎるバグなので、キット直してはもらえるでしょう。

署名の生成に問題があるのは間違いなくて、これが OpenPNE側なのか、libopkele側なのか、で両側から追いかけていったのです。すると、署名する直前のデータは完全に一致。ならば、同じアルゴリズムを使っている以上同じ署名が出るべきなのに、これが出てこない。

と、OpenPNE側の署名生成を見ると、return hash_hmac(‘sha256’, $key, $text, true) とかって書いてある。PHPのリファレンスを参照すると、これは string hash_hmac ( string $algo , string $data , string $key [, bool $raw_output= false ] ) であると、書かれている。はい、鍵とデータが逆ですね oTL

ということで、OpenPNE側の呼び出しを、hash_hmac(‘sha256’, $text, $key, true)に直しただけで、あっさりと、認証をパスしてくれました。ファイルは lib/include/Auth/OpenID/HMACSHA1.php の中です。hash_hmacで探せばすぐに見つかるでしょう。同じ問題でお困りの方はご参考までに。

なお、libopkeleは 2.0.3以降にされることをオススメします。2.0.2以前では、IDが一桁の数字のヒトは認証できませんので。

Single Sign inのための仕組みとして、OpenIDというものがあります。OpenIDに対応しているプロバイダに登録してあるアカウントとパスワードで、他のサービスも受けちゃおうというヤツです。

現在、とある事情で、OpenPNE + mod_auth_openid + Apache2という組み合わせで、OpenPNEに登録されているアカウントで、アクセス制限をかける実験をしているのですが、これが全然上手く動かないのです。

確かに、OpenPNEにログインしているアカウントなのに「ログイン中のユーザではありません」とかいわれて拒否されるのはなんでか？と調べていくと、openid.identityというパラメータに渡っているべき、ユーザIDがまるっと削れている。何故？と調べていくと、ここが一文字だけだと削れてしまうことが判明。ためしに、7桁もあるユーザIDのミクシィを使って認証させると、サクサク通る。

ダレが、これを削っているのかと調べていくと、mod_auth_openidが利用している、libopkele の、URIを正規化している関数にバグがあって、認証用のURIの最後が ‘/x’ のように、「スラッシュ+一文字」だと、そこが削れてしまうのでした。早速修正して、バグレポートをlibopkeleの作者に送ると「今晩、新しい版をリリースするよ。」と、このためだけに新しい版をリリースしてくれました。(2.0.3)

これで、いけると、再トライすると、確かに、少し進むように。が、進んだところで「なんかエラー」と言われて認証できない状態。更に調べていくと、mod_auth_opeind(というかlibopkele)がチェック用に生成する署名と、OpenPNEが送ってきている署名が一致しないので認証できないという状態。署名が一致しないのは、OpenPNEをプロバイダにした場合だけ。さて、何が悪いのか……。

Atom 330なので、ソフト見えは、4CPUなのです。まぁ、実態はDual Coreで、それぞれがHT実装ということだから 2x2みたいな感じでしょうか？

色々がりがり走っているときでも、待たされる感じは少なく、やはり Dual Coreの威力というのはあると思います。

うちのサーバは、あまり重いサービスを走らせてはいないのですが、それでも、昨日、当ブログを、全て再構築した際でも、途中で頓死しまくった、VIA C3 800MHz時代とは雲泥の差。2.5時間ほどかかったものの、全てをきちんと再構築してくれました。

ああ、余力があるっていうのは素晴らしいなぁ。

Vine Linux 5にして、自力で復旧できる部分は復旧したと思います。あとは PHP5.3化に伴う、FreshReader (ioncube)と、XOOPS Cube Legacy の問題だけですが、こればっかりは、対応版が出るまでどうにもなりません。

これまで、割と、後方互換パッケージを提供してくれていた Vineですが、Vine Linux 5になって、この辺を改めたのかもしれません。PHP52 とかっていうパッケージがないかと見てみましたがありませんでした。しくしく。

全然、いらっしゃって下さる方には関係ないのですが、サーバのハードウェアを更新しました。D945GCLF→D945GCLF2に。推定でパフォーマンスは二倍ほどです(笑)

Vine Linux 5がリリースされたんですよ。早速うちのサーバも4.2からアップグレードしました。が、結論から言うとどっぱまりです。

• PHP5.3の呪い
  このおかげさまで、ioncubeが動かず、フレッシュリーダが使えなくなりました。 あと、よく判らないけれど XOOPS Cubeも動かなくなりました oTL
• ロケールの呪い
  Vine Linux 5からデフォルトのロケールがUTF-8になりました。が、既存のものはたっぷりEUC-JPで存在しています。多分、このあたりのからみで、PostgreSQLのデータベース回りにも影響が出ています。 Windows Live Writer経由での投稿が出来なくなりました oTL 文字コードが気に入らんと怒られます。 ^*1

メールと、ブログの部分だけはとりあえず運転開始にこぎ着けましたが、先は長そう。ioncubeは、9月にならないと php5.3対応しないとかいっているし……ちょっと先進的すぎ?! > Vine Linux 5

うちのサーバ上の掲示板には、毎日、よくもまぁ、懲りずに送ってくるよな、という、英語や、時に英語ですらない、いや、おそらくは言語ですらないランダムな文字列と、おそらくろくでもないことが書いてあるであろうURIとが投稿されています。

もちろん、可及的速やかに、削除し、アクセス元の割り出しを行ない、海外からだったら、もう、まるっとアク禁、国内だったら、管轄するプロバイダなりなんなりに、事実報告と対処をお願いしています。

まぁ、国内からはそんなに多くないですし、大体は、DNSに登録もないような、ろくでもないアドレスが多いのが実際です。しかし、今さっき来たのは、なかなかに強烈なアドレスからでした。

ssl.kctax.gov.tw

台湾政府じゃん。それも、税務関係の、しかもSSLかなんかのサーブをしているマシン？ そんなところがボット化しているの？ 大丈夫なの？ やばいんじゃないの？

うちのサーバにおいてある掲示板に、頭の悪いスパムが日々たくさんやってくるのです。日本語の投稿と日本語の読者しかいない ^*1 掲示板に、英語や、時に、英語ですらないようなスパムを落としていくのだから、頭が悪いとしか言いようがありません。

おまけにPukiWiki形式での書き込みを受け付けて、通常のHTMLは受け付けないようにしているので、リンクを偽装しようとしているのが、丸見えになってしまっていたりする間抜けっぷりで、もうどうにもなりません。

そんな頭の悪いスパムですから放置しておいても実害はあまりなさそうなんですが、気分が悪いのでこまめに削除しています。削除するのも件数が多いとウザイので、特定のキーワードなどで、そもそも書き込み時点で拒否したり、ボット化が予想される汚染IPからの書き込み自体を拒否するようにしています。

更に、いかにも、スパムですよという、USER_AGENTのアクセスも禁止しています。が、これをやり過ぎて、知人がアクセスできなくなってしまっていました。ただでさえ少ない読者なのに、これはいけません。

で、何が原因だったかというと、USER_AGENTにGTB5という文字列が含まれていると拒否する設定になっていました。一時期、このGTB5が入ったスパム投稿が多かったのです。大体、GTB5って何だかよく判らないし。

GTB5への制限を外すにあたって、その知人に、「GTB5ってナニ？」とおそるおそる尋ねてみました。「確かに、入っているよ。Google ToolBar ver.5が。」とのお言葉 oTL

たはー、Google ToolBar ver.5ですか。つーか、あんた、それブラウザじゃなくて、ブラウザのプラグインでしょ? プラグインの分際で、いちいち、USER_AGENTを書き換えるですか?! 恐るべし。> Google

UNIX時間が、1234567890を迎えるそうです。UNIX時間は1970-01-01 00:00:00 UTCからの経過秒数で表されているのですが、それが、今週、1234567890に到達するんだそうです。UTCで2009-02-13 11:31:30がそれだそうです。日本では、2009-02-14 08:31:30 JSTになります。

perl を使った方法はあちこちに出ていますので、天の邪鬼なワタシは、そうじゃない方法をいくつか。

最後のJavascriptの実行結果はここにも埋めておきます。あなたのブラウザのローカル時間で、いつ、その瞬間が訪れるのかというと……

諸事情により、Webサーバが利用するPHPを4系から5系に替えた。替えたら、XOOPS 2.0.16aで運用していた、ボクの個人ページのトップが色々不具合を生じた。ログインするとフォントがでかくなってしまうというのは些細な問題だったが、ニュースモジュールがおかしくなって、MySQLに、あり得ない負荷をかけるようになってしまった。

そもそも、XOOPS 2.0系は既に開発も停止され、将来的にセキュリティホールが見つかっても修正されるかどうかが限りなく怪しい状態だ。ならばと、長く見て見ぬふりをしてきた、XOOPS Cubeへのアップグレードをしようと、思い立った。

で、やったらば、あれこれおかしくなった。当たり前だが、モジュールの一部に非互換性ゆえの問題が発生。まぁ、動かないものは外していけばいいやと、気楽にやったのだが、piCalや、XP-Weatherがうまく動かないのはちょっと寂しかった。ヘッドラインモジュールも動かないので、外した。そして、何より問題だったのは、bwikiが動かなくなってしまったこと。

ほとんど内容のない、トップページあって、唯一意味があったのが、このbwikiに書きためた、あれこれなのだ。bwikiは既に、開発は停まっているようで、代わりに xpwikiというのがリリースされていた。そして本当に幸いにも、xpwikiはbwikiのコンテンツをまるっとインポート出来るようになっていた。本当は、こういうことをきちんとチェックしてからアップグレード作業をするべきなんだけれど、いつも「何とかなるよ」とやっちゃうので、いつか本当に困ることがあるんじゃないかと、ちょっとドキドキ。

まだ、所々不具合があるのだけれど、致命的ではないのでゆっくりと直していこうと思う。と、いうわけで、あれこれおかしなところもあるかもしれませんが、そういうものだと思って、生暖かい目で見ていただけると幸いです。

すっかり、Mediatombで快適なマルチメディア生活をしているのですが、一点困ったことがあります。我が家のサーバには、Exact Audio Copy + LAMEでエンコードされたオーディオファイルが蓄積されています。Windows上でリッピングされているので、ID3TAGは当然、Shift JIS (CP932)になっています。

iTunes用に、mt-daapdで公開している分には問題ないのですが、mediatomb.ccから持ち込んだパッケージを使うと、CP932でエンコードされていると指定しても、機能しないのです。

結論から言うと、リンクされているlibtag1が、CP932を理解しないからで、これを libid3を利用するようにするだけで、問題はすっかり解消します。やれ、UTF16でエンコードし直せとか、そんな話もありましたが、面倒すぎてやっていられませんからね。

apt-getでソースを取り込むと、 ^*1 mediatomb-0.11.1/debian というディレクトリが出来ます。rulesというファイルの中で、configureへ渡すオプションが列挙してある場所がありますから、taglibとid3libのスイッチを逆にします。

このまま、リビルドしてもいいのですが、apt-getでアップデートかけると上書きされてしまいますので、debian/filesとdebian/changelog, debian/controlを変更して、1etch1というシリアル番号を 2etch1とかにしてやります。

あとは、dpkg-buildpackage -rfakeroot として、パッケージを作り直してやるだけでオッケーです。これで、CP932のタグを正しく処理できる Mediatombができあがります。

テレビをHD化したら、俄然、色々やる気が出てきた。我が家では、グラタンをメディアサーバ兼メディアバックアップ箱として使っている。これまでは、vrd2/vrdRubyを使って、RDの録画情報を、PCへと渡す中継役兼バックアップやら、デジカメ写真のバックアップ、リッピングしてMP3化した音楽データをためて、mt-daapdを使って、家庭内にiTunes経由で音楽を提供したりしていたのだけれど、ソコ止まり。

知人から、Mediatomb使えば、PS3で動画を見られるからいいよー、と奨められていたものの、20インチのSD液晶テレビにつながったPS3でわざわざ動画をみる気分にもなれず、放置状態。

しかし、急にもったいない気がしてきたので、一念発起して、Mediatombを設定することに!! と、いっても、やったのは、apt経由でソースを取り込んでビルド→インストールと、わずかな設定作業だけ。あっという間に、PS3でビデオも音楽も写真も見られるようになりました。

どうも、長らく放置してあった、Nucleusをつつかれたのが原因のようです。> スパム
直近に、Nucleusのxmlrpcインターフェイスである、server.phpへの不可解なPOSTがいくつか記録されていました。おそらく、これが、トリガーとなって、大量のスパム生成に至ったのでしょう。

とりあえず、Nucleusのブログを削除することも考えたのですが、一時期のサーバに関するあれこれが書き綴られているので、ちょっと勿体ない気もしたので、とりあえず、バージョンアップをしておきました。同時に、不正アクセス元は、アク禁にしておきました。さて、どうなりますか。

必要に迫られて、特定のアカウントのメールの送信制限をかけることになった。具体的には、特定のユーザに関して、ドメイン外へのメール送信を禁止したいのだ。

postfixのマニュアルやら、サイトやらを参照すると、restricted_sendersとlocal_domainsいうマッピングファイルを作って ^*1 、smtpd_sender_restrictions ^*2 とsmtpd_restriction_classesを書き換えることで、制限できると書いてある。

以上のようなファイルを作ったら、MAPを更新して、postfixをreloadしてやる。

と、これで、一応の制限は実現される。が、この制限には抜け道がある。そして、その抜け道こそが、問題なのだ。

一般的に、電子メールの送信は、SMTPを使って行なわれる。これはユーザエンドのMUAからでも大体同じだ。MUAはメールサーバに対して、SMTP接続を開いて、メールを送る。postfixではsmtpdがこれを受け取り、上記のチェックなどをした後に、pickupというデーモンへと処理を引き継ぐ。

ところが、メールサーバ上で動作しているMUAや、デーモンなどがメールを送り出すときには、事情が違ってくることがある。直接、pickupデーモンにメールを渡してしまうことがあるのだ。sendmailを直接叩いたり、/bin/mailを使ったりする場合、また、Wanderlustなどもどうやら、SMTPを使わずに直接pickupへとメールを送り込むようだ。

こういった場合には、最初のチェックが全て抜け落ちてしまうので、折角かけた送信先制限が全く生きないことになってしまう。ほとんどの場合、最初のsmtpdが行なうのはリレーチェックなどなので、ローカルのアカウントがメールを出す場合にそれらのチェックをバイパスされても困らないが、メールの宛先制限をしたい場合には、困ってしまう。

幸いに、うちの場合は、AMAVISによるウィルス/スパムチェックをしているので、pickupデーモンから、メールはAMAVISに渡され、そして、別ポートで待ち受けているsmtpdへと戻され、cleanupデーモンへと流れていく。

この、AMAVISからの戻り待ちのsmtpdに、同様のチェックを行なわせれば、ローカルのユーザからの直接送信にも制限をかけることが出来る。これらの制限は、master.cfに書き込むのだが、master.cfに書くときには、ルールの記述に空白を持たせることが出来ない。出来ないので、ユーザ定義のルールを main.cfに作って、その名前を渡すことで、これを代替することが出来る。

これで、あらゆるケースに対して、送信先の制限をかけることが出来るようになる。

いや、復旧作業は済んでいたのですが、腸ぶちまけた状態で、机の上に置きっぱなしで、出張に行っていたので、とりあえず、中身を戻して、ふたを閉めて、所定の場所に戻しました。これでちょっと一安心。

新しいサーバに入れ替えて、4ヶ月ほどになろうとしています。巷では「非力」のレッテルを貼られているAtomですが、動画をごりごり再生するとか、ゲームをごりごりプレイしまくるとか、Vistaを走らせるとか、そういう用途でなければ、快適なのです。そもそも、非力さの大部分は、貧相なGPUしか与えられていないことと、大抵の場合、メモリ搭載量が、512MB-1GB程度と小さいことに起因します。

なので、2GBのメモリを実装し、ディスプレイをつないでいないので、グラフィック性能なんてどうでもいい、サーバ用途であれば、問題点のほとんどは消滅なのです。

そんな、快適な、サーバにも、時折、試練が訪れます。大半は、ブログへの、スパムです。スパムコメント、スパムトラックバック、といったものが、大挙して襲ってくるのです。排除は、二段構えで、ブラックリストに載っているIPやドメインからのアクセスは、apache自身が排除します。が、これを漏れたモノが、MovableTypeのフィルタによって捨てられます。

この、二段目のチェックは、CGIを起動するので、大量にやられると、やはり、CPUのロードが上がってしまいます。こんな具合に、ぐんぐんと負荷が上昇してしまいます。この時は、ゴミトラックバックでした。> 元凶

まぁ、旧サーバの時は、これが始まると、あっという間にロードも100を超えて、何も出来なくなってしまったのですが、今は、そこまで上昇することも希になっているので、ほぼ問題ないと言っていいのですが、結局は捨て去られるだけのゴミのために、無駄にリソースを喰われるのは面白くないので、なんとかならないかなー、と思う、今日この頃なのです。

プリンタを新調したのは、随分前のこと。Windows VISTAへのエプソンのやる気のない対応に腹を立てて、それまでずっとEPSONでサービスサービス ^*1 だったのに、PM-980Cを知人に無償で差し上げて、キヤノンMP-960に乗り替えたわけです。

以前のキヤノンのプリンタと言えば、写真画質で、ややエプソンに劣るし、やたらと出力がビビッドで不自然な臭いがする感じだったのですが、すっかりそのあたりは変っていて、今ではもうすっかりキヤノンのプリンタのファンです。エプソンなんて屁ですよ、屁。 ^*2

で、乗り替えて、不満はほとんどなく使っていたのですが、唯一と言っても言い不満が、Linuxからの印刷ができない、という点だったのです。何しろ、キヤノンは何故か、MP-960のLinux用のドライバを公開してくれないのです。MP-510/610用なんて言うのがあったので、印刷してみても、めためたな結果になってしまって、その後放置状態だったのです。が、昨日、不意に、やる気が出て、解決に向けて動いてみたのです。

どうやら、型番の類似性よりも、インクの色数の方が重要らしいです。MP-960はCMYKの四色に、PM/PCのフォトカラー二色、それに顔料黒を加えた七色編成。これと同じ編成で、サポートされているのが iP7500になります。

わい。それじゃあiP7500のドライバをインストールすればいいんだ、と、Linux版のRPMパッケージを持ってきたら、思いっきり、パッケージの依存関係で蹴られました。ダメです、パッケージが古すぎます。ソースパッケージも同じ理由で再構築できません。

仕方がないので、ニコイチです。最新版のV2.90というドライバーのソースパッケージと、iP7500の入っているV2.6のドライバーのソースパッケージを持ってきて、ppd/canonip7500.ppd と、266 以下のファイルを全部まるっとV2.9側へコピーします。あとは、V2.90に iP7500のドライバもビルドされるように、SPECファイルと、configure.inのいくつかを書き換えて、リビルドしてやります。と、恐ろしいくらいにあっさり、パッケージができました。

おそるおそる、印刷もしてみると、テストページが、色も文字もずれることなくばっちりと、印刷されて出て参りました。PM960なのに、CUPS上では iP7500-Ver2.60とか表示されてしまうのが難点ですが、ヨシとします。

勿論、こんなの、メーカが保証している使い方でも何でもないので、やってみようと思う方は自己責任でどうぞ。どんだけの差分を当てたかが気になる人は、続きをご覧ください↓

さっき、ウィルスデータベースを更新してから、トライしてみたら、問題のファイルに含まれていた、トロイの木馬を、がっつりと検出できるようになっていました。

クライアントたるWindowsPCには、勿論、ウィルスバスターやら、AVG Freeやらを入れて、ウィルス対策をしています。が、メールを蓄積する自宅サーバにも、ClamAVを導入して、メールのスキャンなどをするようにしてあります。Vine Linux のパッケージは 0.93.4が最新版なのですが、「もう古いから新しいのにしろよ」と警告されるので、最新の安定版0.94に入れ替えました。

入れ替えて、まずは、データベースの更新をしなければ、と、freshclamという更新用のコマンドを実行します。すると、あろうことか、「データベース、存在しないからー」とか言われてしまいました oTL

結局、暫く待ってから、もう一度更新にいったら、今度はきちんと更新されました。なんだよ、まだ、準備もできてないうちから、「古いから新しくしろー」とかいっていたのか? (^^;

早速、新しくなった ClamAVで、巷で最近流行っている「オンラインで航空券買ってくれてどうもありがとー」という巫山戯たメールに付いてくる、トロイの木馬だと言われているファイルをスキャンしてみました。ZIPファイルで添付されていて、展開すると、"e_Ticket304.doc.exe"という、いかにも、ドキュメント風に見せかけたい気分全開のファイルが出てきます。

素通しでした oTL まぁ、このメール自体は、SpamAssassinによって、スパム認定されて、ゴミ箱送りになるし、万一開こうとしても、PC側で検出されるはずですが、ちょっとがっかり(^^;; だからこそ、防壁を多重化する意味があると言うことでもあるのですが。

自宅のネットワークには、メインのサーバを中心に、NAS箱やら、何やら、色々ぶら下がっています。これらを、手抜き管理するために、様々なツール ^*1 を動かしているわけですが、そんな中の一つが、MRTG。SNMPを利用して、マシンのリソース利用状況などをビジュアル化してくれるツールです。

基本的に、大した仕事をしている訳ではない、NAS群は、定期的なバックアップなどのジョブに合わせて、ネットワークの利用や、CPUの使用率が上昇するのです。が、これが、時折乱れるのです。

先日は、NAS箱の一つに、リプル状のネットワーク使用率の変化が現れました。調べてみたら、NTPで、時間を合わせようとして失敗し続けていた様子。失敗の原因は、サーバを更新したときに、NTPの設定関係を直すのを忘れていたからでした。

また、今日、CPUの使用率が100%になったままになっていました。調べると、バックアップ準備のために、不要となる古い世代のバックアップを削除するジョブが、何やら、刺さったようになっていて、CPUを食いつぶし続けていた上に、バックアップに失敗もしていたという、結構ヤバげな問題を生じていました。

こうして、モニタリングしていることで、間接的にマシンの挙動不審を見つけ、問題を早期に解決することができるのを、改めて実感し、その重要性を再確認しました。

どうにか、新サーバでの運用が 軌道に乗りました。我が家のサーバの歴史は、mobioNXの液晶が割れてしまったことに端を発しています。液晶が死んでしまったモノの、他はすべて生きているこのマシンの第二の人生として、サーバ化が行なわれたのでした。

P54C(MMX Pentium) 200MHz/96MB/4GBという構成で、VineLinux 2.1で始まったサーバは、EPIA-M6000で C3 600MHz/512MB/80GBになり、このマザーのコンデンサ抜けを受けて、EPIA-M8000Eで C3 800MHz/1GB/80GBという構成に、プチアップグレードがなされたものの、長らく、ソフトウェア環境を引き継ぎ続けてやって来ました。

昨今の、サービスの重厚長大化に伴い、非力感が漂いまくっていたので、VIA Nanoを待って、アップグレードしようと思っていたらインテルからATOM 230Dを搭載した、D945GCLFが発売され、ギガバイトからもGA-GC230Dが売り出される、廉価MiniITXシステムが急速に花開きまして、気づくと、D945GCLFを買っていました。いえ、サーバで動かし続けることを考えると、本当は、すべて固体コンデンサというGA-GC230Dが魅力的だったのですが、単に、在庫があったのがこっちだったという理由で、インテル純正品を選ぶことになりました。

メモリはDDR2 667 2GBで、HDDは当初、現行サーバから流用の予定でしたが、HDDが消耗品であること、80GBと小さいこと、ここらで、過去の澱を捨てて、新しい環境を構築し直すべきかもしれない、等々を勘案した結果、WD5000AACS というSATAIIのHDDを買っていました。

一応のサーバ環境の構築に1日。ホームディレクトリなどの引っ越しに1日。最後に、トラブルシューティングで1日、と都合3日かけて引っ越しました。まだまだ、細かな修正すべき点はあるのですが、とりあえず、一段落です。

買い換えることを決意させた、性能問題ですが、シングルパイプ-単一実行の、インストラクションだけi686風にしただけ(しかも一部命令が実装されていないので、時々問題を起こす)のナンチャッテi686互換だったC3に比べて、パイプラインやらレジスタファイルやらを、二重化して、ほとんどデュアルCPUじゃないのというくらいに、SMT強化を図ってきたATOMとではクロックの差以上の性能差が期待されます。更に、メモリも2GBにしたことでスワップの必要性がかなり薄くなっていますし、HDDもSATAII でATA100に比べてかなり高速化していますので、様々に強化されました。これがおよそ二万円。そんで推定三倍以上の性能。赤く塗って角立てたいくらいに、いや、ザクとは違うのだよ...と口走りたいくらいに、パワフルになりました(^^)/

気づくと一週間も間が開いてしまいましたが、皆さんお元気ですか？　なんだか、カウンターが出てなかったり、おかしなところが多々見受けられると思いますが、サーバを移行しているのです。

長く使った、VIA C3ベースのサーバシステムは、流石に、時代の流れから大きく取り残され...簡単に言うと遅かったんです。特に、MovableType関連が。アホな奴が、どかどかとスパムを投げ込んでくれたりすると、身動きが取れなくなってしまうのでした。

そんな中、先頃から販売されるようになった、Intel ATOM 230ベースのシステム。1.6GHz/4Wの省電力。P4よりも進化して使い物になりそうなにおいがする、Hyper Threding。2GBまでのメモリをサポートしたIntel 945GCチップセット。そして、これらを詰め込んだ一万円未満のMiniITXマザー。

気づくと、D945GCLFを買っていました。はい、買いました。勿論、メモリも買いました。DDR2 667 2GB(勿論バルク)。HDDは最初、現行のサーバから引っこ抜こうかと思いましたが、長く使ったモノでもありますし、今時 80GBというのも小さいかと思いまして、これも買いました。WD5000AACS SATAIIです。締めて二万円ほどです。

で、Vine Linux 2.1.5あたりから、脈々と引き継ぎ続けてきた環境を、まっさらに、4.2を導入し直して、データの移行をすることにしたのです。まぁ、これが手間取ること手間取ること。昨夜も三時就寝ですよ、ははは。

と、いったようなわけで、暫くあちこちおかしな状態が続くかと思いますが、平にご容赦ください。ちなみに、ATOMはC3 800MHzの1600bogomips ^*1 に対して、3200bogomips x 2です。P4のような、命令レベルのマルチスレッドではなく、もっと、デュアルCPU的なSMTの実装になっているので、きっと、4バイトまでは行かなくても、3倍くらいは速いはずです。赤く塗って角を立てたくなるくらいには速くなったはずです。まだチューニング中ですが...。

うちの、サーバは、はっきりいって非力だ。いずれは増強を考えてはいるものの、先立つものがないので、とりあえずは、様子見なのである。次買うなら、C7で、メモリが4GBくらい積める奴を買いたい。って、あくまでもMini-ITXで行く気は満々なのだけれど。

非力なサーバに思いっきり負荷をかけてくれる存在が、各種のスパムだ。メールもそうだが、ブログや掲示板へのスパムはすさまじいものがある。特に、MovableType 4になってから、サーバに対する要求の厳しい、ブログへの各種スパムの存在は深刻だ。

基本的に、MovableType自身の持つフィルタは大変に優秀で、腐れスパムが掲載されることはないのだが、こいつらが起動するCGIによる負荷が、時に、サーバーのロードアベレージを50〜100という考えられない水準まで持ち上げてくれる。xloadなんて動かしていたら、ロードアベレージ1ごとに引かれる線で真っ黒に塗りつぶされた、ただの黒い箱が表示されるだけだ。

いくらゴミは自動的にゴミ箱に行くとはいえ、これは不快だし、数少ない来訪者の皆さんが、このタイミングでおいでになったときに、どうにもならないレスポンスの悪さに、嫌気がさしてしまうかも知れない。これはいけない!!

となれば、CGIを蹴られる前に、こちらが蹴落とすしかない。と、いうわけで、数日分のアクセスログがから、あからさまにおかしなアクセスを探し出した。そして、.htaccessに、片っ端から列挙して、アク禁にしてやった。まぁ、全く何も出来ないわけではなく、CGIを蹴れないようにしてあるだけなのだが。

すると、面白い挙動を示すスパマーがいた。上のリストに追加された奴は、403 (Forbidden)になるのだが、すると、User Agentの文字列を次々と変えてリトライしている奴がいるのだ。確かに、ボクのところでも特定のUAに対して制限をかけているが、多くのところで、やはりそういうことをしているのだろう。残念ながら、そのアホは、UAによる拒否ではないので何をやっても撃墜なのだが。しばらくこれを繰り返せば、いくらかは、ましになるのではないかと期待している。

Vine Linux 4.2上で、日々のメインテナンス作業。
apt-get update & upgradeで、システムを最新に、セキュアに保ちます。今日も、いつも通りに……ん？

壊れては、新調し、と、2699(Procease)を使い続けてきましたが、電源モジュールが2年と持たないので、見切りをつけることに。Noah 800B Rev 1.5というケースにしました。厚みは、2699に比べて増えていますが、その分、縦起きしたときの高さは減っています。容積はほとんど変わらない感じですかね。3.5インチのドライブを内蔵できるし、非常にイイ感じです。

写真は、サーバルーム ^*1 に設置した状態。LEDは明るいですが、普段は扉を閉めてしまうので、全く問題なし(^^)。

朝、気づくとサーバーが死んでいた(/_T)
昨夜は生きていた。ネットワークは生きているし、一緒においてある、ルータも、NASたちも生きている。リモートからのリセット操作にも反応しない。デイリーバックアップが走った形跡がないので、未明に走らせるそれよりも前に死んだようだ。

帰ってきてみると、電源のインジケータが煌煌と光っているだけで、うんともすんとも言わない。電源を再投入しても、インジケータが光るだけ。いよいよ、マザーが死んだか？EPIA SN10000GEあたりに乗換えか？なんて、思いつつも、別の電源ユニットを持ってきて、つないでみたら、あっさりと動いた oTL

要するに、EPIAでサーバを運用はじめて、四度目の電源頓死というわけ。Mini-ITX用のスリムケースを使っているのだけれど、コレだけ頻繁に死ぬとなると、次は違うモデルにしようかなという気分になってくる。

年末に Vine Linuxが 4.2へとマイナーバージョンアップしました。あとで、アップグレードしようと、放置していたら、先日、カーネルの更新の際に、幾つかのパッケージが4.1のものじゃあダメと怒られました。

なので、えいやっと、4.2へのアップグレード ^*1 をかけました。アップグレードそれ自体はサクサクと完了しましたが、あおりを食らって、amavis-newが動かなくなりました oTL

CPANパッケージの欠損など、色々起こりまして、これらを全部片付けて、更に、amavis-new自身をアップデートする必要がありました。ついでに(?)、SpamAssassinも更新して、 ^*2 すっきり。だけど、なんだかスパムの透過率が若干上がってしまったような気がする...何故だ?!

UNIX MAGAZINE Classic with DVD
(DVD4枚付)

posted with amazlet on 07.10.03

アスキー書籍編集部
アスキー (2007/09/18)
売り上げランキング: 264

Amazon.co.jp で詳細を見る

UNIX Magazineといえば、ディープなUNIX周辺の情報を掲載し続けた、大変、コユイ雑誌でした。20年続いたそれも、昨今のIT系雑誌受難の時代についに休刊。再出発して、今出ている同名の季刊誌は、中身も装丁も大変軽い、薄っぺらい雑誌になってしまっていて、角川色の強い全くの別物になってしまって、大変に残念に思っていました。

何しろ、ユニマガは、とりあえず、買って寝かしておけ−という感じで、掲載時では意味不明だったり、どう活用したらいいかピンと来なかった記事でも、寝かしておくうちに、ある日役立つときが来るというような、そんな雑誌だったのです。まぁ、濃すぎて、ゆえにこの時代に生き残れなかったのでしょうけれども。こういう濃い技術誌がほとんどなくなってしまったのは、この国のIT産業の将来を考えると大変に不安でもあります。今は、SoftwareDesignとかInterface, トラ技などが細々と頑張っていますが。

新しく、歴史を刻み続けることはなくなってしまいましたが、しかし、創刊号から最終号までに掲載された記事の99%を電子化して収録した、このUNIX Magazine Classic が、先月目出度く発売となりました。これは、ユニマガの良質な記事を現在の、そして将来のプログラマ、エンジニアに伝える最高のアーカイブだと思います。ユニマガはとりあえず買って寝かしておけ、なのです。いつの日か、この中に収録された記事が役立つかもしれません。また既に、美味しくいただける時期が到来しているかもしれません。IT技術者必携の一冊だと強くお奨めします。

ただ、唯一の難点が、「価格」なんですよね。18,900円。アマゾンでも18,000円弱。個人で買うのが難しい場合は、職場や研究室やなんか、こううまいこと予算を分捕って、一冊、装備してもらえればいいんじゃないかなーと思います。

SCO、連邦破産法第11章の適用を申請

　SCO Groupが連邦破産法第11章の適用による破産保護手続きを申請した。Linux陣営に対する訴訟で注目を集めてから3年半が経過した。

逝きました、はい。訴訟をふっかけるというFUD ^*1 を武器に、本来必要でない契約を Linux導入企業などから毟り取っていたSCOビジネスモデルは、「お前にその権利は存在していない。」という判決で崩壊。結局、訴訟を維持するどころか、自社も維持できなくなりましたとさ。こういう企業は早々に退場していただくのがやはりよいと思います。

お金はない。お金はないが、この状況はどうにかしなければならない。何故なら、これではサーバが使い物にならないのだから。さて、ではどうしたらいいだろう？ソフト的なチューニングも限度がある。何しろ、何かしようにも、メモリが足りなのだから。

ん？メモリがない。利用しているのは swap とあわせて、933576KB...なんだ、つまり、1GBあれば、メモリがあふれずに、swapへの退避がなくなるわけだ。これって性能向上に一役買わない？

ということで、懐具合と相談しながらヨドバシへ。ヨドバシドットコムでは、BUFFALOのDDR333-1GBが 9,770円で出ていた。DDR2ならもっと安いのに、旧式の、DDR266のメモリを要求する我が家のサーバには使えない。今後、DDRなんていう退役メモリが廉価になるとも思えないので、ここで購入するつもりでいた。が、店頭には、11,800円のつれない表示。1,000円程度の違いなので、実は大騒ぎするほどのこともないのだが、10,000円をまたいでいるので、その差は実際以上に大きく感じる。ダメもとで店員に聞いてみたら、あっさり「その値段でお出ししますよ。」と、値下げに応じてくれた。

というわけで、散髪によって ^*1 、家に帰って、夕食をとったら、早速入れ替え作業を。

うちのサーバは、ぶっちゃけ、パワフルではありません。VIA C3 800MHzという貧相なCPUで運用しています。なので、MT-4になったら、もう、重くて重くてたまりません。あんまり重いから、思い切って、mod_perl化してみようかと思い立ちました。え、今までしてなかったのかって？していませんでした。まぁ、そこは permission管理の関係とか色々思惑があるわけですよ。perlを直接キックするのは確かに遅いんですけれど、MT-3くらいまでは我慢も出来ていたんですよ。

で、やってみたんですが、結論から言えば、やるんじゃなかった oTL
まず、遅いのは、本質的にサーバが遅いからなんです。perlを起動するのが遅いとか、Apacheの呼び出しが遅いとかそういう問題じゃないんです。なので、mod_perl化しても、少しも早くならないどころか、多分、mod_perlによって肥大化したhttpdによるメモリ圧迫によるものなのか、全体的に耐えがたいくらい遅くなることが発覚。しかも、肝心のブログの更新も、途中でタイムアウトしてしまう程の酷さ...。結局元に戻しました。遅いけれど、それでもきちんと動きますので。サーバの高速化が唯一のソリューションのようです。

以前、CASIOのFIVA (MPC-206)を使っていた頃は、プレインストールのWindows98は使わず、VineLinux 2.6で運用していた。longrunも使って、それなりに便利に使っていた。FIVAが他のCrusoeマシン同様に、CPUの半田不良により動かなくなり、VAIO PCG-U101に買い換えてからこっち、デスクトップは、逆らわずに Windowsを使い続けている。U101ではXPを、そしてTypeGではVistaを使っている。

なので、X関係の環境は、Vine 2.6の頃のものが脈々と、修正もされないまま、自宅のサーバ上に残り続けていた。 ^*1 なにしろ、サーバはディスプレイなど繋がっていないので、Xの環境など整備する必要がなかったからだ。というよりXサーバに至ってはインストールすらされていない。

それが、最近、Software Designの記事に触発されて、RealVNCをインストールしたために、再整備を余儀なくされた。ウィンドウマネージャはqvwmから、metacity (+gnome_panel)に、漢字入力はAnthy+SCIMに、といった具合だ。

まぁ、最近の環境設定は、設定用のお気楽ダイアログが出てくるのがほとんどで、ちょいちょいなんだけれど、長らく、単語登録が出来ないで困っていた。 ^*2

が、最近、ちょっと、VNC上の環境で、日本語入力する機会が増えてきたので、AnthyのキーバインドをVJE風に直したりしているうちに、単語登録には「霞」というツールが必要なことがわかった。 ^*3 判ってしまえば、

自宅のサーバは、FIVAを買ったときに、退役した、液晶の割れたmobioNX上に構築された Vine 2.1の環境を、脈々と、新しいバージョンになる度に、アップグレードし続けてきたものだ。途中でサーバは、EPIAベースのマシンに変わったが、OSのイメージは、パッケージはmobioNXからそのまま引き継いだものだ。なので、きっとはじめからVine 4.1をインストールしたときには当然の様に入っているであろう、こういった基本的なツールが抜け落ちていたりするところがなんともいえない(^^;;

WildTreeドメインを取得する前に、一時期、フリーのDynamicDNSサービスを利用して、ここのサーバは運用していました。そのドメインは今でもキープし続けているのですが、無料ドメインのユーザは、ライブドア検索ツールを設置するようにということになりました。大分前のことですが。

WildTreeドメインは、正規に取得したドメインですので、そこに、用もないライブドア検索ツールなど置きたくありませんから、以前は同一のページを表示していた、フリードメインの方を、VirtualHost機能を利用して、別ページが出るようにして、そこに、ライブドア検索ツールを設置しました。

が、今日になって、突然「設置済みでない」という警告メールが、管理元より来ました。はて、と思って、アクセスしてみると、VirtualHostが全く効いてない状態に...?!

休みなので、時間が取れないと出来ないことをば……と、昨日から、メインサーバのOSをVine 3.2から、4.0へと入れ替えようと……したのが、どつぼの始まりでした。

大変長い間おかしな状態にサーバがありましたが、概ね回復しました。長かった……oTL
不調でアクセスできない間においでいただいた皆様、ご迷惑をおかけしました。

PS3にFedora Core 6を入れてみた。フルインストールすると10GBのディスク領域にあまりはほとんどなくなるので要注意。そしてなにより要注意なのは、PS3用のカーネルは2.6.16ベースなので、FC6のパッケージ群と食い合わせが劇悪だ。おとなしく FC5にするべきだったかとちと後悔している。

Xも、D1しかないうちのSD AQUOSでは、きちんと立ち上がらない。どうも480pを要求している感じ。480iになってくれないとD1の環境では使えませぬ oTL
コンソールはちゃんと480iで動いているんですけれどね。

ネットワークは、無理やり /sbin/dhclient を起動すれば、DHCPDを見つけて、使えるようになります。eth0が見えているのに、ifup-eth0などが存在していないのが微妙に気になりますが。FC6が使えるようになるには、まだ少しかかりそうですね...勇み足だった... oTL

カーネル2.6.18.2がリリースされています。持ってくるだけ持ってきて置いて、ビルドするの忘れていました。現在、GLANTANK用ビルド中。今回から、別配布で、制限つきAS ISのbtndrvとbuttondを出そうと思っています。リクエストがありましたので。制限等については別途配布ページにて。

いつも程度の動作実績で、いつも程度のカンジで、GLANTANK用のlinux-2.6.18.1カーネルのイメージとパッチを公開しておきます。ご入用の方は、ご自由にどうぞ。

細々とではありますが、ダウンロードしてくださっている方がいらっしゃるようなので、使ってもらえているんだろうなぁと思いながら、ビルドしております。お役に立っていますか？立っていれば嬉しい限りです。

間が空いた分、修正点がてんこ盛りの 2.6.18.1 がリリースされています。昨日、気づいていたのですが、OpenPNEを玩ぶのに夢中で、すっかり放置してしまいました。現在、グラタン用をビルド中です。

今頃気づいたのだけれど、2.6.18のカーネルは、IOP321と80219の区別が付くようになっている。ちょっと驚いた(^^;
そういえば、そんなことが修正点に書いてあった気もする。

何とか、動くカーネルが出来ました。カーネルイメージ、パッチともに用意できています。細かい、実装上の変更があれこれあって、パッチの修正に思ったよりも手間取りました。

このパッチはIOPを下敷きに、グラタン用の修正を入れてあるのですが、グラタンとは無関係のパッチも混在していました。2.6.17になったときに、それでもずいぶん整理したのですが、まだ、いくつか残っていたので、とりあえず、無関係なファイルは排除しました。

マイナーアップグレードがありました。2.6.17系へのパッチは終了し、2.6.18へのマイナーバージョンアップです。グラタン用はこれから四苦八苦します(^^;;

思った以上に軽快に使うことができる、Vine on VMWare Playerですが、大きな問題がありました。それは、時計が狂いまくるということです。

Linux ^*1 では、時刻は、起動時にRTC ^*2 から取得したら、あとは、カーネルが刻みつづけます。エミュレータ上ではこのタイミングが正確ではないのですね。なので、NTP ^*3 などで頻繁に同期をとりつづける必要があります。でないと、時刻がどんどん遅れていってしまうのです。むぅ。

持ち歩いているノートPCも、メインのデスクトップもクライアント環境はWindowsをホストOSとして使っています。サーバは、メインのものがVine 3.2で、玄箱とグラタンがdebianで運用されています。さて、メインのサーバのVineは、近々4.0になるので、その評価と、入れ換え準備をしようと、メインのデスクトップ上のVirtual PC 2004 と、ノートPC上の VMWare Playerに、それぞれ、Vine 4.0β1 ^*1 を導入してみました。

Athlon64 3500+のメインデスクトップは当然としても、Celeron 600AMHz(Banias)のノートPCでも、かなり使いものになるパフォーマンスが出ていて、びっくりしています。このまま、メインの生活環境にしてもいいかなあと思えるくらい ^*2 。FIVA MPC206でVineを生活環境として使っていたころを思い出します。

例によって、パッチとカーネルイメージを置いておきます。ご自由にご利用ください。
とりあえず、ほぼ二日、動き続けています。パッチをまとめたり、vrdを使って、RDからファイルを転送し、転送されたファイルを、WindowsXP上のTMPGEncから参照して動画ファイルを処理したりしてもびくともしなかったのでそれなりに安定していると思います。

Linux 2.6.17.13がリリースされています。11の寿命はやや長かったですが、多岐に渡る修正を含んだ12がでていることに気づいたときには13が存在していました。とりあえず、例によって、グラタン用はビルド中です。

GLANTANK用のカーネルイメージとパッチまとめました。いつもの如く、ブートして、このイメージとパッチとを纏め上げるくらいの間は問題なく動いています。

それにしても、あまりにちょこまかとカーネルのアップデートが行なわれるので、動作実績が中々二週間を超えていきません。まぁ、そんな状態ですが、修正点に鑑みて必要だと思われる方はどうぞ。

Linux 2.6.17.11がリリースされています。RAID1周りをはじめ、多岐にわたる修正が入っていますので、流石にこれはビルドしなおすべきでしょうね、とほほ。

Linux 2.6.17.10がリリースされています。修正点は、ブロックデバイスモジュールのアンロード時の問題と、UDFの問題、および、SCTPの権限昇格問題です。SCTPの権限昇格問題が若干気にはなりますが、どのくらいの人が使っているんでしょう？とりあえず、今回も、グラタン用のビルドは見送ろうかと思っています。

Linux 2.6.17.9がリリースされています。が、今回は、グラタン用のカーネルの構築は見送ります。修正点が、PPC970に関する一点のみだからです。Xscaleのグラタンでは2.6.17.8と同じだということです。

どうしても、最新版を追いかけたい方は、2.6.17.8用のパッチを適用して、Makefileの4行目を、次のように修正してからビルドすればいいでしょう。

スパムフィルター、SpamAssassinの3.1系のメインテナンスリリースがいつの間にか ^*1 ありました。3.1.4になっています。うちのサーバのものも入れ替えました。CPANからの入手も可能。

GLANTANK用の2.6.17.8カーネルイメージとパッチ、ついでに、fandrvの2.6.17.8対応版を公開しました。とりあえず、ブートしてカーネルイメージとパッチをまとめるくらいの間は問題なく稼動しています。

Linux-2.6.17系の最新版、2.6.17.8がリリースされています。修正点は相変わらず多いです。/proc/<pid> のファイルのchmod()を無効化するなどのセキュリティ強化も含まれています。グラタン用は、例によってビルド中です。

SVR4 ^*1 以降のシステムは、大抵非同期IO(AIO ^*2 )を持っています。本来ブロックするread/writeなどのIOをブロックせずに行ない、後で結果を受け取ることが出来る、使い方によっては便利なものです。

ところが、多分ユーザがあまりいないからなのか ^*3 、GNU libc2.3.2/2.3.3に含まれているAIOライブラリは、微妙に動作が仕様と異なっていて困ります。

グラタン用のカーネルイメージとパッチ(とfandrv)をいつものように公開しました。とりあえず、ブートアップして数時間は動き続け、かつ、パッチやカーネルイメージをまとめて、ウェブサーバにそれを置くくらいのことまでは出来ています。ブート時にエラーもありませんので、多分、問題はないでしょう。とはいえ、完全無保証ですのでよしなにお願いします。

週刊化しつつある、Linux 2.6系カーネルの最新版です。幾つかの重要な修正を含んでいますので、アップデートが推奨されます。んが、どうも、このところ修正の修正が多いような気がしてなりません。修正に伴ってエンバグされているというか。テスト体制に問題があるのやもしれません。

グラタン用のカーネルは現在ビルド中です ^*1 。動作確認できたら、公開します。お急ぎの方は、2.6.17.6用のパッチを適用して、Makefileの枝番を.7から.7-glantankに変えて、リビルドしてください。当方で、やっていることは正にソレですので。

Have you aimed for mainline inclusion or are you happy if we take your code and modify it in a way that it can be included in kernel.org?

Martin Michimayrという人から、「Debian official installerをグラタンに移植するんだけど、カーネルがいるんだよ。パッチを使ってもいいカイ？　ぃゃ、むしろ、kernel.org送りにしちゃってもイイかい？」……っつーメールが来た。いや、もう、取り込んじゃってください、是非っ。

しかるべきところに取り込まれれば、ヨクワカッテナイヤツ ^*1 が、勝手にやっているパッチを利用することへの不安も軽減されることでしょう。より多くの人がよりセキュアなカーネルの恩恵に預かれると思うので、大歓迎なのです。

GLANTANK用Linux-2.6.17.6のカーネルパッチとカーネルイメージとを置きました。よしなにどうぞ。
動作状況としては、一応ブートアップして、WindowsXP上のPhotoshop Elementsから写真のバックアップを作成するくらいのことは問題なくこなしました。

Linux-2.6.17.6がリリースされています。2.6.17.5で、/procの脆弱性に関する修正が行なわれており、それに対する不具合の修正が提供されました。グラタン用のカーネルイメージは現在作成中です。

グラタン用の2.6.17.4カーネルイメージとパッチを公開しましたので、よしなに。既述の通り、セキュリティホールの修正ですので、2.6.17.3以前の利用はやめた方がいいと思います。完全に閉じている環境での利用ではあまり問題ないとは思いますが。 ^*1

Linux-2.6.17.4がリリースされています。ローカルユーザが権限を昇格したり権限のないファイルを壊したりすることが出来るセキュリティホールが修正されています。外部向けに運用している人は、早急にアップデートしたほうがいいでしょう。グラタン用のカーネルは現在ビルド中です。動作確認出来次第、パッチとイメージを公開する予定です。

Linux-2.6.17.3がリリースされています。2.6.17.2で大量のバグ修正が入っていますので、2.6.17系を利用しているならバージョンアップした方がいいでしょう。グラタン用のカーネルは現在パッケージングするだけ、になっていますが、遊びに行ったりしていたのでまだ終わっていません。急ぎの方は、2.6.17.1用のパッチ(Makefileだけ失敗しますが)が使えますので、それを使ってリビルドどうぞ。initrdに互換leddrv/buzdrvを仕込んでいる方はそちらも忘れずにリビルドして入れ替えてください。

MovableTypeは3.xになって、コメントやトラックバックに対するスパムフィルターが非常に優秀になりました。ほとんどのスパムは自動的に葬ってくれます。しかし、その優秀なフィルターを持ってしても解決できない問題が、過負荷です。スパムかどうかを判断するのは、外部からMovableTypeのシステムに接続して、データを送ってからになるので、大量のゴミコメントやゴミトラックバックを送りつけられると、システムが過負荷で非常に応答が悪くなってしまうのです。こんなときは、もう少しサーバのパフォーマンスが高いほうがいいのかなぁと感じます。

グラタンのカーネルを持っていって、こちらのsndドライバが動かずに苦労されている方がいらっしゃるようですが、モジュールはカーネルのバージョン(とコンパイラ)に依存しますから、ビルド済みのドライバを持ってきて、楽しようと思っても、それは通りません。根性入れて ^*1 リビルドしてください。

カーネルイメージ(他)、パッチ、およびfandrvを公開しました。
2.6.17からの修正点はほとんどないので、SCTPがらみで、netfilterが無限ループに落ち込んじゃった人、以外は、2.6.17からアップグレードする必要性はほとんどないと思います。

早くも、マイナーアップデートがかかっています。SCTP ^*1 のフィルタリングで、長さ0のチャンクを拾うと無限ループに落ち込んでしまうバグがあったそうです。あんまり大きな影響はなさそうですが。

カーネルイメージ(他)、パッチおよび、fandrvを公開しました。
既に、書いてあるように、RTC(RS5C372A)のドライバは、グラタン由来のものから、2.6.17で統合されたものへと変更しました。ただし、そのままでは動作しなかったので、グラタンで動作するように修正してあります。また、(10,135)の/dev/rtcは利用できなくなります。これが問題となる場合には ^*1 、/dev/MAKEDEVのrtcのエントリを書き換えて、適切なデバイス番号のデバイスファイルを作るか、udevへの移行をお勧めします。

グラタン用にrtc-rs5c372.cを修正して、2.6.17でも正しく時刻が取得できるようになりました。つまりは、修正前のバージョンはやっぱり正しく時刻が読めていなかったということです。ntpdateが速攻で時刻を合わせてしまうので判らなかったんですね。

さて、修正したものの、/dev/rtcは最早、miscデバイスの配下ではなくなっています。これは2.6.17でRTCサブシステムを一新した関係です。このためhwclockが正しく動作しなくなっています。これを回避する正しい解は、恐らくudevに移行することです。sysfsには正しくrtc0のエントリが作成されていますから、udevに移行すればこの問題は解消するはずです。ただし、となると、非udevなデバイスドライバ、例えば、leddrvやbuzdrvをどうにかしないと塩梅悪そうですし、何より、ブートシーケンスに関わる大きな修正をするってことは、また、悪くすれば、分解と修復の繰り返しをしなければならないということで、かなりやる気を出さないといけません。ということで、ちょっと思案のしどころです。

グラタン向けの2.6.17カーネルはとりあえず動き出しました。ただし、若干微妙なところがあるので、公開するにはもう少し時間が必要です。微妙なのは、RTCの扱いです。先に書いたように、RS5C372Aのドライバがカーネルに取り込まれているのですが、同時にRTCデバイスの扱いが大きく変更されていて ^*1 、例えばhwclockが機能しなくなってしまっています。まぁあまり必要性はないのかもしれませんが。 ^*2 また、取り込まれているRS5C372Aのドライバもそのままでは、デバイスの検出が出来ず ^*3 、また、認識するように修正しても、どうも、正しく値を読み出せてないような雰囲気がぷんぷん漂っているのです ^*4 。なので、ココをやっつけるまで保留です。

Linux-2.6.17がリリースされました。2.6.16までにたまりにたまった、山のようなバグがフィックスされまくっているようです。グラタンや玄箱に関係しそうな話としてはRS5C372のドライバが取り込まれています。パッチの数から見ても、安定版的な色合いが強そうなリリースですので、追随すべきなんでしょうね。……ということで、グラタンのカーネルのビルドをしてみています。果たしてうまいことブートしてくれるのでしょうか……?

掲題のバージョンがリリースされたので、GLANTANK用のバイナリとパッチも更新しておきました。ついでに、fandrvは2.6.16.20-glantank用のモジュールを追加したパッケージにしました。

どうも、fandrvの使い方が分からないという方がいらっしゃるようなので、一応簡単に説明しておきます。バイナリを利用するだけなら、makeする必要はありません。カーネルのバージョンとあう、fandrv.koをどこか適当なところにおいて(/lib/modules/2.6.16.19-glantank/ とか)、あとは insmodするだけです。

制御には、既に書いてあるように、/proc/fandrv に 0(停止)か1(運転)を書き込むだけです。fanctldは指定されたHDDの温度をhddtempを利用して定期的に測定、自動的にファンの運転・停止を切り替えます。なお、言わずもがなのことですが、GLANTANKの説明書きには「ファンは停めるな」と書いてあるように、このような運用をして、GLANTANKやHDDがイカれても、それは自己責任に帰する問題であることに留意してご利用ください。誰も保証なんて出来ませんししませんから。

GLANTANK用の2.6.16.19が動きましたので、配布しているパッチやバイナリも更新しておきます。fandrvに関しては、2.6.10-iop1用、2.6.16.18-glantank用および2.6.16.18.19-glantank用を同梱しておきます。(今後どうするかは未定)

プチ・バグフィックスがなされた2.6.16.19がリリースされたので、グラタンでもビルドに挑戦。netfilterから情報漏れを起こす可能性があるという問題の修正だそうです。

我が家のLinux環境に、玄箱とグラタンとがそれぞれDebian GNU/Linux 3.1r2(sarge)ベースのシステムとして加わったので、主サーバの Vine 3.2の旧式っぷりや問題が目に付くようになってきました。枯れているシステムというのはVineのいいところでもあるのですが、時に、新しい便利な機能を取り込みたくなるものです。

無保証・無サポートを決め込むなら、最低限、ハードウェアの仕様くらいは公開して欲しいというのは、おかしい考え方でしょうか？いずれにしても、アイ・オー・データという会社はそういう感覚ではないらしいので、GLANTANKは謎だらけなのです。

それでも、わずかなヒントから、推理し、実装し、試すのは、楽しくないかといわれれば、楽しい部類に入ると答えてしまう私です。でも、そんな楽しみは別に味わう必要はないのですけれど。

スイッチ類(電源スイッチとリセットボタン)の操作に伴い、IRQ30(シリアルと共用)に割り込みがあがるのは、btndrvがIRQ30をひっかけているので分かります。CPLD_INTMASK というレジスタがカーネルのソースで定義されているので、これで、この割り込みの制御ができそうなのもわかります。でも割り込みがかかると、刺さってしまうのです。ということで、あれこれ調べて、どうやらCPLD_SDRST_CTRL(シャットダウンとリセットの制御用レジスタ)に特定の値を出力して、割り込み要因を消してやらないといけないらしいことがわかりました。早速実装するとすっきり。割り込みを拾って、適切に、イベントが処理されるようになりました(^^)/

それにしても……こんなことして、ハードの仕様を推測しなければならないって、ホント、どうかしている……と、思います。

じつは、btndrvとbuttondに関しても手を出したのですが、うまくいかないところがあって、頓挫しています。本体に付属のbtndrvは、IRQ30をひっかけて、ボタンの状態変化を拾っている様子ですが、IRQ30を単純に引っ掛けてもスイッチのオン/オフでは割り込みが来ません。ちなみにボタンの状態は、拾い出すことが出来ています。

なので、fanctldのように、一定間隔でボタンの状態を監視して、shutdown を走らせるというようなbuttondと、割り込みが拾えない半端btndrvなら用意できます。が、あんまり間隔が長いとレスポンスが悪い感じだし、間隔が短いとシステムに対する無駄な負荷が増えるような気がしてなりません。

怪しいのは、CPLD_INTMASKという割り込みマスクレジスタ。これのLSB(0x01)を立ててやると、システムがフリーズします。(他のビットは立てても特段の変化なし。0x40はRS5C372Aからの割り込みマスクのようです。) このあたりの、扱いがきちんと分かって、割り込みが拾えるようになれば、poll()で寝て待つbuttondが作れるのですが……。仕様が公開されていれば、こんなことで悩まんで済むのに oTL

5/29 05:40以前にダウンロードされた方へ。fanctldには、異常終了してしまうバグがありました。現在配布中の版では修正済みですので、差し替えてご利用ください。お手数をおかけしますがよろしくお願いします。

ここまでの、ドライバプロジェクトの副産物として、ファンを制御するためのドライバとdaemonを作りましたので、これも公開します。こちらよりどうぞ。

ドライバは、/devにデバイスファイルを作らずに、/proc/fandrvを通して、制御します。0または1を書き込むことで、ファンをまわしたりとめたり出来ます。(0で停止、1で運転)

このドライバを利用して、ファンの運転・停止を自動的に制御するのが fanctldです。標準の設定で、五分に一回、hddtempを使って指定されたドライブの温度を測定して、40度以上になるとファンをまわします。40度未満でも、最近の五分間で一分あたりの温度上昇が0.5度を越えるようだとファンをまわします。Rubyで書かれているので、簡単に書き換えられると思います。お好みの形に書き換えてご利用ください。GPLですので。

GLANTANK用、leddrv/buzdrvを公開します。アイ・オー・データにそれ(公開)を望んでも無理っぽいので。ライセンスはGPLです。副作用として、'leddrv: module license 'I-O DATA' taints kernel.'という汚染メッセージが出なくなります(笑)

ソース一式と、コンパイル済みのドライバ(と少し修正したlinuxrc)を同梱したバイナリイメージをダウンロードできるようにしてありますので、ご利用ください。なお、いうまでもないことですが、あらゆる意味で無保証です。(GPLですし。) 一応、グラタンについてきている ledcont/buzcontで制御できますが、あらゆるパラメータの組み合わせで正しく動作するかどうか不明です。また、特にleddrvの方は、Giga Landiskシリーズ、中でも HDL-Gに分類されるものでは、多分正しく動作しないと思います。(偶然動く可能性はありますが。) 動作の検証はGLANTANKでのみ行なっています。

完成したと思って、ledcont stshw (緑のLEDをHW制御にする)して帰宅したら、LEDが消えていました oTL
点滅はとまったので、何か不足があるってわけです。調べて見ると、緑のLEDをon/off/blink/fastblinkさせることはできます。が、HW制御にはできません。一方赤のLEDの方は一切の制御を受け付けませんし、常にHW制御のようです。HDDへのアクセスでちかちかしますので。

見かけ上の kernel_timer_led_paramの変化は、純正のドライバと、ほぼ同一なのです。何が足りないのだろう……と、カーネルのソースを見ていると、初期化部分にこんなコードがありました。

一応、エラー処理などもそれらしく書いて、最後に、化粧を整えます。GPLにするのでCOPYING (GPLのライセンスシート)を用意して、モジュールのソースの中にも

ところで、この作業中に、ledcontにバグがあることが分かりました。まぁ大したことではないし、HDL-Gではこの仕様でいいのかもしれませんが、ドライバからステータスを読み出して表示するときに、サイクルの表示が、HDL-GW/GZでは、本来6bitのビットフィールドとして取らないといけないところを、他のフィールドにはみ出して7bitで取っているので、時々、実際のサイクル +64の値が表示されることがあります。全くどうでもいい話なんですけれどね(^^;;

渡されているものが分かったら、あとは、それを、カーネルに渡すために整形して、カーネル側のIFをばすんと呼び出すように、ダミーのioctl()を本当の処理に置き換えます。これで、完了!

ledcontをすると、ちゃんと kernel側のパラメータが変わっているのが、/proc/leddrvmemを通して見えます。(実はこの時点では、実機の脇にいるわけではないので、本当にLEDが制御できているのかどうかは分かっていません。状況証拠としては完璧なんですが……。)(^^;

同じ手順で buzdrv も書き起こします。btndrvだけは残念ながら、こういったコマンドがなく、電源ボタンの監視を行なっているので、簡単にはテストできないから、今回は見送ります。電源ボタンを切にしても、したがってシャットダウンは走りません。が、ソフトスイッチで制御できるような状態ならば、ネットワーク経由でログインして、shutdown すればいいだけの話ですから、実用上の問題はないでしょう。(少々面倒ではありますが)

さて、改めて、ビルドして insmodすると、今度は ledcont に反応しました。バッチリsyslogにナニが来たか書き出されています。ioctl()は、一般的に、コマンド(int)と引数へのポインタ(void *)を渡します。コマンドとそれに必要な引数がわたってくる訳です。コマンドは整数なので、ただ表示しても内容はわかります。何か書くときには、0x40046b01が、読み出すときには0x80046b02が渡って来ています。問題は引数です。ただ、LEDの制御には32bitのビットフィールドデータをカーネル側では使っているので、運がよければ、それがそのままvoid*に乗っかって来ていないかと期待したのですが……ダメでした。

デバイスドライバやカーネルとプログラムのインターフェイスには、通常のFile I/Oのほかに、/procに作った擬似ファイルを利用してやり取りする方法もあります。どうやら、ledcontは、これも利用しているようです。ならば、ナニが書いてあるのかを、2.6.10-iop1をブートして調べてみます。中身はこんな感じ。

とりあえず、出来上がった leddrv.koをいそいそと insmodしてみます。

Linuxのドライバをスクラッチから書くのなんて、2.0.xの頃以来なので、ちょっとドキドキ。とりあえず、モジュールにする場合には、モジュールを初期化して、その中で、デバイスを登録すればいいはず。あとは、関連付けられた手続きが順次呼び出されるはずです。とりあえず、体裁を整えて、いざ、gcc……。ん、出来るのは leddrv.oで、2.6のモジュールはみんな .koになっているけれどいいのかな……。よくありませんでした oTL

カーネルが2.6になるとき(2.5のドコからか?)に、モジュール周りのデザインが変わっていたのでした。これだから原始人は……。とりあえず、カーネルのソースツリーがあれば、それに間借りしてビルドできると、ドキュメントに書いてあるので(Documentation/kbuild/modules.txt)、それにならって、Makefileを作って、ビルドします。このとき、カーネルをビルドしたのと同じバージョンのgccを使わないと、あとで、insmod出来なくなります。当然、間借りするソースツリーも、利用するカーネルのものでなければなりません。

単純にLEDが制御できればいいので、ユーザランドのコマンドとドライバを対で書いてもいいかと思ったのだけれど、完全ではなくても、互換にしておくと、それなりに嬉しいかと思い、互換性が取れるようにすることにしました。コマンドのインターフェイスについては --help を渡せば表示されます。問題は、ドライバにはナニが渡されているのかということです。

アイ・オー・データが、leddrv, buzdrv , btndrvの三つに関して、ソースを公開してくれる気配はありません。なので、カーネルを入れ替えてしまうと、LEDが点滅し続ける箱になってしまい、いささか格好悪いのです。実害は少ないのですが、異常を知らせる目的で使われていたりもするのですから、きちんと動いてくれた方が嬉しいのは確かです。

ならば、動かしてしまえばいいではないか……なければ、作る。作ってしばえばいいのです。幸い、ブザーとLEDの制御のほとんどの部分は、カーネル側に存在します。leddrvとbuzdrvのやっていることは、この「本体」と、ユーザランドにある、buzcont. ledcontとのインターフェイスに過ぎないのです。
こうして、デバイスドライバも書いちゃえプロジェクトがスタートしたわけです。

わかってないと、おっしゃった方から、わかってないのがどこなのかというご指摘をいただきました。ご指摘感謝です。いくつかは、確かに、おっしゃるように「わかっていません」でした。が、幾つかには、誤解に基づくものもあるようなので、ちょっと書いておきます。

……延々、「2.6.16.17への道」を書いていたら2.6.16.18になっていました oTL
修正点は、SNMPをNATで外からアクセスできるようにしているときにDoS可能になる問題のようです。あまり大きな修正じゃないので、当該ユーザ以外は放置でもいいかもしれません。

とりあえず、玄箱も、GLANTANKも2.6.16.18へアップグレードしましたが。玄箱はGenbako Kernel collectionの、2.6.16.16用パッチを、GLANTANKには、2.6.16.17への道で、辿った修正をパッチとして整理しておいたものを用いました。

これで、またカーネルの連続稼働時間が……。2.6.16.18は数分稼動中です oTL
……しかしChangeLogから推測される以上にサイズが膨れている気がするなぁ……。

偉そうなことを色々書いているけれど、じゃあ、オマエの作ったカーネルはちゃんと動いているのかよ？
というのは、もっともな疑問です。ちなみに、2.6.15.7は3日以上動作し続けました。クラッシュは一度もありません。その間普通に、ディジタルデータのバックアップ(samba経由)、他のLinuxサーバとのファイルのやりとり(NFS経由)、カーネルのビルド、MP3ファイルのmt-daapd経由での配布などなどを行なっていましたが、クラッシュは当然一度もないです。異常な動作もありませんでした。四日に届かなかった原因は、2.6.16.17に入れ替えてしまったからです。

さて、その2.6.16.17は、入れ替えたのは昨夜のことですので、16時間ほどですが、今のところ全く異常は出ていません。この間、デジカメ写真のバックアップ、音楽ファイルの配信、NFS経由のファイル交換などをしていました。

2.6.15.7へのパッチは、先ほど現在 6人の方がお持ちになっています。うまく動いていますでしょうか？

なぜ、見ず知らずのヒトから、パッチの中身の是非ではなく、いきなり「わかってなさそう」などと、能力否定されてなお、カーネルの更新に関するチャレンジと、その情報を出しているのか。勿論、既に書いたように、知的好奇心を満足させるというモチベーションがひとつの理由なのですが、もうひとつには、脆弱なカーネルを放置する危険性を知っているからです。

グラタンのカーネルの入れ替えに関する情報を探して、ウェブをがさごそあさっていたとき(僕だって、*わかっている*誰かが作ってくれたカーネルがあるならそれがいいです。実際玄箱ではGenbako kernel collectionさんからカーネルパッチをもって来ていますし。)、思いのほか、グラタンを外向けに晒している、という人が見受けられたからです。

これはちょっと、恐いことです。自宅サーバではないですが、管理に関与しているとあるサーバが、(直接の侵入は、あるユーザのパスワードの脆弱性を突かれてだったのですが)クラッカーの侵入を許し、カーネルのセキュリティホールをついて、権限を昇格され、システムを乗っ取られたという経験があるからです。このとき利用されたのはローカルユーザの権限が昇格する問題ですが、例えばそこにリモートのユーザが利用できる脆弱性があれば……。

外に晒すシステムは、表層のサービス群は勿論、カーネルもセキュアに保たなければならないのです。なのに、2.6.10のままとまっているグラタンの公式カーネル……。プロセッサがIOP321ですから、x86のマシンに比べてクラックされる危険性は低いかもしれませんが、それでも、そこにクラックされうる穴があるなら、塞いでおくに越したことはないのです。

そんなわけで、少しでも、そういった被害を未然に防ぐことが出来るのならば、と思って、カーネルの更新を自らクラッシュを繰り返しながら試し、関係する情報を発信しているわけです。

だったら、誰がなんていったって構わずパッチを公開しろ、いや、ビルドしたカーネルを置いて置けよ、という声もあるかもしれません。確かにそれは、正しいと思います。ただ、いきなり、善意のつもりでやっていることで、パッチの中身も見ずに、能力を否定するような人しかいないコミュニティなら、貢献するのもアホ臭いという気分になっているのも事実なのです。

なので、コメントをお寄せください。もし、誰か、必要としている人がいらっしゃるなら、すぐにでもパッチを公開しますし、自力でカーネルのビルドは……というのであれば、ビルド済みのカーネル(と、initrd, /lib/modules)を配布します。それで、そういう情けなくも悲しい被害が未然に防げるのであれば。

ココまで来たら、あとはビルドするだけです。出来たzImageは/bootへ、modulesは、/lib/modulesと/boot/initrd の中身へとインストールします。2.6.15.7化してあって、わたしの linuxrcをinitrdに導入済みである方以外は、linuxrcの中でブザーやLEDに触る部分(ドライバのロードも含めて)を全てコメントアウトするなどして無効にします。

勿論、こういう作業をするときには、必ず、オリジナルの /boot/zImage, /boot/initrd を保管して置いてください。万が一が起きたときに、KNOPPIXなどで簡単に修復できるように、/bootの下にコピーを作っておくといいでしょう。

さあ、ここまで、この***わかってないような奴が書いた駄文***に従って作業された方、お疲れ様です。祈る気持ちで reboot しましょう。
作業はしていないけれど、ここまで読んで、こいつの作ったパッチなら大丈夫そうだと思った方、コメントをお寄せください。もし希望者がいれば、パッチを配布します。パッチは、一発で、ちゃんとあたるように作ってありますので、パッチ適用→コンフィグ→ビルド→入れ替え→再起動でいいようになっています。

最後に、くどいですが、漠然と***わかってない奴だ***と思った人は、絶対に、この一連の作業をしないで下さい。自分でどうぞ自分の道をお行きください。見たところ、勘違いしているところがあるよ、などの具体性を持った指摘はありがたく拝聴させていただきますので、そういう方は是非コメントをお寄せください。
決して、自分で試しもしないで「誰かが人柱になるだろう」などという意図の下に、リンクだけ置くような真似はしないで下さい。

さて、ここが最後にして最大のヤマです。残りは、コンフィグです。カーネルのコンフィグレーションをしなければなりません。Linuxのカーネルコンフィグレーションは、バージョンが変わるたびに構成やシンボル名が変わりますので、単純に古い .config を持ってくればいいという話ではないことがあります。(動いてしまうことも多いですが。)

古い .configを使って、make menuconfigをして、無効になっているもの、新規に追加されたもの、また有効になっているものでも依然必要かどうかの棚卸をする必要があります。2.6.15.7用に、わかってないような奴が用意したサンプルのconfigは大体、イイ感じですが、*** わかってないような奴ですから、必ず、全てのconfig項目に目を通すことをお勧めします。***
面倒ですけれどね。ただ、ここで間違いを犯すと、2.6.15.7の時に、僕が喰らったクラッシュしまくりを追体験する事になりますから、くれぐれも慎重に。

さあ、これでビルドできる……と、そう思った方は、まだちょっと、気が早すぎます。まだ、二山ほど残っています。先に書いた通り、2.6.15と2.6.16とではI2CデバイスドライバとカーネルとのIFが変更になっています。具体的には、i2c_driverとi2c_clientの二つが変わっています。より標準のドライバIFに近づけたというか、そんな感じの修正が入っています。なのでdrivers/i2c/chips/rs5c372.cを修正しなければなりません。

具体的には、i2c_client.flags が廃止になり、i2cdriver.ownerとi2cdriver.flagsも廃止です。なのでこれらに関するコード(初期化部分を含めて)は削除しなければなりません。また、i2cdriver.nameはi2cdriver.driverが追加されたことによって、そっちの中に移動になっています。これに関する部分も書き改めなければなりません。基本的に、しなければならないのはこれだけです。不安だという方は、カーネルの変更点に関するドキュメントを読んで、また、具体的に他のi2c/chipsのドライバがどういう修正を受けたかを具に調べて、理解してから行なってください。尤も、そのくらいを読んだだけでは「わかっているようではない」奴と変わりないのですが……。

さて、今度は、グラタン由来の物体を取り込む必要があります。同じように思い切って2.6.15.7用のパッチを当ててしまいます。
***注意:はじめに書いたように、わかっているようではない奴が作っているので、このパッチはわかってないと思われます。それをバージョンの違うカーネルのソースツリーに適用するので、わかってない問題が噴出する可能性が甚大です。くれぐれも、「わかってない」と感じている人は、パッチを当てないで下さい。更に、自分で試すつもりもないのに、人柱を他人に強いるような*無責任な*リンクを貼ったりはしないで下さい。***
先ほどと同じく、順調にパッチは失敗します。同様に、*.rejファイルを探します。

DMA(やAAU, CCNT)のソースは、iop1パッチから取り込むのが早道です。ということで、2.6.15.4用のパッチを思い切って適用してやります。当然、うまく当たらないパッチがあります。*.rejファイルを探してみましょう。

さて、重要なのは、dma.hのみになります。これは、IOP3XXのdma.cが利用するシンボルを定義しているのですが、パッチを当てる対象の、arch-iop3xx/dma.hはいつの間にか、空っぽになってしまっています。(なので、とっかかりが見つからずパッチを当てられない。) とりあえず、.rejの内容を転記します。慎重な人は、追記した部分の前後に、

これで、最低限のiop1パッチの取り込みは完了です。(M41ST85WやGD31244などのドライバはビルドできないはずではあるけれど、グラタンは使わないので忘れておく。)

と、ここまでを総括すると、取り込むべき機能は、次のものになると思います。

• IOP3XX用DMA機能
• グラタン由来のRS5C372Aドライバ
• グラタン由来のAEC62XXパッチ
• グラタン由来のシャットダウン処理
• グラタン由来のPCIバス周りの設定
• グラタン由来のLED/ブザー処理コード
• IOP3XX用AAUコード(使うなら)
• IOP3XX用CCNTコード(使うなら)

では、グラタンに独自のものというのはなんでしょう？
ひとつは、RS5C372Aというリコー製のRTCです。これは玄箱でも利用されていますね。CPUとは二本のラインでI²Cで接続しています。これのドライバは、グラタンのソースCDの中のlinux-2.6.10-iop1/drivers/i2c/chips/の下に入っています。但し、これも既述のように、2.6.10 → 2.6.16の間にデバイスドライバのIFが変わっているので、2.6.16のそれに合致するように修正する必要があります。

他のものとしては、PCIバス周り(標準のIOP3XXの設定はslot0 に GbEが、slot2がPCI-Xで1,3は未使用)が、全スロットPCI-X扱いになっているとか、AEC62XXで常にUltra DMA/66を利用するようにしていること(mode = 4になるようにべた書きしている。もしかしたらこのあたりがHDDを選ぶ所以かもしれない。)や、ROMのマッピングを強制的にオフセット0からするとか細かな修正が入っています。理由は良くわかりません。ええ、わかっていませんから。また、システムの停止時、電源断の際に、独自のshutdown_portに値を書き込んでいます。pm_poweroff()などの後に呼ばれているので、標準のシーケンスでは電源は切れず、この処理が必要なんだと思われます。他には、LEDを点滅させたりブザーを鳴らしたりするコードが追加されています。

ところで、そもそも IOP ってナンだろうと、思っている人もいると思います。Xscaleじゃないのか、と。インテルのXscaleはARM v5TE ISAに準拠した組み込み用のプロセッサファミリーで、PDAなどに利用される、アプリケーションプロセッサPXAシリーズ、ネットワーク機器向けのIXPシリーズと、IO機器向けのIOPシリーズ(あとその他)に大別されます。IOPシリーズはARMコアに、IO機器向けの機能を組み込んだプロセッサになります。

IOPパッチはこれらのIOPシリーズに特化した機能を利用することを目的としたパッチです。また、一部周辺チップ(PIC16F8X, MT41ST85W, GD31244など)のサポートも含んでいます。LinuxカーネルのXscaleサポートは元々はPXAをターゲットにしていたので、これらの付加機能は、当初インテルから、現在は、Sourceforge上にてパッチの形として提供されています。但し、最新版は、既述の通り 2.6.15.4向けのパッチで、2.6.16向けのものは存在していません。と、いっても、本家のカーネルの方にもIOPに特化した機能も徐々に取り込まれてきているようで、IOPそのものに向けたパッチとしては、DMA、AAU、CCNTなどの一部を残すのみになっています。

逆に言えば、それらの機能を利用しないのであれば、本家のカーネルのconfigurationを適切に作れば動くカーネルを得られるものと考えられます。(試していませんが。)
但し、これとは別に、グラタンにはグラタン独自の仕様から来るパッチが必要になります。こちらを適用せずに動かすと、例えば、カレンダークロックから日時を拾えないとか、シャットダウン時に電源が落ちないとか(多分)そういうことが起こると推測されます。(やってないので実は起きないかもしれませんが、少なくとも時計は読み出せません。)

2.6.15から2.6.16へのジャンプは、非常に大きいというわけではありません。2.6.10から2.6.15まで、一気にジャンプしたのに比べれば、ではありますが。両者の間では、たとえば、デバイスドライバとカーネルのIFが変わっています。これは、RS5C372Aのように、グラタンのソースCDに由来するものにとっては、それなりの変更を要求されます。IFが合ってなければ、ドライバを正しく呼び出せませんし、何よりほとんどの場合、ビルドにさえ失敗してしまいます。反面、iop1パッチにあったものが徐々に取り込まれてきてもいます。残念なことに、グラタンのパッチはまったく取り込まれていませんが、これは仕方ないでしょう。

従って、何が入って、何が入っていないのか、これをチェックすることが必要です。幸いiop1のすべての機能が、グラタンで利用されているわけではないので、このあたりも含めて、要不要も考えます。

現状:

とりあえず、ムカっと来たのを、2.6.16.17にぶつけてしまいました。そんでもって、さっきブートアップ完了しましたよ。ということで、我が家のグラタンは2.6.16.17になっています。iop1のパッチを大部分取り込めていると思いますが、iop1は2.6.16にまだ、対応していませんから、サブバージョンは、-iop1ではなく-glantankにしてあります。

お断り: これから、書き綴る話も、わたしがわからないでやっていると思うヒトは、手も口を出さないでください。リンクもできればお断りしたいくらいです。(とはいえ、ウェブ上に公開していて、リンクするなというのも無理な話なので、別にそれでもリンクするというのを止めるものではありません。)

もちろん、Linuxカーネルの隅々まで理解しているかといわれれば、ノーですし、ましてや、ハードウェアの詳細が公開されているわけでもないハードウェアへの移植作業をしようというのですから、何が起きるかわからないのは当然といえば当然の話です。

それらの危険性を理解したうえで、わたしの愚行に、意義を見出してくださる方だけ、どうか、お付き合いください。それ以外の、自分では試さずに、「誰か人柱求む」みたいな話は、ここの素材を種には、しないでください。わたしは、自分で血を流して検証していますし、自分で挑戦するヒトを応援したいと思っています。

なお、まとめたパッチなどに関しては、「いろいろなことをわかって作っているようではない」ので、信用してはいけません。

とある事情、というのは、アイ・オー・データがソースを公開していないドライバを使っているということです。/lib/modules/noversions というディレクトリに、leddrv.ko, btndrv.ko, そして buzdrv.koという三つのドライバがあります。ディレクトリ名どおり、バージョン非依存ならまだいいのですが、実際には、2.6.10-iop1ではないと動かないようにされています。そしてソースもない。

この三つのドライバは、それぞれ、グラタンの、LED、電源ボタン、ブザーを制御するためのもので、linuxrcがブートのステージを伝えるのに、また、定期的にRAIDのヘルスチェッカが、使っているのですが、これらを組み込むことができないので、linuxrcを変更してバージョンチェックをして、これらの動作(ドライバの組み込みからステータスに基づくLEDなどの制御)をしないようにしてあります。

このため、2.6.15.7-iop1(改)に入れ替えたグラタンは電源LEDが点滅しっぱなしです。異常ではないのですが、ネットワーク経由でログインしないと、状態を調べることは出来なくなります。外部にサービスを公開しているような用途の場合は、別にLEDがどう点滅していようとあまり気にはならないかと思いますが、手元において純然たるNASとして運用しているような場合には、気になるかもしれません。そのような場合には、カーネルを入れ替えないことをお勧めします。(逆に外部にサービスを公開している場合には積極的にカーネルを入れ替えるべきです。セキュリティホールを放置することは、どうぞクラックしてくださいといっているようなものなので。)

現在、挑戦者掲示板から、ソースの開示依頼をしていますが、どうなるかわかりません。時間が取れたら、せめて点滅だけは止めるような、独自仕様のドライバと制御用のコマンドを作るかもしれませんが、美しくないので、アイ・オー・データがソースを開示してくれることを願って止みません。

そうやって、あれこれ試行錯誤した結果得られたものが、このパッチになります。展開すると、dot.configとlinux-2.6.15.7-glantank.diffおよび、linuxrcというファイルが出てきます。diffファイルは patchコマンドで、iop1パッチ適用済みの2.6.15.7のソースへ適用します。dot.configはコンフィグのサンプルです。(勿論このままの設定で我が家で利用していますので、そのままでも動くはずです。保証はしかねますが。)

そして、最後の、linuxrcは、initrdの中のものを置き換えるために必要なのです。本来、そのままのlinuxrcでいいはずなんですが、とある事情により、こんなものを用意しなければならなくなってしまいました。

グラタンのソースCDに入っている2.6.10-iop1に入っている、configというファイルは、使い物になりません。このファイルの設定でカーネルを作ると、グラタンが起動しません。Debianモードで作った箱なら大丈夫かもしれませんが、通常通りの設定で、md0を使うようにしていた場合には、md0がマウントできずに、いきなり linuxrcによって haltされます。つまり落ちます。

何故こんな configが入れていあるのか、理解に苦しむのですが、これは忘れて、地道に、configを作っていきます。現在動作しているであろう、2.6.10-iop1カーネルのdmesgを見ながら、或いは、どこか親切な人が作ってくれた configのサンプルなどを探し出して参考にするなどして、configを作り上げる必要があります。ここで、かなりの試行錯誤を要しました。何しろ、うまくブートしてくれないと、ネットワーク経由で入り込めない状態で頓死していたりするわけで、シリアルキット(純正、似非、とにかくなんでも)がなければ、何に不足があるのかがつかめないのです。自力で進もうという方はシリアルキットは必須となる所以です。

カーネルの基本部分は、iop1で問題なく動作するのではないかと思われるのですが、2.6.10-iop1のソースを見ると、iop1とは別に、こっそり、パッチが当てられているのが判ります。リコーのRS5C372Aというチップ(RTCとハードウェアモニタを兼ねている？)のドライバ、R8169Sというギガニのドライバ、それと、AEC62XX IDEドライバへのパッチ、PCIバス周りのIRQに対する変更、その他、LED、ボタン、ブザーやシャットダウン処理に関する修正がぱらぱらと加えられています。

このうち、R8169Sに関しては、どうも2.6.15では、R8169のドライバがサポートするようになっているように見えるので、捨ててしまっても大丈夫そうです。(そもそも、グラタンでは使ってないようにも見えますし。Giga Landiskのシリーズでは使っているものがあるのでしょうか？) RS5C372Aに関しては、2.6.10 と2.6.15ではドライバ周りのIFが若干変わっているようで、これに対する修正を加える必要があります。あとは、その他の修正を、ちょろちょろと統合していきます。

アイ・オーがやったみたいに、べったりとそれらを書き込んでしまってもいいのですが、かっこよく(?)#ifdefで切り出しておきます。CONFIG_ARCH_GLANTANKというシンボルがある場合だけグラタン用のカーネルになるようにしておきます。同時にarch/arm/Kconfigに ARCH_GLANTANKをdepends on ARCH_IQ80321という形でエントリを作っておきます。これで、IQ80321を選ぶと、GLANTANKが選べるように、menuconfig/xconfigが変わります。

2.6.15系のカーネルは、2.6.15.7が最新版です。これと、2.6.15.4-iop1パッチを取ってきて、展開し適用します。

とりあえず、何も考えずに、最新版の2.6.16.14(当時、現在は2.6.16.16が最新)を持ってきて、ソースCDから取り出した、カーネルのソースツリーに入っていた、2.6.10-iop1のパッチを当ててみる……と、'.rej'の山……oTL

あかん……これでは、お話になりません。仕方がないので、手でパッチを当てていこうかと思い、'*.rej'ファイルと、ソースファイルを見ていると、パッチに含まれていない変更があちらこちらに……。と、ここで、はじめてiop1は、'IOdataPatch'の略ではないことに気づきました。iop対応のカーネルを作るための差分でした。これは、SourceForgeにレポジトリが存在しています。そこを見ると、2.6.15用のパッチがありました。

これだ……コレしかない。最新版ではないけれど、2.6.15.4というのは2.6.10よりかなりマシだと思われますので、コレ以後は、2.6.15.をターゲットとして進むことにしました。

グラタンのカーネルは2.6.10にiop1パッチを当てたものをベースとしています。unameの出力もそういっているし、ソースCDに入っているのも、そうなっています。しかし、これは流石に古く、セキュリティホールも散見されるので、外にさらすのも恐いですし、さらに、過負荷状態になると、DMA周りで刺さってしまうという話も聞きます。ならば、カーネルを新しいものに差し替えるのが筋というものでしょう。玄人志向が正式にサポートしてるわけでもないのに、玄箱には、2.6系のカーネルでブートするすべを見つけた人がいるばかりか、その2.6系のカーネルをメンテしている神もいます。グラタンにだってそういう人がいるんじゃないかと思って、がさごそググって漁ってみても、その様なものには行き当たりませんでした oTL

なけりゃ、自分でやるしかないでしょう……。それが、オープンソースな心意気(なぞ)というものです。ここに、およそ三週間にもわたる、苦闘が始まったのです。

Linux version 2.6.15.7-iop1 (araki@onion) (gcc バージョン 3.4.4 20050314 (prerelease)ian 3.4.3-13)) #5 Fri May 19 10:31:42 JST 2006
CPU: XScale-IOP8032x Family [69052e20] revision 0 (ARMv5TE)
Machine: Intel IQ80321
Memory policy: ECC disabled, Data cache writeback
...

長かった……とりあえず、leddrv, buzdrv, btndrvがないままになっていますが、だからLEDが点滅しっぱなしですが、とりあえず、動き出しました。詳細は、また、改めて。
とりあえず、アイ・オー・データさん、ドライバのソースを公開してください。

2.6.16.16のソースをざっとみたら、aau.[ch]とか、dma.[ch]とか、iop1独自のパーツは入っていませんでした。つまり、今の、2.6.15.7化計画がうまくいっても、安定版といわれる、2.6.16.xの系列への移行は一苦労が予想されるということ。デバイスドライバのIF周りがまた変わっているし、手でパッチを適合させていくとしても、ホネが折れそうだなぁ。グラタンのことだけを考えるならaauなんて使ってないし、dma.[ch]とrs5c732aの書き換えくらいで済むような気もするんだけれど……。

余談ですが、グラタンの掲示板で、noversionのドライバ群のソースがもらえないかどうか質問してみました。どういう返事が得られるのでしょうか……。

430円(+α)の自作シリアルケーブルについて、補足しておきます。もし、自作してみようという挑戦者が現れたときのために。9-KEのケーブルの色については諸説あるようですが、次のようになっています。

	グラタン		9-KE
1	Vcc	-	NC
2	RxD	-	黒
3	TxD	-	橙
4	GND	-	茶
5	NC	-	NC