[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 次のページ ]


Debian リファレンス
第 2 章 - Debian の基礎知識


本章は非開発者のために Debian システムの基礎的な情報を供給します。 信頼できる情報が欲しい場合は、次を参照してください。

参考文献, 第 15.1 節 にリストされています。

あまり詳しくない "how-to" 的な説明を探している場合、 Debian パッケージ管理, 第 6 章 や他の該当する章にすぐ飛んでください。

本章は "Debian FAQ" から取られた文書に基づき、通常の Debian システム管理者が始められるように大規模な再構成を行いました。


2.1 Debian アーカイブ


2.1.1 ディレクトリ構造

Debian 用にパッケージングされているソフトウェアは Debian mirror site のそれぞれのいくつかの ディレクトリツリーの一つから FTP 並びに HTTP 経由で取得できます。

次のディレクトリは 各 Debian ミラーサイトの debian ディレクトリの下で見つかります。

dists/:

このディレクトリには "distributions" が含まれており、これは 現在 Debian release および pre-release で得られるパッケージへの 標準的なアクセス手段として使用されます。いくつかの古いパッケージや Contents-*.gz 、そして Packages.gz も まだここにあります。

pool/:

ここは Debian release および pre-release の全パッケージ が物理的に存在する場所です。

tools/:

ブートディスク作成、ハードディスクのパーティショニング、 ファイル圧縮/解凍、そして Linux のブート用の DOS ユーティリティが ここにあります。

doc/:

FAQ, バグ報告システム指示書などの基本的な Debian に関する 文書がここにあります。

indices/:

Maintainers ファイルや override ファイルがここにあります。

project/:

主に開発者のみ必要なものです。例えば、

project/experimental/:

本ディレクトリにはまだ開発中であり、まだ α テスト段階の パッケージやツールが含まれます。ユーザはここにあるパッケージを 使用するべきではありません。なぜなら、最も経験を積んだ人でさえも 危険で害を及ぼす可能性があるからです。

project/orphaned/:

古いメンテナにより「みなしご化」され、ディストリビューションから なくなったパッケージです。


2.1.2 Debian ディストリビューション

通常 dists ディレクトリには 3種類の Debian ディストリビューションが存在します。これらは stable. testing そして unstable と呼ばれます。 時々 frozen も存在します。(現在はfrozentesting の開発ステージのひとつです。)各ディストリビューションは dists ディレクトリにある、コードネームが付いた 実際のディレクトリのシンボリックリンクとして定義されています。


2.1.3 stable ディストリビューション

stable ディストリビューション, Debian Sarge (3.1r0) 用のパッケージ エントリは stable (sarge/ への シンボリックリンク) ディレクトリに記録されています。

現在は、上に挙げた場所に加えて、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照)

stable ディストリビューションの最新バグステータスは Stable Problems web ページに 報告されています。


2.1.4 testing ディストリビューション

testing ディストリビューション、Debian Etch のパッケージ エントリは unstable でしばらくテストを受けた後に testing (etch/ への シンボリックリンク) ディレクトリに記録されます。 上に挙げた場所に加え、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照) testing/stable/ と同じ機能を提供する maincontrib そして non-free サブディレクトリもあります。

これらのパッケージはビルドされる全てのアーキテクチャで同期を取られ、 インストール可能でなくてはなりません。また、unstable にあるバージョンよりも release-critical bug が少なくてはなりません。 このように、testing は常に release candidate 間近であることを 希望しています。testing のメカニズムの詳細については http://www.debian.org/devel/testing にあります。

testing ディストリビューションの最新バグステータスはこれらのサイト で報告されています。


2.1.5 unstable ディストリビューション

unstable ディストリビューションは、常に "Sid" というコードネームであり、パッケージエントリは Debian archive にアップロードされた後に unstable (sid/ へのシンボリックリンク) ディレクトリに 記録され、testing/ に移動されるまでここにあります。 上に挙げた場所に加え、pool ディレクトリに新しい 物理的なパッケージがあります。 (pool ディレクトリ, 第 2.1.10 節 参照) testing/stable/ と同じ機能を提供する main, contrib, そして non-free サブディレクトリもあります。

unstable ディストリビューションには最新の開発版システムの スナップショットが含まれます。ユーザがパッケージを使ってテストするのは 歓迎されますが、これらのパッケージが準備段階にあることは警告されます。 unstable ディストリビューションを使う利点としては、 常に最新の Debian ソフトウェアプロジェクトを使えます。 — たとえシステムを壊すようなことがあったとしても、 壊れたシステムをそのままキープできます。

unstable ディストリビューションの最新バグステータスは Unstable Problemsweb ページで 報告されています。


2.1.6 frozen ディストリビューション

