Live システムマニュアル

Live システムプロジェクト &lt;debian-live@lists.debian.org&gt;

Live システムマニュアル

About

このマニュアルについて

1. このマニュアルについて

1.1 せっかちな人向け

1.2 用語

1.3 著者

1.4 この文書への貢献

1.4.1 変更の適用

1.4.2 翻訳

Live システムプロジェクトへの貢献

2. Live システムプロジェクトについて

2.1 動機

2.1.1 現在の Live システムの問題点

2.1.2 自身の Live システムを作成する理由

2.2 哲学

2.2.1 Debian「main」の変更しないパッケージしか使いません

2.2.2 Live システム固有のパッケージ設定はありません

2.3 連絡先

ユーザ

インストール

3. インストール

3.1 要件

3.2 live-build のインストール

3.2.1 Debian リポジトリから

3.2.2 ソースから

3.2.3 「スナップショット」から

3.3 live-boot と live-config のインストール

3.3.1 Debian リポジトリから

3.3.2 ソースから

3.3.3 「スナップショット」から

基本

4. 基本

4.1 Live システムとは何?

4.2 ビルド済みイメージのダウンロード

4.3 ウェブ Live イメージビルダーの利用

4.3.1 ウェブビルダーの使い方と注意

4.4 最初の段階: ISO hybrid イメージのビルド

4.5 ISO hybrid Live イメージの利用

4.5.1 ISOイメージの実際のメディアへの書き込み

4.5.2 ISO hybrid イメージのUSBメモリへのコピー

4.5.3 USBメモリの空きスペースの利用

4.5.4 Live メディアのブート

4.6 仮想マシンを利用したテスト

4.6.1 QEMU でのISOイメージのテスト

4.6.2 VirtualBox でのISOイメージのテスト

4.7 HDDイメージのビルド及び利用

4.8 netboot イメージのビルド

4.8.1 DHCP サーバ

4.8.2 TFTP サーバ

4.8.3 NFSサーバ

4.8.4 ネットワーク経由のブートをテストする方法

4.8.5 Qemu

4.9 ウェブブート

4.9.1 ウェブブートファイルの取得

4.9.2 ウェブブートイメージの起動

ツールの概要

5. ツールの概要

5.1 live-build パッケージ

5.1.1 lb config コマンド

5.1.2 lb build コマンド

5.1.3 lb clean コマンド

5.2 live-boot パッケージ

5.3 live-config パッケージ

設定の管理

6. 設定の管理

6.1 設定変更への対応

6.1.1 自動化スクリプトを使う理由は? それは何をするもの?

6.1.2 自動化スクリプトの使用例

6.2 Git経由で公開されている設定の複製

収録内容の独自化

7. 独自化の概要

7.1 ビルド時とブート時の設定

7.2 ビルド段階

7.3 ファイルによる lb config の補完

7.4 独自化タスク

インストールするパッケージの独自化

8. インストールするパッケージの独自化

8.1 パッケージソース

8.1.1 ディストリビューション、アーカイブ領域とモード

8.1.2 ディストリビューションミラー

8.1.3 ビルド時に利用するディストリビューションミラー

8.1.4 実行時に利用するディストリビューションミラー

8.1.5 追加リポジトリ

8.2 インストールするパッケージの選択

8.2.1 パッケージ一覧

8.2.2 メタパッケージの利用

8.2.3 ローカルパッケージ一覧

8.2.4 ローカルバイナリパッケージ一覧

8.2.5 生成されたパッケージ一覧

8.2.6 条件付き内部パッケージ一覧の利用

8.2.7 インストール時のパッケージの削除

8.2.8 デスクトップ及び言語タスク

8.2.9 カーネルのフレーバー (種類) とバージョン

8.2.10 独自のカーネル

8.3 変更したあるいはサードパーティ製パッケージのインストール

8.3.1 packages.chroot を利用した独自のパッケージのインストール

8.3.2 APTリポジトリを利用した独自パッケージのインストール

8.3.3 独自パッケージとAPT

8.4 ビルド時のAPT設定

8.4.1 apt と aptitude の選択

8.4.2 APTでのプロキシの利用

8.4.3 APTの調整による容量節約

8.4.4 apt や aptitude へのオプションの受け渡し

8.4.5 APTのピン止め

収録内容の独自化

9. 収録内容の独自化

9.1 Includes

9.1.1 Live/chroot ローカルインクルード

9.1.2 バイナリローカルインクルード

9.2 フック

9.2.1 Live/chroot ローカルフック

9.2.2 ブート時フック

9.2.3 バイナリローカルフック

9.3 Debconf 質問の preseed

実行時の挙動の独自化

10. 実行時の挙動の独自化

10.1 live ユーザの独自化

10.2 ロケールと言語の独自化

10.3 保持機能

10.3.1 persistence.conf ファイル

10.3.2 保持先を複数使いたい場合

10.4 暗号化した保持先の利用

バイナリイメージの独自化

11. バイナリイメージの独自化

11.1 ブートローダ

11.2 ISO メタ情報

Debian インストーラの独自化

12. Debian インストーラの独自化

12.1 Debian インストーラの種類

12.2 preseed による Debian インストーラの独自化

12.3 Debian インストーラの収録内容の独自化

プロジェクト

プロジェクトへの貢献

13. プロジェクトへの貢献

13.1 変更を加える

バグの報告

14. バグの報告

14.1 既知の問題

14.2 最初から再ビルド

14.3 最新のパッケージを使う

14.4 情報収集

14.5 可能であれば失敗している状況を分離する

14.6 正しいパッケージに対してバグを報告する

14.6.1 ビルド時のパッケージ収集中

14.6.2 ビルド時のパッケージインストール中

14.6.3 ブート時

14.6.4 実行時

14.7 調査してください

14.8 バグの報告先

コーディングスタイル

15. コーディングスタイル

15.1 互換性

15.2 インデント

15.3 改行

15.4 変数

15.5 その他

手順

16. 手順

16.1 主要リリース

16.2 ポイントリリース

16.2.1 ある Debian リリースの最後のポイントリリース

16.2.2 ポイントリリース告知用テンプレート

Gitリポジトリ

17. Gitリポジトリ

17.1 リポジトリを複数処理

例

例

18. 例

18.1 例の使用

18.2 チュートリアル 1: デフォルトイメージ

18.3 チュートリアル 2: ウェブブラウザユーティリティ

18.4 チュートリアル 3: 私的イメージ

18.4.1 最初の改訂

18.4.2 2回目の改訂

18.5 VNC 公衆クライアント

18.6 128MB USB メモリ向けの基本イメージ

18.7 地域化した GNOME デスクトップとインストーラ

付録

スタイルガイド

19. スタイルガイド

19.1 著者向けガイドライン

19.1.1 言語特性

19.1.2 手順

19.2 翻訳者向けガイドライン

19.2.1 翻訳の手がかり

Metadata

SiSU Metadata, document information

Rights: Copyright: Copyright (C) 2006-2014 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.

1

Live システムマニュアル

2

About

3

このマニュアルについて

4

1. このマニュアルについて

5

このマニュアルは Live システムプロジェクトと、特に Debian 8.0「jessie」リリースに向けてプロジェクトにより作られるソフトウェアに関連するあらゆる文書にアクセスするための一元的な起点となります。最新版は常に <http://live-systems.org/> にあります。

6

Live マニュアルは第一に Live システムのビルドの支援を扱い、エンドユーザ向けの話題は扱いませんが、エンドユーザにとって有用な情報がいくらかあるかもしれません: 基本 ではビルド済みイメージのダウンロードや、ウェブビルダーを使うかシステム上の live-build を直接実行することでメディアやネットワークからイメージをブートさせる準備について触れています。 実行時の挙動の変更 では、キーボードレイアウトやロケールの選択、再起動をまたいで状態を引き継がせる仕組みの利用等、ブートプロンプトで指定できるオプションをいくらか説明しています。

7

提示されているコマンドの一部にはスーパーユーザ権限で実行しなければならないものもあります。これは su で root ユーザになるか、sudo を使って実行します。権限のないユーザで実行できるコマンドと実行にスーパーユーザ権限を必要とするコマンドは、それぞれのコマンドの前に $ があるか # があるかで区別します。この記号はコマンドの一部ではありません。

8

1.1 せっかちな人向け

9

このマニュアルにある全てが、少なくとも一部のユーザにとって重要だと確信していますが、触れている内容が多岐にわたることや、詳細を掘り下げるよりも先に、まずはソフトウェアをうまく使う経験をしたいであろうということをわかっています。したがって、以下の順に読み進めることを提案します。

10

最初にこの章 このマニュアルについて を始めから 用語 節まで読んでください。次に 例 節の最初にある3つのチュートリアルまで飛ばします。ここではイメージのビルドと独自化の基本について教えるようになっています。 例の使用 を最初に読み、引き続いて チュートリアル 1: デフォルトイメージ と チュートリアル 2: ウェブブラウザユーティリティ を、最後に チュートリアル 3: 私的イメージ を読んでください。チュートリアル群を終えるまでに、Live システムでできることが何なのかわかってくるでしょう。

11

それから戻り、マニュアルをもっと掘り下げて学習していくことを勧めています。恐らく、その次は 基本 を読み、 netboot イメージのビルド に軽く目を通して、 独自化概要 とそれに続く章を読んで終えるのがいいでしょう。この時点までに、Live システムでできることを知ることがすっかり面白くなってマニュアルの残りを隅から隅まで読む気になっていることを期待します。

12

1.2 用語

13

Live システム: ハードドライブにインストールしなくてもブートできるオペレーティングシステムです。Live システムはそのコンピュータのハードドライブに既にインストールされているローカルのオペレーティングシステムやファイルを、そうするように指示しない限り改変しません。Live システムは通常、CDやDVD、USBメモリ等のメディアからブートされます。ネットワーク越しにブートできるもの (netboot イメージ経由、 netboot イメージのビルド 参照) やインターネット越しにブートできるもの (起動パラメータ fetch=URL 経由、 Webbooting 参照) もあります。

14

Live メディア: Live システムとは異なり、Live メディアは live-build により作成されたバイナリを書き込んでその Live システムをブートするのに利用するCDやDVD、USBメモリを指します。もっと広い意味では、この語はネットワークブートファイルの位置等、Live システムをブートする目的でこのバイナリが置かれている任意の場所を指すこともあります。

15

Live システムプロジェクト: live-boot、live-build、live-config、live-tools、live-manual パッケージを特に保守しているプロジェクトです。

16

ホストシステム: Live システムの作成に利用される環境です。

17

ターゲットシステム: Live システムの実行に利用される環境です。

18

live-boot: Live システムのブートに利用するスクリプト集です。

19

live-build: 独自化した Live システムのビルドに利用するスクリプト集です。

20

live-config: Live システムのブート処理中の設定に利用するスクリプト集です。

21

live-tools: 実行中の Live システム内で有用なタスクを実行するのに利用する追加のスクリプト集です。

22

live-manual: この文書は live-manual というパッケージで保守されています。

23

Debian Installer (d-i): 公式の Debian ディストリビューション用インストールシステムです。

24

ブートパラメータ: bootloader プロンプトで入力し、カーネルや live-config の動作を変更できるパラメータです。

25

chroot: chroot プログラム。chroot(8) により、単一のシステム上で異なる GNU/Linux 環境を再起動せずに並行して実行できるようになります。

26

バイナリイメージ: live-image-i386.hybrid.iso や live-image-i386.img 等、Live システムを収録するファイルです。

27

ターゲットディストリビューション: Live システムがベースとするディストリビューションです。これはホストシステムのディストリビューションとは別のものです。

28

安定版 (stable)/テスト版 (testing)/不安定版 (unstable): 安定版 (stable) ディストリビューション、現在のコード名wheezyには、公式にリリースされた最新の Debian ディストリビューションが含まれます。テスト版 (testing) ディストリビューション、一時的コード名 jessie は次期*{安定版 (stable)}* リリースを集める場です。このディストリビューションを使う主な利点はソフトウェアのバージョンが*{安定版 (stable)}* リリースと比べて新しいということです。unstable ディストリビューション、恒久的コード名 sid は Debian の開発が活発に行われる場です。通常、このディストリビューションは開発者や、苦労をいとわず最新版を使いたい人が利用します。マニュアル全体を通して、リリースを指すのに jessie や sid 等のコード名を使っています。それこそが、ツール自体がサポートしているものだからです。

29

1.3 著者

30

著者一覧 (アルファベット順):

31

Ben Armstrong

32

Brendan Sleight

33

Carlos Zuferri

34

Chris Lamb

35

Daniel Baumann

36

Franklin Piat

37

Jonas Stein

38

Kai Hendry

39

Marco Amadori

40

Mathieu Geli

41

Matthias Kirschner

42

Richard Nelson

43

Trent W. Buck

44

1.4 この文書への貢献

45

このマニュアルの作成はコミュニティ中心のプロジェクトで、改善提案や貢献は全て、非常に歓迎されます。コミットキーの取得方法や良いコミットを行うための詳細な情報については、 プロジェクトへの貢献 節を見てください。

46

1.4.1 変更の適用

47

マニュアルの英語版に変更を加える場合、manual/en/ にある正しいファイルを編集しないといけませんが、その貢献を提出する前に出来上がりを確認してください。Live マニュアルの出来上がりを確認する際は、

48

# apt-get install make po4a ruby ruby-nokogiri sisu-complete

49

を実行してビルドに必要なパッケージがインストールされていることを確認してください。Gitにより取得した最上位のディレクトリから

50

$ make build

51

サポートされている全言語のマニュアルをビルドするのにはある程度時間がかかるため、著者が英語版のマニュアルに追加した新しい文書について見直す場合は見直し用に処理を省略させると好都合かもしれません。PROOF=1 を使うと HTML 形式の live-manual をビルドしますが分割版の HTML ファイルを作成しません。PROOF=2 を使うとPDF形式の live-manual をビルドしますがA4とレター縦だけです。これが PROOF= を指定すると時間の節約が見込める理由です。例えば:

52

$ make build PROOF=1

53

翻訳の一つを見直す場合に一つの言語だけをビルドすることもできます。例えば:

54

$ make build LANGUAGES=ja

55

を実行します。文書の種類を指定してビルドすることもできます。例えば

56

$ make build FORMATS=pdf

57

あるいは両方を組み合わせて

58

$ make build LANGUAGES=de FORMATS=html

59

修正が済んで全て良くなったらコミットですが、そのコミットで翻訳を更新するのでない限り make commit を使わないようにしてください。また、その場合にマニュアルの英語版への変更と翻訳を一度にコミットするのではなく、それぞれ分けてコミットするようにしてください。さらなる詳細については 翻訳 節を見てください。

60

1.4.2 翻訳

61

live-manual を翻訳するには、新しく最初から翻訳を開始するのか、それとも既に存在する翻訳について作業を続けるのか、によって以下の手順を追ってください:

62

新しく最初から翻訳を開始する

63

manual/pot/ にある about_manual.ssi.pot 、about_project.ssi.pot、index.html.in.potファイルを (poedit 等) 好みのエディタで自分の言語に翻訳し、整合性確認のため翻訳した .po ファイルをメーリングリストに送ってください。live-manual の整合性確認では .po ファイルが 100% 翻訳されていることだけではなく誤りの可能性を検出します。

64

確認が済んだ後は、自動ビルドでの新しい言語の有効化は最初の翻訳済みファイルを manual/po/${言語}/ に追加して make commit を実行すれば十分です。それから manual/_sisu/home/index.html を編集して言語の名前と () 内にその英語名を追加してください。

65

既に存在する翻訳について作業を続ける

66

対象の言語が既に追加されている場合は、(poedit 等) 好みのエディタで manual/po/ にある残りの po ファイルを手当たり次第に翻訳を続けてください。

67

翻訳済みマニュアルが .po ファイルから更新されていることを確実にするためには make commit を行う必要があることと、git add .、git commit -m "Translating..."、git push を実行する前に make build を実行すると変更を確認できるということを忘れないでください。make build には相当の時間がかかる可能性があるため、 変更の適用 で説明しているように、見直しの際は1つの言語だけをビルドして確認できることを覚えておくといいでしょう。

68

make commit を実行するとテキストがいくらか流れていくのを目にするでしょう。これは基本的に処理状態についての情報を示すメッセージで、Live マニュアルの改善のために何ができるのかということを知る手がかりにもなります。致命的エラーが起きていない限り、通常はそのまま進めて貢献を提出できます。

69

Live マニュアルには、翻訳者が未翻訳や変更された文字列を検索するのを大きく支援する2つのユーティリティが付属しています。1つ目は「make translate」です。これは各 .po ファイル中にどれだけ未翻訳文字列があるのか、詳細を報告するスクリプトを実行します。2つ目は「make fixfuzzy」で、こちらは変更された文字列だけを対象としますが、1つ1つ見つけて修正する作業を支援します。

70

こういったユーティリティはコマンドラインで翻訳作業を行うのには実際に役立つかもしれませんが、推奨する作業方法は poedit のような専用ツールの利用だということに留意してください。Debian 地域化 (l10n) 文書や、特に Live マニュアル向けの 翻訳者向けのガイドライン を読むのも良いことです。

71

注意: gitツリーを push する前に make clean を実行してきれいにすることができます。この手順は .gitignore ファイルのおかげで強制ではありませんが、ファイルを意図せずコミットすることを避けられる良い実践となります。

72

Live システムプロジェクトへの貢献

73

2. Live システムプロジェクトについて

74

2.1 動機

75

2.1.1 現在の Live システムの問題点

76

Live システムプロジェクトが始まったとき、利用可能な Debian ベースの Live システムは既に複数あり、素晴らしい作業を行っていました。Debian の視点から見て、そのほとんどには以下のような不満があります。

77

Debian のプロジェクトではないために Debian でのサポートがない。

78

異なるディストリビューション、例えば*{安定版 (testing)}* と*{不安定版 (unstable)}* を混ぜて使っている。

79

サポートしているのが i386 だけ。

80

容量節約のためにパッケージの挙動や見た目を変更している。

81

Debian アーカイブ外のパッケージを収録している。

82

Debian のものではない追加パッチを適用した独自カーネルを使っている。

83

本体のサイズのために巨大で遅く、レスキュー用途に合わない。

84

異なる形式、例えば CD、DVD、USB メモリ、netboot イメージから利用できない。

85

2.1.2 自身の Live システムを作成する理由

86

Debian はユニバーサルオペレーティングシステムです: Debian に Live システムがあることで Debian システムを案内、正確に表現することができるとともに、主に以下の利点があります:

87

これは Debian のサブプロジェクトです。

88

単一のディストリビューションの (現在の) 状態を反映します。

89

可能な限り多くのアーキテクチャで動作します。

90

変更しない Debian パッケージだけで構成されます。

91

Debian アーカイブにないパッケージは何も含まれません。

92

改変しない Debian のカーネルを追加パッチなしで利用します。

93

2.2 哲学

94

2.2.1 Debian「main」の変更しないパッケージしか使いません

95

「main」Debian リポジトリのパッケージだけを利用します。「non-free」は Debian の中には含まれないため、公式の Live システムのイメージでは利用できません。

96

いかなるパッケージも変更しません。何か変更が必要であれば Debian のそのパッケージのメンテナと調整を行います。

97

例外として、live-boot や live-build、live-config といった私達の独自のパッケージを開発用の目的 (例えば開発用スナップショットの作成) のため私達自身のリポジトリから一時的に利用するかもしれません。このパッケージ群は定期的に Debian にアップロードされます。

98

2.2.2 Live システム固有のパッケージ設定はありません

99

現段階で、インストール例や代替設定は組み込んでいません。パッケージが利用されるのは Debian を普通にインストールした後のものなので全てデフォルト設定です。

100

別のデフォルト設定が必要であれば Debian のそのパッケージのメンテナと調整を行います。

101

