TurboLinux 導入記 1998年11月

Kernel バージョンアップ(1998/11/03)

　Kernel を 2.0.33 から 2.0.35 へバージョンアップしました。なぜかといいますと、Oracle for Linux を入れるための下準備なんです。Oracle for Linux は想定しているカーネルバージョンが 2.0.34 （以上？）となってます。幸いにも TurboLinux は、CD-ROM に 2.0.34 のパッケージが入っています。これをインストールすればOKです。しかし、私は 2.0.34 をパスして、現在、安定板の最新である 2.0.35 をインストールすることにしました。Ring Server は有難いことに、kernel.org のミラーがあります。そこで So-net のサーバーから取ってくることにしました。ちなみに Ring Server がミラーしてくれているリソースは膨大です。特に Linux 関連は殆どのディストリビューションについてミラーしてくれています。当然、GNU や XF86Free 関連のリソースもミラーされています。大抵のものは、ここで用が足りてしまいます。

　さて、以下がカーネル再構築記録です。Linux カーネル再構築は初体験です。ドキュメントを読みながら行いましたが、初体験が故の苦労もありました。笑ってやってください。

  • アーカイブを展開アーカイブを /usr/src へコピーし、tar xvzf linux-2.0.35.tar.gz で展開する。/usr/src/linux のリンクを /usr/src/linux-2.0.35 へ張り替える。
  • コンフィグ/usr/src/linux-2.0.35 で make xconfig する。しかし、設定項目の多さに唖然としました。最初のうちはヘルプを見ながら設定していたのですが、敢え無く挫折。とりあえず、現在の設定項目をチェックすることにしました。/usr/src/linux-2.0.33 へ移って 同じように make xconfig を行い、現在の設定を参照するという原始的手法にでました。（笑） 設定を進めるうちに、新しく設定項目が増えていたり、逆になくなったりするものがあります。これらは、ヘルプを参照しつつ設定しました。そして、明らかに使わない機能やドライバはざっくり削除しました。少々戸惑ったのは、サウンドの設定です。TurboLinux では、サウンド関係のドライバを Module として読み込むことができますが、本家のカーネルではできないんですね。私は SB16 を使っているのですが、IRQ, DMA の設定がデフォルトと違います。今までは、ドライバを動的に読み込ませて /etc/conf.modules のパラメータ指定で設定させてました。しかし、本来のカーネルでは、サウンド機能については「組み込む／組み込まない」の二者択一です。これは、今回初めて知りました。（笑）確かに、2.0.33 の サウンド関係モジュールのソースには、動的読み込みのためのパッチがあたってました。ディストリビューションとしてインストール設定を容易にするための工夫なんでしょうね。後、戸惑ったのは、ファイルシステムの設定に「コードページの設定」が増えていました。どうやら、FAT 関連や CD-ROM 関連で Native Language を使うための設定のようでしたが、よくわからないので、こいつはモジュールとして作ってしまいまいした。
  • カーネルの作成make dep; make clean してから、make zImage する。これで /usr/src/linux-2.0.35/arch/i386/boot/zImage が作成されます。
  • モジュールの作成とインストールmake modules; make modules_install する。make modules でモジュールが作成され、make modules_install で、/lib/modules/2.0.35 へモジュールがインストールされます。
  • カーネルの（仮）インストール/usr/src/linux-2.0.35/arch/i386/boot/zImage を /boot/vmlinuz-2.0.35 としてコピーする。/usr/src/linux-2.0.35/System.map を /boot/System.map-2.0.35 としてコピーする。コピーした System.map-2.0.35 に System.map のリンクを張りなおす。
  • mkinitrd の実行/etc/conf.modules に必要事項を記述した後に、mkinitrd -f /boot/initrd 2.0.35 する。これを実行する必要があります。実は、これをしなかったためにはまってしまいました。起動時に、SCSI Driver をロードしようとすると、2.0.33 用だからロードできないよと怒られました。その他にも色々とエラーを出してくれます。私は、これが必要だと気づくまでに相当時間を要してしまいました。ちなみに、/etc/conf.modules は、TurboLinux のカーネル設定ユーティリティを使って作ることができます。私は、直接編集しました。気をつけないといけないのは、サウンド設定が入っている場合は削除しておくことです。サウンドはカーネルに組み込まれていますので、TurboLinux のようにモジュール指定できません。
  • lilo の設定/etc/lilo.conf に新しいカーネルを登録する。（テスト用） 以下の内容を登録して lilo を実行する。image=/boot/vmlinuz-2.0.35 label=linux-test root=/dev/hda1 <- 私の場合 initrd=/boot/initrd read-only
  • 新カーネルのテストリブート後、lilo プロンプトで、テスト用に登録した linux-test をタイプする。
  • 最終設定新しいカーネルが正しく動いていることが確認できたら、/boot/vmlinuz に /boot/vmlinuz-2.0.35 をリンクしなおす。また、/etc/lilo.conf に追加したテスト用の設定を削除して、lilo する。

　使わない機能を削ったので、新しいカーネルのサイズは小さくなるものと思ってましたが、逆に大きくなっていました。386 指定ではなく PENTIUM を指定してコンパイルしたからかもしれません。

