Debian JP Project

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]

Debian ポリシーマニュアル
Chapter 9 - オペレーティングシステム

9.1 ファイルシステムの階層構造

9.1.1 ファイルシステム構造

全てのファイルやディレクトリの配置は、それが他で記載されている Debian ポリシーの項目に違反しない限り、そして以下の例外を除いて、すべて Filesystem Hierarchy Standard (FHS) バージョン 2.3 に従わなければなりません。以下に FHS に対する例外を列挙します。

アプリケーションの、ユーザ固有の設定をユーザのホームディレクトリに置くというオプションルールが緩和されています。このようなファイルは、'.' 文字で始まるファイル (ドットファイル) とすることが推奨され、アプリケーションが一つ以上のドットファイルを作成する必要がある場合には、'.' 文字で始まるディレクトリ (ドットディレクトリ) 以下に置くことが推奨されています。また、後者の場合には設定ファイルを '.' 文字で始めないことが推奨されています。

amd64 が 64 ビットバイナリに対して /lib64 を用いなければならないという制約は撤廃されています。

オブジェクトファイル、内部で使うバイナリ、ライブラリ (libc.so.* を含む) は、/lib{,32} または /lib{,32} 以下に直接配置するという要求事項は改訂され、 /lib/triplet および /usr/lib/triplet 以下に置くことも許されています。ここで triplet は対象アーキテクチャでの dpkg-architecture -qDEB_HOST_MULTIARCH の返す値です。パッケージが、その対象アーキテクチャ以外の triplet パスにファイルをインストールすることは許されていません。例えば、Architecture: amd64 であるパッケージに 32-bit x86 向けライブラリが含まれている場合、それらのライブラリを /usr/lib/i386-linux-gnu にインストールすることは許されません [79]。

アプリケーションは、/usr/lib/triplet 以下にサブディレクトリを一つ作成して使うことも許されています。

実行時のリンカ・ローダ、ld* などは /lib または /lib64 以下の既存の場所に置くことが引き続き必須となっています。これは、この仕様が各アーキテクチャでの ELF ABI 仕様の一部であるためです。

/usr/local/share/man と、 /usr/local/man を同一視するという制約は、推奨に緩和されています。

ウィンドウマネージャが、system.*wmrc という名前の設定ファイルを一つだけ持つことを許されるという制約は撤廃されています。また、ウィンドウマネージャのサブディレクトリ名をウィンドウマネージャ名と同じにしなければならないという制約も撤廃されています。

ブートマネージャの設定ファイルを /etc 以下に置くか、少なくとも /etc にシンボリックリンクを置かなければならないという制約は、推奨に緩和されています。

root ファイルシステムに追加ディレクトリ /run があることは許されます。/run は /var/run を置き換えるもので、そのサブディレクトリ /run/lock は /var/lock を置き換えるものであり、/var 以下のディレクトリは後方互換性のためシンボリックリンクに置き換えられます。 /run と /run/lock は、FHS での /var/run と /var/lock に対する全ての要求 (ファイル命名規則、ファイルフォーマットの制限、ブート時のファイル初期化への要求など) に従っていなければいけません。/run にあるファイルおよびディレクトリは、一時ファイルシステムに格納されているべきです。

パッケージは、/run ディレクトリの存在を仮定してはならず、さらに Debian の安定版が /run をサポートするまでは initscripts (>= 2.88dsf-13.3) への依存の宣言なしに /run ティレクトリが利用可能であることも仮定してはいけません。

root ファイルシステムで、/sys ディレクトリが追加で許されるようになりました[80]。

GNU/Hurd システムでは、/hurd と /servers の 2 ディレクトリも、追加で root ファイルシステムに置くことが許されます [81]。

この文書で言及されている版は debian-policy パッケージと一緒に配布されていますし、このマニュアル付属以外では FHS (Debian copy) に、また debian-policy パッケージをインストールしているなら、 FHS (local copy) を見てください。最新版はこの文書で言及されている版より新しいかもしれませんが、 FHS (upstream) にあります。この標準に従うことに対する質問は debian-devel メーリングリストに送るか、もしくは FHS メーリングリスト (FHS web site 参照) に詳細を問い合わせて下さい。

9.1.2 サイト毎のプログラム

FHS に従うため、パッケージは /usr/local/ 以下にファイルをおいてはいけません。それが dpkg によって展開されるアーカイブファイルの中身であっても、メンテナスクリプトによって作成されるようなファイルであっても置いてはいけません。