debconf を使うことで提供されるパッケージ設定システムにより、独自に作成した Live システムのイメージを使って独自に設定したパッケージをインストールすることができるようになりますが、 ビルド済み Live イメージ では Live 環境で動作させるために絶対に必要だという場合を除いて、パッケージをそのデフォルト設定のままにすることを選択しました。Live 用ツールチェインや ビルド済みイメージ設定 への変更よりも、そこで可能である限り、Debian アーカイブにあるパッケージを Live システムでよりよく動作させることを好みます。さらなる情報については、 独自化概要 を見てください。

102

2.3 連絡先

103

メーリングリスト: プロジェクトの第一の連絡先は <https://lists.debian.org/debian-live/> のメーリングリストです。debian-live@lists.debian.org 宛てのメールにより、メーリングリストに直接メールを送ることができます。メーリングリストのアーカイブは <https://lists.debian.org/debian-live/> で利用できます。

104

IRC: ユーザや開発者達が irc.debian.org (OFTC) の #debian-live チャンネルにいます。IRCで質問するときは静かに回答を待ってください。回答が得られないときはメーリングリストにメールで質問してください。

105

BTS : Debian バグ追跡システム (BTS) には、ユーザや開発者により報告されたバグの詳細があります。バグにはそれぞれに番号が与えられ、対処されたものとして指示するまで存在するバグとして扱われます。さらなる情報については バグの報告 を見てください。

106

ユーザ

107

インストール

108

3. インストール

109

3.1 要件

110

Live システムイメージのビルドにはわずかながらシステム要件があります:

111

スーパーユーザ (root) 権限

112

最新版の live-build

113

bash や dash 等の POSIX に準拠したシェル

114

debootstrap または cdebootstrap

115

Linux 2.6 以降。

116

Debian や Debian 派生ディストリビューションの利用は必須ではないことに注意してください - live-build は上記の要件を満たすほぼありとあらゆるディストリビューションで動作します。

117

3.2 live-build のインストール

118

live-build のインストールにはいくつか方法があります:

119

Debian リポジトリから

120

ソースから

121

スナップショットから

122

Debian を使っている場合に推奨するのは Debian リポジトリからの live-build のインストールです。

123

3.2.1 Debian リポジトリから

124

他のあらゆるパッケージと同様に、単に live-build をインストールします:

125

# apt-get install live-build

126

3.2.2 ソースから

127

live-build はGitバージョン管理システムを使って開発されています。Debian ベースのシステムでは git パッケージで提供されています。最新のコードを取得するには

128

$ git clone git://live-systems.org/git/live-build.git

129

を実行します。Debian パッケージを自分でビルド、インストールすることもできます。

130

$ cd live-build
$ dpkg-buildpackage -b -uc -us
$ cd ..

131

を実行し、新しくできた .deb ファイルから対象のものをインストールします。例えば

132

# dpkg -i live-build_3.0-1_all.deb

133

システムに live-build を直接インストールすることもできます:

134

# make install

135

アンインストールは:

136

# make uninstall

137

3.2.3 「スナップショット」から

138

live-build をソースからビルドあるいはインストールしたくない場合、スナップショットを利用できます。スナップショットは Git の最新版から自動的にビルドされ、http://live-systems.org/debian/ から利用できるようになっています。

139

3.3 live-boot と live-config のインストール

140

注意: 独自の Live システムを作成するためにシステムに live-boot や live-config をインストールする必要はありません。インストールは無害で、参照目的で有用でもあります。文書だけを望む場合には live-boot-doc や live-config-doc パッケージを別々にインストールできるようになっています。

141

3.3.1 Debian リポジトリから

142

live-boot と live-config はどちらも、 live-build のインストール にあるように Debian リポジトリから利用できるようになっています。

143

3.3.2 ソースから

144

gitから最新のソースを利用するには以下の処理を追ってください。 用語 で触れている用語について必ずよく理解しておくようにしてください。

145

live-boot 及び live-config のソースの取得

146

$ git clone git://live-systems.org/git/live-boot.git
$ git clone git://live-systems.org/git/live-config.git

147

パッケージをソースからビルドする理由が独自化である場合は、独自化の詳細について live-boot や live-config の man ページを参考にしてください。

148

live-boot 及び live-config の .deb ファイルのビルド

149

ビルドは対象ディストリビューションまたは対象のプラットフォームを収録している chroot で行う必要があります: これはつまり、対象が jessie であれば jessie に対してビルドすべきだということです。

150

ビルドシステムとは異なるディストリビューションを対象とする live-boot をビルドする必要がある場合は pbuilder や sbuild といった個人向けビルダーを使ってください。例えば jessie の Live イメージであれば live-boot を jessie の chroot でビルドしてください。対象のディストリビューションがビルドシステムのディストリビューションと一致している場合はビルドシステムで直接 (dpkg-dev パッケージにより提供される) dpkg-buildpackage を使ってビルドできます:

151

$ cd live-boot
$ dpkg-buildpackage -b -uc -us
$ cd ../live-config
$ dpkg-buildpackage -b -uc -us

152

件の .deb ファイルの利用

153

live-boot と live-config は live-build システムによりインストールされるため、ホストシステムでパッケージをインストールするだけでは十分ではありません: 生成された .deb ファイルを他の独自パッケージと同じように扱う必要があります。ソースからビルドする目的は恐らく公式リリース前の短期間に新しいものをテストすることなので、 変更したあるいはサードパーティ製パッケージのインストール に従って、関連するファイルを設定に一時的に収録するようにしてください。特に、どちらのパッケージも一般的な部分、文書、そしてバックエンドに分割されていることに注意してください。一般的な部分と設定に合うバックエンドをただ1つ、オプションで文書を収録してください。Live イメージを現在のディレクトリでビルドし、前述のディレクトリに両方のパッケージの単一バージョンの .deb ファイルを全て生成したものと仮定して、以下の bash コマンドでデフォルトのバックエンドを含めて関連するパッケージを全てコピーします:

154

$ cp ../live-boot{_,-initramfs-tools,-doc}*.deb config/packages.chroot/
$ cp ../live-config{_,-sysvinit,-doc}*.deb config/packages.chroot/

155

3.3.3 「スナップショット」から

156

live-build の設定ディレクトリで live-systems.org のパッケージリポジトリをサードパーティリポジトリとして設定することで、live-build が自動的に live-boot と live-config の最新のスナップショットを利用するようにできます。

157

基本

158

4. 基本

159

この章ではビルドプロセスの概要と最も広く利用されている3種類のイメージの使用手順について簡単に述べます。最も汎用性の高い形式のイメージである iso-hybrid は、仮想マシンや光学メディア、USBポータブルストレージ機器上で利用できます。特に変わった状況では後述のように、hdd 形式の方が適するかもしれません。この章では netboot 形式のイメージをビルド、利用する手順を記載しています。この形式はサーバ上で必要とする準備のためにやや複雑になります。これは netboot についてまだ不慣れな人にとってはわずかに高度な話題となりますが、その準備さえできればローカルネットワーク上でブートするためのイメージをテスト、展開するのに非常に便利な方法で、難なくイメージのメディアを扱うことができるため、ここに収録しています。

160

この節は ウェブブート の簡単な手引きで終えています。これは恐らく異なる目的の異なるイメージを必要に応じて切り替えて使う最も簡単な方法で、手段としてインターネットを使います。

161

この章全体を通して、live-build により作成されるデフォルトのファイル名を頻繁に参照しています。 ビルド済みイメージをダウンロード した場合、実際のファイル名は異なる場合があります。

162

4.1 Live システムとは何?

163

Live システムとは、 通常 CD-ROM やUSBメモリ等の取り外し可能メディア、あるいはネットワークからコンピュータ上でブートされるオペレーティングシステムを意味し、普通のドライブに何もインストールせずに利用でき、実行時に自動設定が行われます ( 用語 参照)。

164

Live システムはオペレーティングシステムで、サポートしているうちの単一のアーキテクチャ (現在 amd64 と i386) 向けにビルドされています。以下から構成されています。

165

Linux カーネルイメージ 、通常 vmlinuz* という名前です

166

初期 RAM ディスクイメージ (initrd): Linux ブート用に用意された RAM ディスクで、システムのイメージをマウントするのに必要となる可能性があるモジュールとマウントするためのスクリプトをいくつか収録しています。

167

システムイメージ : オペレーティングシステムのファイルシステムのイメージです。通常、Live システムのイメージサイズを最小限にするため、SquashFS 圧縮ファイルシステムが利用されています。このファイルシステムは読み込み専用であることに注意してください。そのため、ブート処理中は Live システムはRAMディスクと「ユニオン」機構を利用して実行中のシステム中でファイルを書き込むことができるようにしています。ただし、オプションの保持機能を使っていない限り、変更は全てシャットダウンにより失われます ( 保持機能 参照)。

168

ブートローダ: 選択したメディアからブートするように作られた短いコードの集合で、オプション/設定を選択できるプロンプトやメニューを恐らく提示します。Linux カーネルとその initrd を読み込んでそのシステムのファイルシステム上で実行します。前に言及した構成要素を収録する対象メディアやファイルシステムの形式によっては別の方法があります。isolinux では ISO9660 形式のCDやDVDからのブート、syslinux ではHDDやUSBドライブの VFAT パーティションからのブート、extlinux では ext2/3/4 や btrfs パーティション、pxelinux では PXE netboot、GRUB では ext2/3/4 パーティション、等。

169

live-build を使って Linux カーネル、initrd、それを実行するためのブートローダを独自仕様で用意して全て1つのメディア特有の形式 (ISO9660 イメージやディスクイメージ等) でシステムのイメージをビルドできます。

170

4.2 ビルド済みイメージのダウンロード

171

このマニュアルの対象は自分の Live イメージの開発やビルドですが、使い方の手引き、あるいは自分でビルドする代わりにビルド済みイメージを簡単に試してみたいこともあるでしょう。 live-images のgitリポジトリ と公式の安定版 (stable) リリースを使ってビルドされたイメージが <https://www.debian.org/CD/live/> で公開されています。さらに、古いものや今後のリリース、non-free ファームウェアを収録する非公式のイメージ、あるいはドライバが <http://live-systems.org/cdimage/release/> から利用できるようになっています。

172

4.3 ウェブ Live イメージビルダーの利用

173

コミュニティへのサービスとして、ウェブベースの Live イメージビルダーサービスを <http://live-build.debian.net/> で運営しています。このサイトはベストエフォートの方針で保守されています。つまり、最新でいつでも使える状態の維持に努め、大規模な運用停止については問題を告知しますが、100% いつでも使えることやイメージの高速なビルドを保証することはできず、サービスについて解決に時間を要する問題が時々あるかもしれないということです。サービスについて問題や疑問があれば、問題のあるビルドへのリンクを添えて 連絡 してください。

174

4.3.1 ウェブビルダーの使い方と注意

175

ウェブインターフェイスでは現在、オプションの不正な組み合わせを避ける対策を何も取っていません。また、特に、変更すると通常ウェブフォームにある他のオプションのデフォルト値 (つまり live-build を直接使った場合の値) が変わるオプションを変更した場合にウェブビルダーはそのデフォルト値を変更しません。最も顕著な例として、--architectures をデフォルトの i386 から amd64 に変更すると対応するオプション --linux-flavours をデフォルトの 486 から amd64 に変更する必要があります。ウェブビルダーにインストールされている live-build のバージョンやさらなる詳細については lb_config man ページを見てください。live-build のバージョン番号はウェブビルダーのページ下部に記載されています。

176

ウェブビルダーにより提示される時間の推定は条件を考慮しない推定であり、実際にビルドにかかる時間を反映していないかもしれません。表示された後に更新もされません。それについては我慢してください。ビルド条件を送信した後にこのページを更新しないでください。更新すると同一のパラメータで再び新たにビルドを送信することになります。ビルドの通知をただの一度も受け取っておらず、十分な時間が確実に過ぎて、通知メールが自分の spam メールフィルタに引っかかっていないことを確認した場合、 連絡 してください。

177

ウェブビルダーがビルドできるイメージの種類は限定されています。これにより、利用や保守を簡単、能率的に維持できます。ウェブインターフェイスで提供されていない独自化を行いたい場合は、live-build を使って自分のイメージをビルドする方法をこのマニュアルの残りで説明しています。

178

4.4 最初の段階: ISO hybrid イメージのビルド

179

イメージの種類を問わず、イメージをビルドするのに同一の基礎手順を毎回実行する必要があります。最初の例ではビルド用のディレクトリを作成して、このディレクトリに移動してから live-build コマンドを以下の順で実行し、X.org のないデフォルトの Live システムを収録する基本的な ISO hybrid イメージを作成します。このイメージはCDやDVDメディアへの書き込み、さらにUSBメモリへの複製にも適しています。

180

作業ディレクトリの名前は完全に自由ですが、live-manual 全体で利用されている例を参考にする場合、特に異なる種類のイメージについて作業、実験している場合、各ディレクトリで作業しているイメージの識別を支援する名前を使うのは良い方法です。ここではデフォルトのシステムをビルドするとして、例えば live-default と呼びましょう。

181

$ mkdir live-default && cd live-default

182

それから lb config コマンドを実行します。これにより他のコマンドが利用する「config/」階層を現在のディレクトリに作成します。

183

$ lb config

184

上記のコマンドにはパラメータが渡されていないので、様々な選択肢についてそれぞれのデフォルト値が使われます。さらなる詳細については lb config コマンド を見てください。

185

これで「config/」階層ができました。lb build コマンドでイメージをビルドします。

186

# lb build

187

コンピュータやネットワーク接続の速度により、このプロセスには少々時間がかかるかもしれません。完了すると、live-image-i386.hybrid.iso イメージファイルが使える状態で現在のディレクトリにできているはずです。

188

注意: amd64 システムでビルドした場合は、出来上がるイメージの名前は live-image-amd64.hybrid.iso となります。マニュアル全体でこの慣例を採用していることに留意してください。

189

4.5 ISO hybrid Live イメージの利用

190

ISO hybrid イメージをビルド、または <https://www.debian.org/CD/live/> にあるものをダウンロードした後、通常は次にブート用メディアとして CD-R(W) や DVD-R(W) の光学メディアかUSBメモリを用意します。

191

4.5.1 ISOイメージの実際のメディアへの書き込み

192

ISOイメージの書き込みは簡単です。xorriso をインストールしてそれをコマンドラインから使ってイメージを書き込むだけです。例えば:

193

# apt-get install xorriso
$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed live-image-i386.hybrid.iso

194

4.5.2 ISO hybrid イメージのUSBメモリへのコピー

195

xorriso で作られたISOイメージは cp プログラムや同等プログラムを使って単純にUSBメモリにコピーすることができます。イメージファイルを置けるだけの十分に大きなサイズのUSBメモリを差し込んでそれがどのデバイスなのか決定します。以後 ${USBメモリ} として参照します。これは例えば /dev/sdb といったUSBメモリのデバイスファイルで、例えば /dev/sdb1 といったパーティションではありません! USBメモリを差し込んでから dmesg か、もっと良いのは ls -l /dev/disk/by-id の出力を見ると正しいデバイス名を調べることができます。

196

正しいデバイス名を得られたことを確信できたら cp コマンドを使ってイメージをUSBメモリにコピーします。これを実行すると以前そのUSBメモリにあった内容は全て確実に上書きされます!

197

$ cp live-image-i386.hybrid.iso ${USBメモリ}
$ sync

198

注意: sync コマンドはイメージのコピー中にカーネルによりメモリに記憶されているデータが全てUSBメモリに書き込まれたことを保証するのに有用です。

199

4.5.3 USBメモリの空きスペースの利用

200

live-image-i386.hybrid.iso をUSBメモリにコピーすると、最初のパーティションは Live システムで埋められます。残った空きスペースを利用するには、gparted や parted といったパーティション作業ツールを使ってそのUSBメモリに新しいパーティションを作成します。

201

# gparted ${USBメモリ}

202

パーティションの作成後にはファイルシステムを作成する必要があります。選択肢には ext4 等があります。${パーティション}には例えば /dev/sdb2 等パーティションの名前が入ります。

203

# mkfs.ext4 ${パーティション}

204

注意: 余った容量を Windows で使いたい場合ですが、このOSでは最初のパーティション以外にアクセスすることは通常できません。この問題に対する解決策が メーリングリスト でいくらか議論されていますが、簡単な解はないようです。

205

Remember: 新しい live-image-i386.hybrid.iso をUSBメモリにインストールする度に、パーティションテーブルがイメージの内容で上書きされるために USB メモリにあるデータは全て失われるので、追加パーティションをまずバックアップしてから、Live イメージの更新後に復帰させるようにしてください。

206

4.5.4 Live メディアのブート

207

Live メディアCD、DVD、USBメモリ、あるいは PXE ブートでの初回ブート時に、そのコンピュータの BIOS をまず設定する必要があるかもしれません。BIOS により機能やキーの割り当てが大きく異なるため、ここではそれについて深くは触れません。BIOS によってはブートするデバイスのメニューをブート時に提示させるキー割り当てを提供しているものがあり、そのシステムでこれが利用できる場合は最も簡単な方法でしょう。それがない場合は BIOS 設定メニューに入って Live システムのブートデバイスを通常のブートデバイスよりも前に配置するようにブート順を変更する必要があります。

208

メディアをブートするとブートメニューが表示されているでしょう。ここで単に enter を押すと、システムはデフォルトの項目 Live とデフォルトのオプションを使ってブートします。ブートオプションのさらなる情報については、メニューの「ヘルプ」の項目や Live システム内にある live-boot 及び live-config の man ページを見てください。

209

Live を選択してデフォルトのデスクトップ Live イメージをブートしたとして、ブートメッセージが流れた後、自動的に user アカウントにログインし、デスクトップがすぐに使える状態で見えているはずです。 ビルド済みイメージ の standard や rescue 等コンソールだけのイメージをブートした場合はコンソールで自動的に user アカウントにログインし、シェルプロンプトがすぐに使える状態で見えているはずです。

210

4.6 仮想マシンを利用したテスト

211

Live イメージを仮想マシン (VM) 内で実行すると開発の面で大きな時間の節約になるかもしれません。これには注意事項がないというわけではありません:

212

VMの実行にはゲストOSとホストOSの両方に十分なRAMが必要で、CPUには仮想化をハードウェアでサポートしているものを推奨します。

213

VM上での実行には、例えばビデオ性能が低いこと、エミュレーするハードウェアの選択肢が限られていること等内在する制限がいくらかあります。

214

特定のハードウェア向けの開発ではそのハードウェア自体での実行に代わるものはありません。

215

VMでの実行にのみ関連するバグが時々あります。その疑いがあるときはイメージをハードウェアで直接テストしてください。

216

こういった制約があることを理解した上で利用可能なVMソフトウェアを調べて要件に合うものを選択してください。

217

4.6.1 QEMU でのISOイメージのテスト

218

Debian で最も汎用性の高いVMは QEMU です。プロセッサが仮想化をハードウェアでサポートしている場合は qemu-kvm パッケージを使ってください。qemu-kvm パッケージの説明に要件の簡単な一覧があります。

219

プロセッサがサポートしている場合はまず qemu-kvm をインストールしてください。サポートしている場合は qemu をインストールしてください。以下の例ではどちらの場合もプログラム名は kvm ではなく qemu とします。qemu-utils パッケージもあると qemu-img で仮想ディスクのイメージを作成するのによいでしょう。

220

# apt-get install qemu-kvm qemu-utils

221

ISOイメージのブートは簡単です:

222

$ kvm -cdrom live-image-i386.hybrid.iso

223

詳細については man ページを見てください。

224

4.6.2 VirtualBox でのISOイメージのテスト

225

virtualbox でISOをテストするには:

226

# apt-get install virtualbox virtualbox-qt virtualbox-dkms
$ virtualbox

227

新しい仮想マシンを作成し、live-image-i386.hybrid.iso を CD/DVD デバイスとして利用するようにストレージ設定を変更して仮想マシンを起動します。

228

注意: X.org を収録している Live システムを virtualbox でテストしたい場合は live-build 設定に VirtualBox X.org ドライバパッケージ virtualboxbox-guest-dkms 及び virtualboxbox-guest-x11 を収録するとよいでしょう。収録しない場合、解像度は 800x600 に限定されます。