よくわからないロケール(1998/11/09)

　どうも TurboLinux のロケールの扱いがよくわかりません。別に不都合があるわけではありません。自分の理解不足からくる疑問なんです。TruboLinux は、libc と glibc の両方がサポートされています。本来ロケールを正しく扱うことができるのは、glibc のみです。（元々の glibc 日本のロケールはしていないそうです）ところが TurboLinux では、ja, ja_JP.EUC, ja_JP.eucJP, ja_JP.ujis, ja_JP.iso2022jp, js_JP.jis, js_JP.sjis なんかが入っています。それから、i18n にも ja_JP が存在します。でも、ちゃんと実装されているかどうかは疑わしいです。テストプログラムを書いてみてみると、ちゃんとロケールは取れてますけど、中に入っている情報はまがいものです。通貨記号は $ が返ってきます。

　また、ややこしくしているのが、X_LOCALE です。これは、libc でロケールがまともに扱えなかった時代に X 側で提供していたものなんですが、TurboLinux では、libc のために X_LOCALE も使えるようになってます。この選択は現実的な選択だと思うのですが、「いったいこのプログラムはどのロケール使ってるんだろう」と思うことも、しばしばです。RedHat なんかは、X_LOCALE は捨てているそうです。でも、これだと glibc が日本をサポートしていない関係から困ってしまうことになり、X を X_LOCALE 付きで再コンパイルし、ソフト側では X_LOCALE を使うか、あるいは、glibc を改造して日本をサポートするようにしければならないようです。　

　TurboLinux は、できあいの日本語環境が簡単に手に入るので「色々と勉強したくない向き」には便利なディストリビューションです。たぶん、できあいの環境のまま使う限りはそんなに問題は発生しないでしょう。ただ、その環境に満足できなくなった時に、ちょっとした苦労を強いられます。例えば、ソフトのバージョンアップなんかがそうですね。TurboLinux のサイトには、TurboLinux にマッチしたパッケージを置いていません。contrib なんてのがありますけど、その中には RedHat 系のものが多いんじゃないでしょうか。そういうパッケージを入れると、/usr/local へ放り込まれます。まだ、それは良いとして、パッケージ名が違ったりするとコンフリクトさえ検出されないことになります。パシフィック・ハイテック社は、ここらへんの状況改善に力を入れて欲しいです。内部では作業をやっていると思われます。それが証拠に、今度出る 3.0 では４００あまり（だったかな？）のパッケージに手を入れたそうですからね。それを現 2.0 にもフィードバックして欲しいですね。3.0 のパッケージが 2.0 では使えないなんてことにならないことを願います。と、最後は、ロケールの話ではなくなってしまいました。（汗）

TurboLinux の XEmacs (1998/11/11)

　最近、デフォルトのエディタは XEmacs 20.4 です。昔は、Mule 使いでしたので、当初は Mule のほうを使っていましたが、XEmacs のカッコイイ画面を見てからすぐに乗り換えてしまいました。（ミハーだ） ちょっとしたファイルは vi でやってしまいますけど、こちらは、jvim を使ってます。元々入っている vi は国際化されているものなのですが、日本語文書を最初から入力すると化けてしまいます。jvim のほうはそういうことがありませんのでこちらのほうが安心です。ONEW の Wnn 対応版に入れ替えてますんで kinput2 いらずというところがミソです。（笑）

　さて、XEmacs の話からそれてしまいましたので元に戻します。で、TurboLinux にパッケージされている XEmacs を何も考えずに使っていたわけですが、ふと、VM を使ってみようとしたら使えませんでした。色々探ってみたものの、わからずに「まあいいか」と放っておくことにしたのですが、調べる過程で、日本語メニューを表示するリソースファイルを見つけました。さっそく、リソースを読み込んでみたんですが、バケバケで玉砕です。（笑） インターネットで検索したところ、configure のオプション指定で表示させることができるということが判明。たぶん、ソースパッケージから作りなおせば大丈夫なんじゃないかと思いまして、TurboLinux のソースパッケージをインストールして SPEC ファイルを見てみることにしました。どうやら –with-xfs という X のフォントセットを使うようにする指定がポイントのようなのですが、Motif のある環境では –with-xim=motif という指定でもOKのようです。TurboLinux には lesstif という Motif 互換のウィンドウマネージャーが入ってます。ですから configure で自動検出されてしまうはずなんですが、なぜ検出されなかったのか？という疑問が沸いてきました。

