mywkfmnrのホームページ

フリーページ

お気に入りブログ

第38回全日本マイク… CPU4Eduさん

源氏物語の世界 jooxさん
一日一冊:読書日記… 本のソムリエさん

全4件 (4件中 1-4件目)

1

KNOPPIX

2004年08月12日
XML
カテゴリ:KNOPPIX
掲示板で、Martyさんから、以下のような質問をいただきました。この日記は、その回答です。

[質問]
自宅ではノートPCでHDDレス+USBメモリ128+CD-ROM起動(XFCE)+VNCServerでWinXPから利用しているのですがこれもPoorマシンで良くフリーズします。ここで毎回rebootする際にそのマシンのrootsehellコンソールでVNCServerを起動させるのが面倒なのでinetdの方法や、runレベル登録など色々試したのですが残念ながらだめでした。既に1年近くこの状態で進まないのであきらめ、起動時にtelnetが上がればの手段に切替えたのですが、これまたtelnetを自動起動できる方法で詰まっています。本当に誰も相談できず、この場を借りて記させて頂きました。もし良かったらご教示のほどを・・・。


[回答]
VNCとtelnetdでは自動起動の仕方が違います。

telnetdはHowto3-2で解説しているftpdと同様な方法で自動起動できるかもしれませんが、やったことが無いので何ともいえません。
KNOPPIXでは、telnetよりsshを推奨しています。sshなら、KDEメニューから[KNOPPIX]->[Services]->[Start SSH Server]があります。使い方は「KNOPPIX "Start SSH Server"」でググると、いろいろ出てくるようです。

VNCはsambaと同じ方法で自動起動できます。ただし、/etc/init.d/vncserverは自前で作成する必要があります。
sambaの自動起動の方法はKNOPPIX実験室のHowto3-1で説明していますので、参考にしてください。

実は、私も、昨年の5~6月頃にVNCを良く使っていました。このため、2003/6/24にKNOPPIX実験室を第0.1版として開設したときから数ヶ月間、VNCサーバの設定ファイルもアップしていました。しかし、560KBもある、KNOPPIX実験室としては巨大なファイルだったので、Webサイト容量不足で悩み始めた頃、真っ先に削除したファイルも、これだったように思います。

このときアップしていたファイルを久々に使ってみたら、KNOPPIX-3.4-20040517-20040629版でも、使えますね。
更新日付から見て、KNOPPIX-3.2-20030415-20030430版を使っていた頃に作ったものと思いますが、それが、まだ使えました。

ただし、自動起動は使っていなかったので、自動起動用のファイル/etc/init.d/vncserverは使えないものが入っていました。
このファイル、元々は2002年頃にLive Linux2で作ったものを移植したものなので、使わない自動起動用のファイルは、Live Linux2用のものが、そのまま、残っていました。そこで、KNOPPIX用の/etc/init.d/vncserverを作って差し替えました。

あと、KNOPPIX 3.4でのVNCのログオフ・停止処理にも問題がありました。VNCをログオフ・停止したいのに、システムの方がログオフ・停止されてしまいます。VNCの方は、中途半端な状態になって、以後、使えなくなってしまいます。

Martyさんのように、コンソールの代わりにVNCを使うのなら、かえって便利に使えるかもしれませんが。

一応、/etc/init.d/vncserverを差し替えただけの設定ファイルをKNOPPIX実験室のHowto1-2にアップしましたので、試してみてください。
FAT32インストール環境を構築(KNOPPIX実験室のHowto1-1参照)してあれば、これらのファイルを以下のパスに配置しておくだけで、VNCが自動起動されるようになります。

/cdrom/KNOPPIX/linuxrc2.d/tbz.d/patchvnc-3.3.2r2.tbz
/cdrom/KNOPPIX/linuxrc2.d/sh.d/patchAutoVNC.sh





過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年08月12日 09時55分02秒
コメント(0) | コメントを書く

2004年08月05日
カテゴリ:KNOPPIX
私は、時々、通常のcloopファイルのほかに、もうひとつcloopファイルをマウントできると便利なのになと思うことがあります。

例えば、RAMディスクや継続的ホームディレクトリにいろんなファイルをインストールした後で、それらをcloopに固めておいて、必要に応じて、ボートオプションで選択してマウントできるようにしておくのです。例えば、あるときは、標準のcloopだけ、あるときは、Javaとeclipseをインストールしたcloopを追加、あるときは、Oracleをインストールしたcloopを追加、といった具合に使うのです。
それなら、継続的ホームディレクトリを複数用意しておいて切り替えればいいと言われそうですが、cloopだと圧縮されていて、しかも圧縮したままマウントできるのが魅力です。特に、50MB程度に収まる場合は、標準のKNOPPIX CDからisolinuxとcloopだけをいただいてきて、それに追加のcloopをいれて、簡単にオリジナルCDの出来上がりとなります。(注)

