1110.2  Linux的日志文件

传统的UNIX系统往往因为它们做日志的方法不一致，甚至还有点儿怪异而受到批评。幸运的是，虽然Linux系统的每一种发行版本都有自己的一套给日志文件命名和分类的方法，但是一般而言Linux要好一点儿。Linux的软件包大多将它们的日志信息送到的软件包大多将它们的日志信息记录到/var/log目录下的文件里。在有些发行版本上，个别日志也保存在/var/adm里。

现如今，大多数程序都把它们的日志项发送到一个称为syslog的中央清理系统，syslog将在本章后面予以介绍。默认的syslog配置一般将这些信息的大部分转储到/var/log中的某个地方。请检查系统日志的配置文件/etc/syslog.conf，找出这些信息究竟存在什么地方。有关syslog.conf文件的格式，请参考第1110.4.1节。

表1110.1总结了一些在我们举例的系统中较为常见的日志文件的有关信息。具体有如下几项：

—  存档、汇总或截断的日志文件；

—  创建各个日志文件的程序；

—  有关如何指定每个文件名的指示；

—  我们认为留意或者清理的合理频率；

—  使用日志文件的发行版本（在我们的例子中出现过）；

—  文件内容的说明。

除非特别说明，否则文件名都是相对于/var/adm或/var/log而言的。

“Where（出处）”一列中的字符说明了日志文件的指定方法：S代表使用syslog的程序， F代表使用一个配置文件的程序，而H则代表文件名是否直接包含在代码中。 “Freq（频率）”一列表明了我们建议的清理频率。“发行版本”一列给出了该项适用的发行版本。

虽然各个发行版本上日志文件的所属关系和模式都有不同，但日志文件一般由root所有。就我们看来，大多数日志的模式都应该是600（只有属主有读写权限），因为它们的内容对于黑客来说可能有帮助。如果用户的水平相当高，那么能够查看日志对用户会有好处。在这种情况下，放开日志文件的部分权限也是合理的。

 

专为日志建立一个用户组，把日志文件的属组设为这个用户组，让这个用户组的成员都能读取日志文件，这是另一种合理的做法。您可以把本地的系统管理员加入到这个用户组里，让他们不必使用sudo命令就能看到日志文件的内容。如果站点有一个初级系统管理员，他没有完全的sudo特权，这样的安排就特有用。

 

 

虽然各个发行版本上日志文件的所属关系和模式都有不同，但日志文件一般由root所有。就我们看来，大多数日志的模式都应该是600（只有属主有读写权限），因为它们的内容对于黑客来说可能有帮助。至少，应该限制用户对secure、auth.log和sudo.log文件不经意地查看。绝对不要把任何日志文件的写权限交给属主之外的任何人。

值得说明的一点是，表1110.1中给出的日志文件大多数都是由syslog维护的，但是syslog的默认配置则随系统的不同而变化很大。采用了比较一致的/etc/syslog.conf文件时文件后，各Linux发行版本上的日志文件看上去就相当相似了。

表10.1                              日志文件列表

