TurboLinux

「ターボリナックスが中国でNO1のシェアを獲得65%の圧倒的なシェアでTurbolinux製品がLinuxサーバーOSとしてデファクトスタンダード(ターボリナックス:ニュースリリース)」ということらしい。しかし、日本語版でも最初はけっこう勢いがあった(ように感じた)。特に、日本語版のディストリビューターとして、インストールするだけで、他の日本語PC用OSと同等の日本語環境がインストールできるのは、俺のようにヘナチョコなPU-unix入門者には福音だった。日本語対応していないディストリビューションに日本語パッチをあて、使いこなすことは、winやmacしか使ったことのない個人には、当時のネットワーク環境もあって、負担だったから。

 ところが、他のディストリビューションの充実につれてシェアを下げ、ニッチ市場への開発資源の集中を行った。AMDの64bitプロセッサーへの対応やこの中国語対応がそうだ。そして、その成果はそれなりに上がっている(単にネットに流れる情報からだけだが)ようだ。

 しかし、新プロセッサーや言語への対応はいずれ追いつかれる。linuxは未だに開発途上の環境だ。しかも、ディレクトリセンシティブな環境設定がlinuxに残り、ディストリビューションが別々の設定を作っているかぎり、シェアの大きなディストリビューションに吸収される運命にある。企業で導入する場合ディストリビューションはそろえないと不便で仕方がないから。

 俺は、今の環境で行けるところまで行って、redhatの最新版を買うことにするつもりだ。TL8wを再インストールしても、現在の状態にするにはかなりの時間と労力が要求されそうだから。「行けるところまで」とは、HDがやばくなるかturbolinuxによるサポートが打ち切られることだ。特にセキュリティアップデートの打ち切りはサーバーOSとしては最後通牒になるだろう(winとかmacなら痛くも痒くもない。実際俺はwin98もmacOS9.2もアップデートしない)。

 寄らば大樹の陰というのは、winNTを導入してメーカーのSEにしょっちゅう来てもらっている某会社のようでいやだが、俺はlinuxの専門家になりたくてサーバーを構築しているのではないから仕方がない。したい事をするためにサーバーを自前で調達すると楽だからそうしているだけなのだから。

counter

 カウンターを移植してみた。cgi-binにプログラムを置いてデータは別ディレクトリだ。ドメインや仮想サーバーで別に管理しているサイト全部から一つのプログラムでできるのは、小さなプログラムなのでそれほど無駄ではないが、気分がいい。

 ISPでよくある1ユーザー1カウンターサービスって、これのことだな。ユーザーに触れないcgi-binにプログラムを置いて、ユーザーにURLを教えるだけだ。

MovableType 設置の覚書2 お世話になりっぱなし

 どの問題も自力では解決できなかった自信(?)があります。感謝!

 標準のcssを使っていて本文が横に広すぎるけど、解決方法がわからなったときにお世話になリました。
しんせんかんそ: IE6のCSS問題

 めったにコメントは付かないですが、ちゃんと見えるほうがいいに決まってます。
TRIGGERS / blognews: 個別の記事URLまたはコメントURLをブラウザで開くと、文字が真っ白になってしまう問題について

左の月別アーカイブをプルダウンにしてスペース効率を上げられたのは
Soanblog [Movabletype版] 創庵: PULLDOWN JUMPMENUのおかげ。カテゴリーの数は自分でコントロールできるけど月単位のアーカイブは増える一方やからね。

Modern Syntaxさんにもお世話になっています。上記のサイトはすべてここで知りました。まだ追及してませんが、Bookmarkletには大きな可能性を感じます。

blog.hinatabocco.comの情報のおかげで、アーカイブのインデックスを作ることができました。

#ところで、こんな横着なまとめトラックバックっていいのかなあ?

Movable Type 設置にまつわる覚え

zdnet.co.jp/help/howto/による。

○ImageMagickのインストール
 ImageMagickはRPMパッケージも用意されているので,ここではRPMパッケージをダウンロードしてインストールを行っている。
・ダウンロードサイト
ftp://ftp.nluug.nl/pub/ImageMagick/linux/redhat-7.x/i386/ImageMagick-5.4.3-11.i386.rpm
ftp://ftp.nluug.nl/pub/ImageMagick/linux/redhat-7.x/i386/ImageMagick-devel-5.4.3-11.i386.rpm
ftp://ftp.nluug.nl/pub/ImageMagick/linux/redhat-7.x/i386/ImageMagick-perl-5.4.3-11.i386.rpm