実際、現在のKNOPPIXには/dev/cloopの他に/dev/cloop1,2,3があったり、UML KNOPPIXを起動すると、/dev/cloop4が作られたりで、2つ目のcloopをマウントすることは不可能ではなさそうに見えます。
第一、別々のcloopを指定して3つのUML KNOPPIXを起動できるということは、カーネルは都合4つのcloopを管理しているということになります。/proc/mountsなどを表示しても、それらは見当たらないのですが、これらは、どういう仕掛けで動いているのでしょうね。

しかし、問題になるのは、そのcloopのマウント方法。以下のようなコマンドでマウントする必要があるのです。
insmod -f cloop.o file=/path/to/the/cloop/file
mount /dev/cloop -t iso9660 -o ro /KNOPPIX

このうち、insmodが曲者です。cloop.oのinsmodは、1回しかできないので、普通にやったら、cloopは1つしかマウントできないのです。

UMLだと、仮想マシンを立ち上げた後で、仮想のカーネルに対してinsmodするので、仮想マシンごとに1つのcloopをマウントできるのです。
しかし、仮想のカーネルだって、本当のカーネルとの仲を取り持つだけで、実際の処理は本当のカーネルが行うはずです。
ならば、仮想のカーネルは、どのようにして本当のカーネルに対して、2つ目以降のcloopの存在を通知しているのでしょう。
insmodでは通知できないので、何か別の方法で通知しているはずです。私も、その方法をいろいろと調べてみたのですが、結局、分からずじまいでした。

産総研さんなら、UML KNOPPIXの開発を通じて、この辺のノウハウをお持ちのことと思いますが、それを公開してもらえないものだでしょうかネェ。
とはいっても、こっちは趣味でやっているだけだし、代替案もいろいろ有りそうだし、ちょっと、「折り入ってお願いがあります」「教えてください」などと頼み込むのは気が引けますよね。

せめて、このページで、ささやかにお願いすることにします。
このページをご覧の方で、この辺のノウハウをお持ちの方、いらっしゃいましたら、是非、それをお教えいただけるとありがたいです。
よろしくお願いいたします。




(注)「それなら圧縮isofsも同じですよ、圧縮率はcloopよりは劣るみたいだけど、どのLinuxでも使える・・・」などといわれると弱いですが。




過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年08月05日 20時54分32秒
コメント(2) | コメントを書く
2004年04月14日
カテゴリ:KNOPPIX
昨日、掲示板でhiroBさんに質問されたものですが、良いテーマなので、この日記で回答させていただきます。

基本的には、以下のことをすればアンインストール完了です。
(1)KNOPPIXを入れたパーティション(HDインストールの場合)またはファイル(FAT32インストールの場合、cloopファイルや他の関連ファイル)を削除します。
(2)元のブートローダを入れなおします。

その方法は以下の通りです。

1.KNOPPIXのパーティションの削除

KNOPPIXをHDインストールして使っていた場合、アンインストール後は、そのパーティションを削除して再利用したいですよね。
しかし、Windows 9xのfdiskでは、このパーティションを削除できません。(NT系のWindows(NT/2000/XP/2003)ならディスクアドミニストレータなどで簡単に削除できます)
そこで、Windows 9xの場合は、Linuxのfdiskやqtpartedなどをつかって、パーティションを削除することになります。

ここでは、qtpartedというGUIのパーティション操作ツールを使って削除する方法を紹介します。
Kメニューの「システム」の中に「qtparted」というエントリがあります。
#20040216-20040220版だと2つ出てくるのですが、この場合、アイコンの大きい下のエントリが正しいエントリのようです。
これを実行すると、以下のような画面が出てきます。
qtparted
#qtpartedの画面を採取するのに手ごろなHDが無かったので、30MBのメモリスティックを使いました。
#15MBのFAT32というのは本来はあってはならない規格違反のもので、Windowsでは作ることも使うことも出来ないのですが、Linuxだと作れてしまいます。
#qtpartedでも、このパーティションの動作は怪しい(この画面だって計算が合わないし・・・)のですが、そこは目をつむることにします。
一応GUIで、しかも日本語化されているので、操作方法はおよそ見当が付くと思います。ちなみに、「操作」メニューは以下のようになっており、基本的なパーティションの操作はqtpartedで出来るようになっているようです。
qtparted 操作メニュー