testing ディストリビューションが充分成熟すると、frozen されます。 そして、新しいコードはもはや受け付けず、必要ならばバグフィックスのみ 受け付けられます。さらに、新しい testing ツリーが dists ディレクトリに作成され、新しいコードネームを割り当てられます。 frozen ディストリビューションは数ヵ月テストされ、"テストサイクル" と呼ばれる deep freeze に入ります。

パッケージのリリースを遅らせたり、リリース全体を止めてしまう frozen ディストリビューションのバグを記録し続けています。 バグ総数が最大許容数を下回ったら、frozen ディストリビューション は stable になり、リリースされます。そして以前の stable ディストリビューションは obsolete になります。(そして archive に移動します)


2.1.7 Debian ディストリビューションのコードネーム

sarge/etch/ などの、dists ディレクトリにある物理的に存在するディレクトリ名は、 単なる "コードネーム" です。Debian ディストリビューションが開発段階に あるとき、バージョン番号を持ちませんが、その代わりコードネームを持ちます。 これらのコードネームの目的は、Debian ディストリビューションのミラーリングを より簡単に行うためです。(もし真のディレクトリ名unstableが 突然stable に変わると、不必要に多くの ダウンロードを再び行わなくてはならなくなります)

現在、stablesarge/ の、 testingetch/ のシンボリック リンクです。これは Sarge が現在の stable ディストリビューションであり、Etch が現在の testing ディストリビューションであることを意味しています。

Sid は常に unstable ディストリビューションですので、unstable/sid/ の永続的なシンボリックリンクです。


2.1.8 過去に使用されたコードネーム

過去に使われたコードネームは次の通りです。 release 1.1 では "Buzz", release 1.2 では "Rex", release 1.3.x では "Bo", release 2.0 では "Hamm", release 2.1 では "Slink", release 2.2 では "Potato", release 3.0 では "Woody", release 3.1 では "Sarge"。


2.1.9 コードネームの由来

いままではコードネームは Pixar 作の映画 トイストーリー の キャラクター名から取られていました。


2.1.10 pool ディレクトリ

歴史的に、パッケージはパッケージを含むディストリビューションに対応した dists サブディレクトリに保持されました。これは大きな変更が 発生した場合、ミラーするのに大きなバンド幅を消費するなどのさまざまな 問題を引き起こしました。

パッケージは現在大きな "pool" に保存され、source パッケージの名前に 従って構造化されます。この "pool" を管理可能にするため、pool は セクション (main, contrib, そして non-free) および source パッケージの先頭の文字により分割されます。これらのディレクトリ には、各アーキテクチャ用のバイナリパッケージ、そして バイナリパッケージの生成元である source パッケージなどが含まれます。

apt-cache showrc mypackagename のようなコマンドを 実行し、"Directory:" 行を見ることにより、パッケージの場所を見つけられます。 例えば、apache パッケージは pool/main/a/apache/ にあります。非常に多くの lib* パッケージが存在するため、これらのパッケージは特別扱いされています。 例えば、libpaper パッケージは pool/main/libp/libpaper/ に保存されています。

dists ディレクトリは依然 apt のような プログラムにより使用される索引ファイルのために使われています。

新しい apt や多分古い dpkg-ftp はシームレスな処理を行うので、通常は これらのことを心配する必要はありません。詳細を知りたい場合は、 RFC: implementation of package pools をご覧ください。


2.1.11 Sid に関するヒストリカルノート

昔 Sid は存在していませんでした。Debian archive サイトは大きな欠陥を 1つ持っていました。アーキテクチャが最新の unstable に作られると、ディストリビューションが新しい stable になった時に それがリリースされるという前提がありました。このケースにあてはまらない 多くのアーキテクチャにとって、リリース時にこれらのディレクトリが移動 しなければならないという結果となりました。この移動が膨大なバンド幅を 消費するため、これは実際的ではありません。

アーカイブ管理者はこの問題に数年間取り掛かり、sid と 呼ばれる特別なディレクトリに未リリースのアーキテクチャのためのバイナリを置く ことにより問題を解決してきました。未リリースのアーキテクチャが最初にリリースされる 場合、最新の stable/ に対し sid/ がリンク されました。アーキテクチャが最初にリリースされると 現在の stable/ から sid/にリンクを作り、それ以降は 通常どおりunstable/のツリーの中につくられていきました。 この配置はユーザーの混乱を招きやすいです。

Woody ディストリビューションの開発中にパッケージプールを (pool ディレクトリ, 第 2.1.10 節 参照) 発明したことにより、バイナリパッケージは ディストリビューションに依らずにプール内の標準的な場所に保存され始めました。 それゆえ、ディストリビューションのリリースを行っても、もはやミラー時に 大きなバンド幅を消費しません。(しかし、開発過程を通し、緩やかなバンド幅 消費が発生します。)