　とりあえず、元のままリビルドしてみようと思いまして、/usr/src/redhat/SPECS で rpm -ba xemacs.spec したら動かない！！このスペックファイルは腐ってます。本当にこれでパッケージを作ったのか？と思いつつも、仕方ないので、中身を追いかけて、パッチを当てて configure してみました。ところが、make でエラーが出ます。config.log を見ると、不思議なことに標準ライブラリが検出されていません。「なぜだ！！」という思いを抱きつつ、今度はオプションなしで configure してみると、不思議なことに大丈夫です。色々試行錯誤の結果、–with-wnn6 オプション指定が悪さをしていることが判明しました。で、ここで思いっきり気づきました。Wnn6 の SDK をインストールしてないじゃないか。さっそく、/usr/jp/OMRONWnn6/sdk にある TurboLinux 用のアーカイブを展開して、もう一度 configure してみますとうまくいきました。最終的には、xemacs.spec に記述されている configure のオプションに –with-xfs を追加しただけです。元々 LDFLAGS=/usr/jp/lib という環境変数を定義して configure するようになってますが、これは –site-libraries=/usr/jp/lib というオプション指定でもかまわないはず。以下が、今回の configure です。./configure –site-libraries=/usr/jp/lib \ –prefix=/usr –lockdir=/var/lock/xemacs \ –with-mule –with-canna \ –with-wnn6 –with-xfs –with-dialogs=athena \ –debug=no –error-checking=none

スペックファイルでは、configure した後に、Dynamic Link Library 版と Static Library 版を作ったりして、ごちゃごちゃやってますけど、全て無視して make してしまいました。やたら長時間の make の後、作成された xemacs をテスト起動すると、ちゃんと日本語メニューが表示されました。ただ、デフォルトのリソースがヘクッててバカでかい字で表示されました。（笑） まあこれは後で直すとして、とりあえず make install しました。スペックファイルをざっと見たら、インストールされる movemail というプログラムだけは chgrp mail して chmod 2755 してやる必要があるようでしたので、こいつは手動でやりました。

　で、目出度く日本語メニューが表示されるようになりましたが、ちとかっこ悪いです。メニューが Motif のようにボタンになってれば見栄えもするんですが、いかんせん Lucid なんで、昔の Windows 3.1 のような感じです。その上、英字と日本語のフォントサイズのバランスがガタガタです。努力の割にはあまり報われない結果となりました。しかし、副作用としてVMが普通に動くようになりましたので良しとしまた。（笑）

　ということで、これで終わるはずでしたが、TurboLinux のパッケージがあまりにも酷いので、興味本位ではありますが JRPM で配布されている xemacs を取ってきて比べてみました。こちらのパッケージは、「かんな対応版」「Wnn6対応版」「かんな、Wnn6対応版」「Wnn4対応版」「かんな、Wnn4対応版」「日本語入力システム非対応（SKK用）」が作れるようになっています。これを TurboLinux でリビルドするには、configure の –site-includes　や –site-libraries を書き換えないといけませんけど（これは仕方ない）、元々ちゃんと –with-xfs も入ってますので、普通の環境ならメニューの日本語表示も問題ないはずです。やはり、パッケージも作り手次第ということがよくわかりました。せっかくですので、スペックファイルを TurboLinux 用に手直ししてビルドしてみたところ、なんと日本語メニューでのフォントのガタガタ問題もなくなってしまいました。パッチが違うんでしょうかね。まあ、結果オーラーイということでこちらのパッケージを入れました。で、これが画面です。

　今回の件で TurboLinux のソースパッケージは信用しないことにしました。（笑） TurboLinux の xemacs.spec は、rpm 自身が解釈できない代物です。rpm のバージョンの違いによるものなのか、作成環境の違いなのかはわからないんですけど、一般的にソースパッケージってこういうものなんでしょうか？ちなみに、TurboLinux の XFree86 のソースパッケージもダメですね。パッチを当てる段階でこけてました。TurboLinux 用に特化したパッケージを作っているのだから、本来作りやすいはずなのに、変なことになってるなんてどうかしてるとしか思えませんね。

Ghostscript 5.10 (1998/11/12)

　Ghostscript は商用用途での使用に制限があるために、TurboLinux では、バージョン 3.33 が入っています。ですので、TurboLinux の環境で Ghostscript を 5.10 にするために PJE で配布されているものをインストールすることとなります。すると若干の問題が生じます。PJE のパッケージは /usr/local をインストールベースとしていますが、TurboLinux では /usr をインストールベースとしているからです。インストールベースが違うので共存することは可能です。3.33 を削除しなければよいのです。ただし、この場合プリンタ出力は 3.33 のままです。試しに 3.33 を削除してしまうと出力できなくなってしまいました。これは、たぶん出力フィルターを書き換えてやることで対処できると思います。あるいは、/usr ベースでコンパイルしなおしてインストールすればよいはずです。

　私は、まず出力フィルターを追っかけることにしました。しかし、どこでディレクトリ依存しているのかを見つけることができませんでした。そこで、5.10 のソースパッケージを /usr ベースでパッケージを作りなおしてアップデートインストールしました。表示、出力とも特に問題なく動いてます。

　UNIX ソフトがディレクトリ構成に依存するのはソースが公開されているからこそ成せる技なんですが、バイナリ配布の場合は問題が生じますね。その点バイナリ配布主体の Windows な世界では、ディレクトリ依存するようなソフトはダメとされてます。UNIX ソフトも、そろそろこういった点を考慮してソフトを作成していかないといけない時期にさしかかっているんじゃないかと思います。

独自のパッケージを作ればいい (1998/11/12)