# rpm -ivh ImageMagick-5.4.3-11.i386.rpm ImageMagick-devel-5.4.3-11.i386.rpm ImageMagick-perl-5.4.3-11.i386.rpm

○Perlモジュールのインストール
 Perlモジュールは,CPANを利用した自動インストールを利用して,必要なものをインストールしよう。インストールするモジュールは下記のものだ。

Bundle::LWP
HTML::Mason
Time::HiRes
Compress::Zlib
XML::LibXML
XML::LibXSLT
Image::Magick

 インストール時はroot(管理者権限)になり,コマンドプロンプトで「perl -MCPAN -e shell」と入力すればよい。

# perl -MCPAN -e shell
CPAN>install Bundle::LWP HTML::Mason Time::HiRes Compress::Zlib XML::LibXML XML::LibXSLT Image::Magick

 MovableTypeを使うだけならImageMagickのインストールは不要だと思われる。必要なのは、perlモジュールの「Image::Magick」だ。多くの環境でCPANで接続してダウンロード・インストールできるらしいが、俺の環境では失敗した。ダウンロードしてのコンパイルもうまくいかなかった。pngを扱うライブラリをインストールしていなかったのが原因らしく、TLのサイトからZabonでインストールしたらすんなりとコンパイル・インストールが完了した。エラーメッセージはCPANも同じだったので、前もって必要なライブラリをインストールしておけばCPANでも問題はなかったのかもしれない。

 パッケージやインストールのオプションによっては他にも依存しているライブラリがあるかもしれないし、新たにインストールする必要がない場合もあると思われる。だから、俺の書いているものもTurboLinux8workstationをパワフルデスクトップというタイプでインストールしたものというのが前提だ。このあたりは、Macやwinしか使ってこなかった人間にはわかり難い。

 繰り返しになるが、これは文化だ。知っているからといって偉くもないし、知ってしまえばそれだけといった知識ではあるが、身に付けるのは大変だし、知らないと何かと不便だ。外国語を勉強するのと一緒で、謙虚に重要度の高いものから覚えるしかない。
========

DBD/DBIの情報。

JAM LOG
PerlでMySQLを使うにはこのDBIという「ドライバーインターフェイス部」とDBDという「ドライバー部分」の二つをインストールしないといけないわけですが、これが結構煩雑で面倒です。そこでついでだったのでDBIとDBDをまとめてワンパックにパッケージインストーラ化してみました。ダウンロードは「Downloads」のコーナーから。
DBI,DBD

 DBD/DBIモジュールをインストールはTL8wのデスクトップではインストールされていないらしい。

 TurboLinux8wsのインストールオプションで「パワフルデスクトップ」を選んだのが失敗らしい。開発環境以上じゃないとこのモジュールは入らないらしい・・・

TurboLinux8wsインストールパッケージ
それは、このページで確認できた。

 MTにたどり着くまでにえらい時間がかかった。

 しかし、直接関係はないが、、cgiの設定について勉強になった。cgi-binというフォルダの使い方もかなりなじんできた。これまでは、cgiを各ユーザーのフォルダごとに置いていたが、うまくcgi-binを使えばcgiは一つにまとめて、データディレクトリだけをユーザーのディレクトリに置くという使い方ができそうだ。

 実際に、coolshotというcgiを設置するときにその方法でうまくいった。これのメリットは、http://www.dddd.net/cgi-bin/cginame.cgiという風に記述できること。実際にはcgiは/var/www/cgi-bin/のU中にあるのに、httpでアクセスされるディレクトリのトップディレクトリにcgi-binが存在するようにURLを書くことができる。

 これは、ほとんどのプロバイダで使えない技だろう。プロバイダでcgi-binを公開したらえらいことになるだろう。レンタルサーバーの場合も、絶対ルート(というのか、HDのディレクトリツリー)が分からないから、実行ファイル以外のファイルやデータの入ったディレクトリをcgiから参照できなくなってしまう。

自前のサーバーで気分最高さ。