2.1.12 incoming/ にパッケージをアップロードする

パッケージのアップロードはそれらが本当に Debian 開発者からのものかを 検査した後に http://incoming.debian.org/ にまず置かれます。 (そしてそれがノンメンテナアップロード (NMU) の場合は、DELAYED サブディレクトリに置かれます。) 1日に 1度、それらは incoming/ から unstable/ に移されます。

緊急時には、incoming/unstable/ に移る前に パッケージをインストールしたい場合があるかもしれません。


2.1.13 古いパッケージを取得する

最新の Debian ディストリビューションは Debian mirror sitedebian ディレクトリ下に保持されますが、Slink などの古い Debian ディストリビューションのアーカイブは http://archive.debian.org/ や Debian の各ミラーサイトの debian-archive ディレクトリに保存されています。

testingunstable の昔のパッケージは http://snapshot.debian.net/ にあります。


2.1.14 アーキテクチャセクション

主要なディレクトリツリーそれぞれ (dists/stable/main, dists/stable/contrib, dists/stable/non-free, dists/unstable/main など) の中に、バイナリパッケージエントリが パッケージがコンパイルされたアーキテクチャを示す名前を持つサブディレクトリ 内に存在します。

testingunstable 用の実際のバイナリパッケージは もはやこれらのディレクトリに無く、pool ディレクトリに あることに注意してください。しかし、索引ファイル (PackagesPackages.gz) は下位互換性のために保持されています。

実際にサポートされているバイナリパッケージについては、 各ディストリビューションのリリースノートをご覧ください。 これらは stable および testing のためのリリースノート サイトにあります。


2.1.15 ソースコード

ソースコードは Debian システムにおける全てに対して含まれます。さらに、 システムのほとんどのプログラムのライセンス事項は、ソースコードが プログラムと共に配布されるか、プログラムに添付するソースコードを 提供することを 要求します。

通常ソースコードは source ディレクトリで配布され、 アーキテクチャ特有のバイナリディレクトリ全てと並列になっているか、 より最近では pool ディレクトリにあります。 (pool ディレクトリ, 第 2.1.10 節 参照) Debian アーカイブの構造を熟知せずにソースコードを取得するには、 apt-get source mypackagename のようなコマンドを 試してみてください。