　RPM の恩恵（依存関係やコンフリクトの検出）を享受するためには、全てを RPM でインストールできればよいわけですが、最新のバージョンなんかは、tar アーカイブでは手に入るものの RPM パッケージが手に入らないこともしばしばです。また、見つけた RPM をインストールしようとすると、ディレクトリ構成の違いや、ライブラリの整合性で問題があったりして使えないこともあります。

　そこで、ひとつの解決策が「自分用の独自パッケージを作る」という方法です。こうしてやれば、インストールソフトの管理を RPM に任せることができます。私は、先日の XEmacs や Ghostscript をパッケージにしました。既存のソースパッケージから自分専用のバイナリパッケージを作るのは SPEC ファイルの修正だけで比較的簡単にできます。SPEC ファイルの書き方に慣れれば、tar アーカイブからパッケージにするのも難しくないでしょう。

　RPM パッケージの作り方は、HOWTO 文書にありますので、それを見ればやり方がわかります。と言ってしまうと、あっさりしすぎでしょうから、今回、パッケージ化した Ghostscript の作成手順を記します。

  • ソースパッケージの展開普通は、XXXX.src.rpm というファイルがあって、これを rpm -ivh XXX.src.rpm とすれば、/usr/src/redhat にある SOURCES と SPECS にソースアーカイブとスペックファイルが展開されます。Ghostscript 5.10 の場合は、rpm ではなくて、ソースアーカイブとスペックファイルが提供されていますので、これらを GET して、手作業で各ディレクトリに展開することになります。[/usr/src/redhat/SOURCES に展開するファイル] ghost.gif ghostscript-5.10.tar.gz ghostscript-5.10gnu.tar.gz ghostscript-5.10jpeg.tar.gz ghostscript-5.10libpng.tar.gz ghostscript-5.10zlib.tar.gz ghostscript-fonts-other-5.10.tar.gz ghostscript-fonts-std-5.10.tar.gz [/usr/src/redhat/SPECS に展開するファイル] ghostscript-5.10j2.0.spec
  • BUILD 用のソースを展開とりあえずは、ソースを展開してパッチを当てるところまでやってみます。SPEC ディレクトリで、rpm -bp ghostscript-5.10j2.0.spec とやれば、スペックファイルの記述に従って、/usr/src/redhat/BUILD に、ソースファイルが展開され、パッチをあててくれます。ghostscript の場合は、gs-5.10 というディレクトリが作成されます。ghostscript の場合は大丈夫なんですが、この段階がうまくいかないパッケージもあります。例えば、TurboLinux の XFree86 はパッチがうまくあたりませんでした。こういう場合は、スペックファイルの %prep という段階を見ながら、手作業でやることになってしまいます。問題点を見つけて修正してやる必要があるので面倒です。
  • 自分の環境用にMAKEするためには？SPEC ファイルの %prep 及び %build の記述を見ますと、%prep %setup -n gs5.10 %setup -T -D -b 1 -n gs5.10 %setup -T -D -a 2 -n gs5.10 %setup -T -D -a 3 -n gs5.10 %setup -T -D -a 4 -n gs5.10 %setup -T -D -a 5 -n gs5.10 patch -p1 <gs510j20.diff ./tar_cat ln -s unix-gcc.mak Makefile chown -R root.root kanji %build make となっています。ソースアーカイブを展開した後、gs510j20.diff というパッチをあてます。./tar_cat なるスクリプトを動かした後に、unix-gcc.mak を Makefile にリンクを張ってます。この Makefile を使って make しているようです。configure 機構がある場合は、./configure –prefix=/usr 等とSPECファイルを変更すれば、事足りるんですが、ghostscript の場合は、configure 機構がなく、あらかじめ準備されている Makefile のうち自分の環境に適合するものを使うようになっているようです。そこで、BUILD/gs-5.10 の Makefile を見てみると、prefix=/usr/local という記述があります。こいつを prefix=/usr とすることでインストールベースを変えることができそうです。これで、方針が決まりました。うまくいけば、make prefix=/usr としてやればOKのはずです。ただ、make できなければ、パッチを当てる必要があるかもしれません。とりあえずは、基本どおり（？）パッチをあてる方向で作業を進めます。
  • オリジナルソースの保存BUILD に作成された gs-5.10 を gs-5.10.orig にして置いておきます。これは、後で差分を作るための元となるソースとなります。（パッチ済みの状態から新たに独自のパッチを当てることにします。）
  • Make してみる再度、最初の手順どおりにソースファイルを展開してやって、BUILD に gs-5.10 を作成します。その中で、先程たてた方針で大丈夫かどうか確認します。Makefile の prefix を /usr に変更した後に、make してやります。エラーがでなければとりあえずOKです。なんらかのエラーが出るようなら、その原因を追求して修正してやります。たいがいの Warning は無視して済みますけど、make が止まってしまうエラーは話になりません。
  • パッチの作成make が通るようになったら、make clean しておいて差分をとります。先程保存しておいた gs-5.10.orig との差分をとることになります。BUILD ディレクトリで、diff -uNr gs-5.10.orig gs-5.10 > ../SOURCES/gs-5.10TL.patchで、パッチが作成されます。ちなみに、Makefile で prefix を変えてやるだけで済むのなら、スペックファイルの修正だけで済みます。make prefix=/usr とするだけで引数指定のほうが優先されるわけです。ソース修正が必要だったり、Makefile 自身の修正がからむなら、こうやってパッチを作成しなければならないでしょう。
  • %prep 段階のスペックファイル修正%prep 段階の修正が必要となります。元々行っている作業はそのままにして、%prep の最後にパッチをあてる作業を追加してやることになります。まずは、作成した gs-5.10TL.patch の存在を知らしめる記述を書き加えます。Source0: ftp://ftp.cs.wisc.edu/ghost/aladdin/ghostscript-5.10.tar.gz Source1: ftp://ftp.cs.wisc.edu/ghost/aladdin/ghostscript-5.10gnu.tar.gz Source2: ftp://ftp.cs.wisc.edu/ghost/aladdin/ghostscript-5.10jpeg.tar.gz Source3: ftp://ftp.cs.wisc.edu/ghost/aladdin/ghostscript-5.10libpng.tar.gz Source4: ftp://ftp.cs.wisc.edu/ghost/aladdin/ghostscript-5.10zlib.tar.gz Source5: ftp://ftp.jaist.ac.jp/pub/os/linux/PJE/sources/gs510j20.tar.gz patch0: localhost:/gs5.10TL.patch 最後の行が追加した記述です。このパッチを当てるように指示するのは %prep 段階の最後です。%prep %setup -n gs5.10 %setup -T -D -b 1 -n gs5.10 %setup -T -D -a 2 -n gs5.10 %setup -T -D -a 3 -n gs5.10 %setup -T -D -a 4 -n gs5.10 %setup -T -D -a 5 -n gs5.10 patch -p1 <gs510j20.diff ./tar_cat ln -s unix-gcc.mak Makefile chown -R root.root kanji %patch0 -p1 最後がパッチの指示の記述です。
  • BUILD 用ソース展開テスト修正した SPEC ファイルとパッチで、正しくソースが展開できるかテストします。再び、rpm -bp ghostscript-5.10j2.0.spec として、正しくパッチがあたったソースが出来ればOKです。
  • BUILD 段階の最終テスト%build 段階のテストを行うには、rpm -bc ghostscript-5.10j2.0.spec とすればできますが、実際には、このテストはやりませんでした。make するだけですし、既に make が通ることは確認できてますから。他のパッケージでは、この段階のスペックファイルの修正が必要な場合もあります。例えば、configure 機構を持つものは、%build 段階の最初で ./configure を走らせます。そういう場合は、この段階までテストして、ちゃんと make できるかどうか確認しなければなりません。
  • パッケージ作成のためのインストール検証RPM は一度インストールしてから、それをパッケージにするという手順を踏みます。make install してしまうと既存の環境を壊してしまうことになり不都合が生じます。（不都合がない場合はやってもよいんですが）そういうことにならないために、インストールするルートを変更して、いったんそこへインストールしてからパッケージを作成するという機構が用意されています。スペックファイルに BuildRoot: ルートディレクトリ と記述しておけば、スペックファイル内では $RPM_BUILD_ROOT として参照できるようになります。Makefile のほうは、インストール時に make prefix=ルートディレクトリ/usr install としてやれば、インストールベースを変更できるはずです。そこで、gs-5.10 で、make; make prefix=/var/tmp/gs5.10-root/usr install して実験してみます。やってみると、エラーが発生しました。ディレクトリが存在しないことが原因のようです。そこで、/var/tmp/gs5.10-root 以下に必要なディレクトリを作成してやります。これは、後でスペックファイルの修正の記述に必要な項目となります。このようにして、インストールが成功するまで原因を追求して解決します。
  • %install 段階のスペックファイル修正まずは、元々のスペックファイルを見てみます。make install ln -sf /usr/local/share/ghostscript/5.10/READMEs /usr/doc/ghostscript-5.10j2.0 strip /usr/local/bin/gs となっています。要は make install して、必要なリンクをはった後で、strip しているだけです。先程のインストールテストの結果から、まず、パッケージ作成するためのルート指定を組み込むことが必要であること、次に、インストール前には、あらかじめディレクトリを作成しておく必要があることがわかっています。make install 時には、make prefix=/var/tmp/gs-5.10-root/usr としなければなりません。また、/usr/local を想定しているパス指定は /usr に変更しなければなりません。
  • インストール段階のテスト修正したスペックファイルが正しいかどうか検証するためにテストします。rpm -bi –short-circuit ghostscript-5.10j2.0.spec –short-circuit の指定で、インストール段階のみのテストを行うことができます。テストしたところ、ps2jpdf がインストールされないと怒られてしまいました。Makefile を見ると、確かにインストールされていませんでしたので、Makefile を修正して再び差分をとりました。もう一度、最初からテストです。rpm -bi ghostscript-5.10j2.0.spec で、インストールまでのすべての段階がうまくいくことが確認できました。
  • パッケージの作成最後は、パッケージの作成です。rpm -ba ghostscript-5.10j2.0.spec これで、ソースパッケージとバイナリパッケージが、SRPMS 及び RPMS/i386 に作成されます。