229

$ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot

230

dkms パッケージを機能させるためには、そのイメージで利用しているカーネルの種類のカーネルヘッダもインストールする必要があります。正しいパッケージの選択は上記で作成したパッケージ一覧に正しい linux-headers パッケージを手作業により列挙する代わりに live-build により自動的に行うことができます。

231

$ lb config --linux-packages "linux-image linux-headers"

232

4.7 HDDイメージのビルド及び利用

233

HDDイメージのビルドは全面的に ISO hybrid イメージのビルドと似ていて、-b hdd を指定することと出来上がりのファイル名が live-image-i386.img で光学メディアに書き込んで使うことができないという点が異なります。このイメージはUSBメモリやUSBハードドライブ、その他様々な他のポータブルストレージデバイスからのブートに適しています。通常、この目的には ISO hybrid イメージを代わりに使えますが、BIOS が hybrid イメージを適切に処理できない場合はHDDイメージが必要となります。

234

注意: 前の例で ISO hybrid イメージを作成している場合 lb clean コマンド ( lb clean コマンド 参照) で作業ディレクトリをきれいにする必要があります:

235

# lb clean --binary

236

前と同様に lb config コマンドを実行します。今回はイメージの種類にHDDを指定する点が異なります:

237

$ lb config -b hdd

238

それから lb build コマンドでイメージをビルドします:

239

# lb build

240

ビルドが完了すると現在のディレクトリに live-image-i386.img ファイルができているはずです。

241

生成されたバイナリイメージには VFAT パーティションと syslinux ブートローダが収録され、そのままUSB機器に書きこめます。繰り返しますがHDDイメージの使い方はUSBで ISO hybrid イメージを使うのと同様です。 ISO hybrid Live イメージの利用 の指示に従ってください。live-image-i386.hybrid.iso に代えて live-image-i386.img をファイル名に使う点が異なります。

242

同様に、Qemu でHDDイメージをテストするには上記の Qemu でのISOイメージのテスト で説明しているように qemu をインストールしてください。それから kvm か qemu のホストシステムで必要バージョンを実行し、最初のハードドライブとして live-image-i386.img を指定します。

243

$ kvm -hda live-image-i386.img

244

4.8 netboot イメージのビルド

245

以下の順でコマンドを実行すると X.org のないデフォルトの Live システムを収録する基本的な netboot イメージを作成します。ネットワーク越しのブートに適しています。

246

注意: 前に示した例からどれかを実行した場合、作業ディレクトリを lb clean コマンドできれいにする必要があります:

247

# lb clean

248

この特定の場合必要な段階の掃除が lb clean --binary では不十分です。netboot イメージのビルドで live-build が netboot の準備を自動的に実行するにあたって異なる initramfs 設定が必要なことがその原因です。initramfs の作成は chroot の段階で行われるため、既存のビルドディレクトリで netboot に切り替えるということは chroot の段階も再ビルドするということになります。したがって、lb clean (これは chroot の段階も削除します) を使う必要があります。

249

lb config コマンドを以下のように実行してイメージを netboot 用に設定します:

250

$ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.2"

251

ISO及びHDDイメージとは対照的に netboot 自体ではクライアントに対してファイルシステムのイメージを提供しないため、ファイルをNFS経由で提供する必要があります。lb config で異なるネットワークファイルシステムを選択することもできます。--net-root-path 及び --net-root-server オプションはそれぞれ、ブート時にファイルシステムのイメージが置かれるNFSサーバの位置とサーバを指定します。ネットワークやサーバに合う適切な値がセットされていることを確認してください。

252

それから lb build コマンドでイメージをビルドします:

253

# lb build

254

ネットワーク経由のブートでは、クライアントは通常イーサネットカードの EPROM にある小さなソフトウェアを実行します。このプログラムは DHCP リクエストを送り、IPアドレスと次に行うことについての情報を取得します。次の段階は通常、TFTP プロトコルを経由した高レベルブートローダの取得です。これには pxelinux や GRUB、さらには直接 Linux のようなオペレーティングシステムをブートすることもできます。

255

例えば生成された live-image-i386.netboot.tar アーカイブを /srv/debian-live ディレクトリに展開すると、live/filesystem.squashfs にファイルシステムのイメージ、カーネルや initrd、pxelinux ブートローダが tftpboot/ にあることがわかるでしょう。

256

ネットワーク経由でのブートをできるようにするにはサーバ上でサービスを3つ、DHCP サーバ、TFTP サーバ、NFSサーバを設定する必要があります。

257

4.8.1 DHCP サーバ

258

ネットワーク経由でブートするクライアントシステムに対して確実にIPアドレスを1つ与え、PXEブートローダの位置を通知するようにネットワークの DHCP サーバを設定する必要があります。

259

イメージしやすいように /etc/dhcp/dhcpd.conf 設定ファイルで設定する ISC DHCP サーバ isc-dhcp-server 向けに書かれた例を示します:

260

# /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;
}

261

4.8.2 TFTP サーバ

262

これはカーネルと初期RAMディスクをシステム実行時に提供します。

263

tftpd-hpa パッケージをインストールすべきです。これはルートディレクトリ、通常 /srv/tftp 内にある全ファイルを提供できます。/srv/debian-live/tftpboot 内にあるファイルを提供させるには root で

264

# dpkg-reconfigure -plow tftpd-hpa

265

を実行し、tftp サーバの新しいディレクトリについて聞かれたら回答します。

266

4.8.3 NFSサーバ

267

ゲストコンピュータが Linux カーネルをダウンロード、ブートして initrd を読み込むと、NFSサーバ経由で Live ファイルシステムのイメージをマウントしようとします。

268

nfs-kernel-server パッケージをインストールする必要があります。

269

それから /etc/exports に

270

/srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

271

のような行を追記してファイルシステムのイメージをNFS経由で利用できるようにし、この新しいエクスポートについてNFSサーバに知らせます:

272

# exportfs -rv

273

この3つのサービスの設定にはやや注意が必要かもしれません。全て協調して機能させるまでには忍耐がいくらか必要かもしれません。さらなる情報については <http://www.syslinux.org/wiki/index.php/PXELINUX> にある syslinux wiki や <http://d-i.alioth.debian.org/manual/ja.i386/ch04s05.html> にある Debian インストーラマニュアルの TFTP ネットブート節を見てください。方法はとても似ているので手助けになるかもしれません。

274

4.8.4 ネットワーク経由のブートをテストする方法

275

Netboot イメージの作成は live-build により簡単になりましたが、イメージを実際のマシンでテストするのは本当に時間がかかるものとなるかもしれません。

276

日常を楽にするために仮想化を利用できます。

277

4.8.5 Qemu

278

qemu、bridge-utils、sudo をインストールします。

279

/etc/qemu-ifup を編集します:

280

#!/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

281

grub-floppy-netboot を取得またはビルドします。

282

「-net nic,vlan=0 -net tap,vlan=0,ifname=tun0」を引数にして qemu を実行します

283

4.9 ウェブブート

284

ウェブブートは手段としてインターネットを使い Live システムをブートするための便利な方法です。ウェブブートの要件はとても少なくなっています。ある言い方をすれば必要なのはブートローダと初期RAMディスク、カーネルを収録したメディアです。別の言い方をすれば必要なのはファイルシステムを収録する squashfs ファイルを置くウェブサーバです。

285

4.9.1 ウェブブートファイルの取得

286

いつものように、イメージを自分でビルドすることも、プロジェクトのホームページ <http://live-systems.org/> から取得できるビルド済みファイルを利用することも可能です。自身の必要に応じて微調整ができるまでの初期テストにはビルド済みイメージの利用が手軽でしょう。Live イメージのビルド後ならウェブブートに必要なファイルは binary/live/ 下のビルドディレクトリで見つけられるでしょう。ファイルは vmlinuz、initrd.img、filesystem.squashfs と呼ばれます。

287

必要なファイルを既に存在するISOイメージから抽出することも可能です。そのためには以下のようにしてそのイメージをループバックマウントします:

288

# mount -o loop image.iso /mnt

289

ファイルは live/ ディレクトリで見つけられます。この例の場合は /mnt/live/ になります。この方法にはそのイメージをマウントするのに root になる必要があるという欠点があります。しかしこれには簡単に定型処理、つまり自動化できるという利点があります。

290

しかし疑いようもなく、ISOイメージからファイルを抽出すると同時にウェブサーバにアップロードするのに最も簡単なのはミッドナイトコマンダーや mc の利用でしょう。genisoimage パッケージをインストールしていれば2ペインのファイルマネージャによりISOファイルの内容を確認しながらもう1つのペインではftp経由でファイルをアップロードできます。この方法は手作業の介入が必要とはなりますが root 権限を必要としません。

291

4.9.2 ウェブブートイメージの起動

292

ユーザによってはウェブブートのテストに仮想化を好みますがここでは以下の活用事例に合わせて実際のハードウェアについて言及します。あくまで例だと思ってください。

293

ウェブブートイメージの起動は上記で示した構成要素、つまり vmlinuz と initrd.img をUSBメモリの live/ ディレクトリ以下に書き込み、ブートローダとして syslinux をインストールすれば十分です。そしてUSBメモリからブートしてブートオプションに fetch=URL/ファイル/への/パス を入力します。live-boot は squashfs ファイルを取得してRAMに格納します。こうして、ダウンロードした圧縮ファイルシステムを普通の Live システムとして使えるようになります。例えば:

294

append boot=live components fetch=http://192.168.2.50/images/webboot/filesystem.squashfs

295

活用事例: ウェブサーバがあり、squashfs ファイルが2つ、1つは例えば gnome のようなデスクトップ環境一式を収録したものともう1つは復旧用が置かれているとします。あるマシンでグラフィカル環境が必要であればUSBメモリを差し込んで gnome 用イメージをウェブブートできます。後者のイメージに収録されている復旧用ツールが別のマシン等で必要になった場合は復旧用のイメージをウェブブートできます。

296

ツールの概要

297

5. ツールの概要

298

この章では Live システムのビルドに使う3つの主要ツール live-build、live-boot、live-config の概要をまとめています。

299

5.1 live-build パッケージ

300

live-build は Live システムをビルドするためのスクリプト集です。収録されているスクリプトは「コマンド」としても言及されています。

301

live-build の背景となる考え方は、設定ディレクトリを使って Live イメージのビルドに関するあらゆる面を完全に自動化、独自化するフレームワークにしようということです。

302

その多くの概念は debhelper で Debian パッケージをビルドするのと同様です:

303

スクリプトには操作を制御するために中心となる位置があります。debhelper ではパッケージツリーの debian/ サブディレクトリがこれにあたります。例えば dh_install は、他にもありますが、debian/install というファイルを探して特定のバイナリパッケージに収録すべきファイルを判断します。ほぼ同様に live-build は設定全体を config/ サブディレクトリ以下に保管します。

304

スクリプトは独立しています - つまり、各コマンドの実行は常に安全です。

305

debhelper とは異なり、live-build は設定ディレクトリの骨格を生成するツールを提供しています。これは dh-make 等のツールに似ていると言っても良いでしょう。こういったツールのさらなる情報については、この節の残りで最も重要な4つのコマンドについて触れているので続きを読んでください。各コマンドで先行している lb は live-build コマンドのラッパーであることに注意してください。

306

lb config: Live システム設定ディレクトリの初期化を担当します。さらなる情報については lb config コマンド を見てください。

307

lb build: Live システムのビルドの開始を担当します。さらなる情報については lb build を見てください。

308

lb clean: Live システムでビルドされた部分の掃除を担当します。さらなる情報については lb clean コマンド を見てください。

309

5.1.1 lb config コマンド

310

live-build で説明しているように、live-build を構成するスクリプトは config/ という名の単一のディレクトリから source コマンドで指定された設定を読み込みます。このディレクトリを手作業により構成するのは時間がかかる上に誤りの元となりやすいため、lb config コマンドを使って初期設定ツリーの骨格を作成できるようになっています。

311

引数を付けずに lb config を実行すると config/ サブディレクトリを作成してデフォルト設定がいくらか指定された設定ファイルを配置し、auto/ 及び local/ という骨格となる2つのツリーを作成します。

312

$ lb config
[2014-04-25 17:14:34] lb config
P: Updating config tree for a debian/wheezy/i386 system

313

とても基本的なイメージを必要とするユーザや後で auto/config を使ってもっと全面的な設定を行おうと考えている場合は lb config を引数無しで使うのが適切でしょう (詳細は 設定管理 参照)。

314

通常はオプションをいくらか指定します。例えばイメージのビルド時に利用するパッケージマネージャーを指定する場合:

315

$ lb config --apt aptitude

316

多数のオプションを指定することもできます:

317

$ lb config --binary-images netboot --bootappend-live "boot=live components hostname=live-host username=live-user" ...

318

利用可能なオプションの全容は lb_config man ページにあります。

319

5.1.2 lb build コマンド

320

lb build コマンドは config/ ディレクトリから設定を読み込みます。それから Live システムのビルドに必要な低レベルコマンドを実行します。

321

5.1.3 lb clean コマンド

322

ビルドによる様々な生成物を削除するのは lb clean コマンドの役目で、それによりその後のビルドがきれいな状態から始められるようになります。デフォルトで chroot、バイナリ、ソースの段階が対象となりますが、キャッシュはそのまま残されます。また、個々の段階を個別に掃除することもできます。例えばバイナリ段階にのみ影響のある変更を加えた場合は新しいバイナリをビルドする前に lb clean --binary を実行します。変更がパッケージ収集やパッケージのキャッシュを無効化するようなもの、例えば --mode や --architecture、--bootstrap を変更した場合は lb clean --purge を実行しないといけません。オプションの全容については lb_clean man ページを見てください。

323

5.2 live-boot パッケージ

324

live-boot は live-build 等により作成される Live システムのブート時に利用する initramfs の生成に利用する initramfs-tools のフックを提供するスクリプト集です。Live システムのISOやネットワーク経由のブートに利用するtarアーカイブ、USBメモリ向けイメージも対象です。

325

ブート時にはルートファイルシステム (squashfs のような圧縮ファイルシステムのイメージであることが多い) が保存されている /live/ ディレクトリを収録する読み取り専用メディアを探します。見つかった場合は Debian 類似システムでそのメディアからブートできるように、aufs を使って書き込み可能な環境を作成します。

326

Debian の初期RAMファイルシステムについてのさらなる情報は <http://kernel-handbook.alioth.debian.org/> にある Debian Linux カーネルハンドブックの initramfs の章にあります。

327

5.3 live-config パッケージ

328

live-config はブート時に live-boot の後に実行して Live システムを自動的に設定するためのスクリプト集で構成されています。ホスト名やロケール、タイムゾーンの設定や live ユーザの作成、cron ジョブの抑制、live ユーザの自動ログイン等のタスクを処理します。

329

設定の管理

330

6. 設定の管理

331

この章では live-build ソフトウェアと Live イメージ自体の両方について、最初の作成から継続的な改訂、継続的なリリースを通して Live 設定を管理する方法を説明します。

332

6.1 設定変更への対応

333

Live 設定が最初の試行で全て上手くいくのはまれです。一度だけビルドするのならコマンドラインから lb config オプションを渡すだけで済むかもしれませんが、満足のいくまでオプションを改訂してビルドを繰り返す方が標準的です。そうした変更を支援するには設定を確実に一貫した状態に保つ自動化スクリプトが必要となるでしょう。

334

6.1.1 自動化スクリプトを使う理由は? それは何をするもの?

335

