7.2. 通常步骤
本节主要向您展示系统管理员经常遇到的通用操作的提示信息。这个过程未必包括所有可能遇到的情况,但可以作为处理更复杂问题的开始点。
发现 其他语言的文档
通常情况下,非英语的文档都会放置在一些与软件包本身对应的独立软件包当中,这些独立的软件包会加上 -*lang*
之类的后缀(根据语言的不同,这里的 lang 会被替换为 ISO 标准的两字符语言编号)。
因此,apt-howto-fr 这个软件包就包含了法文版的 APT howto文档。与此同时, quick-reference-fr 和 debian-reference-fr 都是法文版本的Debian参考指引(最初的英文版本是由 Osamu Aoki 编写的)。
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进程通常将其所遇到的所有出错信息报存在一种被成为日志文件或者系统日志的文件中。日志文件通常报存在 /var/log/
目录或者其子目录当中。要准确知道日志文件对应的daemon进程,可以查看其文档。需要注意的是,单次测试通常不足以覆盖所有可能的用例;某些问题只在特定的条件下才会产生。
工具使用rsyslogd
后台进程(daemon)
rsyslogd
很特殊:它收集由其他程序发送给它的日志信息(内部系统消息)。每个日志的入口,都与一个子系统(如电子邮件、内核、授权系统等等)以及一个优先级相联系;rsyslod
通过这两部分的信息来决定下一步操作。日志消息可能被记录在多个不同的日志文件当中,和/或被发送到管理终端上。具体的定义都被记录在配置文件/etc/rsyslog.conf
当中(手册文档页的名称与配置文件名相同)。
rsyslogd
有提供特定的C函数用以发送日志信息,这能有效简化其使用的复杂程度。然而,一些后台运行的程序会由其自身来进行对日志文件的管理(samba
程序就是这样的例子,其作用是实现Windows到Linux系统的文件共享)。
请注意在使用systemd
时,日志实际上是由systemd
进行搜集的,之后才会转发至rsyslogd
。因此这些日志可经由systemd
的日志系统,使用journalctl
进行查阅(参见第 9.1.1 节 “Systemd 启动系统”以了解详细信息)。
基础知识 Daemon
一个守护进程是指不直接由用户调用而停留在后台的一类程序,在某些特定条件被满足的时候就会执行一些任务。很多的服务器程序都是守护进程,并且这类程序的命名通常都会以一个字母“d”来结尾(例如 sshd
、smtpd
、httpd
,等等)。
作为一种预防措施,管理员应当定期阅读近期相关的系统日志。如此可以在遇到问题而不高兴的用户报告问题之前便发现问题。的确,用户可能会在数天中等待问题重复发生数次之后才报告问题。在大多数场合下,有一些专门的工具可以分析较大的日志文件的内容。特别地,存在分析网页服务器日志的工具(如analog
、awstats
、webalizer
,它们和 Apache 协同工作),以及针对 FTP 服务器、代理/缓存服务器、防火墙、电子邮件服务器、DNS 服务器甚至是打印服务器的日志分析工具。其中某些工具支持以模块的方式运行,从而可以分析数种不同类型的日志文件,例如 lire
。还有其它工具,如logcheck
(该软件在 第 14 章 安全 部分有所讨论),能够扫描日志文件并搜索需要处理的告警信息。
7.2.3. 通过邮件列表寻求帮助
如果经过多番查找仍然没办法找出问题的根源,最可能得到帮助的方法,就是去咨询有经验的人。[debian-user@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-user@lists.debian.org)
邮件列表正是为此意图而设立的。如其他社区一样,邮件列表作为一种社区,同样有其需要遵守的规则。在提出任何问题之前,需要再三检查问题是否符合着些规则,你需要确认问题并未包含在近期的讨论话题以及任何的官方文档之中。
→ https://wiki.debian.org/DebianMailingLists
→ https://lists.debian.org/debian-user/
“
TIP 从网络上浏览列表
对于一些高度活跃的邮件列表,如[debian-user@lists.debian.org](https://www.debian.org/doc/manuals/debian-handbook/mailto:debian-user@lists.debian.org)
,通常都值得将其当作论坛(或新闻组)来浏览。网站Gmane.org 则允许以这种格式对Debian的列表进行咨询。刚提到的邮件列表地址如下:
→ http://dir.gmane.org/gmane.linux.debian.user
基础知识 实用网络礼仪
一般来说,对于所有邮件列表上的信件来往,都应当遵守网络礼仪(Netiquette)的相关规则。这个术语(Netiquette)指代一组常识性的规则,从常见礼貌行为到应当避免犯的错误都有所涉及。
→ http://tools.ietf.org/html/rfc1855
此外,Debian项目组提供了沟通的频道。在这里你可以联系上Debian的源代码组织负责人(the Debian Code of Conduct):
→ https://www.debian.org/code_of_conduct
一旦你遇到的问题满足了以上两个条件,你就可以考虑将你所描述的问题提交到邮件列表。发布的内容尽可能包括如下一些信息:不同的测试条件,所查阅过的文档,诊断问题的方法,相关的依赖包以及其他一切可能包含的信息信息等。检查Debian的Bug跟踪系统(或简称BTS工具 缺陷跟踪系统)上有没类似的问题,向查找出来的bugs链接提交你研究的结果。BTS的地址是
→ http://www.debian.org/Bugs/index.html
只有当问题描述更加精确且措辞得当,你才能有更大的机会得到答案,或至少能得到一些有用的回应。如果你收到一些与问题相关的私人电邮,不妨考虑将其公布到邮件列表当中,这可以使得其他人受益。同样如果邮件列表能被进行归档,或者能被不同的搜索引擎索引,也能使问题的解决方案更容易被查找到。
7.2.4. 报告棘手的问题所存在的Bug
如果所有的努力都不能解决你所遇到的问题,或许得不到解决方法并非你的责任,而更可能是因为程序本身存在缺陷。在这种情况之下,合理的流程就是将缺陷向 Debian 或者直接向上游的开发者进行报告。要做到这一点,你需要对有问题的程序进行有效的隔离,并且创造一个可以使问题重现的最小测试环境。如果你知道是什么原因导致的问题,则可以使用命令 dpkg -S *file_in_question*
来寻找问题文件对应的软件包。请查阅缺陷跟踪系统(https://bugs.debian.org/*package*
)以确保该问题尚未被其他人报告。之后,你可以使用命令 reportbug
来发送你自己的缺陷报告,其中应当包括尽可能多的信息,特别是关于可用于重现问题的最小测试用例方面的完整描述,以便于其他人重现你所报告的缺陷。
本章旨在更有效地解决后面章节可能遇到的问题。有需要的话,就经常使用这些方法吧!