　実際のケースを例に簡単に書くつもりでしたが、簡潔に書くことは難しいですね。新たにパッケージを作成するむきには HOWTO にある RPM+Slackware.euc.gz, RPM-BUILD-HOWTO.euc.gz, RPM-HOWTO.euc.gz あたりを見てもらったほうがわかりやすいでしょう。

PC Xサーバー(1998/11/13)

　以前、「開発日誌」で「Windows を X 端末化してしまえ。」と述べました。私自身は、数年前に某プロジェクトで PC X サーバーを実際に使っていたのでどういうものか知ってたのですが、今回 ASTEC-X という製品の体験版を入れてみましたのでスクリーンショットなんぞを紹介したいと思います。

　まず、安心なのは日本製だということです。日本の環境が考慮されていることは言うまでもありません。導入、設定も至って簡単で好感が持てました。まあ、製品の宣伝をあまりやっても、私が得することはありませんから、スクリーンショットを見てやってください。まず、最初は、XDMCP を使ってログイン画面が出たところです。xdm じゃなくて、ごめんなさいです。（笑） この他に rexec してターミナルを立ち上げたり、telnet 接続からターミナルを立ち上げたりすることも可能です。次は、ログインして Windows 98 のデスクトップにアプリケーションを立ち上げた画面です。最後に、X のルートウィンドウを表示してメニューなんかを表示してみた画面です。このように、シームレスに統合できるところが凄いですね。X プロトコルさえ喋れればこういったことが可能になるんですね。