lb config コマンドに渡されたオプションはされている他の多数のオプションと共にデフォルト値として config/* ファイルに保管されます。その後に lb config を実行した場合最初のオプションを基にしてデフォルトのオプションはリセットされません。そのため、例えば --binary-images に新しい値を指定して再び lb config を実行した場合以前指定していた種類のイメージに依存しているオプションのデフォルト値は新しく指定した種類のイメージでは使えなくなるかもしれません。そのファイルが読み取りや変更の対象からも外れているかもしれません。これを使うと100以上のオプションの値を保管するため、実際に指定されたオプションを誰でも確認できます。最後に、lb config を実行した後に live-build をアップグレードして、オプションの名前が変更されていた場合、config/* には古いオプションが有効ではなくなった後に名付けられた変数も収録されます。

336

以上に挙げた理由により auto/* スクリプトにより楽が出来るようになります。このスクリプト群は lb config や lb build、lb clean コマンドの単純なラッパーで、設定の管理を支援するように設計されています。auto/config スクリプトは lb config コマンドと希望したオプションを全て保管し、auto/clean スクリプトは設定用変数値を収録するファイルを削除し、auto/build スクリプトは各ビルドの build.log を維持します。このスクリプト群はそれぞれ対応する lb コマンドの実行時に自動的に実行されます。このスクリプト群を利用することで設定が見やすくなり、改訂を越えて内部的に一貫した状態が維持されます。また、更新された文書を読んだ後に live-build をアップグレードすれば変更の必要があるオプションを識別、修正するのははるかに容易になるでしょう。

337

6.1.2 自動化スクリプトの使用例

338

便宜のため live-build には例の自動化シェルスクリプトが付属していてコピーして編集できるようになっています。デフォルトの設定を新しく作成してから例をコピーしましょう:

339

$ mkdir mylive && cd mylive && lb config
$ mkdir auto
$ cp /usr/share/doc/live-build/examples/auto/* auto/

340

auto/config を編集して、希望に合わせてオプションを追加します。例えば:

341

#!/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/ \
"${@}"

342

これで、lb config を使うたびに auto/config がそのオプションを基にして設定をリセットします。オプションを変更したいときには lb config に渡すのではなくこのファイルに書かれているものを編集します。lb clean を使うと auto/clean は config/* ファイルを、ビルドした他のものとあわせて削除します。最後に、lb build を使うとビルド時のログは auto/build により build.log に書かれます。

343

注意: ここで特別な noauto パラメータを使い、auto/config を別に呼び出すことのないようにして無限再帰を回避しています。編集時に不注意で削除することのないようにしてください。また、読みやすくするために上記の例で示したように lb config コマンドを複数行に分割する場合は次の行に続く各行末のバックスラッシュ (\) を忘れることのないようにしてください。

344

6.2 Git経由で公開されている設定の複製

345

lb config --config オプションを使って Live システムの設定を収録しているGitリポジトリを複製します。Live システムプロジェクトにより保守されている設定を基にしたい場合は <http://live-systems.org/gitweb/> の Packages カテゴリーの live-images という名前のリポジトリに目を通してみてください。このリポジトリには Live システムの ビルド済みイメージ 用の設定を収録しています。

346

例えばレスキュー用のイメージをビルドするには live-images リポジトリを使って

347

$ mkdir live-images && cd live-images
$ lb config --config git://live-systems.org/git/live-images.git
$ cd images/rescue

348

のようにし、必要に応じて auto/config やその他 config ツリーにあるものを必要なだけ編集します。例えば非公式の non-free ビルド済みイメージは単純に --archive-areas "main contrib non-free" を追加することで作成されます。

349

オプションとしてGit設定でショートカットを定義することもできます。${HOME}/.gitconfig に

350

[url "git://live-systems.org/git/"]
insteadOf = lso:

351

を追加すると live-systems.org にあるgitリポジトリのアドレスを指定する必要があるところで lso: を使えるようになります。さらにオプションで末尾の .git も省くと、この設定を使って新しいイメージの作成を始めるのはこれだけ簡単になります:

352

$ lb config --config lso:live-images

353

live-images リポジトリ全体を複製すると数種類のイメージの設定を取得します。最初のイメージが出来上がってから異なるイメージをビルドしたい場合は別のディレクトリに移動して繰り返し、必要に応じて変更を加えてください。

354

どの場合も、イメージのビルド lb build は毎回スーパーユーザで行う必要があることを覚えておいてください。

355

収録内容の独自化

356

7. 独自化の概要

357

この章では Live システムを独自化できる様々な方法について概要を示します。

358

7.1 ビルド時とブート時の設定

359

Live システムの設定オプションはビルド時に適用されるビルド時オプションとブート時に適用されるブート時オプションとに分けられます。ブート時オプションはさらに、live-boot パッケージにより適用され、ブートの早い段階で起きるものと live-config パッケージにより適用され、ブートの遅い段階で起きるものとに分けられます。ブート時オプションはどれも、ユーザがブートプロンプトで指定することで変更できます。イメージは、デフォルトのブートパラメータを指定してビルドし、デフォルト値を全て適応する場合オプションをユーザが何も指定せずに普通に Live システムを直接ブートするようにもできます。特に、lb --bootappend-live への引数は設定の維持やキーボードレイアウト、タイムゾーン等、Live システムのカーネルコマンドラインオプションのデフォルト値で構成されます。例については ロケールと言語の独自化 を見てください。

360

ビルド時設定オプションは lb config の man ページで説明されています。ブート時オプションは live-boot と live-config の man ページで説明されています。live-boot 及び live-config パッケージはビルドする Live システム内にインストールされますが、設定作業時に参照しやすいようにビルドシステムにもインストールすることを勧めます。収録されているスクリプトはどれも、そのシステムが Live システムとして設定されていないと実行されないため、ビルドシステムへのインストールは安全です。

361

7.2 ビルド段階

362

ビルドプロセスは段階ごとに分けられ、様々な独自化がそれぞれ順に適用されます。実行の最初の段階は*{パッケージ収集}*段階です。この初期段階では chroot ディレクトリを作成して Debian システムの骨子を構成するパッケージを集めます。引き続いて*{chroot}*段階があり、chroot ディレクトリの構成を完了させ、他の内容とともに設定に列挙されているパッケージを全て収集します。収録内容の独自化はほとんどがこの段階で起こります。Live イメージの準備の最終段階は*{バイナリ}*段階で、ブート可能なイメージをビルドします。chroot ディレクトリの内容を使って Live システムのルートファイルシステムを作成し、インストーラと 対象メディアの Live システムのファイルシステム外に配置する、他の追加の内容を全て収録します。Live イメージをビルドした後は、有効化されている場合はソースの tar アーカイブを*{ソース}*段階で作成します。

363

各段階で、コマンドの適用には特定の順序があります。そのように配置することで、独自化を合理的に階層化できるようになります。例えば chroot 段階ではどのパッケージをインストールするよりも前に preseed が適用され、ローカルに収録したどのファイルをコピーするよりも前にパッケージをインストールし、フックはその後に、収録内容を全て配置してから実行されます。

364

7.3 ファイルによる lb config の補完

365

lb config は設定の骨格を config/ ディレクトリに作成しますが、目標を実現するには config/ サブディレクトリ以下に追加のファイルを提供する必要があるかもしれません。設定のどこにファイルを置くかにより、Live システムのファイルシステムやバイナリイメージのファイルシステムにコピーされるか、コマンドラインオプションとして渡す方法では扱いにくいビルド時のシステム設定を提供することになります。独自のパッケージ一覧やアートワーク、あるいはビルド時またはブート時に実行するフックスクリプト等を収録し、debian-live は既にかなりの柔軟性がありますが、自身のコードでそれを後押しすることができます。

366

7.4 独自化タスク

367

以下の章ではユーザがよく行う類の独自化タスクをほんの一部ですがまとめています: インストールするパッケージの独自化 収録内容の独自化 ロケールと言語の独自化

368

インストールするパッケージの独自化

369

8. インストールするパッケージの独自化

370

恐らく Live システムの最も基本的な独自化はイメージに収録するパッケージの選択でしょう。この章では live-build でのパッケージのインストールの独自化のためのビルド時の様々なオプションを見ていきます。イメージへのインストールに利用可能なパッケージに関して最も影響が大きい選択はディストリビューションとアーカイブ領域です。まともなダウンロード速度を確保するため、近いディストリビューションミラーを選択してください。backports や experimental あるいは独自のパッケージのある自身専用のリポジトリを追加することもできます。また、ファイルを直接パッケージとして収録することもできます。特定のデスクトップや言語のパッケージ等、多数の関連パッケージを同時にインストールするメタパッケージを含め、パッケージ一覧は定義できます。最後に、ビルドでパッケージをインストールするときに apt や好みにより aptitude を制御するオプションもいくらかあります。プロキシを使っていたり、推奨パッケージのインストールを無効にして容量を節約したい、インストールするパッケージのバージョンをAPTのピン経由で制御する必要がある、等便利だと思う場面があるかもしれません。

371

8.1 パッケージソース

372

8.1.1 ディストリビューション、アーカイブ領域とモード

373

ディストリビューションの選択は Live イメージへの収録に利用できるパッケージに最も影響があります。コード名を指定してください。jessie バージョンの live-build では jessie がデフォルトになっています。現在アーカイブにある任意のディストリビューションをコード名で指定できます (詳細については 条件 参照)。--distribution オプションはアーカイブ内のパッケージソースに影響するだけでなく、サポートしている各ディストリビューションをビルドするのに必要な動作をするよう live-build に指示します。例えば*{unstable}*リリースであるsidに対してビルドする場合は:

374

$ lb config --distribution sid

375

のように指定します。ディストリビューションアーカイブ内で、アーカイブ領域はアーカイブを大きく分類します。Debian では#{main}#、contrib、non-free となっています。mainに収録されるソフトウェアだけが Debian ディストリビューションの一部であり、したがってそれがデフォルトとなっています。複数指定することもできます。例えば

376

$ lb config --archive-areas "main contrib non-free"

377

Debian 派生物によっては --mode オプションの実験的サポートが利用できるものがあります。このオプションは Debian または未知のシステムでビルドしている場合にのみデフォルトで debian がセットされています。サポートしている派生物のどれかで lb config を実行した場合のデフォルト値はその派生物のイメージを作成するための値になります。lb config を例えば ubuntu モードで実行すると Debian 向けに代えて指定された派生物のディストリビューション名やアーカイブ領域がサポートされます。このモードはその派生物に合うように live-build の挙動も変更します。

378

注意: モードを追加したプロジェクトの設定については主にそのオプションのサポートユーザの担当です。Live システムプロジェクトは最善の努力をもって開発サポートを提供はしますが、私たちは派生物を自ら開発あるいはサポートしているわけではないため、あくまで派生物プロジェクトからのフィードバックが基になります。

379

8.1.2 ディストリビューションミラー

380

Debian アーカイブは世界中の巨大なネットワークミラーにまたがって複製されているため、各地域の人が最高のダウンロード速度を求めて近いミラーを選択できます。--mirror-* オプションはそれぞれ、ビルドの様々な段階でどのディストリビューションミラーを利用するのかを決定します。 ビルド段階 の繰り返しになりますが*{パッケージ収集}*段階は最小限のシステムで debootstrap により最初に chroot を構成する段階、chroot 段階は chroot を使って Live システムのファイルシステムをビルドする段階です。ミラーはこの各段階ごとにそれぞれのオプションで指定するため*{バイナリ}*の段階では --mirror-binary や --mirror-binary-security の値が採用され、早い段階で使っていたミラーは置き換えられることになります。

381

8.1.3 ビルド時に利用するディストリビューションミラー

382

ビルド時に利用するディストリビューションミラーにローカルミラーを指定するには、--mirror-bootstrap、--mirror-chroot-security、--mirror-chroot-backports を以下のように指定するだけです。

383

$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/ \
--mirror-chroot-backports http://localhost/debian-backports/

384

--mirror-chroot で指定する chroot ミラーのデフォルト値は --mirror-bootstrap の値になっています。

385

8.1.4 実行時に利用するディストリビューションミラー

386

--mirror-binary* オプションはバイナリイメージ中のディストリビューションミラーの位置を決定します。このオプションは Live システムの実行中に追加のパッケージをインストールする際に利用できます。デフォルトは http.debian.net で、利用できるミラーの中から特にユーザのIPアドレスを基にして地理的に近いミラーを選択するサービスになっています。これはその Live システムを利用するユーザにとって最適なミラーを予測できない場合に適切な選択です。以下の例に示すように自分専用の値を指定することもできます。この設定でビルドされたイメージはその"ミラー"が到達可能なネットワークにいるユーザにとってのみ適します。

387

$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/ \
--mirror-binary-backports http://mirror/debian-backports/

388

8.1.5 追加リポジトリ

389

リポジトリをさらに追加して、利用できるパッケージ選択の幅を対象ディストリビューション以外にも広げられます。それにより、例えば backports や experimental、そして独自のパッケージを利用できます。追加のリポジトリを設定するには config/archives/your-repository.list.chroot や config/archives/your-repository.list.binary ファイルを作成します。--mirror-* オプションにより、イメージのビルドの chroot 段階や*{バイナリ}*段階、つまり Live システムの実行時に利用するリポジトリを決定できます。

390

例えば config/archives/live.list.chroot により Live システムのビルド時に debian-live スナップショットリポジトリからパッケージをインストールできます。

391

deb http://live-systems.org/ sid-snapshots main contrib non-free

392

同一の行を config/archives/live.list.binary に追加すると、Live システムの /etc/apt/sources.list.d/ ディレクトリにそのリポジトリが追加されます。

393

こういったファイルが存在すれば自動的に処理されます。

394

リポジトリの署名に利用されたGPG鍵を config/archives/your-repository.key.{binary,chroot} ファイルに置くこともできます。

395

APTのピン止めが独自に必要な場合、APT設定行等を config/archives/your-repository.pref.{binary,chroot} ファイルに配置すれば自動的に Live システムの /etc/apt/preferences.d/ ディレクトリに追加されます。

396

8.2 インストールするパッケージの選択

397

イメージに live-build がインストールするパッケージを選択する方法はいくつかあり、異なる様々な要求に対応します。インストールする個々のパッケージをパッケージ一覧で指定できます。その一覧でメタパッケージを利用あるいはパッケージ制御 ファイル fields を使って選択できます。 そして最後に、パッケージファイルを config/ ツリーに置く方法があります。 この方法は、新しいあるいは試験的なパッケージをリポジトリから利用できるようになる前にテストするのに非常に適しています。

398

8.2.1 パッケージ一覧

399

パッケージ一覧はインストールするパッケージを明確にする強力な方法です。一覧の構文では条件付けをサポートし、一覧の生成や複数の設定への適合を容易にしています。ビルド時にシェルヘルパーを使って一覧にパッケージ名を差し込むこともできます。

400

注意: 存在しないパッケージが指定されたときの live-build の挙動はAPTユーティリティの選択により決定されます。さらなる詳細については apt と aptitude の選択 を見てください。

401

8.2.2 メタパッケージの利用

402

パッケージ一覧を指示するもっとも簡単な方法は利用するディストリビューションで保守されているタスクのメタパッケージの利用です。例えば:

403

$ lb config
$ echo task-gnome-desktop > config/package-lists/desktop.list.chroot

404

live-build 2.x でサポートされていた、一覧を事前定義する古い方法はこれで置き換えられました。一覧の事前定義とは異なり、タスクのメタパッケージは Live システムプロジェクト特有のものではありません。タスクのメタパッケージはディストリビューション内の専門の作業グループにより保守されているため、要求したユーザに対して提供する最善のパッケージについて、各グループでの合意を反映したものとなっています。また、一覧を事前定義する置き換えられた方法よりはるかに幅広い事例にも対応できます。

405

タスクのメタパッケージには全て先頭が task- から始まるため、利用できるものを簡単に判別する方法があります (名前が該当しても実際にはメタパッケージではないものもほんの一部とはいえありますが)。パッケージ名を前方一致で検索します:

406

$ apt-cache search --names-only ^task-

407

以上に加え、他に様々な目的を持ったメタパッケージを見つけられるでしょう。gnome-core のように他のもっと範囲の広いタスクパッケージの一部を構成するものや、education-* メタパッケージのように Debian Pure Blend の中のある個々の専門分野に特化したものもあります。アーカイブにある全メタパッケージを列挙するには、debtags パッケージをインストールして role::metapackage タグの付けられたパッケージを全て列挙させます:

408

$ debtags search role::metapackage

409

8.2.3 ローカルパッケージ一覧

410

列挙したものがメタパッケージであれ、個々のパッケージであれ、両方の組み合わせであれ、ローカルパッケージ一覧は全て config/package-lists/ に保存されます。この一覧は複数利用できるため、うまい具合にこの一覧自体を組み込める設計になっています。例えばある一覧は特定のデスクトップ選択時向け、別の一覧は異なるデスクトップでも簡単に使えるような関連パッケージ群を、というようにできます。これにより、パッケージ群の異なる組み合わせを最小限の手間で試したり、あるいは異なる Live イメージプロジェクトで一覧を共有する、といったことが可能になります。

411

このディレクトリに存在するパッケージ一覧は、処理対象とするためには後ろに .list を付ける必要があり、さらにその一覧をどの段階の対象とするのか示すためには .chroot や .binary をその後に追加します。

412

注意: 対象とする段階の指定を追加しない場合、その一覧は両方の段階で利用されます。通常指定するのは .list.chroot で、この場合そのパッケージは Live ファイルシステムにのみインストールされ、メディア上に .deb の余計なコピーは置かれません。

413

8.2.4 ローカルバイナリパッケージ一覧

414

バイナリ段階の一覧を作成する場合はファイルの末尾を .list.binary にして config/package-lists/ に置きます。それにより指定したパッケージは Live ファイルシステムにはインストールされず、Live メディアの pool/ 以下に収録されます。Live ではないインストーラでこういった一覧を標準的に利用しているものもあります。バイナリ段階で chroot 段階と同一の一覧を利用したい場合は上述したように末尾を .list とします。

415

8.2.5 生成されたパッケージ一覧

416

一覧の構成はスクリプトで生成するのが最善の方法だということもあります。感嘆符から始まる行は全て、そのコマンドがイメージのビルド後に chroot 内で実行されることを示します。例えばパッケージ一覧に ! grep-aptavail -n -sPackage -FPriority standard | sort という行を書いておけば、Priority: standard で利用可能なパッケージをソートした一覧を生成できます。

417

実際、パッケージの選択に grep-aptavail コマンド (dctrl-tools パッケージに収録) はとても有用なので、live-build では便宜のため Packages 補助スクリプトを提供しています。このスクリプトは引数を#{フィールド}#と#{パターン}#の2つ取ります。一覧を作成する例:

418

$ lb config
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

419

8.2.6 条件付き内部パッケージ一覧の利用

420

config/* (LB_ が先頭に付くものは除く) に保存された live-build の設定変数はどれもパッケージ一覧の条件文で利用できます。一般には lb config オプションを大文字に、ダッシュ文字をアンダースコアに変更したものになります。しかし実際に意味があるのは、パッケージ選択に関わるもの、例えば DISTRIBUTION や ARCHITECTURES、ARCHIVE_AREAS だけです。

421

例えば --architectures amd64 が指定された場合に ia32-libs をインストールする場合:

422

#if ARCHITECTURES amd64
ia32-libs
#endif

423

任意の1つを条件の値とすることもできます。--architectures i386 または --architectures amd64 のどちらかが指定された場合に memtest86+ をインストールする場合の例:

424

#if ARCHITECTURES i386 amd64
memtest86+
#endif

425

値を複数指定できる変数を条件にすることもできます。--archive-areas で contrib または non-free のどちらかが指定されている場合に vrms をインストールする場合の例:

426

#if ARCHIVE_AREAS contrib non-free
vrms
#endif

427

入り組んだ条件分岐はサポートしていません。

428

8.2.7 インストール時のパッケージの削除

429

config/package-lists ディレクトリの末尾が .list.chroot_live や .list.chroot_install のファイルにパッケージを列挙できます。Live 用とインストール用の両方の一覧が存在する場合、.list.chroot_live に列挙されているパッケージは (ユーザがインストーラを利用している場合) インストール後にフックにより削除されます。.list.chroot_install に列挙されているパッケージは Live システムとインストールされたシステムの両方に存在することになります。これはインストーラ向けの特別な調整で、設定で --debian-installer live をセットしている場合や Live システム特有のパッケージをインストール時には削除したい場合に有用かもしれません。

430

8.2.8 デスクトップ及び言語タスク

431

デスクトップと言語のタスクは特別で、計画性や設定が追加で必要となります。Live イメージが Debian インストーライメージとは異なる点です。Debian インストーラでは、特定のデスクトップ環境向けに用意されたメディアでは対応するタスクは自動的にインストールされます。内部に gnome-desktop や kde-desktop、lxde-desktop、xfce-desktop タスクがあり、tasksel のメニューにはどれも出てきません。同様に言語向けタスクのメニュー項目はありませんが、インストール中にユーザが選択した言語が対応する言語タスクの選択に影響します。

432

デスクトップ向け Live イメージ開発時には、イメージは通常動作するデスクトップを直接ブートし、デスクトップやデフォルト言語はどちらも Debian インストーラの場合のように実行時に選択するのではなくビルド時に決められています。これは Live イメージでデスクトップや言語を複数サポートしてユーザに選択の機会を与えるようにできないわけではなく、それが live-build のデフォルトの挙動ではないというだけです。

433

言語特有のフォントや入力メソッドにどのパッケージを収録するのか、といった規定は言語タスクにはないので、特定のパッケージを収録したい場合は設定で指定する必要があります。ドイツ語サポートを収録した GNOME デスクトップイメージの場合に収録するタスクのメタパッケージの例:

434

$ 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

435

8.2.9 カーネルのフレーバー (種類) とバージョン

436

アーキテクチャによっては、イメージに複数のカーネルをデフォルトで収録することができます。フレーバーは --linux-flavours オプションで選択できます。各フレーバーはデフォルトの短い linux-image に、イメージに収録される実際のカーネルパッケージに依存する各メタパッケージの名前を付加した形式になります。

437

そうして、デフォルトで amd64 アーキテクチャのイメージは linux-image-amd64 のメタパッケージを収録し、i386 アーキテクチャのイメージは linux-image-486 と linux-image-686-pae メタパッケージを収録します。これを書いている時点ではそれぞれ linux-image-3.2.0-4-amd64、linux-image-3.2.0-4-486、linux-image-3.2.0-4-686-pae に依存しています。

438

設定したアーカイブで複数バージョンのカーネルパッケージが利用できる場合、--linux-packages オプションでカーネルパッケージ名の前半部を指定できます。例えば amd64 アーキテクチャのイメージをビルドする際にテスト用に experimental アーカイブを追加すると linux-image-3.7-trunk-amd64 カーネルをインストールできます。そのイメージの設定例:

439

$ lb config --linux-packages linux-image-3.7-trunk
$ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

440

8.2.10 独自のカーネル

441

Debian パッケージ管理システムに組み入れられていれば、独自のカーネルを自分でビルド、収録できます。live-build システムは .deb パッケージでビルドされていないカーネルはサポートしていません。

442

自身のカーネルパッケージを配置するための適切で推奨する方法は kernel-handbook の指示に従うことです。パッケージ名のABIとフレーバーの部分を忘れずに適切に変更し、リポジトリに linux の完全なビルドとそれに該当する linux-latest パッケージを収録してください。

443

該当するメタパッケージ無しでカーネルパッケージをビルドしたい場合は、 カーネルのフレーバー (種類) とバージョン で説明しているように --linux-packages でパッケージ名の適切な前半部を指定する必要があります。 変更したあるいはサードパーティ製パッケージのインストール で説明しているように、自身のリポジトリに独自のカーネルパッケージを収録する場合はそのようにするのが最善ですが、別の方法についても説明しています。

444

カーネルを独自化する方法はこの文書の対象範囲ではありません。とはいえ、設定が最低限満たさないといけない要件があります:

445

初期RAMディスクを利用する。

446

結合ファイルシステムモジュール (つまり通常は aufs) を収録する。

447

自分の設定で必要とする他のファイルシステムモジュール (つまり通常は squashfs) があればそれを収録する。

448

8.3 変更したあるいはサードパーティ製パッケージのインストール

449

Live システムの哲学には反しますが、Debian リポジトリにあるバージョンのパッケージを改変して Live システムをビルドする必要に迫られることもあります。それは機能や言語、商標を変更あるいは追加するものであったり、既存のパッケージから望ましくない要素を削除するものであるかもしれません。同様に求める機能や独自開発の機能を追加するのに「サードパーティ製」パッケージを利用できます。

450

この節では変更したパッケージのビルドや保守については対象としていません。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 新メンテナーガイドその他で説明されています。

451

変更した独自のパッケージをインストールする方法は2つあります:

452

packages.chroot

453

独自APTリポジトリの利用

454

packages.chroot を使う方法はより簡単に出来て「一度限りの」独自化には有用ですが欠点がいくつかあります。一方独自のAPTリポジトリを使う方法はその準備に時間がかかりまます。

455

8.3.1 packages.chroot を利用した独自のパッケージのインストール

456

独自化したパッケージをインストールするには、単に#{config/packages.chroot/}# ディレクトリにコピーします。このディレクトリ内に置かれたパッケージはビルドの際に Live システムに自動的にインストールされます - 他のどこかを指定する必要はありません。

457

パッケージ名は規定の命名規則に従わ*{ないといけません}*。それを簡単に行う方法は dpkg-name の利用です。

458

packages.chroot を利用した独自のパッケージのインストールには欠点があります:

459

secure APT を利用することができません。

460

config/packages.chroot/ ディレクトリに適切なパッケージを全てインストールしないといけません。

461

Live システムの設定をリビジョン管理するには適しません。

462

8.3.2 APTリポジトリを利用した独自パッケージのインストール

463

packages.chroot を使う場合とは異なり、独自のAPTリポジトリを使う場合は他のどこかでパッケージを指定する必要があります。詳細については インストールするパッケージの選択 を見てください。

464

独自のパッケージをインストールするためにAPTリポジトリを作成するのは不要な手間だと思うかもしれませんが、その基盤は変更したパッケージを後で更新する際に簡単に再利用できます。

465

8.3.3 独自パッケージとAPT

466

live-build は Live システムへのパッケージのインストールに全てAPTを利用するため、そのプログラムの挙動を引き継ぎます。関連する一例としては (デフォルト設定だと仮定して)、異なる2つのリポジトリでバージョン番号の異なるあるパッケージが利用可能な場合に、APTはバージョン番号の大きい方のパッケージをインストールに選択します。

467

そのため、独自パッケージの debian/changeLog ファイルでバージョン番号を増加させ、公式の Debian リポジトリにあるものよりも変更したバージョンが確実にインストールされるようにすると良いでしょう。Live システムのAPTのピン設定を改変する方法もあります - さらなる情報については、 APTのピン止め を見てください。

468

8.4 ビルド時のAPT設定

469

ビルド時だけに適用されるオプションを使ってAPTを設定できます (実行中の Live システムで利用されるAPTの設定は Live システムの内容による通常の、config/includes.chroot/ で適切な設定を収録する) 方法により設定できます。オプションの全容については lb_config man ページの apt で始まるオプションを見てください。

470

8.4.1 apt と aptitude の選択

471

ビルド時にパッケージをインストールする際に apt と aptitude のどちらを利用するのか選択できます。利用するユーティリティは lb config の --apt 引数で決定します。パッケージが欠けている場合の処理方法に顕著な違いがあることに着目し、パッケージのインストール時に望ましい挙動を実装している方を選択してください。

472

apt: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは失敗します。これはデフォルトの設定です。

473

aptitude: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは成功します。

474

8.4.2 APTでのプロキシの利用

475

よく要求されるAPTの設定として、プロキシの内側でのイメージのビルドへの対応があります。必要に応じて、--apt-ftp-proxy や --apt-http-proxy オプションによりAPTプロキシを指定できます。例:

476

$ lb config --apt-http-proxy http://proxy/

477

8.4.3 APTの調整による容量節約

478

イメージのメディアの容量をいくらか節約する必要があるかもしれません。その場合は以下に挙げるオプションを利用するといいかもしれません。

479

APTの索引をイメージに収録したくない場合は除外できます:

480

$ lb config --apt-indices false

481

これは /etc/apt/sources.list 内の項目には影響せず、単に /var/lib/apt に索引ファイルを収録するかどうかだけに影響します。その代わりに、Live システムでAPTを操作するためにはこの索引が必要なので、apt-cache search や apt-get install を実行する前にユーザは例えば apt-get update をまず実行して索引を作成しないといけません。

482

推奨パッケージのインストールによりイメージが肥大化しているような場合、以下で説明している影響を踏まえた上でAPTのデフォルトオプションを無効にできます:

483

$ lb config --apt-recommends false

484

推奨パッケージを無効にした場合の最も重要な影響は、live-boot や live-config 自体が、ほとんどの Live 設定に利用している重要な機能を提供する一部のパッケージを推奨していることで、例えば live-config が推奨し、Live ユーザの作成に利用している user-setup があります。ほぼ例外なく、パッケージ一覧に追加しないといけないパッケージが推奨パッケージの中にいくらかあります。追加しない場合は、イメージが期待通りに動作しないということになります。 ビルドに収録されている各 live-* パッケージの推奨パッケージを確認し、省略できると確信できない場合はパッケージ一覧に当該パッケージを追加するようにしてください。

485

あるパッケージの推奨パッケージをインストールしないことによるもっと一般的な影響は「異常なインストール状態でなければあるパッケージとともにあるはずの」(Debian ポリシーマニュアル7.2節) Live システムのユーザが実際に必要とする一部のパッケージが省略されているかもしれないということです。したがって、推奨パッケージのインストールを無効にした場合とのパッケージ一覧 (lb build により生成される binary.packages ファイル参照) の違いを確認して、欠けているパッケージの中にインストールしたいものがあれば一覧に収録することを推奨しています。推奨パッケージからほんの一部を除外したい場合は、推奨パッケージのインストールは有効なままにしておき、 APTのピン止め で説明しているようにAPTのピン機能で、選択したパッケージについて負の優先度をセットしてインストールされないようにする方法があります。

486

8.4.4 apt や aptitude へのオプションの受け渡し

487

障害となるAPTの挙動を変更するための lb config オプションがない場合、--apt-options や --aptitude-options により任意のオプションを選択したAPTツールに渡せます。詳細については apt や aptitude の man ページを見てください。どちらのオプションにも、優先設定に加えて保持しておく必要のあるデフォルト値があることに注意してください。そのため、例えば snapshot.debian.org からテスト用に何か取得する場合に Acquire::Check-Valid-Until=false を指定するとAPTは古いままの Release ファイルを使い続けます。以下の例のように、デフォルト値 --yes の後に新しいオプションを付加します:

488

$ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"

489

このオプションを利用する場合は man ページを確認して完全に理解するようにしてください。これはあくまで例であり、イメージをこの方法で設定するようにという助言だと解釈することのないようにしてください。このオプションは例えば Live イメージの最終的なリリースには適しません。

490

apt.conf のオプションを利用するようなもっと複雑なAPT設定には代わりに config/apt/apt.conf ファイルを作成すると良いでしょう。少数ですが、よく必要とされるオプションへの有用なショートカットがあります。他の apt-* オプションについても参照してください。

491

8.4.5 APTのピン止め

492

背景として、apt_preferences(5) man ページをまず読んでください。APTのピン機能はビルド時用と実行時用に設定できます。前者については config/archives/*.pref、config/archives/*.pref.chroot、config/apt/preferences を、後者については config/includes.chroot/etc/apt/preferences を作成してください。

493

jessie の Live システムをビルドするとしましょう。その場合に必要な Live パッケージは全て、ビルド時にバイナリイメージを sid からインストールする必要があります。APTソースに sid を追加して、ピン機能で sid の Live パッケージには高い優先度をセットし、他のパッケージには全てデフォルトよりも低い優先度をセットする必要があります。そうするとビルド時に望むパッケージだけを sid からインストールし、他は全て対象システムのディストリビューションである jessie から取得します。以下によりその動作になります:

494

$ 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

495

別のパッケージにより推奨されたパッケージを望まない場合に、ピン機能で優先度に負の値をセットすることによりそのパッケージをインストールしないようにできます。config/package-lists/desktop.list.chroot で task-lxde-desktop を使って LXDE イメージをビルドしていて、wifi パスワードをキーリングに保存するかユーザに聞かないようにしたいと仮定しましょう。このメタパッケージは lxde-core に依存し、lxde-core は gksu を推奨し、gksu は gnome-keyring を推奨しています。そこで、推奨された gnome-keyring パッケージを除外したい場合、config/apt/preferences に以下を追加することで除外できます:

496

Package: gnome-keyring
Pin: version *
Pin-Priority: -1

497

収録内容の独自化

498

9. 収録内容の独自化

499

この章では収録するパッケージを単に選択だけにとどまらない、微調整まで含めた Live システムの収録内容の独自化について説明します。インクルードにより Live システムイメージの任意のファイルを追加、置換できるようになり、フックによりビルド時及びブート時の異なる段階で任意のコマンドを実行できるようになり、preseed が debconf の質問に対する回答を提供することでパッケージのインストール時に設定できるようになります。

500

9.1 Includes

501

理想的なのは変更されていないパッケージにより提供されるファイルを Live システムで完全に収録することではありますが、ファイルを使って内容をいくらか提供あるいは変更することが便利なこともあります。インクルードを使うと Live システムイメージ中の任意のファイルを追加 (または置換) することができるようになります。live-build ではこれを使う仕組みを2つ提供しています:

502

chroot ローカルインクルード: chroot/Live ファイルシステムに対してファイルの追加や置換ができるようになります。さらなる情報については、 Live/chroot ローカルインクルード を見てください。

503

バイナリローカルインクルード: バイナリイメージ中のファイルの追加や置換ができるようになります。さらなる情報については、 バイナリローカルインクルード を見てください。

504

「Live」及び「バイナリ」イメージの違いについてのさらなる情報は、 用語 を見てください。

505

9.1.1 Live/chroot ローカルインクルード

506

chroot ローカルインクルードを使って chroot/Live ファイルシステム中のファイルの追加や置換を行い、それを Live システムで利用することができます。代表的な使い方として Live システムで利用するユーザディレクトリ (/etc/skel) の骨格を構成させ、live ユーザのホームディレクトリを作成するということがあります。別の使い方としては設定ファイルを提供し、そのまま加工せずイメージ中に追加または置換するということがあります。加工が必要な場合は Live/chroot ローカルフック を見てください。

507

ファイルを収録するには config/includes.chroot ディレクトリに単純に追加します。このディレクトリが Live システムのルートディレクトリ / に対応します。例えば Live システムにファイル /var/www/index.html を追加する場合:

508

$ mkdir -p config/includes.chroot/var/www
$ cp /path/to/my/index.html config/includes.chroot/var/www

509

それから設定は以下の配置になっているでしょう:

510

-- config
[...]
|-- includes.chroot
| `-- var
| `-- www
| `-- index.html
[...]

511

chroot ローカルインクルードはパッケージがインストールされた後にインストールされるので、パッケージによりインストールされたファイルは上書きされます。

512

9.1.2 バイナリローカルインクルード

513

文書やビデオ等の内容をメディアのファイルシステムに収録して、メディアを差し込んで Live システムをブートしなくてもすぐにアクセスできるようにするのにバイナリローカルインクルードを使えます。これは chroot ローカルインクルードと同様の方法で動作します。例えばファイル ~/video_demo.* が Live システムの実演ビデオで、リンク先の HTML 索引ページでそれを説明しているものと仮定しましょう。単純に内容を config/includes.binary/ にコピーします:

514

$ cp ~/video_demo.* config/includes.binary/

515

これでファイルは Live メディアの最上位ディレクトリに現れます。

516

9.2 フック

517

フックではビルドの chroot 及び バイナリの段階でコマンドを実行し、イメージを独自化できます。

518

9.2.1 Live/chroot ローカルフック

519

chroot の段階でコマンドを実行するにはファイル名末尾が .hook.chroot でコマンドを収録するフックスクリプトを config/hooks/ ディレクトリに作成します。フックは残りの chroot 設定の適用後に chroot 内で実行されるため、フックの実行に必要なパッケージやファイルを全て確実に設定に収録することを忘れないようにしてください。代表的な chroot の様々な独自化タスクについて /usr/share/doc/live-build/examples/hooks で提供されている chroot フックスクリプトの例を確認してください。この例からコピーやシンボリックリンクを作成して自分の設定で使えます。

520

9.2.2 ブート時フック

521

ブート時にコマンドを実行するために man ページの「独自化」節で説明されている live-config フックを提供することができます。/lib/live/config/ で提供している live-config 独自のフックを、実行順を示す頭の番号に注意して調べてください。それから自分のフックに実行順を示す適切な番号を頭に付けて、config/includes.chroot/lib/live/config/ 内の chroot ローカルインクルードか、 変更したあるいはサードパーティのパッケージのインストール で説明している独自パッケージとして提供してください。

522

9.2.3 バイナリローカルフック

523

バイナリ段階でコマンドを実行するには、コマンドを収録するフックスクリプトを、末尾に .hook.binary を付けて config/hooks/ ディレクトリに作成します。このフックは他の binary_checksums を除いたバイナリコマンドを全て実行した後の、バイナリコマンドのほぼ最後に実行されます。フック内のコマンドは chroot 内で実行されるのではないため、ビルドツリー外のファイルを変更することのないように注意してください。変更するとビルドシステムが機能しなくなるかもしれません! 代表的なバイナリ独自化タスクについて /usr/share/doc/live-build/examples/hooks で提供されているバイナリフックスクリプトの例を確認してください。この例からコピーやシンボリックリンクを作成して自分の設定で使えます。

524

9.3 Debconf 質問の preseed

525

config/preseed/ ディレクトリにある、末尾が段階 (.chroot か .binary) に続いて .cfg で終わるファイルは debconf の preseed ファイルと見なされ、対応する段階で live-build により debconf-set-selections を使ってインストールされます。

526

debconf のさらなる情報については、debconf パッケージの debconf(7) を見てください。

527

実行時の挙動の独自化

528

10. 実行時の挙動の独自化

529

実行時に行われる設定は全て live-config により行われます。ユーザが関心を持つであろう live-config の最も一般的なオプションから一部を説明します。オプションの全容は live-config の man ページにあります。

530

10.1 live ユーザの独自化

531

重要な検討事項が1つあり、live ユーザはブート時に live-boot により作成され、ビルド時に live-build により作成されるのではないということです。この影響は Live/chroot ローカルインクルード で説明しているように、ビルドで live ユーザに関連する内容が導入されるところだけにはとどまらず、live ユーザに関連するグループや権限にも影響します。

532

live-config を設定できる複数の方法で live ユーザの所属する追加のグループを指定できます。例えば live ユーザを fuse グループに追加するには config/includes.chroot/etc/live/config/user-setup.conf ファイルに

533

LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse"

534

を追加するかブートパラメータとして live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse と指定します。

535

デフォルトのユーザ名「user」やデフォルトのパスワード「live」を変更することもできます。何らかの理由で変更したい場合は以下のようにして簡単に変更できます:

536

デフォルトのユーザ名を変更するには単に設定で指定します:

537

$ lb config --bootappend-live "boot=live components username=live-user"

538

デフォルトのパスワードを変更できる1つの方法は ブート時フック で説明しているフックを使います。そのためには /usr/share/doc/live-config/examples/hooks から「passwd」を使い、適当な名前 (例えば 2000-passwd) で保存してそれを config/includes.chroot/lib/live/config/ に追加します。

539

10.2 ロケールと言語の独自化

540

Live システムがブートする際、2つの段階で言語が関わってきます:

541

ロケール生成

542

キーボードの設定

543

Live システムをビルドする際のデフォルトのロケールは locales=en_US.UTF-8 となっています。生成したいロケールの定義には lb config の --bootappend-live オプションで locales パラメータを指定します。例えば

544

$ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8"

545

ロケールをコンマで区切って複数指定することもできます。

546

このパラメータも以下に示すキーボード設定用パラメータと同様にカーネルコマンドラインで指定できます。ロケールは 言語_国 (デフォルトのエンコーディングを使う場合) または完全な 言語_国.エンコーディング の形式で指定できます。サポートしているロケールやそれぞれで利用されるエンコーディングの一覧は /usr/share/i18n/SUPPORTED にあります。

547

コンソールとXキーボードの設定はどちらも live-config により console-setup パッケージを使って行われます。設定には --bootappend-live オプション経由で keyboard-layouts、keyboard-variants、keyboard-options、keyboard-model ブートパラメータを利用します。それぞれの有効なオプションは /usr/share/X11/xkb/rules/base.lst にあります。ある言語向けのレイアウトや配列を見つけるには、その言語の英語名やその言語が話されている国を検索してみてください。例:

548

$ 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

549

それぞれの配列の説明に、適合するレイアウトが示されていることに注意してください。

550

レイアウトだけを設定する必要があることはよくあります。例えばXで利用するドイツ語のロケールファイル及びスイスのドイツ語のキーボードレイアウトを利用する場合:

551

$ lb config --bootappend-live "boot=live components locales=de_CH.UTF-8 keyboard-layouts=ch"

552

非常に具体的な事例ですが他のパラメータを同時に指定することもできます。例えばフランス語のシステムを用意して TypeMatrix EZ-Reach 2030 USB キーボードで (Bepo と呼ばれる) フランス語用の Dvorak 配置を使う場合:

553

$ lb config --bootappend-live \
"boot=live components locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb"

554

値を1つだけ受け付ける keyboard-model は例外ですが、他の keyboard-* オプションではそれぞれに値をコンマで区切って複数指定することもできます。XKBMODEL や XKBLAYOUT、XKBVARIANT、XKBOPTIONS 変数の詳細や例については keyboard(5) man ページを見てください。keyboard-variants に複数の値を指定した場合、1つずつ keyboard-layouts の値 (setxkbmap(1) の -variant オプション参照) との照合が行われます。空白の値も使えます。例えばデフォルトとして米国向けの QWERTY、それとは別に米国向けの Dvorak、の2つの配列を指定する場合:

555

$ lb config --bootappend-live \
"boot=live components keyboard-layouts=us,us keyboard-variants=,dvorak"

556

10.3 保持機能

557

典型的なライブCDというものは CD-ROM 等の読み取り専用メディアから起動するインストール済みシステムで、書き込みや変更は起動したホストハードウェアの再起動により消え去ります。

558

Live システムはそれを一般化したものであり、CD以外のメディアもサポートしますが、デフォルトの挙動としては読み取り専用であり、そのシステムで実行時に行ったことは全てシャットダウンにより失われるものだと考えるべきです。

559

「保持機能」というのは、実行時にシステムに行ったことの一部あるいは全てを保存し、リブート後に引き継ぐための様々な策の共通の呼び名です。それが機能する仕組みを理解するためには、読み取り専用メディアからブート、実行している場合でもファイルやディレクトリへの変更が書き込み可能メディア、標準的にはRAMディスク (tmpfs) に書かれ、RAMディスクのデータはリブート後には残らないのだ、ということを知っておくと良いでしょう。

560

このRAMディスクに保存されるデータは、ローカルストレージメディアやネットワーク共有、あるいはマルチセッションで (再)書き込み可能な CD/DVD のセッション等の書き込み可能な保持用メディアに保存する必要があります。こういったメディアは Live システムで様々な方法でサポートされています。また、特別なブートパラメータ persistence をブート時に指定する必要があるということも重要です。

561

ブートパラメータ persistence がセットされている (と同時に nopersistence がセットされていない) 場合、保持用ボリューム用のローカルストレージメディア (例えばハードディスクやUSBドライブ) がブート中に調査されます。live-boot(7) man ページで説明している特定のブートパラメータを指定することにより、利用する保持用ボリュームの種類を制限できます。保持用ボリュームは以下のどれかになります:

562

GPT名により識別されるパーティション

563

ファイルシステムラベルにより識別されるファイルシステム

564

読み取り可能な任意のファイルシステム (異質のOSの NTFS パーティションも利用可) の最上位に置かれている、ファイル名により識別されるイメージファイル

565

オーバーレイ用のボリュームラベルは persistence でないといけません。さらにその最上位に、ボリュームの保持を完全に制御するのに利用する persistence.conf というファイルが置かれていない限り無視されます。これは言うに及ばず、リブート後に保持用ボリュームに保存する対象となるディレクトリを指定します。さらなる詳細については persistence.conf ファイル を見てください。

566

保持用に利用するボリュームを用意する方法についていくつか例を示します。これは例えばハードディスクやUSBメモリに例えば

567

# mkfs.ext4 -L persistence /dev/sdb1

568

により作成した ext4 パーティションを利用できます。 USBメモリの空きスペースの利用 も見てください。

569

デバイスに既存のパーティションがある場合は以下に示すどれかによりラベルを変更するだけで準備は終わりです:

570

# tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems

571

保持用に利用する ext4 ベースのイメージファイルの作成例:

572

$ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F persistence

573

イメージファイル作成後、例えば /usr を保持させる場合に、保存するのはディレクトリに対する変更だけで、/usr の内容を丸ごと保存したいわけではない、という場合、「union」オプションを利用できます。イメージファイルがホームディレクトリに置かれている場合はハードドライブのファイルシステム最上位にコピーして /mnt にマウントします:

574

# cp persistence /
# mount -t ext4 /persistence /mnt

575

それから、内容を追加する persistence.conf ファイルを作成してイメージファイルのマウントを解除します。

576

# echo "/usr union" >> /mnt/persistence.conf
# umount /mnt

577

ブートパラメータ「persistence」を指定して Live メディアでリブートします。

578

10.3.1 persistence.conf ファイル

579

persistence のラベルを付けられたボリュームは persistence.conf ファイルを使って、任意のディレクトリを保持するように設定します。ボリュームのファイルシステム最上位に置かれているこのファイルは保持するディレクトリや方法を制御します。

580

独自のオーバーレイマウントの設定方法は persistence.conf(5) man ページで詳細に説明されていますが、ほとんどの場合簡単な例で十分なはずです。/dev/sdb1 パーティションの ext4 ファイルシステムにホームディレクトリとAPTキャッシュを保持させる場合:

581

# 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

582

それからリブートします。最初のブート中に /home と /var/cache/apt の内容が保持用ボリュームにコピーされ、以後のこのディレクトリへの変更は全て保持用ボリュームに残ります。persistence.conf ファイルに列挙するパスには空白文字や特別なパス構成要素 . and .. を含めることは一切できないことに注意してください。また、/lib や /lib/live (はそのサブディレクトリを含めて)、/ は独自マウントを使って保持させることができません。この制約の回避策として、persistence.conf ファイルに / union を追加すると完全な保持を実現できます。

583

10.3.2 保持先を複数使いたい場合

584

複数の保存先を使う方法は複数あります。目的の明確な例として、複数のボリュームを同時に使う場合と1つだけを選択して使う場合を取り上げます。

585

異なる (個別の persistence.conf ファイルを利用する) 独自オーバーレイボリュームを複数同時に利用できますが、同一のディレクトリを保持させる設定のボリュームが複数ある場合はその中から1つだけが利用されます。ある2つのマウントが「入り組んでいる」(つまり他にマウントしたディレクトリ以下のサブディレクトリとしてマウントする) ような場合には子孫側ディレクトリよりも前に親側ディレクトリがマウントされるため、他のマウントにより見えなくなるマウントは発生しません。入り組んでいる独自マウントが同一の persistence.conf ファイルで指定されている場合は問題があります。そういった状況が実際に必要な場合の処理方法については persistence.conf(5) man ページを見てください (ヒント: 通常は必要ありません)。

586

ありそうな事例: ユーザデータ、つまり /home とスーパーユーザのデータ、つまり /root を異なるパーティションに保存するため persistence ラベルの付いたパーティションを2つ作成し、それぞれに persistence.conf ファイルを1つはユーザのファイルを保存する最初のパーティション向けに # echo "/home" > persistence.conf、もう1つはスーパーユーザのファイルを保存する2つ目のパーティション向けに # echo "/root" > persistence.conf として作成します。最後に、ブートパラメータとして persistence を使います。

587

別の位置やテストのために例えば private と work のようにして同一の種類で複数の保持先が必要な場合、ブートパラメータ persistence と合わせてブートパラメータ persistence-label を使うと、複数でそれぞれ一意となる保持用メディアを使えるようになります。例として、ブラウザのブックマークその他の個人用データ用に private のラベルを付けられた保持用パーティションを使いたい場合、ブートパラメータとして persistence persistence-label=private を使います。そして文書や研究プロジェクトその他の仕事関係のデータ用にはブートパラメータとして persistence persistence-label=work を使います。

588

各ボリューム private 及び work にはそれぞれ最上位に persistence.conf ファイルが必要だということは重要ですので覚えておいてください。古い名前でこういったラベルを使う方法についてさらなる情報が live-boot man ページにあります。

589

10.4 暗号化した保持先の利用

590

保持機能を使うことには重要なデータが漏洩する危険がいくらか存在します。特に保持するデータがUSBメモリや外付ハードドライブ等のポータブル機器に保存される場合は。そういった場合には暗号化が便利です。手順が多いために全体として複雑に見えるかもしれませんが、live-boot で暗号化したパーティションを扱うのは実際には簡単です。サポートしている luks という種類の暗号化を利用するためには、暗号化したパーティションを作成する側と暗号化した保持用パーティションを利用する Live システムの両方のマシンに cryptsetup をインストールする必要があります。

591

マシンへの cryptsetup のインストール:

592

# apt-get install cryptsetup

593

Live システムに cryptsetup をインストールするには、パッケージ一覧に追加します:

594

$ lb config
$ echo "cryptsetup" > config/package-lists/encryption.list.chroot

595

cryptsetup を備えた Live システムが出来たら、基本的に必要なのは新しいパーティションを作成して暗号化し、persistence と persistence-encryption=luks パラメータを指定してブートするだけです。既にこの段階を予測し、通常の手順に沿ったブートパラメータを追加してあります:

596

$ lb config --bootappend-live "boot=live components persistence persistence-encryption=luks"

597

暗号化についてよく理解していない人たちのために詳細を見て行きましょう。以下の例では /dev/sdc2 に対応するUSBメモリ上のパーティションを利用します。自分で使う際にはどのパーティションになるのか判断する必要があることに注意してください。

598

最初の段階はUSBメモリを接続してそれがどのデバイスになるのか判断することです。live-manual で推奨するデバイス一覧方法では ls -l /dev/disk/by-id を使います。それから新しいパーティションを作成、さらにパスフレーズを使って暗号化します:

599

# cryptsetup --verify-passphrase luksFormat /dev/sdc2

600

仮想デバイスマッパーから luks パーティションを開きます。好きな名前を使ってください。ここでは例として live を使います:

601

# cryptsetup luksOpen /dev/sdc2 live

602

次の段階はファイルシステムを作成する前にデバイスをゼロで埋めることです:

603

# dd if=/dev/zero of=/dev/mapper/live

604

これでファイルシステムを作成する準備ができました。ラベル persistence の指定を追加しているためこのデバイスはブート時に保持用としてマウントされるということに注意してください。

605

# mkfs.ext4 -L persistence /dev/mapper/live

606

準備を続けるにはデバイスをマウントする必要があります。例として /mnt にマウントします。

607

# mount /dev/mapper/live /mnt

608

そしてパーティション最上位に persistence.conf ファイルを作成します。これは前に説明したように必ず必要です。 persistence.conf ファイル を見てください。

609

# echo "/ union" > /mnt/persistence.conf

610

それからマウントポイントのマウントを解除します:

611

# umount /mnt

612

オプションですがパーティションに追加したばかりのデータを安全にしておくと良いでしょう。デバイスを閉じます:

613

# cryptsetup luksClose live

614

手順をまとめます。これまでに、暗号化を有効化した Live システムを作成しました。これは ISO hybrid イメージのUSBメモリへのコピー で説明しているようにUSBメモリにコピーできます。暗号化したパーティションも作成しました。これは同一のUSBメモリに置いて持ち運べます。保持先として利用する暗号化パーティションを設定しました。あと必要なのは Live システムをブートするだけです。ブート時に live-boot は保持用として利用する暗号化したパーティションのパスフレーズを質問し、マウントします。

615

バイナリイメージの独自化

616

11. バイナリイメージの独自化

617

11.1 ブートローダ

618

live-build は syslinux や (イメージの種類により) その派生物の一部をブートローダとしてデフォルトで利用します。これは要件に合わせて簡単に独自化できます。

619

全面的なテーマを使うには /usr/share/live/build/bootloaders を config/bootloaders にコピーしてその中のファイルを編集します。サポートしているブートローダ全部の設定変更を望まない場合は、ブートローダの1つ、例えば config/bootloaders/isolinux にある isolinux だけを局所的に地域化したものを提供するのでも、活用方法によりますが十分です。

620

のようになります。デフォルトのテーマを変更してブートメニューとともに表示される背景画像に個別のものを使いたい場合は 640x480 ピクセルの画像を splash.png というファイル名で追加し、splash.svg ファイルを削除します。

621

変更を加えるに至る要因は多々あります。例えば syslinux 派生物ではデフォルトでタイムアウト時間が0に設定されていて、この場合はスプラッシュ画面でキーが押されるまでいつまでも一時停止状態で止まっているということになります。

622

デフォルトの iso-hybrid イメージのブート時のタイムアウト時間を変更する方法は、デフォルトの isolinux.cfg ファイルを編集して1/10秒単位でタイムアウト時間を指定するだけです。5秒後にブートするように isolinux.cfg を変更する場合は

623

include menu.cfg
default vesamenu.c32
prompt 0
timeout 50

624

11.2 ISO メタ情報

625

ISO9660 バイナリイメージの作成時に以下のオプションを使って、テキストの様々なメタ情報をイメージに追加できます。これはイメージのバージョンや設定をブートせずに簡単に識別する手助けとなります。

626

LB_ISO_APPLICATION/--iso-application NAME: これにはイメージ上に置かれる、アプリケーションの説明を記述します。最大長は128文字です。

627

LB_ISO_PREPARER/--iso-preparer NAME: これはイメージの作成者を説明し、通常連絡先の詳細をいくらか含めます。このオプションのデフォルト値は作成に利用した live-build のバージョンで、後でデバッグするときに手がかりとなることを意図しています。最大長は128文字です。

628

LB_ISO_PUBLISHER/--iso-publisher NAME: これはイメージの発行者を説明し、通常連絡先の詳細をいくらか含めます。最大長は128文字です。

629

LB_ISO_VOLUME/--iso-volume NAME: これはイメージのボリュームIDを指定します。Windows や Apple Mac OS 等一部のプラットフォームではユーザから見えるラベルとして利用されます。最大長は32文字です。

630

Debian インストーラの独自化

631

12. Debian インストーラの独自化

632

Live システムのイメージは Debian インストーラと統合できます。インストールには収録内容やインストーラの動作方法によりいくつもの異なる種類があります。

633

この節で「Debian インストーラ」と大文字を使った表記で参照しているところに注意してください - この表記の場合には公式の Debian システム用インストーラを明示的に指していて、他の何かではありません。「d-i」と短縮することもよくあります。

634

12.1 Debian インストーラの種類

635

インストーラの主な3つの種類:

636

「通常の」Debian インストーラ: これは通常の Live システムのイメージで、(適切なブートローダからそれを選択した場合に) Debian のCDイメージをダウンロードしてそれをブートしたのと同様に標準の Debian インストーラを起動するための別個のカーネルと initrd を収録しています。Live システムとこういった別個の独立したインストーラを収録するイメージはよく「複合イメージ」と呼ばれます。

637

こういったイメージでは、debootstrap を使ってローカルメディアやネットワークから .deb パッケージを取得、インストールすることで Debian がインストールされます。結果としてはデフォルトの Debian システムがハードディスクにインストールされます。

638

このプロセス全体で、いくつもの方法で preseed を使って独自化できます。さらなる情報については Debian インストーラマニュアルの関連するページを見てください。機能する preseed ファイルが得られたら live-build が自動的にイメージに取り込んで使えるようになります。

639

「Live」Debian インストーラ: これは Live システムイメージで、(適切なブートローダからそれを選択した場合に) Debian インストーラを起動するための別個のカーネルと initrd を収録しています。

640

インストールは上記で説明した「通常の」インストールと全く同じように進みますが、実際にパッケージをインストールする段階で、debootstrap を使ってパッケージを取得、インストールする代わりに、Live ファイルシステムのイメージを対象にコピーします。これは live-installer という特別な udeb により行っています。

641

この段階の後は、Debian インストーラはインストールや、ブートローダやローカルユーザ等の設定を通常どおり続けます。

642

注意: 一つの Live メディアのブートローダの項目で通常のインストーラと Live インストーラの両方に対応するには、live-installer/enable=false という preseed により live-installer を無効化する必要があります。

643

「デスクトップ」Debian インストーラ: 収録する Debian インストーラの種類を問わず、デスクトップからアイコンをクリックすることで d-i を起動できます。状況によってはこちらの方がユーザからわかりやすいこともあります。これを使えるようにするには debian-installer-launcher パッケージを収録する必要があります。

644

live-build は Debian インストーラのイメージをデフォルトではイメージに収録しないことに注意してください。lb config により具体的に有効化する必要があります。さらに、「デスクトップ」インストーラが機能するようにするには Live システムのカーネルが指定されたアーキテクチャで d-i が利用するカーネルと一致する必要があることに注意してください。例えば:

645

$ lb config --architectures i386 --linux-flavours 486 \
--debian-installer live
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot

646

12.2 preseed による Debian インストーラの独自化

647

<https://www.debian.org/releases/stable/i386/apb.html> にある Debian インストーラマニュアルの付録Bで説明されていますが「preseed は、インストールの実行中に手作業により回答を入力せずに、インストールプロセス中の質問の回答を設定する方法を提供します。これにより、ほとんどの方法のインストールを完全に自動化し、さらに通常のインストールでは利用できない特徴もあります」。この種の独自化は live-build を使って設定を preseed.cfg ファイルに書き、config/includes.installer/ に置くことで最も完成させることができます。例えばロケールを en_US に設定する preseed は:

648

$ echo "d-i debian-installer/locale string en_US" \
>> config/includes.installer/preseed.cfg

649

12.3 Debian インストーラの収録内容の独自化

650

実験やデバッグの目的で、ローカルでビルドした d-i の一部である udeb パッケージを収録したいことがあるかもしれません。config/packages.binary/ にそれを配置してイメージに収録します。 Live/chroot ローカルインクルード と同じ方法で内容を config/includes.installer/ に置くことで、追加または置換するファイルやディレクトリを同様にインストーラの initrd に収録することもできます。

651

プロジェクト

652

プロジェクトへの貢献

653

13. プロジェクトへの貢献

654

貢献物の提出にあたっては著作権者を明確に識別し、適用するライセンス文を収録してください。受け入れられるためには、その貢献物はその文書の他の部分と同一の、GPL バージョン 3 以降というライセンスを採用する必要があることに注意してください。

655

翻訳やパッチといったプロジェクトへの貢献は大いに歓迎します。誰もがリポジトリに直接コミットできますが、大きな変更についてはまずメーリングリストに送って議論するようお願いします。さらなる情報については 連絡先 節を見てください。

656

Live システムプロジェクトではGitをソースコード管理用のバージョン管理システムとして利用しています。 Gitリポジトリ で説明しているように、開発用ブランチは debian と debian-next の2つあります。debian-next ブランチの live-boot、live-build、live-config、live-images、live-manual、live-tools リポジトリには誰でもコミットできます。

657

ただし、特定の制限があります。サーバは

658

fast-forward ではないプッシュ

659

マージコミット

660

タグやブランチの追加や削除

661

を拒否します。あらゆるコミットを訂正できるとはいえ、自分の常識に従って、良いコミットメッセージを使って良いコミットを行うようお願いします。

662

完結した、有意な文で構成されるコミットメッセージを英語で書き、大文字から始めて句点で終えるようにしてください。通常、「Fixing/Adding/Removing/Correcting/Translating/...」のようなものから開始します。

663

良いコミットメッセージを書いてください。先頭行はそのコミットの内容を正確にまとめるようにしてください。これは changelog に収録されることになります。何か説明がさらに必要であれば、先頭行の後に1行空けてから書き、各段落の後には新たな空行を空けてください。段落の行の長さは80文字を超えないようにしてください。

664

コミットは小分けにしてください。これは関係のないものをまとめてコミットしないようにということです。各変更ごとに別個にコミットするようにしてください。

665

13.1 変更を加える

666

リポジトリに送るには、以下の手順に従う必要があります。ここでは live-manual を例として使うのでそれは作業したいリポジトリに置き換えてください。live-manual を変更する方法に関する詳細な情報については この文書への貢献 を見てください。

667

公開コミットキーを取得します:

668

$ 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*

669

openssh-client の設定に以下を追記します:

670

$ cat >> ~/.ssh/config << EOF
Host live-systems.org
Hostname live-systems.org
User git
IdentitiesOnly yes
IdentityFile ~/.ssh/keys/git@live-systems.org
EOF

671

ssh 経由で live-manual の複製を取得します:

672

$ git clone git@live-systems.org:/live-manual.git
$ cd live-manual && git checkout debian-next

673

Gitで作者とメールをセットしたことを確認してください:

674

$ git config user.name "John Doe"
$ git config user.email john@example.org

675

重要: 変更はどれも debian-next ブランチにコミットする必要があるということを忘れないでください

676

変更を加えます。この例ではまずパッチの適用を扱う新しい節を書き、ファイルの追加をコミットする下準備をしてコミットメッセージを

677

$ git commit -a -m "Adding a section on applying patches."

678

のように書いてサーバにコミットを送ります:

679

$ git push

680

バグの報告

681

14. バグの報告

682

Live システムは完璧にはほど遠いですが、可能な限り完璧に近づけたいと思っています - あなたの支援とともに。バグの報告を躊躇わないでください。バグがあるのに報告されないよりも二重に報告される方がいいからです。この章ではバグ報告を提出するにあたっての推奨事項について説明します。

683

せっかちな人向け:

684

常にまず <http://live-systems.org/> にある私達のホームページにあるイメージの更新状況により既知の問題を確認してください。

685

バグ報告を提出する前に使用している live-build、live-boot、live-config、live-tools のブランチの*{最新版}* (live-build 4 を使っているなら最新のバージョン 4.x の live-build) でそのバグを再現できるか常に確認します。

686

バグについて*{できるだけ具体的な情報}*を提示するようにしてください。これには (最低限) 利用した live-build、live-boot、live-config、live-tools のバージョンや Live システムをどのディストリビューションでビルドしたのか、等があります。

687

14.1 既知の問題

688

Debian テスト版 (testing) と Debian 不安定版 (unstable) ディストリビューションは変化しているのでこのどちらかを対象システムディストリビューションに指定している場合、ビルドが常に成功するとは限りません。

689

そのためにあまり困難になる場合はビルドに*{テスト版 (testing)}* や*{不安定版 (unstable)}* をベースにしたシステムではなく*{安定版 (stable)} を使ってください。live-build は常に*{安定版 (stable)}* リリースをデフォルトとしています。

690

現在わかっている問題は <http://live-systems.org/> にある私達のホームページの「status」に一覧があります。

691

開発用ディストリビューションのパッケージにある問題を正しく識別、修正するための訓練はこのマニュアルの目的ではありませんが、常に確認できることが2つあります: テスト版 (testing) を対象ディストリビューションとしてビルドに失敗した場合に*{不安定版 (unstable)}* で試してみるということです。不安定版 (unstable) でもダメな場合は*{テスト版 (testing)}* に差し戻し、失敗しているパッケージのもっと新しいバージョンを*{不安定版 (unstable)}* から利用するようにしてみます (詳細については APTのPIN設定 参照)。

692

14.2 最初から再ビルド

693

きれいではない環境でシステムがビルドされたことにより特定のバグが発生しているのではないことを保証するため、Live システム全体を最初から再ビルドして、そのバグが再現するか常に確認してください。

694

14.3 最新のパッケージを使う

695

問題を再現 (最終的には修正) しようとするときに古くなったパッケージを使用すると重大な問題を引き起こす可能性があります。ビルドシステムが最新であること、同様にそのイメージに収録されているパッケージがどれも最新であることを確認してください。

696

14.4 情報収集

697

報告では十分な情報を提供してください。最低でもそのバグが発生した live-build の正確なバージョンとそれを再現する手順を含めてください。常識的に考えて問題解決の支援になりそうだと思う関連情報が何か他にあればそれも提供してください。

698

バグ報告を最大限に活用するため、最低限次の情報が必要です:

699

ホストシステムのアーキテクチャ

700

ホストシステムのディストリビューション

701

ホストシステムの live-build のバージョン

702

ホストシステムの Python のバージョン

703

ホストシステムの debootstrap や cdebootstrap のバージョン

704

Live システムのアーキテクチャ

705

Live システムのディストリビューション

706

Live システムの live-boot のバージョン

707

Live システムの live-config のバージョン

708

Live システムの live-tools のバージョン

709

tee コマンドを使ってビルドプロセスのログを生成することができます。auto/build スクリプトによりこれを自動的に行うことを推奨します (詳細は 設定管理 参照)。

710

# lb build 2>&1 | tee build.log

711

ブート時に、live-boot と live-config はログファイルを /var/log/live/ に保存します。エラーメッセージはここを確認してください。

712

さらに、他のエラーを除外するため、config/ ディレクトリを tar でまとめてどこかにアップロードするのは常に良い方法です (メーリングリストに添付として送ら*{ないでください}*)。それにより、そのエラーの再現を試みることが可能になります。それが (例えばサイズの問題により) 困難な場合は lb config --dump の出力を使ってください。これは設定ツリーのまとめです (つまり config/ のサブディレクトリにあるファイル一覧を列挙しますがファイル自体は収録しません)。

713

ログは全て英語のロケール設定で生成されたものを提示することを忘れないでください。例えば先頭に LC_ALL=C や LC_ALL=en_US を付けて live-build コマンドを実行してください。

714

14.5 可能であれば失敗している状況を分離する

715

可能であれば失敗している状況を可能な限りうまくいかなくなる最小の変更に分離してください。これは常に簡単だとは限らないので、報告の際にできないようであれば気にする必要はありません。しかし、開発サイクルを向上させたい場合、繰り返しのたびに変更する量を十分に小さくすると、実際の設定により近く、より単純な「ベース」設定を構成することによりうまくいかなくなる追加の変更点だけに問題を分離することができるかもしれません。どの変更によりうまくいかなくなっているのか区別するのに苦労している場合、それぞれの変更点が多すぎることが考えられ、その場合開発の進行は緩くなるはずです。

716

14.6 正しいパッケージに対してバグを報告する

717

どの構成要素がそのバグの原因なのかわからない、あるいはそのバグが Live システム全般に関係するバグである場合は debian-live 疑似パッケージに対するバグとして報告してください。

718

とはいうものの、バグの現れ方を元にその範囲を限定してくれると助かります。

719

14.6.1 ビルド時のパッケージ収集中

720

live-build は最初に debootstrap または cdebootstrap で Debian システムの基本的なパッケージを収集します。利用したパッケージ収集ツールやパッケージを収集した Debian ディストリビューションによっては失敗するかもしれません。バグがここで起きていると思われる場合は、そのエラーが特定の Debian パッケージに (ほとんどの場合こちらです) 関連するのか、パッケージ収集ツール自体に関連するものなのか確認してください。

721

どちらの場合でも、これは Live システムではなく Debian 自体のバグで、恐らく私達が直接修正することはできません。こういったバグはパッケージ収集ツールまたは失敗しているパッケージに対して報告してください。

722

14.6.2 ビルド時のパッケージインストール中

723

live-build は追加のパッケージを Debian アーカイブからインストールしているため、利用する Debian ディストリビューションとその日のアーカイブの状態によっては失敗するかもしれません。バグがここで起きていると思われる場合は、そのエラーが通常のシステムで再現できるか確認してください。

724

通常のシステムで再現できる場合これは Live システムではなく Debian のバグです - 失敗しているパッケージに対して報告してください。Live システムのビルドとは別に debootstrap を実行、あるいは lbbootstrap --debug を実行するとさらなる情報を得られるでしょう。

725

また、ローカルミラーやプロキシの類を使っていて問題が起きている場合はまず、公式ミラーからパッケージを収集した場合に再現するか常に確認してください。

726

14.6.3 ブート時

727

イメージがブートしない場合は 情報収集 で指定している情報を添えてメーリングリストに報告してください。そのイメージが正確にどのように/どの段階で失敗しているのか、仮想化を使っているのか実際のハードウェアなのか、ということについて忘れずに言及してください。何らかの仮想化技術を使っている場合はバグを報告する前に常に実際のハードウェアで実行してください。失敗しているときのスクリーンショットを提供することも、とても参考になります。

728

14.6.4 実行時

729

パッケージのインストールには成功したけれども Live システムを実際に実行している間に何か失敗している場合、これは恐らく Live システムのバグです。その場合:

730

14.7 調査してください

731

バグを報告する前に、問題の症状やそのエラーメッセージについてウェブを検索してください。その問題に遭っているのがあなた一人だけだという可能性は非常に低いからです。他のどこかで議題に上り、解決できそうな方法やパッチ、回避策が提案されている可能性は常にあります。

732

Live システムのメーリングリストや同様にホームページには。最新の情報がある可能性があるので、特に注意を払ってください。そういった情報が存在する場合は、バグ報告で常に参照するようにしてください。

733

さらに、似たことが既に報告されていないか live-build、live-boot、live-config、live-tools の現在のバグ一覧を確認してください。

734

14.8 バグの報告先

735

Live システムプロジェクトではバグ追跡システム (BTS) に報告されたバグを全て追跡しています。このシステムの使い方についての情報は <https://bugs.debian.org/> を見てください。reportbug パッケージの同名コマンドを使ってバグを報告することもできます。

736

一般的に、ビルド時のエラーは live-build に、ブート時のエラーは live-boot に、実行時のエラーは live-config パッケージに対して報告してください。どのパッケージが適切なのかよくわからない、あるいはバグの報告前にもっと支援が必要だという場合は debian-live 疑似パッケージに対して報告してください。その場合は私達が調べて適切なものに割り当てし直します。

737

(Ubuntu その他の) Debian 派生ディストリビューションで見つかったバグは、それが公式の Debian パッケージを使っている Debian システムでも再現するものでない限り、Debian BTS に報告すべきでは*{ない}*ことに注意してください。

738

コーディングスタイル

739

15. コーディングスタイル

740

この章では Live システムで利用されているコーディングスタイルについて述べます。

741

15.1 互換性

742

Bash シェル固有の書式や記号を使わないでください。例えば配列構造の利用など

743

POSIX のサブセットだけを使ってください - 例えば `foo` よりも $(foo) を使ってください。

744

'sh -n' と 'checkbashisms' によりスクリプトをチェックできます。

745

シェルコードが全て確実に 'set -e' で動作するようにしてください。

746

15.2 インデント

747

常にスペースよりもタブを使います。

748

15.3 改行

749

通常、行は最大で80文字までです。

750

「Linux 式」で改行します:

751

悪い例:

752

if foo; then
bar
fi

753

良い例:

754

if foo
then
bar
fi

755

関数についても同様です:

756

悪い例:

757

Foo () {
bar
}

758

良い例:

759

Foo ()
{
bar
}

760

15.4 変数

761

変数は常に大文字です。

762

live-build で利用する変数は先頭を常に LB_ で始めます。

763

live-build 内部の一時変数は _LB_ で始めます。

764

live-build のローカル変数は __LB_ で始めます。

765

live-config 中のブートパラメータにつながる変数は LIVE_ で始めます。

766

live-config 中の他の変数は全て _ で始めます。

767

変数は大括弧「{}」で囲みます。例えば $FOO ではなく ${FOO} とします。

768

空白文字の可能性を考慮し、常に引用符を使って変数を保護します: ${FOO} ではなく "${FOO}" とします。

769

一貫性を保つため、変数に値を割り当てるときは常に引用符を使います:

770

悪い例:

771

FOO=bar

772

良い例:

773

FOO="bar"

774

複数の変数を使うときは表現全体を引用符で囲みます:

775

悪い例:

776

if [ -f "${FOO}"/foo/"${BAR}"/bar ]
then
foobar
fi

777

良い例:

778

if [ -f "${FOO}/foo/${BAR}/bar" ]
then
foobar
fi

779

15.5 その他

780

sed を呼び出すときは区切り文字に「|」を使います。例えば「sed -e 's|foo|bar|'」

781

比較やテストには test コマンドを使わず、「[」や「]」を使います。例えば「if [ -x /bin/foo ]; ...」を使い、「if test -x /bin/foo; ...」は使いません。

782

test よりも case の方が読みやすく実行速度も早いため、可能な部分ではこちらを使います。

783

ユーザの環境と混ざる可能性を限定するため、関数の名前には大文字を使います。

784

手順

785

16. 手順

786

この章では、Debian の他のチームと協調する必要のある、Live システムプロジェクトの様々な作業の手順について触れます。

787

16.1 主要リリース

788

Debian の安定版の新しい主要バージョンのリリースでは、その完成のために多くの異なるチームが協調して作業しています。どこかの時点で、Live チームが参加して Live システムのイメージをビルドします。そのための要件は

789

リリースしたバージョンに該当する debian 及び debian-security アーカイブを収録している、debian-live の buildd からアクセスできるミラー

790

イメージの名前は既知の形式である必要があります (例えば debian-live-バージョン-アーキテクチャ-収録デスクトップ環境等.iso)。

791

debian-cd から来るデータを同期する必要があります (udeb 除外一覧)。

792

ビルドされたイメージのミラーが cdimage.debian.org に置かれます。

793

16.2 ポイントリリース

794

ここでも、debian と debian-security の更新されたミラーが必要です。

795

ビルドされたイメージのミラーが cdimage.debian.org に置かれます。

796

告知メールを送ります

797

16.2.1 ある Debian リリースの最後のポイントリリース

798

ある Debian リリース向けの最後のイメージを ftp.debian.org から archive.debian.org に移動した後にビルドするときには、chroot とバイナリミラーの両方を調整することを忘れないでください。そうすることで、古いビルド済み Live イメージをユーザが変更しなくてもそのまま続けて使えるようになります。

799

16.2.2 ポイントリリース告知用テンプレート

800

ポイントリリース用の告知メールはテンプレートと以下のコマンドを使って生成できます。

801

$ sed \
-e 's|@MAJOR@|7.0|g' \
-e 's|@MINOR@|7.0.1|g' \
-e 's|@CODENAME@|wheezy|g' \
-e 's|@ANNOUNCE@|2013/msgXXXXX.html|g'

802

メールを送る前に注意深く確認し、他の人による校正を受けてください。

803

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>.

804

Gitリポジトリ

805

17. Gitリポジトリ

806

Live システムプロジェクトの利用可能な全リポジトリ一覧は <http://live-systems.org/gitweb/> にあります。プロジェクトの git URL は: プロトコル://live-systems.org/git/リポジトリ という形式になっています。したがって、live-manual を読み込み専用で複製するには

807

$ git clone git://live-systems.org/git/live-manual.git

808

$ git clone https://live-systems.org/git/live-manual.git

809

$ git clone http://live-systems.org/git/live-manual.git

810

のどれかを実行します。書き込み権限のある複製には git@live-systems.org:/リポジトリという形式のアドレスを使います。

811

なので、繰り返しますが live-manual をssh経由で複製するには

812

$ git clone git@live-systems.org:live-manual.git

813

と入力する必要があります。gitツリーは複数の異なるブランチでできています。debian 及び debian-next ブランチは最終的には新しいリリースそれぞれに収録される実際の作業を収録しているため特に注目すべきです。

814

既存のリポジトリのどれかを複製した後は debian ブランチにいるでしょう。これはプロジェクトの最新リリースの状態を確認するには適切ですが、作業開始前に必ず debian-next ブランチに切り替える必要があります。切り替えには

815

$ git checkout debian-next

816

を実行します。debian-next ブランチは常に fast-forward とは限らず、あらゆる変更が debian ブランチにマージされる前にまずはこにコミットされます。例えて言えばテストの場のようなものです。このブランチで作業していてサーバにある変更を取得する必要がある場合は git pull --rebase を実行する必要があります。それにより、サーバから取得するときにローカルでの変更が反映され、その変更が最上位に配置されます。

817

17.1 リポジトリを複数処理

818

Live システムのリポジトリを複数複製してすぐに、最新コードの確認、パッチ作成、あるいは翻訳での貢献等のために debian-next ブランチに切り替えたい場合、複数のリポジトリを扱いやすくするための mrconfig ファイルをgitサーバで提供していることを紫知っておくべきでしょう。これを使うには mr パッケージをインストールする必要があります。その後、

819

$ mr bootstrap http://live-systems.org/other/mr/mrconfig

820

を実行します。このコマンドは自動的に複製し、プロジェクトにより作成される Debian パッケージの開発用リポジトリである debian-next ブランチを取得します。これには、中でも live-images リポジトリがあり、プロジェクトが一般用途向けに公開しているビルド済みイメージで利用される設定を収録しています。このリポジトリの使い方に関するさらなる情報については、 Git経由で公開されている設定の複製 を見てください。

821

例

822

例

823

18. 例

824

この章では特定の Live システム活用事例向けの見本ビルドについて触れます。自分用の Live システムイメージのビルドが初めてであれば、まず3つのチュートリアルを順に調べてみることを勧めます。それぞれで他の例の利用、理解を支援する新しい技術を学ぶようになっているためです。

825

18.1 例の使用

826

提示している例を利用するためには、ビルドするために 要件 に記載されている要件一覧に合致するシステムと、 live-build のインストール で説明しているように live-build がインストールされていることが必要となります。

827

簡潔にするため、ここに挙げる例ではビルドで利用するローカルミラーを指定していないことに注意してください。ローカルミラーを利用するとダウンロード速度をかなり高速化できます。 ビルド時に利用するディストリビューションのミラー で説明しているように、lb config を使った場合はオプションを指定することができます。ビルドシステムのデフォルト値を /etc/live/build.conf でセットするともっと便利になります。このファイルを単純に作成し、対応する LB_MIRROR_* 変数に望ましいミラーをセットしてください。ビルドで利用する他のミラーは全て、これにより設定した値をデフォルト値として使います。例えば:

828

LB_MIRROR_BOOTSTRAP="http://mirror/debian/"
LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security/"
LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-backports/"

829

18.2 チュートリアル 1: デフォルトイメージ

830

事例: 簡単な最初のイメージを作成して live-build の基礎を学びます。

831

このチュートリアルでは、live-build を利用した最初の演習としてbase パッケージ (Xorg は含まない) と Live システムを支援するパッケージだけを収録する、デフォルトの ISO hybrid 形式の Live システムイメージをビルドします。

832

これ以上簡単にすることはなかなかできないでしょう:

833

$ mkdir tutorial1 ; cd tutorial1 ; lb config

834

何か望むことがあれば config/ ディレクトリの内容を調べてください。ここには概略の設定があり、すぐ独自化もできますが、ここではそのままでデフォルトのイメージをビルドします。

835

スーパーユーザでイメージをビルドし、そのログを tee により保存します。

836

# lb build 2>&1 | tee build.log

837

すべてがうまくいくとして、しばらくすると現在のディレクトリに live-image-i386.hybrid.iso が出来上がります。この ISO hybrid イメージは Qemu でのISOイメージのテスト や VirtualBox でのISOイメージのテスト で説明しているように仮想マシンで直接、あるいは 物理メディアへのISOイメージ書き込み や USBメモリへの ISO hybrid イメージのコピー で説明しているように光学メディアやUSBフラッシュ機器に書き込んだイメージ、それぞれからブートできます。

838

18.3 チュートリアル 2: ウェブブラウザユーティリティ

839

事例: ウェブブラウザユーティリティイメージを作成し、独自化の適用方法を学びます。

840

このチュートリアルでは Live システムイメージを独自化する方法の紹介として、ウェブブラウザユーティリティとしての利用に適するイメージを作成します。

841

$ mkdir tutorial2
$ cd tutorial2
$ lb config
$ echo "task-lxde-desktop iceweasel" >> config/package-lists/my.list.chroot
$ lb config

842

この例で LXDE を選択しているのは最小限のデスクトップ環境を提供するという私達の目的を反映しています。念頭に置いているこのイメージの目的はただ一つ、ウェブブラウザだけだからです。もっと細かく、config/includes.chroot/etc/iceweasel/profile/ でのウェブブラウザ向けデフォルト設定やウェブ上の様々な種類の内容を表示するための追加のサポートパッケージを提供することはできますが、それは読み手の演習として残しておきます。

843

チュートリアル 1 と同様、ここでもスーパーユーザでイメージをビルドし、ログを残します:

844

# lb build 2>&1 | tee build.log

845

ここでも チュートリアル 1 と同様、イメージがうまくできているか検証し、テストします。

846

18.4 チュートリアル 3: 私的イメージ

847

事例: プロジェクトを作成して個人用イメージをビルドします。USBメモリを使って好みのソフトウェアを自由に収録し、要求や設定を変更しながらこのイメージを続けて改訂します。

848

この個人用イメージを何度も改訂し、変更を追跡しておいて実験的に試してみてうまくいかなかったときには差し戻せるようにしたいため、人気のある#{git}#バージョン管理システムに設定を残します。 設定管理 で説明している auto スクリプトによる自動設定を経由した最善の実践も利用します。

849

18.4.1 最初の改訂

850

$ mkdir -p tutorial3/auto
$ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/
$ cd tutorial3

851

auto/config を以下のように変更します:

852

#!/bin/sh

lb config noauto \
--architectures i386 \
--linux-flavours 686-pae \
"${@}"

853

lb config を実行して設定ツリーを生成し、生成された auto/config スクリプトを使います:

854

$ lb config

855

ここでローカルパッケージ一覧を設定します:

856

$ echo "task-lxde-desktop iceweasel xchat" >> config/package-lists/my.list.chroot

857

まず、--architectures i386 により必ず amd64 ビルドシステムでほとんどのマシンでの利用に適応する32ビット版をビルドするようにします。次に、相当に古いシステムでのこのイメージの利用を想定しないため --linux-flavours 686-pae を使います。lxde のタスクメタパッケージを選択して最小限のデスクトップを揃えます。最後に、好みのパッケージの初期値として iceweasel と xchat を追加しています。

858

そして、イメージをビルドします:

859

# lb build

860

最初の2つのチュートリアルとは異なり、2>&1 | tee build.log は auto/build に書かれているため打ち込む必要がなくなっていることに注意してください。

861

( チュートリアル 1 にあるように) イメージをテストしてうまく機能する確信を得たら#{git}#リポジトリを初期化し、作成したばかりの auto スクリプトだけを追加し、最初のコミットを行います:

862

$ git init
$ cp /usr/share/doc/live-build/examples/gitignore .gitignore
$ git add .
$ git commit -m "Initial import."

863

18.4.2 2回目の改訂

864

この改訂では、最初のビルドをきれいにし、vlc パッケージを設定に追加して再ビルド、テストコミットを行います。

865

lb clean コマンドは前のビルドで生成したファイルを、パッケージを再びダウンロードせずに済むようにキャッシュを除いて全てきれいにします。これにより以降の lb build が全段階で再び実行され、必ず新しい設定でファイルを再生成するようになります。

866

# lb clean

867

vlc パッケージを config/package-lists/my.list.chroot のローカルパッケージ一覧に追記します:

868

$ echo vlc >> config/package-lists/my.list.chroot

869

再びビルドします:

870

# lb build

871

テストして満足したら次の改訂としてコミットします:

872

$ git commit -a -m "Adding vlc media player."

873

もちろん、config/ 以下のサブディレクトリにファイルを追加する等により設定をもっと複雑に変更することも可能です。新しい改訂版をコミットする際、config の最上位にある、LB_* 変数を設定しているファイルもビルドされてできたもので、lb clean と、対応する auto スクリプトを経由して再作成した lb config により常に整理されるものなので、手で編集したりコミットすることのないように注意してください。

874

一連のチュートリアルもこれで終わりです。もっと多様な独自化はできますが、ここまでの簡単な例で見てきた少しの機能を使うだけでも、イメージはほぼ無限の異なる組み合わせを作成することができます。この節の残りの例では、収集してきた Live システムのユーザの経験を元にした他の事例についていくつか触れます。

875

18.5 VNC 公衆クライアント

876

事例: live-build を使って、ブートすると直接 VNC サーバに接続するイメージを作成します。

877

ビルド用ディレクトリを作ってそこに概略設定を作成し、推奨パッケージを無効にして最小限のシステムを作成します。それから初期パッケージ一覧を2つ作成します: 1つ目は live-build により提供される Packages というスクリプト ( 生成されるパッケージ一覧 参照) により生成し、2つ目では xorg、gdm3、metacity、xvnc4viewer を収録します。

878

$ 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

879

APT の調整による容量の節約 で説明しているように、イメージが適切に機能するためには推奨パッケージを再びいくらか追加する必要があるかもしれません。

880

推奨パッケージ一覧を調べるための簡単な方法として apt-cache の利用があります。例えば:

881

$ apt-cache depends live-config live-boot

882

この例では live-config 及び live-boot により推奨されるパッケージを複数、再び収録する必要があることがわかっています: 自動ログインが機能するためには user-setup、システムをシャットダウンするための不可欠なプログラムとして sudo。他に、イメージをRAMにコピーできるようになる live-tools や Live メディアを最終的に取り出す eject を追加しておくと便利でしょう。それを反映すると:

883

$ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot

884

その後ディレクトリ /etc/skel を config/includes.chroot に作成し、その中にデフォルトユーザ向けの独自の .xsession を置きます。このファイルは metacity を立ち上げて xvncviewer を起動し、192.168.1.2 にあるサーバのポート 5901 に接続します:

885

$ 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

886

イメージをビルドします:

887

# lb build

888

楽しみましょう。

889

18.6 128MB USB メモリ向けの基本イメージ

890

事例: 128MB USB メモリに収まるように構成要素をいくらか削除して、収まることがわかるように容量を少し空けたデフォルトのイメージの作成。

891

特定のメディア容量に収まるようにイメージを最適化する場合、イメージのサイズと機能はトレードオフになることを理解する必要があります。この例では削るだけにしているので 128MB のメディアサイズ内に何か追加する余地をできるだけ残していますが、localepurge パッケージによるロケールの完全削除や収録しているパッケージ内の一貫性は何も壊していません。また、その他の「押し付ける」ような最適化もしていません。特に注目すべきなのは、最小限のシステムを最初から作成するために --debootstrap-options を利用している点です。

892

$ lb config -k 486 --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none

893

イメージを適切に機能させるためには、最低でも --apt-recommends false オプションにより外されていた推奨パッケージを2つ追加しなおす必要があります。 APTの調整による容量の節約 を見てください。

894

$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot

895

ここで、普通の方法でイメージをビルドしてみます:

896

# lb build 2>&1 | tee build.log

897

これを書いている時点の著者のシステムでは、上記の設定により 77MB のイメージができました。これを チュートリアル 1 のデフォルト設定で作成された 177MB のイメージと都合良く比較してみましょう。

898

i386 アーキテクチャシステム上でデフォルトのイメージをビルドするのと比較して、ここで最もスペースの節約になったのはカーネルのアーキテクチャの種類をデフォルトの -k "486 686-pae" に代えて 486 だけを選択することでした。--apt-indices false によりAPTの索引を省くことでもかなりの容量を節約していますが、その代わりに Live システムで apt を使う前に apt-get update を実行する必要があります。--apt-recommends false により推奨パッケージを除外することで、本来あるはずのパッケージをいくらか除外する代わりにいくらか追加で容量を節約します。--debootstrap-options "--variant=minbase" で最初から最小限のシステムを構成します。--firmware-chroot false でファームウェアパッケージを自動的に収録しないようにすることでもさらに容量をいくらか節約します。そして最後に、--memtest none によりメモリテスターのインストールを抑制します。

899

注意: 最小限のシステムの構成はフックを使って、例えば /usr/share/doc/live-build/examples/hooks にある stripped.hook.chroot でも実現できます。これは容量をさらに少し減らし、62MB のイメージを生成します。しかしこれはその実現のために、システムにインストールしたパッケージから文書その他のファイルを削除しています。これはそうしたパッケージの完全性を破壊し、ヘッダで警告しているように思わぬ結果をもたらすかもしれません。それが、この目標のために推奨するのが最小限の debootstrap を利用する方法になっている理由です。

900

18.7 地域化した GNOME デスクトップとインストーラ

901

事例: GNOME デスクトップのイメージを作成し、スイス用の地域化とインストーラを収録する

902

好みのデスクトップを使った i386 アーキテクチャ向けの iso-hybrid イメージを作りたい。ここでは GNOME を使用して、GNOME 用の標準の Debian インストーラによりインストールされるのと同一のパッケージを全て収録します。

903

最初の問題は適切な言語用タスクの名前を判断する方法です。現在 live-build はこれを支援できません。運良くこれを試行錯誤で見つけられるかもしれませんが、そのためのツールがあります。grep-dctrl を利用して tasksel-data にあるタスクの説明を見つけることができます。そのため、準備としてこの両方が揃っていることを確認してください:

904

# apt-get install dctrl-tools tasksel-data

905

これで適切なタスクを検索できるようになりました。まず、

906

$ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german

907

というコマンドにより、呼ばれたタスクが、簡単に言うとここではドイツだということがわかります。次は関連タスクを見つけます:

908

$ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german-desktop
Task: german-kde-desktop

909

ブート時に de_CH.UTF-8 ロケールを生成して ch のキーボードレイアウトを選択します。一緒に見ていきましょう。 メタパッケージの利用 から、タスクのメタパッケージには先頭に task- が付くことを思いだしてください。こういった言語のブートパラメータを指定し、それから優先度が標準のパッケージと発見したタスクの全メタパッケージをパッケージ一覧に追加するだけです:

910

$ mkdir live-gnome-ch
$ cd live-gnome-ch
$ lb config \
-a i386 \
-k 486 \
--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

911

のようになります。インストーラを Live デスクトップから立ち上げるために debian-installer-launcher パッケージを収録し、さらに 486 用のカーネルを指定していることに注意してください。これは現在、インストーラを立ち上げる機能が適切に動作するためにはインストーラと Live システムのカーネルを一致させる必要があるためです。

912

付録

913

スタイルガイド

914

19. スタイルガイド

915

19.1 著者向けガイドライン

916

この節では Live マニュアル向けの技術的文書を記述する際に一般的に考慮すべき事項を扱います。言語特性と推奨手順に分かれています。

917

注意: 著者はまず この文書への貢献 を読んでください

918

19.1.1 言語特性

919

平易な英語を使う

920

読み手は英語が母国語ではない人の割合が高いことに留意してください。そのため、一般的規則として短く有意な文章を使い、引き続いて終止符を打ってください。

921

これは単純で幼稚な書き方をするように言っているわけではありません。英語が母国語ではない人にとって理解しにくい複雑な従属文にすることを可能な限り避けましょうという提案です。

922

英語の方言

923

最も広く使われている英語の方言はイギリス英語とアメリカ英語なので、ほとんどの著者が非常に高い率でこのどちらかを使っています。共同作業環境下で理想的なのは「国際英語」ですが、既存の全ての方言からどれを使うのが最善なのか決定するのは不可能とは言いませんが非常に困難です。

924

誤解を生まずに複数の方言を混在させることもできるとは思いますが、一般論として一貫性を持たせるようにすべきで、また、イギリス英語やアメリカ英語、その他の英語の方言からどれを使うか自分の裁量で決める前に、他の人がどのように書いているのかを調べてそれを真似るようにしてください。

925

バランス良く

926

偏見を持たないようにしてください。Live マニュアルに全く関係のない思想への言及を引用することは避けてください。技術的文献は可能な限り中立であるべきです。科学的文献では中立こそが自然です。

927

政治的に正しく

928

性差を表す言葉を可能な限り避けるようにしてください。個人の第三者を持ち出す必要がある場合は「he (彼)」や「she (彼女)」、あるいは「s/he や s(he) 彼(女)」などと複雑にするよりも「they (彼ら)」を使うのが好ましいです。

929

簡潔に

930

要点を直接述べ、回りくどい表現を使わないようにしてください。必要な情報は十分に提示ながらも、必要以上の余計な情報を提示するのはやめてください。これは不要な詳細を説明しないようにということです。読み手には理解力があります。読み手の側にいくらか前提知識があることを仮定してください。

931

翻訳作業を最小限に

932

書かれたものは他の複数の言語に翻訳されることになるということに留意してください。これは無意味あるいは冗長な情報を追加するとその分余計な作業をする人が出てくるということを意味します。

933

一貫性を

934

前にも提案しましたが、共同作業の文書を標準化して全体を完全に統一することはほぼ不可能です。しかし、文書を書く際に全体を通して他の著者と一貫した書き方をすることを歓迎します。

935

結束性を

936

必要なだけ文脈形成句を使い、文章に結束性を持たせて明確にしてください (文脈形成句は接続語句等の言語標識です)。

937

記述的に

938

標準的な「changelog」形式で文を単に羅列するよりも段落を使って要点を説明する方が好ましいです。描写してください! 読み手はそれを歓迎するでしょう。

939

辞書

940

英語で特定の概念を表現する方法がわからないときは辞書や百科事典でその語の意味を調べてください。ただし、辞書は最高の友ですが正しい使い方を知らなければ最悪の敵にもなることに留意してください。

941

英語には最大の語彙が存在する言語の一つです (100万語以上)。この語の多くは他の言語から取り入れられたものです。単語の意味を二カ国語の辞書で調べる際、英語が母国語ではない人は母国語の言葉により似ているものを選択する傾向があります。このことにより、英語ではあまり自然に聞こえない、過度に形式ばった文体になりがちです。

942

原則として、ある概念が複数の異なる同義語により表現できるとき、辞書で最初に提示された語を選択するのが良い判断となるでしょう。疑問がある場合はゲルマン起源の語 (通常単音節の語) を選択すると多くの場合正しいとなります。この2つの技ではどちらかというとくだけた表現になるかもしれないという点には注意が必要ですが、少なくとも広く使われていて通常受け入れられる語を選択することになります。

943

共起辞書の利用を勧めます。通常合わせて利用する語がわかるようになると極めて役に立ちます。

944

繰り返しますが、他の人の作業から学ぶことが最良の実践です。検索エンジンを使って他の著者が特定の表現をどのように使っているか確認することは大きな手助けとなるでしょう。

945

空似言葉や熟語その他の慣習的な表現

946

空似言葉に気をつけてください。外国語の熟練度を問わず、2つの言語で同じように見える語だけれどもその意味や使い方が全く異なる「空似言葉」という罠にはまることがあることは避けられません。

947

熟語は可能な限り避けてください。「熟語」は個々の語が持っていた意味とは完全に異なる意味を表すことがあります。熟語は英語が母国語の人でさえ理解しにくいこともあります!

948

俗語や省略、短縮表現等は避けましょう

949

平易な、日常的な英語の使用を勧めるとはいっても、技術的文献は言語を正式に記録する類のものです。

950

俗語や通常使わない解釈困難な省略表現、特に母国語での表現を模倣するような短縮表現は避けてください。IRCや、家族や仲間内で使うような特有の表現での記述はしないでください。

951

19.1.2 手順

952

書く前にテストを

953

著者が Live マニュアルに追加する前に例をテストして、全て確実に説明通りに動作するようにすることは重要です。きれいな chroot やVM環境でのテストが良い起点となるでしょう。他に、それから異なるハードウェアを使っている異なるマシンでテストを実施し、起きるであろう問題を発見することができれば理想でしょう。

954

例

955

例示するときはできるだけ具体的にするようにしてください。例は結局例でしかありませんから。

956

抽象的な表現で読み手を混乱させるよりも、特定の状況でのみ適用できるような書き方をする方がより良いことはよくあります。この場合は提示した例の効果を簡単に説明することもできます。

957

使い方を誤ればデータ消失や類似の望ましくない影響を及ぼす可能性のある、潜在的に危険なコマンド類の使用を例示する場合等、例外がいくらかあります。この場合は起こりうる副作用について十分な説明を提供すべきです。

958

外部リンク

959

外部サイトへのリンクは、そのサイトにある情報が特別な点を理解するために決定的な効果が期待できる場合にのみ利用すべきです。その場合でも、外部サイトへのリンクは可能な限り少なくしてください。インターネット上のリンクはその内容がほとんどが変更される可能性があるもので、その結果機能しないリンクができたり、論拠を不完全な状態にしてしまうことになります。

960

他に、インターネットに接続せずにそのマニュアルを読んでいる人にはそのリンクを追う機会がありません。

961

商標の主張やマニュアルの公開にあたって採用したライセンスに違反するものは避ける

962

商標の主張は可能な限り避けてください。記述した文書は他の下流のプロジェクトで使うことになるかもしれないことに留意してください。つまり、ある種の特定の内容を追加することは事態を複雑にすることになります。

963

live-manual は GNU GPL の条件下で使用を許可しています。これには、合わせて公開する (著作権のある画像やロゴを含むあらゆる種類の) 内容の配布物に適用する意味合いがいくつかあります。

964

まず草稿を書き、改訂、変更して改善し、必要なら作り直す

965

- 案を引き出しましょう! まず論理的に順を追って考えを整理する必要があります。

966

- 頭の中で何とか形ができたら最初の草稿を書きます。

967

- 文法や書式、つづりを直します。リリースの正しい名前は jessie や sid で、これをコード名として参照するときは大文字にすべきではないことに留意してください。「spell」ターゲットを使って、つまり#{make spell}#でつづりの誤りがないか確認できます。

968

- 記述を改善し、必要な部分があれば書き直します。

969

章

970

章や副題には慣習的な番号の付け方をしてください。例えば 1、1.1、1.1.1、1.1.2 ... 1.2、1.2.1、1.2.2 ... 2、2.1 ... などというようにです。以下のマークアップを見てください。

971

説明するのに一連の手順や段階を列挙する必要がある場合は、First (最初に)、second (2つ目に)、third (3つ目に) ... というように序数を使ったり、First (最初に)、Then (それから)、After that (その後)、Finally (最後に)、... あるいは箇条書きすることもできます。

972

マークアップ

973

大事なことを言い忘れましたが、live-manual では SiSU を使ってテキストファイルを処理し、複数の形式の出力を生成しています。 SiSU マニュアル を眺めてそのマークアップ方法をよく理解することを勧めます。代わりに

974

$ sisu --help markup

975

と入力する方法もあります。マークアップをいくらか例示してみます。有用だということはわかるかもしれません。

976

- 文字列の強調/太字:

977

*{foo}* または !{foo}!

978

は「foo または foo 」となります。これは特定のキーワードを強調するのに使います。

979

- 斜体:

980

/{foo}/

981

は foo となります。これは例えば Debian パッケージの名前に使います。

982

- 等幅:

983

#{foo}#

984

は foo となります。これは例えばコマンドの名前に使います。また、キーワードやパスのようなものの一部を強調するのにも使います。

985

- コードブロック:

986

code{

$ foo
# bar

}code

987

は

988

$ foo
# bar

989

となります。タグの開始には code{ を、終了には }code を使います。コードの各行には先頭に空白が必要だということを必ず覚えておいてください。

990

19.2 翻訳者向けガイドライン

991

この節では Live マニュアルの内容を翻訳する際に一般的に考慮すべき事項を扱います。

992

一般的な推奨事項として、翻訳者は自分の言語に適用される翻訳規則を既に読んで理解しておくべきです。通常、翻訳用のグループやメーリングリストが Debian の品質標準に合致する翻訳物を作成する方法についての情報を提供しています。

993

注意: 翻訳者は この文書への貢献 も読むべきです。特に 翻訳 節を

994

19.2.1 翻訳の手がかり

995

コメント

996

翻訳者の役割は元の著者により書かれた語や文、段落、そして文章の意味を可能な限り忠実に目標の言語で伝えることです。

997

そのため、個人的なコメントや自分の余計な情報の追加は控えるべきです。同一の文書について作業している他の翻訳者に向けてコメントを追加したい場合はそのために用意されている場があります。これは po ファイルの番号記号 # に続く文字列のヘッダです。ほとんどの視覚的な翻訳用プログラムで自動的にこれをコメントの種類に属するものとして処理します。

998

TN, Translator's Note (翻訳者によるメモ)

999

完全に受け入れられるとはいえ、翻訳済みテキストの括弧「()」内に語や表現を含めることは、ややこしい語や表現の意味を読み手にとってより明確にする場合にのみ行ってください。翻訳者は括弧内に「(訳注)」等と記載して、その追記が翻訳者によるものであることを明確にすべきです。

1000

非人称の文を

1001

英語で書かれた文書は「you」を非人称として幅広く使います。他の言語にはこの特徴を共有しないものもあります。このことで、元の文が読み手に対して直接呼びかけているかのような誤った印象を実際にはそうではないのに与えてしまうかもしれません。翻訳者はこの点に注意して、可能な限り正確に自分の言語に反映する必要があります。

1002

空似言葉

1003

前に説明した「空似言葉」の罠は特に翻訳者に当てはまります。疑いがあれば、その疑わしい空似言葉の意味を再点検してください。

1004

マークアップ

1005

最初は*{pot}*ファイル、後には*{po}*ファイルについて作業する翻訳者は多数のマークアップ機能を文字列に確認できるでしょう。文は翻訳できるものである限り翻訳できますが、それが元の英語版と全く同一のマークアップを採用しているということは極めて重要です。

1006

コードブロック

1007

コードブロックは通常翻訳できませんが、翻訳にそれを含めることが、翻訳率 100% を達成する唯一の方法です。コードが変更されると翻訳者による介入が必要となるため最初は余計な作業になりますが、長期的に見るとこれが .po ファイルの整合性を確認したときに何が既に翻訳済みで何が未翻訳なのか識別する最善の方法です。

1008

改行

1009

翻訳文には元の文と全く同じだけの改行が必要です。元のファイルに改行があるときは注意して「Enter」キーを押すか*{\n}*を打ち込んでください。改行は例えばコードブロック中でよく使われます。

1010

勘違いしないでください。これは翻訳文を英語版と同一の長さにする必要がある、ということではありません。それはほぼ不可能です。

1011

翻訳できない、してはいけない文字列

1012

翻訳者が決して翻訳すべきでないもの:

1013

- リリースのコード名 (小文字で書くべき)

1014

- プログラムの名前

1015

- 例示するコマンド

1016

- メタ情報 (前後にコロンが置かれることが多い :メタ情報:)

1017

- リンク

1018

- パス

Metadata

Document Metadata:

Title: Live システムマニュアル

Creator: Live システムプロジェクト <debian-live@lists.debian.org>

Rights: Copyright: Copyright (C) 2006-2014 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.

Publisher: Live システムプロジェクト <debian-live@lists.debian.org>

Date: 2014-10-25

Version Information:

Sourcefile: live-manual.ssm.sst

Filetype: SiSU text 2.0, UTF-8 Unicode text, with very long lines

Source Digest: SHA256(live-manual.ssm.sst)= c89c1989b8f7190efa7b806a748ee1bbab7aad4070830f63acf5c82b53833271

Generated:

Generated by: Generated by: SiSU 5.7.1 of 2014w41/7 (2014-10-19)

Ruby version: ruby 2.1.3p242 (2014-09-19) [x86_64-linux-gnu]

Document (ao) last generated: 2014-10-25 13:16:02 +0000