Product SiteDocumentation Site

7.2. 通常步骤

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

7.2.1. 配置一个程序

当你需要配置一个未知的软件包时,你必须按照如下步骤:首先,必须将原维护者所编写的文档通读一遍。阅读完 /usr/share/doc/package/README.Debian 这文件之后,软件的使用将会变得简单。为了要了解程序原本的运作原理与新的版本间的不同之处,阅读文档(如 howtos 类的文档)就显得尤为重要。着些文档甚至会包括一些常见错误的处理办法,这能有效避免你在一些常规问题上多浪费时间。
然后,你需要阅读软件的官方文档——对应于第 7.1 节 “文档资源”上一节有提到文档存在于不同的地方。采用命令dpkg -L 包名 会给出软件包当中的文件列表;通过这个列表,你能迅速的找到有用的文档(包括位于/etc/目录下的配置文件)。dpkg -s 包名 这个命令能生成包的元数据信息以及显示任何对软件包可能的意见与建议;通过这些命令,你就能找到那些让软件配置工作变得容易的文档或者工具。
最后,上述的配置文件通过注释的方式通常都拥有良好的自定义文档,这些注释对每个变量的取值和设置的方式都用详细的描述。对于想对某行配置开启某些特定功能来说,这种注释文档的方式足以应付。在一些情况下,配置文件的样例,都会在 /usr/share/doc/package/examples/ 目录。这些样例可以作为基本的配置文件使用。

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

要理解后台进程(Daemon)做了什么通常都更加的复杂,因为系统管理员与进程间并不进行直接交互。要检查后台进程(daemon)的工作状态,需要进行测试。例如:如果要测试Apache(web服务)的daemon是否有效,需要通过生成http请求的方式进行测试。
为了有效记录测试的结果,,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. Other tools, such as logcheck (a software discussed in 第 14 章 安全), scan these files in search of alerts to be dealt with.

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

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 mailing list and its language specific siblings . 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 节 “Reporting bugs”) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:
只有当问题描述更加精确且措辞得当,你才能有更大的机会得到答案,或至少能得到一些有用的回应。如果你收到一些与问题相关的私人电邮,不妨考虑将其公布到邮件列表当中,这可以使得其他人受益。同样如果邮件列表能被进行归档,或者能被不同的搜索引擎索引,也能使问题的解决方案更容易被查找到。

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

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