Movable Typeの利点

 これまでに設置した掲示板や日記cgiと比較してのことだが、複数のユーザーと複数のblogを統合して管理できるのが便利だ。これについては、圧倒的と感じた。coolnoteもサブユーザーと利用権の管理はできるが、それをさらに便利にした感じだ。新しいblogをものの数分で作ることが可能だ。慣れてくれば他のcgiでも数分で設定することは可能だが、Mtの場合はその半分以下の労力だ。これは、規模が大きくなればなるほどメリットとして感じられるだろう。

 また、メインのDBファイルを標準的なDBソフトで管理することも、将来的にはメリットになると思う(まあ、俺が残すべきテキストを書ければの話だが・・・それは別の話ということで)。これも、規模が大きくなればなるほどメリットは増大するだろう。管理者はDBのバックアップさえとっていれば各々のフロントエンドに何かあってもデータは守られるし、読み出すことも可能だ。

 このソフトは、常時高速接続のキラーソフトになるかもしれない。ダイヤルアップ時代にはブラウザーのフォームで日記を書くなんて思いもしなかったし、こんなグラフィックパーツてんこ盛りのフォームなんて大嫌いだった。ADSLと新しいパソコンを買ったけど使い道がよくわからないという多くのユーザーのPC使用時間を増やすことにつながる可能性がある。(まあ、ISPも接続業者もハードメーカもソフトメーカーもユーザーのPC活用度になんかあんまり興味ないんだろうけどね)。

実際は

CNET Japan – 梅田望夫・英語で読むITトレンド:次世代ソフト開発で各分野に広がるLinux、ペンギン恐るべし

 実際はこれなんだろうが、テレビで10時~11時にかけてのニュース・エンタテインメントを見ている人には、サーバーもwinが一人勝ちに見えているに違いない。あと、シスコもコスト削減効果があるかのような広告をしている。

 どちらも、コスト算出の条件について全く情報を提供していないイメージ広告だが、油断してはいけない。こんなクソCMでも自分でシステムを触らない人間には浸透してしまう。それはwin95のときを思い出せばいい。win3.1よりはるかにバギーで、macとは比べ物にならないくらい使いにくい代物を消費者は喜んで受け入れたのだった。そして、何年かしたら「前のものより安定が良くなり使いやすさに磨きがかかったwin98」その2年後に「新しい技術を盛り込んだwinMe」をリリースした。win98は意外によかったが、winMeが不良品だったことは記憶に新しい。それでも、今、消費者の大半はwinXpマシンを買うのだ。

 そのうち、「うちのサーバーはなぜwindowsサーバーにしないんだ?」とか「シスコを導入したらどうなんだ?」と言われるシステム担当者が出てくるに違いない。

その後、「CNET Japan – 梅田望夫・英語で読むITトレンド:デスクトップLinuxが盛り上がるとすれば」というコラムで、にデスクトップへの普及の可能性について考えている。が、アメリカでも2007年とは・・・気が長すぎるんじゃないだろうか。

 俺は自分だけで使うならLINUXでも十分だが、何かしようと思ったときのハードルの高さが軽減されないことにはしんどすぎる。ディレクトリ構成がディストリビューションによって異なったり、アプリケーションによって設定ファイルの持ち方が違ったり、名前の付け方が違ったりする。コントロールパネルに類するソフトも少ない。(TurboLIinux8workstation固有の問題かもしれないが)

 それと、最近設定にハマって気付いたことは、コンパイルユーティリティがないことにも戸惑う。makeというのがgccのコンパイラだが、ターミナル(DOS窓みたいなもの)でしか使えない。全てがバイナリベース(コンパイル済みのソフトを配付する方法。だから、winやmacの大半のユーザーはコンパイラすら持っていない)のwinやmacならコンパイラは不要だが、ソースでの配付がデフォルトであるlinuxでは、このままでは厳しいだろう。

 いっそのこと、ブラックボックス化してインストールやメンテナンスをすべてネット経由でやるというアプローチのほうが現実的かもしれない・・・

 と考えていたらすでに織り込んだものが出るらしい。

 HDDを省き価格を169ドルに抑えたリナックスPC :Mainichi INTERACTIVE コンピューティング

 なるほど。ネットワーク上からOSをダウンロードして起動するんじゃなくて、KNOPPIXと同じ考え方か。ゲーム機とも似ている。常時高速接続が現実的になった今なら十分に効果的だと思う。インストールとかバージョンアップなんて考える必要ないし(そもそもできない)、登録ユーザーにはCDを定期的に送ればいい。周辺機器への対応に一抹の不安が残るが・・・そんな人間はオプションのHDを買えばいい。クライアントと割り切るならCDブート+ネットワークストレージは有りだ。

 ただ、問題は市場とのミスマッチだ。このページを読んでいるようなオタクは興味を持つかもしれないが、これでは物足りなくて買わないだろう。palm DeskTopがインストールできないのでは困るものね。かといって、一台目のPCとしてこれを選ぶ初心者もいないだろう。初心者であればあるほど目的が漠然としているので、「あれもできるlこれもできる」に魅力を感じるものだ。

 このマシンを受け入れるほどユーザーは熟したのかどうか。結果がとても楽しみだ。