qtpartedの操作方法はすでに解説ページがインターネット上にいくつかあるようなので、Googleで検索してみてください。
「qtparted KNOPPIX」で検索すると、KNOPPIXのqtpartedを使って解説しているページがヒットするようです。

2.ブートローダを元に戻す。

KNOPPIXではブートローダにGRUBを使うことが多いと思いますが、ブートローダにアンインストールという考え方は無いので、ふたたび、以前のブートローダをインストールしなおすことで、元に戻します。

その方法は、GRUBを何処にインストールしていたかによって、異なります。

2.1 GRUBをMBR(マスタブートレコード)にインストールしていた場合。

Windowsの標準のブートローダをMBRに書き込むことで対処できます。
その方法は、PowerQuest/NetJapanのサポート資料「MBRをリフレッシュする方法で解説されています。

2.2 GRUBをPBR(パーティションブートレコード)にインストールしていた場合。

2.2.1 そのパーティションがWindows 98/Meのシステムパーティションだった場合

Windows 9xの場合は、PBRはMBRのように単独で書き込むことが出来ません。
したがって、もし、GRUBをインストールしていたパーティションがWindows 98/Meのシステムパーティションだった場合は、Windowsを再インストールしないと、元に戻せません。Windowsを再インストールした場合は、Uindows Updatesの多くは適用しなおしになるなどの対処が必要になります。ご注意ください。

2.2.2 そのパーティションがWindows 2000/XPのシステムパーティションだった場合

Windows 2000/XP の場合は、MBRにインストールしていた場合と同じ方法が使えるかもしれません。試してみてください。

2.2.3 そのパーティションがWindows のシステムパーティションではない場合

PBRは、そのまま放置し、アクティブパーティションをGRUBをインストールしていたパーティションからWindowsのシステムパーティションに変更することで対応します。
Windowsの標準のブートローダは基本パーティションの中からアクティブに設定されているパーティションを探し、そのパーティションのブートレコード(PBR)に制御を渡すので、アクティブパーティションをWindowsのシステムパーティションに変更するだけで、Windowsからブートできるようになります。
もっとも、この設定の場合、GRUBからはWindowsを起動できなかったはずで、LinuxとWindowsのマルチブートを実現するには、別途、PQBootやOS-2のブートマネージャのようなブート対象OS切り替え機能を持つツールを使っているはずなので、その場合には、特に設定変更する必要は無いはずです。

アクティブパーティションに設定する操作も、qtpartedで出来ます。「操作」メニューの「アクティブに設定」がそれです。GUIで簡単に使えるので特に説明しません。やってみてください。


更新2 2004/10/19
PowerQuest/NetJapanのサポート資料「MBRをリフレッシュする方法へのリンクが切れていたので修正しました。


過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年10月19日 17時31分03秒
コメント(1) | コメントを書く
2004年02月14日
カテゴリ:KNOPPIX
訂正:Javaを標準でサポートしたLinuxは沢山あると思っていたのですが、私の使ったことのあるLinuxの中では、Live Linux2だけでした。
最近発売の有償Linuxでは、以下のものでJavaがサポートされているらしいことはWebページで確認できました。
・Miracle Linux Standard Edition 2.1
・Red Hat Professinal Workstation
・Red Hat Enterprise Linux 2.1
しかし、私が使ったことのあるFTP版のLinuxでは、どれも、標準ではJavaはサポートされていませんでした。
重要な点で勘違いしていたことをお詫びし、訂正いたします。(以下の記述は訂正済みです。)

現在、KNOPPIXではJavaがプリインストールされていません。代わりにインストール用のスクリプトが添付されていて、自分でダウンロード&インストールして使うようになっています。
なぜ、そんな面倒なことになっているのでしょうか。
それは、KNOPPIXでは全てのプログラムがインストール済みで即使用可能な状態で配布されるという、通常のLinuxとは異なった特殊な側面があるために生じるJavaのライセンスの解釈の問題のようです。

JREはダウンロード、使用、再配布がフリーです。でも、ソース提供がなく、改変も認められていません。KNOPPIXの開発者は、この2点から、JavaをKNOPPIXで配布するのは問題ありと考えたのでしょう。

でも、JREをプリインストールしたCDブートLinuxが無いわけではありません。
Live Linux2にはJREがインストールされ、Tomcatもインストールされていました。
Java2 Standard Edition SDKはインストールされていませんでしたが、これは、当時、このSDKの再配布が認められていなかったからです。コンパイラなどの一部バイナリが再配布可能になったのは、Live Linux2の発売直前だったようです。でも、コンパイラが無いと、Tomcatだけあっても、Javaのプログラムを作れないので使い物になりません。そこで、かわりにjikesが入っていました。