　まあ、これが現実的にどういうメリットがあるのか？と問われれば答えに窮してしまいます。（可能性がありすぎてね）UNIX をサーバーとして Windows のクライアントの開発やってる現場では、こういった環境はことのほか便利であることは事実です。「telnet できればいいじゃん」という説もありますが「X できればもっといいじゃん」ということです。

Kernel 2.1.128 (1998/11/16)

　今年のクリスマス頃には、Kernel 2.2 がリリースされるそうですね。現在の最新版がどういうものなのか知りたかったので Kernel 2.1.128 を試してみました。make にあたっては設定項目がかなり増えているので往生しましたが、試行錯誤の末になんとか動かすことに成功しました。

　いったい何が変わっているのかをきちんとレポートしたいのですが、悲しいことに技術的な詳細を見極める目を持っていません。また、膨大なドキュメントを追いかけるのも大変ですので、無謀な比較とは思いますが Configuration の項目の違いから見てみたいと思います。現時点における、安定版、先進版の最新版は、2.0.35 と 2.1.128 です。この２つを make xconfig した画面から見てください。2.0.35 はこちら、2.1.128 はこちらです。設定項目の分類が増えていることにまず目がいきます。分類が増えたぶん中身はすっきりとまとまっています。

　さて、各項目ごとに目についた違いは以下のとおりです。

  • Processor type and featuresPentium Pro、Pentium II のために MTRR(Memory Type Range Register) Support という項目が追加されています。AGP バスのためのもののようです。現在 BIOS が抱えている問題に対処できるようです。
  • Plug and Play supportどのレベルで Plug and Play できるのかわかりません。ドキュメントには書いてある？
  • Block devicesサポートされる DMA chipset や、IDE chipset の種類が増えています。また Network block device がサポートされています。
  • Networking options設定項目が細分化されてます。また、サポートされるプロトコルや機能が増えてまして、私にはわけがわからない状態です。（涙） 最初のカーネル構築の際に適当に設定したらまったく動きませんでした。勉強します。
  • Network device supportサポートされる NIC が増えています。WAN drivers が増えていることが大きな違いですね。X.25 や Frame Relay 等がサポートされます。
  • Amateur Radio support別項目になっただけあり色々と増えているようです。私には何なのかまったくわからないです。
  • Caracter devicesUnix98 PTY support というのが大きな変更のようですね。Video For Linux、Joystick support というのも目をひきます。
  • FilesystemsApple Macintosh filesystem support というのが目をひきました。読み取りのみですが、NTFS や Solaris (x86) のパーティションもサポートされています。
  • Console driversAmiga, Mac, Sparc 等の機種ごとの設定や、ビデオカードのサポートがなされています。
  • Soundすっきりとモジュール化されてます。サポートされるカードやチップの種類も増えてます。

重要な違いを見落としている可能性は大です。追々、勉強しつつ気づいた点をレポートします。

　さて、実際にカーネルを試した感じでは、先進版とは言え十分に安定して動いております。これは特殊な機能を使っていないためかもしれません。安定板と比較して全体的にサクサクと動いてくれますね。特にネットワーク関係で実感できます。これはますます、2.2 のリリースに期待が持てそうです。

SAMBA で大文字、小文字 (1998/11/17)

　SAMBA へファイルをコピーしたり、新規ファイルを作成したりするとファイル名が全て小文字になってしまっていました。今まで別に不都合を感じてなかったので放っておいたんですが、本格的に使い始めるとやはり気持ち悪くなってきました。さっそく調べてみると、mangle case = no case sensitive = no default case = upper preserve case = yes short preserve case = yes

