When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.

その後、ソフトウェアの公式文書を確認してください。既存のさまざまな文書源を見つける方法は第 7.1 節「情報源となる文書」を参照してください。dpkg -L package コマンドでパッケージに含まれるファイルのリストが表示されます。さらに、このコマンドを使えば、利用できる文書 (と同時に /etc/ に格納された設定ファイル) を素早く特定することも可能です。dpkg -s package でパッケージのメタ情報が表示されるので、そこから推奨パッケージや提案パッケージが分かります。さらにそこから、ソフトウェアの設定を簡単に行うための文書またはユーティリティを見つけることも可能です。

最後に、設定ファイルには通常、各設定項目に関して設定できる値をそれぞれ詳細に説明した説明用コメントが数多く書かれています。このため、利用できる行を選んで有効化するだけで十分な場合もあります。また、設定ファイルの例が /usr/share/doc/package/examples/ ディレクトリの中に格納されている場合もあります。設定ファイルの例は、自分の設定ファイルのたたき台になります。

デーモンの挙動を理解するのはやや面倒です。なぜなら、デーモンは管理者と直接的に対話するものではないからです。デーモンが実際にどのような作業をしているかを確認するには、デーモンをテストする必要があります。たとえば、Apache (ウェブサーバ) デーモンの挙動を確認するには、HTTP リクエストを使ってテストします。

この種のテストを行うために、デーモンは通常自分のしたことだけでなく発生したエラーも含めてすべてを「ログファイル」や「システムログ」と呼ばれるログに記録します。ログは /var/log/ の中か、このディレクトリのサブディレクトリの中に保存されます。それぞれのデーモンの正確なログファイル名を知るには、文書を確認してください。そのテストによって考え得る使用例のすべてが満足されない限り、テストは必ずしも 1 回で十分とは限らない点に注意してください。さらに、いくつかの問題は特定の状況下でしか起こりません。

As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in 第 14 章「セキュリティ」), scan these files in search of alerts to be dealt with.

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the [email protected] mailing list and its language specific siblings debian-user-lang@lists.debian.org. As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.

Once those two conditions are met, you can think of describing your problem to the mailing list. Include as much relevant information as possible: various tests conducted, documentation consulted, how you attempted to diagnose the problem, the packages concerned or those that may be involved, etc. Check the Debian Bug Tracking System (BTS, described in sidebar 第 1.3.2.1 節「バグの報告」) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:

礼儀正しく正確であればあるほど、答えを得られる (少なくとも多少の反応を得られる) チャンスが大きくなります。私信で関連する情報を受け取った場合、その情報を要約して公にすることを考えてください。そうすれば、他の人がその恩恵を受けられます。またこうすることで、さまざまな検索エンジンを通じて、同じ疑問を持つ人がメーリングリストのアーカイブからその解決策を得ることが可能です。

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

この章では、効率的な問題解決の手段を解説しました。以降の章ではこの手段を使うことになるでしょう。必要に応じて何度でも使ってください!