では、KNOPPIXで問題ありと判断されたJREをLive Linux2でインストールされているのはライセンス違反だったのでしょうか。
ここがKNOPPIXとJava、いや、CDブートLinuxとJavaの関係の微妙なところで、判断の分かれるところです。
私は、Live Linux2のようにJREをインストールしてもライセンス違反とは言えないと考えています。
Live Linux2が何を根拠にこのような判断を下したかは不明ですが、私は、以下のような考えから、CDブートLinuxにJREをプリインストールして配布しても問題無いのではないかと考えています。
#これは、あくまで私の個人的な意見です。この意見が正しいのかどうか私には分かりません。
#この意見はあくまで参考にとどめ、最終的にはご自身の責任で判断してください。
#その判断の結果、何か損害をこうむったとしても、私は何らその責を負うことは出来ません。
#とはいえ、KNOPPIX(またはその派生版)を提供する権限と責任を持つ立場の方が、この意見を読んで、Javaをプリインストールして配布しても問題ないと判断してくれることを期待して、この記事を書きます。

(1)ソースが提供されない点について。

GPLのFAQに次のような記述があります。
http://www.gnu.org/licenses/gpl-faq.ja.html#MoneyGuzzlerInc
(GPLで保護されたプログラムを改変し、カネヨコセ社(Money Guzzler Inc.)から出ているポータビリティライブラリとリンクしたいのですが、私はカネヨコセ社のライブラリのソースコードを頒布することができません。そこで、カネヨコセ社のライブラリとリンクしたバージョンを改変したいユーザは、それらのライブラリを別に入手しなければなりません。どうしてGPLはこれを許可していないのですか?)

このカネヨコセ社をSun、ポータビリティライブラリをJREに当てはめて考えてみると、Sunはカネヨコセとは言っていないだけで、あとは符合します。つまり、JavaとGPLのプログラムを組み合わせたものを作ることは出来ないということでしょうか。
だからか、Javaを使ったプログラムにGPLを採用するものを私は知らないので、問題が無いのかもしれません。しかし、Javaで書いたプログラムからLinuxのシステムコールや各種のコマンド・プログラムを使ったりするのは問題ないのでしょうか。単に使うだけなら問題ないことが多いのでしょうが、いろんなライセンスのものが混在しているので、私には良く分かりません。
ただ、この問題はKNOPPIXだけにとどまりません。Javaをサポートする全てのLinuxに言えることです。
いまだに多くのLinux(FTP版)でJavaがサポートされない理由の一つはここにあるのでしょうか。

しかし、最近、有償版ではJavaをサポートしたものも出てきたようです。
・Miracle Linux Standard Edition 2.1 (標準で、SunのJava2 SDK 1.3.1-04が入っている。Tomcat 4.0.3も標準で入っている。)
・Red Hat Professinal Workstation (インストールCDには入っていないが、同梱の別CDでIBMとSunのJREが提供される。)
・Red Hat Enterprise Linux 2.1 (モデルによってはIBMのJREが標準でサポートされている。SunのJREは無し?)

本件は有償・無償とは無関係なはずなので、少なくとも、これらのディストリビュータは、本件に関しては問題ないと考えているということだと思います。
(2)改変を認めていない点について。

これは微妙な問題を含んでいます。
まず、改変とは、何処までを言うのでしょう。JavaのVMやライブラリを一部でも変更すれば該当することは自明ですが、これらを変更しない場合が問題です。
Sunから提供されるインストーラを使ってインストールした即実行可能な状態のもの(cloop)を配布することは、改変したものを配布することになるのでしょうか。
これが改変だということになると、面倒な問題が出てきます。KNOPPIXのcloopファイルを作成するということは、そこにインストールする多くのプログラムに、この改変を加えて、1つのcloopファイルに統合することだということになると考えるからです。ということは、複数のプログラムを改変して統合した1つのプログラムという位置づけになってしまうのではないでしょうか。GPLの場合、独立したプログラムの集合体なら、ライセンスの異なるプログラムを一緒に配布することが認められていますが、そうでなければ、全体がGPLでなければなりません。つまり、Javaはおろか、Apacheのようなものでさえ、ライセンスがGPLでないため、組み込めないことになってしまい、KNOPPIXのライセンスは破綻してしまいます。

KNOPPIXのような配布形態でも、GPLで言うところの独立したプログラムの集合体に該当すると言うためには、改変・統合とは別の見方をする必要があると考えます。