文  件	程  序	出  处a	频  率a	发行版本a	内    容
auth.log	su等b	S	M	DU	授权
apache2/*	httpd第2版	F	D	SDU	Apache HTTP服务器的日志（第2版）
boot.log	rc脚本	Fc	M	RF	系统启动脚本的输出
boot.msg	内核	H	-	S	内核消息缓冲的转储
cron	cron	S	W	RF	cron的执行情况和出错信息
cups/*	CUPS	CF	W	所有	与打印有关的消息（CUPS）
daemon.log	许多	S	W	DU	所有守护进程功能的消息
debug	许多	S	D	DU	调试输出
dmesg	内核	H	-	RFDU	内核消息缓冲的转储
dpkg.log	dkpg	F	M	DU	软件包管理日志
faillog	login	H	W	DSSDU	不成功的登录企图
httpd/logs/*	httpd	F	D	RF	Apache HTTP服务器的日志（在/etc下）

续表

文  件	程  序	出  处a	频  率a	发行版本a	内    容
kern.log	内核	S	W	DU	所有kern功能的消息
lastlog	login	H	-	所有	每个用户上次登录的时间（二进制）
mail*	与mail有关的	S	W	所有	所有mail功能的消息
messages	许多	S	W	所有	经常是主要的系统日志文件
rpmpkgs	cron.daily/rpm	H	D	RF	已安装的RPM软件包清单
samba/*	smbd等	CF	W	-	Samba（Windows/CIFS文件共享）
secure	sshd、sudo等	S	M	RF	保密的授权消息
syslog	许多	S	W	DU	经常是主要的系统日志文件
warn	许多	S	W	S	所有的警告/出错级的消息
wtmp	login	H	M	所有	登录记录（二进制）
Xrog.n.log	Xorg	F	W	RFS	X窗口服务器的出错信息
yum.log	yum	F	W	RF	软件包管理日志

a．出处: ：S=syslog, H=硬连接, ，F=配置文件。

   频率：: D＝每天，W＝每周，M＝每月。

   发行版本： R＝Red Hat Enterprise Linux，F = Fedora，D＝Debian，S＝SUSE，U = Ubuntu。

b．passwd、login和shutdown也可以写入授权日志。在Red Hat和Fedora系统上，它在/var/adm里。

c．实际是通过syslog做日志，但是在/etc/initlog.conf中配置功能和级别。

表11.1    日志文件列表

 

a. 出处: S=syslog, H=硬连接, F=配置文件

  频率: D＝每天，W＝每周，M＝每月

  发行版本： R＝Red Hat，D＝Debian，S＝SuSE

b. passwd、login和shutdown也可以写入授权日志。在Red Hat上，它在/var/adm里。

c. 实际是通过syslog做日志，但是在/etc/initlog.conf中配置方式和级别。

1110.2.1  特殊的日志文件

大多数日志是文本文件，当发生“感兴趣的”事件时，就会向这些文件中写入日志记录行。但是表1110.1中列出了几个日志文件中列出的几个日志，但它们的来龙去脉却非常不同。

/var/log/wtmp中包含用户登录系统和退出系统的记录，也包含了表明系统何时重启或者关机的记录项。因为新的记录项只是简单地追加到文件的末尾，所以它是一种相当普通的日志文件。不过，wtmp文件是以二进制形式保存的。使用last命令可以解读这些信息。尽管wtmp的格式不一般，但是应该像其他任何日志文件那样，轮换或者截断这个文件，因为它的自然特性是无限制的增长。

/var/log/lastlog包含的信息类似于/var/log/wtmp中的信息，但是它只记录每个用户上次登录的时间。它是一个稀疏的二进制文件，以UID作为索引。如果您的UID是以某种数字序列来指定的，那么虽然这肯定对现实世界没什么影响，但这个文件会变得小一些。lastlog文件不需要轮换lastlog文件，因为除非有新用户加入，否则它的大小保持不变。参见9.3.1节的脚注了解有关“稀疏”文件的更多知识。

1110.2.2  内核和启动日志

内核和系统启动脚本反映出了在日志领域内的一些特殊的挑战。对于内核来说，问题在于既要创建有关引导进程和内核操作的永久记录，又不能增加对任何特殊的文件系统或者文件系统组成的依赖性。对于启动脚本而言，挑战在于既要捕捉启动过程的连贯描述，又不能总是试图把任何系统守护进程都和启动日志文件扯到一块，干扰任何程序自己的日志机制，或是让启动脚本做两份日志项或者把日志输出重定向。

 

内核的日志机制是通过让内核把它的日志项保存在一个大小有限的内部缓冲区来做到的。缓冲区要足够大，以便能放得下内核在引导时的活动所产生的全部消息。一旦系统全部启动以后，用户进程就可以访问内核的日志缓冲，最终处理它的内容。各发行版本一般是运行dmesg命令，并把它的输出重定向到/var/log/dmesg（Red HatRHEL、Fedora和、Debian和Ubuntu）或者/var/log/boot.msg（SuSESUSE）。这是查看最近启动过程信息的最好的地方。

内核当前运行的日志机制是由一个叫做klogd的守护进程处理的。klogd的功能实际上是dmesg功能的超集，除了转储内核的日志并退出之外，它还可以在内核缓冲区内的消息产生的时候读取它们，并将其发送到一个文件或者syslog。在正常的运行方式下，klogd采取后一种模式；。syslog根据对“kern”的指令来处理这些消息（一般把它们发送到/var/log/messages）。

我们举例用的发行版本的启动脚本在一开始转储日志消息的时候，都不用dmesg的-c标志，所以虽然读取了内核的消息缓冲区，但并不清除它。当klogd启动的时候，它在缓冲区里发现了和dmesg见到的一样的一组消息，于是把它们发送给syslog。出于这个原因，有些日志项既会出现在dmesg或者boot.msg文件里，又会出现在如/var/log/messages这样由syslog管理的文件里。

内核日志机制的另一个问题是要在系统控制台做适当的管理。伴随系统的引导，在控制台上输出信息是很重要的。不过，一旦系统已经启动了，控制台的消息可能与其说是帮助，不如说是烦人，如果用控制台登录的话就更是这样了。

dmesg和klogd都可以让您用一个命令行标志设置内核的控制台日志级别。例如：

%$ sudo dmesg-n 2

级别7级提供的信息最多，还包括调试信息。级别1级只包含内核的“panic（恐慌）”消息（最小的编号小的级别最严重）。所有的内核消息继续进入中央缓冲区（也进入syslog），而不管它们是否被转发到控制台。

内核在/proc/sys目录下提供了一些控制文件，让大量重复发生的日志消息在来源处就被阻塞。参见28.4节，了解通过设置哪些内核参数来实现一般控制机制的更多信息。这些专门的控制文件是/proc/sys/kernel/printk_ratelimit和/proc/sys/kernel/printk_ratelimit_burst，前者指定在启动阻塞之后内核消息之间必须间隔最少多少秒（默认为5s），后者规定在启动阻塞之前允许多少组消息通过（默认为10）。这两个参数都是建议性的，所以它们不会绝对保证能制止大量消息。

 

 

遗憾的是，系统启动脚本的日志机制没有内核的日志机制管理得好。Red Hat Enterprise Linux采用一条叫做initlog的命令来截取启动命令的输出的命令来捕获启动命令的输出，并把它发送给syslog。遗憾的是，无论什么时候运行命令，都必须明确提到都必须明确调用initlog，所以确实要以某种复杂性为代价才能捕获到信息。这些日志项最终还是会进入/var/log/boot.log。

我们举例用的其他系统都没有连续捕获启动脚本的历史输出。个别命令和守护进程能记录下来一些信息，但是大多数信息都不作日志记录。

 

Fedora以前使用和Red Hat一样的initlog系统，但是现在这条提交日志记录的命令已经从启动脚本中注释掉了。幸好还有一个工具函数的中央库/etc/init.d/functions，您可以在那里去掉initlog的注释行重新启用它们。

 

Fedora formerly used the same initlog system as Red Hat, but the commands to

submit log entries have been commented out of the startup files. Fortunately, there’s

a central library of utility functions, /etc/init.d/functions, where you can uncomment

the initlog lines to reenable them.

我们举例用的其他系统都没有连续捕获启动脚本的历史输出。个别命令和守护进程能记录下来一些信息，但是大多数信息都不作日志记录。