Product SiteDocumentation Site

7.2. 通常步骤

本节主要向您展示系统管理员经常遇到的通用操作的提示信息。这个过程未必包括所有可能遇到的情况,但可以作为处理更复杂问题的开始点。

7.2.1. 配置一个程序

当你需要配置一个未知的软件包时,你必须按照如下步骤:首先,必须将原维护者所编写的文档通读一遍。阅读完 /usr/share/doc/package/README.Debian 这文件之后,软件的使用将会变得简单。为了要了解程序原本的运作原理与新的版本间的不同之处,阅读文档(如 howtos 类的文档)就显得尤为重要。着些文档甚至会包括一些常见错误的处理办法,这能有效避免你在一些常规问题上多浪费时间。
Then, you should look at the software's official documentation — refer to the previous section to identify the various existing documentation sources. The dpkg -L package command gives a list of files included in the package; you can therefore quickly identify the available documentation (as well as the configuration files, located in /etc/). dpkg -s package displays the package meta-data and shows any possible recommended or suggested packages; in there, you can find documentation or a utility that will ease the configuration of the software.
最后,上述的配置文件通过注释的方式通常都拥有良好的自定义文档,这些注释对每个变量的取值和设置的方式都用详细的描述。对于想对某行配置开启某些特定功能来说,这种注释文档的方式足以应付。在一些情况下,配置文件的样例,都会在 /usr/share/doc/package/examples/ 目录。这些样例可以作为基本的配置文件使用。

7.2.2. 监控后台进程在做什么

Understanding what a daemon does is somewhat more complicated, since it does not interact directly with the administrator. To check that a daemon is actually working, you need to test it. For example, to check the Apache (web server) daemon, test it with an HTTP request.
为了有效记录测试的结果,,daemon进程通常将其所遇到的所有出错信息报存在一种被成为日志文件或者系统日志的文件中。日志文件通常报存在 /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, webalizer for Apache), for FTP servers, for proxy/cache servers, for firewalls, for e-mail servers, for DNS servers, and even for print servers. Some of these utilities operate in a modular manner and allow analysis of several types of log files. This is the case of lire or also modlogan. Other tools, such as logcheck (a software discussed in 第 14 章 安全), scan these files in search of alerts to be dealt with.

7.2.3. 通过邮件列表寻求帮助

如果经过多番查找仍然没办法找出问题的根源,最可能得到帮助的方法,就是去咨询有经验的人。邮件列表就是为此意图而设立的。如其他社区一样,邮件列表作为一种社区,同样有其需要遵守的规则。在提出任何问题之前,需要再三检查问题是否符合着些规则,你需要确认问题并未包含在近期的讨论话题以及任何的官方文档之中。 "
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 TOOL Bug tracking system) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:
The more courteous and precise you have been, the greater your chances are of getting an answer, or, at least, some elements of response. If you receive relevant information by private e-mail, think of summarizing this information publicly so that others can benefit. This also allows the list's archives, searched through various search engines, to show the resolution for others who may have the same question.

7.2.4. 报告棘手的问题所存在的Bug

如果所有的努力都不能解决你所遇到的问题,或许是因为得不到解决方法并非你的责任,而更可能是因为程序本身存在bug。在这种情况之下,更合理的流程就是将bug向Debian或者上游的开发者进行回报。要做到向开发者们报告,你需要对有问题的程序进行有效的隔离,并且创造一个最小的测试环境使得问题可以重现。如果你知道是什么原因导致的问题,则可以使用命令 dpkg -S file_in_question 来查阅Bug跟踪系统,以确保该问题尚未被其他人上报。确认无上报后,使用命令 reportbug 来提供尽可能完整的信息,特别是关于可用于重现问题的最小测试用例方面的描述。
本章旨在更有效的解决后面章节可能遇到的问题,建议上述方法能经常被采用。