私は、通常のLinuxとKNOPPIXのようなCDブートLinuxは、配布とインストールのやり方が違うだけで、ライセンス的には同等であると考えます。
通常のLinuxは独立した複数のプログラムの集合体をCDROMなどのメディアに記録して配布し、エンドユーザが、インストーラを使って、これらのプログラムを特定のファイルシステムにインストールして使います。
これに対して、CDブートLinuxでは、独立した複数のプログラムの集合体をディストリビュータがCDROM上のファイルシステムにインストールして配布します。エンドユーザは、この配布されたファイルシステムをそのまま使います。

この両者は以下の点で同じです。
・共に独立した複数のプログラムの集合体を基にしています。
・実際にエンドユーザが使うものはインストールが終わったファイルシステムだという点も同じです。

違う点があるとすると、以下の点です。
・エンドユーザから見ると、CDブートLinuxでは、独立した複数のプログラムの集合体が見えません。
・インストール時にライセンス確認があった場合、それを確認するのは、CDブートLinuxでは、エンドユーザではなくディストリビュータになります。

この2点の違いを克服して、通常のLinuxとCDブートLinuxはライセンス的に同じ立場にあるということが出来れば、通常のLinuxでサポートできるプログラムなら何でも、CDブートLinuxにプリインストールして配布できることになるのではないかと考えています。
(3)独立した複数のプログラムの集合体がエンドユーザから見えない点について。

これについては、すでに類似の問題があります。GPLではソースをエンドユーザに提供することを求めていますが、現在の多くのLinuxの配布媒体からはソースは見えない点です。
これについては、インターネットからソースをダウンロードできるようにしたり、エンドユーザが要求すればいつでもソースを記録した媒体を実費程度の価格で配布できるようにすることで、問題無しとされています。
したがって、CDROM上のファイルシステムへのインストールに使用したプログラムについても、そのインストール用のバイナリパッケージに対して、ソースと同様な処置を講じれば、同じ論理で問題無しとなるのではないでしょうか。
実際、KNOPPIX本家では、このようなバイナリパッケージをインターネットから自由にダウンロードできるようにしてくれています。
(4)インストール時のライセンス確認をディストリビュータが行う点について。

これについては、ディストリビュータがライセンスを確認した時点で、そのライセンスをディストリビュータの責任でエンドユーザに通知し、確認を求める義務を負うと考えることで対処できるのではないでしょうか。そうすれば、ディストリビュータが、その義務を全うすることで、インストール時のライセンスをエンドユーザが確認したとみなすことが出来るようになり、問題は克服されると考えるからです。
その方法となると、すでに多くの先例があるので、おおよその見当は付くと思います。(少々面倒くさいものにはなりそうですが)

しかし、この問題は、インストーラでライセンス確認するプログラムだけの問題でしょうか。Linuxではインストーラでもライセンス確認しないものの方が多く存在しますが、これらのプログラムでも、ライセンスに同意しなければ使えない、あるいは、使ったことによってライセンスに同意したとみなされる点は同じです。
したがって、そのような仕掛けになっていることを包括的にでもエンドユーザに通知して、同意を求める必要があるのではないでしょうか。つまり、インストーラでライセンス確認するプログラムをプリインストールしたかどうかとは無関係に、全体の包括的なライセンスをディストリビュータの責任でエンドユーザに通知し、確認を求めることは、もともと、ディストリビュータに求められている義務なのではないでしょうか。
実際、Red Hat Linuxなどの統合インストーラを持つLinuxではインストールの最初の段階で、この包括的なライセンスの確認を求められます。
また、CDROMで配布されるものの場合には、CDROMの開封時にライセンスの確認を求めるのが一般的です。
KNOPPIXのようにisoイメージのダウンロードで配布されるものの場合は、ダウンロード時に、この包括的なライセンスの確認を求める必要がありそうな気がします。そして、その包括的なライセンスの中に、再配布する場合は、再配布者の責任でエンドユーザに包括的なライセンスの確認を求める義務があることを明記しておけば良いように思います。

以上のような対処をすることで、私は、CDブートLinuxもライセンス上は通常のLinuxと同じ立場に立つことが出来るようになり、通常のLinuxで配布できるプログラムなら何でも、CDブートLinuxにプリインストールして配布できるようになるのではないかと考えています。


過去のKNOPPIX関連日記一覧はこちら

KNOPPIX実験室








最終更新日  2004年08月17日 18時45分54秒
コメント(2) | コメントを書く

全4件 (4件中 1-4件目)

1

PR


Copyright (c) 1997-2017 Rakuten, Inc. All Rights Reserved.