という設定が必要なようです。HOWTO にちゃんと書かれているんですね。最初から読んでおけばよかったです。（笑）で、以前紹介した smb.conf は更新しました。

PC X サーバーは便利 (1998/11/17)

　この前紹介した ASTEC-X は、ちょっと手放せないなあと思い始めてます。（私の悪い癖です） 同じデスクトップで Windows と UNIX 両方のソフトが使えるのは本当に便利です。開発環境として便利だというのは前に述べたとおりなんですが、通常の使用でも色々と便利であることに気づきました。例えば、ちょっとしたテキスト処理はシェルスクリプトにやらせてしまえます。フルセットの Emacs が使えることも魅力ですね。それから画像処理も便利です。スキャナで取りこんだ画像やビデオキャプチャしたものを Gimp で編集できます。Windows と UNIX の良いとこどりして上手く使い分けることができるんですね。こういった作業で、裏で活躍してくれているのが SAMBA なんですよね。昔だったら「PC NFS を導入してマウントする」とか「ftp で転送する」とか「kermit で転送する」とか、何かと手間がかかったものですが、SAMBA のおかげで手軽に共有環境が構築できます。問題となるのはテキストの場合で、S-JIS と EUC の違いだけは気をつけておかないといけません。Emacs はセーブするときに S-JIS にしてやれば済む話ですけどね。

　さて、PC X サーバーはバカ高いというのが通例です。Free ではMIX というのがありますけど、ASTEC-X のような使い勝手はありません。ASTEC-X の定価を調べてみますと、\78,000でした。こりゃ個人には手が届かない（Visual Studio よりは安いか）と、ASTEC のサイトを去ろうとした時に「個人向け販売」というページの存在に気づきました。なんと、個人での利用の場合に限って \39,000 だそうです。頑張れば手が届く価格ですね。所定の注文書をFAXすれば、カード決済で手に入るようです。こういうお手軽な注文ができると私は非常に弱いです。でも、この時期に税込み４万弱の出費は痛いです。試用期限は今年いっぱいなんでそれまで使わせてもらってから考えようと、やっと踏みとどまった次第です。（笑）

Kernel 2.0.36 (1998/11/18)

　安定板の 2.0.36 がリリースされました。SunSITEにミラーされてます。RingServer ももうすぐでしょう。

やっちまった (1998/11/21)

　せっかく、調子よく動いてくれていた TurboLinux ですが、私の大ポカのために再起不能になってしまいました。（涙）

　事の原因は PJE 0.3alpha の libwcsmbs-0.0.4-3.i386.rpm を試したことでした。これを入れると、glibc の差し替えなしで日本語ロケールが扱えるようになるとの情報を得て、「えいや！！」と入れてしまったのです。その直後からおかしくなってしまいました。全てのコマンドが core を吐いて落ちてしまうようになってしまったんです。ls や cp さえもできない始末。telnet 接続もできませんし ftp もできません。この状況の中、とりあえず生きている SAMBA から Windows へデータをバックアップしました。日頃、SAMBA の共有領域へ必要なデータをバックアップしていたのが幸いでした。lib がやられてしまったわけですから被害は甚大です。恐らく、ログアウトしたなら二度とログインしないであろうし、シャットダウンしたらもう二度と立ちあがらないであろうということはバカな私にも想像がつきました。

　バックアップ終了後、X を殺してログアウトしましたが、やはり2度とログインできない状態でした。ログインマネージャも死にました。login プロンプトから Ctrl-C しても、シャットダウンプロセスが途中でストップです。やむなくハードリセットをかけて再起動させましたが、ＯＳは２度と立ちあがってくれませんでした。（涙）

　主要なバックアップがとれていたこともあり、ダメージはそう大きくはなかったものの、再インストールするしか術がなくて半日を費やしてしまいました。まったく今回の件は我ながら情けない結果になってしまいました。（笑ってやってください）

　ついつい調子に乗って色々やっているうちに警戒心が薄れてしまっていたようです。こういう場合の復旧は本来どうすべきなんでしょう？ワークステーションで仕事してた時は、テープやCD-ROM からブートして、手動でファイルシステムをマウントすることができました。こういったことができるように、最小セットのディスクを作っておけば役に立つはずなのですがどうやって作ればいいんでしょう？そももそもディスク１枚に入るのか？あるいは複数に分けて作れるのか？なんともまあお寒い危機管理だこと。（苦笑） これはさっそく勉強せねばなりませんね。

緊急用起動ディスクの作成 (1998/11/26)

　大ポカによるトラブルを経験した私は、真面目に緊急用の起動ディスクの作成について調べました。HOWTO にあった Bootdisk.euc.gz をプリントアウトして理解することから始めました。わかったことは、ブートディスクというカーネルのみをブートするディスクと、ルートディスクというルートファイルシステムの入ったディスクの２枚構成が可能であることです。FDに書きこむカーネルに対してディスク交換フラグをセットしてやれば、カーネルが起動した後に２枚目のディスクを挿入するようにプロンプトが表示されるようになります。２枚目のルートディスクには、ルートファイルシステムを圧縮したものを書きこんでおけば、それを読みこんで RAM DISK に展開してルートとしてマウントしてくれます。

