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 包名 会给出软件包当中的文件列表；通过这个列表，你能迅速的找到有用的文档（包括位于/etc/目录下的配置文件）。dpkg -s 包名 这个命令能显示包的元数据信息，并显示任何可能的推荐或建议软件包；通过这些命令，你就能找到那些让软件配置工作变得容易的文档或者工具。

最后，上述的配置文件通过注释的方式通常都拥有良好的自定义文档，这些注释对每个变量的取值和设置的方式都用详细的描述。对于想对某行配置开启某些特定功能来说，这种注释文档的方式足以应付。在一些情况下，配置文件的样例，都会在 /usr/share/doc/package/examples/ 目录。这些样例可以作为基本的配置文件使用。

要理解守护进程(Daemon)做了什么通常都更加的复杂，因为系统管理员与进程间并不进行直接交互。要检查守护进程（daemon）的工作状态，需要进行测试。例如：如果要测试Apache（web服务）的daemon是否有效，需要通过生成http请求的方式进行测试。

为了有效记录测试的结果，守护进程通常将其所遇到的所有出错信息保存在一种被称为日志文件或者系统日志的文件中。日志文件通常保存在 /var/log/目录或者其子目录当中。要准确知道日志文件对应的daemon进程，可以查看其文档。需要注意的是，单次测试通常不足以覆盖所有可能的用例；某些问题只在特定的条件下才会产生。

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.

如果经过多番查找仍然没办法找出问题的根源，最可能得到帮助的方法，就是去咨询有经验的人。debian-user@lists.debian.org邮件列表及其特定语言版本 debian-user-lang@lists.debian.org 正是为此意图而设立的。如其他社区一样，邮件列表作为一种社区，同样有其需要遵守的规则。在提出任何问题之前，需要再三检查问题是否符合着些规则，你需要确认问题并未包含在近期的讨论话题以及任何的官方文档之中。

一旦你遇到的问题满足了以上两个条件，你就可以考虑将你所描述的问题提交到邮件列表。发布的内容尽可能包括如下一些信息：不同的测试条件，所查阅过的文档，诊断问题的方法，相关的依赖包以及其他一切可能包含的信息信息等。检查 Debian 的 Bug 跟踪系统（BTS，在侧栏中 第 1.3.2.1 节 “反馈缺陷” 描述）上有没类似的问题，向查找出来的 bugs 链接提交你研究的结果。BTS 的地址是

只有当问题描述更加精确且措辞得当，你才能有更大的机会得到答案，或至少能得到一些有用的回应。如果你收到一些与问题相关的私人电邮，不妨考虑将其公布到邮件列表当中，这可以使得其他人受益。同样如果邮件列表能被进行归档，或者能被不同的搜索引擎索引，也能使问题的解决方案更容易被查找到。

如果所有的努力都不能解决你所遇到的问题，或许得不到解决方法并非你的责任，而更可能是因为程序本身存在缺陷。在这种情况之下，合理的流程就是将缺陷向 Debian 或者直接向上游的开发者进行报告。要做到这一点，你需要对有问题的程序进行有效的隔离，并且创造一个可以使问题重现的最小测试环境。如果你知道是什么原因导致的问题，则可以使用命令 dpkg -S file_in_question 来寻找问题文件对应的软件包。请查阅缺陷跟踪系统（https://bugs.debian.org/package）以确保该问题尚未被其他人报告。之后，你可以使用命令 reportbug 来发送你自己的缺陷报告，其中应当包括尽可能多的信息，特别是关于可用于重现问题的最小测试用例方面的完整描述，以便于其他人重现你所报告的缺陷。

本章旨在更有效地解决后面章节可能遇到的问题。有需要的话，就经常使用这些方法吧！