いくつかのパッケージ、とりわけ pine は そのライセンスの制限により、ソースパッケージでしか得られません。 (最近、pine-tracker パッケージが Pine のインストールを 容易にするために導入されました。stable システムへのパッケージ移植, 第 6.4.10 節パッケージング, 第 13.10 節 に記述された手順により、パッケージを手動で構築する方法を習得できます。

公式には Debian システムの一部では無い contribnon-free ディレクトリにあるパッケージのソースコードは 入手できるかもしれませんし、できないかもしれません。


2.2 Debian パッケージ管理システム


2.2.1 Debian パッケージの概観

一般にパッケージには関連するコマンドや機能を実装するのに必要な ファイルすべてが含まれています。Debian パッケージには 2つのタイプがあります。

このパッケージシステムでは、ソフトウェアをインストールするとき、 パッケージ保守担当者により宣言された "依存情報" を使います。 この依存情報はそれぞれのパッケージに関連する 制御 (control) ファイルに記載されています。例えば、GNU C コンパイラ (gcc) を含むパッケージは、リンカやアセンブラを含む binutils パッケージに "依存"しています。もしユーザがあらかじめ binutils をインストールしていないのに gcc をインストール>しようとしたなら、Debian のパッケージシステムは binutils も必要であるというエラーメッセージを出力し、 ユーザがまず binutils をインストールするのに同意するまで gcc をインストールしません (とは言うものの、頑固なユーザは この機能を上書きできます。dpkg(8) 参照) さらに詳しい情報は、パッケージの依存性, 第 2.2.8 節 下をご覧ください。

Debian のパッケージングツールは以下の用途に使えます。


2.2.2 Debian パッケージのフォーマット

Debian の "パッケージ" つまり Debian アーカイブファイルには、 実行プログラム一式や関連するプログラムのセットに関係する実行ファイルや、 ライブラリ、ドキュメントが含まれています。通常、Debian アーカイブファイルは ファイル名の最後に .deb が付いています。 [1]

Debian バイナリパッケージフォーマットの内部仕様は deb(5) マニュアルページに解説されています。 このフォーマットは (Debian のメジャーリリースの間で) 変更されることが あるので、.deb ファイルを操作する時は必ず dpkg-deb(1) を使って下さい。

少なくても Sarge ディストリビューションを通じ、全ての Debian アーカイブ ファイルは、dpkg コマンドが使えない場合であっても、 標準的な Unix コマンドである artar により操作できます。


2.2.3 Debian パッケージ名の命名規則

Debian パッケージのファイル名は次のような規則に従います。

     foo_バージョン番号-リビジョン番号__アーキテクチャ.deb

ここで、通常 foo はパッケージ名であり、var は 上流のバージョン番号、rev は Debian でのリビジョン番号、 そして arch はターゲットのアーキテクチャです。 ファイルはもちろん簡単に改名できます。 次のコマンドを実行することにより、filename という名前の ファイルに含まれているパッケージを調べることができます。

     dpkg --info filename

Debian のリビジョン番号は Debian 開発者又はパッケージを構築した人 により指定されます。通常リビジョン番号の変更はパッケージングの観点から 変更が加えられたことを意味しています。


2.2.4 ローカル設定の保存

ローカルの管理者により変更可能とされているファイルは /etc/ に保持されています。 Debian ポリシーはローカルの設定可能なファイルへの全ての変更が パッケージのアップグレードを通じて保持されるべきであることを指示しています。

ローカルの設定可能なファイルの標準のバージョンがパッケージ自身に 含まれている場合、そのファイルは "conffile" としてリストされます。 パッケージは管理者の許可無しで最後にインストールされたので、 パッケージ管理システムは管理者により変更された conffile を更新しません。 一方、conffile が管理者により変更されていないと、パッケージの他のファイル と一緒に conffile もアップグレードされます。 これはほとんど常に好ましく、conffile への変更を最小限にすることは好都合です。

パッケージに所属する conffile をリストするには、次のコマンドを実行します。

     dpkg --status package

このリストの "Conffiles:" 行に conffile が表示されます。

conffile に関するより詳しい情報については、Debian ポリシーマニュアルの "Configuration files" という章を読んでください。(参考文献, 第 15.1 節 参照)


2.2.5 Debian メンテナンススクリプト

Debian メンテナンススクリプトはパッケージがインストールされる前か後で 自動的に実行される実行可能なスクリプトです。これらのファイルは control という名前のファイルと一緒に全て Debian アーカイブファイルの "制御 (control)" セクションの一部となっています。

個々のファイルは以下の通りです。

preinst

このスクリプトは、パッケージが Debian アーカイブ (.deb/) ファイルからアンパックされる前に実行されます。パッケージがインストールか アップグレードし終わる ("postinst" スクリプトが正常に実行された後) まで、多くの"preinst" スクリプトの中で、更新されるパッケージのために サービスが停止されるようになっています。

postinst

このスクリプトの典型的な仕事は、Debian アーカイブファイル (.deb/) からアンパックされたら、それに必要な設定をすべて完了させる ことです。 "postinst" スクリプトのよくある動作として、ユーザに入力を求め、 既定値を受け入れるなら後戻りしてこのパッケージを環境に沿うように 再設定することを忘れないように警告を表示します。 新しいパッケージがインストールされるかアップグレードされると、 多くの "postinst" スクリプトはサービスを開始または再開するのに 必要なコマンドをすべて実行します。

prerm

このスクリプトは、典型的にはパッケージに関連したあらゆる デーモンを停止します。これはパッケージに関連したファイルを 削除する前に実行されます。

postrm

このスクリプトは、典型的にはパッケージに関連したリンクや 他のファイルを修整したりパッケージが作成したファイルを削除したりします。 (仮想パッケージ, 第 2.2.7 節 も参照。)

現在、制御ファイルは全て /var/lib/dpkg/info/ に置かれています。パッケージ foo に関係するファイルは "foo" で始まる 名前を持ち、"preinst" や "postinst" などの適当なファイル拡張子を持ちます。 このディレクトリにある foo.list というファイルは、 パッケージ foo によってインストールされたファイルがすべて リストされています (これらのファイルの存在場所は dpkg が 内部に持っていることに注意して下さい。存在場所を頼りにしないほうが いいでしょう)。


2.2.6 パッケージ優先度

それぞれの Debian パッケージには、パッケージ管理システムの助けとして、 ディストリビューション保守担当者が 優先度 を割りあてています。 優先度には以下のものがあります。

パッケージの説明にある "Priority: required", "Section: base" と "Essential: yes" の違いについて注意してください。"Section: base" は、 新しいシステムでは他の全てをインストールする前に、このパッケージが インストールされることを意味しています。"Section: base" なパッケージの ほとんどは "Priority: required" または、少なくても "Priority: important" であり、それらの多くは "Essential: yes" にタグづけられています。 "Essential: yes" は、このパッケージをシステムから削除するには、 dpkg のようなパッケージ管理システムに特別な強制オプションを 指示する必要があることを意味しています。例えば、 libc6mawkmakedev は "Priority: required" かつ "Section: base" ですが、"Essential: yes" ではありません。


2.2.7 仮想パッケージ

仮想パッケージとは、すべて同じ基本機能を提供するパッケージの集まりの どれか一つに供される一般的な名前のことです。 例えば、tintrn プログラムはどちらも ニュースリーダであり、それゆえ、動作するか利用するためにニュースリーダを 要求するプログラムの依存性を満たします。したがって、両プログラムは news-reader と呼ばれる "仮想パッケージ" を供給します。

同様に、eximexim4sendmailpostfix のような多くのパッケージは メール配送エージェント (mail transport agent) の機能を備えているために 仮想パッケージ mail-transport-agent を 提供すると言われます。これらのうちどれかがインストールされていれば、 mail transport agent がインストールされていることに依存する プログラムはどれでもこの仮想パッケージが存在しているために 条件を満足しています。

Debian はこのようなしくみを提供するので、同じ仮想パッケージを持つ パッケージが 1つ以上システムにインストールされると、システム管理者は 優先パッケージを設定できます。関連するコマンドは update-alternatives で、Alternative コマンド, 第 6.5.3 節 で さらに詳しく述べられています。


2.2.8 パッケージの依存性

Debian パッケージングシステムは、あるパッケージが機能したり、うまく 働くようにインストールされるべき他のパッケージを要求するという事実を 表現するために使われる依存性に関する宣言を操作します。

これらの用語の使用法についてのより詳しい情報は Debian パッケージング マニュアルDebian ポリシーマニュアル にあります。

Depends と指定されたパッケージ全てを単に取得しますが、 RecommendsSuggests と指定された パッケージを全て無視する apt-get に比べ、aptitudedselect は、RecommendsSuggests により指定されるより洗練されたパッケージ制御機能を有します。これらのプログラムは、共に現代的な形で APT をバックエンドとして使用します。


2.2.9 "pre-depends" の意味

dpkg は、常に他のパッケージが依存しているパッケージを 先に設定します。しかしながら、dpkg は通常ファイルを任意の順番で、依存性と関係なく解凍します。 (解凍とは、アーカイブファイルからのファイルの展開とそれらのファイルを 正しい場所に置くことから構成されます。) しかしながら、もしパッケージが他のパッケージに Pre-Depends している場合、Pre-Depends しているパッケージが解凍されていても、 その前に Pre-Depends されているパッケージの解凍と設定が行われます。 [2] この依存性の使用は最小限に保たれています。


2.2.10 パッケージステータス

パッケージステータスには "unknown", "install", "remove", "purge", "hold" があります。 これらの "want" フラグは利用者がそのパッケージをどう扱いたいかを示しています。 利用者は dselect の "Select" セクションでのアクション や dpkg の直接起動によってこれを示すことができます。

それぞれの意味は以下の通りです。


2.2.11 更新からパッケージを hold する

パッケージを hold するには二つの方法があります。dpkg を使う方法と、Woody から始まった APT を使う方法です。

dpkg では、パッケージ選択の一覧を

     dpkg --get-selections \* > selections.txt

で書き出すだけです。それから書き出されたファイル selections.txt を編集して hold したいパッケージの 行を変更します。例えば、

     libc6                       install

     libc6                       hold

にします。ファイルを保存して、

     dpkg --set-selections < selections.txt

でdpkg データベースに再ロードしてください。又、hold したいパッケージ名 を知っている場合は、単に

     echo libc6 hold | dpkg --set-selections

を実行するだけです。この手順は各パッケージファイルのインストール処理で パッケージを hold します。

同様の効果が dselect を通しても得られます。[S]elect 画面に 入って hold したいパッケージの現在の状態を確認し、「=」キー (もしくは「H」キー) を押下するだけです。変更は [S]elect 画面を終了するとすぐに反映します

Woody ディストリビューションにおける APT システムは Pin-Priority を用いてアーカイブ取得処理中にパッケージを hold する新しいもう一つの機構 を持ちます。 http://www.debian.org/doc/manuals/apt-howto/ 又は apt-howto パッケージのに、マニュアルページ apt_preferences(5) をご覧ください。


2.2.12 ソースパッケージ

ソースパッケージは source と呼ばれるディレクトリで 配布されています。手動でダウンロードできますし、

     apt-get source foo

を使ってダウンロードもできます。 (このための APT の設定法については apt-get(8) マニュアルページを 参照してください。) apt-get source foo を使って取得することもできます (このための APT の設定法については apt-get(8) を参照願います。)


2.2.13 ソースパッケージからバイナリパッケージを作る

パッケージ foo をソースからコンパイルするには、 foo_*.dsc, foo_*.tar.gz および foo_*.diff.gz の全てが必要となります (注意:Debian 固有のパッケージに は .diff.gz はありません)。

これらを入手し、pkg-dev パッケージをインストールしている場合、

     $ dpkg-source -x foo_version-revision.dsc

というコマンドを実行すれば foo-version というディレクトリ にパッケージが取り出されます。

バイナリパッケージをコンパイルしたいならば、

     $ cd foo-version
     $ su -c "apt-get update ; apt-get install fakeroot"
     $ dpkg-buildpackage -rfakeroot -us -uc

を実行し、

     # su -c "dpkg -i ../foo_version-revision_arch.deb"

で新たに構築したパッケージをインストールします。 stable システムへのパッケージ移植, 第 6.4.10 節 をご覧ください。


2.2.14 新しい Debian パッケージを作る

新しいパッケージを作ることに関する詳細な情報は、 maint-guide パッケージで得られる Debian メンテナ入門 又は http://www.debian.org/doc/manuals/maint-guide/ をご覧ください。


2.3 Debian システムのアップグレード

Debian の目標の一つは首尾一貫したアップグレード方針と安全な アップグレード手順を提供することです。パッケージングシステムは 管理者に重要な変更について警告し、時々は管理者に決定を促します。 リリースノートも読むべきです。これは全ての Debian CD と一緒に 出荷されており、WWW でも http://www.debian.org/releases/stable/releasenoteshttp://www.debian.org/releases/testing/releasenotes で利用可能です。

アップグレードを行う実際的なガイドは Debian パッケージ管理, 第 6 章 で供給されます。 本章では単に概要を供給します。まずはパッケージングツールから始めます。


2.3.1 dpkg

これはパッケージファイルの操作のための主要なプログラムです。 完全な説明は dpkg(8) を読んでください。

dpkg にはいくつかの原始的な補助プログラムが付随します。

dpkg-ftpdpkg-mountable は APT システムに 取って代わられました。


2.3.2 APT

APT (the Advanced Packaging Tool) は Debian パッケージングシステムの 先進的なインターフェースであり、"apt-" で始まる名前を持ついくつかのプログラム から構成されています。 apt-get, apt-cache, と apt-cdrom はパッケージ操作用のコマンドラインツールです。これらは、 dselectaptitude のような他のツールへのユーザ "バックエンド" としても 働きます。 現在、aptitudeは、システム維持のための推奨ツールです。

より詳しい情報は、apt パッケージと aptitude パッケージをインストールして、 aptitude(8), apt-get(8), apt-cache(8), apt-cdrom(8), apt.conf(5), sources.list(5), apt_preferences(5) を読んでください。

もう一つの情報源としては、 APT HOWTO があります。 /usr/share/doc/Debian/apt-howto/apt-howto によりインストールできます。

apt-get upgradeapt-get dist-upgrade は "Depends:" にリストされたパッケージのみを引っ張ってきますが、 "Recommends:" や "Suggests:" にリストされたパッケージは無視します。 これを避けるには、dselect を御使用ください。


2.3.3 dselect

このプログラムは Debian パッケージ管理システムへのメニュドリブンな ユーザインターフェースです。最初のインストール時や大規模なアップグレード時 に特に役立ちます。dselect, 第 6.2.3 節 をご覧ください。

より詳しい情報は、install-doc パッケージをインストールし、 /usr/share/doc/install-doc/dselect-beginner.en.htmldselect Documentation for Beginners を読んでください。


2.3.4 起動中のシステムをアップグレードする

Debian システムにおける kernel (ファイルシステム) はファイルを使用中 でさえも、そのファイルの置き換えをサポートしてます。 現在のランレベルで起動されるようにパッケージが設定されている場合、 パッケージの更新時にパッケージにより供給されるサービスが再起動 されます。 Debian システムは起動中のシステムをアップグレードするのに シングルユーザモードを必要としません。


2.3.5 .deb アーカイブファイルのダウンロードとキャッシュ

手動でパッケージファイルをディスクにダウンロードした場合、 (これは必ずしも必要ではありません。上に記述した dpkg-ftp または APT の説明をご覧ください) パッケージをインストールした後、 システムから .deb ファイルを削除できます。

APT を使っている場合、これらのファイルは /var/cache/apt/archives ディレクトリにキャッシュされます。 これらをインストール後に削除 (apt-get clean) できますし、 その後のインストール中のダウンロード時間を節約するため、 他のマシーンの /var/cache/apt/archives ディレクトリにコピー してもかまいません。


2.3.6 アップグレードの記録を取る

dpkg は展開、設定、削除またはパージされたパッケージの記録を取ります が、 (現在) パッケージにそのような操作が行われている間に起こったターミナル上の コマンドログを取っていません。

コマンドログを取る最もシンプルな方法は、dpkg, dselect, apt-get などのセッションを script(1)プログラム内で起動することです。


2.4 Debian ブートプロセス


2.4.1 init プログラム

他の Unix ライク OS と同様に、Debian は init プログラムを 実行することによりブートを始めます。init 用の設定ファイル (/etc/inittab) は、実行されるべき最初のスクリプトが /etc/init.d/rcS であることを指定しています。

次に起きることは sysv-rc 又は file-rc のどちらかがインストールされているかどうかに依存しています。 次に述べることは sysv-rc がインストールされていることを 仮定しています。(file-rc には固有の /etc/init.d/rcS スクリプトが含まれており、ランレベル毎に 起動されるサービスの種類を制御するために rc ディレクトリにある シンボリックリンクの代わりにこのスクリプトが用いられます。)

sysv-rc パッケージにある /etc/init.d/rcS ファイルはファイルシステムのチェックやマウント、モジュールの読み込み、 ネットワークサービスの開始、時計の設定などの初期化作業を行うために /etc/rcS.d/ にあるスクリプト全てを起動します。 そして、互換性のために、/etc/rc.boot/ 下にあるファイル (ファイル名に `.' が付くファイルを除く) も実行します。 後者のディレクトリ内のスクリプトは、通常システム管理者が使用するために 予約されており、パッケージがこのディレクトリにスクリプトを置くのは 時代遅れです。詳細は Debian ポリシーマニュアルの システムの初期化, 第 9.1 節System run levels and init.d scripts をご覧ください。


2.4.2 ランレベル

ブートプロセス完了後、init は (/etc/inittabid 用のエントリにより与えられる) 標準のランレベルで 起動されるように設定された全てのサービスを起動します。 標準のランレベルは /etc/inittab 中の id エントリ により与えられます。 Debian は id=2 となっています。

Debian は次のランレベルを使用しています。

ランレベル 7, 8, 9 も使用可能ですが、パッケージがインストールされる時に これらの rc ディレクトリにはあまり起動スクリプトがリンクされません。

ランレベルを切替えるには telinit コマンドを用います。

あるランレベルに入ると、/etc/rcrunlevel.d/ にある全てのスクリプトが実行されます。 スクリプトの最初の 1文字はスクリプトの起動方法 を決定します。 K で始まる名前のスクリプトは、引数 stop を取って 起動されます。 S で始まる名前のスクリプトは、引数 start を取って 起動されます。 これらのスクリプトは名前のアルファベット順で起動されます。それゆえ、 "stop" スクリプトは "start" スクリプトより前に起動され、 KS に続く 2桁の数字はスクリプトの起動順序 を決定します。

実は、/etc/rcrunlevel.d/ ディレクトリにある スクリプトは、/etc/init.d/ にあるスクリプトの 単なるシンボリックリンクです。 これらのスクリプトは引数として "restart" や "force-reload" という 引数も受け取ります。システムのブート後にサービスを再起動 するためや、設定ファイルを再読み込みさせるためにこれらの引数を使えます。

例えば、

     # /etc/init.d/exim4 reload

のように使います。


2.4.3 ランレベルのカスタマイズ

ランレベルをカスタマイズするのは一歩進んだシステム管理者の仕事です。 ほとんどのサービスの場合、次に示すアドバイスが適用できます。

ランレベル R でサービス service を有効にするには、 ターゲットを ../init.d/service として シンボリックリンク /etc/rcR.d/Sxyservice を作成します。 シーケンス番号 xy はパッケージがインストールされた時の サービスに割り当てられたシーケンス番号と一致させてください。

サービスを無効にするには、名前が S で始まるのではなく K で始まるようにシンボリックリンクをリネームし、 シーケンス番号を 100-xy にします。

これらの目的には sysv-rc-confksysv のようなランレベルエディタを使うのが便利です。

特定のランレベルディレクトリにあるサービスのシンボリックリンクを リネームするのではなく削除することも可能です。 これはサービスを無効にしますが、sysv-rc の 初期化システムに関する限りに "floating" な状態に保ちます。 ランレベルを変更すると、サービスは起動されませんし、 停止もされませんが、起動しているかそうでないかにかかわらずそのままに 保たれます。 しかしながら、そのような浮いた状態にされたサービスは、 サービスを提供するパッケージがアップグレードされた場合、 アップグレード前に起動されているかにかかわらず起動されてしまうことに 注意してください。 これは現在の Debian システムの欠点として良く知られています。 又、ランレベル 0 と 6 では K で始まるサービスのシンボリックリンク を保持すべきであることに注意してください。 このサービスに対するシンボリックリンクを全て削除してしまうと、 アップグレードの際、出荷時の標準の状態にサービスを提供するパッケージが シンボリックリンクを回復させてしまいます。

/etc/rcS.d/ にあるシンボリックリンクにあらゆる変更を加える ことは推奨できません


2.5 多様性のサポート

Debian はシステムを壊さずにシステム管理者の希望を満たすためのいくつかの手段 を提供します。

/usr/local/ 以下のファイルはシステム管理者のものであり、 Debian は一切触りません。 /etc 以下のほとんどの ファイルは conffiles であり、 Debian はシステム管理者が明示的に要求しない限りアップグレード時に 上書きしません。


2.6 国際化

Debian システムは国際化されており、コンソール上ならびに X 上で 多種の言語の文字を表示し、入力するためのサポートを供給します。 たくさんのドキュメント、マニュアルページ、そしてシステムメッセージが 翻訳されており、翻訳されている言語は増加し続けています。インストール中、 Debian はユーザにインストール言語 (そして時々はローカル言語変数 )の選択を 促します。

あなたが必要な言語の機能全てをインストールしたシステムがサポート していない場合、又はあなたの言語をサポートするために言語の変更や、 異なるキーボードのインストールが必要な場合、ローカライゼーション (l10n), 第 9.7 節 をご覧ください。


2.7 Debian と kernel

Debian での Linux kernel, 第 7 章 をご覧ください。


2.7.1 非 Debian なソースから kernel をコンパイルする

header に関する Debian ポリシーを理解する必要があります。

Debian C ライブラリは kernel header の最新の stable リリースを用いて構築されています。

例えば、Debian-1.2 リリースは version 5.4.13 のヘッダを用いていました。 この慣習は全ての Linux FTP アーカイブサイトにおいて配布される Linux kernel ソースパッケージに対照しており、Linux kernel ソースパッケージはより最新 の header を使ってさえいます。kernel source により配布される kernel header は /usr/include/linux/include/ にあります。

libc6-dev により供給されるものより新しい kernel header を用いてプログラムをコンパイルする必要がある場合には、コンパイル時、コマンド ラインに -I/usr/src/linux/include/ を付け加える必要があります。 これは、例えば automounter daemon (amd) のパッケージング をする場合に使われます。新しい kernel が NFS を扱うための内部処理を変更した 場合、amd はそれを知る必要があるため、最新の kernel header を 含める必要性が発生します。


2.7.2 カスタム kernel 構築ツール

カスタム kernel を構築したい (する必要がある) 人は kernel-package パッケージのダウンロードが推奨されます。本パッケージには kernel パッケージ の構築用スクリプトが含まれ、次のようなコマンドを kernel ソースディレクトリの 最上段で実行するだけで Debian kernel-image パッケージを構築する機能を 供給します。

     # make-kpkg kernel_image

ヘルプは次のコマンドを実行すると得られます。

     # make-kpkg --help

また、マニュアルページ make-kpkg(1) 全体と Debian での Linux kernel, 第 7 章 も参照願います。

kernel-source-version (version は kernel バージョンを 表す) パッケージが得られない場合、好みの Linux アーカイブサイトから最新の kernel (又は選んだ kernel) のソースコードを別途ダウンロードする必要があります。 Debian の initrd ブートスクリプトは initrd と呼ばれる 特別な kernel patch を要求します。http://bugs.debian.org/149236 をご覧ください。

kernel-package パッケージの詳細な使用方法は /usr/share/doc/kernel-package/README.gz にあります。


2.7.3 モジュールを扱うための特別な準備

Debian の modconf パッケージはモジュールの設定を カスタマイズするために使用できるシェルスクリプト (/usr/sbin/modconf) を供給します。このスクリプトはメニュベースの インターフェースを表示し、システムのローダブルデバイスドライバに関する詳細に 対してユーザを促します。 その応答は /etc/modules.conf/etc/modules をカスタマイズするのに使用されます (これらにはブート時にロードされる モジュールがリストされています)。

カスタム kernel の構築をサポートするために得られる (新しい) Configure.help ファイルと同様に、modconf パッケージにはモジュールそれぞれに対して適切な引数についての詳細な情報を 供給する (/usr/share/modconf/ にある) ヘルプファイルが付属します。


2.7.4 古い kernel パッケージを削除する

kernel-image-NNN.prerm スクリプトは現在起動している kernel が削除しようとしている kernel と同じかどうかチェックします。それゆえ、 使わない kernel image パッケージを安全に次のコマンドを用いて削除できます。

     # dpkg --purge --force-remove-essential kernel-image-NNN

(もちろん、NNN を削除したい kernel のバージョンとリビジョンに 置き換えます。)


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ A ] [ 次のページ ]


Debian リファレンス

CVS, 2007年 1月 18日 木曜日 11時54分01秒 UTC時間

Osamu Aoki (青木 修) osamu#at#debian.org
翻訳: 角田 慎一 tsuno#at#ngy.1st.ne.jp
著者, 第 A.1 節