1 files changed, 520 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/ja/user_basics.ssi b/markup/pod/live-manual/media/text/ja/user_basics.ssi
new file mode 100644
index 0000000..bffdaad
--- /dev/null
+++ b/markup/pod/live-manual/media/text/ja/user_basics.ssi
@@ -0,0 +1,520 @@
+:B~ 基本
+
+1~the-basics 基本
+
+この章ではビルドプロセスの概要と最も広く利用されている3種類のイメージの使用手順について簡単に述べます。最も汎用性の高い形式のイメージである
+#{iso-hybrid}#
+は、仮想マシンや光学メディア、USBポータブルストレージ機器上で利用できます。特に変わった状況では後述のように、#{hdd}#
+形式の方が適するかもしれません。この章では #{netboot}#
+形式のイメージをビルド、利用する手順を記載しています。この形式はサーバ上で必要とする準備のためにやや複雑になります。これは netboot
+についてまだ不慣れな人にとってはわずかに高度な話題となりますが、その準備さえできればローカルネットワーク上でブートするためのイメージをテスト、展開するのに非常に便利な方法で、難なくイメージのメディアを扱うことができるため、ここに収録しています。
+
+この節は {ウェブブート}#webbooting
+の簡単な手引きで終えています。これは恐らく異なる目的の異なるイメージを必要に応じて切り替えて使う最も簡単な方法で、手段としてインターネットを使います。
+
+この章全体を通して、live-build
+により作成されるデフォルトのファイル名を頻繁に参照しています。{ビルド済みイメージをダウンロード}#downloading-prebuilt-images
+した場合、実際のファイル名は異なる場合があります。
+
+2~what-is-live Live システムとは何?
+
+Live システムとは、 通常 CD-ROM
+やUSBメモリ等の取り外し可能メディア、あるいはネットワークからコンピュータ上でブートされるオペレーティングシステムを意味し、普通のドライブに何もインストールせずに利用でき、実行時に自動設定が行われます
+({用語}#terms 参照)。
+
+Live システムはオペレーティングシステムで、サポートしているうちの単一のアーキテクチャ (現在 amd64 と i386)
+向けにビルドされています。以下から構成されています。
+
+_* *{Linux カーネルイメージ}*、通常 #{vmlinuz*}# という名前です
+
+_* *{初期 RAM ディスクイメージ (initrd)}*: Linux ブート用に用意された RAM
+ディスクで、システムのイメージをマウントするのに必要となる可能性があるモジュールとマウントするためのスクリプトをいくつか収録しています。
+
+_* *{システムイメージ}*: オペレーティングシステムのファイルシステムのイメージです。通常、Live
+システムのイメージサイズを最小限にするため、SquashFS
+圧縮ファイルシステムが利用されています。このファイルシステムは読み込み専用であることに注意してください。そのため、ブート処理中は Live
+システムはRAMディスクと「ユニオン」機構を利用して実行中のシステム中でファイルを書き込むことができるようにしています。ただし、オプションの保持機能を使っていない限り、変更は全てシャットダウンにより失われます
+({保持機能}#persistence 参照)。
+
+_* *{ブートローダ}*:
+選択したメディアからブートするように作られた短いコードの集合で、オプション/設定を選択できるプロンプトやメニューを恐らく提示します。Linux
+カーネルとその initrd
+を読み込んでそのシステムのファイルシステム上で実行します。前に言及した構成要素を収録する対象メディアやファイルシステムの形式によっては別の方法があります。isolinux
+では ISO9660 形式のCDやDVDからのブート、syslinux ではHDDやUSBドライブの VFAT
+パーティションからのブート、extlinux では ext2/3/4 や btrfs パーティション、pxelinux では PXE
+netboot、GRUB では ext2/3/4 パーティション、等。
+
+live-build を使って Linux カーネル、initrd、それを実行するためのブートローダを独自仕様で用意して全て1つのメディア特有の形式
+(ISO9660 イメージやディスクイメージ等) でシステムのイメージをビルドできます。
+
+2~downloading-prebuilt-images ビルド済みイメージのダウンロード
+
+このマニュアルの対象は自分の Live
+イメージの開発やビルドですが、使い方の手引き、あるいは自分でビルドする代わりにビルド済みイメージを簡単に試してみたいこともあるでしょう。{live-images
+のgitリポジトリ}#clone-configuration-via-git と公式の安定版 (stable) リリースを使ってビルドされたイメージが
+https://www.debian.org/CD/live/ で公開されています。さらに、古いものや今後のリリース、non-free
+ファームウェアを収録する非公式のイメージ、あるいはドライバが http://live-systems.org/cdimage/release/
+から利用できるようになっています。
+
+2~using-web-builder ウェブ Live イメージビルダーの利用
+
+コミュニティへのサービスとして、ウェブベースの Live イメージビルダーサービスを http://live-systems.org/build/
+で運営しています。このサイトはベストエフォートの方針で保守されています。つまり、最新でいつでも使える状態の維持に努め、大規模な運用停止については問題を告知しますが、100%
+いつでも使えることやイメージの高速なビルドを保証することはできず、サービスについて解決に時間を要する問題が時々あるかもしれないということです。サービスについて問題や疑問があれば、問題のあるビルドへのリンクを添えて{連絡}#contact
+してください。
+
+3~ ウェブビルダーの使い方と注意
+
+ウェブインターフェイスでは現在、オプションの不正な組み合わせを避ける対策を何も取っていません。また、特に、変更すると通常ウェブフォームにある他のオプションのデフォルト値
+(つまり live-build を直接使った場合の値)
+が変わるオプションを変更した場合にウェブビルダーはそのデフォルト値を変更しません。最も顕著な例として、#{--architectures}#
+をデフォルトの #{i386}# から #{amd64}# に変更すると対応するオプション #{--linux-flavours}# をデフォルトの
+#{586}# から #{amd64}# に変更する必要があります。ウェブビルダーにインストールされている live-build
+のバージョンやさらなる詳細については #{lb_config}# man ページを見てください。live-build
+のバージョン番号はウェブビルダーのページ下部に記載されています。
+
+ウェブビルダーにより提示される時間の推定は条件を考慮しない推定であり、実際にビルドにかかる時間を反映していないかもしれません。表示された後に更新もされません。それについては我慢してください。ビルド条件を送信した後にこのページを更新しないでください。更新すると同一のパラメータで再び新たにビルドを送信することになります。ビルドの通知をただの一度も受け取っておらず、十分な時間が確実に過ぎて、通知メールが自分の
+spam メールフィルタに引っかかっていないことを確認した場合、{連絡}#contact してください。
+
+ウェブビルダーがビルドできるイメージの種類は限定されています。これにより、利用や保守を簡単、能率的に維持できます。ウェブインターフェイスで提供されていない独自化を行いたい場合は、live-build
+を使って自分のイメージをビルドする方法をこのマニュアルの残りで説明しています。
+
+2~building-iso-hybrid 最初の段階: ISO hybrid イメージのビルド
+
+イメージの種類を問わず、イメージをビルドするのに同一の基礎手順を毎回実行する必要があります。最初の例ではビルド用のディレクトリを作成して、このディレクトリに移動してから
+live-build コマンドを以下の順で実行し、X.org のないデフォルトの Live システムを収録する基本的な ISO hybrid
+イメージを作成します。このイメージはCDやDVDメディアへの書き込み、さらにUSBメモリへの複製にも適しています。
+
+作業ディレクトリの名前は完全に自由ですが、live-manual
+全体で利用されている例を参考にする場合、特に異なる種類のイメージについて作業、実験している場合、各ディレクトリで作業しているイメージの識別を支援する名前を使うのは良い方法です。ここではデフォルトのシステムをビルドするとして、例えば
+live-default と呼びましょう。
+
+code{
+
+ $ mkdir live-default && cd live-default
+
+}code
+
+それから #{lb config}# コマンドを実行します。これにより他のコマンドが利用する「config/」階層を現在のディレクトリに作成します。
+
+code{
+
+ $ lb config
+
+}code
+
+上記のコマンドにはパラメータが渡されていないので、様々な選択肢についてそれぞれのデフォルト値が使われます。さらなる詳細については {lb config
+コマンド}#lb-config を見てください。
+
+これで「config/」階層ができました。#{lb build}# コマンドでイメージをビルドします。
+
+code{
+
+ # lb build
+
+}code
+
+コンピュータやネットワーク接続の速度により、このプロセスには少々時間がかかるかもしれません。完了すると、#{live-image-i386.hybrid.iso}#
+イメージファイルが使える状態で現在のディレクトリにできているはずです。
+
+*{注意:}* amd64 システムでビルドした場合は、出来上がるイメージの名前は #{live-image-amd64.hybrid.iso}# となります。マニュアル全体でこの慣例を採用していることに留意してください。
+
+2~using-iso-hybrid ISO hybrid Live イメージの利用
+
+ISO hybrid イメージをビルド、または https://www.debian.org/CD/live/
+にあるものをダウンロードした後、通常は次にブート用メディアとして CD-R(W) や DVD-R(W) の光学メディアかUSBメモリを用意します。
+
+3~burning-iso-image ISOイメージの実際のメディアへの書き込み
+
+ISOイメージの書き込みは簡単です。/{xorriso}/ をインストールしてそれをコマンドラインから使ってイメージを書き込むだけです。例えば:
+
+code{
+
+ # apt-get install xorriso
+ $ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-i386.hybrid.iso
+
+}code
+
+3~copying-iso-hybrid-to-usb ISO hybrid イメージのUSBメモリへのコピー
+
+#{xorriso}# で作られたISOイメージは #{cp}#
+プログラムや同等プログラムを使って単純にUSBメモリにコピーすることができます。イメージファイルを置けるだけの十分に大きなサイズのUSBメモリを差し込んでそれがどのデバイスなのか決定します。以後
+#{${USBメモリ}}# として参照します。これは例えば #{/dev/sdb}# といったUSBメモリのデバイスファイルで、例えば
+#{/dev/sdb1}# といったパーティションではありません! USBメモリを差し込んでから #{dmesg}# か、もっと良いのは #{ls -l
+/dev/disk/by-id}# の出力を見ると正しいデバイス名を調べることができます。
+
+正しいデバイス名を得られたことを確信できたら #{cp}#
+コマンドを使ってイメージをUSBメモリにコピーします。*{これを実行すると以前そのUSBメモリにあった内容は全て確実に上書きされます!}*
+
+code{
+
+ $ cp live-image-i386.hybrid.iso ${USBメモリ}
+ $ sync
+
+}code
+
+*{注意:}* /{sync}/ コマンドはイメージのコピー中にカーネルによりメモリに記憶されているデータが全てUSBメモリに書き込まれたことを保証するのに有用です。
+
+3~using-usb-extra-space USBメモリの空きスペースの利用
+
+#{live-image-i386.hybrid.iso}# をUSBメモリにコピーすると、最初のパーティションは Live
+システムで埋められます。残った空きスペースを利用するには、/{gparted}/ や /{parted}/
+といったパーティション作業ツールを使ってそのUSBメモリに新しいパーティションを作成します。
+
+code{
+
+ # gparted ${USBメモリ}
+
+}code
+
+パーティションの作成後にはファイルシステムを作成する必要があります。選択肢には ext4 等があります。#{${パーティション}}#には例えば
+#{/dev/sdb2}# 等パーティションの名前が入ります。
+
+code{
+
+ # mkfs.ext4 ${パーティション}
+
+}code
+
+*{注意:}* 余った容量を Windows で使いたい場合ですが、このOSでは最初のパーティション以外にアクセスすることは通常できません。この問題に対する解決策が{メーリングリスト}#contact でいくらか議論されていますが、簡単な解はないようです。
+
+*{Remember: 新しい live-image-i386.hybrid.iso をUSBメモリにインストールする度に、パーティションテーブルがイメージの内容で上書きされるために USB メモリにあるデータは全て失われるので、追加パーティションをまずバックアップしてから、Live イメージの更新後に復帰させるようにしてください。}*
+
+3~booting-live-medium Live メディアのブート
+
+Live メディアCD、DVD、USBメモリ、あるいは PXE ブートでの初回ブート時に、そのコンピュータの BIOS
+をまず設定する必要があるかもしれません。BIOS により機能やキーの割り当てが大きく異なるため、ここではそれについて深くは触れません。BIOS
+によってはブートするデバイスのメニューをブート時に提示させるキー割り当てを提供しているものがあり、そのシステムでこれが利用できる場合は最も簡単な方法でしょう。それがない場合は
+BIOS 設定メニューに入って Live システムのブートデバイスを通常のブートデバイスよりも前に配置するようにブート順を変更する必要があります。
+
+メディアをブートするとブートメニューが表示されているでしょう。ここで単に enter を押すと、システムはデフォルトの項目 #{Live}#
+とデフォルトのオプションを使ってブートします。ブートオプションのさらなる情報については、メニューの「ヘルプ」の項目や Live システム内にある
+live-boot 及び live-config の man ページを見てください。
+
+#{Live}# を選択してデフォルトのデスクトップ Live イメージをブートしたとして、ブートメッセージが流れた後、自動的に #{user}#
+アカウントにログインし、デスクトップがすぐに使える状態で見えているはずです。{ビルド済みイメージ}#downloading-prebuilt-images
+の #{standard}# 等コンソールだけのイメージをブートした場合はコンソールで自動的に #{user}#
+アカウントにログインし、シェルプロンプトがすぐに使える状態で見えているはずです。
+
+2~using-virtual-machine 仮想マシンを利用したテスト
+
+Live イメージを仮想マシン (VM) 内で実行すると開発の面で大きな時間の節約になるかもしれません。これには注意事項がないというわけではありません:
+
+_* VMの実行にはゲストOSとホストOSの両方に十分なRAMが必要で、CPUには仮想化をハードウェアでサポートしているものを推奨します。
+
+_* VM上での実行には、例えばビデオ性能が低いこと、エミュレーするハードウェアの選択肢が限られていること等内在する制限がいくらかあります。
+
+_* 特定のハードウェア向けの開発ではそのハードウェア自体での実行に代わるものはありません。
+
+_* VMでの実行にのみ関連するバグが時々あります。その疑いがあるときはイメージをハードウェアで直接テストしてください。
+
+こういった制約があることを理解した上で利用可能なVMソフトウェアを調べて要件に合うものを選択してください。
+
+3~testing-iso-with-qemu QEMU でのISOイメージのテスト
+
+Debian で最も汎用性の高いVMは QEMU です。プロセッサが仮想化をハードウェアでサポートしている場合は /{qemu-kvm}/
+パッケージを使ってください。/{qemu-kvm}/ パッケージの説明に要件の簡単な一覧があります。
+
+プロセッサがサポートしている場合はまず /{qemu-kvm}/ をインストールしてください。サポートしている場合は /{qemu}/
+をインストールしてください。以下の例ではどちらの場合もプログラム名は #{kvm}# ではなく #{qemu}# とします。/{qemu-utils}/
+パッケージもあると #{qemu-img}# で仮想ディスクのイメージを作成するのによいでしょう。
+
+code{
+
+ # apt-get install qemu-kvm qemu-utils
+
+}code
+
+ISOイメージのブートは簡単です:
+
+code{
+
+ $ kvm -cdrom live-image-i386.hybrid.iso
+
+}code
+
+詳細については man ページを見てください。
+
+3~testing-iso-with-virtualbox VirtualBox でのISOイメージのテスト
+
+/{virtualbox}/ でISOをテストするには:
+
+code{
+
+ # apt-get install virtualbox virtualbox-qt virtualbox-dkms
+ $ virtualbox
+
+}code
+
+新しい仮想マシンを作成し、#{live-image-i386.hybrid.iso}# を CD/DVD
+デバイスとして利用するようにストレージ設定を変更して仮想マシンを起動します。
+
+*{注意:}* X.org を収録している Live システムを /{virtualbox}/ でテストしたい場合は live-build 設定に VirtualBox X.org ドライバパッケージ /{virtualboxbox-guest-dkms}/ 及び /{virtualboxbox-guest-x11}/ を収録するとよいでしょう。収録しない場合、解像度は 800x600 に限定されます。
+
+code{
+
+ $ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot
+
+}code
+
+dkms
+パッケージを機能させるためには、そのイメージで利用しているカーネルの種類のカーネルヘッダもインストールする必要があります。正しいパッケージの選択は上記で作成したパッケージ一覧に正しい
+/{linux-headers}/ パッケージを手作業により列挙する代わりに live-build により自動的に行うことができます。
+
+code{
+
+  $ lb config --linux-packages "linux-image linux-headers"
+
+}code
+
+2~using-hdd-image HDDイメージのビルド及び利用
+
+HDDイメージのビルドは全面的に ISO hybrid イメージのビルドと似ていて、#{-b hdd}# を指定することと出来上がりのファイル名が
+#{live-image-i386.img}#
+で光学メディアに書き込んで使うことができないという点が異なります。このイメージはUSBメモリやUSBハードドライブ、その他様々な他のポータブルストレージデバイスからのブートに適しています。通常、この目的には
+ISO hybrid イメージを代わりに使えますが、BIOS が hybrid イメージを適切に処理できない場合はHDDイメージが必要となります。
+
+*{注意:}* 前の例で ISO hybrid イメージを作成している場合 #{lb clean}# コマンド ({lb clean コマンド}#lb-clean 参照) で作業ディレクトリをきれいにする必要があります:
+
+code{
+
+ # lb clean --binary
+
+}code
+
+前と同様に #{lb config}# コマンドを実行します。今回はイメージの種類にHDDを指定する点が異なります:
+
+code{
+
+ $ lb config -b hdd
+
+}code
+
+それから #{lb build}# コマンドでイメージをビルドします:
+
+code{
+
+ # lb build
+
+}code
+
+ビルドが完了すると現在のディレクトリに #{live-image-i386.img}# ファイルができているはずです。
+
+生成されたバイナリイメージには VFAT パーティションと syslinux
+ブートローダが収録され、そのままUSB機器に書きこめます。繰り返しますがHDDイメージの使い方はUSBで ISO hybrid
+イメージを使うのと同様です。{ISO hybrid Live イメージの利用}#using-iso-hybrid
+の指示に従ってください。#{live-image-i386.hybrid.iso}# に代えて #{live-image-i386.img}#
+をファイル名に使う点が異なります。
+
+同様に、Qemu でHDDイメージをテストするには上記の {Qemu でのISOイメージのテスト}#testing-iso-with-qemu
+で説明しているように /{qemu}/ をインストールしてください。それから #{kvm}# か #{qemu}#
+のホストシステムで必要バージョンを実行し、最初のハードドライブとして #{live-image-i386.img}# を指定します。
+
+code{
+
+ $ kvm -hda live-image-i386.img
+
+}code
+
+2~building-netboot-image netboot イメージのビルド
+
+以下の順でコマンドを実行すると X.org のないデフォルトの Live システムを収録する基本的な netboot
+イメージを作成します。ネットワーク越しのブートに適しています。
+
+*{注意:}* 前に示した例からどれかを実行した場合、作業ディレクトリを #{lb clean}# コマンドできれいにする必要があります:
+
+code{
+
+ # lb clean
+
+}code
+
+この特定の場合必要な段階の掃除が #{lb clean --binary}# では不十分です。netboot イメージのビルドで live-build
+が netboot の準備を自動的に実行するにあたって異なる initramfs 設定が必要なことがその原因です。initramfs の作成は
+chroot の段階で行われるため、既存のビルドディレクトリで netboot に切り替えるということは chroot
+の段階も再ビルドするということになります。したがって、#{lb clean}# (これは chroot の段階も削除します) を使う必要があります。
+
+#{lb config}# コマンドを以下のように実行してイメージを netboot 用に設定します:
+
+code{
+
+ $ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.2"
+
+}code
+
+ISO及びHDDイメージとは対照的に netboot
+自体ではクライアントに対してファイルシステムのイメージを提供しないため、ファイルをNFS経由で提供する必要があります。lb config
+で異なるネットワークファイルシステムを選択することもできます。#{--net-root-path}# 及び #{--net-root-server}#
+オプションはそれぞれ、ブート時にファイルシステムのイメージが置かれるNFSサーバの位置とサーバを指定します。ネットワークやサーバに合う適切な値がセットされていることを確認してください。
+
+それから #{lb build}# コマンドでイメージをビルドします:
+
+code{
+
+ # lb build
+
+}code
+
+ネットワーク経由のブートでは、クライアントは通常イーサネットカードの EPROM にある小さなソフトウェアを実行します。このプログラムは DHCP
+リクエストを送り、IPアドレスと次に行うことについての情報を取得します。次の段階は通常、TFTP
+プロトコルを経由した高レベルブートローダの取得です。これには pxelinux や GRUB、さらには直接 Linux
+のようなオペレーティングシステムをブートすることもできます。
+
+例えば生成された #{live-image-i386.netboot.tar}# アーカイブを #{/srv/debian-live}#
+ディレクトリに展開すると、#{live/filesystem.squashfs}# にファイルシステムのイメージ、カーネルや
+initrd、pxelinux ブートローダが #{tftpboot/}# にあることがわかるでしょう。
+
+ネットワーク経由でのブートをできるようにするにはサーバ上でサービスを3つ、DHCP サーバ、TFTP サーバ、NFSサーバを設定する必要があります。
+
+3~ DHCP サーバ
+
+ネットワーク経由でブートするクライアントシステムに対して確実にIPアドレスを1つ与え、PXEブートローダの位置を通知するようにネットワークの DHCP
+サーバを設定する必要があります。
+
+イメージしやすいように #{/etc/dhcp/dhcpd.conf}# 設定ファイルで設定する ISC DHCP サーバ
+#{isc-dhcp-server}# 向けに書かれた例を示します:
+
+code{
+
+ # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
+
+ ddns-update-style none;
+
+ option domain-name "example.org";
+ option domain-name-servers ns1.example.org, ns2.example.org;
+
+ default-lease-time 600;
+ max-lease-time 7200;
+
+ log-facility local7;
+
+ subnet 192.168.0.0 netmask 255.255.255.0 {
+   range 192.168.0.1 192.168.0.254;
+   filename "pxelinux.0";
+   next-server 192.168.0.2;
+   option subnet-mask 255.255.255.0;
+   option broadcast-address 192.168.0.255;
+   option routers 192.168.0.1;
+}
+
+}code
+
+3~ TFTP サーバ
+
+これはカーネルと初期RAMディスクをシステム実行時に提供します。
+
+/{tftpd-hpa}/ パッケージをインストールすべきです。これはルートディレクトリ、通常 #{/srv/tftp}#
+内にある全ファイルを提供できます。#{/srv/debian-live/tftpboot}# 内にあるファイルを提供させるには root で
+
+code{
+
+ # dpkg-reconfigure -plow tftpd-hpa
+
+}code
+
+を実行し、tftp サーバの新しいディレクトリについて聞かれたら回答します。
+
+3~ NFSサーバ
+
+ゲストコンピュータが Linux カーネルをダウンロード、ブートして initrd を読み込むと、NFSサーバ経由で Live
+ファイルシステムのイメージをマウントしようとします。
+
+/{nfs-kernel-server}/ パッケージをインストールする必要があります。
+
+それから #{/etc/exports}# に
+
+code{
+
+ /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
+
+}code
+
+のような行を追記してファイルシステムのイメージをNFS経由で利用できるようにし、この新しいエクスポートについてNFSサーバに知らせます:
+
+code{
+
+ # exportfs -rv
+
+}code
+
+この3つのサービスの設定にはやや注意が必要かもしれません。全て協調して機能させるまでには忍耐がいくらか必要かもしれません。さらなる情報については
+http://www.syslinux.org/wiki/index.php/PXELINUX にある syslinux wiki や
+http://d-i.alioth.debian.org/manual/ja.i386/ch04s05.html にある Debian
+インストーラマニュアルの TFTP ネットブート節を見てください。方法はとても似ているので手助けになるかもしれません。
+
+3~ ネットワーク経由のブートをテストする方法
+
+Netboot イメージの作成は live-build
+により簡単になりましたが、イメージを実際のマシンでテストするのは本当に時間がかかるものとなるかもしれません。
+
+日常を楽にするために仮想化を利用できます。
+
+3~ Qemu
+
+_* /{qemu}/、/{bridge-utils}/、/{sudo}/ をインストールします。
+
+#{/etc/qemu-ifup}# を編集します:
+
+code{
+
+ #!/bin/sh
+ sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
+ echo "Executing /etc/qemu-ifup"
+ echo "Bringing up $1 for bridged mode..."
+ sudo /sbin/ifconfig $1 0.0.0.0 promisc up
+ echo "Adding $1 to br0..."
+ sudo /usr/sbin/brctl addif br0 $1
+ sleep 2
+
+}code
+
+#{grub-floppy-netboot}# を取得またはビルドします。
+
+「#{-net nic,vlan=0 -net tap,vlan=0,ifname=tun0}#」を引数にして #{qemu}# を実行します
+
+2~webbooting ウェブブート
+
+ウェブブートは手段としてインターネットを使い Live
+システムをブートするための便利な方法です。ウェブブートの要件はとても少なくなっています。ある言い方をすれば必要なのはブートローダと初期RAMディスク、カーネルを収録したメディアです。別の言い方をすれば必要なのはファイルシステムを収録する
+squashfs ファイルを置くウェブサーバです。
+
+3~ ウェブブートファイルの取得
+
+いつものように、イメージを自分でビルドすることも、プロジェクトのホームページ http://live-systems.org/
+から取得できるビルド済みファイルを利用することも可能です。自身の必要に応じて微調整ができるまでの初期テストにはビルド済みイメージの利用が手軽でしょう。Live
+イメージのビルド後ならウェブブートに必要なファイルは #{binary/live/}# 下のビルドディレクトリで見つけられるでしょう。ファイルは
+#{vmlinuz}#、#{initrd.img}#、#{filesystem.squashfs}# と呼ばれます。
+
+必要なファイルを既に存在するISOイメージから抽出することも可能です。そのためには以下のようにしてそのイメージをループバックマウントします:
+
+code{
+
+ # mount -o loop image.iso /mnt
+
+}code
+
+ファイルは #{live/}# ディレクトリで見つけられます。この例の場合は #{/mnt/live/}#
+になります。この方法にはそのイメージをマウントするのに root
+になる必要があるという欠点があります。しかしこれには簡単に定型処理、つまり自動化できるという利点があります。
+
+しかし疑いようもなく、ISOイメージからファイルを抽出すると同時にウェブサーバにアップロードするのに最も簡単なのはミッドナイトコマンダーや /{mc}/
+の利用でしょう。/{genisoimage}/
+パッケージをインストールしていれば2ペインのファイルマネージャによりISOファイルの内容を確認しながらもう1つのペインではftp経由でファイルをアップロードできます。この方法は手作業の介入が必要とはなりますが
+root 権限を必要としません。
+
+3~ ウェブブートイメージの起動
+
+ユーザによってはウェブブートのテストに仮想化を好みますがここでは以下の活用事例に合わせて実際のハードウェアについて言及します。あくまで例だと思ってください。
+
+ウェブブートイメージの起動は上記で示した構成要素、つまり #{vmlinuz}# と #{initrd.img}# をUSBメモリの #{live/}#
+ディレクトリ以下に書き込み、ブートローダとして syslinux をインストールすれば十分です。そしてUSBメモリからブートしてブートオプションに
+#{fetch=URL/ファイル/への/パス}# を入力します。live-boot は squashfs
+ファイルを取得してRAMに格納します。こうして、ダウンロードした圧縮ファイルシステムを普通の Live システムとして使えるようになります。例えば:
+
+code{
+
+ append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs
+
+}code
+
+*{活用事例:}* ウェブサーバがあり、squashfs ファイルが2つ、1つは例えば gnome のようなデスクトップ環境一式を収録したものともう1つは標準のものが置かれているとします。あるマシンでグラフィカル環境が必要であればUSBメモリを差し込んで gnome 用イメージをウェブブートできます。後者のイメージに収録されている何かのツールが別のマシン等で必要になった場合は標準的なイメージをウェブブートできます。