diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/ja')
21 files changed, 3709 insertions, 0 deletions
diff --git a/markup/pod/live-manual/media/text/ja/about_manual.ssi b/markup/pod/live-manual/media/text/ja/about_manual.ssi new file mode 100644 index 0000000..3617fbe --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/about_manual.ssi @@ -0,0 +1,218 @@ +:B~ このマニュアルについて + +1~about-manual このマニュアルについて + +このマニュアルは ${project}と、特に Debian +9.0「${stable}」リリースに向けてプロジェクトにより作られるソフトウェアに関連するあらゆる文書にアクセスするための一元的な起点となります。最新版は常に +http://live-systems.org/ にあります。 + +Live マニュアルは第一に Live +システムのビルドの支援を扱い、エンドユーザ向けの話題は扱いませんが、エンドユーザにとって有用な情報がいくらかあるかもしれません: +{基本}#the-basics ではビルド済みイメージのダウンロードや、ウェブビルダーを使うかシステム上の live-build +を直接実行することでメディアやネットワークからイメージをブートさせる準備について触れています。{実行時の挙動の変更}#customizing-run-time-behaviours +では、キーボードレイアウトやロケールの選択、再起動をまたいで状態を引き継がせる仕組みの利用等、ブートプロンプトで指定できるオプションをいくらか説明しています。 + +提示されているコマンドの一部にはスーパーユーザ権限で実行しなければならないものもあります。これは #{su}# で root +ユーザになるか、#{sudo}# +を使って実行します。権限のないユーザで実行できるコマンドと実行にスーパーユーザ権限を必要とするコマンドは、それぞれのコマンドの前に #{$}# があるか +#{#}# があるかで区別します。この記号はコマンドの一部ではありません。 + +2~ せっかちな人向け + +このマニュアルにある全てが、少なくとも一部のユーザにとって重要だと確信していますが、触れている内容が多岐にわたることや、詳細を掘り下げるよりも先に、まずはソフトウェアをうまく使う経験をしたいであろうということをわかっています。したがって、以下の順に読み進めることを提案します。 + +最初にこの章{このマニュアルについて}#about-manual を始めから{用語}#terms 節まで読んでください。次に{例}#examples +節の最初にある3つのチュートリアルまで飛ばします。ここではイメージのビルドと独自化の基本について教えるようになっています。{例の使用}#using-the-examples +を最初に読み、引き続いて {チュートリアル 1: デフォルトイメージ}#tutorial-1 と {チュートリアル 2: +ウェブブラウザユーティリティ}#tutorial-2 を、最後に {チュートリアル 3: 私的イメージ}#tutorial-3 +を読んでください。チュートリアル群を終えるまでに、Live システムでできることが何なのかわかってくるでしょう。 + +それから戻り、マニュアルをもっと掘り下げて学習していくことを勧めています。恐らく、その次は{基本}#the-basics を読み、{netboot +イメージのビルド}#building-netboot-image に軽く目を通して、{独自化概要}#customization-overview +とそれに続く章を読んで終えるのがいいでしょう。この時点までに、Live +システムでできることを知ることがすっかり面白くなってマニュアルの残りを隅から隅まで読む気になっていることを期待します。 + +2~terms 用語 + +_* *{Live システム}*: ハードドライブにインストールしなくてもブートできるオペレーティングシステムです。Live +システムはそのコンピュータのハードドライブに既にインストールされているローカルのオペレーティングシステムやファイルを、そうするように指示しない限り改変しません。Live +システムは通常、CDやDVD、USBメモリ等のメディアからブートされます。ネットワーク越しにブートできるもの (netboot +イメージ経由、{netboot イメージのビルド}#building-netboot-image 参照) やインターネット越しにブートできるもの +(起動パラメータ #{fetch=URL}# 経由、{Webbooting}#webbooting 参照) もあります。 + +_* *{Live メディア}*: Live システムとは異なり、Live メディアは live-build により作成されたバイナリを書き込んでその +Live システムをブートするのに利用するCDやDVD、USBメモリを指します。もっと広い意味では、この語はネットワークブートファイルの位置等、Live +システムをブートする目的でこのバイナリが置かれている任意の場所を指すこともあります。 + +_* *{${project}}*: live-boot、live-build、live-config、live-tools、live-manual +パッケージを特に保守しているプロジェクトです。 + +_* *{ホストシステム}*: Live システムの作成に利用される環境です。 + +_* *{ターゲットシステム}*: Live システムの実行に利用される環境です。 + +_* *{live-boot}*: Live システムのブートに利用するスクリプト集です。 + +_* *{live-build}*: 独自化した Live システムのビルドに利用するスクリプト集です。 + +_* *{live-config}*: Live システムのブート処理中の設定に利用するスクリプト集です。 + +_* *{live-tools}*: 実行中の Live システム内で有用なタスクを実行するのに利用する追加のスクリプト集です。 + +_* *{live-manual}*: この文書は live-manual というパッケージで保守されています。 + +_* *{Debian Installer (d-i)}*: 公式の Debian ディストリビューション用インストールシステムです。 + +_* *{ブートパラメータ}*: bootloader プロンプトで入力し、カーネルや live-config の動作を変更できるパラメータです。 + +_* *{chroot}*: /{chroot}/ プログラム。#{chroot(8)}# により、単一のシステム上で異なる GNU/Linux +環境を再起動せずに並行して実行できるようになります。 + +_* *{バイナリイメージ}*: live-image-i386.hybrid.iso や live-image-i386.img 等、Live +システムを収録するファイルです。 + +_* *{ターゲットディストリビューション}*: Live +システムがベースとするディストリビューションです。これはホストシステムのディストリビューションとは別のものです。 + +_* *{安定版 (stable)/テスト版 (testing)/不安定版 (unstable)}*: *{安定版 (stable)}* +ディストリビューション、現在のコード名${stable}には、公式にリリースされた最新の Debian ディストリビューションが含まれます。*{テスト版 +(testing)}* ディストリビューション、一時的コード名 ${testing} は次期*{安定版 (stable)}* +リリースを集める場です。このディストリビューションを使う主な利点はソフトウェアのバージョンが*{安定版 (stable)}* +リリースと比べて新しいということです。*{unstable}* ディストリビューション、恒久的コード名 sid は Debian +の開発が活発に行われる場です。通常、このディストリビューションは開発者や、苦労をいとわず最新版を使いたい人が利用します。マニュアル全体を通して、リリースを指すのに +${testing} や sid 等のコード名を使っています。それこそが、ツール自体がサポートしているものだからです。 + +2~ 著者 + +著者一覧 (アルファベット順): + +_* Ben Armstrong + +_* Brendan Sleight + +_* Carlos Zuferri + +_* Chris Lamb + +_* Daniel Baumann + +_* Franklin Piat + +_* Jonas Stein + +_* Kai Hendry + +_* Marco Amadori + +_* Mathieu Geli + +_* Matthias Kirschner + +_* Richard Nelson + +_* Trent W. Buck + +2~how-to-contribute この文書への貢献 + +このマニュアルの作成はコミュニティ中心のプロジェクトで、改善提案や貢献は全て、非常に歓迎されます。コミットキーの取得方法や良いコミットを行うための詳細な情報については、{プロジェクトへの貢献}#contributing-to-project +節を見てください。 + +3~applying-changes 変更の適用 + +マニュアルの英語版に変更を加える場合、#{manual/en/}# +にある正しいファイルを編集しないといけませんが、その貢献を提出する前に出来上がりを確認してください。Live マニュアルの出来上がりを確認する際は、 + +code{ + + # apt-get install make po4a ruby ruby-nokogiri sisu-complete + +}code + +を実行してビルドに必要なパッケージがインストールされていることを確認してください。Gitにより取得した最上位のディレクトリから + +code{ + + $ make build + +}code + +サポートされている全言語のマニュアルをビルドするのにはある程度時間がかかるため、著者が英語版のマニュアルに追加した新しい文書について見直す場合は見直し用に処理を省略させると好都合かもしれません。#{PROOF=1}# +を使うと HTML 形式の live-manual をビルドしますが分割版の HTML ファイルを作成しません。#{PROOF=2}# +を使うとPDF形式の live-manual をビルドしますがA4とレター縦だけです。これが #{PROOF=}# +を指定すると時間の節約が見込める理由です。例えば: + +code{ + + $ make build PROOF=1 + +}code + +翻訳の一つを見直す場合に一つの言語だけをビルドすることもできます。例えば: + +code{ + + $ make build LANGUAGES=ja + +}code + +を実行します。文書の種類を指定してビルドすることもできます。例えば + +code{ + + $ make build FORMATS=pdf + +}code + +あるいは両方を組み合わせて + +code{ + + $ make build LANGUAGES=de FORMATS=html + +}code + +修正が済んで全て良くなったらコミットですが、そのコミットで翻訳を更新するのでない限り #{make commit}# +を使わないようにしてください。また、その場合にマニュアルの英語版への変更と翻訳を一度にコミットするのではなく、それぞれ分けてコミットするようにしてください。さらなる詳細については{翻訳}#translation +節を見てください。 + +3~translation 翻訳 + +live-manual +を翻訳するには、新しく最初から翻訳を開始するのか、それとも既に存在する翻訳について作業を続けるのか、によって以下の手順を追ってください: + +_* 新しく最初から翻訳を開始する + +_2* #{manual/pot/}# にある +*{about_manual.ssi.pot}*、*{about_project.ssi.pot}*、*{index.html.in.pot}*ファイルを +(/{poedit}/ 等) 好みのエディタで自分の言語に翻訳し、整合性確認のため翻訳した #{.po}# +ファイルをメーリングリストに送ってください。live-manual の整合性確認では #{.po}# ファイルが 100% +翻訳されていることだけではなく誤りの可能性を検出します。 + +_2* 確認が済んだ後は、自動ビルドでの新しい言語の有効化は最初の翻訳済みファイルを #{manual/po/${言語}/}# に追加して #{make +commit}# を実行すれば十分です。それから #{manual/_sisu/home/index.html}# を編集して言語の名前と () +内にその英語名を追加してください。 + +_* 既に存在する翻訳について作業を続ける + +_2* 対象の言語が既に追加されている場合は、(/{poedit}/ 等) 好みのエディタで #{manual/po/}# にある残りの po +ファイルを手当たり次第に翻訳を続けてください。 + +_2* 翻訳済みマニュアルが .po ファイルから更新されていることを確実にするためには #{make commit}# +を行う必要があることと、#{git add .}#、#{git commit -m "Translating..."}#、#{git push}# +を実行する前に #{make build}# を実行すると変更を確認できるということを忘れないでください。#{make build}# +には相当の時間がかかる可能性があるため、{変更の適用}#applying-changes +で説明しているように、見直しの際は1つの言語だけをビルドして確認できることを覚えておくといいでしょう。 + +#{make commit}# +を実行するとテキストがいくらか流れていくのを目にするでしょう。これは基本的に処理状態についての情報を示すメッセージで、Live +マニュアルの改善のために何ができるのかということを知る手がかりにもなります。致命的エラーが起きていない限り、通常はそのまま進めて貢献を提出できます。 + +Live マニュアルには、翻訳者が未翻訳や変更された文字列を検索するのを大きく支援する2つのユーティリティが付属しています。1つ目は「make +translate」です。これは各 .po ファイル中にどれだけ未翻訳文字列があるのか、詳細を報告するスクリプトを実行します。2つ目は「make +fixfuzzy」で、こちらは変更された文字列だけを対象としますが、1つ1つ見つけて修正する作業を支援します。 + +こういったユーティリティはコマンドラインで翻訳作業を行うのには実際に役立つかもしれませんが、推奨する作業方法は /{poedit}/ +のような専用ツールの利用だということに留意してください。Debian 地域化 (l10n) 文書や、特に Live +マニュアル向けの{翻訳者向けのガイドライン}#guidelines-translators を読むのも良いことです。 + +*{注意:}* gitツリーを push する前に #{make clean}# を実行してきれいにすることができます。この手順は .gitignore ファイルのおかげで強制ではありませんが、ファイルを意図せずコミットすることを避けられる良い実践となります。 diff --git a/markup/pod/live-manual/media/text/ja/about_project.ssi b/markup/pod/live-manual/media/text/ja/about_project.ssi new file mode 100644 index 0000000..f458c27 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/about_project.ssi @@ -0,0 +1,85 @@ +:B~ ${project}への貢献 + +1~about-project ${project}について + +2~ 動機 + +3~ 現在の Live システムの問題点 + +${project}が始まったとき、利用可能な Debian ベースの Live システムは既に複数あり、素晴らしい作業を行っていました。Debian +の視点から見て、そのほとんどには以下のような不満があります。 + +_* Debian のプロジェクトではないために Debian でのサポートがない。 + +_* 異なるディストリビューション、例えば*{安定版 (testing)}* と*{不安定版 (unstable)}* を混ぜて使っている。 + +_* サポートしているのが i386 だけ。 + +_* 容量節約のためにパッケージの挙動や見た目を変更している。 + +_* Debian アーカイブ外のパッケージを収録している。 + +_* Debian のものではない追加パッチを適用した独自カーネルを使っている。 + +_* 本体のサイズのために巨大で遅く、レスキュー用途に合わない。 + +_* 異なる形式、例えば CD、DVD、USB メモリ、netboot イメージから利用できない。 + +3~ 自身の Live システムを作成する理由 + +Debian はユニバーサルオペレーティングシステムです: Debian に Live システムがあることで Debian +システムを案内、正確に表現することができるとともに、主に以下の利点があります: + +_* これは Debian のサブプロジェクトです。 + +_* 単一のディストリビューションの (現在の) 状態を反映します。 + +_* 可能な限り多くのアーキテクチャで動作します。 + +_* 変更しない Debian パッケージだけで構成されます。 + +_* Debian アーカイブにないパッケージは何も含まれません。 + +_* 改変しない Debian のカーネルを追加パッチなしで利用します。 + +2~ 哲学 + +3~ Debian「main」の変更しないパッケージしか使いません + +「main」Debian リポジトリのパッケージだけを利用します。「non-free」は Debian の中には含まれないため、公式の Live +システムのイメージでは利用できません。 + +いかなるパッケージも変更しません。何か変更が必要であれば Debian のそのパッケージのメンテナと調整を行います。 + +例外として、live-boot や live-build、live-config といった私達の独自のパッケージを開発用の目的 +(例えば開発用スナップショットの作成) のため私達自身のリポジトリから一時的に利用するかもしれません。このパッケージ群は定期的に Debian +にアップロードされます。 + +3~ Live システム固有のパッケージ設定はありません + +現段階で、インストール例や代替設定は組み込んでいません。パッケージが利用されるのは Debian +を普通にインストールした後のものなので全てデフォルト設定です。 + +別のデフォルト設定が必要であれば Debian のそのパッケージのメンテナと調整を行います。 + +debconf を使うことで提供されるパッケージ設定システムにより、独自に作成した Live +システムのイメージを使って独自に設定したパッケージをインストールすることができるようになりますが、{ビルド済み Live +イメージ}#downloading-prebuilt-images では Live +環境で動作させるために絶対に必要だという場合を除いて、パッケージをそのデフォルト設定のままにすることを選択しました。Live +用ツールチェインや{ビルド済みイメージ設定}#clone-configuration-via-git への変更よりも、そこで可能である限り、Debian +アーカイブにあるパッケージを Live +システムでよりよく動作させることを好みます。さらなる情報については、{独自化概要}#customization-overview を見てください。 + +2~contact 連絡先 + +_* *{メーリングリスト}*: プロジェクトの第一の連絡先は https://lists.debian.org/debian-live/ +のメーリングリストです。debian-live@lists.debian.org +宛てのメールにより、メーリングリストに直接メールを送ることができます。メーリングリストのアーカイブは +https://lists.debian.org/debian-live/ で利用できます。 + +_* *{IRC}*: ユーザや開発者達が irc.debian.org (OFTC) の #debian-live +チャンネルにいます。IRCで質問するときは静かに回答を待ってください。回答が得られないときはメーリングリストにメールで質問してください。 + +_* *{BTS}*: {Debian バグ追跡システム}https://www.debian.org/Bugs/ (BTS) +には、ユーザや開発者により報告されたバグの詳細があります。バグにはそれぞれに番号が与えられ、対処されたものとして指示するまで存在するバグとして扱われます。さらなる情報については{バグの報告}#bugs +を見てください。 diff --git a/markup/pod/live-manual/media/text/ja/appendix_style-guide.ssi b/markup/pod/live-manual/media/text/ja/appendix_style-guide.ssi new file mode 100644 index 0000000..d86d370 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/appendix_style-guide.ssi @@ -0,0 +1,263 @@ +:B~ スタイルガイド + +1~style-guide スタイルガイド + +2~ 著者向けガイドライン + +この節では Live マニュアル向けの技術的文書を記述する際に一般的に考慮すべき事項を扱います。言語特性と推奨手順に分かれています。 + +*{注意:}* 著者はまず{この文書への貢献}#how-to-contribute を読んでください + +3~ 言語特性 + +_* /{平易な英語を使う}/ + +読み手は英語が母国語ではない人の割合が高いことに留意してください。そのため、一般的規則として短く有意な文章を使い、引き続いて終止符を打ってください。 + +これは単純で幼稚な書き方をするように言っているわけではありません。英語が母国語ではない人にとって理解しにくい複雑な従属文にすることを可能な限り避けましょうという提案です。 + +_* /{英語の方言}/ + +最も広く使われている英語の方言はイギリス英語とアメリカ英語なので、ほとんどの著者が非常に高い率でこのどちらかを使っています。共同作業環境下で理想的なのは「国際英語」ですが、既存の全ての方言からどれを使うのが最善なのか決定するのは不可能とは言いませんが非常に困難です。 + +誤解を生まずに複数の方言を混在させることもできるとは思いますが、一般論として一貫性を持たせるようにすべきで、また、イギリス英語やアメリカ英語、その他の英語の方言からどれを使うか自分の裁量で決める前に、他の人がどのように書いているのかを調べてそれを真似るようにしてください。 + +_* /{バランス良く}/ + +偏見を持たないようにしてください。Live +マニュアルに全く関係のない思想への言及を引用することは避けてください。技術的文献は可能な限り中立であるべきです。科学的文献では中立こそが自然です。 + +_* /{政治的に正しく}/ + +性差を表す言葉を可能な限り避けるようにしてください。個人の第三者を持ち出す必要がある場合は「he (彼)」や「she (彼女)」、あるいは「s/he や +s(he) 彼(女)」などと複雑にするよりも「they (彼ら)」を使うのが好ましいです。 + +_* /{簡潔に}/ + +要点を直接述べ、回りくどい表現を使わないようにしてください。必要な情報は十分に提示ながらも、必要以上の余計な情報を提示するのはやめてください。これは不要な詳細を説明しないようにということです。読み手には理解力があります。読み手の側にいくらか前提知識があることを仮定してください。 + +_* /{翻訳作業を最小限に}/ + +書かれたものは他の複数の言語に翻訳されることになるということに留意してください。これは無意味あるいは冗長な情報を追加するとその分余計な作業をする人が出てくるということを意味します。 + +_* /{一貫性を}/ + +前にも提案しましたが、共同作業の文書を標準化して全体を完全に統一することはほぼ不可能です。しかし、文書を書く際に全体を通して他の著者と一貫した書き方をすることを歓迎します。 + +_* /{結束性を}/ + +必要なだけ文脈形成句を使い、文章に結束性を持たせて明確にしてください (文脈形成句は接続語句等の言語標識です)。 + +_* /{記述的に}/ + +標準的な「changelog」形式で文を単に羅列するよりも段落を使って要点を説明する方が好ましいです。描写してください! +読み手はそれを歓迎するでしょう。 + +_* /{辞書}/ + +英語で特定の概念を表現する方法がわからないときは辞書や百科事典でその語の意味を調べてください。ただし、辞書は最高の友ですが正しい使い方を知らなければ最悪の敵にもなることに留意してください。 + +英語には最大の語彙が存在する言語の一つです +(100万語以上)。この語の多くは他の言語から取り入れられたものです。単語の意味を二カ国語の辞書で調べる際、英語が母国語ではない人は母国語の言葉により似ているものを選択する傾向があります。このことにより、英語ではあまり自然に聞こえない、過度に形式ばった文体になりがちです。 + +原則として、ある概念が複数の異なる同義語により表現できるとき、辞書で最初に提示された語を選択するのが良い判断となるでしょう。疑問がある場合はゲルマン起源の語 +(通常単音節の語) +を選択すると多くの場合正しいとなります。この2つの技ではどちらかというとくだけた表現になるかもしれないという点には注意が必要ですが、少なくとも広く使われていて通常受け入れられる語を選択することになります。 + +共起辞書の利用を勧めます。通常合わせて利用する語がわかるようになると極めて役に立ちます。 + +繰り返しますが、他の人の作業から学ぶことが最良の実践です。検索エンジンを使って他の著者が特定の表現をどのように使っているか確認することは大きな手助けとなるでしょう。 + +_* /{空似言葉や熟語その他の慣習的な表現}/ + +空似言葉に気をつけてください。外国語の熟練度を問わず、2つの言語で同じように見える語だけれどもその意味や使い方が全く異なる「空似言葉」という罠にはまることがあることは避けられません。 + +熟語は可能な限り避けてください。「熟語」は個々の語が持っていた意味とは完全に異なる意味を表すことがあります。熟語は英語が母国語の人でさえ理解しにくいこともあります! + +_* /{俗語や省略、短縮表現等は避けましょう}/ + +平易な、日常的な英語の使用を勧めるとはいっても、技術的文献は言語を正式に記録する類のものです。 + +俗語や通常使わない解釈困難な省略表現、特に母国語での表現を模倣するような短縮表現は避けてください。IRCや、家族や仲間内で使うような特有の表現での記述はしないでください。 + +3~ 手順 + +_* /{書く前にテストを}/ + +著者が Live マニュアルに追加する前に例をテストして、全て確実に説明通りに動作するようにすることは重要です。きれいな chroot +やVM環境でのテストが良い起点となるでしょう。他に、それから異なるハードウェアを使っている異なるマシンでテストを実施し、起きるであろう問題を発見することができれば理想でしょう。 + +_* /{例}/ + +例示するときはできるだけ具体的にするようにしてください。例は結局例でしかありませんから。 + +抽象的な表現で読み手を混乱させるよりも、特定の状況でのみ適用できるような書き方をする方がより良いことはよくあります。この場合は提示した例の効果を簡単に説明することもできます。 + +使い方を誤ればデータ消失や類似の望ましくない影響を及ぼす可能性のある、潜在的に危険なコマンド類の使用を例示する場合等、例外がいくらかあります。この場合は起こりうる副作用について十分な説明を提供すべきです。 + +_* /{外部リンク}/ + +外部サイトへのリンクは、そのサイトにある情報が特別な点を理解するために決定的な効果が期待できる場合にのみ利用すべきです。その場合でも、外部サイトへのリンクは可能な限り少なくしてください。インターネット上のリンクはその内容がほとんどが変更される可能性があるもので、その結果機能しないリンクができたり、論拠を不完全な状態にしてしまうことになります。 + +他に、インターネットに接続せずにそのマニュアルを読んでいる人にはそのリンクを追う機会がありません。 + +_* /{商標の主張やマニュアルの公開にあたって採用したライセンスに違反するものは避ける}/ + +商標の主張は可能な限り避けてください。記述した文書は他の下流のプロジェクトで使うことになるかもしれないことに留意してください。つまり、ある種の特定の内容を追加することは事態を複雑にすることになります。 + +live-manual は GNU GPL の条件下で使用を許可しています。これには、合わせて公開する (著作権のある画像やロゴを含むあらゆる種類の) +内容の配布物に適用する意味合いがいくつかあります。 + +_* /{まず草稿を書き、改訂、変更して改善し、必要なら作り直す}/ + + - 案を引き出しましょう! まず論理的に順を追って考えを整理する必要があります。 + + - 頭の中で何とか形ができたら最初の草稿を書きます。 + + - 文法や書式、つづりを直します。リリースの正しい名前は ${testing} や sid + で、これをコード名として参照するときは大文字にすべきではないことに留意してください。「spell」ターゲットを使って、つまり#{make + spell}#でつづりの誤りがないか確認できます。 + + - 記述を改善し、必要な部分があれば書き直します。 + +_* /{章}/ + +章や副題には慣習的な番号の付け方をしてください。例えば 1、1.1、1.1.1、1.1.2 ... 1.2、1.2.1、1.2.2 ... 2、2.1 +... などというようにです。以下のマークアップを見てください。 + +説明するのに一連の手順や段階を列挙する必要がある場合は、First (最初に)、second (2つ目に)、third (3つ目に) +... というように序数を使ったり、First (最初に)、Then (それから)、After that (その後)、Finally +(最後に)、... あるいは箇条書きすることもできます。 + +_* /{マークアップ}/ + +大事なことを言い忘れましたが、live-manual では {SiSU}http://www.sisudoc.org/ +を使ってテキストファイルを処理し、複数の形式の出力を生成しています。{SiSU +マニュアル}http://www.sisudoc.org/sisu/en/html/sisu_manual/markup.html +を眺めてそのマークアップ方法をよく理解することを勧めます。代わりに + +code{ + + $ sisu --help markup + +}code + +と入力する方法もあります。マークアップをいくらか例示してみます。有用だということはわかるかもしれません。 + + - 文字列の強調/太字: + +code{ + +*{foo}* または !{foo}! + +}code + +は「*{foo}* または !{foo}!」となります。これは特定のキーワードを強調するのに使います。 + + - 斜体: + +code{ + +/{foo}/ + +}code + +は /{foo}/ となります。これは例えば Debian パッケージの名前に使います。 + + - 等幅: + +code{ + +#{foo}# + +}code + +は #{foo}# となります。これは例えばコマンドの名前に使います。また、キーワードやパスのようなものの一部を強調するのにも使います。 + + - コードブロック: + +code{ + + code{ + + $ foo + # bar + + }code + +}code + +は + +code{ + + $ foo + # bar + +}code + +となります。タグの開始には #{code{}# を、終了には #{}code}# +を使います。コードの各行には先頭に空白が必要だということを必ず覚えておいてください。 + +2~guidelines-translators 翻訳者向けガイドライン + +この節では Live マニュアルの内容を翻訳する際に一般的に考慮すべき事項を扱います。 + +一般的な推奨事項として、翻訳者は自分の言語に適用される翻訳規則を既に読んで理解しておくべきです。通常、翻訳用のグループやメーリングリストが Debian +の品質標準に合致する翻訳物を作成する方法についての情報を提供しています。 + +*{注意:}* 翻訳者は{この文書への貢献}#how-to-contribute も読むべきです。特に{翻訳}#translation 節を + +3~ 翻訳の手がかり + +_* /{コメント}/ + +翻訳者の役割は元の著者により書かれた語や文、段落、そして文章の意味を可能な限り忠実に目標の言語で伝えることです。 + +そのため、個人的なコメントや自分の余計な情報の追加は控えるべきです。同一の文書について作業している他の翻訳者に向けてコメントを追加したい場合はそのために用意されている場があります。これは +*{po}* ファイルの番号記号 *{#}* +に続く文字列のヘッダです。ほとんどの視覚的な翻訳用プログラムで自動的にこれをコメントの種類に属するものとして処理します。 + +_* /{TN, Translator's Note (翻訳者によるメモ)}/ + +完全に受け入れられるとはいえ、翻訳済みテキストの括弧「()」内に語や表現を含めることは、ややこしい語や表現の意味を読み手にとってより明確にする場合にのみ行ってください。翻訳者は括弧内に「(訳注)」等と記載して、その追記が翻訳者によるものであることを明確にすべきです。 + +_* /{非人称の文を}/ + +英語で書かれた文書は「you」を非人称として幅広く使います。他の言語にはこの特徴を共有しないものもあります。このことで、元の文が読み手に対して直接呼びかけているかのような誤った印象を実際にはそうではないのに与えてしまうかもしれません。翻訳者はこの点に注意して、可能な限り正確に自分の言語に反映する必要があります。 + +_* /{空似言葉}/ + +前に説明した「空似言葉」の罠は特に翻訳者に当てはまります。疑いがあれば、その疑わしい空似言葉の意味を再点検してください。 + +_* /{マークアップ}/ + +最初は*{pot}*ファイル、後には*{po}*ファイルについて作業する翻訳者は多数のマークアップ機能を文字列に確認できるでしょう。文は翻訳できるものである限り翻訳できますが、それが元の英語版と全く同一のマークアップを採用しているということは極めて重要です。 + +_* /{コードブロック}/ + +コードブロックは通常翻訳できませんが、翻訳にそれを含めることが、翻訳率 100% +を達成する唯一の方法です。コードが変更されると翻訳者による介入が必要となるため最初は余計な作業になりますが、長期的に見るとこれが .po +ファイルの整合性を確認したときに何が既に翻訳済みで何が未翻訳なのか識別する最善の方法です。 + +_* /{改行}/ + +翻訳文には元の文と全く同じだけの改行が必要です。元のファイルに改行があるときは注意して「Enter」キーを押すか*{\n}*を打ち込んでください。改行は例えばコードブロック中でよく使われます。 + +勘違いしないでください。これは翻訳文を英語版と同一の長さにする必要がある、ということではありません。それはほぼ不可能です。 + +_* /{翻訳できない、してはいけない文字列}/ + +翻訳者が決して翻訳すべきでないもの: + + - リリースのコード名 (小文字で書くべき) + + - プログラムの名前 + + - 例示するコマンド + + - メタ情報 (前後にコロンが置かれることが多い *{:メタ情報:}*) + + - リンク + + - パス diff --git a/markup/pod/live-manual/media/text/ja/examples.ssi b/markup/pod/live-manual/media/text/ja/examples.ssi new file mode 100644 index 0000000..1d6fa99 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/examples.ssi @@ -0,0 +1,383 @@ +:B~ 例 + +1~examples 例 + +この章では特定の Live システム活用事例向けの見本ビルドについて触れます。自分用の Live +システムイメージのビルドが初めてであれば、まず3つのチュートリアルを順に調べてみることを勧めます。それぞれで他の例の利用、理解を支援する新しい技術を学ぶようになっているためです。 + +2~using-the-examples 例の使用 + +提示している例を利用するためには、ビルドするために{要件}#requirements +に記載されている要件一覧に合致するシステムと、{live-build のインストール}#installing-live-build で説明しているように +live-build がインストールされていることが必要となります。 + +簡潔にするため、ここに挙げる例ではビルドで利用するローカルミラーを指定していないことに注意してください。ローカルミラーを利用するとダウンロード速度をかなり高速化できます。{ビルド時に利用するディストリビューションのミラー}#distribution-mirrors-build-time +で説明しているように、#{lb config}# を使った場合はオプションを指定することができます。ビルドシステムのデフォルト値を +#{/etc/live/build.conf}# でセットするともっと便利になります。このファイルを単純に作成し、対応する +#{LB_MIRROR_*}# +変数に望ましいミラーをセットしてください。ビルドで利用する他のミラーは全て、これにより設定した値をデフォルト値として使います。例えば: + +code{ + + LB_MIRROR_BOOTSTRAP="http://mirror/debian/" + LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security/" + LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-backports/" + +}code + +2~tutorial-1 チュートリアル 1: デフォルトイメージ + +*{事例:}* 簡単な最初のイメージを作成して live-build の基礎を学びます。 + +このチュートリアルでは、live-build を利用した最初の演習としてbase パッケージ (Xorg は含まない) と Live +システムを支援するパッケージだけを収録する、デフォルトの ISO hybrid 形式の Live システムイメージをビルドします。 + +これ以上簡単にすることはなかなかできないでしょう: + +code{ + + $ mkdir tutorial1 ; cd tutorial1 ; lb config + +}code + +何か望むことがあれば #{config/}# +ディレクトリの内容を調べてください。ここには概略の設定があり、すぐ独自化もできますが、ここではそのままでデフォルトのイメージをビルドします。 + +スーパーユーザでイメージをビルドし、そのログを #{tee}# により保存します。 + +code{ + + # lb build 2>&1 | tee build.log + +}code + +すべてがうまくいくとして、しばらくすると現在のディレクトリに #{live-image-i386.hybrid.iso}# が出来上がります。この +ISO hybrid イメージは {Qemu でのISOイメージのテスト}#testing-iso-with-qemu や {VirtualBox +でのISOイメージのテスト}#testing-iso-with-virtualbox +で説明しているように仮想マシンで直接、あるいは{物理メディアへのISOイメージ書き込み}#burning-iso-image や {USBメモリへの +ISO hybrid イメージのコピー}#copying-iso-hybrid-to-usb +で説明しているように光学メディアやUSBフラッシュ機器に書き込んだイメージ、それぞれからブートできます。 + +2~tutorial-2 チュートリアル 2: ウェブブラウザユーティリティ + +*{事例:}* ウェブブラウザユーティリティイメージを作成し、独自化の適用方法を学びます。 + +このチュートリアルでは Live システムイメージを独自化する方法の紹介として、ウェブブラウザユーティリティとしての利用に適するイメージを作成します。 + +code{ + + $ mkdir tutorial2 + $ cd tutorial2 + $ lb config + $ echo "task-lxde-desktop iceweasel" >> config/package-lists/my.list.chroot + +}code + +この例で LXDE +を選択しているのは最小限のデスクトップ環境を提供するという私達の目的を反映しています。念頭に置いているこのイメージの目的はただ一つ、ウェブブラウザだけだからです。もっと細かく、#{config/includes.chroot/etc/iceweasel/profile/}# +でのウェブブラウザ向けデフォルト設定やウェブ上の様々な種類の内容を表示するための追加のサポートパッケージを提供することはできますが、それは読み手の演習として残しておきます。 + +{チュートリアル 1}#tutorial-1 と同様、ここでもスーパーユーザでイメージをビルドし、ログを残します: + +code{ + + # lb build 2>&1 | tee build.log + +}code + +ここでも{チュートリアル 1}#tutorial-1 と同様、イメージがうまくできているか検証し、テストします。 + +2~tutorial-3 チュートリアル 3: 私的イメージ + +*{事例:}* プロジェクトを作成して個人用イメージをビルドします。USBメモリを使って好みのソフトウェアを自由に収録し、要求や設定を変更しながらこのイメージを続けて改訂します。 + +この個人用イメージを何度も改訂し、変更を追跡しておいて実験的に試してみてうまくいかなかったときには差し戻せるようにしたいため、人気のある#{git}#バージョン管理システムに設定を残します。{設定管理}#managing-a-configuration +で説明している #{auto}# スクリプトによる自動設定を経由した最善の実践も利用します。 + +3~ 最初の改訂 + +code{ + + $ mkdir -p tutorial3/auto + $ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/ + $ cd tutorial3 + +}code + +#{auto/config}# を以下のように変更します: + +code{ + + #!/bin/sh + + lb config noauto \ + --architectures i386 \ + --linux-flavours 686-pae \ + "${@}" + +}code + +#{lb config}# を実行して設定ツリーを生成し、生成された #{auto/config}# スクリプトを使います: + +code{ + + $ lb config + +}code + +ここでローカルパッケージ一覧を設定します: + +code{ + + $ echo "task-lxde-desktop iceweasel xchat" >> config/package-lists/my.list.chroot + +}code + +まず、#{--architectures i386}# により必ず #{amd64}# +ビルドシステムでほとんどのマシンでの利用に適応する32ビット版をビルドするようにします。次に、相当に古いシステムでのこのイメージの利用を想定しないため +#{--linux-flavours 686-pae}# を使います。/{lxde}/ +のタスクメタパッケージを選択して最小限のデスクトップを揃えます。最後に、好みのパッケージの初期値として /{iceweasel}/ と +/{xchat}/ を追加しています。 + +そして、イメージをビルドします: + +code{ + + # lb build + +}code + +最初の2つのチュートリアルとは異なり、#{2>&1 | tee build.log}# は #{auto/build}# +に書かれているため打ち込む必要がなくなっていることに注意してください。 + +({チュートリアル 1}#tutorial-1 にあるように) +イメージをテストしてうまく機能する確信を得たら#{git}#リポジトリを初期化し、作成したばかりの auto +スクリプトだけを追加し、最初のコミットを行います: + +code{ + + $ git init + $ cp /usr/share/doc/live-build/examples/gitignore .gitignore + $ git add . + $ git commit -m "Initial import." + +}code + +3~ 2回目の改訂 + +この改訂では、最初のビルドをきれいにし、/{vlc}/ パッケージを設定に追加して再ビルド、テストコミットを行います。 + +#{lb clean}# +コマンドは前のビルドで生成したファイルを、パッケージを再びダウンロードせずに済むようにキャッシュを除いて全てきれいにします。これにより以降の #{lb +build}# が全段階で再び実行され、必ず新しい設定でファイルを再生成するようになります。 + +code{ + + # lb clean + +}code + +/{vlc}/ パッケージを #{config/package-lists/my.list.chroot}# のローカルパッケージ一覧に追記します: + +code{ + + $ echo vlc >> config/package-lists/my.list.chroot + +}code + +再びビルドします: + +code{ + +# lb build + +}code + +テストして満足したら次の改訂としてコミットします: + +code{ + + $ git commit -a -m "Adding vlc media player." + +}code + +もちろん、#{config/}# +以下のサブディレクトリにファイルを追加する等により設定をもっと複雑に変更することも可能です。新しい改訂版をコミットする際、#{config}# +の最上位にある、#{LB_*}# 変数を設定しているファイルもビルドされてできたもので、#{lb clean}# と、対応する #{auto}# +スクリプトを経由して再作成した #{lb config}# により常に整理されるものなので、手で編集したりコミットすることのないように注意してください。 + +一連のチュートリアルもこれで終わりです。もっと多様な独自化はできますが、ここまでの簡単な例で見てきた少しの機能を使うだけでも、イメージはほぼ無限の異なる組み合わせを作成することができます。この節の残りの例では、収集してきた +Live システムのユーザの経験を元にした他の事例についていくつか触れます。 + +2~ VNC 公衆クライアント + +*{事例:}* live-build を使って、ブートすると直接 VNC サーバに接続するイメージを作成します。 + +ビルド用ディレクトリを作ってそこに概略設定を作成し、推奨パッケージを無効にして最小限のシステムを作成します。それから初期パッケージ一覧を2つ作成します: +1つ目は live-build により提供される #{Packages}# というスクリプト +({生成されるパッケージ一覧}#generated-package-lists 参照) により生成し、2つ目では +/{xorg}/、/{gdm3}/、/{metacity}/、/{xvnc4viewer}/ を収録します。 + +code{ + + $ mkdir vnc-kiosk-client + $ cd vnc-kiosk-client + $ lb config -a i386 -k 686-pae --apt-recommends false + $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot + $ echo "xorg gdm3 metacity xvnc4viewer" > config/package-lists/my.list.chroot + +}code + +{APT の調整による容量の節約}#tweaking-apt-to-save-space +で説明しているように、イメージが適切に機能するためには推奨パッケージを再びいくらか追加する必要があるかもしれません。 + +推奨パッケージ一覧を調べるための簡単な方法として /{apt-cache}/ の利用があります。例えば: + +code{ + + $ apt-cache depends live-config live-boot + +}code + +この例では live-config 及び live-boot により推奨されるパッケージを複数、再び収録する必要があることがわかっています: +自動ログインが機能するためには #{user-setup}#、システムをシャットダウンするための不可欠なプログラムとして +#{sudo}#。他に、イメージをRAMにコピーできるようになる #{live-tools}# や Live メディアを最終的に取り出す +#{eject}# を追加しておくと便利でしょう。それを反映すると: + +code{ + + $ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot + +}code + +その後ディレクトリ #{/etc/skel}# を #{config/includes.chroot}# に作成し、その中にデフォルトユーザ向けの独自の +#{.xsession}# を置きます。このファイルは /{metacity}/ を立ち上げて /{xvncviewer}/ +を起動し、#{192.168.1.2}# にあるサーバのポート #{5901}# に接続します: + +code{ + + $ mkdir -p config/includes.chroot/etc/skel + $ cat > config/includes.chroot/etc/skel/.xsession << EOF + #!/bin/sh + + /usr/bin/metacity & + /usr/bin/xvncviewer 192.168.1.2:1 + + exit + EOF + +}code + +イメージをビルドします: + +code{ + + # lb build + +}code + +楽しみましょう。 + +2~ 128MB USB メモリ向けの基本イメージ + +*{事例:}* 128MB USB メモリに収まるように構成要素をいくらか削除して、収まることがわかるように容量を少し空けたデフォルトのイメージの作成。 + +特定のメディア容量に収まるようにイメージを最適化する場合、イメージのサイズと機能はトレードオフになることを理解する必要があります。この例では削るだけにしているので +128MB のメディアサイズ内に何か追加する余地をできるだけ残していますが、/{localepurge}/ +パッケージによるロケールの完全削除や収録しているパッケージ内の一貫性は何も壊していません。また、その他の「押し付ける」ような最適化もしていません。特に注目すべきなのは、最小限のシステムを最初から作成するために +#{--debootstrap-options}# を利用している点です。 + +code{ + + $ lb config --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none + +}code + +イメージを適切に機能させるためには、最低でも #{--apt-recommends false}# +オプションにより外されていた推奨パッケージを2つ追加しなおす必要があります。{APTの調整による容量の節約}#tweaking-apt-to-save-space +を見てください。 + +code{ + + $ echo "user-setup sudo" > config/package-lists/recommends.list.chroot + +}code + +ここで、普通の方法でイメージをビルドしてみます: + +code{ + + # lb build 2>&1 | tee build.log + +}code + +これを書いている時点の著者のシステムでは、上記の設定により 110MB のイメージができました。これを{チュートリアル 1}#tutorial-1 +のデフォルト設定で作成された 192MB のイメージと都合良く比較してみましょう。 + +#{--apt-indices false}# によりAPTの索引を省くことでかなりの容量を節約していますが、その代わりに Live システムで +/{apt}/ を使う前に #{apt-get update}# を実行する必要があります。#{--apt-recommends false}# +により推奨パッケージを除外することで、本来あるはずのパッケージをいくらか除外する代わりにいくらか追加で容量を節約します。#{--debootstrap-options +"--variant=minbase"}# で最初から最小限のシステムを構成します。#{--firmware-chroot false}# +でファームウェアパッケージを自動的に収録しないようにすることでもさらに容量をいくらか節約します。そして最後に、#{--memtest none}# +によりメモリテスターのインストールを抑制します。 + +*{注意:}* 最小限のシステムの構成はフックを使って、例えば #{/usr/share/doc/live-build/examples/hooks}# にある #{stripped.hook.chroot}# でも実現できます。これは容量をさらに少し減らし、62MB のイメージを生成します。しかしこれはその実現のために、システムにインストールしたパッケージから文書その他のファイルを削除しています。これはそうしたパッケージの完全性を破壊し、ヘッダで警告しているように思わぬ結果をもたらすかもしれません。それが、この目標のために推奨するのが最小限の /{debootstrap}/ を利用する方法になっている理由です。 + +2~ 地域化した GNOME デスクトップとインストーラ + +*{事例:}* GNOME デスクトップのイメージを作成し、スイス用の地域化とインストーラを収録する + +好みのデスクトップを使った i386 アーキテクチャ向けの iso-hybrid イメージを作りたい。ここでは GNOME を使用して、GNOME +用の標準の Debian インストーラによりインストールされるのと同一のパッケージを全て収録します。 + +最初の問題は適切な言語用タスクの名前を判断する方法です。現在 live-build +はこれを支援できません。運良くこれを試行錯誤で見つけられるかもしれませんが、そのためのツールがあります。#{grep-dctrl}# を利用して +tasksel-data にあるタスクの説明を見つけることができます。そのため、準備としてこの両方が揃っていることを確認してください: + +code{ + + # apt-get install dctrl-tools tasksel-data + +}code + +これで適切なタスクを検索できるようになりました。まず、 + +code{ + + $ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask + Task: german + +}code + +というコマンドにより、呼ばれたタスクが、簡単に言うとここではドイツだということがわかります。次は関連タスクを見つけます: + +code{ + + $ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask + Task: german-desktop + Task: german-kde-desktop + +}code + +ブート時に *{de_CH.UTF-8}* ロケールを生成して *{ch}* +のキーボードレイアウトを選択します。一緒に見ていきましょう。{メタパッケージの利用}#using-metapackages +から、タスクのメタパッケージには先頭に #{task-}# +が付くことを思いだしてください。こういった言語のブートパラメータを指定し、それから優先度が標準のパッケージと発見したタスクの全メタパッケージをパッケージ一覧に追加するだけです: + +code{ + + $ mkdir live-gnome-ch + $ cd live-gnome-ch + $ lb config \ + -a i386 \ + --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" \ + --debian-installer live + $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot + $ echo task-gnome-desktop task-german task-german-desktop >> config/package-lists/desktop.list.chroot + $ echo debian-installer-launcher >> config/package-lists/installer.list.chroot + +}code + +のようになります。インストーラを Live デスクトップから立ち上げるために /{debian-installer-launcher}/ +パッケージを収録していることに注意してください。さらに、インストーラを立ち上げる機能が適切に動作するために現在必要な #{586}# +用のカーネルがデフォルトで収録されます。 diff --git a/markup/pod/live-manual/media/text/ja/index.html.in b/markup/pod/live-manual/media/text/ja/index.html.in new file mode 100644 index 0000000..8ee8824 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/index.html.in @@ -0,0 +1,66 @@ +<html> + +<head> + <title>Live システムプロジェクト</title> + <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> +</head> + +<body> + <h2>Live システムマニュアル</h2> + + <p> + <i>live-manual</i> +は複数のファイル形式が利用可能で、複数の言語に翻訳されています。翻訳によっては不完全なものや最新ではないかもしれないことに留意してください。 + </p> + + <p> + + 誤りや欠落、パッチや提案があれば <a +href="mailto:debian-live@lists.debian.org">debian-live@lists.debian.org</a> +のメーリングリストに報告してください。また、このマニュアルへの<a +href="html/live-manual.ja.html#how-to-contribute">この文書への貢献</a>を読んでください。 + </p> + + <h3>利用可能な形式</h3> + + <ul> + <li><a href="epub/live-manual.ja.epub">EPUB</a></li> + <li>HTML: <a href="html/live-manual/toc.ja.html">複数ページ版</a>、<a +href="html/live-manual.ja.html">単一ページ版</a></li> + <li><a href="odt/live-manual.ja.odt">ODF</a></li> + <li>PDF: <a href="pdf/live-manual.portrait.ja.a4.pdf">A4縦</a>, <a +href="pdf/live-manual.landscape.ja.a4.pdf">A4横</a>, <a +href="pdf/live-manual.portrait.ja.letter.pdf">レター縦</a>, <a +href="pdf/live-manual.landscape.ja.letter.pdf">レター横</a></li> + <li><a href="txt/live-manual.ja.txt">テキスト版</a></li> + </ul> + + <p> + 最終変更日時: @DATE_CHANGE@<br /> + 最終ビルド日時: @DATE_BUILD@ + </p> + + <h3><a href="search.cgi">検索</a></h3> + + <h3>ソース</h3> + + <p> + このマニュアルのソースは live-systems.org の<a +href="http://git-scm.com/">Git</a>リポジトリから利用できます。 + </p> + + <ul> + <li>閲覧: <a +href="http://live-systems.org/gitweb/?p=live-manual.git"><small><tt>http://live-systems.org/gitweb/?p=live-manual.git</tt></small></a></li> + <li>Git: <a +href="git://live-systems.org/git/live-manual.git"><small><tt>git://live-systems.org/git/live-manual.git</tt></small></a></li> + </ul> + + <p> + <a href="http://live-systems.org/">Live システムプロジェクト</a> <<a +href="mailto:debian-live@lists.debian.org">debian-live@lists.debian.org</a>> +- <a href="http://live-systems.org/project/legal/">法的情報</a> + </p> +</body> + +</html> diff --git a/markup/pod/live-manual/media/text/ja/live-manual.ssm b/markup/pod/live-manual/media/text/ja/live-manual.ssm new file mode 100644 index 0000000..d8a6e0d --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/live-manual.ssm @@ -0,0 +1,75 @@ +# SiSU 2.0 + +title: "Live システムマニュアル" + +creator: + author: "Live システムプロジェクト <debian-live@lists.debian.org>" + +rights: + copyright: "Copyright (C) 2006-2015 Live Systems Project" + license: "This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. \\ \\ This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. \\ \\ You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. \\ \\ The complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL-3 file." + +date: + published: "2015-08-23" + +publisher: "Live システムプロジェクト <debian-live@lists.debian.org>" + +classify: + topic_register: "SiSU markup sample:technical writing;software:program" + +make: + num_top: "1" + bold: "\\$\\{stable\\}|\\$\\{testing\\}|stretch|buster|sid" + italics: "live-boot|live-build|live-config|live-config-sysvinit|live-manual|live-tools|live-images|live-installer|debian-installer-launcher" +# bold: "[$][{]stable[}]|[$][{]testing[}]|stretch|buster|sid" +# substitute: "/${stable}/,'stretch' /${testing}/,'buster' /${project}/,'Live システムプロジェクト'" + +:A~ @title + +:B~ About + +<< about_manual.ssi + +<< about_project.ssi + +:B~ ユーザ + +<< user_installation.ssi + +<< user_basics.ssi + +<< user_overview.ssi + +<< user_managing_a_configuration.ssi + +<< user_customization-overview.ssi + +<< user_customization-packages.ssi + +<< user_customization-contents.ssi + +<< user_customization-runtime.ssi + +<< user_customization-binary.ssi + +<< user_customization-installer.ssi + +:B~ プロジェクト + +<< project_contributing.ssi + +<< project_bugs.ssi + +<< project_coding-style.ssi + +<< project_procedures.ssi + +<< project_git.ssi + +:B~ 例 + +<< examples.ssi + +:B~ 付録 + +<< appendix_style-guide.ssi diff --git a/markup/pod/live-manual/media/text/ja/project_bugs.ssi b/markup/pod/live-manual/media/text/ja/project_bugs.ssi new file mode 100644 index 0000000..11018fb --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/project_bugs.ssi @@ -0,0 +1,156 @@ +:B~ バグの報告 + +1~bugs バグの報告 + +Live システムは完璧にはほど遠いですが、可能な限り完璧に近づけたいと思っています - +あなたの支援とともに。バグの報告を躊躇わないでください。バグがあるのに報告されないよりも二重に報告される方がいいからです。この章ではバグ報告を提出するにあたっての推奨事項について説明します。 + +せっかちな人向け: + +_* 常にまず http://live-systems.org/ にある私達のホームページにあるイメージの更新状況により既知の問題を確認してください。 + +_* バグ報告を提出する前に使用している live-build、live-boot、live-config、live-tools +のブランチの*{最新版}* (live-build 4 を使っているなら最新のバージョン 4.x の live-build) +でそのバグを再現できるか常に確認します。 + +_* バグについて*{できるだけ具体的な情報}*を提示するようにしてください。これには (最低限) 利用した +live-build、live-boot、live-config、live-tools のバージョンや Live +システムをどのディストリビューションでビルドしたのか、等があります。 + +2~ 既知の問題 + +Debian *{テスト版 (testing)}* と Debian *{不安定版 (unstable)}* +ディストリビューションは変化しているのでこのどちらかを対象システムディストリビューションに指定している場合、ビルドが常に成功するとは限りません。 + +% FIXME: + +そのためにあまり困難になる場合はビルドに*{テスト版 (testing)}* や*{不安定版 (unstable)}* +をベースにしたシステムではなく*{安定版 (stable)} を使ってください。live-build は常に*{安定版 (stable)}* +リリースをデフォルトとしています。 + +現在わかっている問題は http://live-systems.org/ にある私達のホームページの「status」に一覧があります。 + +開発用ディストリビューションのパッケージにある問題を正しく識別、修正するための訓練はこのマニュアルの目的ではありませんが、常に確認できることが2つあります: +*{テスト版 (testing)}* を対象ディストリビューションとしてビルドに失敗した場合に*{不安定版 (unstable)}* +で試してみるということです。*{不安定版 (unstable)}* でもダメな場合は*{テスト版 (testing)}* +に差し戻し、失敗しているパッケージのもっと新しいバージョンを*{不安定版 (unstable)}* から利用するようにしてみます (詳細については +{APTのPIN設定}#apt-pinning 参照)。 + +2~ 最初から再ビルド + +きれいではない環境でシステムがビルドされたことにより特定のバグが発生しているのではないことを保証するため、Live +システム全体を最初から再ビルドして、そのバグが再現するか常に確認してください。 + +2~ 最新のパッケージを使う + +問題を再現 (最終的には修正) +しようとするときに古くなったパッケージを使用すると重大な問題を引き起こす可能性があります。ビルドシステムが最新であること、同様にそのイメージに収録されているパッケージがどれも最新であることを確認してください。 + +2~collect-information 情報収集 + +報告では十分な情報を提供してください。最低でもそのバグが発生した live-build +の正確なバージョンとそれを再現する手順を含めてください。常識的に考えて問題解決の支援になりそうだと思う関連情報が何か他にあればそれも提供してください。 + +バグ報告を最大限に活用するため、最低限次の情報が必要です: + +_* ホストシステムのアーキテクチャ + +_* ホストシステムのディストリビューション + +_* ホストシステムの live-build のバージョン + +_* ホストシステムの /{debootstrap}/ のバージョン + +_* Live システムのアーキテクチャ + +_* Live システムのディストリビューション + +_* Live システムの live-boot のバージョン + +_* Live システムの live-config のバージョン + +_* Live システムの live-tools のバージョン + +#{tee}# コマンドを使ってビルドプロセスのログを生成することができます。#{auto/build}# +スクリプトによりこれを自動的に行うことを推奨します (詳細は{設定管理}#managing-a-configuration 参照)。 + +code{ + + # lb build 2>&1 | tee build.log + +}code + +ブート時に、live-boot と live-config はログファイルを #{/var/log/live/}# +に保存します。エラーメッセージはここを確認してください。 + +さらに、他のエラーを除外するため、#{config/}# ディレクトリを tar でまとめてどこかにアップロードするのは常に良い方法です +(メーリングリストに添付として送ら*{ないでください}*)。それにより、そのエラーの再現を試みることが可能になります。それが +(例えばサイズの問題により) 困難な場合は #{lb config --dump}# の出力を使ってください。これは設定ツリーのまとめです (つまり +#{config/}# のサブディレクトリにあるファイル一覧を列挙しますがファイル自体は収録しません)。 + +ログは全て英語のロケール設定で生成されたものを提示することを忘れないでください。例えば先頭に #{LC_ALL=C}# や +#{LC_ALL=en_US}# を付けて live-build コマンドを実行してください。 + +2~ 可能であれば失敗している状況を分離する + +可能であれば失敗している状況を可能な限りうまくいかなくなる最小の変更に分離してください。これは常に簡単だとは限らないので、報告の際にできないようであれば気にする必要はありません。しかし、開発サイクルを向上させたい場合、繰り返しのたびに変更する量を十分に小さくすると、実際の設定により近く、より単純な「ベース」設定を構成することによりうまくいかなくなる追加の変更点だけに問題を分離することができるかもしれません。どの変更によりうまくいかなくなっているのか区別するのに苦労している場合、それぞれの変更点が多すぎることが考えられ、その場合開発の進行は緩くなるはずです。 + +2~ 正しいパッケージに対してバグを報告する + +どの構成要素がそのバグの原因なのかわからない、あるいはそのバグが Live システム全般に関係するバグである場合は debian-live +疑似パッケージに対するバグとして報告してください。 + +とはいうものの、バグの現れ方を元にその範囲を限定してくれると助かります。 + +3~ ビルド時のパッケージ収集中 + +live-build は最初に /{debootstrap}/ で Debian +システムの基本的なパッケージを収集します。バグがここで起きていると思われる場合は、そのエラーが特定の Debian パッケージに +(ほとんどの場合こちらです) 関連するのか、パッケージ収集ツール自体に関連するものなのか確認してください。 + +どちらの場合でも、これは Live システムではなく Debian +自体のバグで、恐らく私達が直接修正することはできません。こういったバグはパッケージ収集ツールまたは失敗しているパッケージに対して報告してください。 + +3~ ビルド時のパッケージインストール中 + +live-build は追加のパッケージを Debian アーカイブからインストールしているため、利用する Debian +ディストリビューションとその日のアーカイブの状態によっては失敗するかもしれません。バグがここで起きていると思われる場合は、そのエラーが通常のシステムで再現できるか確認してください。 + +通常のシステムで再現できる場合これは Live システムではなく Debian のバグです - 失敗しているパッケージに対して報告してください。Live +システムのビルドとは別に /{debootstrap}/ を実行、あるいは #{lbbootstrap --debug}# +を実行するとさらなる情報を得られるでしょう。 + +また、ローカルミラーやプロキシの類を使っていて問題が起きている場合はまず、公式ミラーからパッケージを収集した場合に再現するか常に確認してください。 + +3~ ブート時 + +イメージがブートしない場合は{情報収集}#collect-information +で指定している情報を添えてメーリングリストに報告してください。そのイメージが正確にどのように/どの段階で失敗しているのか、仮想化を使っているのか実際のハードウェアなのか、ということについて忘れずに言及してください。何らかの仮想化技術を使っている場合はバグを報告する前に常に実際のハードウェアで実行してください。失敗しているときのスクリーンショットを提供することも、とても参考になります。 + +3~ 実行時 + +パッケージのインストールには成功したけれども Live システムを実際に実行している間に何か失敗している場合、これは恐らく Live +システムのバグです。その場合: + +2~ 調査してください + +バグを報告する前に、問題の症状やそのエラーメッセージについてウェブを検索してください。その問題に遭っているのがあなた一人だけだという可能性は非常に低いからです。他のどこかで議題に上り、解決できそうな方法やパッチ、回避策が提案されている可能性は常にあります。 + +Live +システムのメーリングリストや同様にホームページには。最新の情報がある可能性があるので、特に注意を払ってください。そういった情報が存在する場合は、バグ報告で常に参照するようにしてください。 + +さらに、似たことが既に報告されていないか live-build、live-boot、live-config、live-tools +の現在のバグ一覧を確認してください。 + +2~ バグの報告先 + +${project}ではバグ追跡システム (BTS) に報告されたバグを全て追跡しています。このシステムの使い方についての情報は +https://bugs.debian.org/ を見てください。#{reportbug}# +パッケージの同名コマンドを使ってバグを報告することもできます。 + +一般的に、ビルド時のエラーは live-build に、ブート時のエラーは live-boot に、実行時のエラーは live-config +パッケージに対して報告してください。どのパッケージが適切なのかよくわからない、あるいはバグの報告前にもっと支援が必要だという場合は +debian-live 疑似パッケージに対して報告してください。その場合は私達が調べて適切なものに割り当てし直します。 + +(Ubuntu その他の) Debian 派生ディストリビューションで見つかったバグは、それが公式の Debian パッケージを使っている Debian +システムでも再現するものでない限り、Debian BTS に報告すべきでは*{ない}*ことに注意してください。 diff --git a/markup/pod/live-manual/media/text/ja/project_coding-style.ssi b/markup/pod/live-manual/media/text/ja/project_coding-style.ssi new file mode 100644 index 0000000..cc8c41a --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/project_coding-style.ssi @@ -0,0 +1,140 @@ +:B~ コーディングスタイル + +1~coding-style コーディングスタイル + +この章では Live システムで利用されているコーディングスタイルについて述べます。 + +2~ 互換性 + +_* Bash シェル固有の書式や記号を使わないでください。例えば配列構造の利用など + +_* POSIX のサブセットだけを使ってください - 例えば `foo` よりも $(foo) を使ってください。 + +_* 'sh -n' と 'checkbashisms' によりスクリプトをチェックできます。 + +_* シェルコードが全て確実に 'set -e' で動作するようにしてください。 + +2~ インデント + +_* 常にスペースよりもタブを使います。 + +2~ 改行 + +_* 通常、行は最大で80文字までです。 + +_* 「Linux 式」で改行します: + +悪い例: + +code{ + + if foo; then + bar + fi + +}code + +良い例: + +code{ + + if foo + then + bar + fi + +}code + +_* 関数についても同様です: + +悪い例: + +code{ + + Foo () { + bar + } + +}code + +良い例: + +code{ + + Foo () + { + bar + } + +}code + +2~ 変数 + +_* 変数は常に大文字です。 + +_* live-build で利用する変数は先頭を常に #{LB_}# で始めます。 + +_* live-build 内部の一時変数は #{\_LB_}# で始めます。 + +_* live-build のローカル変数は #{\_\_LB_}# で始めます。 + +_* live-config 中のブートパラメータにつながる変数は #{LIVE_}# で始めます。 + +_* live-config 中の他の変数は全て #{_}# で始めます。 + +_* 変数は大括弧「{}」で囲みます。例えば #{$FOO}# ではなく #{${FOO}}# とします。 + +_* 空白文字の可能性を考慮し、常に引用符を使って変数を保護します: #{${FOO}}# ではなく #{"${FOO}"}# とします。 + +_* 一貫性を保つため、変数に値を割り当てるときは常に引用符を使います: + +悪い例: + +code{ + + FOO=bar + +}code + +良い例: + +code{ + + FOO="bar" + +}code + +_* 複数の変数を使うときは表現全体を引用符で囲みます: + +悪い例: + +code{ + + if [ -f "${FOO}"/foo/"${BAR}"/bar ] + then + foobar + fi + +}code + +良い例: + +code{ + + if [ -f "${FOO}/foo/${BAR}/bar" ] + then + foobar + fi + +}code + +2~ その他 + +_* sed を呼び出すときは区切り文字に「#{|}#」を使います。例えば「#{sed -e 's|foo|bar|'}#」 + +_* 比較やテストには #{test}# コマンドを使わず、「#{[}#」や「#{]}#」を使います。例えば「#{if [ -x /bin/foo ]; +...}#」を使い、「#{if test -x /bin/foo; ...}#」は使いません。 + +_* #{test}# よりも #{case}# の方が読みやすく実行速度も早いため、可能な部分ではこちらを使います。 + +_* ユーザの環境と混ざる可能性を限定するため、関数の名前には大文字を使います。 diff --git a/markup/pod/live-manual/media/text/ja/project_contributing.ssi b/markup/pod/live-manual/media/text/ja/project_contributing.ssi new file mode 100644 index 0000000..a1dcea2 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/project_contributing.ssi @@ -0,0 +1,100 @@ +:B~ プロジェクトへの貢献 + +1~contributing-to-project プロジェクトへの貢献 + +貢献物の提出にあたっては著作権者を明確に識別し、適用するライセンス文を収録してください。受け入れられるためには、その貢献物はその文書の他の部分と同一の、GPL +バージョン 3 以降というライセンスを採用する必要があることに注意してください。 + +翻訳やパッチといったプロジェクトへの貢献は大いに歓迎します。誰もがリポジトリに直接コミットできますが、大きな変更についてはまずメーリングリストに送って議論するようお願いします。さらなる情報については{連絡先}#contact +節を見てください。 + +${project}ではGitをソースコード管理用のバージョン管理システムとして利用しています。{Gitリポジトリ}#git-repositories +で説明しているように、開発用ブランチは *{debian}* と *{debian-next}* の2つあります。debian-next ブランチの +live-boot、live-build、live-config、live-images、live-manual、live-tools +リポジトリには誰でもコミットできます。 + +ただし、特定の制限があります。サーバは + +_* fast-forward ではないプッシュ + +_* マージコミット + +_* タグやブランチの追加や削除 + +を拒否します。あらゆるコミットを訂正できるとはいえ、自分の常識に従って、良いコミットメッセージを使って良いコミットを行うようお願いします。 + +_* +完結した、有意な文で構成されるコミットメッセージを英語で書き、大文字から始めて句点で終えるようにしてください。通常、「Fixing/Adding/Removing/Correcting/Translating/...」のようなものから開始します。 + +_* 良いコミットメッセージを書いてください。先頭行はそのコミットの内容を正確にまとめるようにしてください。これは changelog +に収録されることになります。何か説明がさらに必要であれば、先頭行の後に1行空けてから書き、各段落の後には新たな空行を空けてください。段落の行の長さは80文字を超えないようにしてください。 + +_* +コミットは小分けにしてください。これは関係のないものをまとめてコミットしないようにということです。各変更ごとに別個にコミットするようにしてください。 + +2~ 変更を加える + +リポジトリに送るには、以下の手順に従う必要があります。ここでは live-manual +を例として使うのでそれは作業したいリポジトリに置き換えてください。live-manual +を変更する方法に関する詳細な情報については{この文書への貢献}#how-to-contribute を見てください。 + +_* 公開コミットキーを取得します: + +code{ + + $ mkdir -p ~/.ssh/keys + $ wget http://live-systems.org/other/keys/git@live-systems.org -O ~/.ssh/keys/git@live-systems.org + $ wget http://live-systems.org/other/keys/git@live-systems.org.pub -O ~/.ssh/keys/git@live-systems.org.pub + $ chmod 0600 ~/.ssh/keys/git@live-systems.org* + +}code + +_* openssh-client の設定に以下を追記します: + +code{ + + $ cat >> ~/.ssh/config << EOF + Host live-systems.org + Hostname live-systems.org + User git + IdentitiesOnly yes + IdentityFile ~/.ssh/keys/git@live-systems.org + EOF + +}code + +_* ssh 経由で live-manual の複製を取得します: + +code{ + + $ git clone git@live-systems.org:/live-manual.git + $ cd live-manual && git checkout debian-next + +}code + +_* Gitで作者とメールをセットしたことを確認してください: + +code{ + + $ git config user.name "John Doe" + $ git config user.email john@example.org + +}code + +*{重要:}* 変更はどれも *{debian-next}* ブランチにコミットする必要があるということを忘れないでください + +_* 変更を加えます。この例ではまずパッチの適用を扱う新しい節を書き、ファイルの追加をコミットする下準備をしてコミットメッセージを + +code{ + + $ git commit -a -m "Adding a section on applying patches." + +}code + +_* のように書いてサーバにコミットを送ります: + +code{ + + $ git push + +}code diff --git a/markup/pod/live-manual/media/text/ja/project_git.ssi b/markup/pod/live-manual/media/text/ja/project_git.ssi new file mode 100644 index 0000000..91f84c6 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/project_git.ssi @@ -0,0 +1,74 @@ +:B~ Gitリポジトリ + +1~git-repositories Gitリポジトリ + +${project}の利用可能な全リポジトリ一覧は http://live-systems.org/gitweb/ にあります。プロジェクトの git +URL は: #{プロトコル://live-systems.org/git/リポジトリ}# という形式になっています。したがって、live-manual +を読み込み専用で複製するには + +code{ + + $ git clone git://live-systems.org/git/live-manual.git + +}code + + + +code{ + + $ git clone https://live-systems.org/git/live-manual.git + +}code + + + +code{ + + $ git clone http://live-systems.org/git/live-manual.git + +}code + +のどれかを実行します。書き込み権限のある複製には #{git@live-systems.org:/リポジトリ}#という形式のアドレスを使います。 + +なので、繰り返しますが live-manual をssh経由で複製するには + +code{ + + $ git clone git@live-systems.org:live-manual.git + +}code + +と入力する必要があります。gitツリーは複数の異なるブランチでできています。*{debian}* 及び *{debian-next}* +ブランチは最終的には新しいリリースそれぞれに収録される実際の作業を収録しているため特に注目すべきです。 + +既存のリポジトリのどれかを複製した後は *{debian}* +ブランチにいるでしょう。これはプロジェクトの最新リリースの状態を確認するには適切ですが、作業開始前に必ず *{debian-next}* +ブランチに切り替える必要があります。切り替えには + +code{ + + $ git checkout debian-next + +}code + +を実行します。*{debian-next}* ブランチは常に fast-forward とは限らず、あらゆる変更が *{debian}* +ブランチにマージされる前にまずはこにコミットされます。例えて言えばテストの場のようなものです。このブランチで作業していてサーバにある変更を取得する必要がある場合は +#{git pull --rebase}# +を実行する必要があります。それにより、サーバから取得するときにローカルでの変更が反映され、その変更が最上位に配置されます。 + +2~ リポジトリを複数処理 + +Live システムのリポジトリを複数複製してすぐに、最新コードの確認、パッチ作成、あるいは翻訳での貢献等のために *{debian-next}* +ブランチに切り替えたい場合、複数のリポジトリを扱いやすくするための #{mrconfig}# +ファイルをgitサーバで提供していることを紫知っておくべきでしょう。これを使うには /{mr}/ パッケージをインストールする必要があります。その後、 + +code{ + + $ mr bootstrap http://live-systems.org/other/mr/mrconfig + +}code + +を実行します。このコマンドは自動的に複製し、プロジェクトにより作成される Debian パッケージの開発用リポジトリである +*{debian-next}* ブランチを取得します。これには、中でも live-images +リポジトリがあり、プロジェクトが一般用途向けに公開しているビルド済みイメージで利用される設定を収録しています。このリポジトリの使い方に関するさらなる情報については、{Git経由で公開されている設定の複製}#clone-configuration-via-git +を見てください。 diff --git a/markup/pod/live-manual/media/text/ja/project_procedures.ssi b/markup/pod/live-manual/media/text/ja/project_procedures.ssi new file mode 100644 index 0000000..2bca00e --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/project_procedures.ssi @@ -0,0 +1,93 @@ +:B~ 手順 + +1~procedures 手順 + +この章では、Debian の他のチームと協調する必要のある、${project}の様々な作業の手順について触れます。 + +2~ 主要リリース + +Debian の安定版の新しい主要バージョンのリリースでは、その完成のために多くの異なるチームが協調して作業しています。どこかの時点で、Live +チームが参加して Live システムのイメージをビルドします。そのための要件は + +_* リリースしたバージョンに該当する debian 及び debian-security アーカイブを収録している、debian-live の +buildd からアクセスできるミラー + +_* イメージの名前は既知の形式である必要があります (例えば debian-live-バージョン-アーキテクチャ-収録デスクトップ環境等.iso)。 + +_* debian-cd から来るデータを同期する必要があります (udeb 除外一覧)。 + +_* ビルドされたイメージのミラーが cdimage.debian.org に置かれます。 + +2~ ポイントリリース + +_* ここでも、debian と debian-security の更新されたミラーが必要です。 + +_* ビルドされたイメージのミラーが cdimage.debian.org に置かれます。 + +_* 告知メールを送ります + +3~ ある Debian リリースの最後のポイントリリース + +ある Debian リリース向けの最後のイメージを ftp.debian.org から archive.debian.org +に移動した後にビルドするときには、chroot とバイナリミラーの両方を調整することを忘れないでください。そうすることで、古いビルド済み Live +イメージをユーザが変更しなくてもそのまま続けて使えるようになります。 + +3~ ポイントリリース告知用テンプレート + +ポイントリリース用の告知メールはテンプレートと以下のコマンドを使って生成できます。 + +code{ + + $ sed \ + -e 's|@MAJOR@|9.0|g' \ + -e 's|@MINOR@|9.0.1|g' \ + -e 's|@CODENAME@|stretch|g' \ + -e 's|@ANNOUNCE@|2017/msgXXXXX.html|g' + +}code + +メールを送る前に注意深く確認し、他の人による校正を受けてください。 + +code{ + +Updated Live @MAJOR@: @MINOR@ released + + The Live Systems Project is pleased to announce the @MINOR@ update of the + Live images for the stable distribution Debian @MAJOR@ (codename "@CODENAME@"). + + The images are available for download at: + + <http://live-systems.org/cdimage/release/current/> + + and later at: + + <http://cdimage.debian.org/cdimage/release/current-live/> + + This update includes the changes of the Debian @MINOR@ release: + + <https://lists.debian.org/debian-announce/@ANNOUNCE@> + + Additionally it includes the following Live-specific changes: + + * [LIVE 固有の変更をここに] + * [LIVE 固有の変更をここに] + * [大きな問題については専用の節を作ることもあります] + + About Live Systems + ------------------ + The Live Systems Project produces the tools used to build official + live systems and the official live images themselves for Debian. + + About Debian + ------------ + The Debian Project is an association of Free Software developers who + volunteer their time and effort in order to produce the completely free + operating system Debian. + + Contact Information + ------------------- + For further information, please visit the Live Systems web pages at + <http://live-systems.org/>, or contact the Live Systems team at + <debian-live@lists.debian.org>. + +}code 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 用イメージをウェブブートできます。後者のイメージに収録されている何かのツールが別のマシン等で必要になった場合は標準的なイメージをウェブブートできます。 diff --git a/markup/pod/live-manual/media/text/ja/user_customization-binary.ssi b/markup/pod/live-manual/media/text/ja/user_customization-binary.ssi new file mode 100644 index 0000000..6ab1d9a --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-binary.ssi @@ -0,0 +1,49 @@ +:B~ バイナリイメージの独自化 + +1~customizing-binary バイナリイメージの独自化 + +2~ ブートローダ + +live-build は /{syslinux}/ や (イメージの種類により) +その派生物の一部をブートローダとしてデフォルトで利用します。これは要件に合わせて簡単に独自化できます。 + +全面的なテーマを使うには #{/usr/share/live/build/bootloaders}# を #{config/bootloaders}# +にコピーしてその中のファイルを編集します。サポートしているブートローダ全部の設定変更を望まない場合は、ブートローダの1つ、例えば +#{config/bootloaders/isolinux}# にある *{isolinux}* +だけを局所的に地域化したものを提供するのでも、活用方法によりますが十分です。 + +のようになります。デフォルトのテーマを変更してブートメニューとともに表示される背景画像に個別のものを使いたい場合は 640x480 ピクセルの画像を +splash.png というファイル名で追加し、splash.svg ファイルを削除します。 + +変更を加えるに至る要因は多々あります。例えば syslinux +派生物ではデフォルトでタイムアウト時間が0に設定されていて、この場合はスプラッシュ画面でキーが押されるまでいつまでも一時停止状態で止まっているということになります。 + +デフォルトの #{iso-hybrid}# イメージのブート時のタイムアウト時間を変更する方法は、デフォルトの *{isolinux.cfg}* +ファイルを編集して1/10秒単位でタイムアウト時間を指定するだけです。5秒後にブートするように *{isolinux.cfg}* を変更する場合は + +code{ + + include menu.cfg + default vesamenu.c32 + prompt 0 + timeout 50 + +}code + +2~ ISO メタ情報 + +ISO9660 +バイナリイメージの作成時に以下のオプションを使って、テキストの様々なメタ情報をイメージに追加できます。これはイメージのバージョンや設定をブートせずに簡単に識別する手助けとなります。 + +_* #{LB_ISO_APPLICATION/--iso-application NAME}#: +これにはイメージ上に置かれる、アプリケーションの説明を記述します。最大長は128文字です。 + +_* #{LB_ISO_PREPARER/--iso-preparer NAME}#: +これはイメージの作成者を説明し、通常連絡先の詳細をいくらか含めます。このオプションのデフォルト値は作成に利用した live-build +のバージョンで、後でデバッグするときに手がかりとなることを意図しています。最大長は128文字です。 + +_* #{LB_ISO_PUBLISHER/--iso-publisher NAME}#: +これはイメージの発行者を説明し、通常連絡先の詳細をいくらか含めます。最大長は128文字です。 + +_* #{LB_ISO_VOLUME/--iso-volume NAME}#: これはイメージのボリュームIDを指定します。Windows や +Apple Mac OS 等一部のプラットフォームではユーザから見えるラベルとして利用されます。最大長は32文字です。 diff --git a/markup/pod/live-manual/media/text/ja/user_customization-contents.ssi b/markup/pod/live-manual/media/text/ja/user_customization-contents.ssi new file mode 100644 index 0000000..510323a --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-contents.ssi @@ -0,0 +1,114 @@ +:B~ 収録内容の独自化 + +1~customizing-contents 収録内容の独自化 + +この章では収録するパッケージを単に選択だけにとどまらない、微調整まで含めた Live システムの収録内容の独自化について説明します。インクルードにより +Live +システムイメージの任意のファイルを追加、置換できるようになり、フックによりビルド時及びブート時の異なる段階で任意のコマンドを実行できるようになり、preseed +が debconf の質問に対する回答を提供することでパッケージのインストール時に設定できるようになります。 + +2~includes Includes + +理想的なのは変更されていないパッケージにより提供されるファイルを Live +システムで完全に収録することではありますが、ファイルを使って内容をいくらか提供あるいは変更することが便利なこともあります。インクルードを使うと Live +システムイメージ中の任意のファイルを追加 (または置換) することができるようになります。live-build +ではこれを使う仕組みを2つ提供しています: + +_* chroot ローカルインクルード: chroot/Live +ファイルシステムに対してファイルの追加や置換ができるようになります。さらなる情報については、{Live/chroot +ローカルインクルード}#live-chroot-local-includes を見てください。 + +_* バイナリローカルインクルード: +バイナリイメージ中のファイルの追加や置換ができるようになります。さらなる情報については、{バイナリローカルインクルード}#binary-local-includes +を見てください。 + +「Live」及び「バイナリ」イメージの違いについてのさらなる情報は、{用語}#terms を見てください。 + +3~live-chroot-local-includes Live/chroot ローカルインクルード + +chroot ローカルインクルードを使って chroot/Live ファイルシステム中のファイルの追加や置換を行い、それを Live +システムで利用することができます。代表的な使い方として Live システムで利用するユーザディレクトリ (#{/etc/skel}#) +の骨格を構成させ、live +ユーザのホームディレクトリを作成するということがあります。別の使い方としては設定ファイルを提供し、そのまま加工せずイメージ中に追加または置換するということがあります。加工が必要な場合は +{Live/chroot ローカルフック}#live-chroot-local-hooks を見てください。 + +ファイルを収録するには #{config/includes.chroot}# ディレクトリに単純に追加します。このディレクトリが Live +システムのルートディレクトリ #{/}# に対応します。例えば Live システムにファイル #{/var/www/index.html}# +を追加する場合: + +code{ + + $ mkdir -p config/includes.chroot/var/www + $ cp /path/to/my/index.html config/includes.chroot/var/www + +}code + +それから設定は以下の配置になっているでしょう: + +code{ + + -- config + [...] + |-- includes.chroot + | `-- var + | `-- www + | `-- index.html + [...] + +}code + +chroot +ローカルインクルードはパッケージがインストールされた後にインストールされるので、パッケージによりインストールされたファイルは上書きされます。 + +3~binary-local-includes バイナリローカルインクルード + +文書やビデオ等の内容をメディアのファイルシステムに収録して、メディアを差し込んで Live +システムをブートしなくてもすぐにアクセスできるようにするのにバイナリローカルインクルードを使えます。これは chroot +ローカルインクルードと同様の方法で動作します。例えばファイル #{~/video_demo.*}# が Live システムの実演ビデオで、リンク先の +HTML 索引ページでそれを説明しているものと仮定しましょう。単純に内容を #{config/includes.binary/}# にコピーします: + +code{ + + $ cp ~/video_demo.* config/includes.binary/ + +}code + +これでファイルは Live メディアの最上位ディレクトリに現れます。 + +2~hooks フック + +フックではビルドの chroot 及び バイナリの段階でコマンドを実行し、イメージを独自化できます。 + +3~live-chroot-local-hooks Live/chroot ローカルフック + +chroot の段階でコマンドを実行するにはファイル名末尾が #{.hook.chroot}# でコマンドを収録するフックスクリプトを +#{config/hooks/}# ディレクトリに作成します。フックは残りの chroot 設定の適用後に chroot +内で実行されるため、フックの実行に必要なパッケージやファイルを全て確実に設定に収録することを忘れないようにしてください。代表的な chroot +の様々な独自化タスクについて #{/usr/share/doc/live-build/examples/hooks}# で提供されている chroot +フックスクリプトの例を確認してください。この例からコピーやシンボリックリンクを作成して自分の設定で使えます。 + +3~boot-time-hooks ブート時フック + +ブート時にコマンドを実行するために man ページの「独自化」節で説明されている live-config +フックを提供することができます。#{/lib/live/config/}# で提供している live-config +独自のフックを、実行順を示す頭の番号に注意して調べてください。それから自分のフックに実行順を示す適切な番号を頭に付けて、#{config/includes.chroot/lib/live/config/}# +内の chroot +ローカルインクルードか、{変更したあるいはサードパーティのパッケージのインストール}#installing-modified-or-third-party-packages +で説明している独自パッケージとして提供してください。 + +3~ バイナリローカルフック + +バイナリ段階でコマンドを実行するには、コマンドを収録するフックスクリプトを、末尾に #{.hook.binary}# を付けて +#{config/hooks/}# ディレクトリに作成します。このフックは他の binary_checksums +を除いたバイナリコマンドを全て実行した後の、バイナリコマンドのほぼ最後に実行されます。フック内のコマンドは chroot +内で実行されるのではないため、ビルドツリー外のファイルを変更することのないように注意してください。変更するとビルドシステムが機能しなくなるかもしれません! +代表的なバイナリ独自化タスクについて #{/usr/share/doc/live-build/examples/hooks}# +で提供されているバイナリフックスクリプトの例を確認してください。この例からコピーやシンボリックリンクを作成して自分の設定で使えます。 + +2~ Debconf 質問の preseed + +#{config/preseed/}# ディレクトリにある、末尾が段階 (#{.chroot}# か #{.binary}#) に続いて +#{.cfg}# で終わるファイルは debconf の preseed ファイルと見なされ、対応する段階で live-build により +#{debconf-set-selections}# を使ってインストールされます。 + +debconf のさらなる情報については、/{debconf}/ パッケージの #{debconf(7)}# を見てください。 diff --git a/markup/pod/live-manual/media/text/ja/user_customization-installer.ssi b/markup/pod/live-manual/media/text/ja/user_customization-installer.ssi new file mode 100644 index 0000000..66d8e75 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-installer.ssi @@ -0,0 +1,69 @@ +:B~ Debian インストーラの独自化 + +1~customizing-installer Debian インストーラの独自化 + +Live システムのイメージは Debian +インストーラと統合できます。インストールには収録内容やインストーラの動作方法によりいくつもの異なる種類があります。 + +この節で「Debian インストーラ」と大文字を使った表記で参照しているところに注意してください - この表記の場合には公式の Debian +システム用インストーラを明示的に指していて、他の何かではありません。「d-i」と短縮することもよくあります。 + +2~ Debian インストーラの種類 + +インストーラの主な3つの種類: + +*{「通常の」Debian インストーラ}*: これは通常の Live システムのイメージで、(適切なブートローダからそれを選択した場合に) Debian のCDイメージをダウンロードしてそれをブートしたのと同様に標準の Debian インストーラを起動するための別個のカーネルと initrd を収録しています。Live システムとこういった別個の独立したインストーラを収録するイメージはよく「複合イメージ」と呼ばれます。 + +こういったイメージでは、/{debootstrap}/ を使ってローカルメディアやネットワークから .deb パッケージを取得、インストールすることで +Debian がインストールされます。結果としてはデフォルトの Debian システムがハードディスクにインストールされます。 + +このプロセス全体で、いくつもの方法で preseed を使って独自化できます。さらなる情報については Debian +インストーラマニュアルの関連するページを見てください。機能する preseed ファイルが得られたら live-build +が自動的にイメージに取り込んで使えるようになります。 + +*{「Live」Debian インストーラ}*: これは Live システムイメージで、(適切なブートローダからそれを選択した場合に) Debian インストーラを起動するための別個のカーネルと initrd を収録しています。 + +インストールは上記で説明した「通常の」インストールと全く同じように進みますが、実際にパッケージをインストールする段階で、/{debootstrap}/ +を使ってパッケージを取得、インストールする代わりに、Live ファイルシステムのイメージを対象にコピーします。これは live-installer +という特別な udeb により行っています。 + +この段階の後は、Debian インストーラはインストールや、ブートローダやローカルユーザ等の設定を通常どおり続けます。 + +*{注意:}* 一つの Live メディアのブートローダの項目で通常のインストーラと Live インストーラの両方に対応するには、#{live-installer/enable=false}# という preseed により live-installer を無効化する必要があります。 + +*{「デスクトップ」Debian インストーラ}*: 収録する Debian インストーラの種類を問わず、デスクトップからアイコンをクリックすることで #{d-i}# を起動できます。状況によってはこちらの方がユーザからわかりやすいこともあります。これを使えるようにするには debian-installer-launcher パッケージを収録する必要があります。 + +live-build は Debian インストーラのイメージをデフォルトではイメージに収録しないことに注意してください。#{lb config}# +により具体的に有効化する必要があります。さらに、「デスクトップ」インストーラが機能するようにするには Live +システムのカーネルが指定されたアーキテクチャで #{d-i}# が利用するカーネルと一致する必要があることに注意してください。例えば: + +code{ + + $ lb config --architectures i386 --linux-flavours 586 \ + --debian-installer live + $ echo debian-installer-launcher >> config/package-lists/my.list.chroot + +}code + +2~ preseed による Debian インストーラの独自化 + +https://www.debian.org/releases/stable/i386/apb.html にある Debian +インストーラマニュアルの付録Bで説明されていますが「preseed +は、インストールの実行中に手作業により回答を入力せずに、インストールプロセス中の質問の回答を設定する方法を提供します。これにより、ほとんどの方法のインストールを完全に自動化し、さらに通常のインストールでは利用できない特徴もあります」。この種の独自化は +live-build を使って設定を #{preseed.cfg}# ファイルに書き、#{config/includes.installer/}# +に置くことで最も完成させることができます。例えばロケールを #{en_US}# に設定する preseed は: + +code{ + + $ echo "d-i debian-installer/locale string en_US" \ + >> config/includes.installer/preseed.cfg + +}code + +2~ Debian インストーラの収録内容の独自化 + +実験やデバッグの目的で、ローカルでビルドした #{d-i}# の一部である udeb +パッケージを収録したいことがあるかもしれません。#{config/packages.binary/}# +にそれを配置してイメージに収録します。{Live/chroot ローカルインクルード}#live-chroot-local-includes +と同じ方法で内容を #{config/includes.installer/}# +に置くことで、追加または置換するファイルやディレクトリを同様にインストーラの initrd に収録することもできます。 diff --git a/markup/pod/live-manual/media/text/ja/user_customization-overview.ssi b/markup/pod/live-manual/media/text/ja/user_customization-overview.ssi new file mode 100644 index 0000000..dee4093 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-overview.ssi @@ -0,0 +1,49 @@ +:B~ 収録内容の独自化 + +1~customization-overview 独自化の概要 + +この章では Live システムを独自化できる様々な方法について概要を示します。 + +2~ ビルド時とブート時の設定 + +Live +システムの設定オプションはビルド時に適用されるビルド時オプションとブート時に適用されるブート時オプションとに分けられます。ブート時オプションはさらに、live-boot +パッケージにより適用され、ブートの早い段階で起きるものと live-config +パッケージにより適用され、ブートの遅い段階で起きるものとに分けられます。ブート時オプションはどれも、ユーザがブートプロンプトで指定することで変更できます。イメージは、デフォルトのブートパラメータを指定してビルドし、デフォルト値を全て適応する場合オプションをユーザが何も指定せずに普通に +Live システムを直接ブートするようにもできます。特に、#{lb --bootappend-live}# +への引数は設定の維持やキーボードレイアウト、タイムゾーン等、Live +システムのカーネルコマンドラインオプションのデフォルト値で構成されます。例については{ロケールと言語の独自化}#customizing-locale-and-language +を見てください。 + +ビルド時設定オプションは #{lb config}# の man ページで説明されています。ブート時オプションは live-boot と +live-config の man ページで説明されています。live-boot 及び live-config パッケージはビルドする Live +システム内にインストールされますが、設定作業時に参照しやすいようにビルドシステムにもインストールすることを勧めます。収録されているスクリプトはどれも、そのシステムが +Live システムとして設定されていないと実行されないため、ビルドシステムへのインストールは安全です。 + +2~stages-of-the-build ビルド段階 + +ビルドプロセスは段階ごとに分けられ、様々な独自化がそれぞれ順に適用されます。実行の最初の段階は*{パッケージ収集}*段階です。この初期段階では +chroot ディレクトリを作成して Debian システムの骨子を構成するパッケージを集めます。引き続いて*{chroot}*段階があり、chroot +ディレクトリの構成を完了させ、他の内容とともに設定に列挙されているパッケージを全て収集します。収録内容の独自化はほとんどがこの段階で起こります。Live +イメージの準備の最終段階は*{バイナリ}*段階で、ブート可能なイメージをビルドします。chroot ディレクトリの内容を使って Live +システムのルートファイルシステムを作成し、インストーラと 対象メディアの Live +システムのファイルシステム外に配置する、他の追加の内容を全て収録します。Live イメージをビルドした後は、有効化されている場合はソースの tar +アーカイブを*{ソース}*段階で作成します。 + +各段階で、コマンドの適用には特定の順序があります。そのように配置することで、独自化を合理的に階層化できるようになります。例えば *{chroot}* +段階ではどのパッケージをインストールするよりも前に preseed +が適用され、ローカルに収録したどのファイルをコピーするよりも前にパッケージをインストールし、フックはその後に、収録内容を全て配置してから実行されます。 + +2~ ファイルによる lb config の補完 + +#{lb config}# は設定の骨格を #{config/}# ディレクトリに作成しますが、目標を実現するには #{config/}# +サブディレクトリ以下に追加のファイルを提供する必要があるかもしれません。設定のどこにファイルを置くかにより、Live +システムのファイルシステムやバイナリイメージのファイルシステムにコピーされるか、コマンドラインオプションとして渡す方法では扱いにくいビルド時のシステム設定を提供することになります。独自のパッケージ一覧やアートワーク、あるいはビルド時またはブート時に実行するフックスクリプト等を収録し、debian-live +は既にかなりの柔軟性がありますが、自身のコードでそれを後押しすることができます。 + +2~ 独自化タスク + +以下の章ではユーザがよく行う類の独自化タスクをほんの一部ですがまとめています: +{インストールするパッケージの独自化}#customizing-package-installation +{収録内容の独自化}#customizing-contents +{ロケールと言語の独自化}#customizing-locale-and-language diff --git a/markup/pod/live-manual/media/text/ja/user_customization-packages.ssi b/markup/pod/live-manual/media/text/ja/user_customization-packages.ssi new file mode 100644 index 0000000..97c9ab5 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-packages.ssi @@ -0,0 +1,510 @@ +:B~ インストールするパッケージの独自化 + +1~customizing-package-installation インストールするパッケージの独自化 + +恐らく Live システムの最も基本的な独自化はイメージに収録するパッケージの選択でしょう。この章では live-build +でのパッケージのインストールの独自化のためのビルド時の様々なオプションを見ていきます。イメージへのインストールに利用可能なパッケージに関して最も影響が大きい選択はディストリビューションとアーカイブ領域です。まともなダウンロード速度を確保するため、近いディストリビューションミラーを選択してください。backports +や experimental +あるいは独自のパッケージのある自身専用のリポジトリを追加することもできます。また、ファイルを直接パッケージとして収録することもできます。特定のデスクトップや言語のパッケージ等、多数の関連パッケージを同時にインストールするメタパッケージを含め、パッケージ一覧は定義できます。最後に、ビルドでパッケージをインストールするときに +/{apt}/ や好みにより /{aptitude}/ +を制御するオプションもいくらかあります。プロキシを使っていたり、推奨パッケージのインストールを無効にして容量を節約したい、インストールするパッケージのバージョンをAPTのピン経由で制御する必要がある、等便利だと思う場面があるかもしれません。 + +2~ パッケージソース + +3~ ディストリビューション、アーカイブ領域とモード + +ディストリビューションの選択は Live イメージへの収録に利用できるパッケージに最も影響があります。コード名を指定してください。${testing} +バージョンの live-build では ${testing} +がデフォルトになっています。現在アーカイブにある任意のディストリビューションをコード名で指定できます (詳細については{条件}#terms +参照)。#{--distribution}# +オプションはアーカイブ内のパッケージソースに影響するだけでなく、サポートしている各ディストリビューションをビルドするのに必要な動作をするよう +live-build に指示します。例えば*{unstable}*リリースであるsidに対してビルドする場合は: + +code{ + + $ lb config --distribution sid + +}code + +のように指定します。ディストリビューションアーカイブ内で、アーカイブ領域はアーカイブを大きく分類します。Debian +では#{main}#、#{contrib}#、#{non-free}# となっています。#{main}#に収録されるソフトウェアだけが Debian +ディストリビューションの一部であり、したがってそれがデフォルトとなっています。複数指定することもできます。例えば + +code{ + + $ lb config --archive-areas "main contrib non-free" + +}code + +Debian 派生物によっては #{--mode}# オプションの実験的サポートが利用できるものがあります。このオプションは Debian +または未知のシステムでビルドしている場合にのみデフォルトで #{debian}# がセットされています。サポートしている派生物のどれかで #{lb +config}# を実行した場合のデフォルト値はその派生物のイメージを作成するための値になります。#{lb config}# を例えば +#{ubuntu}# モードで実行すると Debian +向けに代えて指定された派生物のディストリビューション名やアーカイブ領域がサポートされます。このモードはその派生物に合うように live-build +の挙動も変更します。 + +*{注意:}* モードを追加したプロジェクトの設定については主にそのオプションのサポートユーザの担当です。${project}は最善の努力をもって開発サポートを提供はしますが、私たちは派生物を自ら開発あるいはサポートしているわけではないため、あくまで派生物プロジェクトからのフィードバックが基になります。 + +3~ ディストリビューションミラー + +Debian +アーカイブは世界中の巨大なネットワークミラーにまたがって複製されているため、各地域の人が最高のダウンロード速度を求めて近いミラーを選択できます。#{--mirror-*}# +オプションはそれぞれ、ビルドの様々な段階でどのディストリビューションミラーを利用するのかを決定します。{ビルド段階}#stages-of-the-build +の繰り返しになりますが*{パッケージ収集}*段階は最小限のシステムで /{debootstrap}/ により最初に chroot +を構成する段階、*{chroot}* 段階は chroot を使って Live +システムのファイルシステムをビルドする段階です。ミラーはこの各段階ごとにそれぞれのオプションで指定するため*{バイナリ}*の段階では +#{--mirror-binary}# や #{--mirror-binary-security}# +の値が採用され、早い段階で使っていたミラーは置き換えられることになります。 + +3~distribution-mirrors-build-time ビルド時に利用するディストリビューションミラー + +ビルド時に利用するディストリビューションミラーにローカルミラーを指定するには、#{--mirror-bootstrap}# と +#{--mirror-chroot-security}# を以下のように指定するだけです。 + +code{ + + $ lb config --mirror-bootstrap http://localhost/debian/ \ + --mirror-chroot-security http://localhost/debian-security/ + +}code + +#{--mirror-chroot}# で指定する chroot ミラーのデフォルト値は #{--mirror-bootstrap}# +の値になっています。 + +3~ 実行時に利用するディストリビューションミラー + +#{--mirror-binary*}# オプションはバイナリイメージ中のディストリビューションミラーの位置を決定します。このオプションは Live +システムの実行中に追加のパッケージをインストールする際に利用できます。デフォルトは #{httpredir.debian.org}# +で、利用できるミラーの中から特にユーザのIPアドレスを基にして地理的に近いミラーを選択するサービスになっています。これはその Live +システムを利用するユーザにとって最適なミラーを予測できない場合に適切な選択です。以下の例に示すように自分専用の値を指定することもできます。この設定でビルドされたイメージはその"#{ミラー}#"が到達可能なネットワークにいるユーザにとってのみ適します。 + +code{ + + $ lb config --mirror-binary http://mirror/debian/ \ + --mirror-binary-security http://mirror/debian-security/ \ + --mirror-binary-backports http://mirror/debian-backports/ + +}code + +3~additional-repositories 追加リポジトリ + +リポジトリをさらに追加して、利用できるパッケージ選択の幅を対象ディストリビューション以外にも広げられます。それにより、例えば backports や +experimental、そして独自のパッケージを利用できます。追加のリポジトリを設定するには +#{config/archives/your-repository.list.chroot}# や +#{config/archives/your-repository.list.binary}# ファイルを作成します。#{--mirror-*}# +オプションにより、イメージのビルドの *{chroot}* 段階や*{バイナリ}*段階、つまり Live +システムの実行時に利用するリポジトリを決定できます。 + +例えば #{config/archives/live.list.chroot}# により Live システムのビルド時に debian-live +スナップショットリポジトリからパッケージをインストールできます。 + +code{ + + deb http://live-systems.org/ sid-snapshots main contrib non-free + +}code + +同一の行を #{config/archives/live.list.binary}# に追加すると、Live システムの +#{/etc/apt/sources.list.d/}# ディレクトリにそのリポジトリが追加されます。 + +こういったファイルが存在すれば自動的に処理されます。 + +リポジトリの署名に利用されたGPG鍵を #{config/archives/your-repository.key.{binary,chroot}}# +ファイルに置くこともできます。 + +APTのピン止めが独自に必要な場合、APT設定行等を +#{config/archives/your-repository.pref.{binary,chroot}}# ファイルに配置すれば自動的に Live +システムの #{/etc/apt/preferences.d/}# ディレクトリに追加されます。 + +2~choosing-packages-to-install インストールするパッケージの選択 + +There are a number of ways to choose which packages live-build will install +in your image, covering a variety of different needs. You can simply name +individual packages to install in a package list. You can also use +metapackages in those lists, or select them using package control file +fields. And finally, you may place package files in your #{config/}# tree, +which is well suited to testing of new or experimental packages before they +are available from a repository. + +3~package-lists パッケージ一覧 + +パッケージ一覧はインストールするパッケージを明確にする強力な方法です。一覧の構文では条件付けをサポートし、一覧の生成や複数の設定への適合を容易にしています。ビルド時にシェルヘルパーを使って一覧にパッケージ名を差し込むこともできます。 + +*{注意:}* 存在しないパッケージが指定されたときの live-build の挙動はAPTユーティリティの選択により決定されます。さらなる詳細については {apt と aptitude の選択}#choosing-apt-or-aptitude を見てください。 + +3~using-metapackages メタパッケージの利用 + +パッケージ一覧を指示するもっとも簡単な方法は利用するディストリビューションで保守されているタスクのメタパッケージの利用です。例えば: + +code{ + + $ lb config + $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot + +}code + +#{live-build}# 2.x +でサポートされていた、一覧を事前定義する古い方法はこれで置き換えられました。一覧の事前定義とは異なり、タスクのメタパッケージは Live +システムプロジェクト特有のものではありません。タスクのメタパッケージはディストリビューション内の専門の作業グループにより保守されているため、要求したユーザに対して提供する最善のパッケージについて、各グループでの合意を反映したものとなっています。また、一覧を事前定義する置き換えられた方法よりはるかに幅広い事例にも対応できます。 + +タスクのメタパッケージには全て先頭が #{task-}# から始まるため、利用できるものを簡単に判別する方法があります +(名前が該当しても実際にはメタパッケージではないものもほんの一部とはいえありますが)。パッケージ名を前方一致で検索します: + +code{ + + $ apt-cache search --names-only ^task- + +}code + +以上に加え、他に様々な目的を持ったメタパッケージを見つけられるでしょう。#{gnome-core}# +のように他のもっと範囲の広いタスクパッケージの一部を構成するものや、#{education-*}# メタパッケージのように Debian Pure +Blend の中のある個々の専門分野に特化したものもあります。アーカイブにある全メタパッケージを列挙するには、#{debtags}# +パッケージをインストールして #{role::metapackage}# タグの付けられたパッケージを全て列挙させます: + +code{ + + $ debtags search role::metapackage + +}code + +3~ ローカルパッケージ一覧 + +列挙したものがメタパッケージであれ、個々のパッケージであれ、両方の組み合わせであれ、ローカルパッケージ一覧は全て +#{config/package-lists/}# +に保存されます。この一覧は複数利用できるため、うまい具合にこの一覧自体を組み込める設計になっています。例えばある一覧は特定のデスクトップ選択時向け、別の一覧は異なるデスクトップでも簡単に使えるような関連パッケージ群を、というようにできます。これにより、パッケージ群の異なる組み合わせを最小限の手間で試したり、あるいは異なる +Live イメージプロジェクトで一覧を共有する、といったことが可能になります。 + +このディレクトリに存在するパッケージ一覧は、処理対象とするためには後ろに #{.list}# +を付ける必要があり、さらにその一覧をどの段階の対象とするのか示すためには #{.chroot}# や #{.binary}# をその後に追加します。 + +*{注意:}* 対象とする段階の指定を追加しない場合、その一覧は両方の段階で利用されます。通常指定するのは #{.list.chroot}# で、この場合そのパッケージは Live ファイルシステムにのみインストールされ、メディア上に #{.deb}# の余計なコピーは置かれません。 + +3~ ローカルバイナリパッケージ一覧 + +バイナリ段階の一覧を作成する場合はファイルの末尾を #{.list.binary}# にして #{config/package-lists/}# +に置きます。それにより指定したパッケージは Live ファイルシステムにはインストールされず、Live メディアの #{pool/}# +以下に収録されます。Live ではないインストーラでこういった一覧を標準的に利用しているものもあります。バイナリ段階で chroot +段階と同一の一覧を利用したい場合は上述したように末尾を #{.list}# とします。 + +3~generated-package-lists 生成されたパッケージ一覧 + +一覧の構成はスクリプトで生成するのが最善の方法だということもあります。感嘆符から始まる行は全て、そのコマンドがイメージのビルド後に chroot +内で実行されることを示します。例えばパッケージ一覧に #{! grep-aptavail -n -sPackage -FPriority +standard | sort}# という行を書いておけば、#{Priority: standard}# +で利用可能なパッケージをソートした一覧を生成できます。 + +実際、パッケージの選択に #{grep-aptavail}# コマンド (#{dctrl-tools}# パッケージに収録) +はとても有用なので、#{live-build}# では便宜のため #{Packages}# +補助スクリプトを提供しています。このスクリプトは引数を#{フィールド}#と#{パターン}#の2つ取ります。一覧を作成する例: + +code{ + + $ lb config + $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot + +}code + +3~ 条件付き内部パッケージ一覧の利用 + +#{config/*}# (#{LB_}# が先頭に付くものは除く) に保存された live-build +の設定変数はどれもパッケージ一覧の条件文で利用できます。一般には #{lb config}# +オプションを大文字に、ダッシュ文字をアンダースコアに変更したものになります。しかし実際に意味があるのは、パッケージ選択に関わるもの、例えば +#{DISTRIBUTION}# や #{ARCHITECTURES}#、#{ARCHIVE_AREAS}# だけです。 + +例えば #{--architectures amd64}# が指定された場合に #{ia32-libs}# をインストールする場合: + +code{ + + #if ARCHITECTURES amd64 + ia32-libs + #endif + +}code + +任意の1つを条件の値とすることもできます。#{--architectures i386}# または #{--architectures amd64}# +のどちらかが指定された場合に /{memtest86+}/ をインストールする場合の例: + +code{ + + #if ARCHITECTURES i386 amd64 + memtest86+ + #endif + +}code + +値を複数指定できる変数を条件にすることもできます。#{--archive-areas}# で #{contrib}# または #{non-free}# +のどちらかが指定されている場合に /{vrms}/ をインストールする場合の例: + +code{ + + #if ARCHIVE_AREAS contrib non-free + vrms + #endif + +}code + +入り組んだ条件分岐はサポートしていません。 + +% FIXME: + +3~ インストール時のパッケージの削除 + +#{config/package-lists}# ディレクトリの末尾が #{.list.chroot_live}# や +#{.list.chroot_install}# のファイルにパッケージを列挙できます。Live +用とインストール用の両方の一覧が存在する場合、#{.list.chroot_live}# に列挙されているパッケージは +(ユーザがインストーラを利用している場合) インストール後にフックにより削除されます。#{.list.chroot_install}# +に列挙されているパッケージは Live システムとインストールされたシステムの両方に存在することになります。これはインストーラ向けの特別な調整で、設定で +#{--debian-installer live}# をセットしている場合や Live +システム特有のパッケージをインストール時には削除したい場合に有用かもしれません。 + +3~desktop-and-language-tasks デスクトップ及び言語タスク + +デスクトップと言語のタスクは特別で、計画性や設定が追加で必要となります。Live イメージが Debian +インストーライメージとは異なる点です。Debian +インストーラでは、特定のデスクトップ環境向けに用意されたメディアでは対応するタスクは自動的にインストールされます。内部に +#{gnome-desktop}# や #{kde-desktop}#、#{lxde-desktop}#、#{xfce-desktop}# +タスクがあり、#{tasksel}# +のメニューにはどれも出てきません。同様に言語向けタスクのメニュー項目はありませんが、インストール中にユーザが選択した言語が対応する言語タスクの選択に影響します。 + +デスクトップ向け Live イメージ開発時には、イメージは通常動作するデスクトップを直接ブートし、デスクトップやデフォルト言語はどちらも Debian +インストーラの場合のように実行時に選択するのではなくビルド時に決められています。これは Live +イメージでデスクトップや言語を複数サポートしてユーザに選択の機会を与えるようにできないわけではなく、それが live-build +のデフォルトの挙動ではないというだけです。 + +言語特有のフォントや入力メソッドにどのパッケージを収録するのか、といった規定は言語タスクにはないので、特定のパッケージを収録したい場合は設定で指定する必要があります。ドイツ語サポートを収録した +GNOME デスクトップイメージの場合に収録するタスクのメタパッケージの例: + +code{ + + $ lb config + $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot + $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot + +}code + +3~kernel-flavour-and-version カーネルのフレーバー (種類) とバージョン + +アーキテクチャによっては、イメージに複数のカーネルをデフォルトで収録することができます。フレーバーは #{--linux-flavours}# +オプションで選択できます。各フレーバーはデフォルトの短い #{linux-image}# +に、イメージに収録される実際のカーネルパッケージに依存する各メタパッケージの名前を付加した形式になります。 + +そうして、デフォルトで #{amd64}# アーキテクチャのイメージは #{linux-image-amd64}# +のメタパッケージを収録し、#{i386}# アーキテクチャのイメージは #{linux-image-586}# メタパッケージを収録します。 + +設定したアーカイブで複数バージョンのカーネルパッケージが利用できる場合、#{--linux-packages}# +オプションでカーネルパッケージ名の前半部を指定できます。例えば #{amd64}# アーキテクチャのイメージをビルドする際にテスト用に +experimental アーカイブを追加すると #{linux-image-3.18.0-trunk-amd64}# +カーネルをインストールできます。そのイメージの設定例: + +code{ + + $ lb config --linux-packages linux-image-3.18.0-trunk + $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot + +}code + +3~custom-kernels 独自のカーネル + +Debian パッケージ管理システムに組み入れられていれば、独自のカーネルを自分でビルド、収録できます。live-build システムは +#{.deb}# パッケージでビルドされていないカーネルはサポートしていません。 + +自身のカーネルパッケージを配置するための適切で推奨する方法は #{kernel-handbook}# +の指示に従うことです。パッケージ名のABIとフレーバーの部分を忘れずに適切に変更し、リポジトリに #{linux}# の完全なビルドとそれに該当する +#{linux-latest}# パッケージを収録してください。 + +該当するメタパッケージ無しでカーネルパッケージをビルドしたい場合は、{カーネルのフレーバー (種類) +とバージョン}#kernel-flavour-and-version で説明しているように #{--linux-packages}# +でパッケージ名の適切な前半部を指定する必要があります。{変更したあるいはサードパーティ製パッケージのインストール}#installing-modified-or-third-party-packages +で説明しているように、自身のリポジトリに独自のカーネルパッケージを収録する場合はそのようにするのが最善ですが、別の方法についても説明しています。 + +カーネルを独自化する方法はこの文書の対象範囲ではありません。とはいえ、設定が最低限満たさないといけない要件があります: + +_* 初期RAMディスクを利用する。 + +_* 結合ファイルシステムモジュール (つまり通常は #{aufs}#) を収録する。 + +_* 自分の設定で必要とする他のファイルシステムモジュール (つまり通常は #{squashfs}#) があればそれを収録する。 + +2~installing-modified-or-third-party-packages 変更したあるいはサードパーティ製パッケージのインストール + +Live システムの哲学には反しますが、Debian リポジトリにあるバージョンのパッケージを改変して Live +システムをビルドする必要に迫られることもあります。それは機能や言語、商標を変更あるいは追加するものであったり、既存のパッケージから望ましくない要素を削除するものであるかもしれません。同様に求める機能や独自開発の機能を追加するのに「サードパーティ製」パッケージを利用できます。 + +この節では変更したパッケージのビルドや保守については対象としていません。Joachim Breitner さんの +http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html +にある「How to fork privately」に書かれている方法が該当するのかもしれませんが。求める機能を収録したパッケージの作成については +https://www.debian.org/doc/maint-guide/ にある Debian 新メンテナーガイドその他で説明されています。 + +変更した独自のパッケージをインストールする方法は2つあります: + +_* #{packages.chroot}# + +_* 独自APTリポジトリの利用 + +#{packages.chroot}# +を使う方法はより簡単に出来て「一度限りの」独自化には有用ですが欠点がいくつかあります。一方独自のAPTリポジトリを使う方法はその準備に時間がかかりまます。 + +3~ #{packages.chroot}# を利用した独自のパッケージのインストール + +独自化したパッケージをインストールするには、単に#{config/packages.chroot/}# +ディレクトリにコピーします。このディレクトリ内に置かれたパッケージはビルドの際に Live システムに自動的にインストールされます - +他のどこかを指定する必要はありません。 + +パッケージ名は規定の命名規則に従わ*{ないといけません}*。それを簡単に行う方法は #{dpkg-name}# の利用です。 + +#{packages.chroot}# を利用した独自のパッケージのインストールには欠点があります: + +_* secure APT を利用することができません。 + +_* #{config/packages.chroot/}# ディレクトリに適切なパッケージを全てインストールしないといけません。 + +_* Live システムの設定をリビジョン管理するには適しません。 + +3~ APTリポジトリを利用した独自パッケージのインストール + +#{packages.chroot}# +を使う場合とは異なり、独自のAPTリポジトリを使う場合は他のどこかでパッケージを指定する必要があります。詳細については{インストールするパッケージの選択}#choosing-packages-to-install +を見てください。 + +独自のパッケージをインストールするためにAPTリポジトリを作成するのは不要な手間だと思うかもしれませんが、その基盤は変更したパッケージを後で更新する際に簡単に再利用できます。 + +3~ 独自パッケージとAPT + +live-build は Live +システムへのパッケージのインストールに全てAPTを利用するため、そのプログラムの挙動を引き継ぎます。関連する一例としては +(デフォルト設定だと仮定して)、異なる2つのリポジトリでバージョン番号の異なるあるパッケージが利用可能な場合に、APTはバージョン番号の大きい方のパッケージをインストールに選択します。 + +そのため、独自パッケージの #{debian/changeLog}# ファイルでバージョン番号を増加させ、公式の Debian +リポジトリにあるものよりも変更したバージョンが確実にインストールされるようにすると良いでしょう。Live +システムのAPTのピン設定を改変する方法もあります - さらなる情報については、{APTのピン止め}#apt-pinning を見てください。 + +2~ ビルド時のAPT設定 + +ビルド時だけに適用されるオプションを使ってAPTを設定できます (実行中の Live システムで利用されるAPTの設定は Live +システムの内容による通常の、#{config/includes.chroot/}# で適切な設定を収録する) +方法により設定できます。オプションの全容については #{lb_config}# man ページの #{apt}# で始まるオプションを見てください。 + +3~choosing-apt-or-aptitude apt と aptitude の選択 + +ビルド時にパッケージをインストールする際に /{apt}/ と /{aptitude}/ のどちらを利用するのか選択できます。利用するユーティリティは +#{lb config}# の #{--apt}# +引数で決定します。パッケージが欠けている場合の処理方法に顕著な違いがあることに着目し、パッケージのインストール時に望ましい挙動を実装している方を選択してください。 + +_* #{apt}#: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは失敗します。これはデフォルトの設定です。 + +_* #{aptitude}#: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは成功します。 + +3~ APTでのプロキシの利用 + +よく要求されるAPTの設定として、プロキシの内側でのイメージのビルドへの対応があります。必要に応じて、#{--apt-ftp-proxy}# や +#{--apt-http-proxy}# オプションによりAPTプロキシを指定できます。例: + +code{ + + $ lb config --apt-http-proxy http://proxy/ + +}code + +3~tweaking-apt-to-save-space APTの調整による容量節約 + +イメージのメディアの容量をいくらか節約する必要があるかもしれません。その場合は以下に挙げるオプションを利用するといいかもしれません。 + +APTの索引をイメージに収録したくない場合は除外できます: + +code{ + + $ lb config --apt-indices false + +}code + +これは #{/etc/apt/sources.list}# 内の項目には影響せず、単に #{/var/lib/apt}# +に索引ファイルを収録するかどうかだけに影響します。その代わりに、Live システムでAPTを操作するためにはこの索引が必要なので、#{apt-cache +search}# や #{apt-get install}# を実行する前にユーザは例えば #{apt-get update}# +をまず実行して索引を作成しないといけません。 + +推奨パッケージのインストールによりイメージが肥大化しているような場合、以下で説明している影響を踏まえた上でAPTのデフォルトオプションを無効にできます: + +code{ + + $ lb config --apt-recommends false + +}code + +推奨パッケージを無効にした場合の最も重要な影響は、#{live-boot}# や #{live-config}# 自体が、ほとんどの Live +設定に利用している重要な機能を提供する一部のパッケージを推奨していることによるもので、例えば #{live-config}# が推奨し、Live +ユーザの作成に利用している #{user-setup}# +があります。ほぼ例外なく、パッケージ一覧に追加しないといけないパッケージが推奨パッケージの中にいくらかあります。追加しない場合は、イメージが期待通りに動作しないということになります。ビルドに収録されている各 +#{live-*}# パッケージの推奨パッケージを確認し、省略できると確信できない場合はパッケージ一覧に当該パッケージを追加するようにしてください。 + +あるパッケージの推奨パッケージをインストールしないことによるもっと一般的な影響は「異常なインストール状態でなければあるパッケージとともにあるはずの」(Debian +ポリシーマニュアル7.2節) Live +システムのユーザが実際に必要とする一部のパッケージが省略されているかもしれないということです。したがって、推奨パッケージのインストールを無効にした場合とのパッケージ一覧 +(#{lb build}# により生成される #{binary.packages}# ファイル参照) +の違いを確認して、欠けているパッケージの中にインストールしたいものがあれば一覧に収録することを推奨しています。推奨パッケージからほんの一部を除外したい場合は、推奨パッケージのインストールは有効なままにしておき、{APTのピン止め}#apt-pinning +で説明しているようにAPTのピン機能で、選択したパッケージについて負の優先度をセットしてインストールされないようにする方法があります。 + +3~ apt や aptitude へのオプションの受け渡し + +障害となるAPTの挙動を変更するための #{lb config}# オプションがない場合、#{--apt-options}# や +#{--aptitude-options}# により任意のオプションを選択したAPTツールに渡せます。詳細については #{apt}# や +#{aptitude}# の man +ページを見てください。どちらのオプションにも、優先設定に加えて保持しておく必要のあるデフォルト値があることに注意してください。そのため、例えば +#{snapshot.debian.org}# からテスト用に何か取得する場合に +#{Acquire::Check-Valid-Until=false}# を指定するとAPTは古いままの #{Release}# +ファイルを使い続けます。以下の例のように、デフォルト値 #{--yes}# の後に新しいオプションを付加します: + +code{ + + $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false" + +}code + +このオプションを利用する場合は man +ページを確認して完全に理解するようにしてください。これはあくまで例であり、イメージをこの方法で設定するようにという助言だと解釈することのないようにしてください。このオプションは例えば +Live イメージの最終的なリリースには適しません。 + +#{apt.conf}# のオプションを利用するようなもっと複雑なAPT設定には代わりに #{config/apt/apt.conf}# +ファイルを作成すると良いでしょう。少数ですが、よく必要とされるオプションへの有用なショートカットがあります。他の #{apt-*}# +オプションについても参照してください。 + +3~apt-pinning APTのピン止め + +背景として、#{apt_preferences(5)}# man +ページをまず読んでください。APTのピン機能はビルド時用と実行時用に設定できます。前者については +#{config/archives/*.pref}#、#{config/archives/*.pref.chroot}#、#{config/apt/preferences}# +を、後者については #{config/includes.chroot/etc/apt/preferences}# を作成してください。 + +${testing} の Live システムをビルドするとしましょう。その場合に必要な Live パッケージは全て、ビルド時にバイナリイメージを sid +からインストールする必要があります。APTソースに sid を追加して、ピン機能で sid の Live +パッケージには高い優先度をセットし、他のパッケージには全てデフォルトよりも低い優先度をセットする必要があります。そうするとビルド時に望むパッケージだけを +sid からインストールし、他は全て対象システムのディストリビューションである ${testing} から取得します。以下によりその動作になります: + +code{ + + $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot + $ cat >> config/archives/sid.pref.chroot << EOF + Package: live-* + Pin: release n=sid + Pin-Priority: 600 + + Package: * + Pin: release n=sid + Pin-Priority: 1 + EOF + +}code + +別のパッケージにより推奨されたパッケージを望まない場合に、ピン機能で優先度に負の値をセットすることによりそのパッケージをインストールしないようにできます。#{config/package-lists/desktop.list.chroot}# +で #{task-lxde-desktop}# を使って LXDE イメージをビルドしていて、wifi +パスワードをキーリングに保存するかユーザに聞かないようにしたいと仮定しましょう。このメタパッケージは /{lxde-core}/ +に依存し、/{lxde-core}/ は /{gksu}/ を推奨し、/{gksu}/ は /{gnome-keyring}/ +を推奨しています。そこで、推奨された /{gnome-keyring}/ +パッケージを除外したい場合、#{config/apt/preferences}# に以下を追加することで除外できます: + +code{ + + Package: gnome-keyring + Pin: version * + Pin-Priority: -1 + +}code diff --git a/markup/pod/live-manual/media/text/ja/user_customization-runtime.ssi b/markup/pod/live-manual/media/text/ja/user_customization-runtime.ssi new file mode 100644 index 0000000..43364f9 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_customization-runtime.ssi @@ -0,0 +1,368 @@ +:B~ 実行時の挙動の独自化 + +1~customizing-run-time-behaviours 実行時の挙動の独自化 + +実行時に行われる設定は全て live-config により行われます。ユーザが関心を持つであろう live-config +の最も一般的なオプションから一部を説明します。オプションの全容は live-config の man ページにあります。 + +2~ live ユーザの独自化 + +重要な検討事項が1つあり、live ユーザはブート時に live-boot により作成され、ビルド時に live-build +により作成されるのではないということです。この影響は {Live/chroot +ローカルインクルード}#live-chroot-local-includes で説明しているように、ビルドで live +ユーザに関連する内容が導入されるところだけにはとどまらず、live ユーザに関連するグループや権限にも影響します。 + +live-config を設定できる複数の方法で live ユーザの所属する追加のグループを指定できます。例えば live ユーザを #{fuse}# +グループに追加するには #{config/includes.chroot/etc/live/config/user-setup.conf}# ファイルに + +code{ + + LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse" + +}code + +を追加するかブートパラメータとして +#{live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse}# +と指定します。 + +デフォルトのユーザ名「user」やデフォルトのパスワード「live」を変更することもできます。何らかの理由で変更したい場合は以下のようにして簡単に変更できます: + +デフォルトのユーザ名を変更するには単に設定で指定します: + +code{ + + $ lb config --bootappend-live "boot=live components username=live-user" + +}code + +デフォルトのパスワードを変更できる1つの方法は{ブート時フック}#boot-time-hooks で説明しているフックを使います。そのためには +#{/usr/share/doc/live-config/examples/hooks}# から「passwd」を使い、適当な名前 (例えば +2000-passwd) で保存してそれを #{config/includes.chroot/lib/live/config/}# に追加します。 + +2~customizing-locale-and-language ロケールと言語の独自化 + +Live システムがブートする際、2つの段階で言語が関わってきます: + +_* ロケール生成 + +_* キーボードの設定 + +Live システムをビルドする際のデフォルトのロケールは #{locales=en_US.UTF-8}# となっています。生成したいロケールの定義には +#{lb config}# の #{--bootappend-live}# オプションで #{locales}# パラメータを指定します。例えば + +code{ + + $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8" + +}code + +ロケールをコンマで区切って複数指定することもできます。 + +このパラメータも以下に示すキーボード設定用パラメータと同様にカーネルコマンドラインで指定できます。ロケールは #{言語_国}# +(デフォルトのエンコーディングを使う場合) または完全な #{言語_国.エンコーディング}# +の形式で指定できます。サポートしているロケールやそれぞれで利用されるエンコーディングの一覧は #{/usr/share/i18n/SUPPORTED}# +にあります。 + +コンソールとXキーボードの設定はどちらも #{live-config}# により #{console-setup}# +パッケージを使って行われます。設定には #{--bootappend-live}# オプション経由で +#{keyboard-layouts}#、#{keyboard-variants}#、#{keyboard-options}#、#{keyboard-model}# +ブートパラメータを利用します。それぞれの有効なオプションは #{/usr/share/X11/xkb/rules/base.lst}# +にあります。ある言語向けのレイアウトや配列を見つけるには、その言語の英語名やその言語が話されている国を検索してみてください。例: + +code{ + +$ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst + ! model + ! layout + ch German (Switzerland) + ! variant + legacy ch: German (Switzerland, legacy) + de_nodeadkeys ch: German (Switzerland, eliminate dead keys) + de_sundeadkeys ch: German (Switzerland, Sun dead keys) + de_mac ch: German (Switzerland, Macintosh) + ! option + +}code + +それぞれの配列の説明に、適合するレイアウトが示されていることに注意してください。 + +レイアウトだけを設定する必要があることはよくあります。例えばXで利用するドイツ語のロケールファイル及びスイスのドイツ語のキーボードレイアウトを利用する場合: + +code{ + + $ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch" + +}code + +非常に具体的な事例ですが他のパラメータを同時に指定することもできます。例えばフランス語のシステムを用意して TypeMatrix EZ-Reach +2030 USB キーボードで (Bepo と呼ばれる) フランス語用の Dvorak 配置を使う場合: + +code{ + + $ lb config --bootappend-live \ + "boot=live components locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb" + +}code + +値を1つだけ受け付ける #{keyboard-model}# は例外ですが、他の #{keyboard-*}# +オプションではそれぞれに値をコンマで区切って複数指定することもできます。#{XKBMODEL}# や +#{XKBLAYOUT}#、#{XKBVARIANT}#、#{XKBOPTIONS}# 変数の詳細や例については #{keyboard(5)}# man +ページを見てください。#{keyboard-variants}# に複数の値を指定した場合、1つずつ #{keyboard-layouts}# の値 +(#{setxkbmap(1)}# の #{-variant}# オプション参照) +との照合が行われます。空白の値も使えます。例えばデフォルトとして米国向けの QWERTY、それとは別に米国向けの +Dvorak、の2つの配列を指定する場合: + +code{ + + $ lb config --bootappend-live \ + "boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak" + +}code + +2~persistence 保持機能 + +典型的なライブCDというものは CD-ROM +等の読み取り専用メディアから起動するインストール済みシステムで、書き込みや変更は起動したホストハードウェアの再起動により消え去ります。 + +Live +システムはそれを一般化したものであり、CD以外のメディアもサポートしますが、デフォルトの挙動としては読み取り専用であり、そのシステムで実行時に行ったことは全てシャットダウンにより失われるものだと考えるべきです。 + +「保持機能」というのは、実行時にシステムに行ったことの一部あるいは全てを保存し、リブート後に引き継ぐための様々な策の共通の呼び名です。それが機能する仕組みを理解するためには、読み取り専用メディアからブート、実行している場合でもファイルやディレクトリへの変更が書き込み可能メディア、標準的にはRAMディスク +(tmpfs) に書かれ、RAMディスクのデータはリブート後には残らないのだ、ということを知っておくと良いでしょう。 + +このRAMディスクに保存されるデータは、ローカルストレージメディアやネットワーク共有、あるいはマルチセッションで (再)書き込み可能な CD/DVD +のセッション等の書き込み可能な保持用メディアに保存する必要があります。こういったメディアは Live +システムで様々な方法でサポートされています。また、特別なブートパラメータ #{persistence}# +をブート時に指定する必要があるということも重要です。 + +ブートパラメータ #{persistence}# がセットされている (と同時に #{nopersistence}# がセットされていない) +場合、保持用ボリューム用のローカルストレージメディア (例えばハードディスクやUSBドライブ) がブート中に調査されます。live-boot(7) +man +ページで説明している特定のブートパラメータを指定することにより、利用する保持用ボリュームの種類を制限できます。保持用ボリュームは以下のどれかになります: + +_* GPT名により識別されるパーティション + +_* ファイルシステムラベルにより識別されるファイルシステム + +_* 読み取り可能な任意のファイルシステム (異質のOSの NTFS パーティションも利用可) +の最上位に置かれている、ファイル名により識別されるイメージファイル + +オーバーレイ用のボリュームラベルは #{persistence}# でないといけません。さらにその最上位に、ボリュームの保持を完全に制御するのに利用する +#{persistence.conf}# +というファイルが置かれていない限り無視されます。これは言うに及ばず、リブート後に保持用ボリュームに保存する対象となるディレクトリを指定します。さらなる詳細については +{persistence.conf ファイル}#persistence-conf を見てください。 + +保持用に利用するボリュームを用意する方法についていくつか例を示します。これは例えばハードディスクやUSBメモリに例えば + +code{ + + # mkfs.ext4 -L persistence /dev/sdb1 + +}code + +により作成した ext4 パーティションを利用できます。{USBメモリの空きスペースの利用}#using-usb-extra-space +も見てください。 + +デバイスに既存のパーティションがある場合は以下に示すどれかによりラベルを変更するだけで準備は終わりです: + +code{ + + # tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems + +}code + +保持用に利用する ext4 ベースのイメージファイルの作成例: + +code{ + + $ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file + $ /sbin/mkfs.ext4 -F persistence + +}code + +イメージファイル作成後、例えば #{/usr}# を保持させる場合に、保存するのはディレクトリに対する変更だけで、#{/usr}# +の内容を丸ごと保存したいわけではない、という場合、「union」オプションを利用できます。イメージファイルがホームディレクトリに置かれている場合はハードドライブのファイルシステム最上位にコピーして +#{/mnt}# にマウントします: + +code{ + + # cp persistence / + # mount -t ext4 /persistence /mnt + +}code + +それから、内容を追加する #{persistence.conf}# ファイルを作成してイメージファイルのマウントを解除します。 + +code{ + + # echo "/usr union" >> /mnt/persistence.conf + # umount /mnt + +}code + +ブートパラメータ「persistence」を指定して Live メディアでリブートします。 + +3~persistence-conf persistence.conf ファイル + +#{persistence}# のラベルを付けられたボリュームは #{persistence.conf}# +ファイルを使って、任意のディレクトリを保持するように設定します。ボリュームのファイルシステム最上位に置かれているこのファイルは保持するディレクトリや方法を制御します。 + +独自のオーバーレイマウントの設定方法は persistence.conf(5) man +ページで詳細に説明されていますが、ほとんどの場合簡単な例で十分なはずです。/dev/sdb1 パーティションの ext4 +ファイルシステムにホームディレクトリとAPTキャッシュを保持させる場合: + +code{ + + # mkfs.ext4 -L persistence /dev/sdb1 + # mount -t ext4 /dev/sdb1 /mnt + # echo "/home" >> /mnt/persistence.conf + # echo "/var/cache/apt" >> /mnt/persistence.conf + # umount /mnt + +}code + +それからリブートします。最初のブート中に #{/home}# と #{/var/cache/apt}# +の内容が保持用ボリュームにコピーされ、以後のこのディレクトリへの変更は全て保持用ボリュームに残ります。#{persistence.conf}# +ファイルに列挙するパスには空白文字や特別なパス構成要素 #{.}# and #{..}# +を含めることは一切できないことに注意してください。また、#{/lib}# や #{/lib/live}# (はそのサブディレクトリを含めて)、#{/}# +は独自マウントを使って保持させることができません。この制約の回避策として、#{persistence.conf}# ファイルに #{/ union}# +を追加すると完全な保持を実現できます。 + +3~ 保持先を複数使いたい場合 + +複数の保存先を使う方法は複数あります。目的の明確な例として、複数のボリュームを同時に使う場合と1つだけを選択して使う場合を取り上げます。 + +異なる (個別の #{persistence.conf}# ファイルを利用する) +独自オーバーレイボリュームを複数同時に利用できますが、同一のディレクトリを保持させる設定のボリュームが複数ある場合はその中から1つだけが利用されます。ある2つのマウントが「入り組んでいる」(つまり他にマウントしたディレクトリ以下のサブディレクトリとしてマウントする) +ような場合には子孫側ディレクトリよりも前に親側ディレクトリがマウントされるため、他のマウントにより見えなくなるマウントは発生しません。入り組んでいる独自マウントが同一の +#{persistence.conf}# ファイルで指定されている場合は問題があります。そういった状況が実際に必要な場合の処理方法については +persistence.conf(5) man ページを見てください (ヒント: 通常は必要ありません)。 + +ありそうな事例: ユーザデータ、つまり #{/home}# とスーパーユーザのデータ、つまり #{/root}# を異なるパーティションに保存するため +#{persistence}# ラベルの付いたパーティションを2つ作成し、それぞれに #{persistence.conf}# +ファイルを1つはユーザのファイルを保存する最初のパーティション向けに #{# echo "/home" > +persistence.conf}#、もう1つはスーパーユーザのファイルを保存する2つ目のパーティション向けに #{# echo "/root" > +persistence.conf}# として作成します。最後に、ブートパラメータとして #{persistence}# を使います。 + +別の位置やテストのために例えば #{private}# と #{work}# のようにして同一の種類で複数の保持先が必要な場合、ブートパラメータ +#{persistence}# と合わせてブートパラメータ #{persistence-label}# +を使うと、複数でそれぞれ一意となる保持用メディアを使えるようになります。例として、ブラウザのブックマークその他の個人用データ用に #{private}# +のラベルを付けられた保持用パーティションを使いたい場合、ブートパラメータとして #{persistence}# +#{persistence-label=private}# を使います。そして文書や研究プロジェクトその他の仕事関係のデータ用にはブートパラメータとして +#{persistence}# #{persistence-label=work}# を使います。 + +各ボリューム #{private}# 及び #{work}# にはそれぞれ最上位に #{persistence.conf}# +ファイルが必要だということは重要ですので覚えておいてください。古い名前でこういったラベルを使う方法についてさらなる情報が live-boot man +ページにあります。 + +3~ 暗号化した保持先の利用 + +保持機能を使うことには重要なデータが漏洩する危険がいくらか存在します。特に保持するデータがUSBメモリや外付ハードドライブ等のポータブル機器に保存される場合は。そういった場合には暗号化が便利です。手順が多いために全体として複雑に見えるかもしれませんが、live-boot +で暗号化したパーティションを扱うのは実際には簡単です。サポートしている *{luks}* +という種類の暗号化を利用するためには、暗号化したパーティションを作成する側と暗号化した保持用パーティションを利用する Live システムの両方のマシンに +/{cryptsetup}/ をインストールする必要があります。 + +マシンへの /{cryptsetup}/ のインストール: + +code{ + + # apt-get install cryptsetup + +}code + +Live システムに /{cryptsetup}/ をインストールするには、パッケージ一覧に追加します: + +code{ + + $ lb config + $ echo "cryptsetup" > config/package-lists/encryption.list.chroot + +}code + +/{cryptsetup}/ を備えた Live +システムが出来たら、基本的に必要なのは新しいパーティションを作成して暗号化し、#{persistence}# と +#{persistence-encryption=luks}# +パラメータを指定してブートするだけです。既にこの段階を予測し、通常の手順に沿ったブートパラメータを追加してあります: + +code{ + + $ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks" + +}code + +暗号化についてよく理解していない人たちのために詳細を見て行きましょう。以下の例では #{/dev/sdc2}# +に対応するUSBメモリ上のパーティションを利用します。自分で使う際にはどのパーティションになるのか判断する必要があることに注意してください。 + +最初の段階はUSBメモリを接続してそれがどのデバイスになるのか判断することです。live-manual で推奨するデバイス一覧方法では #{ls -l +/dev/disk/by-id}# を使います。それから新しいパーティションを作成、さらにパスフレーズを使って暗号化します: + +code{ + + # cryptsetup --verify-passphrase luksFormat /dev/sdc2 + +}code + +仮想デバイスマッパーから luks パーティションを開きます。好きな名前を使ってください。ここでは例として *{live}* を使います: + +code{ + + # cryptsetup luksOpen /dev/sdc2 live + +}code + +次の段階はファイルシステムを作成する前にデバイスをゼロで埋めることです: + +code{ + + # dd if=/dev/zero of=/dev/mapper/live + +}code + +これでファイルシステムを作成する準備ができました。ラベル #{persistence}# +の指定を追加しているためこのデバイスはブート時に保持用としてマウントされるということに注意してください。 + +code{ + + # mkfs.ext4 -L persistence /dev/mapper/live + +}code + +準備を続けるにはデバイスをマウントする必要があります。例として #{/mnt}# にマウントします。 + +code{ + + # mount /dev/mapper/live /mnt + +}code + +そしてパーティション最上位に #{persistence.conf}# +ファイルを作成します。これは前に説明したように必ず必要です。{persistence.conf ファイル}#persistence-conf +を見てください。 + +code{ + + # echo "/ union" > /mnt/persistence.conf + +}code + +それからマウントポイントのマウントを解除します: + +code{ + + # umount /mnt + +}code + +オプションですがパーティションに追加したばかりのデータを安全にしておくと良いでしょう。デバイスを閉じます: + +code{ + + # cryptsetup luksClose live + +}code + +手順をまとめます。これまでに、暗号化を有効化した Live システムを作成しました。これは {ISO hybrid +イメージのUSBメモリへのコピー}#copying-iso-hybrid-to-usb +で説明しているようにUSBメモリにコピーできます。暗号化したパーティションも作成しました。これは同一のUSBメモリに置いて持ち運べます。保持先として利用する暗号化パーティションを設定しました。あと必要なのは +Live システムをブートするだけです。ブート時に live-boot +は保持用として利用する暗号化したパーティションのパスフレーズを質問し、マウントします。 diff --git a/markup/pod/live-manual/media/text/ja/user_installation.ssi b/markup/pod/live-manual/media/text/ja/user_installation.ssi new file mode 100644 index 0000000..28b8c94 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_installation.ssi @@ -0,0 +1,159 @@ +:B~ インストール + +1~installation インストール + +2~requirements 要件 + +Live システムイメージのビルドにはわずかながらシステム要件があります: + +_* スーパーユーザ (root) 権限 + +_* 最新版の live-build + +_* /{bash}/ や /{dash}/ 等の POSIX に準拠したシェル + +_* /{debootstrap}/ + +_* Linux 2.6 以降。 + +Debian や Debian 派生ディストリビューションの利用は必須ではないことに注意してください - live-build +は上記の要件を満たすほぼありとあらゆるディストリビューションで動作します。 + +2~installing-live-build live-build のインストール + +live-build のインストールにはいくつか方法があります: + +_* Debian リポジトリから + +_* ソースから + +_* スナップショットから + +Debian を使っている場合に推奨するのは Debian リポジトリからの live-build のインストールです。 + +3~ Debian リポジトリから + +他のあらゆるパッケージと同様に、単に live-build をインストールします: + +code{ + + # apt-get install live-build + +}code + +3~ ソースから + +live-build はGitバージョン管理システムを使って開発されています。Debian ベースのシステムでは /{git}/ +パッケージで提供されています。最新のコードを取得するには + +code{ + + $ git clone git://live-systems.org/git/live-build.git + +}code + +を実行します。Debian パッケージを自分でビルド、インストールすることもできます。 + +code{ + + $ cd live-build + $ dpkg-buildpackage -b -uc -us + $ cd .. + +}code + +を実行し、新しくできた #{.deb}# ファイルから対象のものをインストールします。例えば + +code{ + + # dpkg -i live-build_4.0-1_all.deb + +}code + +システムに live-build を直接インストールすることもできます: + +code{ + + # make install + +}code + +アンインストールは: + +code{ + + # make uninstall + +}code + +3~ 「スナップショット」から + +live-build をソースからビルドあるいはインストールしたくない場合、スナップショットを利用できます。スナップショットは Git +の最新版から自動的にビルドされ、http://live-systems.org/debian/ から利用できるようになっています。 + +2~ live-boot と live-config のインストール + +*{注意:}* 独自の Live システムを作成するためにシステムに live-boot や live-config をインストールする必要はありません。インストールは無害で、参照目的で有用でもあります。文書だけを望む場合には /{live-boot-doc}/ や /{live-config-doc}/ パッケージを別々にインストールできるようになっています。 + +3~ Debian リポジトリから + +live-boot と live-config はどちらも、{live-build のインストール}#installing-live-build +にあるように Debian リポジトリから利用できるようになっています。 + +3~ ソースから + +gitから最新のソースを利用するには以下の処理を追ってください。{用語}#terms で触れている用語について必ずよく理解しておくようにしてください。 + +_* live-boot 及び live-config のソースの取得 + +code{ + + $ git clone git://live-systems.org/git/live-boot.git + $ git clone git://live-systems.org/git/live-config.git + +}code + +パッケージをソースからビルドする理由が独自化である場合は、独自化の詳細について live-boot や live-config の man +ページを参考にしてください。 + +_* live-boot 及び live-config の .deb ファイルのビルド + +ビルドは対象ディストリビューションまたは対象のプラットフォームを収録している chroot で行う必要があります: これはつまり、対象が +${testing} であれば ${testing} に対してビルドすべきだということです。 + +ビルドシステムとは異なるディストリビューションを対象とする live-boot をビルドする必要がある場合は /{pbuilder}/ や +/{sbuild}/ といった個人向けビルダーを使ってください。例えば ${testing} の Live イメージであれば live-boot を +${testing} の chroot +でビルドしてください。対象のディストリビューションがビルドシステムのディストリビューションと一致している場合はビルドシステムで直接 +(/{dpkg-dev}/ パッケージにより提供される) #{dpkg-buildpackage}# を使ってビルドできます: + +code{ + + $ cd live-boot + $ dpkg-buildpackage -b -uc -us + $ cd ../live-config + $ dpkg-buildpackage -b -uc -us + +}code + +_* 件の .deb ファイルの利用 + +live-boot と live-config は live-build +システムによりインストールされるため、ホストシステムでパッケージをインストールするだけでは十分ではありません: 生成された .deb +ファイルを他の独自パッケージと同じように扱う必要があります。ソースからビルドする目的は恐らく公式リリース前の短期間に新しいものをテストすることなので、{変更したあるいはサードパーティ製パッケージのインストール}#installing-modified-or-third-party-packages +に従って、関連するファイルを設定に一時的に収録するようにしてください。特に、どちらのパッケージも一般的な部分、文書、そしてバックエンドに分割されていることに注意してください。一般的な部分と設定に合うバックエンドをただ1つ、オプションで文書を収録してください。Live +イメージを現在のディレクトリでビルドし、前述のディレクトリに両方のパッケージの単一バージョンの .deb ファイルを全て生成したものと仮定して、以下の +bash コマンドでデフォルトのバックエンドを含めて関連するパッケージを全てコピーします: + +code{ + + $ cp ../live-boot{_,-initramfs-tools,-doc}*.deb config/packages.chroot/ + $ cp ../live-config{_,-sysvinit,-doc}*.deb config/packages.chroot/ + +}code + +3~ 「スナップショット」から + +live-build の設定ディレクトリで live-systems.org +のパッケージリポジトリをサードパーティリポジトリとして設定することで、live-build が自動的に live-boot と live-config +の最新のスナップショットを利用するようにできます。 diff --git a/markup/pod/live-manual/media/text/ja/user_managing_a_configuration.ssi b/markup/pod/live-manual/media/text/ja/user_managing_a_configuration.ssi new file mode 100644 index 0000000..8cf9132 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_managing_a_configuration.ssi @@ -0,0 +1,110 @@ +:B~ 設定の管理 + +1~managing-a-configuration 設定の管理 + +この章では live-build ソフトウェアと Live イメージ自体の両方について、最初の作成から継続的な改訂、継続的なリリースを通して Live +設定を管理する方法を説明します。 + +2~ 設定変更への対応 + +Live 設定が最初の試行で全て上手くいくのはまれです。一度だけビルドするのならコマンドラインから #{lb config}# +オプションを渡すだけで済むかもしれませんが、満足のいくまでオプションを改訂してビルドを繰り返す方が標準的です。そうした変更を支援するには設定を確実に一貫した状態に保つ自動化スクリプトが必要となるでしょう。 + +3~ 自動化スクリプトを使う理由は? それは何をするもの? + +#{lb config}# コマンドに渡されたオプションはされている他の多数のオプションと共にデフォルト値として #{config/*}# +ファイルに保管されます。その後に #{lb config}# +を実行した場合最初のオプションを基にしてデフォルトのオプションはリセットされません。そのため、例えば #{--binary-images}# +に新しい値を指定して再び #{lb config}# +を実行した場合以前指定していた種類のイメージに依存しているオプションのデフォルト値は新しく指定した種類のイメージでは使えなくなるかもしれません。そのファイルが読み取りや変更の対象からも外れているかもしれません。これを使うと100以上のオプションの値を保管するため、実際に指定されたオプションを誰でも確認できます。最後に、#{lb +config}# を実行した後に live-build をアップグレードして、オプションの名前が変更されていた場合、#{config/*}# +には古いオプションが有効ではなくなった後に名付けられた変数も収録されます。 + +以上に挙げた理由により #{auto/*}# スクリプトにより楽が出来るようになります。このスクリプト群は #{lb config}# や #{lb +build}#、#{lb clean}# コマンドの単純なラッパーで、設定の管理を支援するように設計されています。#{auto/config}# +スクリプトは #{lb config}# コマンドと希望したオプションを全て保管し、#{auto/clean}# +スクリプトは設定用変数値を収録するファイルを削除し、#{auto/build}# スクリプトは各ビルドの #{build.log}# +を維持します。このスクリプト群はそれぞれ対応する #{lb}# +コマンドの実行時に自動的に実行されます。このスクリプト群を利用することで設定が見やすくなり、改訂を越えて内部的に一貫した状態が維持されます。また、更新された文書を読んだ後に +live-build をアップグレードすれば変更の必要があるオプションを識別、修正するのははるかに容易になるでしょう。 + +3~ 自動化スクリプトの使用例 + +便宜のため live-build +には例の自動化シェルスクリプトが付属していてコピーして編集できるようになっています。デフォルトの設定を新しく作成してから例をコピーしましょう: + +code{ + + $ mkdir mylive && cd mylive && lb config + $ mkdir auto + $ cp /usr/share/doc/live-build/examples/auto/* auto/ + +}code + +#{auto/config}# を編集して、希望に合わせてオプションを追加します。例えば: + +code{ + + #!/bin/sh + lb config noauto \ + --architectures i386 \ + --linux-flavours 686-pae \ + --binary-images hdd \ + --mirror-bootstrap http://ftp.ch.debian.org/debian/ \ + --mirror-binary http://ftp.ch.debian.org/debian/ \ + "${@}" + +}code + +これで、#{lb config}# を使うたびに #{auto/config}# +がそのオプションを基にして設定をリセットします。オプションを変更したいときには #{lb config}# +に渡すのではなくこのファイルに書かれているものを編集します。#{lb clean}# を使うと #{auto/clean}# は +#{config/*}# ファイルを、ビルドした他のものとあわせて削除します。最後に、#{lb build}# を使うとビルド時のログは +#{auto/build}# により #{build.log}# に書かれます。 + +*{注意:}* ここで特別な #{noauto}# パラメータを使い、#{auto/config}# を別に呼び出すことのないようにして無限再帰を回避しています。編集時に不注意で削除することのないようにしてください。また、読みやすくするために上記の例で示したように #{lb config}# コマンドを複数行に分割する場合は次の行に続く各行末のバックスラッシュ (\) を忘れることのないようにしてください。 + +2~clone-configuration-via-git Git経由で公開されている設定の複製 + +#{lb config --config}# オプションを使って Live +システムの設定を収録しているGitリポジトリを複製します。${project}により保守されている設定を基にしたい場合は +http://live-systems.org/gitweb/ の #{Packages}# カテゴリーの #{live-images}# +という名前のリポジトリに目を通してみてください。このリポジトリには Live システムの +{ビルド済みイメージ}#downloading-prebuilt-images 用の設定を収録しています。 + +例えば標準的なイメージをビルドするには #{live-images}# リポジトリを使って + +code{ + + $ mkdir live-images && cd live-images + $ lb config --config git://live-systems.org/git/live-images.git + $ cd images/standard + +}code + +のようにし、必要に応じて #{auto/config}# やその他 #{config}# ツリーにあるものを必要なだけ編集します。例えば非公式の +non-free ビルド済みイメージは単純に #{--archive-areas "main contrib non-free"}# +を追加することで作成されます。 + +オプションとしてGit設定でショートカットを定義することもできます。#{${HOME}/.gitconfig}# に + +code{ + + [url "git://live-systems.org/git/"] + insteadOf = lso: + +}code + +を追加すると #{live-systems.org}# にあるgitリポジトリのアドレスを指定する必要があるところで #{lso:}# +を使えるようになります。さらにオプションで末尾の #{.git}# も省くと、この設定を使って新しいイメージの作成を始めるのはこれだけ簡単になります: + +code{ + + $ lb config --config lso:live-images + +}code + +#{live-images}# +リポジトリ全体を複製すると数種類のイメージの設定を取得します。最初のイメージが出来上がってから異なるイメージをビルドしたい場合は別のディレクトリに移動して繰り返し、必要に応じて変更を加えてください。 + +どの場合も、イメージのビルド #{lb build}# は毎回スーパーユーザで行う必要があることを覚えておいてください。 diff --git a/markup/pod/live-manual/media/text/ja/user_overview.ssi b/markup/pod/live-manual/media/text/ja/user_overview.ssi new file mode 100644 index 0000000..fb98939 --- /dev/null +++ b/markup/pod/live-manual/media/text/ja/user_overview.ssi @@ -0,0 +1,108 @@ +:B~ ツールの概要 + +1~overview-of-tools ツールの概要 + +この章では Live システムのビルドに使う3つの主要ツール live-build、live-boot、live-config の概要をまとめています。 + +2~live-build live-build パッケージ + +live-build は Live システムをビルドするためのスクリプト集です。収録されているスクリプトは「コマンド」としても言及されています。 + +live-build の背景となる考え方は、設定ディレクトリを使って Live +イメージのビルドに関するあらゆる面を完全に自動化、独自化するフレームワークにしようということです。 + +その多くの概念は /{debhelper}/ で Debian パッケージをビルドするのと同様です: + +_* スクリプトには操作を制御するために中心となる位置があります。/{debhelper}/ ではパッケージツリーの #{debian/}# +サブディレクトリがこれにあたります。例えば dh_install は、他にもありますが、#{debian/install}# +というファイルを探して特定のバイナリパッケージに収録すべきファイルを判断します。ほぼ同様に live-build は設定全体を #{config/}# +サブディレクトリ以下に保管します。 + +_* スクリプトは独立しています - つまり、各コマンドの実行は常に安全です。 + +/{debhelper}/ とは異なり、live-build は設定ディレクトリの骨格を生成するツールを提供しています。これは /{dh-make}/ +等のツールに似ていると言っても良いでしょう。こういったツールのさらなる情報については、この節の残りで最も重要な4つのコマンドについて触れているので続きを読んでください。各コマンドで先行している +#{lb}# は live-build コマンドのラッパーであることに注意してください。 + +_* *{lb config}*: Live システム設定ディレクトリの初期化を担当します。さらなる情報については {lb config +コマンド}#lb-config を見てください。 + +_* *{lb build}*: Live システムのビルドの開始を担当します。さらなる情報については {lb build}#lb-build +を見てください。 + +_* *{lb clean}*: Live システムでビルドされた部分の掃除を担当します。さらなる情報については {lb clean +コマンド}#lb-clean を見てください。 + +3~lb-config #{lb config}# コマンド + +{live-build}#live-build で説明しているように、live-build を構成するスクリプトは #{config/}# +という名の単一のディレクトリから #{source}# +コマンドで指定された設定を読み込みます。このディレクトリを手作業により構成するのは時間がかかる上に誤りの元となりやすいため、#{lb config}# +コマンドを使って初期設定ツリーの骨格を作成できるようになっています。 + +引数を付けずに #{lb config}# を実行すると #{config/}# +サブディレクトリを作成してデフォルト設定がいくらか指定された設定ファイルを配置し、#{auto/}# 及び #{local/}# +という骨格となる2つのツリーを作成します。 + +code{ + + $ lb config + [2015-01-06 19:25:58] lb config + P: Creating config tree for a debian/stretch/i386 system + P: Symlinking hooks... + +}code + +とても基本的なイメージを必要とするユーザや後で #{auto/config}# を使ってもっと全面的な設定を行おうと考えている場合は #{lb +config}# を引数無しで使うのが適切でしょう (詳細は{設定管理}#managing-a-configuration 参照)。 + +通常はオプションをいくらか指定します。例えばイメージのビルド時に利用するパッケージマネージャーを指定する場合: + +code{ + + $ lb config --apt aptitude + +}code + +多数のオプションを指定することもできます: + +code{ + + $ lb config --binary-images netboot --bootappend-live "boot=live components hostname=live-host username=live-user" ... + +}code + +利用可能なオプションの全容は #{lb_config}# man ページにあります。 + +3~lb-build #{lb build}# コマンド + +#{lb build}# コマンドは #{config/}# ディレクトリから設定を読み込みます。それから Live +システムのビルドに必要な低レベルコマンドを実行します。 + +3~lb-clean #{lb clean}# コマンド + +ビルドによる様々な生成物を削除するのは #{lb clean}# +コマンドの役目で、それによりその後のビルドがきれいな状態から始められるようになります。デフォルトで +#{chroot}#、#{バイナリ}#、#{ソース}#の段階が対象となりますが、キャッシュはそのまま残されます。また、個々の段階を個別に掃除することもできます。例えばバイナリ段階にのみ影響のある変更を加えた場合は新しいバイナリをビルドする前に +#{lb clean --binary}# を実行します。変更がパッケージ収集やパッケージのキャッシュを無効化するようなもの、例えば +#{--mode}# や #{--architecture}#、#{--bootstrap}# を変更した場合は #{lb clean +--purge}# を実行しないといけません。オプションの全容については #{lb_clean}# man ページを見てください。 + +2~live-boot live-boot パッケージ + +live-boot は live-build 等により作成される Live システムのブート時に利用する initramfs の生成に利用する +/{initramfs-tools}/ のフックを提供するスクリプト集です。Live +システムのISOやネットワーク経由のブートに利用するtarアーカイブ、USBメモリ向けイメージも対象です。 + +ブート時にはルートファイルシステム (squashfs のような圧縮ファイルシステムのイメージであることが多い) が保存されている #{/live/}# +ディレクトリを収録する読み取り専用メディアを探します。見つかった場合は Debian 類似システムでそのメディアからブートできるように、aufs +を使って書き込み可能な環境を作成します。 + +Debian の初期RAMファイルシステムについてのさらなる情報は http://kernel-handbook.alioth.debian.org/ +にある Debian Linux カーネルハンドブックの initramfs の章にあります。 + +2~live-config live-config パッケージ + +live-config はブート時に live-boot の後に実行して Live +システムを自動的に設定するためのスクリプト集で構成されています。ホスト名やロケール、タイムゾーンの設定や live ユーザの作成、cron +ジョブの抑制、live ユーザの自動ログイン等のタスクを処理します。 |