しかし、サイト特有のファイルを置く場所がシステム管理者にわかるように、空のディレクトリを /usr/local 以下のディレクトリ中に作ることはかまいません。但し、これは /usr/local の直下ではなく、 /usr/local 下にあるディレクトリのサブディレクトリでなければなりません。これらのディレクトリ (/usr/local/*/dir/) は、パッケージの削除の際にそれが空であれば同時に削除される様になっていなければいけません。

このようなパッケージ固有のディレクトリを作成していいのは /usr/local より一段以上深い ディレクトリだけで、/usr/local 直下に作成してはいけないことに注意して下さい。パッケージから /usr/local ディレクトリ直下には FHS のセクション 4.5 に列挙されているサブディレクトリ以外のものを作成してはいけません。しかし、それら列挙されたディレクトリの下には自由にサブディレクトリを作ってもかまいません。もし自分で作ったディレクトリであったとしても、セクション 4.5 に列挙されているディレクトリは消してはいけません。

/usr/local がリモートのサーバからリードオンリーでマウントされていている場合に対処するため、それらのディレクトリは .deb アーカイブに含まれるメンテナスクリプトである postinst や prerm から作成や削除を行わなければいけません。これらのスクリプトはそういった作業に失敗しても、それ自身が落ちるようなことがあってはいけません。

例えば、emacsen-commonパッケージは、postinst に

     if [ ! -e /usr/local/share/emacs ]
     then
       if mkdir /usr/local/share/emacs 2>/dev/null
       then
         chown root:staff /usr/local/share/emacs
         chmod 2775 /usr/local/share/emacs
       fi
     fi

を含め、prermに

     rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
     rmdir /usr/local/share/emacs 2>/dev/null || true

を入れることになるでしょう (ここでこのスクリプトが割り込まれた際にもディレクトリ /usr/local/share/emacs が削除されるように書かれていることに注意してください)。

あるパッケージ用にローカルな追加をするために /usr/local 配下にディレクトリを作成した場合、 /usr/local 配下の設定が /usr 配下のものより優先されるよう保証しておくべきです。

しかし /usr/local とその中身は、ローカルの管理者が占有して利用する為にあるのであって、通常の利用においてパッケージが /usr/local 以下のファイルやディレクトリの有無に依存することがあってはなりません。

/usr/local ディレクトリ自身と、パッケージによって作成されたそのサブディレクトリは、標準設定のパーミッションとして 2775 (group 書き込み許可、group id セット) を、そしてオーナとしては root:staff を設定しておくべきです。

9.1.3 システムで使うメールディレクトリ

システムで使うメールディレクトリは /var/mail です。このディレクトリは基本システムの一部で、特定のメールエージェントに属しているべきではありません。以前の場所の /var/spool/mail は、スプールが依然として物理的にその場所に置かれている場合でも、使うべきではありません。

9.1.4 `/run` および `/run/lock`

ディレクトリ /run はブート時に初期化されます。通常は、この動作は一時ファイルシステムのマウントポイントとして実現されています。パッケージは、したがって、最後のリブート以降にそのパッケージが作成しているのでない限り、 /run/lock 以外のファイルまたはディレクトリの存在を仮定してはいけません。通常、このような作成はパッケージの init スクリプトで行われます。詳細はスクリプトの書き方, Section 9.3.2 を参照ください。

パッケージは、/run 以下、及び古い /var/run または /var/lock パス以下にファイルまたはディレクトリを収録していてはいけません。後者のパスは、今後は後方互換性のために /run 以下へ、シンボリックリンクまたは他の方法で転送されるようになります。

9.2 ユーザとグループ

9.2.1 はじめに

Debian システムは、平文のパスワードとシャドウパスワードのいずれの設定とすることも可能です。

一部のユーザ ID(UID) とグループ ID(GID) は特定のパッケージで使用するため、ディストリビューションとして予約されています。いくつかのパッケージではこれらのユーザやグループに所有されたファイルを同梱することが必要だったり、プログラムにこれらの ID をコンパイル時に組み込んだりする必要があるため、Debian システムではこれらの ID は割り当てられた目的のためだけに使用が許されています。これは重大な制限で、個々のサイトローカルな管理方針を取り入れてはいけません。特に多くのサイトではローカルなユーザやシステムグループの ID を 100 から順に割り振っていますので、この制約に注意してください。

これとは別に動的に割り当てられる ID があります。このような ID は所定の妥当な順で配置されていくようになっていますが、この配置の挙動は設定可能です。

base-passwd 以外のパッケージは /etc/passwd、 /etc/shadow、/etc/group および /etc/gshadow を変更してはいけません。

9.2.2 UID と GID の割り当て

UID と GID の割り当てを下記に示します。

0-99:

Debian プロジェクトで共通に割り当てられ、すべての Debian システムで同じ目的のために使われるものです。これらの ID はすべての Debian システムの passwd と group に現れ、base-passwd 更新の際にこの範囲にある ID は自動的に追加されます。

静的に割り当てられた uid や gid が必要なパッケージはこの範囲の ID を使わなければなりません。当該パッケージのメンテナは ID を base-passwd のメンテナに割り当ててもらう必要があります。

100-999:: 動的に割り当てられるシステム用のユーザアカウントです。パッケージでユーザやグループの割り当てが必要ではあるけれども、それらが動的に割り当てられた、システム毎に異なるものでも構わない場合には、 adduser --system を使ってこの範囲のユーザやグループを作成してください。 adduser は個々のユーザやグループの有無をチェックします。また必要なら adduser.conf の範囲指定で使わない ID を選択してください。

1000-59999:: 動的に割り当てられるユーザアカウントです。標準設定の adduser はこの範囲の UID と GID を割り当てますが、この動作は adduser.conf で変更することができます。

60000-64999:

Debian プロジェクトとして共通に割り当てているものですが、要求に応じて作成されます。ID 自体は集中管理で、静的に割り当てられているものですが、実際のアカウント作成は必要になった時点で行われます。

これらの ID はあまり使われないパッケージや、多くの静的に割り当てられた ID を必要とするパッケージのためのものです。このようなパッケージでは /etc/passwd や /etc/group を調べて、(adduser があるなら使って) 必要に応じてアカウントを作成しなければいけません。引き続いて ID を要求していく可能性のあるようなパッケージでは、割り当てた ID の後に将来の追加のために保留部を残しておかなければいけません。

65000-65533:: 予約されています。

65534:: ユーザ nobody に割り当てられています。対応するグループ id はグループ nogroup に割り当ててください。

65535:: (uid_t)(-1) == (gid_t)(-1) です。この値はエラー検出判定に用いるため、使わないでください。

9.3 システムランレベルと `init.d` スクリプト

9.3.1 はじめに

/etc/init.d ディレクトリにはブート時と init の状態 (ランレベル) が変わったときに (init(8) 参照)、init に実行されるスクリプトが納められています。

これらのスクリプトを用いるにあたり、少なくとも二つ (機能上は等しいものですが) の方法があります。簡単のため、このドキュメントではシンボリックリンクによる方法のみを記します。しかし、メンテナスクリプト中でこの方法だけが用いられていると思い込んではなりません。また、それぞれのランレベルの挙動に対する操作は、手でシンボリックリンクを作成または削除することで実行せず、後述するように update-rc.d によって行われなくてはなりません。 file-rc パッケージで実装されている、もう一つの方法による実装の詳細については、当該パッケージのドキュメントを参照して下さい。

これらのスクリプトは /etc/rcn.d ディレクトリの中からシンボリックリンクが張られています。ランレベルを変更すると、initは /etc/rcn.d ディレクトリ内を見て、実行すべきスクリプトを探します。ここで n は、これから変更されるランレベルを示します。また S はブート時のスクリプトを指します。

リンクの名前は全て Smmscript か Kmmscript の形をとっています。ここで mm は二桁の数字で、script はスクリプトの名前を示しています (この名前は /etc/init.d 内の実際のスクリプトと同一の名前にしておくべきです)。

init がランレベルを変更したとき、まず名前が K で始まるシンボリックリンクの先のスクリプトが、それぞれ stop オプション付きで実行されます。次に S で始まるスクリプトが start オプション付きで起動されていきます (リンクは新しいランレベルに対応した /etc/rcn.d ディレクトリに置かれたものです)。K で始まる名前でリンクを張られたものは、サービスを停止することに対応し、S の方は、そのランレベルになる時にサービスを開始することを示します。

例えば、ランレベル 2 から 3 へと移行したとします。 init は、まず /etc/rc3.d/ にある全ての K で始まるスクリプトを、その後そのディレクトリの S で始まるスクリプトを実行していきます。K で始まるものはそれぞれに対応したファイルを stop オプション付きで、そして S で始まるリンク先を start オプション付きで実行します。

mm で示した二桁の数字は、スクリプトの実行順序を決定するのに用いられます。ここでは小さい数字から順番に実行されます。例えば K20 というふうに始まるスクリプトは K30 で始まるものよりも先に実行されます。あるサービスが他のサービスよりも先に開始していなければならないときに使うわけです。例えば、ネームサーバ bind はニュースサーバ inn がアクセスリストをセットアップできるよう、先に起動しておく必要があるでしょう。このケースでは bind を起動するスクリプトは inn を起動するものよりも小さい番号にします。

     /etc/rc2.d/S17bind
     /etc/rc2.d/S70inn

ランレベル 0 (halt) と 6 (reboot) の二つは多少異なります。この二つのランレベルでは S で始まるスクリプトが K で始まるスクリプトの後に実行されるという点では他と変わりませんが、どちらも引数 stop 付きで実行されます。

9.3.2 スクリプトの書き方

システムサービスを行うデーモンを含むパッケージは、ブート時やランレベル変更時にサービスを開始及び停止させるため、 /etc/init.d にスクリプトを置くべきです。このスクリプトは、/etc/init.d/package という名前にすべきで、何を行うかを指定する一つの引数を取るようにすべきです。

start: サービスを開始します。

stop: サービスを停止します。

restart: サービスが既に実行中ならサービスを停止し、再起動します。そうでないなら、サービスを開始します。

reload: サービスを停止したり再起動することなく、サービスの設定を再読み込みします。

force-reload: サービスが設定の再読み込みに対応しているならば再読み込みを行ないます。対応していないなら再起動します。

start、stop、restart、 force-reload の各オプションは /etc/init.d 内の全てのスクリプトがサポートしていなければなりませんが、 reload オプションのサポートは任意です。

init.d スクリプトは、該当するサービスが既に起動しているのに start オプション付きで実行された場合の動作に慎重さをもって (即ち、実行時に成功を返し、複数のサービスのコピーを同時に起動しない) 実行されるようにしなければなりません。逆に起動していないのに stop オプション付きで実行された際には、他のユーザプロセスを落さないようにしなければなりません。これを実現するのに通常最良の方法は start-stop-daemon に --oknodo オプションをつけて用いるようにすることです。

init.d スクリプトで set -e を使う場合は注意してください。正しい init.d スクリプトでは、デーモンが既に実行されていた、またはすでに異常終了ではなく停止していたなどの様々な異常終了状態を受け付ける必要があり、共通に使われる init.d 関数ライブラリは、set -e を付けた安全な呼び出しが行えない [82] 可能性があります。init.d スクリプトでは、多くの場合 set -e を使わずに個々のコマンドの結果を別々にチェックするほうが容易です。

もしサービスが設定を自動的に再読み込みするような場合 (例えば cron などで)、init.d スクリプトに付けられた reload オプションは、再読み込みに成功したかのように振る舞う必要があります。

/etc/init.d は、conffile としてマークされている場合 (パッケージ中に、つまり .deb ファイルに含まれている場合) と、メンテナスクリプト中から適切に扱う (パッケージ中に含まれていない場合。設定ファイル, Section 10.7 参照。) 場合のいずれも、設定ファイルとして扱わなければいけません。これはローカルのシステム管理者がローカルに向けてスクリプトを修正できるようにしたいため、重要です。つまり、パッケージを削除することなくサービスを止めたい、またはサービスを開始する際に何か特別のコマンドラインオプションを与えたい、という場合にその人の修正を次のパッケージアップグレードの際に失われることがないようにしたいのです。

パッケージ自体が削除されていても設定ファイルはシステムに残っているため、その状態でこれらのスクリプトは不可解な落ち方をしないようにすべきです。 dpkg は --purge オプション付きで実行されて初めて設定ファイルを削除します。特に /etc/init.d/package スクリプト自体も通常 conffile ですので、パッケージが削除されても、上記オプションが指定されて完全削除されていない場合ではスクリプトはシステムに残ったままになっています。このため、次のように test 文をスクリプトの先頭に置くべきです。

     test -f program-executed-later-in-script || exit 0

init.d スクリプト中にはスクリプトの動作を制御するために使われ、管理者がしばしば変更したいような値をいくつか含む場合が良くあります。スクリプトは多くの場合 conffile ですので、スクリプトを変更した場合管理者がパッケージアップグレードの際に毎回変更された conffile に対してローカルの変更をマージする必要があります。このシステム管理者の負担を軽減するため、そのような設定可能な値はスクリプト中に直接書くべきではありません。その代わりに、そのような値は /etc/default 中のファイルによって与えます。このファイルは通常 init.d スクリプトと同じ名前にしてください。この追加ファイルはスクリプトを実行する際に参照されます。このファイルに SUSv3 sh フォーマット形式の変数設定と、コメント以外を書かないでください。また、これは conffile とするか、またはパッケージのメンテナスクリプトで処理される設定ファイルとすべきです。詳細は、設定ファイル, Section 10.7 の節を参照ください。

必要な設定値がいつも存在していることを保証するため、 init.d スクリプト中で /etc/default/ ファイルを取り込む前に各シェル変数に標準値を設定するか、取り込んだ後に ${VAR:=default} の書式を使って設定するかのいずれかとして置いてください。また、init.d スクリプトは /etc/default/ が消されていた場合にも失敗することなく妥当に振る舞わなければいけません。

/run 以下のファイルまたはディレクトリ、および後方互換性のためのパス /var/run および /var/lock 経由のファイルまたはディレクトリは、通常は一時ファイルシステム上に格納され、通常リブート間では保持されません。 init.d スクリプトはこの挙動を正しく扱うことが出来なければいけません。これは、典型的には必要なサブディレクトリを init.d 実行時に動的に作成するという事です。詳しくは /run および /run/lock, Section 9.1.4 を参照ください。

9.3.3 initscript システムとのインターフェース

メンテナは、自分のパッケージの、例えば postinst、 prerm や postrm のような initscript 群を扱う際に update-rc.d と invoke-rc.d で提供される抽象化の機構を使うべきです。

直接 /etc/rc?.d リンクを操作し、直接 /etc/init.d/ initscript を起動して良いのは、initscript サブシステムを提供するパッケージ (例えば sysv-rc および file-rc) に限られるべきです。

9.3.3.1 リンクの取り扱い

/etc/rcn.d のシンボリックリンクの作成と削除 (前に触れたもう一つの方法を用いている場合には機能的に等価な処理になります) の作業をパッケージメンテナが適切に行うため、 update-rc.d というプログラムが配布されています。このプログラムは、メンテナがパッケージ内の postinst や postrm スクリプトの中で使います。

/etc/rcn.d 内のシンボリックリンクを直接アーカイブに含めたり、メンテナスクリプトによってシンボリックリンクの作成及び削除を行ってはいけません。その代わりに update-rc.d プログラムを使わなければいけません。 (前者の方法は、ランレベル情報の取り扱いをもう一つの方法で行っている場合には正しく動作しません)。 /etc/rcn.d ディレクトリ自体をアーカイブに含めるのもいけません (これが許されているのは、sysvinit パッケージだけです)。

デフォルトでは、update-rc.d はマルチユーザ状態の各ランレベル (2,3,4,5) にて各種サービスを開始させ、 halt(0)、シングルユーザ(1)、リブート(6) の各ランレベルでは停止するようにします。システムの管理者は、シンボリックリンクによる管理がなされている場合には /etc/rcn.d のシンボリックリンクを追加、移動、削除することによって、また、 file-rc による方法で管理されていれば /etc/runlevel.conf を変更することによって、ランレベルをカスタマイズすることができます。

自分のパッケージをデフォルトの挙動を持つものとして設定するには、 postinst スクリプトに次のように書きます。

     	update-rc.d package defaults

postrm では次のようになります。

     	if [ "$1" = purge ]; then
     		update-rc.d package remove
     	fi

あなたのパッケージのランレベルや優先順位を変更した場合、古いリンクが残ってしまうためリンクを削除したり再作成したりする必要があるかもしれないことに注意してください。 update-rc.d の解説文書を参考にしてください。

この方法ではデフォルトのシーケンス番号として 20 が使われます。 init.d スクリプトを動かす際、順序が問題にならないならば、このデフォルトを使うようにして下さい。そうでなければ sysvinit パッケージのメンテナと連絡をとるか、 debian-devel にポストしましょう。番号の選択について手助けしてもらえるはずです。

update-rc.dの使い方に関する情報は、man update-rc.d(8) を見て下さい。

9.3.3.2 initscript を実行する

invoke-rc.d プログラムは、パッケージメンテナが initscript を適切に (ランレベルに従い、またそのほかのパッケージが開始できる状況を制限するローカルでの制約を満たして) 起動する作業を容易にするために提供されています。このプログラムは、パッケージのスクリプト中で、メンテナが使うことができます。

プログラムは、/etc/init.d/* initscript を起動するのに、それらを直接起動するのではなく invoke-rc.d を用いるようにしなければなりません。

標準では、invoke-rc.d は動作の要求 (start、stop、 reload、restart など) を、意図したランレベル外での start および restart をフィルタするだけで、そのまま /etc/init.d に渡します。

ほとんどのパッケージでは、postinst と prerm スクリプトで、

     /etc/init.d/<package>
     	      <action>

を単に以下のように変更すればいいはずです。

     	if which invoke-rc.d >/dev/null 2>&1; then
     		invoke-rc.d package <action>
     	else
     		/etc/init.d/package <action>
     	fi

パッケージは invoke-rc.d を用いて起動する前に update-rc.d を使って initscript サービスを登録しておく必要があります。未登録のサービスの起動は失敗するかもしれません。

invoke-rc.d の使い方に関する情報は、 invoke-rc.d(8) を見てください。

9.3.4 ブート時における初期化

ホストをブートした時に一度だけ実行されるスクリプトをまとめた /etc/rc.boot なるディレクトリが昔は存在しましたが、はじめに, Section 9.3.1 でも記載した通り、/etc/rcS.d から /etc/init.d 内のファイルへのリンクに置きかえることが強く推奨されています。パッケージが /etc/rc.boot にファイルを置くことは許されていません。

9.3.5 実例

あなたの /etc/init.d スクリプトのベースとなるサンプルは /etc/init.d/skeletonにあります。

9.4 `init.d` スクリプトからのコンソールメッセージ

この章では /etc/init.d 内のスクリプトが標準出力に書き出す各種のメッセージの書式について述べます。この規定の狙いは Debian の起動とシャットダウン時の見栄えをより一貫したものとすることです。このため、細部にわたって、注意深く読んでください。空白や句読点、大文字小文字の使い分けなどが同じフォーマットに従うようにしようと考えています。

まず、/etc/init.d スクリプトで出力メッセージを作成する際に使うべき基本的なルールを示します。

メッセージは一行に書かれ、大文字で始まり、ピリオド (.) と改行 ("\n") で終えなければなりません。

スクリプトがバックグラウンドで時間のかかる処理を行っている場合 (単にプログラムの開始や終了ではなく、特定の作業が進行中である場合などです) "省略符号" (ellipsis。すなわち、三つのドット ... で、前後に空白や改行は入れません) を使います。

コンピュータが何をしているのか教えようとするかのように丁寧に :-) メッセージを作成してください。但し、コンピュータ自体を主語としては使わないでください。例えば、
```
     I'm starting network daemons: nfsd mountd.
```
と表現したいならば、単に次のようにしてください。
```
     Starting network daemons: nfsd mountd.
```

init.d スクリプトでは、以下の標準の書式を場合分けに対応して使ってください。

デーモンを開始するとき

スクリプトが一つ以上のデーモンを起動するときには、次の書式を使います。出力は次のようにしてください (1 行にし、最初に空白は入れません)。
```
     Starting description: daemon-1 ... daemon-n.
```
description は対象となる一つまたは複数のデーモンの属するサブシステムについて記述してください。 daemon-1 から始まって daemon-n までは各デーモンの名前 (通常はそのプログラムのファイル名) を記載してください。

例えば /etc/init.d/lpd の出力は次のようになります:
```
     Starting printer spooler: lpd.
```
このように出力するためにスクリプト中では次のようにしています。
```
     echo -n "Starting printer spooler: lpd"
     start-stop-daemon --start --quiet --exec /usr/sbin/lpd
     echo "."
```
一つ以上のデーモンを起動するときは次のようにします:
```
     echo -n "Starting remote file system services:"
     echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
     echo -n " mountd"; start-stop-daemon --start --quiet mountd
     echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
     echo "."
```
これによりユーザは現在何が起こっているのか、またいつ最後のデーモンが起動したのかを知ることができます。スペースをどこに置くかに気をつけるべきです。上記の例では、既に述べたように、システム管理者が特定のデーモンを起動したくないときには簡単にコメントアウトできますし、その場合でもメッセージはきちんと表示されます。

システムパラメータをセットするとき

起動時にシステムの設定を変更するときには、次のような書式を使うべきです。
```
     Setting parameter to "value".
```
引用符が正しくなるようにするには、次のような行が使えます。
```
     echo "Setting DNS domainname to \"$domainname\"."
```
同じ二重引用符 (") が、左右の引用符として使われていることに注意してください。グラーヴアクセント (`) は引用符ではありません。アポストロフィ (') も違います。

デーモンを停止または再起動するとき

デーモンを止める、または再起動するときのメッセージの書式は起動時のメッセージに準じ、 Starting を Stopping ないし Restarting に変えたものです。

プリンタデーモンを止める時の出力を例にすると、次のようになります。
```
     Stopping printer spooler: lpd.
```

何かを実行しているとき

システムの開始時やシャットダウン時に特定の処理を行うためにプログラムを実行しなければならないようなことはよくあります。例えば netdate でシステムの時計を合わせたり、システム終了時に全てのプロセスを止めたりする場合などです。このような場合のコンソールメッセージは次のようになります。
```
     Doing something very useful...done.
```
作業が終了した後は直ぐに done. を表示し、ユーザに何故待たされていたのかを知らせなければいけません。これは次のようにスクリプトに書きます。
```
     echo -n "Doing something very useful..."
     do_something
     echo "done."
```

設定を再読み込みするとき

デーモンが設定ファイルを再読み込みするときは、次の書式を使ってください。
```
     Reloading description configuration...done.
```
ここで、description の部分はデーモンを開始するときと同じです。

9.5 Cron ジョブ

パッケージは /etc/crontab 設定ファイルを変更してはいけません。また、/var/spool/cron/crontabs 内のファイルを変更してもいけません。

パッケージが cron で実行されるようなジョブをインストールしたいときは、下記のディレクトリに Cron ジョブファイル名称, Section 9.5.1 で規定された仕様に沿った名前を持つファイルを置いてください。

     /etc/cron.hourly
     /etc/cron.daily
     /etc/cron.weekly
     /etc/cron.monthly

これらのディレクトリの名前が示す通り、これらの中のファイルはそれぞれ、毎時 (Hourly)、毎日(daily)、毎週(weekly)、毎月(monthly) 実行されます。正確な時刻は /etc/crontab に記載されています。

これらのディレクトリにインストールされた全てのファイルは、ローカルシステムの管理者が簡単に変更できるようにスクリプト (シェルスクリプト、perl スクリプトなど) でなければいけません。また、設定ファイル (設定ファイル, Section 10.7参照) として扱わなければいけません。

これ以外の頻度、あるいは指定時刻に実行する必要のあるジョブがある場合には、パッケージは /etc/cron.d ディレクトリに Cron ジョブファイル名称, Section 9.5.1 で規定された仕様に沿った名称のファイルをインストールしてください。このファイルは /etc/crontab と同じ書式で、cron により自動的に実行されます。このファイルも設定ファイルとして扱わなければいけません (注記：この /etc/cron.d の中のエントリは anacron では処理されないので、ここに置くジョブはシステムが停止しているときには行う必要がないものに限られます)。

The Open Group から取得できる IEEE Std 1003.1-2008 (POSIX.1) で記載された crontab とは異なり、 /etc/cron.d のファイル、および /etc/crontab は 7 つのフィールドを持ちます。具体的には

分 [0,59]

時 [0,23]

月中の日付 [1,31]

月 [1,12]

曜日 ([0,6] with 0=Sunday)

ユーザ名

実行するコマンド

数字の範囲が指定できます。範囲は、ハイフンで分離した二つの数字で指定します。指定する範囲は排他的ではありません。また、リストも許されます。リストは、一連の数字 (または数字の範囲) をカンマで区切って指定します。範囲と飛び飛びの値は併用できます。

これらのディレクトリにあるスクリプトまたは crontab エントリは、実行する前に必要なプログラムがインストールされているかをチェックするようになっていなければいけません。そうしないと、パッケージをパージ (完全削除) ではなく単に削除したときには設定ファイルがシステムに残ったままになっているので、問題が起きてしまいます。

cron デーモンは、/usr/bin/crontab と POSIX 規定に従った crontab サポートを提供しなければいけません。またデーモンは月日の名前、範囲、飛び飛びの値などをサポートしなければいけません。また /etc/crontab をサポートし、/etc/cron.d のスクリプトを正しく実行しなければいけません。また、デーモンは /etc/cron.{hourly,daily,weekly,monthly} 中のスクリプトを正しく実行しなければいけません。

9.5.1 Cron ジョブファイル名称

cron ジョブのファイル名は、通常はそのジョブを提供したパッケージの名称と同じにすべきです。

パッケージが複数の cron ジョブファイルを同じディレクトリに置く場合、ファイル名はパッケージ名 (以下の修正も必要かもしれません) で始まり、ハイフン (-) と適切な接尾子をつけるようにすべきです。

cron ジョブ名には、ピリオド . やプラス文字 + を含めることは許されません。含まれていた場合には、cron から無視されます。 . や + の代わりにアンダースコア (_) を使うべきです。

9.6 メニュー

Debian の menu パッケージはアプリケーションを提供するパッケージと メニュープログラム (X window マネージャや、 pdmenu のようなテキストベースのメニュープログラム) の間の標準インターフェースを提供します。

通常の操作において特別な引数を必要としないアプリケーションを提供する全てのパッケージは、そのアプリケーションに対してメニューエントリ (menu entry) を登録します。こうすれば menu パッケージを使うユーザはウィンドウマネージャ内や、pdmenu のようなシェルからメニューを自動的に取得できます。

Menu エントリは現在の Menu ポリシーに従う必要があります。

Menu ポリシーは debian-policy パッケージに menu-policy ファイルとして同梱されています。また、 Debian ウェブミラーサイト /doc/packaging-manuals/menu-policy/ にもあります。

アプリケーションや web 文書を登録する方法の詳細については、 menu パッケージに付属する Debian メニューシステム ドキュメントを参照してください。

9.7 マルチメディアハンドラ

MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) とはファイルやデータストリームを符号化し、それに関するメタ情報、特に種別 (音声や画像) とフォーマット (PNG、HTML、MP3 など) などの付随情報を付加するための機構です。

MIME タイプを登録することで、メール受信ユーザプログラムやウェブブラウザがそれ自身で直接扱えない MIME タイプの表示や編集などをハンドラを呼び出すことで行うことができるようになります。

ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能をもつプログラムは mailcap(5) フォーマット (RFC 1524) を用いてディレクトリ /usr/lib/mime/packages/ にファイルを置くことにより登録を行う必要があります。ここでのファイル名はバイナリパッケージ名です。

mime-support パッケージが update-mime プログラムを提供しています。このプログラムが /etc/mailcap ファイル中の上記の登録情報を dpkg からのトリガで統合します[83]。この機能を用いるパッケージは、mime-support に対する依存 (depend)、推奨 (recommend), 推奨 (suggest) 等を宣言する べきではありません。

9.8 キーボード設定

システムで一貫したキーボードの設定、具体的にはすべてのアプリケーションがキーボード打鍵イベントを同じように解釈するようにするために、 Debian ディストリビューションのプログラムは下記のガイドラインに従わなければなりません。

以降の特定のキーは記載の解釈としなければいけません。

<--: カーソルの左の文字を削除する

Delete: カーソルの右の文字を削除する

Control+H: emacs では一連のヘルプを呼び出す

terminal emulator, an rlogin/telnet session, etc.--> キーボード打鍵イベントの解釈はそのとき使っている端末 (仮想コンソールや X 端末エミュレータ、rlogin/telnet セッションなど) に依存しないものでなければいけません。

下記のリストは異なったプログラムでこれを実現するための説明です。

<-- X 環境ではバックスペースキーイベント (KB_BackSpace) を起こします

Delete X 環境では Delete キーイベント(KB_Delete)を起こします

X 環境ではバックスペースキーイベント (KB_Backspace) は ASCII の DEL を生成し、Delete キーイベント (KB_Delete) では ESC [ 3 ~ (これは vt220 のデリートキーのエスケープシーケンスです) を生成するように設定します。これは全 X 表示画面に対して xrdb でリソースをロードすることで設定します。アプリケーションの標準設定値の変更はしません。これは xmodmap 設定とここでの解釈のリソースを一致させるためです。

Linux コンソールは <-- は DEL を、 Delete キーは ESC [ 3 ~ を生成するように設定されています。

X アプリケーションは <-- キーはカーソルの左を、 Delete キーは右を消すように設定します。Motif アプリケーションは既にこうなっています。

ターミナルでは stty erase は ^? と設定します。

xterm の terminfo エントリは kdch1 に ESC [ 3 ~ を設定します。TERM=linux と TERM=vt220 も同様です。

Emacs はバックスペースキーイベント (KB_Backspace) と、stty erase で設定されたキーイベントは delete-backward-char にマップされ、Delete キーイベント (KB_Delete) と kdch1 は delete-forward-char にマップされ、^H は常にヘルプの呼び出しになるようプログラムされています。

他のアプリケーションでは stty erase と kdch1 は二つの delete キーとして、ASCII DEL 文字は前の文字を消すように、kdch1 はカーソルの下の文字を消すようにします。

これで大部分の問題は解決しますが、以降に例外に属する処理について記しておきます。

一部のターミナルでは <-- キーで ^H 以外のコードを生成することができません。このようなターミナルでは、Emacs のヘルプを ^H で呼ぶことができません (Emacs では stty erase の設定の方が優先され、かつ正しく設定されているという前提の下です)。 M-x help または F1 (あれば) を代わりに使うことができます。

一部の OS は ^H を stty erase の文字に使います。ただ、最近の telnet やすべての rlogin プログラムは stty 設定を引き継ぎますし、ほとんどすべての UNIX 類は stty erase の設定を尊重します。 stty 設定が正しく引き継がれない場合には、 stty を手動設定して正しく動くようにしてください。

一部のシステム (以前の Debian の版もそうでした) では <-- キーと Delete キーが Delete キーイベント (KB_Delete) を起こすよう xmodmap で設定しています。このようなシステムの X クライアントのふるまいを、私たちの環境と同じ X リソースを使って変えることもできますし、逆の場合にはこのようなシステムのリソースで私たちのクライアントを設定することもできます。このようにして設定したシステムでは Delete はたぶん動きませんが、 <-- の方は正しく動作します。

一部の OS では xterm などの端末設定の terminfo データベース中の kdch1 に別の設定がされています。このようなシステムに、このポリシーに従ったシステムからログインした場合には Delete キーは正しく動作しませんが、 <-- は正しく動作します。

9.9 環境変数

プログラムは妥当な結果を得るために特定の環境変数の設定に依存するものであってはいけません。これはこのような環境変数はシステム全体に影響を及ぼす /etc/profile のような設定ファイルで設定しなければなりませんが、このような設定ファイルがすべてのシェルでサポートされているわけではないためです。

プログラムが通常環境変数の設定に依存する場合、環境変数が設定されていなかった場合に妥当な標準設定値を使うように修正するようにすべきです。これがもし容易に行えないようなら (例えば non-free プログラムでソースコードがない場合など) プログラムは環境変数を設定して元のプログラムを呼び出すようなラッパスクリプトに置きかえておかなければいけません。

この目的のためのラッパスクリプトを次に示します。

     #!/bin/sh
     BAR=${BAR:-/var/lib/fubar}
     export BAR
     exec /usr/lib/foo/foo "$@"

更に /etc/profile は base-files パッケージの設定ファイルですので、他のプログラムはこのファイルに環境変数やそのほかのコマンドの設定を追加してはいけません。

9.10 doc-base を用いて文書を登録する

doc-base パッケージは文書を扱ったり表示したりするための柔軟な枠組を提供します。おすすめのやりかたは、オンライン文書 (単なる man ページだけではなく) を提供している Debian パッケージでは、その文書を doc-base に登録する方法です。これには、 doc-base コントロールファイルを、 /usr/share/doc-base/ にインストールします。

詳細については、doc-base パッケージの付属文書を参照ください。

9.11 代替 init システム

sysvinit パッケージの代替として利用できる init システムが現在 Debian でいくつか提供されています。この代替となる init 実装は、互換性のためシステムランレベルと init.d スクリプト, Section 9.3 で文書化された SysV init スクリプトの実行をサポートしなければいけません。

パッケージは、これらの代替 init システムに実装依存の設定情報を統合して提供しても構いません。この設定情報には、サービスをスタートする方法とタイミング、ブート時に特定のタスクを実行する順番などが含まれます。但し、他の init システムを統合するパッケージでは、init 関連のジョブに対して sys-V 書式の同等の機能を提供する init スクリプトを後方互換性のために提供しなければいけません。これは sys-V 書式が、全ての init 実装でサポートされていることが保証された唯一の書式であるためです。この規則の例外は、init 実装そのもので提供されているスクリプトやジョブで、このようなジョブは /etc/rcS.d/ の実装依存の互換機能を提供するために必要になる場合があり、init スクリプトと 1 対 1 の関係を持たないかもしれないためです。

9.11.1 upstart によるイベントベースのブート

パッケージは、/etc/init ディレクトリにジョブファイルを配置することにより、イベントベースのブートシステム upstart と統合することも可能です。 Upstart と同等の機能を提供する SysV init スクリプトの側では、 initctl version コマンドの結果に upstart という文字列の有無を確認して、upstart ネイティヴのジョブとの重複実行を避けなければいけません。テストは以下のように行います。

     if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
     then
     	exit 1
     fi

upstart 向けのジョブを含んだパッケージを upstart を用いていないシステムにインストールしても構わないため、メンテナスクリプトでは共通の update-rc.d と invoke-rc.d インターフェースを用いてランレベルの設定や、サービスの開始と停止を行わなければいけません。このようなメンテナスクリプトでは、upstart の start、 restart、reload、stop の各インターフェースを直接呼び出してはいけません。代わりに、invoke-rc.d の実装で upstart が実行されているかどうかを検出し、upstart のジョブと同じ名前の init スクリプトが存在する場合には、init スクリプトではなく upstart ジョブを用いて要求された動作を行わなければいけません。

SysV init スクリプト向けの依存関係ベースのブートマネージャ (例えば startpar) は、相当する upstart ジョブが存在する場合には、何もしない init スクリプトでの不要な fork を避けるために、与えられた init スクリプトの実行を全く行わなくとも構いません。この場合には、ブートマネージャは、いつ依存関係が満たされたかを確認するために、対象となる upstart ジョブが実行中か停止中かの判定を行うことができるよう、upstart と統合すべきです。