- Wnn6 マイナーバージョンアップ (1999/03/02)
- Wnn6 オムロンソフトウェアの回答 (1999/03/03)
- TurboLinx 3.0 アップグレード版 (1999/03/05)
- ブートペンギンの拝み方 (1999/03/08)
- Window Maker 0.51.1 (1999/03/10)
- Samba のトラブル (1999/03/10)
- Kernel 2.2.3 (1999/03/12)
- TurboLinux 謹製 Kernel 2.2.3 (1999/03/15)
- Window Maker 0.51.2 (1999/03/15)
- TurboLinux 謹製 Kernel 2.2.3 の所在 (1999/03/17)
- Kernel 2.2.4 (1999/03/25)
- 時刻合わせ (1999/03/25)
- TurboLinux 謹製 kernel-2.2.4 (1999/03/28)
- kernel-2.2.5 (1999/03/31)
Wnn6 マイナーバージョンアップ (1999/03/02)
Wnn6 Ver 2.01 がリリースされました。TurboLinux 3.0 への対応のみですが、今後、他のディストリビューションにも順次対応していくそうです。
Get してインストールしてみましたがダメでした。xwnmo が使い物にならない。(爆笑) 現象は前と同じです。TurboLinux 3.0 用というのがミソなのかな。私の環境は glibc を入れ替えてるからダメなのかもしれません。まさか元々の環境でダメということはないでしょうが、それを検証するのはちと酷な話です。大体、TurboLinux 3.0 用と言っているところが胡散臭いですよね。と言うか、TurboLinux 3.0 が胡散臭いというほうが正解?(大爆笑)
Wnn6 オムロンソフトウェアの回答 (1999/03/03)
xwnmo が動かないんで、オムロンソフトウェアに問い合わせたところ、Wnn6 Ver 2.01 は TurboLinux 3.0 アップグレード版では動作保証しないそうです。TurboLinux 3.0 オリジナルの環境でしか使えないということになりますね。
オムロンソフトウェアは Linux の状況をよく見ていないというか、流れに乗り遅れ気味ですね。日々進化する Linux の世界で、パッケージソフトの開発、販売する難しさを露呈する結果になってます。「X_LOCALE はそろそろ捨てて glibc の国際化に備えましょう」と言っている時期に、X_LOCALE に依存してたのが前回の問題。「glibc + wcsmbs に対応しました」と修正版を出したところ、glibc + wcsmbs のほうが進化(?)してたというのが今回の問題。
ちょっと不思議に思うのが、Debian なんですね。Wnn6 Ver 2.0 の xwnmo は Debian では問題なく動いているのかなあ。Debian 用の xwnmo の障害についてはアナウンスがありません。Debian の glibc + wcsmbs と RedHat 系のは違うんでしょうか?また、Debian は元々 X_LOCALE を早々に捨ててるわけでしょ。当然 Wnn6 Ver 2.0 も X_LOCALE には依存してないはずですよね。ここらへんが、どうも納得できない部分ではあります。
色々言ったところでどうにもならないことです。オムロンソフトウェアに頑張ってもらうしかありません。OEM で供給してたほうが楽だったろうに、わざわざパッケージソフトとして商品化したわけですから、それなりの覚悟はあったはず。もし撤退するならば xwnmo をオープンソース化してくれれば有難いですね。私は何もできませんが。。。(爆笑)
TurboLinx 3.0 アップグレード版 (1999/03/05)
「TurboLinux 日本語版 3.0アップデートRPMパック」が配布されます。雑誌付録 CD-ROM で手に入れるか、パシフィックハイテックで 1000円で申し込みするかのようです。
メールによる案内だったですが、気になったのが、「なお、アップデート後の動作保証、サポートはしかねますのでご自身の責任において慎重に行う必要があります。」という一文。元々、動作保証やサポートを期待していないとは言え、少々ひっかかりがあります。逆に言えば TurboLiunx 3.0 のオリジナルは動作保証してるってことですよね。パシフィックハイテックが公式に配布するアップデートをかけると動作保証しないという点に矛盾を感じます。
私がディストリビューションに求めるものは、一言で言えば「一貫性のあるパッケージング」です。そのディストリビューションをインストールすれば Linux が問題なく動いてくれること。それ以上のことは望みません。でも、一貫性を崩すようなパッケージが見つかった場合は修正して欲しいし、自社開発のツールの修正はして欲しいものです。そういう修正版が公式アップデートであり、それ以外のものは Non Support でかまわないんです。パシフィックハイテックのサイトには、updates と non_support と分かれていますから、私はてっきりそういうふうに使い分けてるものだと思ってました。ところが今回の案内を見る限り、公式アップデートも Non Support とのことで、矛盾を感じたわけです。
私の考え(求めるもの)が間違っていると言う主張もあるでしょうし、パシフィックハイテックがどう考えるかも自由です。こういったことは最終的には市場が判断することでしょう。でも、そろそろ「寄せ集めてハイどうぞ」という時代は終わりつつあるのも事実。そういった類のものも必要だと思いますけど、それはそれで、動作保証だのサポートだの中途半端なことを言わなければいいわけです。パシフィックハイテックはいったいどういう思想を持っているのでしょうね。
ブートペンギンの拝み方 (1999/03/08)
ブート時にペンギンのロゴを表示させることができない方は、/usr/src/linux/Documents/fb にあるドキュメントをご覧になったら幸せになれるかもしれません。lilo.conf にビデオモードを設定してやるところがミソのようですね。前提となるカーネルのほうは、Console Drivers の指定の中で VGA Text Console を Y、Video mode selection support を Y、Support for frame buffer devices を Y、VESA VGA graphics console を Y にすれば良いそうです。これについては、保科さんのページで紹介されてますので、そちらをご覧になったらよくわかるかと思います。
Window Maker 0.51.1 (1999/03/10)
Window Maker が 0.51.1 になりました。このバージョンはバグ出しの意味合いが濃いらしいですから、0.51.0 からすぐに上げる必要はないかもしれません。すぐに 0.51.2 が出る可能性があります。一応、プライベートパッケージに置きます。
Samba のトラブル (1999/03/10)
Samba が突然トラブルに見まわれましてちょっと焦ってしまいました。Windows クライアントから全然見えなくなってしまったんです。実は、トラブル数日前ぐらいからちょっと様子が変でした。エクスプローラーのネットワークコンピュータから消えてしまったんです。「コンピュータの検索」をすれば出てくる状態だったんで、「なんかの拍子にマスターブラウザが Samba から(マスターブラウザになるように設定してます)どっかのコンピュータに移って見えないのかなあ」程度にしか思いませんでした。ところが、突然、プリンタ出力もできないし「コンピュータの検索」でも見つからない状態に陥ってしまったんです。
smb.conf を見なおしてリスタートしてみたりしましたが全然回復しませんでした。ログも見てみましたがよくわからない。どうしたものか?と考えた末、いっちょ 2.x にバージョンアップしてみようと思い立ち、さっそく RPM 探しに出かけました。で、見つけたのが US TurboLinux にあった、samba-2.0.2-19990207.i386.rpm です。ちなみに今現在の最新バージョンは 2.03 のようですね。何も考えずにアップデートしてやって、smb.conf を修正してやりましたら、めでたく復活しました。
さて、新しいバージョンで気をつけないといけないのが security の設定です。デフォルトの smb.conf は security=user になってますから、こいつを security=share へ修正しました。他は特に変更してません。それと smbpasswd のパスワードファイル形式が変わったようです。パスワードファイルを作り直して、パスワード設定は smbpasswd -e ユーザー名、というふうに -e オプションをつけて行う必要があるようです。旧形式からのコンバーターも用意されてます。
目新しいのが swat という管理ツールです。これは、Web ベースで Samba の設定ができるものです。私が Get したパッケージは、インストールすると、既に設定まで行ってくれてましたので、http://sambaマシン:901/ でアクセスするとOKでした。ただ、パッケージのインストールで /etc/services や /etc/inetd.conf をいじられるのもなんだか嫌だなという気がしましたけど。
結局、トラブルの原因はわからずじまいです。(笑) まあ動けば原因なんてどうでもいいです。ユーザーってこんなもんでしょ。(おまえは開発者の端くれだろう!という突っ込みはナシね)
追記:samba-2.0.3-19990228.i386.rpm を Ring Server で見つけました。SAMBA に bin-pkgs というのがあって、その中に TurboLinux 用がちゃんとあるではありませんか。TL3.01 用のを Get しました。SAMBA の最新バージョンは Ring Server から Get で決まりです。
Kernel 2.2.3 (1999/03/12)
Kernel 2.2.3 がリリースされてます。Ring Server にミラーされてます。TurboLinux は、2.2.1 以来、新バージョンのパッケージは公開されてません。私は 2.2.2 をコンパイルしたのみでパスしてたんですが、2.2.3 はパッケージを作って導入してみました。
ベースにしたのは、TurboLinux の kernel-2.2.1.apm-1.i386.src.rpm です。この kernel-2.2.1.tar.gz を kernel-2.2.3.tar.gz に置き換えて、不要と思われるパッチを削除して作りました。ただ、USB 関連で、キーボードのパッチが必要なんですが、2.2.3 に対応したものを見つけることができませんでした。仕方なく USB 関連のキーボードを無効にしました。カーネルのコンフィギュレーションは、プロセッサータイプを 586 に、数値演算エミュレーションをオフに、APM の電源OFFを有効に、コンソール関係をできるだけ指定して作りました。
私の環境じゃ、これで特に問題なく動いているようなんで「プライベートパッケージ」に置いておきます。ソースパッケージは大きいので置いてません。代わりに SPEC だけは置いておきます。nosrc で作ればよかったんですが作り直すのも面倒なんで勘弁してください。
このパッケージをインストールして問題が発生したらカーネルだけにちょっと怖いです。rpm -Uvh –nodeps でインストールできるんですが、これをやると前のパッケージは削除されてから新バージョンがインストールされます。例えば今使っているカーネルが 2.2.1-4 だったとしたら、/boot/kernel-2.2.1-4 と、/lib/modules/2.2.1-4 が削除されてしまいます。じゃあ、どうやってこの危険を回避したらいいのか?という方法が思いつかない方はやめましょう。(笑) わかる方も緊急用のブートディスクを準備しておくことをお忘れなく。さて、私はどうしたかというと、エイヤで目をつぶって rpm -Uvh –nodeps してしまいました。(笑)
TurboLinux 謹製 Kernel 2.2.3 (1999/03/15)
xturbopkg で調べると、どうやら TurboLinux 謹製の kernel-2.2.3-2 というのがあるようですね。US を中心に探してみたんだけどわかりませんでした。xturbopkg はパッケージのバージョンチェックには便利ですが、さすがに xturbopkg からアップデートするわけにもいかないですものね。自動アップデートせずにローカルディスクに保存するオプションを付けて欲しいなあ。
Window Maker 0.51.2 (1999/03/15)
予想どおり(笑) 0.51.1 は短命でした。0.51.2 がリリースされました。プライベートパッケージに置いておきますね。
TurboLinux 謹製 Kernel 2.2.3 の所在 (1999/03/17)
hanibi さんに「US にあるよ」と教えて頂きました。ありがとう。US の Update 3.01 の i386 及び SRPMS にありました。日本パシフィックハイテックのサイトにもミラーされてますから、こちらから Get すればいいかな。2.2.3 の tarball があるから nosrc が欲しかったなあ。
Kernel 2.2.4 (1999/03/25)
もう、2.2.4 が出てますね。はやいなあ。こんなの追いかけてたら身がもたないですね。(笑)
時刻合わせ (1999/03/25)
パソコンに内蔵されている時計の精度が低いのには昔から頭にきています。何故、最先端の電子機器であるはずのコンピュータの時計は、街で売られてる安物の時計よりも劣るんでしょうね。
複数台のマシンが繋がっている環境だと、各マシンの時刻を合わせることが必要になってきます。私は今までこれを手動でやってました。私の環境だと一番時刻が正確なのがルーターなんです。ルーターの機能に「自動時刻設定」という機能がありまして、ntp を使って外のタイムサーバーから定期的に時刻を合わせています。それを基準に各マシンの時刻を合わせてました。今日もこれをやってたのですが「あまりに非人間的な作業だ」と許せなくなりました。(笑) そこで、折角 Linux があるわけですから xntpd を使って実現することにしました。
シナリオは次のとおりです。
- Linux サーバーは、1日1回、外のタイムサーバーより時刻の同期をとる。cron で時刻合わせのためのスクリプトを起動する。
- Linux サーバーで xntpd を動かして Linux マシンの時刻を通知するように設定する。クライアントは Linux サーバーと時刻の同期をとる。Windows 側の ntp クライアントは Sakura Watch を使用し、ルーターは「自動時刻設定機能」で Linux サーバーと同期をとるように設定する。
xntpd の設定
まず、xntpd の設定ですが、/etc/ntp.conf を以下のように設定しました。server 127.127.1.1
これで、ローカルマシーンの時刻を見てくれるそうです。
時刻合わせのスクリプト作成
次に、作らなければならないのは時刻合わせのためのスクリプトです。TurboLinux には /etc/rc.d/init.d/tltime というブート時に時刻を合わせるためのスクリプトが存在します。しかし、これをそのまま使うにはちょっと問題があります。tltime の中で ntpdate が呼び出されるのですが、これは xntpd が起動していると動かないからです。そこで、xntpd をいったん止めてから tltime を呼び出して、再び xntpd を起動する adjusttime というラッパスクリプトを作成しました。#!/bin/bash # # adjust time # /etc/rc.d/init.d/xntpd stop /etc/rc.d/init.d/tltime start /sbin/clock -w /etc/rc.d/init.d/xntpd start
これを /usr/bin に置いて、root ユーザーにて crontab -e で0 1 * * * /usr/bin/adjusttime
と、毎日1時に時刻合わせするように設定しました。
時刻合わせのパラメータ設定
tltime は、/etc/sysconfig/network に記述されているパラメータを参照します。TIMESERVERATBOOT=yes TIMESERVERTYPE=ntp TIMESERVERHOST=<最寄りのタイムサーバーを指定します>
最寄りのタイムサーバーは自分で探してください。ちなみに、私はプロパイダのサーバーを使わせてもらいました。
Sakura Watch の設定
後は、Sakura Watch の設定です。私は RAS を用いない Sw_noras.exe を使いました。外に出ることはありませんからね。設定は「NTPサーバー名/IPアドレス」に、Linux サーバーを指定して、「起動時にオンラインにする」をチェックするだけです。最後に、Sw_noras.exe をスタートアップに登録して置けばOKです。
これで、全てのマシンの時刻合わせが自動でできるようになりました。もう手動で net time する必要はありません。
補足(1999/03/10) : adjusttime に /sbin/clock -w 追加
TurboLinux 謹製 kernel-2.2.4 (1999/03/28)
TurboLinux 謹製の kernel-2.2.4 が US PHT に登録されてました。この調子だったらカーネルは US PHT に任せても大丈夫のようですね。でも、相変わらず uusbd のリンクは間違ってるし、include に video 入れてくれないし、ブートペンギン出ないし、CPU は 386 ですから、ソースパッケージを貰ってきて SPEC と kernel-config を修正してパッケージ作りなおしました。別に文句を言っているわけじゃありません。(笑) 自分の環境に合わせてパッケージしなおすというのは当たり前だし、kernel は特にそうすべきものでしょうから、パッケージを作ってくれたことを有り難く思わないといけませんね。
uusbd の SPEC 修正は、ln -s $UUSBDDIR/include/uusbd uusbd と記述されているところを ln -s ../drivers/uusbd/include/uusbd uusbd と変更するだけです。$UUSBDDIR だと、パッケージを作る時に Build Root を含んだ形で展開されてしまうから、出来上がったパッケージは、/var/tmp/kernel-root/usr/src/linux/drivers/uusbd/include/uusbd にリンクをはってしまいます。ですから、これを相対パスでリンクはるように修正すれば解決。video を include に含めたい場合は、%files headers の記述に /usr/src/linux-%{kversion}/include/video を追加するだけ。元々ソースツリーには video が入っているのにパッケージするようになってないだけです。
今回 Get したパッケージは kernel-2.2.4-1.src.rpm ですが、ac patch が当たってませんでした。前までは ac patch を当ててパッケージしてました。現在 ac1 が出てますから、すぐに kernel-2.2.4-2 が出る可能性がありますね。
kernel-2.2.5 (1999/03/31)
おいおい、もう 2.2.5 が出てるじゃないですか。ac patch どころじゃなかったですね。(笑)