#「そんなもん、中古PCとKNOPPIXと無料メールアカウントで十分やん」というオタクはすでにターゲットではないと心得よ。

やっと

 TurboLinuxのユーザーBBSで質問してやっと解決した。

 DBDのコンパイルに失敗したのは、開発用のライブラリの不足が原因だった。アドバイスにしたがってコンパイルしたらメッセージが変わったもののまたコンパイルエラーがでて悲しくなったが、そのライブラリの実行ファイルがインストールされていること、そのライブラリはなくてはならないライブラリに含まれていることが分かったので、先例に従って該当する開発ライブラリを入れてみた。

 すると、makeのときにエラーがでなくなりものの2分ほどでインストールも終わった。そして、mt-check.cgiを実行したらmysqlがインストールされていることが認識された。

 そして、loadも終わった。mt.cgiの実行でつまずいたが、これはlinuxの世界のエラーではなくcgiの設定レベルの話なので、自力でなんとかできそうだ。何せ、そのマシンでは既に一本テスト用のmtが動いているから(バークレーDB版)。

 TL8wをインストールするときに開発パッケージを選んでおけば、何の問題もなく終わっていた作業だけに虚しい。しかし、mysql_confgがないとかlibz.soがないと言われたときに、sysql_develとかzlib_develが必要とは思えないよ・・・しかも、libzなんてパッケージに含まれる実行ファイル名だ。さらに、libzという実行ファイルは標準でインストールされていたのだ。

 「ここにあるのに、なんで見つからないの?」という感じだった・・・

必要だったもの、DBI、DBDのソース又はrpm。DBIはftpサイトからインストール可能。DBDはwww.perl.comよりダウンロード。

zlib_devel,mysql_develはftpサイトからzabonでインストール可能。

上記が済んでからDBDのコンパイルを行う。suかrootで、DBDを解凍したフォルダに入って、
perl Makefile.PL
make
make test(エラーメッセージが出たがinstallできないとは書いてなかった)
make install

zlib1.1.4-4,DBI1.37,DBD2.0092,mt-3.26

煮詰まったときにサーバーの再起動をかけてみたら、CPUは45度だった。気温は28度程度だからまだ余裕か。この調子なら真夏の室内でも充分乗りきれそうだ。

それでも

 昨日の予想は当たっていた。DBDというモジュールが必要らしい。そして、それはDBIのパッケージとは別にインストールする必要がある。

 しかし・・・・TurboLinux のインストールサイトにはDBDモジュールは存在しない。しかも、オフィシャルサイトからダウンロードしたものをインストールしようとしたがうまくいかない。コンパイルが通らない。あるべきファイルがないのか、あるべきファイルがあっても入っている場所が悪いのか・・・・作法を知らないので修正のしようがない・・・・

 しかし、返す返すも中途半端なTL8wの仕様・・・サーバー・パッケージと差別化するための仕様かもしれないが、mysqlやphpをユーザーとして使うであろうことはlinuxの性格からして予想されると思うんだけど・・・

これなのか

perl.com

JAM LOG

PerlでMySQLを使うにはこのDBIという「ドライバーインターフェイス部」とDBDという「ドライバー部分」の二つをインストールしないといけないわけですが、これが結構煩雑で面倒です。そこでついでだったのでDBIとDBDをまとめてワンパックにパッケージインストーラ化してみました。ダウンロードは「Downloads」のコーナーから。

DBIとDBDって一つのものじゃなかったのか・・・俺は、パッケージマネージャーにはDBIというモジュールはあったがDBDというモジュールはなかった。DBDというのはDBIに一体化したAPIの名前かと思っていた。しかし、こんなセットじゃなきゃ使えないものを別々に、しかも片一方だけしか置いていないなんて考えにくいけど・・・