7.2. 通常步骤

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

发现 其他语言的文档

通常情况下，非英语的文档都会放置在一些与软件包本身对应的独立软件包当中，这些独立的软件包会加上 -*lang* 之类的后缀（根据语言的不同，这里的 lang 会被替换为 ISO 标准的两字符语言编号）。

For instance, the debian-reference-fr package is the French version of the reference guides for Debian (initially written in English by Osamu Aoki), and the manpages-de package contains the German version of the manual pages about using GNU/Linux.

7.2.1. 配置一个程序

当你需要配置一个未知的软件包时，你必须按照如下步骤：首先，必须将原维护者所编写的文档通读一遍。阅读完 /usr/share/doc/*package*/README.Debian 这文件之后，软件的使用将会变得简单。为了要了解程序原本的运作原理与新的版本间的不同之处，阅读文档（如 howtos 类的文档）就显得尤为重要。着些文档甚至会包括一些常见错误的处理办法，这能有效避免你在一些常规问题上多浪费时间。

然后，你需要阅读软件的官方文档——对应于第 7.1 节 “文档资源”上一节有提到文档存在于不同的地方。采用命令dpkg -L *包名* 会给出软件包当中的文件列表；通过这个列表，你能迅速的找到有用的文档（包括位于/etc/目录下的配置文件）。dpkg -s *包名* 这个命令能生成包的元数据信息以及显示任何对软件包可能的意见与建议；通过这些命令，你就能找到那些让软件配置工作变得容易的文档或者工具。

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

DEBIAN 政策 样例文件的位置

所有的配置文件样例必须安装在/usr/share/doc/*package*/examples/ 目录。这些样例文件包括配置文件，程序的源代码（用于展示库的使用方法的代码），或者是给系统管理员在特定情况下（如初始化一个数据库）使用的数据转换脚本。如果这个样例只是针对某个特定的体系架构，则必须被安装在 /usr/lib/*package*/examples/ 这个路径，并且作一个链接到目录 /usr/share/doc/*package*/examples/ 去。

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

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

基础知识 Daemon

一个守护进程是指不直接由用户调用而停留在后台的一类程序，在某些特定条件被满足的时候就会执行一些任务。很多的服务器程序都是守护进程，并且这类程序的命名通常都会以一个字母“d”来结尾（例如 sshd、smtpd、httpd，等等）。

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

工具使用rsyslogd后台进程（daemon）

rsyslogd is special: it collects logs (internal system messages) that are sent to it by other programs. Each log entry is associated with a subsystem (e-mail, kernel, authentication, etc.) and a priority; rsyslogd processes these two pieces of information to decide on what to do. The log message may be recorded in various log files, and/or sent to an administration console. The details are defined in the /etc/rsyslog.conf configuration file (documented in the manual page of the same name provided in the rsyslog-doc package).

Certain C functions, which are specialized in sending logs, simplify the use of the rsyslogd daemon. However some daemons manage their own log files (this is the case, for example, of samba, which implements Windows shares on Linux).

请注意在使用systemd时，日志实际上是由systemd进行搜集的，之后才会转发至rsyslogd。因此这些日志可经由systemd的日志系统，使用journalctl进行查阅（参见第 9.1.1 节 “Systemd 启动系统”以了解详细信息）。

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 [debian-user@lists.debian.org](https://debian-handbook.info/browse/zh-CN/stable/mailto:debian-user@lists.debian.org) mailing list and its language specific siblings [debian-user-*lang*@lists.debian.org](https://debian-handbook.info/browse/zh-CN/stable/mailto: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.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

基础知识 实用网络礼仪

In general, for all correspondence on e-mail lists, the rules of Netiquette should be followed. This term refers to a set of common sense rules, from common courtesy to mistakes that should be avoided.

→ https://tools.ietf.org/html/rfc1855

此外，Debian项目组提供了沟通的频道。在这里你可以联系上Debian的源代码组织负责人（the Debian Code of Conduct）:

→ https://www.debian.org/code_of_conduct

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:

→ https://bugs.debian.org/

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

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

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

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