Product SiteDocumentation Site

7.2. 常套手段

この節の目的は、管理者が頻繁に実行する特定の操作に関する、いくつかの一般的なヒントを示すことです。もちろんこれらの手順は包括的にすべての考え得る場合をカバーするものではありませんが、より困難な状況に直面した際の出発点として機能します。

7.2.1. プログラムの設定

未知のパッケージを設定する場合、段階を追って進まなければいけません。最初に、パッケージメンテナの書いた文書を読んでください。/usr/share/doc/package/README.Debian を読むことで、そのソフトウェアを簡単に使うための特別規則を学ぶことが可能です。このファイルには、プログラムの元の挙動 (HOWTO などの一般的な文書に書かれている挙動) からの違いが書かれているため、必ず読まなければいけない場合があります。またこのファイルには、ありふれた問題で時間を無駄にするのを避けるために、最も一般的なエラーの詳細も書かれています。
その後、ソフトウェアの公式文書を確認してください。既存のさまざまな文書源を見つける方法は第 7.1 節「情報源となる文書」を参照してください。dpkg -L package コマンドでパッケージに含まれるファイルのリストが表示されます。さらに、このコマンドを使えば、利用できる文書 (と同時に /etc/ に格納された設定ファイル) を素早く特定することも可能です。dpkg -s package でパッケージのメタ情報が表示されるので、そこから推奨パッケージや提案パッケージが分かります。さらにそこから、ソフトウェアの設定を簡単に行うための文書またはユーティリティを見つけることも可能です。
最後に、設定ファイルには通常、各設定項目に関して設定できる値をそれぞれ詳細に説明した説明用コメントが数多く書かれています。このため、利用できる行を選んで有効化するだけで十分な場合もあります。また、設定ファイルの例が /usr/share/doc/package/examples/ ディレクトリの中に格納されている場合もあります。設定ファイルの例は、自分の設定ファイルのたたき台になります。

7.2.2. デーモンの挙動を監視する

デーモンの挙動を理解するのはやや面倒です。なぜなら、デーモンは管理者と直接的に対話するものではないからです。デーモンが実際にどのような作業をしているかを確認するには、デーモンをテストする必要があります。たとえば、Apache (ウェブサーバ) デーモンの挙動を確認するには、HTTP リクエストを使ってテストします。
この種のテストを行うために、デーモンは通常自分のしたことだけでなく発生したエラーも含めてすべてを「ログファイル」や「システムログ」と呼ばれるログに記録します。ログは /var/log/ の中か、このディレクトリのサブディレクトリの中に保存されます。それぞれのデーモンの正確なログファイル名を知るには、文書を確認してください。そのテストによって考え得る使用例のすべてが満足されない限り、テストは必ずしも 1 回で十分とは限らない点に注意してください。さらに、いくつかの問題は特定の状況下でしか起こりません。
問題に対する予防手段として、管理者は日常的に最も重要なサーバログを読むべきです。そうすれば、不満を抱くユーザから報告を受ける前に問題を調査できます。実際のところ、ユーザは報告の前に問題が数日間にわたって繰り返して起こるまで待つかもしれません。長いログファイルの内容を分析するには専用ツールを使います。数多くのサーバに対して専用のログ分析ツールが存在し、特にウェブサーバ (Apache 向けの analogawstatswebalizer)、FTP サーバ、プロキシ/キャッシュサーバ、ファイアウォール、電子メールサーバ、DNS サーバ、プリンタサーバに対してはそのログを解析するユーティリティが存在します。いくつかのユーティリティはモジュール式で機能し、複数のログファイルを解析できます。lire はそのようなユーティリティの一例です。また、ログファイルから対処が必要な警告を検索する logcheck (第 14 章「セキュリティで紹介するソフトウェア) などの他のツールも存在します。

7.2.3. メーリングリストで助けを求める

いろいろと検索しても問題の原因が分からなかった場合、他の人 (おそらく自分よりも経験豊富な人) から助けを受けることも可能です。 メーリングリストはまさにこのために用意されています。他のコミュニティと同様、このメーリングリストにも従う必要のあるルールが存在します。どんな質問でもそれを投稿する前に、メーリングリストに最近投稿された議論および公式文書の中で、自分の問題がまだ取り上げられていないという点を確認するべきです。
前述の 2 条件を満足した時点で、問題の内容をメーリングリストに投稿してみてください。投稿の際には、関連する情報をできる限り含めるようにしてください。ここで関連する情報とは、実施したさまざまなテスト、参照した文書、その問題を診断する際に使った方法、関連するか関連する可能性のあるパッケージなどを指します。さらに Debian バグ追跡システム (BTS、補注TOOL バグ追跡システム」を参照してください) で同様の問題がないか確認し、検索の結果を挙げ、見つかったバグへのリンクを提供してください。以下から BTS を使い始めることが可能です。
礼儀正しく正確であればあるほど、答えを得られる (少なくとも多少の反応を得られる) チャンスが大きくなります。私信で関連する情報を受け取った場合、その情報を要約して公にすることを考えてください。そうすれば、他の人がその恩恵を受けられます。またこうすることで、さまざまな検索エンジンを通じて、同じ疑問を持つ人がメーリングリストのアーカイブからその解決策を得ることが可能です。

7.2.4. 問題が難しすぎる場合のバグ報告

問題を解決するために行ったすべての努力が失敗に終わった場合、問題の原因はあなたの責任のおよぶところになく、プログラムのバグかもしれません。この場合 Debian にバグを報告したり、上流開発者に直接報告したりするとよいでしょう。これを行うには、可能な限り問題を分割し、問題を再現できる最小のテスト環境を作ってください。問題の明白な原因となっているプログラムがわかっている場合、dpkg -S file_in_question コマンドで関連するパッケージを見つけることが可能です。そしてバグ追跡システム (https://bugs.debian.org/package) を使って、問題となっているパッケージに対してそのバグがまだ報告されていないことを確かめてください。その後、reportbug コマンドでバグ報告を送信してください。その際には、可能な限り多くの情報を含め、特に誰もがバグを再現できる最小テストケースの完全な説明を含めてください。
この章では、効率的な問題解決の手段を解説しました。以降の章ではこの手段を使うことになるでしょう。必要に応じて何度でも使ってください!