　実際に作成してみますと、色々と難問に遭遇して未だ成功するにいたっていません。ブートディスクは簡単に作れますが、ルートディスクのほうが難しいです。まずは容量の問題です。圧縮して 1.44Mbyte に押し込めるわけですが、3.8Mbyte 弱が精一杯といったところです。必要なコマンドの libc が２種類（libc5 と glibc）あって、それが容量を圧迫する一因となってます。とりあえず、起動に最低限必要と思われるものをつめこんで、起動プロセスの設定ファイル類を適当に修正してやってみましたがダメでした。ルートが Read only でマウントされてしまい、/etc/mtab が書けないと怒られて中断してしまいました。起動プロセスについての理解が乏しいために何をどうしたらよいかわからない状態です。

　うーーん、どうすればうまくいくんでしょうね。敗因は、ろくな知識もないのに２枚構成にしたことです。初めは１枚でやることから出発したんです。でも、容量不足に泣かされために方針転換してしまったわけです。もう一度基本に立ち返って１枚構成の起動ディスクを作成することから始めたほうがよさそうです。

プライベートパッケージ (1998/11/26)

　自分用の独自パッケージを作ることで、インストールソフトの管理が楽になることを前に書きました。TurboLinux は、既存のパッケージを入れるとおかしくなることがたまにあるので、ソースパッケージから TurboLinux 用にパッケージを作成しなおすといった作業をよく行います。殆どは SPEC ファイルの修正作業ですけどね。最近は SPEC ファイルの書き方にも慣れてきましたので、tar アーカイブからパッケージを作成できるようになりました。

　そこで、自分用に作成したプライベートなパッケージを置く場所を作ろうと思います。自分の環境でのみ検証されたものですから、他の環境で動くことは保証できません。Turbo Linux 用に調整したものですからソースパッケージなんかは役に立つかもしれません。

緊急用起動ディスクの作成２(1998/11/27)

　仕事の合間に緊急用の起動ディスクの作成をやっていたのですが、ようやくシングルモードで起動することができました。ディスクは２枚＋αです。起動用のブートディスクと、圧縮されたルートシステムが入ったルートディスク、それに、メンテナンス用のツールを入れたユーティリティディスクという構成です。最後のユーティリティディスクはブートには関係ありません。さっそく手順を書きたいところですが、あまりにも面倒なんでやめときます。（笑） HOWTO を見ればできます。と言いたいところですが残念ながら TurboLinux ではうまくいきません。ルートディスク作成時に用いるループバックデバイスの扱い方に若干の難がありました。私は、/sbin/mkinitrd のシェルスクリプトを参考にしました。これを読めば、ループバックデバイスの基本的な使い方がわかります。また、HOWTO は libc5 の Slackware ベースでの説明ですから、全てそのとおりにというわけにはいきません。例えば、ルートディスクに入れるコマンド類は TurboLinux では非常に限定されたものになります。前にも書きましたが、libc5 と glibc2 の２種類のライブラリを準備しなければならないことや、PAM 関係のライブラリや設定ファイルが必要になったりします。ですから、ルートディスクには起動プロセスに必要となるコマンドを入れるだけで精一杯でした。別途ユーティリティディスクを作ったのはこのためです。起動後にこれをマウントするようにしたわけです。作成前に把握しておかなければならないのは、/dev 以下に何が必要かということ。これは、/dev/MAKEDEV を見ればあらかた見当がつきます。次に起動プロセスについて理解することが大事です。/etc/inittab の設定に従って /etc/rc.d/rc.sysinit -> /etc/rc.d/rc -> rc?.d という流れで進行します。/etc/inittab のランレベルは 1 に設定して、/etc/rc.d/rc1.d の S??single 以外は削除してしまいます。この流れの中から、詰め込むコマンドｊを洗い出します。そして、それぞれのコマンドについて必要なライブラリを ldd で調べて lib 以下に放りこみます。これら必要なもの全てを圧縮して 1.44Mbyte 以下になればOKです。ルートディスクができれば、ブートディスクから実際に起動させてみてトライアンドエラーの繰り返し作業となります。これに時間がかかるんですね。でも、作業自体は単純です。止まったらエラーの原因を調べ、原因を取り除いてから、フロッピーに書きこんで再テストするだけです。この作業はマシンが２台ないと大変です。私はテスト用に ThinkPad 230 Cs を使いました。

　CD-ROMからブートできれば一番いいんですがねえ。配布 CD-ROM からメンテナンスモードでブートすることができればこういう苦労はしなくても済むのになあと思います。

RedHat 5.2 が気になる(1998/11/28)

　RedHat 5.2 が気になってます。PJE の 0.3 を入れれば日本語化できるんだろうか？ Vine Linux も気になりますね。こちらは RedHat 5.x ベースの日本語ディストリビューションで、来年の１月にリリースされるらしいです。これを待つのも手ですね。

    タイトルとURLをコピーしました